How to make Soduko boring - Follow the Process

I spend a lot of time travelling to and from client sites, and when I travel I often pass the time by playing Soduko on my iPhone (I use a very good version from Mighty Good Games).  Once apon a time I relied on the paper versions in the airline's magazines - but the iPhone app is now my norm.

One incentive for playing Soduko was to keep my little grey cells from getting lazy - but it also a fun way to pass the time, so I was rather surprised last year when my friend Roberta told me that she had given up the game after just a few months of playing. According to Roberta - who is a math teacher - the game wasn't challenging any more.  She'd figured it out, and the puzzles were no longer puzzling.

My first reaction to Roberta's statement was typical for me - I just assumed that the Soduko puzzles she had access to weren't "hard enough".  Many, many times I would finish a flight with an unfinished puzzle from the American Way Magazine staring me in the face.  I certainly hadn't "figured out" Soduko.

Then in March I saw an article in USA Today about J. F. Crook and a Soduko "solution".  Crook is a mathematician, but his "solution" isn't a mathematical proof - it's a series of steps.  I'm a process guy - so when you say "series of steps" I say "process".  Crook had published a process definition for solving any Soduko puzzle.

I read Crook's process definition, and it wasn't that far from recommendations that I has seen earlier.  Soduko puzzles are grids of 81 squares, nine across and nine down. Some boxes have a number filled in; the rest are blank. Players must fill in the blank squares with numbers between 1 and 9 without repeating any numbers in a row, column or the nine interior 3-by-3 boxes of the puzzle.

Crook's Sudoku Solving Process can be summed up as follows:  Mark all the squares in the puzzle that could be a "1" - Based on "what could be a 1" apply some simple rules to "solve" a few squares.  Repeat this process for numbers 2 thru 9.  Crook admits that you still may find some sqaures that might be one of two numbers, but you just "guess"  a number for that square and proceed until your guess is either confirmed or invalidated.

The problem with Crook's Process is that it's really tedious. While solving a Sudoku puzzle you'll often have insights or spot patterns that lead you to solutions for a whole bunch of squares at one time.  Consequently, when I read Crook's Process I said to myself "That's nice" and went on solving my puzzles the same way I always had.

My method for Soduko was to "solve" the obvious squares first, then scan the whole puzzle looking for the less-obvious relationships between the squares.  Using that rather random process I could solve many "Moderate" puzzles in ten to fifteen minutes, but I was also frequently left with puzzles that I just couldn't crack.

When I switched from paper Soduko to iPhone Soduko I initially followed my old-but-not-reliable process... but the iPhone apps features opened my eyes to "the better way".

With paper and pencil it's really messy to follow Crook's Process.  There's a lot of erasing that goes on, and it's really easy to make mistakes.  With the software version I can mark/unmark squares to my heart's content without reducing the legibility of the puzzle.  The software version also immediately flags my mistakes, so I don't multiply those mistakes by contiuing on with bad data driving my subsequent decisions.

A little bit of software can make it a lot easier to follow a process - Who would have imagined that? :-)

Even with my new found ability to make notes on the puzzle - I still stuck to my old process for the most part.  I's use my process to solve as much as I could, and then resort to Crook's process... and sure enough I would still get stuck with puzzles that I just couldn't solve.  This didn't happen often, but it happened.

I should mention that up until this time I was limiting myself to the "Moderate" puzzles on my iPhone. It's very unsatisfying to have an unsolved puzzle when my plane lands, so I stuck to the relatively easy ones for the most part.

On a recent flight I decided to tackle an "Expert" Soduko puzzle - and it was a bear.  I was so intimidated that I followed Crook's Process.  I diligently marked all the "1's", then the "2's", etc. and sure enough in 30 minutes I had solved the puzzle.  I tried again with a new puzzle, and sure enough, in 30 minutes I had solved that one too.

Since that time I have improved a bit, I'd say my average is about 25 minutes, but sure enough I can solve any puzzle as long as I keep to the process.  Just like Roberta, the puzzles aren't really puzzling anymore.  Give me 30 minutes and I will solve the puzzle.

The trade-off here is that I won't be able to solve any puzzle in less time.  The process is tedious and it's not easy to speed it up.  I sacrifice "brilliant flashes of insight" for dependable, predictable, and plodding.  The process makes Soduko boring.

