* Defining and developing IT processes
Today, it seems like it’s all about process. Two years ago, in the U.S., it was difficult to find someone who could spell ITIL, let alone know what it was all about. ITIL caught on in Europe much earlier on, but slowly and surely ITIL and process-oriented methodologies are garnering much more attention.
Process is nothing new. Businesses have been operating for centuries and even decades with their own processes. No, they aren’t all automated or facilitated by technology, but they are processes nevertheless. So why is process such a “new” trend to IT?
Processes do exist in IT. However, many of the processes are individually developed, and some have their genesis in “the way it’s always been done before,” rather than a planned approach to developing efficient and repeatable processes.
Part of the fault rests with the nature of the environment – a problem happens, then IT staff members have to quickly respond. The problems are frequently unexpected, and the correct response depends on what the problem is. So the permutations of possible problems and possible responses are quite overwhelming. (This is quite different from manufacturing processes that are repetitious and constant – they more easily lend themselves to processes and also automation.)
The IT environment most easily lends itself to ad hoc processes rather than proscribed processes, primarily because of the unpredictable environment, the human element that is required and organizational issues. Plus, staffers don’t have the time to define and refine their processes.
What’s bringing process to the forefront of IT thinking today is that IT is being forced to do it. One of the drivers for the interest in IT processes are the regulatory mandates requiring IT organizations to prove that they have taken reasonable care in controlling their IT processes. And you can’t prove that you’re in control of your processes if you don’t know what they are, or if they aren’t documented, or if the processes aren’t auditable.
The second driver is the push for efficiency in IT. Efficiency initiatives have focused on technology – for example, using server consolidation and virtualization to optimize the utilization of the technology. Staffs have also been reduced to squeeze out costs. The one area that has been largely untouched in this effort to maximize IT efficiencies is the process area. There is a wealth of efficiencies that can be reaped from focusing on processes.
The third driver for this increased attention on processes is the push toward automation and responsive infrastructures that can adapt rapidly as business needs change. Automation is not a silver bullet for processes. In reality, automation should not be undertaken unless there are established processes that are already stable and effective. To automate a process, the following must already be in place: you have to trust the current manual process, the process should be documented, the process should be well tested, and the results should be easily verifiable. Only then is a process ready to be automated.
So what do you do if you haven’t started to pay attention to your processes? The first step assess where you are today. Document the processes that you have, and make note of areas where you don’t have processes defined.
Are there any IT processes defined? Are they documented? Are the defined processes being used in practice? If not, why? It’s the answers to questions like these that will provide you with an understanding of where you are.
The next step is to understand where you’re heading. Review the strategic direction of your business and IT’s strategic direction. (Hint: They should be aligned.) This review of strategy should give you a good idea of where your company is headed, as well as your IT organization. Then take what you’ve learned about the strategy and determine what processes will enable the strategic direction of the company and IT.
Next, select and prioritize the processes that need to be worked on. The priorities can be based on critical processes that seriously need to be fixed, their priority in support of strategic initiatives, IT objectives, processes that are most easily automated, or any other factors that will help to set the priorities.
Then develop a plan for working on the processes, including timelines and responsibilities defined. Don’t try to fix everything at once – it’s an evolutionary process. In fact, it’s better to start on even a single process and doing that right, than not proceeding because the task seems so overwhelming.
And lastly, as much attention as ITIL is getting, keep in mind that it is a guideline to assist in the development of IT processes. Remember that the goal is the development of the processes, not ITIL itself. ITIL is one approach, and although it is useful for those focusing on process, you must use whatever works for you and your IT organization – even if it doesn’t carry the ITIL label.
With that said, go and conquer.
