Business Analyst Community & Resources | Modern Analyst

Process Mapping 101: A Guide to Getting Started

Featured

203070 Views

37 Comments

91 Likes

Part 1: The Big Picture

Before starting, it is important to understand process mapping’s place in the larger context of business process improvement. Improving your process typically starts with documenting how it works today, what we call the “as-is” process. The mapping of the as-is process can be divided into two phases.

The Discovery Map: The first phase, which we call the high-level map or discovery map, has the purpose of defining the scope, identifying team members, and articulating the sponsor’s vision and improvement targets. It is created by a small team typically made up of a facilitator, project lead, and the senior management sponsor.
The Process Diagram: In the second phase, a more detailed Process Diagram in the form of a “swim lane” diagram (where information is organized by lanes) is created. Its purpose is to document the current state of the process in more detail; the team creating that diagram is larger. For the Process Diagram, we usually start by describing a single instance in the recent past, but we can extend that later to show the significant exceptions that may occur.

The Discovery Map: It is the Discovery Map that we will focus on in this guide: who needs to be involved, what information goes into it, how to conduct the mapping session, and how to communicate your progress to stakeholders.

In the larger picture that’s not the end of the story. After that you can analyze your as-is map for problem areas, propose process improvements, and capture those improvements in another swim lane diagram. The procedures for modeling the proposed to-be process are similar to the as-is. And you can go on from there to quantifying the expected performance improvement using simulation, and even creating an automated implementation of your process.

Part 2: Getting Started with the high-level Discovery Map

Setting the Stage
As you would expect, in order to get started with Business Process Management (BPM), you need to have identified a specific process to work on. Usually this is done by senior management, based on specific criteria, but it can be done by a work team who recognizes a need for process improvement. These criteria might be customer satisfaction, competitive challenge, or concern about defects or cycle time. Once a process has been decided it is helpful to articulate the business case – in other words what is the business reason we are working on this now.

When you have chosen the process to work on, the first step is to build a high-level map. This map is usually six to ten boxes which represent the high-level phases or milestones in the current process. You can build this high-level map with a small team.

When you begin working with the small team the facilitator or external consultant needs to articulate the process improvement road map. The road map includes:

Getting Started: Selecting the process, doing the high-level map, identifying a sponsor, and eventually all the team members.
Following the Process Improvement Methodology: You follow the methodology to build a Process Diagram for the current state view, analyzing the current state using various techniques, and redesigning the process based on design principles.
Implementation: Although the methodology encourages you to start implementing quick wins very soon, you will have a larger implementation to plan at the conclusion of the redesign phase.

Team Members for Building the High-level Map
At this early stage of building the high-level Discovery Map, it is often best to keep the working group small and have just a project lead who really knows the whole process or a majority of the process and facilitator. Here is more detail to help you select the appropriate people for your team:

The Project Lead: The Lead is a person who knows the most about all the steps in the process and is usually a supervisor or manager. This person is the key point person for the team with the sponsor and will be the point person for any of the team members who want to raise issues outside of the team meeting situations. This person also helps coordinate the meetings.
The Internal Facilitator: The Facilitator manages the meetings, and needs both group process skills as well as knowledge of process improvement methodology. She encourages participation, and builds the diagrams with the team. Later this person will help with analysis and redesign of the process. If you do not have an employee who has the skills and knowledge to perform this role in your organization, you can also choose to hire an external consultant.

The High-level Map
A high-level map is six to ten phases long. It usually contains just these phases and has no decision diamonds. It is a map of the current state of the process, not the should-be state or what you might like it to be. There is no magic to the number six to ten milestones or phases. So it could be as few as four phases and as many as twelve. More than twelve phases and you are probably getting too detailed and could combine some.

Figure 1: A high-level Discovery Map being constructed in Lombardi Blueprint.

There are two main goals for the high-level map:

Communication Tool: This map is an easy communication tool which gets everyone aligned. You want the high-level map detailed enough so people know the phases in the process and what’s not in the process.
Surfacing Issues: The high-level map often surfaces key problems, which means that we are articulating early on what some of the important issues are and documenting them for analysis later.

Once you have developed the map you will know most of the people who should be on your core team – namely employees or managers who know and do the work in these phases. There are a few other people we suggest having on the process improvement team as well and we will discuss them in part three. Additionally, once you have the high-level map, you will take it to the sponsor and ask him or her to review it, and give you important input. This will also be discussed in part three.

Tips for the Facilitator

Identify start and end points first. This helps set limits right from the start. They may change as you communicate this map with more people but they are the starting point. It’s better if the scope is within the sponsor’s range of authority and responsibility.
Name the process. The process name should tell everyone what you are talking about. When you name the process don’t include acronyms or jargon. Keep the words straightforward business words.
Add activities that are mentioned under their milestone. Even if you do not ask groups to list any activities when they build the high-level map, some will always come up. So add them, but don’t try to gather more. You will have fewer activities the higher in the organization your content provider is. People doing the work will want to give you more activities. The time for the detail is the Process Diagram.
Add roles to activities when they are mentioned. But don’t feel you need to get them all. You will be able to add them later.
Document problems as they come up. Now however, is not the time to discuss them or solve them. Just document them.
Move activities and milestones where they need to go.

FAQs for the Facilitator – How do we include this?
Here are four typical questions that may come up from the project lead, sponsor, or others when you are developing or discussing the high-level map.

When some says, “Here’s what happened in another example” they want to know how the map will capture all the different variations. The high-level map is not meant to capture all the variations, but rather to show the flow and phases from a high-level. You will capture more of the variations in the more detailed view called the Process Diagram.
“We don’t do it the same way in Ohio as Texas” is another version of the question above, and we will not show all the variations. But this is also a statement that there is little standardization of the process. It would be good to list this as a problem.
“Often when we do this process we don’t have the right information before the process begins,” is a statement of a problem and could be listed in the problems area at the process level. You can also capture what inputs are needed and list the inputs.
“How will we measure this process?” It is best to ask for measures at two points. 1) output measures – one to two measures that show how the output meets customer specifications and 2) an in-process measure which will be a signal early how the process is going. Are we on target for our outputs or is there a concern? You can identify measures with the team and note them.

Part 3: Adding detail to the Discovery (High-level) Map

In this part you will learn additional elements to be added to the high-level map.

Adding Detail: People