As always I have to turn this experience into an analogy for the domain of Managed Business Processes:  I could have followed Crook's Soduko Solving Process all along - but a little bit of software really made the process easier to follow. Software made each step of the process easier, but it didn't force me to stick to the process - If the software had managed the process (forced me to stick to the process) I would have achieved the goal of consistently solving Soduko puzzles sooner.

You might be saying - "Yeah, but it also made it boring".

That's certainly something to consider when introducing a Managed Business Process into your organization... We don't want to turn our process participants into mindless drones.  We don't want to lessen the importance of creativity and insight - but we do need to make things more predictable and insure success.  Finding the balance between predictable process and bored employees in your organization is a puzzle that won't ever get boring.

Tips for the Business Process Developer - Process Data Perspectives

Those of us who build Managed Business Process solutions for a living have to spend a lot of time thinking about data. Our BPM suites make it a snap to define Process Flow and Routing, but we still have to make sure that each Participant in the process has access to all the data that they need to accomplish their tasks.

I always insist that folks implement their process flow first. Build a place-holder for each Activity in the process, connect them up with flow lines and any necessary Decision Gateways, and add in just enough process data and build just enough user interface to make sure that you can play back each step through every path in the process with your business folks.

Building this much of your process first has huge paybacks - There's nothing like stepping through a process to validate whether or not the business folks agree that you've got the process right. Validate the process requirements first - worry about everything else later.

Once you have this first playback of the process done you've got to turn your attention to defining the rest of the process data... and suddenly it's not as clear how to proceed. Where do you start?

The data aspects of a Process encompasses many things that you might not consider when developing other types of applications. There are several common process data patterns to consider - processes gather, transport and transform data across activities that are performed by multiple participants. Data models often dynamically evolve and transform as the process proceeds.

I've had several recent discussions with Fahad Osmani and some of my other Lombardi colleagues about how to effectively develop process data models. We've all implemented a number of managed business processes - We've all thoroughly mastered the craft of implementing processes - But we haven't really formalized our approach for designing process data models. Knowing in your gut what to do is great, but formalizing that into something that you can share with others is better.

Here's what we've come up with so far:

In every business process you've got a variety of actors with a variety of perspectives that you have to deal with - we've abstracted this into the following list:

1. Process Owners
2. Process Analysts
3. Process Participants
4. Process Builders


We've found it best to design a process data model from each perspective in this order, and then consolidate those models into a consistent unified model.

The Owner's Perspective of Process Data:

Start with the owner's perspective of process data - the folks with overarching concerns to make sure that the outcome of a process is achieved. If you're working with a Bank on a Loan Application process, these are the managers of the Loan Department who are held accountable for efficient and effective handling of the loan applications.

Owners have a business perspective on the process data. They've got the big picture business view of the process payload - What are the basic business objects that the process deals with? What data is being gathered? How is the data transformed during the process? What happens to the data when the process ends?

Owners often see process payload data as starting points and outcomes. Their major concern is with the state of the business data "now". They care about the state of the business objects when the process starts, the state of the business objects at key milestones, and the state of the business objects when the process finishes. The owner's data model provides that information.

Beyond the payload data, owners also perceive data in terms of process rules - What data determines which activities to perform? What data determines when a task is due? What data determines who should perform a task? The owner's data model answers these questions.

The Analyst's Perspective of Process Data:

Process Analysts are the folks who look at historical process metrics to figure out if the process can be tweaked to work better. In some cases the Owner may also be the Analyst - but the Analyst perspective really is different. In a Loan Application process, the analysts are the folks who evaluate the effectiveness of the process itself in the hopes it can be improved in the future.

Analysts deal with understanding the past to improve the future.

Analysts view the process data as snapshots in an album. Their view of data is intricately linked to the process diagram - The snapshots are meaningless to them unless they know where the snapshots were taken.

Analysts care about how long things take and why some things take longer than other things. Analyst care about "rework" (tasks that have to be redone). They don't really care much about what's happening now - they care about what happened over some time period. To meet the analyst's needs, process context data (and time stamps) are stored at specific points in the process. Making sure that the right snapshot is taken at the right time is their major concern. The analyst's data model works in conjunction with "snapshot events" in the process flow to capture the information the analyst needs.

The Participant's Perspective of Process Data:

Participants in the process are the folks who are tasked to perform specific tasks. Sticking with a Loan Application process, these would include the Loan Officers who review and make approval decisions about loan applications.

