At the end of my April 2013 Column on “Scoping Models” (http://bit.ly/11qjuhJ) I said I'd follow up with a look at how they can be extended and used as analysis models. Predictably, I got distracted along the way. Now, a year later, I'm back on the topic. Perhaps not an impressive response time, but better than the two years it took me to get around to writing the last Column on “Conducting an Executive Briefing on Business Processes” (http://bit.ly/1p4dhmC). By the way, a big “thanks!” to all of you who got in touch to say they found that Column especially useful – much appreciated!
Recap and overview
The Column on Scoping Models stressed that I emphasize describing the “what” of a business process before getting into the “who and how.” The essential framework for describing the “what” (the “essence”) of a process comprises four parts. I've numbered the components 1 through 4, but the order in which you discover them may be different, and is always iterative. They are:
- Trigger(s) (or triggering event(s))
- Results (the “output” expected by each stakeholder)
- Activities (5 +/- 2 “milestones” or “subprocesses”)
- Cases (or variations)
That yields the acronym “TRAC,” so I think I'll add “Get on TRAC by scoping before analyzing” to my list of process aphorisms. (A perennial favorite in workshops is “Flow first, detail later.”) As I noted in the Column, the framework is very simple, and that's one reason it works so well – it's intuitive and approachable for our clients. Just because it's simple doesn't mean it's simplistic.
After “TRAC” has been clarified, we venture into “who” by adding the major organization units (internal and external) that participate in the process. This gives us a Process-Function Chart, a personal favorite of mine. BPM professionals wildly underutilize this simple diagram, a shame because nothing else is nearly as effective at illustrating the distinction between “business function” and “business process,” and the relationship between the two. If there was a metric like “Most 'aha' moments per unit of effort,” this diagram would be the winner. It augments our understanding of scope by adding the organizational dimension, and also (as we'll see in the rest of this Column) provides a framework for analysis. Some of my clients have been calling these “Process Summary Charts,” which seems like a sensible term, so that's what I'll use for the rest of this Column. Figure 1 is the example seen in my earlier Column.
From scoping to analysis
After scoping the process, my usual method would be to perform an initial, stakeholder-based assessment of the as-is process, establish goals for the to-be process, and then move on to mapping the process flow with our beloved swimlane diagram. Increasingly, especially over the past year or two, time pressures are such that there just isn't the time (or the will or the attention span) for as-is flow mapping. To be clear, nothing matches a swimlane diagram for helping people understanding the reality (often, the ugly reality!) of the as-is process, but we're all feeling the time crunch of modern business. Besides, there might not even be a defined flow to map (think emergent or adaptive processes.) In these cases, I'll rely on augmenting the Process Summary Chart to support more detailed fact-finding and analysis, the subject of this Column.
Using Process Summary Charts for analysis
In general, I'll treat “analysis” as meaning “learning more about some subject matter by collecting additional detail.” A common and more polished definition of “analysis” is “breaking something down into its constituent elements.” Google offers the definition “a detailed examination of the elements or structure of something, typically as a basis for discussion or interpretation.” Each of these applies to the three approaches we'll look at:
- Using a Process Summary Chart alone. This demonstrates “learning more” – adding functions or organization units to a Process Scoping Model can be very illuminating;
- Collecting more detailed activities by subprocess or by function. This demonstrates “breaking something down;”
- Assessing a process by subprocess, by function, or by stakeholder. This demonstrates “detailed examination;”
It's worth making note of why starting with a scoping model is so effective so you don't inadvertently derail it. Simply put, if you have people do some sort of examination or fact-finding or assessment within a framework of, say, 5 +/- 2 categories, they'll do a more thorough job. For instance:
- Rather than asking “what happens within this process?” ask “who does what within each subprocess?,” which will yield a more complete analysis;
- Rather than asking “what are the strengths or weaknesses of this process?,” ask “what are the strengths and weaknesses of this process with respect to each of these six enablers?” or “what are the strengths and weaknesses of this process from the perspective of each of these stakeholders?”
The key point is “5 +/-2” elements to the framework. Don't try to gather information for 20 subprocesses or 15 assessment criteria, or the techniques won't work any more. As noted in the earlier Column, you'll find out why in George Miller's classic 1956 article “The magical number seven, plus or minus two: some limits on our capacity for processing information.” I use “the magical number five” because I don't want to push the limits, mine or anyone else's.
Let's look at each of the three approaches I outlined above. I'll provide a very brief overview of the method, and recent, real-life examples to illustrate it. Note that all of the examples come from higher education. That's partly because I do a lot of work in that field, but also because institutions are quite willing to let me use their examples.
1 – Using a Process Summary Chart alone
The main idea
It isn't just us – BPM professionals – that learn from these models. The business professionals we work with also learn a great deal. We might wish it was otherwise, but most people don't think in terms of business processes, and they certainly don't “see” end-to-end processes without some help. That's where a simple, readily grasped depiction of a process, such as a Process Summary Chart, can really help. A recent example at a major US university nicely illustrated this.
An example – “Strategic Enrollment”
A strategic initiative (“Strategic Enrollment”) was, well, initiated to raise graduation rates over the long term by attracting students with the highest potential. The problem was, the current processes were so dysfunctional, the best candidates typically had accepted an offer from another school and been admitted before this university had worked through its deliberations and made an offer.
Student Affairs was determined to change this situation by looking at it through the lens of “business process.” This ultimately would mean looking at all the enablers of a process –human resources and organization, motivation and measurement, policies, etc. – not just the technical factors. First, though, it would have to be determined what process or processes needed study.
The internal team of process experts responsible for the initiative achieved a breakthrough of sorts when they determined that the candidate student should ultimately see this as a single process. Currently, it was anything but!
As illustrated in Figure 2, the student's experience was traditionally seen in terms of dealing with many different processes – Recruiting, Admissions, Orientation, and so on. Certainly the students felt they were dealing with disconnected pieces, and a BPM professional recognizes those as likely being organizational constructs, not processes.
We convened a facilitated session with the goal of producing a Scoping Model that would demonstrate that recruiting, admitting, and onboarding a student was a single, end-to-end process. We weren't sure it would be possible, but trying it was the only way to find out for sure if it was reasonable to treat this as a single process!
With 8 or 10 participants, each having significant background in the area, we achieved this in a single 90-minute session. Not only did we produce a plausible Scoping Model, we augmented it by identifying the primary activities in each of the eight subprocesses. (More on this when we get to section 2, “Collecting more detailed activities.”) To be fair, some advance work had been done, and this was an experienced, motivated group with a firm facilitator (me!) so I'm not saying this could always be accomplished in an hour and a half, but that's what a lot of my recent experience has been. In fact, that's my current target for all “process” sessions – a valuable result within 90 minutes. In the Age of Agile, that's a necessity!
The Scoping Model we produced in the first 30 minutes or so is illustrated in Figure 3. That chart alone has been invaluable in helping the university see this as a single process – it makes it clearly visible what a student has to go through to achieve the result they and the university want. Of course, as a Scoping Model always does, it provided the framework for more detailed analysis, which we'll get to shortly.
Another example – “Remove Legal Entity”
In my “Working With Business Processes” workshop we cover Scoping Models, and develop one as part of a case study. A couple of years ago, at an oil and gas company, one of the participants essentially blurted out “Eureka!” at this point in the class. I don't usually get quite such an enthusiastic response to Scoping Models, so I had to ask her why.
As she explained, she was responsible for establishing a “Remove Legal Entity” process. When a company (supplier, customer, partner, …) was dissolved, amalgamated, or otherwise ceased to exist, it had to be removed from SAP and associated recordkeeping systems. The problem was, she just couldn't convince certain key people this was not as simple as it evidently sounded. In the workshop, she realized that if she built a Process Summary Chart for “Remove Legal Entity” it would succinctly demonstrate (always better than convince) the scope of the undertaking and the number of moving parts.
By the time class started the next morning, she'd already built a wonderful Process Summary Chart, and met with her manager, who now realized the process was much more involved than they had assumed. Mission accomplished! The chart illustrated:
- Four different sources of the triggering event;
- Five distinct stakeholder results;
- Six subprocesses
- Five cases
- Seven major functional areas
If that wasn't enough, she augmented it with three to five major contributions by each of the seven functions, as we typically would in “Collect more detailed activities,” and 22 supporting mechanisms (systems, forms, documents, checklists, etc.) required by the process. She did this wall-sized, on a sheet of flipchart paper, using markers and Post-its. To fit within the constraints of this Column, I've produced the simplified version in Figure 5. I often add more information, such as as-is assessment and to-be goals, characteristics of the as-is implementation, and some metrics, and it still fits on the “one-pager” beloved by executive management everywhere!
2 – Collecting more detailed activities
The main idea
Yes, friends, as you probably deduced from the previous example, this is often just adding another level of decomposition. We may have started by decomposing a Process Domain into Business Processes, and with our Scoping Model we've definitely decomposed the Business Process into Subprocesses (or “milestones” or “major activities” or “phases” or whatever you prefer to call them.) Now, if we identify the main Activities within each Subprocess, we have extended our decomposition another level. The “Remove Legal Entity” example we just looked at took a different approach – rather than decomposing each Subprocess into Activities, the heroine of the story listed the Activities carried out by each Function. Admittedly, a subtle distinction. Typically, I essentially do both – I decompose each Subprocess into Activities, and also identify the Function (and specific Actor) responsible for each Activity. That's what we did in the rest of our “Strategic Enrollment” session.
Returning to “Strategic Enrollment” example
Over the course of the remaining hour in the session, we listed the significant Activities that made up each Subprocess, as illustrated in Figure 6.
It isn't shown in that chart, but we also identified which organization was responsible for each Activity. With that information, we were able to add the involved functions to the chart, as illustrated in Figure 7.
This is where the magic happens! Once people see the reality of how many organizations could be involved for a single student admission, three things are very clear:
- For the process performers – the people who do the work – it is almost certainly a very frustrating process, filled with redundant work, inconsistent information, missed handoffs, conflicting policies, and so on.
- For the process customer – the student – there is almost zero chance this process offers a satisfying experience. It's more likely to be a gauntlet they have to run, which a 30 second conversation with a typical student would confirm.
- For the process owner – the university – there is no chance their goals will be met unless these activities and organizations are integrated into a single, well-designed, business process.
That's a lot of learning from a simple chart!
One more key point. Increasingly, given the time crunch we all face, I find myself gathering this kind of information during a session, and producing a first-cut swimlane diagram “offline.” Then, in a subsequent session, we “walk the flow” with the process participants and clean it up. This has proven to be extremely effective in terms of getting a lot done in a short period of time.
3 – Assessing a process by subprocess, function, or stakeholder
The main idea
Our final approach involves taking a detailed look at a process using the Process Summary Chart as a means of framing the examination. Specifically, we'll identify issues in the as-is process, one subprocess at a time, and then use this information to formulate goals for the to-be process. As noted in the introduction, focusing on one subprocess (or stakeholder or enabler) at a time leads to a more thorough examination. It's also worth noting that the three approaches we're looking at are almost always used in concert, and not necessarily in the sequence we've used.
An example – “Continuing Education Student Journey”
There were many complaints about the registration and record-keeping processes in the Continuing Education area at a school in the California State University system. A process-oriented approach was used to:
- Build a Scoping Model that broke the process into manageable “chunks” (subprocesses);
- Identify as-is process issues, one subprocess at a time
- Identify to-be process goals, one subprocess at a time
Two things are notable about this example. First, this was completed in a single 90-minute session. (There's that “90 minute” time box again.) Second, two analysts at the university ran the session the day after completing my two-day “Working With Business Processes” workshop. They really liked the idea of starting a business process study with a “first, draw five boxes” approach, and wanted to put it into action right away. They did, brilliantly.
In Figure 8, I've isolated the part of the table they produced that shows the five boxes (Subprocesses) and some of the key activities within each.
Some of the phrasing, like “Make Registrant a Person,” might seem a little strange, but that's what university administrative staff came up with. The session was going really well, so there was no urge to get fussy about naming. We were also perfectly aware that this wasn't a single business process – it was more of a life cycle, with emphasis on the stages that caused grief. Again, there was no urge to argue the finer points of business process definition. The session was going well, with cross-functional participation, and they were looking at things end-to-end, which qualifies as a win.
Focusing on one Subprocess at a time made it easy to identify as-is issues, and to-be goals, as illustrated in Figure 9.
Finally, the issues and goals were rearranged by stakeholder, and potential metrics added, as shown in Figure 10.
These “one-pagers” gave participants a real sense of accomplishment. Everyone had experienced meetings in which conversation went around in circles without any tangible result. This session produced concrete results within 90 minutes.
More than anything else, I want that last example, and the earlier ones in the Column, to demonstrate that simple (not simplistic!) techniques, rigorously (not rigidly) applied, will help you accomplish a lot in a (relatively) short time.
I hope you'll be able to take what we covered here and adapt it to your situation. Please feel free to contact me with any questions or comments.
The Continuing Education example illustrated a simple assessment of a business process, a topic I'd like to expand on next time around. We'll look at two frameworks that help achieve a holistic assessment. We'll also see how one supports the assessment and goal-setting I do before detailed analysis, and the other supports the assessment and idea-generation I do after detailed analysis. We'll also consider a favorite topic of mine, “the problem with problem statements.” Specifically, why do I avoid doing problem statements until after I have a Process Summary Chart. Let's see if I can annoy some fans of problem statements!
The first quarter of 2014 has been a blur – I've racked up almost 40,000 flying miles already, and will hit 2,000,000 miles on United within a month or two. Some of the public workshops and speaking gigs on the agenda are:
- April 28 I'll be in Austin Texas at Enterprise Data World (always a high point of my year) presenting “The Human Side of Data Modeling.” http://bit.ly/1jGOXTk
- May 21 I'll present “From Process Model to IT Requirements – Crossing the Chasm” for the Portland OR IIBA chapter. http://bit.ly/1h8lYtV
- May 23-24 Our two-day Data Modeling workshop is sponsored by IIBA Vancouver, so the registration fee is much lower than usual. http://bit.ly/1dwfO7y
- June 16-18 I'll be back for IRMUK's Business Process Management and Enterprise Architecture co-located conferences. Combining these two events has worked out brilliantly. I'll do a one-hour session on “How Do You Actually Design a New Process?” and a half-day seminar on “Running a Successful Process Discovery, Scoping, and Mapping Session.” http://bit.ly/1dYKHN9
- Sept 22-24 I'll be in London at IRMUK's Business Analysis Conference Europe presenting a half-day workshop on “Concept Modelling for Business Analysts.” http://bit.ly/1h8mzvr
- October 23-24 will be one of my twice-yearly London presentations with IRMUK of our two-day “Working With Business Processes” workshop. The best part – the interplay between participants from multiple countries in Europe, Africa, the Middle East, and Asia. http://bit.ly/bno3ll
- Nov 02-06 I'll be at the Building Business Capability conference in Ft. Lauderdale FL doing the same two presentations as at the June event in London. http://bit.ly/13BSex2
- Nov 10-13 I'll be presenting half-day seminars on “Process Modeling and Analysis for Higher Education” at Kuali Days 2014 in Indianapolis IN. http://bit.ly/1kF41o1
- Sometime in the fall I'll be back in Helsinki to present our “Advanced Data Modelling” workshop for Ari Hovi Oy.
I hope our paths cross somewhere!
From the Trenches,