Participants: The participants are the most important to capture, because they designate who is responsible for getting this phase or activity done. In the Participant box, identify the main role responsible for the job. Don’t list multiple names. It gets overly confusing. Remember to list roles, not departments and not people’s names. If systems are important they are listed in the participant category.
Business Owners: You will find that many companies don’t have business owners defined yet. Officially a business owner would be the owner of the whole process or possibly a milestone in the process. Later they might be the owner of a sub-process. A business owner is the person who is responsible for overseeing the whole process, making sure it is followed, monitoring the process, and building in continuous improvements. In very mature process companies this person may have budget responsibility for the process and actually manage the people. In most companies the business owner acts through his influence.
Experts: You may want to list experts so that others in the process know whom to go to for advice or input. They may be people you want to have as guests to help you improve the process. Here you would list a real name and their position. You may want to identify what type of help they could provide.

Figure 2: Adding details to the Discovery Map using the Details pop-up window in Lombardi Blueprint.

Adding Detail: Inputs and Outputs
It is usually easiest to capture inputs and outputs at the milestone level. At this stage in the process it is too tedious to capture inputs and outputs for each activity.

Inputs: Just ask the team what the inputs are. Inputs imply a document or organized form of information. The team may not get them all on first pass, put they will know the main ones. Inputs at the second milestone should be outputs from earlier milestones.
Outputs: Outputs will be documents or information significantly enhanced or completed during this milestone.

To get inputs and outputs you have to ask for them. Clients don’t volunteer them very often at the high-level.

Adding Detail: Problems
Problems can come up at any time. And you need to capture them as they come up. You can capture them at the process level, milestone level or activity level. When you are building a high-level map just add them where the respondent says they go. It will probably be at a milestone or activity.

Severity and Frequency: Ask the group, how severe this problem is (low, medium, or high) and how frequently it happens (low, medium or high). You do not have to have specific standard definitions for these terms – low, medium, and high – but if the client wants to build them it would be beneficial to agree to specific criteria, such as severity as a dollar or time cost of so much for each level, and frequency is a certain percentage of occurrences by project for each level.

Adding Detail: Documentation
Documentation can be used in a variety of ways. You can use it to write a more detailed description of the activity. You could actually write full procedures here, but in the process session you would just add an example or expand on what you put in the activity box if that is what the speaker is suggesting. You can also use it for Improvement ideas.

Adding Detail: Documentation – Sponsor’s Vision and Improvement
Another important element to record in Documentation is the sponsor’s vision and improvement targets. When you have finished the high-level map, set a meeting with the sponsor.

Ask the sponsor about

His or her vision: Ask what is important about this process to him or her, what they would like to see if it were really working. Often they will say things about values, important elements for the customer, needs for the marketplace, and any special hot buttons.
Specific improvement targets: These are changes the sponsor would like to see after you redesign the process and implement –- say in two to three months after you have started implementing. When they give you a statement, help them revise it to make it quantifiable.

Sponsor Meeting
We have discussed several details that you can add to the high-level map. It is now time for a meeting with the sponsor. This is a meeting between the sponsor, project lead, and facilitator. One hour is usually sufficient. Now let’s look at that meeting piece by piece:

Review the milestones of the high-level map.
Get their agreement to the beginning and end of the process as defined – or revise it with them.
Get the sponsor to articulate their vision for the process and provide one to two quantifiable improvement targets. We mentioned this earlier in part three.
Explain the road map so they know what the process improvement project will entail and the extent of the team member’s time needed. The road map will also remind the sponsor of when they will be needed in the process improvement effort and the specific process advocacy role they have in the organization.
Now you should go over the roles of each of the core team members for the sponsor. Explain that the core team members include the project lead, several employees who work the activities in the process, and a “maverick.” Since we have already discussed the sponsor role, project lead role, and internal facilitator or external consultant role in part two we will not repeat them here, but you should start with reviewing those three roles with the sponsor. Then go onto the additional core team members.
- The Best and the Brightest: Employees who do the work of each phase in the high-level map are critical to the core team for the Process Diagram. They should be your best and brightest employees not just the ones who are available. Often a team will be six to ten people. If the process happens in different locations, you should include people from those different locations.
- The Maverick: There is one more person who is a great addition to the team, the “maverick.” This person does not need to know the process, and in fact it is often better if he doesn’t. His role is to ask the question, “Why do we do it that way” or “Couldn’t we try it this way?” In other words encouraging the team to think out of the box.
- IT, Customer and Supplier Representatives: There are other people who would be strong additions to your team. Most business processes involve IT and an IT member will bring their expertise. An IT member can often tell you what is possible today and how technology might help in the future. Having a customer on the team will always provide the perspective of the customer, and is usually a very inspiring addition to the team. If you have a key supplier, you can really build a stronger relationship and solidify requirements by having him on the team. Sometimes the customer and supplier players just come for one or two meetings.
Now come back to the high-level map and get the sponsor to help designate who should be on the team for the next part of the methodology, developing a more detailed Process Diagram in a swim lane format. The project lead and facilitator can bring a draft of names and roles that you recommend or just build the list with the sponsor.
For the other stakeholders, the presentation is largely the same, but with a different emphasis. With them, you want a reality check. Does this make sense? Have we missed anything? Can we actually achieve the sponsor’s vision?

Part 4: Summary and Next Steps

Summary
What’s needed for a successful start to the improvement project? We have developed most of these already:

High-level Discovery Map: We already have this. We have completed it with the project lead and facilitator, added more details to it in this section, and then reviewed it with the sponsor.
Have the right resources identified, based on the process you want to improve:
- The project lead and facilitator who build the initial high-level map and then discuss it with the sponsor.
- The core team members who actually do the work of the process and will help you build the Process Diagram, then analyze and redesign the process.
- Other team members such as an IT person, customer and supplier.
- The sponsor vision and improvement targets.
Road map: The facilitator prepares a road map of the process improvement methodology for the sponsor, project lead and team members. The road map should include different phases – getting started (the high-level map, selecting team members, sponsor vision and targets, and roles and responsibilities), process mapping and analysis, and redesign meetings and implementation. Share this overall road map as well as the high-level map every time a new person joins the project.
Scheduled meetings: This is an aspect of project planning. In order to make the process happen in three months or less you need to schedule the meetings at the beginning. In this training we will cover the first meetings but not the phases of analysis, redesign, and implementation planning. Time should be put aside for all these meetings. You should have meetings about every week or every other week for two to four hours each time. If you meet every month you will never get it finished. You can also do it faster – say six days in a row. It’s up to you.
Presenting the High-level Map: After you’ve completed the high-level map, your presentation to senior management should emphasize the sponsor’s vision and improvement targets, key problems identified, and a list of the participants needed for the Process Diagram.

Where to next?
After you have created and gotten buy-in on your high-level map the next step of the as-is process is creating the process flow or “swim lane” diagram.

