Millions of dollars spent, countless hours wasted, and frustrated business users seem to be fairly standard outcomes when IT and business try to work together. While this problem seems apparent, little progress has been made. What is happening? I believe two key factors are in play. First both the IT and business folks are operating under a number of faulty assumptions. Here are some flawed assumptions from the IT perspective.
- Business users know their process.
- Business users know what is wrong with the process and how to fix it. (Give me an IT solution even if that is not the problem.)
- There is no value in doing an “as is” flow chart.
- If we do an “as is” map, then let’s put every variation of the process on one map. (It ends up looking like spaghetti and meatballs.)
- IT can go it alone, and IT professionals sometimes try to be heroes, and will attempt to make things work even if no one else does their part.
- We don’t have the time to do a lot of analysis because business wants a quick solution. (Which may be true, but is damaging.)
From the business side, here are some flawed assumptions:
- IT is the only solution to the problem.
- I (the manager) have already figured out what IT solution I need, just implement it.
- I (the manager) know the process well. At least I know what they “should be” doing.
- I (the manager) know what’s wrong with the process.
- Business users know what their customers want. (A customer is the entity at the end of the process and receives the output.)
- Business expects that IT will take care of everything, with little or no effort on anyone else’s part. (Which may be true, but is damaging.)
- We don’t have the time to do a lot of analysis because we want a quick solution. (Which may be true, but is damaging.)
The second factor which causes the divide is a deficient methodology. I researched the International Institute of Business Analyst’s Body of Knowledge (IIBABOK), Version 1.6. While the scope is wide, there are some glaring omissions.
IT folks spend a considerable amount of time gathering requirements. From the IIBABOK, Chapter 4: Requirements Elicitation, here is the intended audience.
- Marketing
- Project team
- Subject matter experts
- Primary and secondary stakeholders
- Current/potential users of a system.
Interestingly there is no mention of the Customer. (The customer can be internal or external. The customer is the entity at the end of the business process and receives the output.) What does the customer of the process need, want, expect, or desire? The most important group in any improvement methodology is the customer. The Customer requirements are critical since I believe the purpose of all business processes is to meet or exceed customer requirements. Both Six Sigma and Lean methodologies are built around customer requirements. Shouldn’t we find out how the process is performing based on customer requirements? I have numerous examples of where the business users guessed what their customers wanted. When we interviewed the customers, we found the guesses to be way off target.
The next problem in the IIBABOK is generating the process model. According to the IIBABOK, a workflow model represents:
- business activities,
- the sequential flow of these activities,
- the persons who perform the work,
- key business decisions that affect the flow of work, and
- the start and end points of the process flow.
In addition to the diagram, some textual information is also required to ensure that the diagram is useful and understandable. For example, each activity requires at least a meaningful description. Other information, such as process volumes (e.g. time, costs, resources), may also be collected.
The main omission in the above is finding out what’s wrong with the current process. In my 21 year career as a process improvement consultant, I have yet to find a perfect “as is” process. How can you create a better process if you don’t know what’s wrong with the current one?
When we analyze processes we look at the process from various perspectives which I call “lenses of analysis.” The lenses are: Customer satisfaction (As mentioned earlier)
Worker frustration Quality issues (Six Sigma and Lean methodology)
Timeliness issues (Lean Methodology)
Cost (Activity Based Costing)
Waste (Lean Methodology)
I seldom use all six lenses. My favorites are customer satisfaction, worker frustration, quality issues, and time. After we have analyzed the process and found issues, problems, and key data, they are then placed on the “as is” flow chart so everyone can see them. (See Shelley Sweet’s article in the BPMI newsletter, “Taking the Process Map to the Next Level – The Visual Analysis Map.”) By making the problems visible, it:
- Helps pinpoint problem areas
- Shows that the “as is” needs fixing. We can’t just automate the
“as is.” - Allows everyone to reach agreement on prioritization of problems
- Identifies some obvious solutions
- Shows many solutions require no IT
- Is an excellent way to gather requirements
- Makes the case to senior management to make the change
- Reinforces that the problem is the process, not the people.
We propose another methodology to do process analysis, gather requirements, and create a new process. We think this methodology addresses the faulty assumptions mentioned earlier and at the same time overcomes the shortfalls in the IIBABOK approach. As you examine the approach, you will find that the IT representative is part of a team. And it is the team that identifies problems, finds solutions, and invents the new process. IT is there to enable the improved process.
This methodology has four phases and ten steps.
Phase 1: Getting Started
1. Introduction to Business Process Improvement:
This step is comprised of two parts. The first is a meeting with senior management. In this meeting there is a discussion regarding barriers to process improvement, impact of job change, clarifying roles and responsibilities, identifying the project manager, and creating the communication plan to staff. The second part is an all-hands meeting to launch the effort and answer questions from staff.
2. Process Improvement Team Formation:
The team is largely comprised of the people who work in the process. We look for those who want to make a change and are considered the best and the brightest. One team member comes from outside the targeted process. This person is “hard-wired” to ask “why.” We call this person the Maverick. It is this person’s job to challenge the team to think outside-the-box. The team has a representative from IT. This person will learn in detail the “as is” process and the problems with the “as is.” She will be very helpful when the team creates the “to be” process. The team also has a facilitator and a project manager. The first work of the team is to create ground rules on how they want to function. Next the team crafts a communication plan to all affected stakeholders.
Phase 2: Flow Charting, Interviewing and Benchmarking
3. “As Is” Flow Chart:
Flow charting is a technique that allows us to map the current process in detail. To create an accurate “as is” map, the team remembers a time in the past when the process occurred. This is a true “as is” because this really happened. While this is only one variation of the process, other key variations are mapped on separate documents. By remembering a time in the past, it allows the “as is” map to be created very quickly. The process is documented in terms of time, poor quality, and where frustration occurs. The bottlenecks, delays, areas of poor quality, and high frustration areas are ranked and prioritized. Through process mapping, the team will identify which process design principles should be used in the redesign.
4. Customer Interviews:
The customers of the process are interviewed to discover what they think of the current process, what they like about it, and what they do not like about it. The process is evaluated by the customer in terms ranging from “excellent” to “unacceptable.” In addition to interviewing customers, the staff members that work in the process but are not part of the Process Improvement Team are also interviewed to get their ideas, comments, and suggestions. All of this information is shared with the team, Project Manager, and Senior Management.
5. Benchmarking and Best Practices:
Often, other organizations have discovered innovative ways to design processes. Instead of “reinventing the wheel,” we find out who does this process the best. Members of the team will develop questions and then interview innovative organizations. This information is shared with the team in order to incorporate the best ideas into the redesign.
Phase 3: Process Redesign
6. First Cut Redesign:
Since the IT representative now knows the process very well, we ask this person how IT can enable the changes the team is thinking about. We then ask each team member to create a new process that incorporates design principles, customer feedback, fixing frustrations, fixing quality problems, eliminating non-value added steps, and information technology. This task is done with a “clean sheet of paper.” We ask: “If we were to invent this process today with what we know, what would it look like?” Here we are looking for “out-of-the-box” thinking and innovative ideas. Process design principles significantly enhance creating the new process. Process design principles are distilled best practices from world class organizations. The team also creates a list of things necessary to bring about the redesign. These items become action items when we move into implementation.
7. Share Redesign with Senior Executives, Employees and Customers:
If the redesign has any controversial elements or requires major capital outlays, then the Senior Executives need to review and approve the plan. Turf issues and other types of resistance may surface at this time. In addition, the redesign is shared with the rest of the people that work within the process in order to get their ideas, comments, and suggestions. If some customers are available and involved, the redesign is shared with them as well. This type of feedback is extremely helpful and is used in the final redesign.
8. Final Redesign:
Any changes that were required from the Senior Executives, the staff, and customers have now been incorporated. Key items get prioritized, and the project is now ready for implementation.
9. Implement Changes:
This stage of process improvement is often the hardest to gauge in terms of time, resources, and obstacles. The project manager makes sure that everything gets done on time and that people meet their commitments. Action plans are developed and assigned. The IT representative will begin implementing the key requirements which might require software changes, writing code, and equipment upgrades.
The facilitator can work with the organization to address obstacles that arise. He can smooth the transition into the new process and help people adjust to new ways of working together. Sometimes simulations or pilot programs are initiated in order to test the new design before a complete changeover is made. This reduces risk and allows for a smoother transition.
Phase 4: Celebrate Results and Continuous Improvement
10. Monitor Results and Continuous Improvement:
At this point the Process Improvement Team has made significant, measurable progress in improving the process. Feedback mechanisms, measurements, and continuous improvement become embedded in the process. The team is rewarded and recognized for its accomplishments. Expect the team to continue to meet on some regular basis. Improvement in cycle time and quality will be an ongoing part of your organization’s culture.
We have been using the above methodology for 19 years with great success. The keys are:Strong project managerSenior management commitmentAt least one bright team memberThe IT person knows the technology cold
Let’s close the IT and Business divide. I think the above is a big step in that direction.