Participants care about now. Their perspective of process data is immediate. What forms do they need to fill out? What fields are on each form? What are the acceptable values for each field on a form? Participants view data from a task level - What information do they need to consult and what information do they need to gather and modify to accomplish their task.

Some information is passed to the participant when they are assigned a task, and some information they look up - but it's all information that is necessary to accomplish a task. Making sure that they can access data and modify the data that they need is their major concern.

One special caveat when considering the Participant's view of data is to ask whether or not any of the data that the Participant changes must be "immediately" seen by others. Data visibility requirements like this are critically important to the Process Builders.

The Builder's Perspective of Process Data:

Finally we get down to the Process Builder's view of the process data - that's us. We really can't do our work until we understand what the Owners, Analysts and Participants need.

Builders care about the actual structure of the data. What data are we going to pass around and how are we going to pass the data around? What data needs to be stored an retrieved and how are we going to store and retrieve the data? How are we going to meet the data visibility requirements?

The Owner's perspective helps the Builder define the major business objects that the process will deal with. The owner's data model also identifies the data that is used to determine which paths are taken, how long each task should take, and who should perform each task.

The Analyst's perspective helps the Builder define the data structures for the snapshots that are taken throughout the process - and informs the Builder where in the process the snapshot needs to be taken.

The Participant's perspective helps the Builder define the process payload (the data that is passed to and from tasks) and it helps them define the data system architecture that is required to retrieve and modify data within activities.

The Payoff:

The end result of this multi-perspective approach is a model for process data that just plain works.

It takes a bit more up-front effort, but you are less likely to get blind-sided by unanticipated data requirements popping up late in your development cycle. The data requirements may change, and any requirement change may still require substantial rework - but odds are the rework will be much easier for you to accomplish.

Clearly understanding requirements from the perspectives of your the process actors always pays off - and this axiom is doubly true when data is involved.

Open Source + User Builders = Great Products

I read this story over at npr.org this morning:

"Before Jonathan Kuniholm had a tour of duty in Iraq, he worked for Tackle Design, an industrial design, research and development firm. After that tour, he was missing part of his right arm — which he lost when his Marine patrol was ambushed near Haditha.

When Kuniholm returned to his design shop, he brought along three prosthetic arms given to him at Walter Reed Medical Center — the same body-operated hook many veterans have used since World War I, a shorter utility prosthetic, and a new, state-of-the-art myoelectric arm. Each one had its drawbacks — and when Kuniholm and his Tackle Design colleagues disassembled them, they quickly concluded that they could improve on the designs. They founded the Open Prosthetics Project, an open-source collaboration that makes its innovations available to anyone. And Kuniholm signed on with Revolutionizing Prosthetics, an initiative of the Defense Advanced Research Projects Agency, or DARPA."

There's an important lesson here for every company that builds products:

1. Users are a better judge of what your product should do than your developers.
   
2. Users who have the skills to build your product themselves will improve your product if given the chance.
   
3. If you don't let your User/Builders improve your product, your product won't be as good as it should be.

Viva Las Lunas!

It's taken me a few days to figure out what I wanted to write about the 40th anniversary of the moon landing... I was 12 years old - and the moon race played a very prominent role in the world view of that nerdy 12 year old.

I remember an evening shortly before "One small step" - I don't remember if they'd already landed or if it was between the touch-down landing and Neil Armstrong's famous descent of the ladder - but I was outside with my father and looking up at the moon. Tom, my father, was talking with his friend "Mr. Hahn" about the landing, and "Mr. Hahn" asked me if I was going to watch it on TV that evening.

For some reason, my response was "No". Perhaps I was just being a contrarian pre-teen, but I definitely remember him reminding me what a special occasion this was. Humans had been standing on the earth looking up at the moon in the sky for thousands of years, but never before had someone been standing on the moon looking back at the earth.

"Mr. Hahn" was a rather profane man, born into the wild-catter-oil-patch culture of West Texas and not predisposed to poetry - but he shook me out of whatever funk I was in and I went home and watched Neil and Buzz with rapt attention.

What amazes me to this day is the undeniable fact that at 12 I was already jaded by the space program before the moon's first footprint. I've been going through my stash of memorabilia weeding things out lately, and I came across a folder bulging with NASA photos and articles and sketches of my own plans for space ships. There's quite a lot of "Star Trek" along with the NASA glossy photos - obviously I was hooked on space.


