Most people who are involved in business redesign, BPMS (business process management suite) modeling or application generation know the wonders and horrors of design iteration. The wonder is that you can version the designs and keep trying new changes. This holds true for both business operation designs and the application designs in the final "solution" design.
Now for the horror that iterations cause! Have you ever had to deal with unending iterations for a business design or a solution design? The concept behind this is that you can continue to prototype a design until it can deliver what you want it to. Theoretically this reduces up front design time and produces a much better solution. In theory this is great. But in practice, not so much.
In the early days of BPM I have to confess to drinkingthe Kool Aid and all was well. Then it wore off as my teams and I had to actually deliver improvements to companies. The ability to iterate is great – a major step forward. However, it is only a part of the foundation needed to evolve a business operation and its support rapidly, with low cost and low risk.
The problem is that iteration can quickly get out of control. Too often we find that people will actually over analyze problems, fretting over small things that really don’t make a difference. With iteration, we risk getting trapped in this analysis "pit" and iterating until we think we have achieved a 99.99999% solution. This investment in perfection can distract BPM professionals from their mission of ‘solving’ the business problem quickly, efficiently, and with low risk and cost.
Note: We believe that it is impossible to reach a perfect solution to any problem because the business operation and competitive environment will have changed by the time the analysis is deemed complete. Iteration when controlled and supported by BPMS enabled BPM can go a long way to addressing this, but the BPM team can easily fall into the unending iteration trap of diminishing return on effort.
This is a major issue with BPMS enabled BPM and Agile. Both are centered on the iteration concept and both often fail to really control it properly. The result is that both are often plagued with unending iteration. This trap occurs largely because there is no real way of knowing if any change from a past iteration really improved the outcome of the design. So people really take informed guesses at exactly where processes (or at a lower level of detail, workflows in business areas) have issues and what will correct or mitigate them. The same is true for the possible impact of the change.
The result is that many BPM projects simply seem to never deliver anything in a timely manner. The iterations simply go on and on until someone declares the design to be good enough. Here unfortunately, the declaration has to be based on a good enough estimation because no one can accurately predict the real outcome of the solution. This is equally true on the business design side and the application operation on the IT solution side.
Controlling iteration to improve results
The biggest issue however is not the ability to iterate – nor is it related to BPMS tool capability or application generation weaknesses. There are examples of significant successes – but there are also a lot of design and iteration problems that these successes needed to overcome.
The biggest problem in my opinion is that no one knows the real result of changes to any iteration’s design at any point in the BPM project. No one knows if a problem has really been fixed or a saving will really be realized. The reason is because there has been no way to look at the impact of the changes to the design in any iteration and then use that impact to drive further improvement in the next iteration. The reality is that the designs were declared good enough and the solutions teams then given requirements based on these designs. Once given these requirements, the IT side of the BPMS use began – applications were generated, interfaces were built, additional applications were built, and legacy applications were changed. At this point, the combined business side team and IT team could finally see what they really had and how it really worked. Fortunately for many years improvements were fairly obvious and benefits were realized. But the solutions were often imperfect and the iteration game continued as further improvements were needed.
But there is a better way. Today with iBPM and with separate simulation and analytics engines that link to tools like Visio, we can add design operation simulation to our bag of tricks. This is a real game changer – but it is also largely unrecognized.
The fact is that when you create a current state model you can add the collection of the data needed to drive a simulation of the workflow to your discovery process. The good news here is that most operations today need to report on a wide variety of information for performance management. This means that much of the data you will need to drive the simulation exists – it is simply not currently organized in a way that makes it easy to use to drive simulation.
However, where there are holes in the available data, you can work with the business managers to start with estimates and then implement measurements to collect any additional data you cannot obtain from existing sources. Will this immediately give you accurate data? No! Will this give you a good start to build from as time passes and more data iscollected? YES!
With the ability to import business and application models, and basic data, you can now run a baseline current state operating model in simulation and find bottlenecks, work problems and much more. You can check this model with the business manager and users and make any needed changes to the current state model simulation information and run it again. This may take a couple of passes or iterations, but each will be narrowly focused on correcting specific issues.
The project team can now take the business requirements (from the project request) and begin a future state design. After the team believes they have fulfilled the requirements they can then run the design through the simulation tool and find flaws, inefficiencies, etc.
The current state simulation can then serve as a baseline operation efficiency model. By comparing any iteration’s operating simulation against this baseline, a BPM project team can now start to accurately determine any improvement over the last iteration’s design and its impact on the operation. With this foundation, the team can identify persistent issues and focus on their resolution.
This allows the team to focus on the issues in the last iteration and make improvements. The design is solid when the simulation cannot find any real issues with the flow or decisions. At this point the team has a good new design. But the design can still be improved quickly by working with the business manager to see how the design will function under anticipated stresses – like peak periods and sales growth. This becomes a final set of simulation supported design iterations.
The result is a really solid design – that can be justified and proven. It also provides a design that will produce good detailed business requirements. That itself would make this worthwhile. The simulation driven iteration approach provides optimal work and workflow models.
Simulation modeling – new to many
However, simulation and its use is a new concept in many organizations. My goal in this column is open readers to the concepts of using simulation to focus iteration design changes and proving the quality of a design – before it is built.
To move into simulation you will need to first identify the simulation tool you want to use. It is worth the time to learn about these tools and what they can do – each works a little differently once you get beyond some common basics. Some of these tools are offered by vendors as standalone products and some are modules that can be included in a BPMS license.
I recommend that you first identify what these tools can do and how they work. Then leverage that knowledge to determine how you want to use this type of tool and what it will be required to support. This gives you a laundry list of requirements for the vendor. Then join with IT to do a vendor study and tool selection – unless your company already has a good tool that is up to date or you have one in your BPMS tools.
These tool options will allow you to move into the best tool for your use. This will let you move into the level of simulation supported design evaluation you want for a very low investment (some simulation tools are as low as $5,000 per "seat" per year).
If it’s worth doing it’s worth doing right
I firmly believe that if you are going to do something you need to do it the right way and you need to commit to giving it every chance to succeed. You also need to be creative in how you do things or apply concepts or tools. This is true with any move to simulation driven design iteration. These factors are also part of the fundamental BPM foundation.
Iteration was adopted to allow a type of evolving prototyping that supports constant business change through the solution development process and allows the design to be flexible. Great stuff and needed. But a part of the ability to really do this in an effective and efficient manner had eluded most of us – until now, leveraging simulation engines.
This capability now allows us to test the operational aspects of any design quickly and know when we have reached a good, effective, and efficient new operating design.
This represents a small tool investment, a training investment, and a commitment to integrate simulation into the approach used to design business changes.
Need to build it to try it
The key problem in creating BPM solutions in the past is that the solution needed to be completely built before it could be evaluated. And, unless performance measurement was built into the applications, there was no way you could prove any benefit beyond staff reduction.
Clearly this was not an optimal situation. Today we can prove the benefit of a new business design through simulation. We can know if a business design and its supporting BPMS generated applications will function properly without a significant investment. But we still cannot predict if the solution will deliver project targets in a way that streamlines the business operation and reduces cost.
For this part, I would like you to consider an old application testing technique and apply it here. This is to build small programs that either pass data or take it from the solution programs. The "drivers" pass data in predefined formats with values in and out of limits. The "stubs" take data from different points in the generated programs and test it to make certain it is good. These are small programs that can be reused with minor changes.
Applying this approach to BPMS generated applications and using a minimal amount of data copied from the company’s live data stream, the ability of the solution to deliver the performance goals of the project can be tested. Using performance measurement that should be built into the new business design, the results of the new solution can be tested and the measurement formula can be improved. At this point any problems would be spotted and the "future state" models that were used to generate the solution can be iterated – focusing on specific corrections needed to deliver the target outcomes. This is a recycled old programmer’s trick from years ago, that is applicable for this purpose because the BPMS generated the core applications largely from models and rules.
However, the goal here is to test the solution and iterate it before a lot of manual programming effort has been invested. That is not to say that no effort will have been expended to support the BPMS application generation capability. It is just that stopping here and iterating through focused improvements/changes/reduces and possibly eliminatingthe need to take several passes at changing interfaces, data needs, etc., as the future state design models are iterated once again to improve the actual applications and other supporting technical considerations that will support the new design.
I hope that you will think about this approach. It is fundamental to actually leveraging the iBPM concept and providing improved designs and solutions. I welcome a chance to discuss this approach and encourage you to call me at 630-290-4858 or email me at Dan.Morris@wendan-consulting.com.