The need for control - lessons from history part II

In our last installment, we drew comparisons between the current state of affairs in BPM, the relationships between IT and business operations and the ‘tick box’ approach to problems with a similar situation many of us faced during the 80s. Today we looking in more depth at how reengineering this process can produce better, longer lasting results.

"Reengineering", BPMS and Control

To a large degree, the need for formal business improvement/transformation methodologies is a result of both the movement to reengineer the business operation in the 1990s and the advent of today’s BPMS tools. Together, they changed a lot of the business operation landscape.

In the 1990s Michael Hammer picked up the improvement torch from Deming and "Business Reengineering" was created. This was actually an evolution of process performance management, but it was a good one. It refocused the way that companies looked at improvement and set the stage for BPM and BPMS acceptance.

The quest to engage business experts continued through the evolution of early modeling tools to the creation of Business Process Management Suites. These tools were basic by today’s standards but they were great at helping to redesign the business and create business change requirements. Because the redesigns defined the business requirements, they became much better. However, for a few years everyone now had problems converting business requirements to technical requirements.

With the evolution of BPMS tools, this requirements conversion issue has largely been resolved as the business requirements shown in the models are decomposed in the models to a very low level of granularity – controlled by a set of standards called BPMN (business process management notation). When data and rules are added to the models, the BPMS tools can generate the applications needed to support business activity. But while the modeling can be done by business designers, the setup of data access, links to legacy applications, and links to web sites and social media apps, still requires BPMS developers – IT staff with the right BPMS expertise. Here however there is a type of hand-off from the business designers to the BPMS developers as the models and supporting data in the BPMS are moved from business and support redesign to detailed applications design at the lower levels in the models. This forces a type of integration between the business design/requirements and the application requirements/design.

This newer technology and its integrated business / IT environment requires new design, development and deployment approaches that mix those traditionally used by business designers with those of IT developers.

Waterfall approaches and techniques work well for some things, but do not lend themselves to the flexibility and iteration of BPM and BPMS.

There are two basic approaches to design and development – Waterfall and Agile. Waterfall approaches are prescriptive and require people to move through them step by step. Agile approaches are much more free form and much more flexible.

The fact is that Waterfall approaches and techniques work well for some things, but do not lend themselves to the flexibility and iteration of BPM and BPMS. On the other hand, an Agile approach works well for the flexibility and iteration of BPM and BPMS, but it does not have the rigor or control needed by many business operation redesign projects. So, today, many BPM practitioners are beginning to merge the two and create more customized approaches.

Where are we?

Today the better methodologies follow a tool box approach. They provide a comprehensive "soup to nuts" list of organized tasks that managers can choose from in constructing a version of the method for their project and thus avoid a lot of wasted effort performing "cover your butt tasks".

We again have a situation where the tools and programming languages work, but business improvement and transformation is often marginally tied to the real business. As a result, we are seeing the delivery of projects that are technical successes but business failures. All the requirement tick boxes are checked and the applications work, but the business managers and staff are not happy with the applications or the way they force the business to change. History is repeating itself.

The issues involve inconsistent results based on approach and control issues. This brings us back to the need for methodology with built in governance. Experience has shown that is the only way to deliver expected results consistently. It is the only way to deal with the fact that different project managers will have different experiences and different levels of knowledge on how to actually improve or transform operations.

However, unlike with the monolithic methodologies of the past, the better modern methodologies have become less prescriptive and much more flexible. Today the better methodologies follow a tool box approach. They provide a comprehensive "soup to nuts" list of organized tasks that managers can choose from in constructing a version of the method for their project and thus avoid a lot of wasted effort performing "cover your butt tasks". In addition, the ones that blend waterfall and agile concepts allow managers to better govern the iterations and simulations of BPM and support both new business change and improvement to the current operation.

Fortunately, today better methodologies allow companies to identify a core set of activities that will be used by all projects and then add to the core only what is needed to control the project and ensure that it follows the right approach using common techniques the same way all the other teams use them.

I obviously believe strongly in comprehensive business oriented BPM methodologies. I consider them to be even more important than the technically oriented ones the BPMS vendors can provide. But the real magic in success consistency happens when you blend the two types – business transformation (BPM) with BPMS tool specific methods. Then you get the advantage of optimizing the business operation with the best ways of using the BPMS tools to support the new business design. In this mix of approaches, you should also get the advantage of being able to show the level and type of business managers and SME support that is needed, why it is needed, and when it is needed.

Takeaways

BPMS and other IT technology works! There are thousands of successful applications built with any technology you can think of. But there are also challenges related to background, understanding of BPM and BPMS, the current IT environment and more, that introduce inconsistency into the creation of any solution in business transformation or improvement.

How well a solution fits the business needs is up to the business – not IT or compliance or finance or anyone else. It is the responsibility of the business manager to provide the time and talent needed to deliver the necessary results and optimize the solution.

I believe that the solution used in IT in the 1980s to provide outcome consistency is again needed for both the business redesign and application sides of creating an optimal business operation. That is a comprehensive methodology. However, now with BPM and BPMS and the integration that these provide, it is necessary to blend IT related and business transformation related methods to deliver control, ensure involvement, and provide consistently successful outcomes.

As always I am interested in your thoughts and comments. Please write me at daniel.morris@wendan-consulting.com.