I was working on some training materials this week, and I needed to whip up as-is and to-be business process maps. These would be used to help trainees visualize how the software they were going to build in an agile way during the training would transform the fictional business for which it was being written.
I got completely mired down in this seemingly simple task, and I realized it is because the more you think about it, the more the business process mapping for the purpose of planning a software project is just not simple.
BPMN 2.0
If you're like me, you are probably thinking, "well gee, just throw together some circles, rectangles, and arrows, and you're done, what's the big deal?" Indeed, I started down this track, and in the name of being professional, I spent an afternoon this week familiarizing myself with Business Process Modeling Notation (BPMN, currently at version 2.0). I became fairly adept at BPMN, which is very nice for creating process flowcharts, and tried out a very cool tool, Lombardi Blueprint, which keeps track of all the arrows for you (as MS-Visio and OmniGraffle do not). Blueprint also ensures that you create "legal" process flows, which means that each process has a single starting point and a single ending point, and within the process, each box has one or more entering arrows, and only one exit arrow.
Armed with a new knowledge of circles, rectangles, arrows, and a very nice "clock" widget, I quickly mapped all of the business processes relevant to the software process, and thought how handy the flow charts were going to be when planning scenarios and stories for the softwareBut that's when it hit me--what had I done?! My "business analysis" was predisposed to think of the business process as a set of manipulations of database objects which could potentially be automated, and the moment I had chosen the BPMN flow-chart as the tool I wanted to use to map the business, I lost focus on the actual business problems which were spurring the need for new software in the first place. I was describing "as-is" and "to-be" from a systems perspective without providing any particular way to notate why "to be" was going to be better than "as is," except perhaps by showing some rectangles being eliminated through software creation.
Here's where I entered the world Dan Woods describes aptly as "Stalking and Capturing a Business Process." I didn't want to start with procedural details--I wanted to understand in plain words what the company was trying to do, and where the pain points were. I wanted to talk about value and strategy. For this fictional widget company, it turns out, there's an inventory problem customers run into when trying to buy widgets. You might guess that when you see the clock in the diagram, but the problem doesn't leap out at you. I wondered whether other maps might do a better job at visualizing pain points. I found two, which I'll race through here--I think I might need to write something longer one day, to do this topic justice. (who knew? I need to write a book!)
Value Stream Mapping
Mary and Tom Poppendieck lay out Value Stream Mapping in Chapter 4 of their awesome book, Implementing Lean Software Development. For their purposes, mapping should start with a customer demand, and work back from there to show all the steps that lead the company to meet the customer demand. A business process map looks something like this, and can be developed with a process the Poppendiecks describe, and which is also nicely laid out step-by-step in Ron Periera's Lean Six Sigma blog:
Note that this value stream map focuses on things which occur which impact the cost and timing of delivering goods or services to the customer, focusing on the customer. Although it may be necessary, in Periera's example, to eventually create and describe an object model which includes customers and peanut butter sandwiches, creation of a flowchart which traces the movement of those objects is secondary to this first business process map, which looks primarily at strategic value and what may be getting in the company's way in delivering it.
Value Chain Mapping
Value Chain Mapping was first developed by a Harvard professor, Michael Porter (and in fact you can find out a lot about it by doing an internet search on "Porter Value Chain." ) Value Chain Mapping provides a more rigorous checklist of topics to evaluate in mapping business processes, and is likely appropriate when looking at a larger company than my widget store or Periera's peanut butter sandwich factory. Porter formalizes the different areas which come into play with any company of size, in delivering a product or service to a customer. Like value stream modeling, value chain modeling looks at the process that takes raw materials and converts them into something beyond what the customer could build for himself without help, and evaluates where and how value is added. Here's Porter's scheme:
There's quite a good free web site describing value chain analysis here.
The Bottom Line
I apologize for flying through this quickly, but I wanted to put a bit of an outline out for people who are interested--the bottom line is that the type of mapping you do will heavily impact the way you think about problems. As usual, I'm pushing tools which may help us to think more about strategic business value, at least at first, during project inception, and less about the systematic steps to improve it.
Author's note: It's no coincidence that BPMN is embraced first and foremost by software engineering companies like Oracle who can handily map it to Business Process Engineering Language (BPEL), and thereby create the framework for a Service Oriented Architecture (SOA) software solution. Further, it's no coincidence that the BPEL created this way is generally described as "not human readible," and that nobody has come up with a way to map BACK from BPEL to BPMN. I would like to think that it simply stands to reason that the governing body which owns BPEL and BPMN (and UML, for that matter) has the acronym OMG.
I got completely mired down in this seemingly simple task, and I realized it is because the more you think about it, the more the business process mapping for the purpose of planning a software project is just not simple.
BPMN 2.0
If you're like me, you are probably thinking, "well gee, just throw together some circles, rectangles, and arrows, and you're done, what's the big deal?" Indeed, I started down this track, and in the name of being professional, I spent an afternoon this week familiarizing myself with Business Process Modeling Notation (BPMN, currently at version 2.0). I became fairly adept at BPMN, which is very nice for creating process flowcharts, and tried out a very cool tool, Lombardi Blueprint, which keeps track of all the arrows for you (as MS-Visio and OmniGraffle do not). Blueprint also ensures that you create "legal" process flows, which means that each process has a single starting point and a single ending point, and within the process, each box has one or more entering arrows, and only one exit arrow.
Armed with a new knowledge of circles, rectangles, arrows, and a very nice "clock" widget, I quickly mapped all of the business processes relevant to the software process, and thought how handy the flow charts were going to be when planning scenarios and stories for the softwareHere's where I entered the world Dan Woods describes aptly as "Stalking and Capturing a Business Process." I didn't want to start with procedural details--I wanted to understand in plain words what the company was trying to do, and where the pain points were. I wanted to talk about value and strategy. For this fictional widget company, it turns out, there's an inventory problem customers run into when trying to buy widgets. You might guess that when you see the clock in the diagram, but the problem doesn't leap out at you. I wondered whether other maps might do a better job at visualizing pain points. I found two, which I'll race through here--I think I might need to write something longer one day, to do this topic justice. (who knew? I need to write a book!)
Value Stream Mapping
Mary and Tom Poppendieck lay out Value Stream Mapping in Chapter 4 of their awesome book, Implementing Lean Software Development. For their purposes, mapping should start with a customer demand, and work back from there to show all the steps that lead the company to meet the customer demand. A business process map looks something like this, and can be developed with a process the Poppendiecks describe, and which is also nicely laid out step-by-step in Ron Periera's Lean Six Sigma blog:
Note that this value stream map focuses on things which occur which impact the cost and timing of delivering goods or services to the customer, focusing on the customer. Although it may be necessary, in Periera's example, to eventually create and describe an object model which includes customers and peanut butter sandwiches, creation of a flowchart which traces the movement of those objects is secondary to this first business process map, which looks primarily at strategic value and what may be getting in the company's way in delivering it.
Value Chain Mapping
Value Chain Mapping was first developed by a Harvard professor, Michael Porter (and in fact you can find out a lot about it by doing an internet search on "Porter Value Chain." ) Value Chain Mapping provides a more rigorous checklist of topics to evaluate in mapping business processes, and is likely appropriate when looking at a larger company than my widget store or Periera's peanut butter sandwich factory. Porter formalizes the different areas which come into play with any company of size, in delivering a product or service to a customer. Like value stream modeling, value chain modeling looks at the process that takes raw materials and converts them into something beyond what the customer could build for himself without help, and evaluates where and how value is added. Here's Porter's scheme:
There's quite a good free web site describing value chain analysis here.
The Bottom Line
I apologize for flying through this quickly, but I wanted to put a bit of an outline out for people who are interested--the bottom line is that the type of mapping you do will heavily impact the way you think about problems. As usual, I'm pushing tools which may help us to think more about strategic business value, at least at first, during project inception, and less about the systematic steps to improve it.
Author's note: It's no coincidence that BPMN is embraced first and foremost by software engineering companies like Oracle who can handily map it to Business Process Engineering Language (BPEL), and thereby create the framework for a Service Oriented Architecture (SOA) software solution. Further, it's no coincidence that the BPEL created this way is generally described as "not human readible," and that nobody has come up with a way to map BACK from BPEL to BPMN. I would like to think that it simply stands to reason that the governing body which owns BPEL and BPMN (and UML, for that matter) has the acronym OMG.
Hey--when I read your first sentence, thought you were saying something like "whip ass". I think it also applies, though. :)
ReplyDeleteMore colorful than what I had in mind, but okay!
ReplyDeleteThis is indeed interesting will for sure put this to work when I start process simulation later this week.
ReplyDeleteHow did it go, Jeffrey?
ReplyDeletewhat about "value networks"? you could think about it!
ReplyDeletehttp://valuenetworks.com
Thanks, pictor, I will!
ReplyDelete