Figure 3: A Process Diagram automatically generated by Lombardi Blueprint from the high-level map.

The purpose of the Process Diagram is to document the current state of the process in more detail; the team creating that diagram is larger. For the Process Diagram, we usually start by describing a single instance in the recent past, but we can extend that later to show the significant exceptions that may occur.

Beyond As-is
Once your as-is map is complete, you can analyze it for problem areas, propose process improvements, and capture those improvements in another swim lane diagram. The procedures for modeling the proposed to-be process are similar to the as-is. And you can go on from there to quantifying the expected performance improvement using simulation, and even creating an automated implementation of your process.

The goal of BPM is to improve your processes, make them more effective, more efficient, more agile, with greater satisfaction for both employees and customers. By creating a solid high-level map you have created a sturdy foundation on which to continue building your BPM efforts.

Source: This article is based on the online training course “Process Mapping 101” created for Lombardi Software by Bruce Silver, founder of BPMessentials.com, and Shelley Sweet of I4Process Consulting and was edited by Barton George, of Lombardi Software. If you are interested in learning more about this course please visit http://www.lombardi.com/bptraining.

Although this article is meant to stand by itself, it is even more powerful when combined with the Lombardi Blueprint process mapping tool. For a 30-day free Blueprint trial, please visit https://blueprint.lombardi.com/signup/trial.

Posted in: Business Process Management (BPM), Process Improvement (CMMI, Six Sigma, SPICE, etc.)

91 members liked this article

Featured

203070 Views

37 Comments

91 Likes

Data-Driven Decision Making: Leveraging Analytics in Process Management

The Top 10 Reasons Business Analysts Should Leverage Process Mining

AI & Citizen Development: Fueling Business Transformation beyond Cost Cutting

Your Next Process Model’s Degree of Abstraction

COMMENTS

JohnIMM posted on Monday, April 6, 2009 5:24 PM

One of the major errors taken in business analysis and modeling is that of modeling the "As Is", then the "To Be" and then trying to plot a trail from the one to the other. This approach is hugely wasteful of time, money and peoples' goodwill. Most modeling projects run in this way take so long to deliver results that they fail.

If the business is not currently doing what it ought to be doing in the way that it ought to be doing it, then modeling it is about as useful as modeling what it was doing last week, last month or last year.

And what have you got at the end? A detailed model of what the business OUGHT NOT doing!

All good business analysis starts by modeling WHAT the business OUGHT to be doing. This is the only model that is of any value.

Sadly, many analysts actually believe that this cannot be done. When they make this statement they are actually saying "Nobody in this business knows what they ought to be doing"! If this is the case the business may as well shut up shop.

Good analysts find the key senior executives in the business - going to director level if necessary - who know what ought to be done, interview them and the then build a series or really powerful models that can take the business to where it ought to be - at an accelerated pace.

The next major error the analysts make is by starting out modeling business processes as opposed to business functions. But that is a whole other story.

Business analysis and modeling is a very powerful tool that can bring real business benefits when it is done corectly. Sadly, too many analysts and consultants squander this opportunity by starting in the wrong place and modeling the wrong thing.

John Owens
[email protected]
http://www.integrated-modeling-method.com

Jonathan posted on Tuesday, April 7, 2009 7:48 PM

Interesting post, Adrian. What you show above seems to equate roughly to what I do with use cases and UML activity diagrams.

John, You make some good points. I found your comment on the usefulness (or lack thereof) of current state modeling particularly interesting. I'm might have to chew on that one for a bit, though.

I certainly see where it would be preferable to save time and effort and only do desired/optimized or "ought to be doing" state. At the same time, I think having the current model for context in defining/explaining the business problem can be useful.

Maybe it's not that the business is doing what they ought not to as much as there may not be a clear understanding across stakeholders from different business units/departments/etc (you know, "silos") of exactly how they're going about it.

I've found that doing the side by side comparison of current vs. desired state can be helpful in illustrating the benefits of the desired state to business stakeholders as contrasted with the waste and other faults in the current state.

In my mind, though, the current state model is just another tool available for helping define the problem. When it doesn't add any value, I'm all for dropping it.

I would be interested in hearing your thoughts on modeling business functions vs. processes, too. I'll check out your site and see what you have there.

Jonathan Babcock
http://practicalanalyst.com

JohnIMM posted on Wednesday, April 8, 2009 12:23 AM

The current problem is always that the business/system is doing something other than what it ought to be doing. Understanding this problem is essential, but this can be achieved without modeling all that the business is doing wrong in detail.

The most powerful question to ask is, “What ought you (or the system) be doing?”

It is true that there is misunderstanding across the ‘silos’. Clarity can be brought about by modelling what ought to be done and asking “is this what you are doing?”. If the answer is “yes” then no problem, if “no”, then they know what they ought be doing.

Modeling the “ought” state on its own actually makes it very clear to stakeholders what the benefits of the project / system will be.

I have not come across a case where modelling the existing state has added any real value. It makes analysts feel comfortable because they believe that this is where they should start.

In the Integrated Modeling Method I have shifted this paradigm completely and defined the starting point always to be “what” the business “ought” to be doing.

This forces me to find people in the business who can answer this question and stops me wasting time modeling something else. This has resulted in greatly increased productivity and accelerated solutions.

Process modeling is a secondary modeling technique. The two primary business modeling techniques are Function Modeling and Data Structure Modeling.

The core activities of any business are Business Functions. These are the discrete, coherent activities that a business must perform in order to meet its objectives and remain in business.

When you need to know the order in which Functions need to be carried out then you use Process Modeling. Every step in a Process is a Function. So, know the Functions first.

The other great error perpetrated in Process Modeling is decomposing Processes. This results in generating up to 300% more models that are necessary and introduces inherent logic errors.

I have expanded on all of this in a series of eBooks I have written, which are available at:

http://www.integrated-modeling-method.com

John Owens
[email protected]

Adrian M. posted on Wednesday, April 8, 2009 1:54 AM

John... You're correct that in many cases the Business Analysts by default fall into the "AS-IS" vs. "TO-BE" paradigm.

Having said that, there is much value in documenting existing processes. For starters, smart organizations should document their processes (and functions) because they should have a clear picture of how the organization conducts business. Too many businesses work on process mapping only when they need new software or when they implement new business initiatives.

So - in an ideal world - when the organization has designated process owners and maintains process maps, there would not be the need to create "AS-IS" flows at the start of a project since they would already exist.

If they don't exist, "AS-IS" process allow the project team to answer many questions such as:
- what do we do today (aka don't re-invent the wheel if you don't need to),
- what problems we have (aka show me the problem before I approve $$$ for a new project),
- what "changes" do I need to make to the existing organization's processes and function,
- etc.

