ITIL
Flowcharts
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.