Skip to main content

Value Chains and Value Streams: Strategic Maps Are Better For Project Inception

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 software
But 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.

Comments

  1. Hey--when I read your first sentence, thought you were saying something like "whip ass". I think it also applies, though. :)

    ReplyDelete
  2. More colorful than what I had in mind, but okay!

    ReplyDelete
  3. This is indeed interesting will for sure put this to work when I start process simulation later this week.

    ReplyDelete
  4. what about "value networks"? you could think about it!
    http://valuenetworks.com

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica