[51CTO.com Special Report] On one side, demands from leadership; on the other, resistance from employees. Trying to “change wheels while the car is moving” can feel utterly overwhelming. How can he solve the problem of operations management?
“Southern Oranges” Turn Into “Northern Bitter Oranges”
Director Wang heads the billing business center of a provincial telecom company. With fifty to sixty employees, the billing business center is responsible for the construction and operation of critical business systems such as provincial billing and business analytics. Although the billing business center has quite a few people, each system typically has only one or two individuals assigned to it. Due to rapidly changing business needs and frequent system upgrades, these employees focus most of their energy on project construction and engineering. Operations assurance remains at a rather basic, reactive state: work mainly consists of passive, “firefighting” style responses, with virtually no records or summaries for troubleshooting and system maintenance processes. Director Wang understands that ITIL (Information Technology Infrastructure Library) implementation is a management project. The ITIL standards are indeed advanced, the consulting experts are absolutely correct, and the expensive software from major vendors certainly has many features. But when it comes to practical implementation in his own department, it always feels disconnected. Listening to experts and vendors, everything sounds perfectly logical 鈥?just buy their products and services and all ailments will be cured. Yet after spending a lot of money, it seems no illness has been treated, and it is hard to even pinpoint exactly what is wrong with their offerings. Has ITIL failed to adapt to the domestic environment, or are the prescriptions from large international vendors simply not addressing the real problems? He can’t exactly claim that the illness itself is wrong, can he?
The application of ITIL in this enterprise boils down to the following key problems:
鈼?System construction consumes a massive amount of departmental resources, leaving no capacity for operations assurance work;
鈼?Some employees are unwilling to accept the changes brought by ITIL;
鈼?The phenomenon of “one person playing multiple roles” in processes is severe, leading to significant resistance at the execution level;
鈼?Usage of process tools is suboptimal, and the effectiveness of system construction is not significant enough.
Don’t Let ITIL Turn Into a “Northern Bitter Orange”
80% of the problems enterprises encounter during IT operations are caused by management issues, and management problems require management methods to solve them. This is one of the reasons why ITIL, as the best practice for IT management, is so highly regarded. However, despite ITIL having a “pure pedigree” of successful practices from major foreign enterprises, just like the principle behind “Southern Oranges becoming Northern Bitter Oranges,” simply transplanting others’ successes does not guarantee your own. According to our surveys of major domestic enterprises, quite a few have adopted ITIL, but very few have truly utilized it effectively and realized its value. The topic of discussion has gradually shifted from “What” to “How.” How to correctly implement ITIL within an organization so that its best practice concepts and methods can take root, germinate, and thrive in the domestic IT soil, eventually yielding the desired harvest 鈥?how to make the “Northern Bitter Orange” as sweet as the “Southern Orange,” or even surpass it to become a praiseworthy “Northern Orange” 鈥?has become a severe and challenging real-world problem.
How to Harvest “Southern Oranges” in the North – Building Fault Point Dependency Relationship Displays
Fault analysis is often the most headache-inducing part, because finding the root cause of a problem takes a lot of time. Yet in our past operations, a common phenomenon occurs: after spending a great deal of effort resolving a fault, someone immediately calls asking why fixing this issue caused another function to stop working. In fact, when administrators focus entirely on handling a fault, they often overlook other IT resources related to that fault point. This leads to situations where we might “rob Peter to pay Paul.” If there were a mechanism that could help administrators list the dependent IT resources related to a fault point while handling it, then administrators would have a reference to conduct risk analysis during the fault-handling process proactively. This way, the phenomenon of solving an old problem only to create a new one would not occur. For example, consider the following fault:
|