I'm involved in Search-and-Rescue (just got back from a search operation)... in that environment we often decide or are told where we need to be (aka "TO-BE").

Guess what's the first thing we do once we understand where we need to go?

Determine where we are (aka "AS-IS").

We need to know where we are in order to plot a course to where we want to go.

Same goes for any project which involves process changes. Knowing the "TO-BE" is great - but it won't tell me how to get there unless I understand the current state.

Imagine creating a great "TO-BE" model and spending money to get there only to realize that you were already there - you just did not know it.

I realize it's a silly scenario - but you get my point.

Happy process modeling!

- Adrian

JohnIMM posted on Wednesday, April 8, 2009 4:43 AM

Adrian....

It is a trap that too many analysts fall into - the need to model everything about a place they ought not be.

However, even the analogy you give for search and rescue supports my argument. All you will need to know about where you are starting from are the coordinates. One you have these you do not hang around for the next day, week or month mapping where you are in minute detail. Quite the contrary, you know where you ought to be and you get the hell on with getting there and rescuing those in trouble.

The same is true in business. Analysts need to get the hell on with rescuing the business, not indulging themselves in mapping a place the business ought not be and will never be again.

The "As Is" and "To Be" approach is a very bad practice developed by large consultancies who got paid huge mounts of money for modeling businesses. So, instead of developing one effective "Ought to be" model, they developed three. The "As Is", the "To Be" an then the migration model from the "As Is" to the "To Be".

It was these same consultancies who introduced the flawed approach of modeling business processes as opposed to business functions - once again because it required far more (up to 300% more) modeling time for which they got paid.

Its time for the industry to drop these bad habits.

Try the "Ought to be" approach. It's scary because it is so simple, but I guarantee that it works. I have used it successfully in all types of industries and in enterprises of all sizes in the Ireland, the UK, Europe and New Zealand.

Happy function modeling! :-)

- John
[email protected]
http://www.integrated-modeling-method.com

Nathan Caswell posted on Friday, April 10, 2009 4:29 PM

Having tried it all over the last 25 years, I have to agree with John: most as-is work is a waste of time and energy.

To add a few extra stakes to it's heart:
* done well, it focuses on a bottom up, user driven design approach that may have a lot to do with personal/organizational issues and not so much with the larger needs of the business. In practice this allows abdication of accountability by Sr, managers and execs for defining business objectives and operational goals.
* generally drives a to-be that solves none of the top level business issues in favor or cleaning up often silly issues with the presumed as-is.

That said, the core justification of "knowing what is there now" remains valid.

A way of recasting the problem is to look at the 'as-is' phase as creating a catalog of functional resources. To-be processes that actually rise above the as-is state tend to run into severe resistance from almost every level. Designing them with recognizable places for existing organizations and people that reuse "resource" (skills, not necessarily activities) and responsibilities (at the department manager level) may dramatically improve the overall success rate. It is a significant change in the workproduct presentation, although not the labor to collect the content. It is well aligned with John's functional approach and does a much better job of exposing glaring gaps than the standard rummler brache swim lanes.

apthorp

Scott Sehlhorst posted on Saturday, April 11, 2009 10:46 PM

Great discussion. I agree with John that there is too much risk of as-is details polluting the to-be process discovery and documentation. Doing an as-is analysis first both delays the to-be work and influences it.

I also agree with Adrian - when doing change management, to help the organization migrate their operations from as-is to to-be, you have to understand (and to varying extent, update the documentation of) the as-is processes.

Documenting as-is is also a pretty convenient crutch for getting immersed in, and up to speed on, a new-to-you domain. The risk here is that you don't tease out the value (i.e. business goals) and get mired in the procedures (arbitrary "perceived requirements") that are actually orthogonal to the value.

What I have not tried yet, but would like to try some time, is doing to-be first (and letting the implementation team start building the to-be solution), and then, while iterating on the to-be, begin documenting as-is, in an as-needed way, to drive change management activities (like user training, policy updates, legal review, staging / conversion scheduling...).

