We all know the IT Infrastructure Library® ITIL® describes what needs to get done. The ITIL just describes process models and does not provide step-by-step directions. The ITIL is guidance that you must interpret and adapt before you can use.
Processes describe the work performed by people. Practicing ITIL then becomes a simple idea: understand your existing processes (workflow), compare it to ITIL models, adapt, improvise, and overcome!
But as Shakespeare said, "aye, there's the rub" - IT processes often span more than a single silo, so its very difficult to find a worker or manager who truly knows the entire end-to-end process workflow.
This realization is fundamental to your success practicing ITIL - how a process currently works is often very different from how you think it is (or should be) working.
Following I provide the key steps you should take before you attempt any process design or re-design.
Step 1 - Process Control Truths
The very first thing you have to do is accept that no one really knows what is going on and how people perform their work, neither workers nor managers.
It might seem obvious that the higher your management role, the less you truly understand how work actually gets done. However, not only do managers often have no idea of how processes get performed, most workers could not tell you if you asked them either.
Hundreds of years of manufacturing process improvements have raised two facts about workflow. First, only those who actually perform the job tasks really have the skills to accomplish a job; and second, you cannot ask the worker what they are doing, since they have internalized many of the skills tasks.
In other words, only those doing the work know how to do it, and you cannot ask them about their work because they are not consciously aware of all the little steps. This fundamental disconnect has been occurring in every process improvement program since the beginning of process control.
Human Resource professionals refer to documenting what a skilled subject matter expert (SME) actually does as task analysis. In professional task analysis you observe the subject matter expert and record what they are doing. You do not ask them what they plan to do, but rather record what they actually did.
This is because virtually very SME has internalized many elements of the work. They tend to do things without realizing they are doing them. Thus, asking them to write down what they do results in incomplete process and workflow documentation.
It often turns out that these "missing" steps are key elements in the workflow, and mask the real issues or opportunities. Begin by putting aside pre-conceived ideas of what is "right" and "wrong", but do clarify the goals and what you expect to be accomplished, the end result.
Regardless of what you think you know, the work really getting done, and how it gets done, is different. Be ready for some real surprises!
Step 2 - Real vs. Imaginary Workflow
Since step 1 is to accept that you neither you nor your staff really understands whatever process you are about to engineer or re-engineer. This makes the very first step to learn first hand what is really transpiring.
The only way to actually discover what is really getting done is to get up from behind the desk, walk out of the office, and literally walk around, observe, and take notes. You cannot practice ITIL from behind a desk. This sounds simple, but as in many things, the doing is not so straightforward. To practice ITIL you have to walk the process, literally.
To succeed you have to understand the difference between what is expected and what is actually going on so you can understand the factors and variables involved. Only once you understand the real process workflow can you improve or change.
Your mission here is not to enforce compliance or conformance, but rather to understand why the work is getting done as it is. Note that I did not write "why the work is getting done wrong" - and this is key - work gets done according to what it takes, not what you think it takes. At this stage, assigning guilt and labels such as "right" or "wrong" is not productive.
Many managers feel they must gather together a group of workers and build or document process workflow as a group process. This is not correct because it is an imaginary exercise. Experience and best practice shows this method actually takes much longer and results in incomplete understanding.
However, you may need a willing accomplice in your process evaluation -- a subject matter expert. It is much easier to model process based on observing a willing participant. A SME can help reduce how much information you have to record, and can validate and/or explain the reasoning behind many actions. Just remember that most SMEs don't know themselves every little thing that they actually do.
Learn about performing a task analysis, if possible locate and select an SME, and then walk the process, making notes of workflow and tasks. Start with the most common workflow. Note exceptions to what you believe to be "correct" but don't stop or interrupt the SME while they work, instead make a note and review these exceptions with the SME later on.
Keep in mind that your goal is to collect and model the existing process as it works today; not what you imagine it ought to be, but rather the actual tasks and workflow in place.
Step 3 - Walk the Walk
Your goal is to observe the entire workflow, and this takes time. If you consider the service desk as an example, you might need a few hours to observe how calls get answered, the tasks involved, the delays, waiting periods, tool usage, documentation accessed, physical movements, etc. Other processes might take even longer. Your goal is accuracy and detail, so take your time.
Observe the selected SME. Here are some suggested tips for gathering workflow:
- Make sure whomever you are observing know what you are doing and why - they are the experts and you want to know how they make it happen
- Focus on the normal or routine work, not the exceptions
- Observe more than one repetition of the process
- Write down important things immediately
- Take good notes that you can actually read afterwards
- Be meticulous and pay attention to details
- Don't interrupt the SME, criticize or try to correct the SME
You need to capture the "who, what, when and where" of the process, and should skip the "how and why" for now. So during your task analysis try to record:
- Who is doing the work and each time the person doing the work changes
- What is done at each step in the process
- When the process begins, the time it takes to perform each major task and any delays
- Where the work is located at the start of the process and where the work goes
- Once you have all the facts, you must build a process flow chart to model the workflow.
Step 4 - Model the Workflow
Now is the time to make a flowchart! And now you see what you cannot make a flow chart in an office or conference room.
You can model the workflow (task analysis) via an outline or using flowcharting symbols.
Common flowcharting symbols are:
Start/End - An oval indicates the beginning of a task as well as the conclusion of a task. A flowchart should have just one starting point but will probably have many end points. For example, the beginning of the Problem Management process.
Input/Output - A parallelogram indicates an input or an output. Keeping with the previous Problem Management example an input is the Incident Record. An output might be a Known Error Record. Usually, an output becomes the input to another process or chain of events.
Process/Procedure - A rectangle indicates a simple procedure. Technically this is called a process, but don't get confused with ITIL process and the Process flowchart symbol. These processes do not include decisions. Continuing the example, a flow chart process might be review of Incidents associated with the problem record.
Decision - A diamond indicates a decision, and flowing "out" of this symbol will be other chains of start/end, input/output, process/procedure, and decision symbols.
Table 1. Process Control Symbols
You can also simply use a text outline if you wish. The important thing is to document what really occurs as completely as possible and to produce your model as soon after collecting the data as possible.
Regardless of now you collect the data you need to create the model the same day you collect the information. This is because you yourself have not written everything down! In your mind is the glue required to properly document what you have learned - if you wait to write it all down you will lose vital details.
When you create your model, make it using a simple and easy to understand "blocks". This allows anyone, especially those not familiar with the process, to follow the process workflow. For now, don't include the timings in your flow chart, stick to the work, we can add the timings later.
Try laying down your model from left to right, with other activities within the process flowing "down" from the top level blocks. Try to prevent doubling back and crossovers if possible.
Review your chart with the SME. Then review the chart again by walking the process a few more times to tune your chart. Once you are satisfied that your chart accurately reflects what is going on (not what you want to go on) you can go back add in the timings.
Be ready for a shock here - you will most likely be absolutely astonished at the actual work and time involved. Now you are ready to think about ITIL, and how you might be able to improve the workflow.
Conclusion
Designing a process takes work and direct observation of one or more SMEs. It also takes attention to detail. You have to actually get up and leave your office to perform a task analysis.
Perhaps the hardest part is accepting that you don't really know what is going on. It is also very difficult to impartially observe a person doing something that you think could be done better without intervening - but your goal is to be an impartial observer. If you cannot do this then you ought to consider having an unbiased professional document your processes. You goal during task analysis is documentation, not improvement.
Part of learning what is really going on is to collect every form used by anyone involved with the process under study. Capture screen dumps or physical copies of any data entry form used. Take good notes about how it's used. Do the same for any other "tools" or systems in use. If you cannot get a copy then at least document the tools in use.
A key tenet of ITIL is efficiency -- working smarter, not harder. Thus, improvement in the time it takes to do things is an important measure. This is well known in manufacturing and human resources circles, but often overlooked or omitted by IT managers seeking to improve workflow.
Along with gathering the tools in use, you need to capture how long it takes to perform the work. You need to be able to answer the question "how long does it take to do this" before you can answer the question "should this be changed."
The value of an accurate process model cannot be underestimated. You cannot improve anything without understanding it first.