When I was 9 years old, we were all going to live and work in space. The first astronauts were super-human test pilots - but that made sense. They were blazing the trail that we were all going to follow. Space was not going to be the sole domain of multi-Phd toting eggheads - "Normal people" would be there doing all the things that "normal people" do.

NASA was an agency of innovation. They were constantly unveiling new rockets, capsules, rocket planes, etc. It was always new and exciting.

Perhaps the Apollo One disaster was the beginning of my disenchantment. The inferno that killed those 3 heroes was due to sloppy workmanship, not technical complexity. Even as a 10 year old I was sickened. How could anybody associated with the space program be sloppy?

After the last moon flight it just got worse.

Skylab was a disaster on launch - Solar panels ripping off during launch due to poor construction. The shuttle - supposedly cheap and reliable - just a ticking time bomb of compromises that had more to do with keeping the money flowing to contractors than to accomplishing anything worthwhile.

NASA (the agency) has no luster left to lose - not the people. The people are great. The agency NASA should be scuttled and its responsibilities parceled out to more focussed agencies: NOAA, DARPA, DOE, etc.

My space heroes are now Elon Musk and Robert Bigelow. These guys understand that interest in space has little to do with science - it's about adventure. If it's not exciting, then why go?

NASA's plans for a moon base are about as exciting as the Antarctic Scott Base. How many people do you know who are dying to visit Scott Base? (How many have even heard of it?)

I know many people who would love to take a cruise to Antarctica to see the fjords, glaciers and penguins... but who wants to go sit in an over sized high tech igloo? Compare NASA's 2009 vision of a moon base to their 1970's vision for a space settlement and you'll see how boring the future has become.

Vegas baby... the moon doesn't need a "base", it needs a "strip". Vegas is a city that never should have been - a gaudy exciting bubble of sex, sin and gambling in the middle of absolutely nothing. If Vegas didn't cater to hedonism, there wouldn't be a Vegas.

Musk and Bigelow understand that. They're serious businessmen, and they're following the money that's available now (COTS, etc.), but I think they know that the NASA gravy-train and communication satellites are only going to take things so far. The moon's going to remain forlorn until Cirque du Sole has a lunar venue where they can perform.

40 years ago something truly amazing happened on the moon. Let's hope that 40 years from now we don't have to look back 80 years for inspiration.

Get the Words (and Notation) Right

Dan North (the chief evangelist for Behavior Driven Development) loves to say:

"Get the Words Right"

In the context of creating software if you don't know what somebody wants you to build - then you can't build it for them... That statement is true for lots of contexts but let's stick to software for the moment.

If the person who wants something built uses terms that you don't fully understand, then you'll have to translate those terms into something that you do fully understand. Translation is never perfect, so you're bound to screw up something. When you are ready to explain what you're building to the client (to confirm that you are in fact building the right thing) if you use terms that the client doesn't fully understand, then they'll have to translate your words - and they are likely to misunderstand what you're building.

Sometimes a 3rd party will be on hand who understands both the client's and the builder's terms (I do that a lot)... but then you are dependent on the translation skills of the 3rd party. The good news is that both you and the client can blame the 3rd party, but your software still stinks.

Dan's solution to that problem is to spend more time up front agreeing on a common vocabulary between builder and client... with a definite prejudice towards adopting the client's vocabulary whenever possible.

Seems pretty much like common sense, but it's very hard to actually do it.

Many programmers just don't really want to understand their client's businesses... they're excited about programming, not business. Business concerns are mundane and boring compared to the challenges that they face when creating software... in their opinion. Many business people are just as bored by technical details as programmers are by business details.

It's hard - but in truth it's the easiest way to succeed. When everyone is on the same page building projects are actually fun... and the "buildings" are really fun to "live in".

In the Business Process software domain, we have a common notation for expressing the "flow" aspects of processes - BPMN. BPMN is relatively simple to learn and it has proved to be a very effective means for Business and Programmer to communicate about the "flow" aspects of their business processes. Unfortunately, BPMN isn't good at all when communicating all of the other aspects of a business process (data requirements, routing rules, etc.) but it's a good start.

BPMN is Notation rather than words... but Dan's point is hugely relevant - you have to get the Notation right.

I've worked with BPMN for a few years, and I think the Notation has elements that just aren't right. They don't convey the meaning of the symbol to most Business people.

