Leading on from the first instalment of this two-part blog on the future of optimization, PEX Network Columnist Dan Morris continues to highlight the key advances in BPM through new design and analytic and proposes a new approach.
Changes during the development
Although there will be debate of which came first, iteration or Agile, the fact is that the two are tied. The central concept is that the business will change and the old way of freezing the solution model after it is approved, until it is delivered, causes the solution to be out of sync with the real business operation and needs when it is delivered. The new iterative approach allows changes throughout the design and development with changes being reflected as they become known and accepted. The IT response to this business model iteration is to break the solution into small components and build them separately in a type of focused incremental application development called "Sprints". This can work well when the completed business design is used to direct the way the solution is divided into components and when the component construction is designed to allow them to fit back together and deliver the completed solution.
However, the problem has been context. The question is "what is the real impact of changes once the business design is divided into components?" The fact is that the changes, if isolated in a component, can still impact other components in the solution and cause a ripple of change that is seldom considered – as each component is generally viewed as being separate from the others it will link to. This can cause adjustment problems.
The way to avoid this issue is to make any changes first in the complete business model of the solution. As with any new iteration of the solution, the changed model should be run again in simulation to determine the impact and ripple of the change. This provides an opportunity to look at the changes and ensure that the way they are included in the new design will not adversely affect the overall performance of any part of the complete solution. As with any iteration, the simulation will tell you where further changes are needed, including to other parts of the new design outside of the scope of the component being changed. This will direct changes to the "Agile Sprints" being used for the creation of the IT support. In this way, "optimal" stays "optimal".
Proving Improvement
Few improvement projects can prove the real benefit of any new design – again, until it is built and put in place. However, real delivered improvement is seldom measured after the project is completed. Why? Because it has been hard to do and without a baseline, the real performance improvement is a guess.
With the approach proposed in this column that is no longer the case.
Anticipated improvement is determined by the delta between the current state simulation metrics and the future state solution that is chosen. This gives you a predicted improvement. It also tells if the performance part is really better than the old way.
Actual proof of the performance benefit will still require that the solution be constructed. However, the final "optimal" design should have the measurement of these metrics built into the workflow design along with the way performance data will be captured. In this way, the optimal state simulation model and its improvement over the "current state" operation can be easily checked and the real results in performance defined. This is also the foundation for continuous improvement performance checking – as each new improvement is based on a redesign of the last deployed improvement. Iteration of this continuous improvement design will thus follow the same iterative process as previous improvements.
However, while this will help to guarantee that the solution is optimal, it does not ensure that the delivered solution will be accepted.
While new operating design optimization is a worthy goal, the design must actually be usable and the customer must like it!
It is very possible to optimize a new design to the point that it cannot be used easily by the workforce you have. When that happens you have two choices – replace the staff or change the design. But how do you know when the optimized iterative design reaches this point?
So before the "best iterative business solution" is chosen for actual development, it should now be reviewed in a type of "paper" walkthrough with sample screen models showing reports and data capture. Using a BPMS tool, this walkthrough is straight forward. It is a series of workshops with the solution and screens projected onto a large screen. The managers and staff then walk through the work and workflow seeing each screen and the business rules that drive each activity. This walkthrough is a sample of the live final solution because the BPMS generates the applications that will be used for much of the solution, all the workflow management, and the screens that will be used. The walkthrough is thus a close version of the way the new business operation and its IT support will work.
This will provide great feedback and some interesting insights. All of this information should then go back to the design team and used to improve the "best" iteration model. Of course, the new version of the "best" iteration model should then be run in simulation and the results compared against the "best model" version to make certain the changes have not harmed the design.
Now add analytics!
Now that we know which business design is best, the questions become:
· How we can predict the real improvement?
· How can we imbed the analytics needed to prove our prediction once the solution is implemented?
Here is where Six Sigma modeling comes in. I recommend that Six Sigma based analytics be built into the workflow of the new solution as one of the last steps in the solution’s design. These performance analytics will need to be considered as the project team divides the solution into components for Agile development. This will allow the solution components to be analyzed as each is completed and again as the components are knit together to form the solution. This will be the foundation for operational performance evaluation and for a continuous improvement effort as the various analytics provideinformation for a robust business intelligence program.
In addition, if management understands how they will look at real benefit and the type of information that they will need to run the operation effectively in the future, the business analytics and the collection of the data that drives them can be built into the new operating model and the data refined as the solution is being built. This provides a type of analytics feedback loop during the design and development of the solution.
Possibly even more important, support for these analytics will provide the ability to continue monitoring the new business operation and directing its evolution over time.
Summary
When taken together, the ability to use simulation to direct iterative improvement and the use of analytics imbedded in the new solution design, puts management in direct control of the solution’s actual outcome. The overhead to the project is minimal, but there may well be resistance that will need to be overcome.
However, the advantages in time saved through iteration improvement focusing and the improvement of the iterative design process are important benefits – as are the ability to measure true operating improvement and direct continuous improvement business redesign iterations. The use of these techniques to address serious issues that we all deal with every day when redesigning a business operationcan provide significant benefits. For this reason, they should be considered as each company looks at its approach to process transformation and improvement efforts.
I would like to thank Rod Moyer and Keith Leust who are my partners in a quest for innovation in BPM. Without their experience and insight, as well as countless hours of debate and challenge to ideas, many of my columns would not be possible. As always, I welcome discussion.
Please contact me at Dan.Morris@accelare.com or call me at 630-290-4858. Also, for those who like to stay up on activity in the BPM community, I recommend that you check out Jim Sinur’s blog at https://jimsinur.blogspot.com .