BPM is unique in offering so much promise while being so generally ignored. Even among companies that actively pursue some level of process improvement, only a few have a process based management structure. At least one reason for our tepid impact is our failure to model an enterprise-wide perspective in the initial launch of process improvement efforts. Gartner Inc. reports that in North America IT leads 42% of the BPM efforts and the Business leads 58% of the efforts. How can we ever hope to create an enterprise-wide view of process when we start out with a narrow, functional perspective? The reason organizations tend to remain at the initial stages of BPM is because employees focus on their own jobs, managers have priorities in their own departments, and C-suite executives are incented by initiatives in their own divisions or business units. To move to a more enterprise approach employees, managers and C-suite executives need to think outside their area, identify how the organization serves the customer and then commit to creating results cross functionally for the organization. This wider thinking starts with the business and IT working together as sponsors and as teams, driving initiatives together from the top and team level. Hopefully one day Gartner will report that almost 100% of process improvement efforts are driven by a cross-functional team from IT and the relevant business units.
Getting Started: Creating the Foundation for Enterprise BPM
There are three initial elements that make a business process improvement a success and build process capability across the organization.
- A high-level map providing scope and quantifiable improvement goals
- Active executive sponsorship
- The right team members
A high-level map is a process map of 6-10 steps that describes the key activities in the process. It defines the team members and the scope of the process. The beginning and end of the process bounds the scope and the sponsor and project lead designate what’s in and out of consideration, such as different scenarios, customer segments, geographic regions, etc.
 |
The high-level map signals what roles should be on the improvement team.
 |
The sponsor selects the team members, sets the project charter by defining the scope and quantitative improvement goals, keeps the team on focus during the improvement effort, and drives the implementation recommendations. Why not have co-sponsors– one from IT and one from the business? I have seen co-sponsorship work very successfully.
The project lead knows the process best (the most experienced subject matter expert), ensures that the team makes improvements to meet the sponsor’s goals, and leads the implementation efforts. The facilitator uses a structured business process methodology to guide the team to model, analyze, and make improvements to the identified process. Subject Matter Experts are people who do the work at each step of the high-level map. The team needs representation for all the roles and departments who participate. IT – Each team needs to have at least one person (but could be more) from IT. This person is someone who works with the application systems that interface with the process. This person provides knowledge about the functionality of the current system, how changes in the functionality would benefit the process, how to integrate with other systems in the organization, and ideas for what would be possible with new systems. It could be a business architect, business analyst, developer, database analyst, or others with relevant technology expertise. |
If it seems to you in a process as straightforward as the hiring process that you do not need the business and IT, think again. There are many business subject matter experts from different business units doing hiring, Human resources, and IT to help think about how to relate recruiting software with human resources software.
Here’s the first secret: Engage the business and IT together from the start. They should both be members of the team. When the two work together in all the phases of business process improvement effort, they see the end-to-end process as a unit, not just individually from their own perspective. They work toward the same goal – the improvement goal designated by the sponsor(s). It is critical that they move beyond the goals specific to their function. The IT member, for example, has to be first and foremost a member of the team, and only secondarily a voice of the IT perspective.
Building the Process Model
The team takes the high-level map and builds a more detailed model that documents the current process using a swim lane format. Each swim lane shows a role or system.
Often business team members perform the daily operations and think of the process at a very detailed transactional level. IT, on the other hand, often lacks understanding of the business context and has a view of the process that is isolated to the technology task.
There are many ways to build the process model. Best case is all team members are in the same room and you do it on a wall together. Alternatively, use a tool such a Visio, IBM Blueworks, or other vendor applications with an LCD projector that projects onto the wall or on a white board over the web. Some organizations have business analysts conduct an interviews with key stakeholders. This method does not get the team talking to one another and discovering the similarities and tensions among them. That conversation is important not just for the richness of the data it creates, but for the relationships it creates as well. An enterprise-wide perspective requires working relationships that cross functional boundaries.
I am just beginning to use Business Process Model and Notation 2.0 (BPMN), the standard language of these “as is” diagrams from Object Management Group (OMG). There are many advantages for using BPMN.
- It creates a standard visual language that all can understand (business and IT) that can become the standard for the company. (I have seen too many organizations use different software which makes it difficult for groups to ‘read’ each other’s models.)
- It captures information at the high level map and then builds sub processes so that each sub process is nested in the higher process.
- Models from this As Is stage transfer to more detail models automatically, which can be used to run simulations and eventually for execution of the redesigned process and automating improvements.
Mapping the current process together
- Enables all team members to contribute and feel valued
- Allows each team member to see what his/her part is and how it impacts other steps
- Takes the process from verbal stories and examples to a document ‘on the wall’
- Informally elicits issues and improvement ideas (Keep track of these!)
- Builds a common language of the steps, their sequence, the symbols on the process model, and the specific vocabulary of the process
- Develops an understanding of the end to end process by all
Here’s the second secret: Build the process model with a common language that all understand. The common language comes from four elements:
- Developing the model together
- Using agreed common symbols on the model (BPMN or simple flow chart symbols.)
- Gathering quantitative data at key points about steps in the model (Quantitative data tells us about the process in an objective way which informs the team about the gaps from the improvement goals.)
- Doing a customer scorecard– have each team member do a short interview with a customer to find out what customers need, want, and require of the process and how the process is currently performing. Information from the customer is the second guiding light along with the improvement goals for focusing the team when it is ready to make improvements to the process.
Using Visual Analysis to Impact Communication
Next, it is time to analyze the As Is process models. Many organizations have a process tools they use for analysis, such as identifying wastes, time, cost, resources, risks and control points, and errors. However, most organizations don’t know how to display the analysis data and engage others with it. Instead, they make lists, do PowerPoint presentations, and have files showing the results of evaluation tools.
How should the team think about the 30-100 issues and ideas from these lists? The answer: build a Visual Analysis Model. Put each of your challenges on the current process model using designated icons or symbols. Place them where they go, at the step or decision where they take place. Add quantitative data, risks, control points, quality problems, and time to the model using different icons as well. Then step back and look at your model. Ask yourselves where the problems cluster? What problem themes can you see? If we fixed problems in some areas, would others go away? Which problems correlate most highly with our improvement goals?
Example of a Visual Analysis model
 |