Here's my least favorite symbol - the Multiple Instance Activity:

When you see this symbol, you are supposed to know that many copies (instances) of this Activity will be performed at the same time. You "know" this because there are those two little parallel lines on the Activity - They're parallel to each other, so of course that means there are parallel Activities taking place.

I am not a Business person, but I doubt that many would describe Activities-That-Happen-At-The-Same-Time as parallel Activities. If someone out there knows of a study that proves me wrong, please tell me.

I think a better symbol would be something like the following:

With this symbol everyone can see at a glance that Multiple-Things-Are-Happening (hopefully at once). I'd also add some indicator of the number of "Things"... although often that's only determined when the process is running.

I suspect that the current Multi-Instance symbol was chosen because it is easy to draw by hand. Fair enough... but I find that most of my hand-drawing is done on white boards, and I almost always draw something that looks a lot more like my proposed symbol.

Fortunately, with the current state of BPMN editors it is usually pretty easy to swap out the "official" notation's symbols for your own... There are much bigger problems to solve in the realm of conveying Business Requirements to Programmers than this little icon - so please don't waste any time lobbying for it to change. I'm just using it to illustrate the point:

Words Matter - Notations Matter - Diagrams Matter

Pictures are worth a thousand words, so take the time to get the picture right before you start building your next project.

The Toilet Paper Replenishment Process

Don Norman has an excellent blog posting about the poor design of many Toilet Paper Dispensers - focusing mainly on the poor algorithms that we simple humans use when given a choice of which roll to use from a multi-roll dispenser... Multi-roll TP dispensers prove Don's thesis that many every day things just aren't designed well. I had read Don's book and seen his blog long ago, but it came back to mind when I encountered the following in a bathroom in Stanford University's Terman Engineering Building...

No less than six partial rolls of toilet paper perched on top of a standard two roll toilet paper dispenser.

Obviously Don is right about the design of the dispenser itself... Given the choice of which roll to use we'll pull sheets off each. But obviously there's something more at work here: The process for refilling the dispenser is suspect.

I suspect the process is something like the following:

Check the dispenser each day. If either of the rolls is less than 1/4 full
replace it with a full roll and place the partial roll on top of the dispenser.

The objective of this process is to make sure that there's always plenty of toilet paper available... Obviously you don't want to run out.

My guess is that the partial roll is left on the dispenser in the hopes that folks will use it - This is much better than throwing it away, and given frugal college students I'm surprised that the partials aren't disappearing.

The flaw in the process seems pretty simple... "Enough Toilet Paper on Hand" doesn't take into account the partial rolls. Instead of basing replacement on the size of the rolls installed in the dispenser, it really ought to be based on the total amount of tissue on hand - the rolls in the dispensers plus the partials.

At first glance this appears to be a classic example of mis-stating the objective of the process. The janitor who refills the dispenser has been told something like "No roll on the dispenser should be less than 1/4 full". The real objective should probably be something like "There should always be the equivalent of a full roll on hand".

Having restated the objective: What if you ended up an "equivalent full roll" made up of sixteen partial rolls? That certainly wouldn't be acceptable to most folks.



Returning to Don Norman's point - the design of the dispenser itself is really at the heart of this "process" problem. The process for refilling the dispenser is overly complex due to the poor design of the dispenser itself. Try as we might to give proper instructions to the janitor, success is going to be highly dependent on the janitor's judgement on whether or not enough toilet paper is on hand.

What can we learn from this example?

If a process that should be simple isn't, then look beyond the process definition: It may be better to buy a new dispenser than to figure out how to refill the one that you have.

---

UPDATE:

---

Prompted by the comment of a good friend and Stanford Alum I delved a bit deeper into the conundrum and sadly discovered that this is both a Process and a Design problem... In another bathroom at Stanford I discovered the following shocking sight:

The superior design of this multi-roll dispenser has been thwarted by the installation of two such dispensers... The point of the design was to eliminate choice (thus simplifying the refill process) - introducing a second dispenser nixes that advantage... and as you can see the "refill process" is still needlessly removing partial rolls.

Such a thing would never have happened at my alma matter (Rice University) ;-)

Changing planes while in the air

I fly a lot... way more than I ever thought I would... and I can say with some confidence that it's sometimes much harder to get from point A to point B than you thought it would be.

