Nils proposes his rule of three boxes as a consideration when developing software or software features to improve business processes. In short, make sure that you can actually execute the new process. It isn’t enough to create a good “replacement process” – you have to be able to transition to the new process and then back out of it. The new process is plugged into a business ecosystem, and it must coexist with the existing processes.
From Nils…
Improving the process is all well and good. But this rule addresses the fact that processes don’t live on their own – there are processes that come before and that come after.
Nils presents an easy to understand diagram of the original process (A->B->C) and the end state after replacing “B” (A->B’->C).
Nils also presents four common causes of friction between the new improved process and the existing processes with which it works.
- Platform Mismatch
- Technology Change
- Unfamiliar Look and Feel
- Legacy Data Integration
From Tyner Blain
Nils uses photoshop as a great example – photoshop is easily an order of magnitude better at editing images than previous manual solutions. However, getting the image from a film negative to photoshop, and then onto paper (for use by the printer) was still hard. This slowed the growth of photoshop (or drove growth in the digital imaging and digital printing industries).
In addition to considering how best to integrate B’ with A and C, we should also consider A and C as “fair game” for re-engineering. We should consider the possibility of going from {A->B->C} to {A->D} or {D->C} or just {D}.
By keeping our requirements at the proper level of abstraction (not design and value focused), we can question the importance of replacing each element of the previous process. We can also develop an understanding of why the original process was put in place, and how best to modify it. This is a great approach when dealing with migration projects.
Another consideration is change management – what does our customer have to do when migrating from their old process to our new one? Perhaps the change management should break that transition down into stages (e.g. initial dual systems, then mixed systems, then finally a new system).
Conclusion
Make sure you’ve targeted the highest priority problems to fix. Then make sure the solution can be integrated into the existing process. Then determine how best to manage the transition of actually running the business from the old system to the new.
Scott – thanks for mentioning my “three boxes” entry. I think your abstraction of it into a reengineering exercise is excellent. Certainly any process (e.g., either “B” itself or the process it sits within “A->B->C”) are fair game for improvement.
Nils
Happy to link, Nils! Thanks for writing it – I love good ideas. They say the best ideas are the ones that, when seeing them for the first time, make you say “well, duh!”.
Scott