The visual analysis model enables the team to analyze the process model and the analysis notations as a holistic system. Patterns, themes, and interrelationships become much more evident. It is easier to decide what priorities are important for the redesigned map. Additionally this visual analysis model becomes a tool for communication and further engagement. Other employees can affirm the steps in the model, as well as the issues, risks, measures, etc it now displays. I had one client who developed the visual analysis model first with the process improvement teams. Then they gave executives a plain process model and asked them to put issues they knew or saw and build a second visual analysis model. The team and executives compared the two. You can guess how easily the dialog flowed.
Here’s the third secret: Turn the process map into a visual analysis model. With a visual analysis model, everyone can see where the problems are, and they can add the ones they know. This creates a high level of engagement based on data. It also creates a high level of shared thought among the team members. The team is working as one seeing where the patterns are and deciding what the priorities are in relationship to the improvement goals and the customer needs. The model becomes a living, breathing representation of the current state, and the gaps are obvious. Now the team begins to make decisions together, with the business and IT working toward a common goal. Employees are no longer focused on their individual silos; they work to improve the process for the organization.
Conclusion
In order to move from individual improvement activities to a BPM organization that sees process improvement as a integral practice of how it does work, employees, managers and the C-suite must
- Understand their role in each end to end processes
- Know how improving the process will impact the company
- Be committed to creating the result needed for the organization
To get there, widen the engagement circle. Get the right employees and management (that means the business and IT) involved in working together on key processes (not just giving input). In today’s world, technology is an integral part of the business. Currently when IT and the business hand off assignments or requirements to each other, the ball is dropped, there is misunderstanding, and little opportunity for synergy. More importantly, if the IT and business sponsors do not model a high level of collaboration, they cannot expect the organization to see the enterprise-wide potential of BPM. Process improvement efforts will remain siloed and returns aren’t optimized. If you want to build a good foundation for BPM, start by getting the business and IT collaborating on the same team. As Peter Senge, says, “The team is the unit of learning in an organization. Unless the team can learn, the organization cannot learn.”
