Why does it take so much effort to automate a process into a workflow

By ITIL® from Experience ©

Many ITSM tools have workflow functionality. They can automate process models like an assembly line so that tasks are automatically assigned to the next participant as they are completed.

To automate a process as a workflow, effort is needed understand what is being automated. As a result it is normal to ask Business Analyst type of questions such as is there a: flow-chart or business process document, RACI Matrix12, work instructions, user guide and training material. However, some people may see this analysis as unnecessary and a waste of time. After all "people know their job; it’s simply to automate it." Moreover, when external resources like consultants are used there might be a perception of gouging due to the amount of effort spent on the analysis.

Things like these need to be analyzed for a successful automation:


    • Data required by each task
    • Source of the data (i.e. another system or manual data entry if an interface is unfeasible)
    • Sequence when the data is created and when it is needed by each task
    • Business rules for the data (e.g. access restrictions, retention, naming convention, format for data interchange)


    • Business objective and Critical Success Factor (CSF)

      Critical Success Factor (CSF):

      Something that must happen if an IT service, process, plan, project or other activity is to succeed. Key performance indicators are used to measure the achievement of each critical success factor. For example, a critical success factor of ‘protect IT services when making changes’ could be measured by key performance indicators such as ‘percentage reduction of unsuccessful changes’, ‘percentage reduction in changes causing incidents’ etc.

      Source: ITIL® glossary and abbreviations, English, 2011

    • Performance measures and reporting needs like Key Performance Indicators (KPI) and metrics
    • Authorization and decisions points needed to direct the flow
    • Roles of process participants to determine access permissions/restrictions
    • Process inter-dependencies. For Example, even an employee hiring process is related to other processes that affects its design (e.g. legislation, pay & benefits, performance management)


    • Training requirements to determine if a training system will be required for hands on training with partially completed records for hands on exercises.
    • Procedures for people to transition their work in progress to the new workflow

During this analysis it is not unusual to discover that the current way of doing business does not reflect the documented process or the common understanding of how things are done. There are a lot of subtleties and nuances in tribal knowledge and people's interpretation of practices that evolved over the years.

For example, in one organization, a custom application was developed to process trademark applications according to the legislation. However, during the User Acceptance testing, users refused the application as it did not enable their current process. The Project Manager, the developers and management were all taken aback. How could users disagree with the application as it was based on the legislation? Unfortunately, over the years the clerical procedures evolved causing a significant variance. All of a sudden this simple automation project was transformed into a business process re-engineering3 and compliance.

Organization should be cautious with any estimates if the process is not documented and updated recently. Estimates are often done from a technology perspective whereby it is easy to code/configure. However, most of the effort is spent understanding the business and how the work is performed to gather requirements.

The risk of not having a good understanding of the requirements may result in a disrupted business process flow, capacity and confused people. Moreover, it is well known that most IT projects fail to deliver the expected business results and value. This failure is rarely caused by technology. They usually fail because the business process and context was not well understood. Thus, some workflows may take a lot of effort to develop and implement to be successful.


Implementation > Technology (ITSM Tools)

1. RACI: (ITIL Service Design) A model used to help define roles and responsibilities. RACI stands for responsible, accountable, consulted and informed. Source: ITIL® glossary and abbreviations. English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx
2. A synonym for RACI is Authority Matrix. Source: ITIL® glossary and abbreviations. English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx


Copyright 2014 - ITIL® from Experience - D.Matte