A flowchart is a graphical representation of a process, depicting inputs, outputs and units of activity. It represents the entire process at a high or detailed (depending on your use) level of observation, allowing analysis and optimization of workflow.
So, ITIL Flowcharts are a graphical representation of a process. ITIL Flowcharts represent the entire process from start to finish, showing inputs, pathways and circuits, action or decision points, and ultimately, completion. ITIL Flowcharts can serve as instruction manuals or a tools for facilitating detailed analysis and optimization of workflow and service delivery.
So, ITIL Flowcharts are a pictorial representation showing all of the steps of a process. A Flowchart is used for:
- Defining and analyzing processes (example: What is the registration process for entering freshmen students?)
- Building a step-by-step picture of the process for analysis, discussion, or communication purposes (example: Is it possible to shorten the length of time it takes for a student to complete the program?)
- Defining, standardizing, or finding areas for improvement in a process
Steps for creating ITIL Flowcharts are:
- Familiarize the participants with the flowchart symbols
- Brainstorm major process tasks. Ask questions such as “What really happens next in the process?”, “Does a decision need to be made before the next step?”, or What approvals are required before moving on to the next task?”
- Draw the process flowchart using the symbols on a flip chart or overhead transparency. Every process will have a start and an end (shown by elongated circles). All processes will have tasks and most will have decision points (shown by a diamond).
- Analyze the flowchart for such items as:
- Time-per-event (reducing cycle time)
- Process repeats (preventing rework)
- Duplication of effort (identifying and eliminating duplicated tasks)
- Unnecessary tasks (eliminating tasks that are in the process for no apparent reason)
- Value-added versus non-value-added tasks
ITIL Flowcharts Problem Management Process:
1) Identify High Occurrence of Similar Incidents. Level 1 Support Analyst
(Problem Manager) provides incident trend analysis and identifies high occurrence incidents from the Service Desk (Incident Control). Proceed to 2.
2) Review Incident Records. Problem Manager and Service Desk reviews all relevant incidents indicated by the trend analysis. Capturing, using, and analyzing of incident history is done at this point and documented. Proceed to 3.
3) Is more information required? If yes proceed to 4.
4) Contact Customer and Gather more information. Get additional information from customer that have reported the incidents, review with technical support in the resolution of the incidents, etc. Proceed to 5.
5) Create/Update the problem record. Proceed to 6.
6) Categorize and assess the impact of the incidents. Determine who is impacted, what is impacted, the effect in time, resources, and cost. Proceed to 7.
7) Does the problem reflect incidents? Does this problem warrant the problem management process? If yes, proceed to 10. If no, proceed to 8.
8) Create/Update Problem record.
9) Update the Service Desk on the status of the problem. Close the problem record.
10) Identify and Assign Level 3 Support Resource. A Level 3 support specialist(s) to perform root cause analysis, design solution. Proceed to 11.
11) Perform root cause analysis. Determine the root cause of the incidents. (Need to define known error at this point). Proceed to 12.
12) Design Problem Resolution. This includes solutions, develop requirements, and identify required resources. Proceed to 13.
13) Solution Acceptable? Would this cost too much? Does it impact more than it fixes? If no, proceed to 14. If yes, proceed to 15.
14) Modify the Resolution? If yes, proceed to 12. If no, proceed to 8.
15) Build/Test the solution. (This should be another process output, i.e., to deployment, or planning, or what) Proceed to 16.
16) Passed Test/Verification? The production environment test for the solution passed? If yes, proceed to 17. If no, proceed to 14.
i?) Change required implementing the solution? If no, proceed to 18. If yes, proceed to the Change management Process.
18) Implement the solution. (This should be another process output, i.e., to deployment, or planning, or what) Proceed to 8.