How to identify workflows to develop first

By ITIL® from Experience ©

Many ITSM tools have workflow functionality. They can automate process models like an assembly line so that tasks are assigned to the next participant as they are completed. One challenge is to identify which workflow to develop first. Ideally, the first workflow would: a) yield the best Return On Investment (ROI), b) improve service, c) be used by a large number of people to inspire them with possibilities and, d) be easy to implement to catch that proverbial “low hanging fruit.” All of this is more easily said than done.

Although the method discussed here can be used for any process, our focus will be on identifying workflows for Service Requests. We specifically exclude Incidents since their resolution process is often unpredictable and thus less prone to automation. Moreover, if incidents have a known resolution and I.T. gets a lot of them, they should be addressed by Problem Management. At minimum, the Known Error and, thus its workaround should be documented and made available to the Service Desk and/or to the Users via a Web site, a Knowledge Base or a Wiki. However, we digressed.

Good candidates for workflows are requests that need the involvement of several groups to be fulfilled. Also, a key element is that its fulfillment follows a well-established process. One approach is to ask the Service Desk since many have documented procedures as it helps them provide consistent service when faced with a high-staff turnover. However, their tendency is to propose the automation of the process causing the most operational pain. Most often they are painful because of complexity due to the number of groups involved with unclear business rules and blurred responsibilities between participants. Instead, a six steps approach is proposed using the ITSM tool’s data.

Step 1: The Report

Prepare a report listing all Service Requests not resolved at the first point-of-contact or in other words requests that were assigned more than once. The report should also contain the following information:

Category of the request (e.g. Purchase Request, Account Creation)
Total number of assignments between groups and between individuals
Name of all the groups the request was assigned to
Duration of the request (i.e. difference between the date opened and closed)
Name of the group and the individual who:
- Received the request for the first action and,
- Completed/closed the request.

Step 2: Top 10 Categories

Identify the ten categories used the most (i.e. Top 10). Next, if a major change was made to a process recently, remove it from the list. Even though changes are usually made to address issues there is a risk that they may not have all been resolved. In addition, like most implementations certain requirements may have been differed to the next version/phase along new issues and enhancements discovered since it was last modified. Selecting such processes to automate will be perceived as this next phase, thus opening a “can-of-worms.” Also, resist the temptation to implement a new-process to address operational issues. An existing and stable process should be used to ensure a quick implementation and capture that low hanging fruit. Thus, focus on processes to automate, not design.

Step 3: Number of Assignments

Identify requests that have been assigned three or four times between I.T. groups. Too many assignments usually indicate a complex process or that it is not well understood by participants. Less than 3 assignments and the value of structured workflows diminish as people could simply manually reassign the request to the next person.

Step 4: Duration

Isolate requests of short duration as they usually indicate that the steps are well understood by individuals who participate in the process.

Step 5: Documentation and Owner

Next, determine which of these requests are documented (e.g. process guide, work instructions, check lists) which also have a distinct process owner. If they do not have a process owner, identify requests that are consistently assigned to the same group and that are completed/closed by the same people.

Having this consistency indicates process predictability. It also identifies key stakeholders and Subject Matter Experts to help design and test the workflow as well as discuss the process' business rules.

Step 6: Organization Unit

Finally, identify requests performed entirely by one organizational unit. This expedites the creation of the workflow as it helps secure buy-in from Management. At minimum, the first few workflows developed should be within I.T. to avoid cross-organizational boundaries.

Automating a well understood business process is relatively straightforward to accomplish. Once a few simple workflows have been developed, it is easier to automate complex processes involving multiple organizational units. However, it may take you a while to get to that point as people may be asking for your help to build workflows as they discover their benefits.

Plugin disabled

Plugin footnotearea cannot be executed.

<HR>