Extending apthorps comments (which I also agree with, although I've only been doing this stuff for half as long)...

Understanding of an as-is process can help validate completeness and correctness of a to-be process. Stuff that was previously being done, that is not in your to-be document is either 'not needed' or 'needed.' Another way to think about it: everything you used to do should either be conspicuously abandoned, or intentionally continued/replaced. Comparing to-be and as-is processes allows a rigorous analysis

"why are we doing that (we never did before)" and "why aren't we doing this (we always used to)" are pretty powerful questions.

Thanks all for the great discussion

Scott Sehlhorst
http://tynerblain.com/blog/
http://twitter.com/sehlhorst

Guy Beauchamp posted on Tuesday, April 14, 2009 3:32 AM

Process maps define the end point of a project from a process perspective.

Process requirements are a statement defining what is to be achieved from the process perspective once the changes specified in the process requirements (process models, execution logic and non-functional requirements) have been designed, built, tested and implemented.

To that extent they are the end point of the (change) project that implements them.

So what is the starting point? If we haven't defined the starting point then what is the scope of change that the change project is implementing?

What benefits accrue because of the change? If we don't know how big the change is we can't size the benefits.

So in terms of analysis of change requirements, as-is models are (by definition) useless as they define what is required.

In terms of the overall project analysis of changes required, I don't see how they can be avoided either explicitly or implicitly (as often happens during the design stage).

Guy

Adrian M. posted on Tuesday, April 14, 2009 3:55 AM

Guy - did you mean to say that "as-is models are useful"?

- Adrian

JohnIMM posted on Tuesday, April 14, 2009 5:26 AM

The only process map / model that defines the end point of a process project is the "to be" process!

The starting point of the project is where you are. It is, by definition, the wrong thing in the wrong place, otherwise why change it?

So, having found yourself in wrong place and having decided to get out of it, you now decide to do something you have never done before and model this wrong place in detail! Why? Only in the world of process modeling do people try to defend such a crazy action.

They say "we need to know where we are". You know where you are. You are in a place where you ought not be. So get out of it!

This whole insane notion of modeling the "as is" processes at the precise point that the business has decided that they are wrong, was introduced by large consultancies to generate revenue. If you work for a large consultancy then you would probably still argue that this a good thing to do.

If you work in a business that is trying to improve its processes then you are advocating that your business waste a huge amount of time and money to bring no real business benefit.

There are many thing you might want to catalogue about the existing business environment in order to plan an effective migration path to the future, such as applications, systems, technology, etc. The "as is" business process is not one of these! It has never been of use or benefit and it never will be. It only serves to give a false sense of security to nervous managers, analysts and project managers.

If you want real security model the business functions - these are the absolutes of any business. They will tell you exactly where you need to be, both now and in the future.

John Owens
[email protected]
http://www.integrated-modeling-method.com

posted on Tuesday, April 14, 2009 1:05 PM

I am by no means an expert but it does seem that most projects must have some sort of an as-is model (which may just be a paragraph or two stating the process) to help determine how and why to move on to a new process. (Also, to help get team members up to speed with the context of the problem/opportunity)

With that said, I have seen my share of As-Is modeling get a little out of hand and wasting needless time, effort and money. This happened more so in the early 90's and working for a big consulting firm...:-) Since then, not so much!

OTOH, I find APPROPRIATE as-is process modeling absolutely invaluable to a project that is redefining how a business unit, department, organization is changing their process. Take for example, a system to manage customer information that may integrate with Sales, Finance, Marketing, Customer Service, Technology, etc. The first thing to note is that THERE IS an organization that is getting their work done using People, processes, technology. Thus, there HAS to be an organized way to CHANGE the current process to the new process.

Okay, so I guess one could just start over, get rid of all the current people, processes, and technology. And I don't mean to sound glib...this is a very real option that may make sense. If so, in this case, I can definitely see why an as-is is not needed. (OTOH, you would need to justify the dumping of all the current processes, people, technology...but I guess that is another discussion)

But, for the sake of argument, let's say the decision is to CHANGE and not REPLACE the current process. How do you know what pieces to change and what to leave alone? What do you slightly update gradually versus switch on off? What pieces are handled good manually or systematically today? What people are invaluable? What pieces of the process utilize old technology or what pieces could benefit from new technology? How much money is there to spend and on which pieces of the process should be updated using this money?

I would say, that some version and some level of detail is needed of todays process to determine the answer to the questions. As I said above, the model may not be a complete UML based activity diagram that models down to the individual groups manual processes of send and receiving emails....but I think we all agree that some understanding of the current process is needed. Right????

I guess, I don't completely accept that as-is process modeling is a complete waste of time. As always, each project is different and requires different levels of detail. All projects are not created equal. A blanket standard stating that each project DOES NOT need or DOES need X level of process modeling detail, I think, is the wrong way to think about it.

David Wright posted on Tuesday, April 14, 2009 1:13 PM

I thought I had weighed in on this already (somewhere else, perhaps?).

In any case, I have found in practice that you can get both models at the same time. Ask what is done now and then ask if that is working OK, or does it need it to be better in the future? SME's need to start with something they do know, what is done right now; a blank page and asking what should the future be will get blank stares in return.

This is also where you need to involve different SME's, perhaps in separate sessions. Hands-on SME's doing the work today know what they do, but their managers will be the more likely sources for what change is needed, indeed sometimes changes that workers may not want.

So, if the discussion here is about slavish adherence to all 'as-is' versus all 'to-be', then the answer is between the extremes, as it almost always is.

David Wright posted on Tuesday, April 14, 2009 1:40 PM

John.

"The next major error the analysts make is by starting out modeling business processes as opposed to business functions. But that is a whole other story."

Yes, and worth discussing, I use Process Modeling as a primary means of identifying Business Functions/Activities. By dividing the desired process into activities based on common actors and time delays, I get a set of distinct activities that can be used and re-used in any process, and I know I have all the activities the business needs. So, I don't think its a case of Process versus Function, it is Process begats Function.

Scott Sehlhorst posted on Tuesday, April 14, 2009 1:52 PM

There's a really important distinction between process (what the business needs to do) and procedure (how the business _happens_to_do_it_today), that most of the junior analysts I've worked with found difficult to make.

This distinction can be made by some SMEs when prompted (so don't forget to ask), but not others.

I've used it as a litmus test of SMEs on some projects - do you know what _to_ do, or just what _you_ do?

This is especially difficult with emergent processes that have evolved organically over time. I worked with an insurance company that had processes that had evolved over decades (adapting to regulatory changes, policy changes, changes in business conditions, and technology changes). By far, the hardest part of that work was finding people that knew _why_ X happened before Y (or at all).

At risk of completely derailing the thread, I'll also point out that this is why it is critical to differentiate between "business rules" and "requirements."

Scott Sehlhorst
http://tynerblain.com/blog/
http://twitter.com/sehlhorst

posted on Tuesday, April 14, 2009 3:37 PM

@Scott - That's a very good point regarding the distinction between process and procedure. The problem is that SMEs that are very influencial and/or powerful in the organization tend to think of process as a combination of process and procedure.

I'm not sure if, in my experience, the SME doesn't understand the difference so much as they don't believe another procedural way is feasible.

I think most analysts understand the distinction...I think the challenge is articulating the idea so that the business owners and SMEs accept it; don't take it as a blow to their ego; allow the process flows to be detailed without the procedural stuff.

I have had to detail process flows, and for the sake of moving along in the project, include procedural flow. This can be a plus though, I guess, in that you can list alternative solutions to a specific procedure.

Good thread!

Anonymous User posted on Tuesday, April 14, 2009 8:14 PM

Business Functions are the building blocks for all other business activity. Processes are built from functions not the other way around.

From the function model you can derive ALL other models, including data models. This cannot be said of any other model.

Of course it is a crazy question to ask a business "what do you think your processes should look like in the future". This question is only ever asked when you start in the wrong place by using process modeling as the primary modeling technique.

Asking the business "WHAT is it that your business OUGHT to be doing" is not asking the business to gaze into a crystal ball. Rather, it asking senior executives to define what the whole business, or a particular area, is all about - probably never previously defined - in other words, what are its core activities or Business Functions. This is not an optional question.

This is the essential starting point for any successful project, NOT business processes. Their misuse has created so much confusion and complexity over the years that it is becoming almost impossible to unravel.

Too many people now honestly believe, because they have never seen Function Modeling in action, that process modeling really is the correct starting point. This is having a massive negative impact on businesses, because:

o It requires about 300% more effort, time and money.
o Its slows down development and improvement.
o It misses out up to 30% of essential business activity.
o It always starts by modeling the wrong thing in the wrong way and fails to deliver the benefits the business hoped to achieve.

John Owens
[email protected]
http://www.integrated-modeling-method.com

David Wright posted on Tuesday, April 14, 2009 10:43 PM

John,

Interesting claims; how did you determine these numbers?

JohnIMM posted on Tuesday, April 14, 2009 11:30 PM

I did a series of measurements on a set of projects that were run in several large organizations in the UK, including BP Chemicals, London Underground and others.

On average Process Modeling required the production of 3 times more diagrams than Function Modeling in order to arrive at the level of elementary function / process.

Process Modeling also missed out 30% or more of the essential business functions. It missed all of the business functions that created reference and master data - not much good for MDD.

David Wright posted on Wednesday, April 15, 2009 6:46 AM

It comes back to "what is a business process model?". You can draw involved diagrams; you can also just list steps in a primary scenario,and then list alternate scenarios/paths.

Steps in a process are generally about someone doing something with some information, guided by policies and/or constrained by rules, to achieve a goal. So, a process does also support data modeling and rule definition, and a good CRUD matrix will find those missing data management functions.

Any way, we may just end up agreeing to disagree.

So, how do you define your functions/activities, and how do you make sure you have defined all of them within a scope/domain?

DougGtheBA posted on Wednesday, April 15, 2009 8:21 AM

Wow! Great thread to all. John..thanks for opening the hornet's nest.

I have to say that while reading the article and then all the posts, I kept thinking about the "What about when...." scenarios that I thought called for AS-IS process definition. Each and every time I came back to John's statements.

Why DO we really need to know what Wrong looks like? Someone has already determined that there is a problem. I need to do some more research on all this, granted, but my eyes are open now. Why can't we factor in wholesale changes in business process and impacts while we define where the organization needs to be?

Creating, consuming and perpetuating current methods of business functionality can be dangerous. Once defined, specific functions must be owned, and those owners (SMEs) have a vested interest in keeping things just like they are and have been for the last 20 years. It is easy to lose sight of what should be while mired in organizational politics and wrangling as invested personnel try to keep their roles/jobs from changing. In the end, the whole argument clouds the real purpose, which is to achieve a more effective way of performing. I might even have to say that only be removing the As-Is garbage can one truly focus on real solutions. What results will change org structure, functions and the like, but by that point you've already determined where you need to be and all that remains is fine-tuning today in order to get to tomorrow. Why give a darn about yesterday?

Every once in a while, we all need a slap in the face to get us unfocused on what we thought was the gospel. How else can we step back to re-evaluate what we are doing and determine whether it provides value. I think this may be one of those times.

I'd like to come back to this after researching a bit more. Thanks to JB for bringing this discussion to light on his site. Now...I have some As-Is process models to burn....

DougGtheBA
http://twitter.com/DougGtheBA

JohnIMM posted on Thursday, April 16, 2009 5:05 AM

In answer to the question "what is a business process?", it is "the definition of the order of execution of business functions in response to a trigger in order to arrive at a preferred business outcome".

The elements of a business process are:

o business functions
o trigger or triggers
o preferred outcome
o non-preferred outcome(s)

Each execution step in a process is a function. Each of the elements are linked via dependencies that define the precedence.

All of the above are defined in detail in my eBook IMM Business Process Modelling.

In answer to the question "So, how do you define your functions/activities, and how do you make sure you have defined all of them within a scope/domain?"

In the the Integrated Modeling Method I have developed a technique that enables you to identify all of the functions that fall within the scope/domain.

Who to ask, where to start, how to proceed and how to end up in the right place are all defined in my eBook IMM Business Function Modelling.

Both eBooks are available at http://www.integrated-modeling-method.com. There is also a series Rapid Guides available for FREE on the website that introduce each of the modelling techniques.

John Owens
[email protected]
http://www.integrated-modeling-method.com

Tony Markos posted on Thursday, April 16, 2009 11:19 AM

Are As-Is models necessary?

Hey, if I, as a BA, could find someone - exec director, ceo - anyone - who would just give a To-Be model that is comprehensive and integrated enough to get the job done, life would be a heck of alot more fun. As-Is modeling, especially for large-scale systems, involves alot of tough negotiations among affected parties dealing with conflicting views of what the To-Be should look like. As-Is modeling also involves being bambozzaled alot as knowledge of company proprietary procedure is "turf" and people will often defend "their" turf to the death.

You mean some of you have worked on projects where someone has born all this pain for you and given you an adequate To-Be at the start? Wow! Please tell me what majical lands you work in! I desire such serenity.

Thanks,

Tony Markos
Waiting for a Miracle

JohnIMM posted on Thursday, April 16, 2009 4:33 PM

No director or executive is going to hand you a To-Be model. There would be no need for a BA if they did this.

The Integrated Modelling Method shows you how to extract the complete function model form properly structured interviews with senior executives. Any To-Be processes that need to be modelled can easily be extracted from the function model.

BAs and business managers should also remember that not everything that happens in a business is a process and so should not be modelled as such. On the other hand, everything that happens in a business is a function and only by using the function model can you be sure that you have modellled it.

Yuour miracle has arrived, Tony. It is the Integrated Modelling Method! :-)

John Owens
[email protected]
http://www.integrated-modeling-method.com

Scott Sehlhorst posted on Thursday, April 16, 2009 6:41 PM

This continues to be a fun discussion.

Communicating the business rules and the requirements for a to-be process is "required" in order to build the future-state solution.

Understanding the as-is process is "required" to help a company migrate their operations from the current-state to the future-state.

Technically, neither statement above "requires" documentation of either the as-is or to-be process.

My experience has been, and my expectation continues to be, that documenting the to-be process is critical to the success of communicating the associated business rules and requirements in a context that will lead to a successful implementation.

My experience has also been that documenting the as-is process reduces the risk of undiscovered or misunderstood requirements when documenting the to-be processes. An effective way to validate "what do you need" answers is by asking "how do you do it today" questions. These paths of conversational exploration also regularly lead to otherwise-undiscovered requirements and rules.

If you can create _complete_ to-be requirements, _without_ having an understanding of how the business runs today, then more power to you. [caveat: when the business wants to go do something completely new, and there is no 'as-is', of course that's different]

Further, the amount of effort put into designing a transition from an as-is state to a to-be state is inversely proportional to the cost/pain that the organization realizes during the transition.

Do you have to create two equivalent documents, with the same level of detail, one for as-is and one for to-be? No, absolutely not. The documents are artifacts, and only exist to serve a purpose. Since the purpose of as-is documentation is different than the purpose of to-be documentation, doesn't it logically follow that the form of the documentation should be different?

Wow. I meant to say something concise, and apparently climbed up on a soapbox.

Scott Sehlhorst
http://tynerblain.com/blog/
http://twitter.com/sehlhorst

Adrian M. posted on Friday, April 17, 2009 1:00 AM

Scott - you bring up some great points!

Do the AS-IS and TO-BE have to be on par in terms of level of details and type of artifacts? Of course not!

I truly believe in "Just Enough"! And this applies to both as-is and to-be. Also - are both models even needed for all projects? Of course not!

If we have not yet figured it out, business analysis is not a science but an art. There is no magic formula. That's why experienced practitioners with a well equipped war chest are in demand. They are able to make just in time decisions as to which methods, tools, processes, artifacts, techniques to use in order to get the job done. The client never wants to pay for unnecessary work.

But I digress...

I wanted to make two more points:
[1] AS-IS and TO-BE do not have to necessarily be separate artifacts. On many projects I've simply used an annotated as-is to serve as the to-be. In many cases this might be good enough as you have the best of both worlds:
- the as-is
- the to-be
- the diffs (aka what changes I need to make)
...all in one place.

[2] (Echoing David Wright) - neither as-is nor to-be have to be represented as traditional process flow diagram. Use the tool the makes sense given the type of project, existing documentation, scope of work, nature of desired changes, etc. Some other options I've used in the past:
- use case narratives
- story boards
- data flow diagrams

Adrian

Tony Markos posted on Monday, April 20, 2009 9:53 AM

Hi:

I don't think that anyone in dicussion has recongnized the fact that a properly constructed As-Is models IS about 98% of the To-Be model.

Expansion: In As-Is modeling we iron out all the complflicting views of how things work. What is really happening here is that we are ironing out how things WILL work. It is in the As-Is modeling process that the essentials of the To-Be are negotiated.

Also, Jim Ownen stated:

"The Integrated Modelling Method shows you how to extract the complete function model form properly structured interviews with senior executives. Any To-Be processes that need to be modelled can easily be extracted from the function model."

My comment: It has always been my experience that, on larger-scale projects, senior executives don't have anywheres near the comprehensive, integrated understanding of the business necessary to complete an As-Is model by just interviewing them.

Tony

DougGtheBA posted on Monday, April 20, 2009 12:26 PM

Hey Tony:

I guess in response to your post I would have to ask why you need two models if they are so similar. If, as you say, that you are ironing out what will be in the future, then you are proving what John Owens says.

It is true that executives don't know the granularities of the current business models, nor should they. They also will most likely not be digesting the TO-BE solution either. What they DO know is where they need the orgainzation to go in order to move forward, and those answers reside as solutions in what is captured in the TO-BE model. It is the user community that is the primary consumer of the models, which is why there are often times failures in requirements elicitation when only management is part of the discussion. They simply don't have the transparency into daily operations, which is where all the details are.

Thanks for the dialog.

DougGtheBA

Tony Markos posted on Tuesday, April 21, 2009 9:25 AM

Doug:

A properly constructed As-Is model is about 98% of the required work of To-Be modeling. Editing this As-Is to incorporate, for example, To-Be implementation considerations can be done, but it takes a relatively very small - often even insignificant - amount of time. So you don't need two models - just one - the properly constructed As-Is.

John and me differ profoundly. I understand him as saying that the As-Is (and To-Be) can be captured from properly crafted questionairs to top management, and that the tough negotiations between the conflictioning factions can be eliminated.

As I previously state, I don't see such as realistic at all. Should top management also be consulted? Of course. Bbt I agree with you that the need to interface with the user community is the BA's real task at hand. And the primary discussions here revolve around As-Is discovery.

Tony

Anonymous User posted on Tuesday, April 21, 2009 4:42 PM

Tony

If I were a CEO I would find it hard to justify expenditure on your project. Say you are asking me to spend $100,000. Of that money, you will expend 98% on building your As-Is model.

So we are going to have to spend 98% of our money to document where we are, when we know that where we are is not where we ought to be and you are going to use the other 2% to get us to where we ought to be?

I am sceptical.

The only time an As-Is model can be 98% of the To-Be model is when the business is 98% perfect and only needs 2% change.

The things that are usually most wrong in a business are what people are doing day-to-day. It is not their fault. They are battling with operating a whole set of mechanisms and procedures that have built up over time and that are based on historical systems and habit.

Analysts waste far too much time trying to infer what a business ought to be doing from this day-to-day activity.

It is about as useful and fruitful as analyzing a shipwreck on the ocean bed and trying to infer from the ship and its cargo what it ought to be doing. If it was capable of doing what it ought to be doing it would not now be at the bottom of the sea!

There is an easier, faster and less painful way for both the business and the analyst.

That is why I developed the Integrated Modeling Method, to help analysts achieve real change at an accelerated rate. To enable them to rid the business of complexity and bring power through simplicity and elegance.

John Owens
[email protected]
http://www.integrated-modeling-method.com

Nathan Caswell posted on Tuesday, April 21, 2009 6:13 PM

If the client value is doing an enhancement (2% change to existing) then doing a full as-is model is, umm, a rip off. Good work if you can get it.

If they simply don't know what is going, low process maturity, wildly out of control mess of incomparable systems, procedures, then two separate engagements are appropriate.
1. an assessment and help them understand what they have and where they are going.
2. hit the low hanging fruit. If it was really ok, just unknown, you give them the good news it will be cheap. If not, you have a profitable engagement on tap, but not one where the to-be is 2% of the as is.

Part of the issue here is that most standard approached focus all the acquisition and modeling into getting to the IT and don't leave the business with anything the gives them leverage the next time. The case where they really need an as-is to find the 2% enhancement was a rip off by the last bunch.

Nathan Caswell posted on Tuesday, April 21, 2009 7:41 PM

Sorry guys. Last comment was a bit intemperate. Meant to say "not giving the client good value". I've been part of enough big as-is efforts to know that they were serious efforts to go good by the client and that anyone posting here is unlikely to be doing otherwise.

Barton George posted on Wednesday, April 22, 2009 9:57 AM

Wow, I had no idea when I submitted this post that it would provoke such a great discussion! (FYI, there seemed to be some confusion early on as to the source of the article, it is based on the online training course “Process Mapping 101” created for Lombardi Software by Bruce Silver, founder of BPMessentials.com, and Shelley Sweet of I4Process Consulting and was edited by myself)

As you might expect I fall in the camp that see’s value in the “As Is” model. That being said I don’t believe that it has to be labored over for weeks and weeks, I am not a fan of mapping for mapping sake. As I’ve experienced it, the value of the “As Is” is in laying out of how the process works in reality. While senior level individuals know the desired process goal e.g. shorten lead time from X->Y, cut defects from A->B, they often don’t know tactically what needs to be changed to get there.

When mapping the current state the idea is to solicit input from those actually involved in the process. By mapping how a process actually works you can identify areas for change. If someone is doing what they shouldn’t be doing, why are they doing it this way? Is it ignorance, incompetence or is there an issue that needs to be identified and resolved?

The more that process mapping can be a collaborative and inclusive effort the greater the chance that reality of business can be fleshed out and then improved on. And the “As Is” map is the best place to start.

Barton George
http://bartongeorge.net/
http://www.lombardisoftware.com/bpm-blueprint-training.php

Anonymous User posted on Wednesday, April 22, 2009 10:11 AM

John:

You state that: "The only time an As-Is model can be 98% of the To-Be model is when the business is 98% perfect and only needs 2% change."

My response:

Far, far from it. I have never done an As-Is effort without having to negotiate among system participants resolution to a ton of confusion and disagreement about what is supposed to be currently done. Jeepers! - this is the biggest difficulty that I face! And it has been my experience and of some of the others that I know that such As-Is models are up to 98% of the ultimate To-Be model.

Maybe there is confusion as to what an As-Is model is? You say that the output of an As-Is modeling effort is " a detailed model of what ought not be done". Not true, unless the analyst creates a poor (i.e., unusable) As-Is model. An analyst can not create a comprehensive, integrated (i.e., usable) As-Is model of a bunch of conflicting and otherwise dysfunctional behavior - and especially a detailed model of such. That would be like successfully documenting the wind.

I, for example, typically use Data Flow Diagrams for my As-Is models. With DFDs confusion or conflicts glaringly stick out - prodding me to address them. To the degree that I don't, the invalidity of my model is clearly made know to all. If the analyst's As-Is model is integrated together, then he/she must have first negotiated amongst the system participants what ought to be currently happening.

Yes a usable As-Is takes time. And yes the majority of analysts focus way too much on the who and how vs. the what. But I do not think it is realistic to think that just by working with the top-dog the analyst can properly define a To-Be. From what I have experienced and seen, the negotiations with the system participants that I previously mentioned is the main thing that needs to be done.

John, can you provide more detail on the nature of the senior execuive interviews that you espouse: What kind of models are created? Has it been your experience that top exec know enough about the business for them to provide the information necessay to creat a usable To-Be? Is the negotiation process that I previously mentioned elminated by use of dictates?

Tony

Tony Markos posted on Wednesday, April 22, 2009 11:36 AM

John:

Oppss... I need to expand commonts that I made in my previous post to read:

Irregardless of whether talking about what ough not to be done or what ought to be done, an analyst can not create a comprehensive, integrated (i.e., usable) As-Is model of a bunch of conflicting and otherwise dysfunctional behavior - and especially a detailed model of such. That would be like successfully documenting the wind.

Tony

JohnIMM posted on Thursday, April 23, 2009 4:57 AM

Tony:

The information carried out with senior executives are structured interviews that are best recorded and later transcribed. They ask questions like:

o what business functions fall within the remit of the project
o descriptions of what these business functions are
o what are the critical success factors for the business
o what are the critical success factors for the project
o who are the other major players in the business regarding these business functions
o who in their management team would have the best view of the way forward fro the business regarding these business functions

The next round of information gathering would be with those senior managers recommend by the senior executives.

I initially avoid interviewing people who are currently immersed in the current systems at a low level as they can only see the business in terms of the current system.

They might have great ideas on how to improve the current system but, as the current system is often doing entirely the wrong thing, they would only be coming ups with a better way of doing the wrong thing!

The initial model I produces ia a function model and from this I can extract the data model.

This whole process is described in details in my eBook IMM Functions Modelling available at http://www.integrated-modeling-method.com

I hope that this helps.

Anonymous User posted on Tuesday, April 28, 2009 9:04 AM

I think Tony brings out a crucial point: In a low process maturity organization characterized by "a bunch of conflicting and otherwise dysfunctional behavior" there is no as-is process!

At higher maturity levels (at least documented processes used by both workers and management) there is a shelf as-is to work from so much of the discussion here doesn't apply.

No process 'on the ground' is a big problem.
o From a 'neutral facilitator' consulting perspective, the client can't provide the required input.
o From the client perspective there is a significant cultural/organizational problem of moving up a maturity level before they can take advantage of the automation.

The discussion here seems to focus on the process chicken and functional egg. (feel free to reverse the mapping :) without directly addressing the bootstrap problem. As-is mapping and functional analysis implicitly address the bootstrap problem in different ways.

o as-is mapping assumes there is a process, and then does the hard work of creating it, bottom up, out of the organic tangle of jobs roles and responsibilities. Note that the client hook for process is "role" -- "what do you do".The myriad minor muddles that could result in finger pointing will be implicitly sorted out during negotiation so that every one appears to be doing a good job. As appropriate for a low maturity transition, the to-be models then represent the impact of IT on interface and coordination within the established role structure.

o Functional mapping side steps the process issue and does the easier work of a top down decomposition. The client hook for function is 'responsibility' -- "who reports to you". This is usually quite clear, even in an operationally muddled organization and allows the smooth transition to automation. The effort of sorting out roles and coordination between them can be left for retraining during implementation. The process maturity may not have been increased leading to efficient development but less than dramatic business impact.

It is worth noting that the original article above starts, in effect, with a functional approach. High level processes/activities are pretty much indistinguishable from functions, particularly when described by management and function follows form. In one fairly spectacular case I observed a quite large and detailed functional decomposition be transformed overnight into a process map based on a strategic change.

What is reflected here is a larger context of oscillation over that last 20 years between enterprises organized around end to end process or functional responsibility structures. Plus the occasional matrix where everyone gets to figure it out for themselves. The oscillation suggests that none of these are 'the' answer.

ITgurublog.com posted on Tuesday, October 25, 2011 9:16 AM

I'm a bit late to the party. I agree with the comments on the (lack of) value in devoting time to an as-is analysis.

However, I strongly disagree with ...

"The Project Lead: The Lead is a person who knows the most about all the steps in the process and is usually a supervisor or manager. "

Several reasons:
1) Objectivity - somebody this close loses objectivity and maight also have their own agenda
2) Process mapping expertise - maybe this person has always performed an operational role and has never been involved in change before. Just because they know the process really well does not mean that they can map it accurately and efficiently
3) Knowledge expertise - if the knowledge expert is running the project, who is available to be interviewed?
4) Project management expertise - same argument as process mapping expertise
5) Availability - a supervisor or manager has a day job and can't devote enough time to effectively lead a process mapping exercise (at least without some form of backfilling - but unless the supervisor/manager has aspirations to change roles, why replace him/her by somebody less effective so that he/she can take on a role where he/she is less effective?)

The project leader should be an experienced process mapper and project leader with basic, generic knowledge of the process to be mapped. Preferably he/she should also be independent of the departments covered by the process, although this might not be possible.

Rob
ITgurublog.com