Passports to Success in BPM24th of October 2015The latest in the series of books about Business Process Management, published by Future Strategies, is once again a collection of white papers submitted by several eminences of the BPM world. Not in the least you will find papers by Keith Swenson, Nathaniel Palmer and Lloyd Dugan, all of which I can only advise you add to your Twitter feeds to follow. A nice feature Future Strategies has added to their books is the Bitlit app they provide, which allows you to retrieve a digital version of the book you just purchased, thus giving you the possibility to have the information contained in the book within your grasp at all times. The book is divided into two sections: "Understanding BPM" and "Using BPM". While the former writes out a more academic approach on BPM, applying structures and listing best practices, derived from the experience of the author, the latter section lists several success stories of BPM initiatives all around the world. For me, the academic essays are usually more informative than the customer cases, as they are more structured in their descriptions. |
 |
The first bit of information found in the foreword of the book is a definition for the BPM discipline, stating:
To me, this definition feels a bit too much as a compromise of sorts. It’s like a hundred gurus of BPM have been asked what their definition is, and from those definitions a union was made that contains all elements raised by these esteemed individuals. This definition tries cramming every bit of knowledge in the discipline into a single unified theory, and ends up being too broad and generic for my tastes. If I want to use this theory to verify whether any activity in a transformational project (for example an IT development project) is part of this discipline, I feel the answer would always be “yes”. The scope of the discipline has become almost all encompassing with this definition.
First paper of the first section by Peter Schoof of BPM.com fame delves into why BPM initiatives seem to fail so often for the same reasons. Most of his pitfalls either reiterate those found in the CHAOS report by the Standish Group in 2009, or in the Gartner report on pitfalls. He does add a significant new pitfalls to this list: “Don’t treat BPM as a project”. In which he means that a BPM initiative should not be finite, as a project approach would suggest. For this, we should always envision continuity of the BPM effort after the project introducing or elaborating on the discipline has ended. One of the ways such a continuity could be taken up is the emergence of a Centre of Excellence, either as part of an existing structure such as a PMO, or as an independent entity.
Next up is the BPM Success Manifesto by Nathaniel Palmer. The paper starts off with a bit of a rehash of BPM history, and leading up to the iBPMS architecture. From there on, the paper explores more of the current influences, such as Social Media (being one of Gartner’s Nexus of Forces), where he indicates that for Social Media to influence and drive your process optimization effort, you need to embrace the two factors governing over it, namely trust and reputation. On Social Media you select your network not on experience or firsthand knowledge, but rather on these principles. Much as the grain trade in ancient Rome, when information on a product can’t travel faster than the actual product, trust becomes key in managing such flows. This leads to him determining three forms of social interaction:
- Social Modeling: let the process modeling and discovery in your organisation be led by social media conventions
- Social Collaboration: using internal social networks to create virtual teams around activities and efforts
- Social Chatter: the Big Data of capturing social events and processing them to use as input for business determinations, and goal driven activities
Finally, a good read is offered on why Enterprise Content Management (ECM), and in extension Enterprise Information Management (EIM) as a parent category, has a strong synergy with the BPM discipline, and as such can be easily used as a sort of a gateway drug to the BPM stuff. Where the ECM layer adheres to the already 40 year old idea in IT of abstracting data from the applications where it is treated, this can easily be expanded into the concept of abstracting process flows and business logic using the BPMS layer.
| ECM and Workflow | BPM and ACM | |
|---|---|---|
| Scope | Single application, document or form; data and object model specific to application or document; not shared | Common UI and transactional thread spanning multiple applications and process lifecycle; data structures based on process definition (or process instance data) and separate from payloads or applications where the work is performed |
| Security | Application-specific, or authorization based on document-specific or form-specific processes | Bound to roles defined by swimlanes and the activities they contain; Role Based Access Control (RBAC) applied to case folder, content or fine-grained control of work items |
| Analytics | Work item specific reporting, limited to a single document, repository, or application | Advanced analytics enable identification and reuse of patterns and exceptions, and operational visibility |
| Data Integration | Visualisation and manipulation of data through forms or application-specific data fields, and not accessible as a shared service | Connectors to integrate external data into the case folder of process instance. Manipulations of the data through external services |
Final pearl of wisdom in this paper is the 90 day plan to getting started with BPM in an organization. The first 30 days will be needed to define a starting point by defining the core goals, deliverables, and assets in collaboration with the stakeholders to determine the scope and boundaries of the plan. This will also give an indication of whether you will “go live” after 90 days, or will simply deliver some proofs of concept. The next 30 days will be spent devising the narrative of the processes, their look and feel, through a series of workshops. The final 30 days will come with the task of defining the measuring points of the newly formulated processes in order to secure buy in from senior management to extend the exercise to more processes. Similar to the Oracle Reference Architecture approach of securing strategic buy in through the tactical approach of demonstration through low hanging fruits.
Next up, we get an evaluation of BPM initiatives towards fulfilling strategic objectives by Charles Farina, of Essroc Cement Corp. The questions he raises and the results (towards customers as well as senior management) he positions as important, lead up to the need for strategic alignment. Beating a dead horse a bit, as almost all customer cases list senior management involvement as a possible pitfall, stating we need to make sure our process development and improvement serve the direction the company is taking in its industry. A top-down direction derived from a management philosophy should shape the business model and trickle down into methodology, which is in term supported by tools. The higher in this top-down approach you integrate a BPM initiative, the more effective it will be. A particular tool to support this exercise will be Kaplan’s Strategy Map, as shown in the example (taken from the PureStonePartners LLC) below.
Pedro Robledo of BPMteca.com writes about the Digital Enterprise, which is defined by Gartner as an enterprise engaging in Digital Business, the creation of new business designs through blurring the digital and physical world. In essence, it promises to create a convergence between people, business and things (as in physical objects). This new wave in IT disrupts regular business modules with the Nexus Forces, as referenced earlier on in this review, as well as adding the Internet of Things as a fifth force. Examples of goals being set to achieve innovation are “End-to-end business processes, based on collaboration and real-time KPIs”, “360° customer unlimited information in real time”, “Personalized Market Strategies” and the like. If done correctly, this will leverage operational effectiveness, operational efficiency, operational excellence, operational success and an overall operational strategy. For me, this white paper was one of the weaker elements in the book, as It depicts in very broad strokes an unachievable ideal for which to strive, but doesn’t really elaborate on how to go about it.
Proceeding on to the white paper of Llyod Dugan, we get an exposé on how to link our BPM initiatives to business architecture (BA). Raising the argumentation that too often, we see that these types of
initiatives are relegated to the use of BPMS components as automation platforms, he states a need for a BPM 2.0 where we reconcile both disciplines. He reiterates the OMG definition for business architecture:
Dugan clarifies BA as an exercise to flesh out the various concerns (for example in the form of the six honest men) of the business using a defined framework. I find within my own experience this view on BA very similar, as where I tackle this type of architecture more from these concerns:
- A canonical data model (and its links to industry standard ontologies) and related information management strategy
- A description of the business processes (using BPMN, XPDL, or similar models), organized in process maps representing the value chains and distribution channels, and indicating the organization’s value proposition
- An organizational structure (as well as enterprise-wide security role structure)
- A positioning of the organization in its market segment
- A description of the business rules and policies (using for example OMG’s DMN)
He also specifies which elements should always be described when process modeling, independent of which framework or methodology is employed:
- Span of Control: a controlling context governing or enforcing the flow of the process (such as a pool in the BPMN syntax)
- Decomposition: essentially a decomposition of spans of control (translating in subprocesses for BPMN)
- Triggers and End States: How a process is started and how it ends.
- Exchange Interfaces: How a process interacts with the environments in which it is executed.
In summary, BA gives a BPM initiative the architectural context BPM needs to be effective as a way for achieving process improvement. In return BPM lends BA the process understanding needed to be effective in planning strategic initiatives.
Frank F. Kowalsky takes us on the journey of identifying those processes worthy of improvement through analytics. He breaks BPM down to 4 components: the processes themselves, a methodology to build/change them,
a body of knowledge about processes, and a management approach to treat them as assets. In order to take analytics past its use as a ranking approach for processes, we need to try and leverage it as a technique
for determining alternatives for process improvement, improvement impact analysis, diagnostic and prescriptive analytics, and predictive capabilities. In order to do this, the author suggests using the risk
versus yield approach.
The yield factor can be calculated using basic metrics and weighing them according to their significance for the improvement initiatives at the enterprise. These metrics are: cycle time, wait time, transport
time (time between steps of processes), process cycle efficiency (or pure work time), error rate, throughput and cost. The linking of risk and yield has to happen in different contexts to have a proper overview.
Once again, these are very much enterprise specific, but as a guideline, some generic contexts are specified: Documents, Technology, Locations, Organizations, relation to other processes… Quantifying the risk
in each of these contexts, gives a clear picture of how the risk is experienced within the enterprise as a whole. Matching these two quantifications gives us a quadrant, and identifies the processes worth
our consideration.
Last of the white papers is a collaboration between Professor Mark von Rosing, Maria Hove and Henrik von Scheel. It is a prelude to the second section of the book, and informs the reader how to read customer cases and in which context each of these should be placed. The view to take on the cases is to learn other people’s way of thinking, way of working, way of modeling, way of implementation, way of governance and way of change. In short, the white paper encourages us to really place yourself in the shoes of the author, divine the purpose of the case presented, identify the expectations of what the initiative was working with, find the central issue that became the lynchpin of the case, determine whether a top-down or bottom-up approach was taken, and understand the solution the case has found for its problems encountered. Last we, as the reader of the case, should take note of which measurements and scorecards were employed.
Once we get into the second section of the book, it loses some of the interest I have in it. Having read multiple books of Future Strategies containing a host of customer cases, most of the pitfalls and best practices raised in these cases, are not really shocking to me. If this is your first time reading one of their books, these cases become a lot more valuable to process. One of the more unusual key improvements mentioned, is to strive for the reduction in internal and external audit finds. One of the more unusual best practices is that analysts should learn the limitations of the BPMS early on in the initiative to limit rework of processes during the implementation.
| Review | BPM | ACM | EIM |