My home bases are Austin Texas and Santa Fe New Mexico, and neither is an airline "hub". Airline hubs are those wonderful airports where you can fly to and from a lot of places (non stop)... Neither Austin nor Santa Fe, as I just said, are one of those wonderful places.

Virtually every trip that I take requires changing planes. I land, scurry to another gate, and take off again. "Scurry" is often a nice way of saying "run flat out as fast as I can". For those of you who don't fly often, you may not realize that most flights board 30 minutes prior to departure, so if you think you have an hour between flights, it's really only 30 minutes... even a minor flight delay can turn "plenty of time" into a missed connection or lost baggage (if you are brave enough to check your bags).

Each trip that I take is (in a sense) a process. I fly from home to an airline hub, then I fly from that hub to another airport. On rare occasions I have to fly from the second airport to a third... You get the idea. On each flight, I am sitting along with a couple of hundred other people who are each taking part in their own similar processes. As long as all of the planes that we'll use are on time (the plane that we are on along with all the planes that we'll connect to) all of our processes will run smoothly. If the plane that we are on has mechanical difficulties and has to return to the airport, or if weather or some other obstacle keeps us from landing where we expected to, then our processes are all in a heap of trouble.




From a process design perspective the events that I have described are exceptions. We don't "expect" these things to happen, but we have to handle them if they occur. Some airlines have processes in place that work really well... other airlines... well... let's just say that I've slept on a bench in O'Hare airport and leave it at that.

Exception handling is actually pretty well understood in the realm of Process Design. With BPMN notation you can attach event handlers to Activities and model "what needs to happen" when something out-of-the-ordinary happens. Proper event handling requires a lot of thought... but in a sense it's a well understood aspect of programming that isn't specific to process engineering... and it's not really what I want to blog about today.

Let's go back to flying... This example is admittedly kind of absurd, but imagine that the airline changes their schedule while I am in the air. Let's say that the itinerary that I am on is now supposed to go from Austin to Denver to Chicago instead of from Austin to Dallas to Chicago. From now on, whenever I want to go to Chicago I will change planes in Denver instead of Dallas.

What I've described here isn't a process exception - it's a process change. The airline has changed the process of getting from Austin to Chicago.

For somebody starting a new trip, it's obvious that they will follow the steps of the new process definition. For folks who are already in the air on the first leg of the trip, there are two options:

1. Continue the following the "old" process steps until the process finishes - this depends on the airline keeping a flight from Dallas to Chicago until everyone in the air gets there.
   
2. Switch to the new process while "in-flight" - this depends on the airline re-routing the plane mid-flight to land at Denver instead of Dallas - or perhaps jumping from one plane to another as they pass each other.

Option number one is really safe. The old process is well understood and it's very clear where everyone will end up... we know we have enough gase to get to Dallas. Unfortunately continuing an old process until it is complete isn't always a viable option. Some processes take a really long time to finish, and it's unreasonable to carry on as if nothing has happened (sometimes for years) - the airline can't keep an unfilled plane waiting at Dallas.

Option number two - metaphorically changing planes while in the air - can be very risky to your in-flight process instances - the planes in the air may not have enough gas to get to the new destination, and it's quite likely that some of the passengers on the flight planned to get off the plane in Dallas. Let's not even think about jumping from one plane to another.

It's this ability to handle in-flight process changes that makes the implementation of a really good process manager difficult. Creating an "engine" that can execute a process definition is pretty straight forward... it's mostly a state machine.



Switching from one process definition to another while "in flight" can be a heap more complex...


Process improvement is a key goal of BPM adoption... When you figure out how to improve a process you want to be able to implement that change as soon as you can... but process change requires more that modelling the new process... you also really need to model the process of getting instances from the old process definition to the new.


For every possible step in the original process definition, you need to define the corresponding step in the new process.

If the correlation isn't exact (one process definition has steps that don't really exist in the other), then you must tell the process manager what to do. In some cases, an in-flight instance may need to "go back" and redo a "previous" step in the new process... or the in-flight process may have to perform some "transformation" steps before merging with the new process flow.




Unfortunately, BPM tools don't generally have explicit support for "migration" processes... it's generally left to the practitioner to figure out what to do with in-flight instances, and sometimes there's a rather painful transition when a new process definition is deployed. I'm sure this will change as BPM adoption increases, but in the mean time you'll have to build your own parachutes in case something goes wrong.