The purpose of this article is to create an awareness of five of the most common pitfalls related to the work of defining, improving, and implementing positive change in the business through the lens of business processes.  The five topics, covered as 'mistakes', are not meant to be all-inclusive.  There are almost as many opportunities to fail as there are to succeed when individuals or teams seek to contribute to the success of an organization through positive changes to its "ways of working."  There are numerous challenges faced when change becomes the norm in a business.  Hopefully, this article will provide a few useful insights into process discovery that will allow the reader to avoid the most common pitfalls.

1.  Starting at the workflow level

Based on research and surveys that have been conducted by a number of organizations (such as the Gartner Group) concerning the focus of most process improvement efforts, it's known that about 65% of organizations are conducting these projects at the tactical or project level.  The majority of these process improvement projects are initiated as part of some type of change in technology.  The individuals involved began their discovery and documentation of the processes as close to the technology level as possible, typically at the step level or (in generic process level terms) process level 5 or 6.  As a result, only portions of the processes are actually documented.  This provides an incomplete view and understanding of the process.  Further, without an E2E (end-to-end) view of the process there will be numerous opportunities for unintended negative consequences such as:

• ineffective decisions by management regarding priorities and focus due to poor visibility into the process,
• poorly-designed or configured systems due to the lack of transparency with regard to data usage and system requirements,
• increase in costs due to resource redundancy and duplication of work,
• decrease in revenue as a result of high levels of customer dissatisfaction and loss of market share.

Finally, the company closes its doors as competitors take the business.

To avoid this, organizations start by creating transparency with regard to people, process, and technology from the top down.  To support and enable this transparency and understanding, the documentation of processes must be from the top down, not bottom up, perspective.

To create alignment and high-level transparency that supports business and technology, organizations should focus on selecting and prioritizing their projects based on business objectives instead of technology priorities.  Next, organizations leverage this transparency to directly align the organization's technology priorities with its strategic business objectives.  Try asking the following two questions from the IT perspective:

1. What value is being delivered to the business through the technical functionality?
2. What business process does the technical functionality enable?

And from the business perspective:

1. How does the technical functionality help the business achieve its business objectives?

2.  Identifying the stakeholders too late

The stakeholders of a process are often not identified until the project is testing or in preparation for implementation.  As a result, the needs and requirements of these stakeholders are not known or made part of the solution and often result in the project being put on hold while it is determined what should be done to respond to these requirements.  In some cases, it is only during implementation that these requirements are discovered.  This can result in the project being stopped completely and, in some cases, never implemented due to these delayed requirements.

Projects should make the identification of stakeholders one of its number-one priorities, perhaps even before the complete definition of the project.  It is not only the external stakeholders but also the internal stakeholders who must be identified.  The majority of the time the internal stakeholders are identified as functional groups within an organization.  While this is a starting point, the real internal stakeholders are processes not functional groups.  Since processes are cross-functional, identifying a functional group as a stakeholder will be very limiting in scope.  Normally, one process will encompass stakeholders from two to seven functional areas.  By identifying only one, the project is missing the requirements of the other three to six, or perhaps 50% of the requirements.  Missing any stakeholder requirements will create problems with the appropriate changes being made to the processes and technology, and will create numerous problems with implementation.  This results in unanticipated consequences that are rarely positive.

3.  Working on process individually vs. as part of an architecture

As noted earlier, about 65% of organizations are conducting process improvement projects at the tactical or project level.  For example, a problem is identified in a specific area of an organization and a project is initiated to solve the problem.  The majority of these organizations don't have their processes identified but will attempt to document some of them as part of the project.  The result is that, at the beginning of the project when the scope, resources, objectives, and timelines are being defined and signed off, very few of the interfaces are known between the various groups in an organization.  This relates directly back to Mistake #1.

• ineffective decisions by management regarding priorities and focus due to poor visibility into the process

Fundamentally, to avoid most of the issues around this problem an organization should first create, then maintain and mature, a process architecture before making any major investments in business or technology changes.

A process architecture enables an organization to identify all of the interfaces for a process, both internal and external, as part of the definition and discovery phase of a project, providing more accurate information for resources, timelines, milestones, and deliverables.  This also provides very useful information to the Change Management team for scoping the impact and communication strategy.  These interfaces include the familiar and traditional input and output flow but also the classifications of additional categories of information called guides and enablers. Guides include the events and policies, procedures, KPIs, knowledge, business rules, requirements, and criteria.  Enablers are systems, tools, resources, and assets of any kind that are required to transform an input into an output.  This will allow an organization to identify how the process-in-focus fits within the organization's other processes and to more accurately evaluate the impact of changes to the organization.

4.  Capturing incomplete process information

When making changes to an organization's business or "way of working", one of the greatest obstacles to identifying the real opportunities for improvement is that only a very small portion of the information about the process is actually known.  This is caused by documenting business processes in basically the same way that system flows are captured, e.g., a system flow is comprised of inputs and outputs.  Unfortunately, from a business perspective, these inputs and outputs represent only about 15% of the understanding, and therefore opportunity, to improve a process.  The majority of the opportunities identified will come from knowledge about the guides and enablers (mentioned above) for process.  Additionally, many of these flow diagrams only show the lines between the activities, not what is moving across that line.  This lack of labeling the lines means that even the inputs and outputs aren't really captured.

The business rules are a major source of opportunity for significant improvements to a process.  The business rules should be captured as Guides in process documentation.  For example, in one organization, by changing the business rules regarding who was empowered to review, verify, and authorize certain transactions, they were able to reduce the cycle time for a portion of their process from fifteen days to forty-five minutes.  Applying the same concept, another organization reduced the cycle time for the acquisition and installation of network servers from ten days to two days.

These examples of efficiency are exclusive of technology.  They relate to improvements to the activities in the process.  Technology solutions are then applied to these improved activities.

5.  Not involving enough of the people who work in the process

The fifth major obstacle to process change is resistance from the people in the process.  The phrase "resistance is futile" cannot be applied to process change.  People can and will successfully resist change in process.  In many cases it could be classified as passive resistance, but it's still resistance and it will prevent "real" process change from occurring.

To avoid this, the people who work in the process targeted for improvement should be part of the team working on the improvement.  Their ideas and suggestions must be eagerly sought out, welcomed, and implemented as quick wins or as part of the overall solution whenever possible.  It's critically important to create a sense of ownership with the people who are part of the process.  People who model the process DO NOT own the process, but that perception is easily created. 

People will almost always resist change.  Therefore, they must believe that the changes being made are actually beneficial to them and the organization.  In addition, appropriate recognition must be given for their ideas that have resulted in positive, bottom-line results.  This recognition and celebration encourages employees on future projects to contribute positively by actively submitting and encouraging both major and minor changes.  This creates an environment where anyone can easily be part of the solution, not the problem.

Conclusion

It should be readily apparent that all of these issues are related with an overall theme of a top-down strategic approach that strives to involve as many of the stakeholders (as is reasonable) in the solution.  Furthermore, the strategic alignment of business and IT is a critical success factor of the overall solution.  Finally, just as a home or building or an airplane cannot be built without blueprints, neither can a successful business.  The blueprints for a business are the various architectures, with an Enterprise Architecture as the overarching view, supported and integrated with other various architectures, including (but not limited to) a Process Architecture.  Although not the main focus of this article, a Process Architecture is one of the critical components of successfully adding value to the organization through the transparency it enables.

# # #