Sourcing Shangri-La

The Process SOP Blues

It seems very odd at first. Why should Life Sciences organizations be so resistant to a change that is so self-evidently valuable? Why push back on something that makes things better, faster and cheaper? 

Standard Operating Procedures (SOP) are the basic building block of Life Sciences organizations. Almost always simply a library of lengthy documents, SOPs set out how the organization understands what it does; how it assures itself and its clients and its regulators that it is following Good Practice.

Even in the best managed Pharma organizations, the costs of compliance can be 16% of operating costs; more typically, they will be 20%+ and may even be towards 30% of operating costs.

So - if there was a better way of managing SOPs, how can there be such indifference? How could smart people be so unenthusiastic about a new way of working that would, say, make clinical trials safer while, at the same time, reducing their cost?

At the European SOP conference yesterday, the evidence from several speakers - none of them linked to Nimbus - was compelling: in many ways, some serious, SOPs don't work:

Susan Ollier from QED Clinical Services noted that SOPs may be missing, or contradictory, or out-of-date or uncontrolled. 

Steve Nicholas from PharmaAcademy presented supporting evidence from the UK's MHRA regulator. He went on to point out that the SOP document fails because is written to meet two mutually incompatible objectives. SOPs are supposed to be concise and easily understood (to support the process user), while at the same time being an exhaustive training document for a new starter with no experience. 

Gareth Turner from PAREXEL noted that 'a lot of what we do is actually quite simple. We've just created a way of making it extraordinarily complex. We need to get back to simplicity.' 

The answer, the future for SOPs that was served up in different ways by different speakers, is to adopt a process-based approach. 

Going beyond document-based SOPs to thinking in terms of end-to-end process can offer huge advantages. It's the kind that would grab any CEO's attention:  

Risk Management - it exposes the gaps and the overlaps that arise from silo-based SOPs. It also provides a comprehensive framework for managing outsourced activities. 

Productivity- it makes work easier. Storyboards deliver content, in an easily digestible format, through a personalized intelligent operations manual.  And it enables more extensive, and successful, automation.

Governance - it brings together Quality, the QMS and all compliance activities into an integrated management platform.  

Performance Improvement - it connects SOPs with KPI metrics.  It integrates Quality and compliance with Lean, Six Sigma and other performance improvement programs.

At the Nimbus Inspiring Performance 2011 conference, Novartis shared a brilliant example of an organization that is forging this future, leveraging Nimbus Control to create a smart, holistic perspective on its clinical trials programs.  

So WHY is the progress towards process-based SOPs so incredibly slow? It's a question I've never satisfactorily answered until yesterday when the penny dropped. I realised that people's resistance to a process perspective is not job-protection or an inability to think creatively.  It's because whenever they are shown process (and we saw many examples of this yesterday) it looks awful.

They know process as swimlanes, pools and numerous symbols (ie the language of BPMN). They see it as technical, in the IT domain, with no sense of design.  They see governance processes separate from operational processes. They see process as bottom-up fragments of understanding. So process for them is a loaded and negative term. Presented like this, who would want to use it? It's really no surprise that they push back and switch off.  

I wasn't the only one bored, I think. I found this rap on a scrap of paper as I left the conference:

 

 

Related Posts

05 Apr 2011    Integrated Compliance Cuts Operating Costs By 9%

11 Aug 2011    Why Management 2.0 Will Be Built Upon BPM

  

The Language of 'Social Business'

Good to see Esteban Kolsky nail an essential truth in his post today The Confusing World of Social Business over on the influential Enterprise Irregulars blog:

 

"The label social is not good.  It does no justice to what we are doing.  This is not about being social; this is about creating collaborative platforms for users and organizations to co-create value. The whole purpose to “being social” is to collaborate."

He's on the money. Beneath the UX wizardry, 'social business' is about wider and more effective collaboration.

And, most often, the language that enables that enhanced collaboration is process.  Complete end-to-end processes, presented graphically and personalized, and, above all, designed to help people get real work done. 

Blend that with social media, add in governance et voilá - the recipe for sustainable transformation and continuous improvement. Both within the enterprise and across its extended supply chain and eco-system. 

[Worth noting of course  that some variants of the process language are not widely spoken outside the CIO's shop. Regional dialects such as BPMN or UML, for instance, have a purpose - but they are too complex and demanding to work as the language of the collaborative enterprise.]

Related Posts

21 Jun 2011    Real-Time Process Governance

04 Jan 2011    BPM In 2011: Truths We Hold Self-Evident

 

Understanding Process: More on Orchestral Scores

Let's not go overboard on swimlanes [groan] but please allow me one brief follow-up to my colleague's insights on how the orchestral score illustrates the genius of the Nimbus Storyboard and the limitations of swimlanes.  

The orchestral score solves a problem that is similar to the problem of how to represent business process.  

The score provides a common language that enables a wide range of instruments working together in real time to create the musical effect that reflects the intentions of the composer and delights the audience. 

Process provides a common language that enables people working together in real time to create products that reflect the intentions of the corporate strategy and delight the customer.

But it's a even richer metaphor than that [and I'd be delighted to publish here your own inspirations on this theme].  I've used the example of the orchestral score as a way of making a different point: about the importance of version control and the value of having a single source of truth, in this article published last summer, which you might find amusing:

The lights dimmed, the audience quieted in response — and you step towards the rostrum. It was an extraordinary honor for you, an amateur conductor and a 'mere' business CEO, to be invited to do a cameo with the Vienna Philharmonic.

It was a simple piece, of course, an early Mozart piano concerto, featuring a young Chinese pianist. But snow at O’Hare had cancelled two days of flights, so there had been no time for any rehearsals at all. Gulp — you lift the white baton to gather the orchestra. It was now or never. Hell, this was more nerve-wracking than any investor presentation.

But really, what could go wrong? You knew the piece intimately. You had even conducted it before. And the Vienna Philharmonic musicians were among the world’s finest. So relax and enjoy.

It was in the second bar when you realized something was awry. The orchestra was going faster than you’d ever imagined.

It came crashing into your head that they were using the revised October 1782 score, while you had the original September 1781 score in front of you. Never mind — maybe you could still get through this.

The orchestra built raggedly toward the entry of the soloist, their eyes looking at you in increasing bewilderment, wondering why your arms were off-beat.

You turned to introduce the pianist. She played from memory, of course. It was half a bar later that you realized that she was performing Mozart’s later revision of this work — his January 1783 score, which was much the same, except for the revised timpani line.

The music careered along, jumping and spluttering like a car with water in the tank. Maybe it was OK for an amateur — you might just make it to the end.

But not much can survive when the timpanist is confused. The cacophony grew. Only true grit could save the day. You waved and pummeled the air, and pulled them through into the final bar — and silence.

First one clap, then another, then spreading around the hall — until, finally, tumultuous applause. You bowed, amazed, and left the podium.

In the wings, you overheard a radio presenter gushing into his microphone: “A stunning new interpretation of Mozart in the style of Philip Glass, the radical American minimalist composer…”

A miraculous survival — again. Yet as you headed back for a final bow — and definitely no encore — your thoughts turned inexplicably to work.

How well were your own teams performing? Weren't similarly talented heroics required far too often, because everyone had a slightly different view of the playbook? How much better could your company be if your people’s skills were better orchestrated?

But you had just put a process improvement project on the back burner. It hadn't seemed that important to get globally consistent processes and documents delivered real-time to all staff.

As you bowed before the tumultuous applause, you vowed to give it the attention it deserved. Hey, you might even get the Europeans onto the same page, at last.

~ reprinted with permission, the IT Cutter Journal, May 2010

Related Posts

1 Feb 2011    Swimlanes and Storyboards

 

The Tube Map: Process Made Easy

Hat tip to Adam Deane for another entertaining post today BPM: Mind The Gap , on the London Tube map and BPM process maps.

It's a helpful analogy, and deserves to be taken a stage further. 

The Tube map that we know and love is a simplified representation that works for us as passengers or end users. 

Behind the scenes, London Underground has all sorts of 'map' representations of its network - rail engineering maps, electrical engineering maps, signalling maps and geographical maps.  There is even a temperature map. Each map is different because it serves a different purpose. 

But the Tube map and all of LU's internal maps relate to the one operational reality. They are multiple integrated views of one reality. 

In the corporate world, end users need simplified representations of process.  They need process to be as simple as the Tube map.

Behind the scenes, and especially in IT, there may be all sorts of process maps in different formats to meet the needs of enterprise architects, Lean and Six Sigma teams, system testing teams, risk and compliance teams. 

What matters is that, wherever they may be, all these process maps are multiple integrated views of one operational reality.

It's the integration that's crucial - it's at the core of BPM 2.0 thinking. It's why the integration of Nimbus Control (the business operational perspective) with SAP Solution Manager (the IT perspective) is so significant. It's a sign of where the future lies. It has to be the foundation of sustainable operational excellence.

The reality of business process is that most organizations have very incomplete and multiple views, that are not integrated and in a variety of formats. They are also often out of date. And they are especially hazy when it comes to the extended enterprise, to activities that are outsourced.

Which is like London Underground using different and unrelated maps, in different formats, for its engineering and signalling teams, and with quite a lot of the stations and lines missing.

Even worse, the process equivalent of the Tube map often looks like gobbledegook.  Small wonder that end users ignore it in favor of asking a mate if they can help. 

The future is not just Tube map thinking to support process end users and other stakeholders. It's about higher levels of personalization as well - so that I get process as I need it, in the form and language that I need it, on the device that I need it, and wrapped around all that I need to do my job well.   

In exactly the same way that the Tube map is increasingly personalized and interactive: stepfree maps for wheeelchair users, maps for riverboat users and cycle hirers, multilingual maps for visitors, Zone 1 maps for central London passengers - even a Tube map optimized for the iPad.

Related posts:

8 Nov 2010        BPM 2.0 on a Napkin

11 Dec 2009        Rethinking BPM as SatNav for the Enterprise 

'Final Touches: BPMN Silk Purse Almost Ready'

Before I come to the defence of Jim Sinur, let me tip my hat to Bruce Silver, the man of the moment, who sometimes, it seems, is single-handedly labouring to make something from the sow's ear that is the OMG's spec for BPMN 2.0 .

Bruce yesterday published  The Rules of BPMN, a list of 62 rules which, as he explains in his accompanying note Following The Rules, are needed because  

"The BPMN spec does not enumerate its rules.  They are in there, but buried in the narrative of a 516-page specification in combination with some UML class diagrams and an XML schema.  And sometimes those three sources don’t precisely agree with each other.  There should be an appendix that simply lists the rules, in plain English and in a way that is easily computable by any tool.  But there isn’t."

Bruce includes 30 rules relating to method and style that are essential to create 'good BPMN':

"My purpose is creating non-executable models in which the diagrams stand on their own, clear and complete, shareable across the business (to those that understand the rules) and between business and IT."

Leaving for another day the merits of The Rules, it's the last part of that sentence that I have to take issue with:  The idea that 'BPMN is shareable across the business, and between the business and IT'.  For Bruce and many others it's an accepted truth - but in reality it's a delusion.  It's a diversion from what's really required.

In his post this week, Bruce describes as 'fatuous' Jim Sinur's post on BPMN last month, where Jim wrote about the limitations of BPMN outside of IT:

"BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark."

Jim got flamed for his comments - 'Apparently BPMN is Too Hard!' - though there was some significant support as well. [All admirably summed up by Sandy Kemsley in The Great BPMN Debate 2010]   

Anyway, back to to Bruce's post earlier this week, describing how 'cooler heads walked Jim back off the ledge'.  Bruce, who must be the global market leader in BPMN training by a long way, and claims to have seen more 'bad BPMN' than anyone on the planet, goes on to write about the difficulties of creating 'good BPMN' in a way that illustrates the reservations that Jim and others are expressing: 

"Creating good BPMN is often more difficult for architects and developers than for business people.  It has nothing to do with BPMN 2.0 vs BPMN 1.x.  And it’s not about the unwieldy BPMN vocabulary of event and gateway types.  As others have pointed out, we already have a limited working set of shapes and symbols in the Descriptive process modeling subclass, and tools like IBM Lombardi Blueprint have an even more limited palette than that.  Trust me, you can create bad BPMN with nothing more than tasks, XOR gateways, and None start and end events."

"To create good BPMN, you need to follow the rules.  It’s not really hard to do, and it’s a readily learnable skill.  Still, for some experienced modelers that’s a problem, since they’ve already made up their own rules and prefer to follow those.  The real problem is knowing what the rules are!"

I'm with Jim. There's nothing wrong with BPMN.  Maybe it's better than ARIS EPC and other competing notations - I'm not qualified to say. And maybe Bruce's Rules are exactly right. But I do know that BPMN is fatally flawed as a universal process language across the enterprise.

Process owners and other business stakeholders will be baffled by it eg (just look at this recently published example of a BPMN 2.0 'collaboration diagram' in healthcare).   The idea that process stakeholders will step up to the mark and design processes in 'good BPMN' is the triumph of hope over experience.  Here's just four of Bruce's BPMN Rules, the ones that business users are expected to understand, by way of illustration that no way is this the language of the business:

• BPMN 0138.  An event gateway must have either a catching intermediate event or Receive task on each gate.
• BPMN 0202.  A sequence flow cannot cross a pool or subprocess boundary.
• BPMN 0203.  A conditional sequence flow cannot be used if there is only one sequence flow out of the element.
• BPMN 0204.  Sequence flow out of a parallel gateway cannot be conditional.

Equally important, BPMN is not a language that can be deployed to desktops across the enterprise.  It's not for business end users or process executors.  They want easy access to a single source of truth, to get quickly to the process or storyboard that tells them what to do.   BPMN just can't do that.

Anyway, time for the olive branch. These BPMN skirmishes are a diversion.  We need a truce and agreement on a process management framework that meets the needs of the enterprise.  As I've written elsewhere, we need to recognize the validity of the two perspectives - IT and business - but synchronise them to create a complete framework for collaboration on transformation and continuous improvement.  And I'll happily concede that BPMN may well be the best choice for the IT perspective.

Related post:

27 July 2010  The Language of Process As A Strategic Issue

 

The Language Of Process As A Strategic Issue

It sounds high-falutin' to say it, but everything that I'm seeing suggests that an organization's approach to the language of process modelling is a strategic decision. And it's a neglected area where savvy CIO leadership can pay huge dividends for the enterprise.

Until recently, an organization's choice of process modelling tool effectively dictated its choice of process modelling language.  If you used ARIS, you adopted the EPC process language. But things are changing: both Nimbus Control and ARIS, and many other tools, now support in addition the use of the BPMN process language, for instance. 

Most organizations are asleep. Their typical 'choice' is to let people do their own thing. If Steve and the Lean team like Visio, and Carmen and the Finance Transformation progam prefer Powerpoint, and IT like everything in Casewise, that's not a problem, it's just inevitable - as they see it. These organizations simply don't realize the possibility of a common process language, let alone its strategic value.

More advanced, more process-aware, organizations may recognise the value of a common process language.  But often they can only forge a limited consensus, especially across the Business:IT divide.

Leaders in this area, on the other hand, think hard about the language of process in their organizations.  They know that sustained continuous excellence is based upon a process awareness, a process intelligence, that permeates their culture from the board room to the shopfloor. And if process is to be their universal language, then their choice of process language matters.

So what is the right process language? For most organizations, the focus will be on the adoption of process. They want end-to-end process to be their DNA.  They want everyone connected with process, and engaged in continuously improving process. They want process cohesion. So they will want to choose a process language that is easily understood by people right across the enterprise - from corporate head office down to call center agent.

That's the vision of the BPMN process language, whose stated aims include, according to its creator, the OMG, that BPMN should be "a notation that is readily understandable by all business users".

Global360 released a video last week with Bruce Silver promoting BPMN [and Visio 2010 as the ideal tool for BPMN]. It's the kind of thing that could be very persuasive.  Bruce is seen as an experienced and independent professional, and his message that BPMN is a global standard, endorsed by many vendors, that provides a new universal modelling language...sounds just plain sensible. 

Even the ARIS community seems to be getting behind BPMN as an alternative to EPC.

So you might think that it's game over, a slam dunk for BPMN as the process modelling language of choice. 

That's where the savvy CIO comes in.  Because BPMN is set to fail as a universal business language for process, for at least a generation, for the same reason that EPC has failed outside of the CIO's domain: It is an IT-driven language. 

Its approach is: 'Tell me what you want and I will build it for you as a system'.  It is effectively blind to process as the business operational environment that is deployed to real life users - except as a system, with 'manual working practices' where required.

As a language for process adoption, as a collaborative framework for the design and management of change, as a platform for managing compliance across the enterprise, BPMN suffers from the same problem as EPC. It's designed to meet the needs of systems-builders. It's therefore a technical language - it may be an excellent one, the best ever, I'm not qualified to judge.  But the software engineering mindset is its weltanschauung.

If anyone needed convincing on this, look no further than online discussions like this , which illustrate the necessary complexity of BPMN as a language for developing systems. Or at blogs like this, where eminent software engineers are wondering if possibly some of the 20 archetypal workflow patterns are not supported by BPMN and work-arounds are required.   This is not the language of the business.

The best candidate that I know, right now, for a universal business process language remains the Nimbus Universal Process Notation (UPN). The guiding principle for UPN is to describe processes in a format which is easily understood by all employees, not just a team of highly trained process specialists. It was designed from the beginning to drive process adoption, whilst still providing for many of the technical needs of an IT audience. 

Proven in hundreds of Nimbus clients around the world, UPN is the recommended - though not the only - notation for use with Nimbus Control. 

That said, UPN is not a complete solution.  Systems require a rigor and detail in describing process that the business does not. Typically, IT will need its own process language in addition to UPN, and a tool that supports it.

Nimbus Control enables a hybrid UPN+BPMN approach within a single hierarchical process model.

But the more practical approach, at the enterprise level, is to synchronize two views of the process reality - the business view and the IT view. Think of it as stereo. The enterprise has chosen to have two tools, supporting two process notations, meeting the needs of two distinct audiences - but fully integrated and synchronized.

And the best example of this synchronized solution, that I know of, is the integration between Nimbus Control (the business operational view, in UPN) and SAP Solution Manager (the enterprise architect and IT view).  

It's worth pointing out btw that this is not vapourware: Nimbus Control + SAP Solution Manager is in daily use in some of the world's largest organizations.

At the end of the day, as I've noted before, we're down to the wisdom of CIOs because they will usually be in a pivotal position. 

The pressures on CIOs to take the easy way out are mounting. Nobody got fired for buying a universal standard like BPMN. It seems almost inevitable that many organizations will slip into BPMN as their de facto universal process modelling language, without realising the choice they are in fact making. Their chances of business:IT alignment will reduce accordingly.

CIOs who understand the significance of these seemingly arcane process issues and can steer their enterprises towards the right choice of process modelling language and tools can deliver huge strategic benefits.

related post:

19 May 2010 BPMN: The Question Every CIO Should Be Asking

BPM: In Search of The Big Idea

At least LinkedIn discussion groups have taught us one thing: That there is no longer any real consensus on what BPM even means, let alone whether it matters. 

I'm almost wistful for the bad old days of BPM. There used to be a sense of structure, an agreed framework for our understanding of BPM and its potential, and a way of defining its relationships - with enterprise architecture, for instance.

We were paying a price for that consensus of course because it was messaging from the big BPM technology vendors that was driving the marketplace and analysts' perceptions.  BPM technology was the answer.  The whole continuous improvement movement, and Lean and Six Sigma, - they might as well have been on another planet.

So the blooming of discussions on LinkedIn and other fora may seem like an anarchy of ideas, but at least it's more open and inclusive.

That said, structure and consensus can be very helpful for participants in any human endeavor, and its absence in BPM is remarkable and problematic.

Right now, we have an intellectual mash-up in BPM, a low-value ideasfest. Our common understanding has collapsed, leaving a noisy void. There is no consistent analyst interpretation any more. There are many conflicting narratives - from the grassroots BPI movement, through the Outside-In approach and the Lean Sigma community to the BPMN folks. It's becoming driven by fads - Social BPM for instance. 

Some diversity in approach is inevitable and desirable - but BPM is in danger of becoming dysfunctional just as it is becoming mainstream.  It needs a Big Idea around which all its various strands can coalesce to create a shared understanding and an alignment that would drive vendors to deliver what organizations really need.

It was with these thoughts in mind that I read Paul Harmon's article defining a Business Process Architecture - and almost 100% agreed with it.  It seemed to me to be the kernel of the Big Idea, a very useful development. You could meet the CEO in the lunch line and use it to explain in a couple of sentences what BPM meant and why it mattered.

In my post last week, I went on to disagree with Paul, in just one area: his assertion that 'any process modeling tool would do' in developing and maintaining a Business Process Architecture. 

I defined the four properties for a process modelling tool that I see as the essential foundation for any Business Process Architecture of the kind Paul describes.

• It uses the language of the business
• It is owned by the business, within a governance framework that enables collaboration on change by all process stakeholders
• It is deployed to process consumers across the organization as a personalised intelligent operations manual - 'the way we work' - with features that encourage engagement in continuous improvement
• The Business Operational view of process is synchronised with the complementary but different Enterprise Architecture view of the organization's processes.

The funniest feedback on this btw - on a LinkedIn discussion - was from a product manager at a major tool vendor who wrote contemptuously: 'what you're saying Mike is that your tool is better!'. Er, yes! That's exactly what I'm saying.  All process modelling tools are the same like all vehicles or all fruits or all flowers are the same.   

I'm open-minded - but in all the feedback I've received so far, I haven't heard a convincing argument why:

• any the four properties I've defined is not required to support Paul's notion of a Business Process Architecture
• any other property should be considered essential.

I'm planning to unpack each of the four essential properties here in the coming weeks, and to invite debate.  If we could agree a conceptual framework for BPM that has something like Paul Harmon's Business Process Architecture at its heart, and we could agree the essential properties of the tool that's required to support it, we'd be back on track.  Actually, a much better track - a richer and more inclusive conceptual framework for BPM that is grounded in real-world sustainable performance improvement and continuous excellence.

PS I'm totally cool that while Nimbus Control may be ahead, that's only right now.  As the market converges on the requirements for a tool that can support a new conception of BPM, this will become much more competitive and eventually, no doubt, commoditised. But we have every intention of staying ahead btw ;-)

related post:

22 June - The Leap From BPM To Continuous Excellence

When Business Is Held Hostage By IT

I've been in discussions with three clients in recent weeks - all Fortune 500 and all stuck in hostage situations.

In one case, business processes are buried in the code of in-house systems developed over many years by a bloated IT department.  Which leaves IT calling the shots on any and every change program, and leaves execs who are attempting to focus on business transformation and performance improvement almost like onlookers. 

In another client, the IT department is mandating the use of BMPN as the framework for business transformation and performance improvement.

[re BPMN. Thanks to the reader who pointed out this gem of a post, where a BPMN enthusiast blogs with an example of how crystal clear BPMN is, and how the business is just making a big fuss - only to have a fellow zealot comment that:

"The story is good but your BPMN diagrams are not syntactically correct. The customer process is missing an end event in both cases. Catching message intermediate events must have an ingoing message flow. If you want to denote the type of information going from one task to another a document artefact associated with the sequence flow would be the correct way to draw this..."

You couldn't make it up. As a famous screenwriter for spy movies lamented this week about the story of the Russian spies in deep cover in suburban USA, using their secret messaging to Moscow to ask questions about their expenses, the problem for fiction writers is that it has to be plausible.]

In the third case, the IT department has forced the business to manage a global business transformation program using a BPA tool, on the grounds that it was 'essential to SAP configuration'.

How do you know you're in a hostage situation? Two tell-tale signs:

• Stockholm Syndrome. Do you find yourself talking about BPMN and BPMS and SOA and Cloud?
• there's a gulf between Business and IT.

If you're unlucky enough to be in a hostage situation: what can you do? You might look for a secret weapon, or a hidden trapdoor, or some other Deus ex machina.  Or you could start a conversation with your captors about BPM because it might be your single best bargaining chip.

BPM is really a framework for collaboration.  It creates visibility and allows clear business ownership of end-to-end processes. It correlates the business operations model with the underlying systems architecture. It provides a governance framework for all the stakeholders to jointly manage change.

BPM enables the Business hostage and the IT captor to begin an intelligent and ongoing discussion where business requirements and priorities drive transformation of the operations and the underlying systems landscape. It allows everyone to do what they do best.

A lot of IT captors have deep-seated grievances of course - they've never been understood, always been pigeon-holed as nerds, and so on - so even after they put down the BPA tool and allow the Business hostage to walk free, it will take time. But stick to talking BPM and this can still have a happy ending.

BPM and the US Constitution

There seem to be still a lot of folks out there with a very narrow definition of BPM, seeing its focus as being just automation.

A client story I heard yesterday and the coming July 4th weekend celebrations triggered the idea that the US Constitution provides a useful parallel to illustrate the real scope and power of BPM.

The genius of the Founding Fathers created a Constitution that continues to underpin 'justice, tranquillity, peace, welfare and liberty' in American society - and has provided a model for many other republics.

The Constitution created a clear framework for governance and accountability. It provided the means to plan and implement innovation and change.  It was universal in its scope. It provided the framework for collaboration and progress.

The client's identity has to remain confidential for now - this is about a major restructuring of their business that is not yet fully announced - though they may yet be able to speak at the Inspiring Performance 2010 conference later in the year.  It is a global Fortune 100 organization.

The client's business transformation program focusses on one operational area but it is substantial. They are consolidating three business units spread across several countries. The target is an immediate 20%+ reduction in operating costs.  And it is process-driven.

The client has adopted Nimbus Control as its framework for process management. They have a single integrated and graphical view of their current end-to-end business processes. They have a future state model in similar detail.  They are capturing innovation ideas, assessing the gap-fit, and planning change all within this single BPM platform. Changes to the underlying systems landscape are driven from the future state processes defined within this single framework. The exec board driving the program is discussing and signing off end-to-end process and Storyboards within this framework. 

When the program is announced and the new structure goes live, end users will be trained using the same Storyboards. And the new processes will be integrated with documents and metrics, within Sharepoint, to deliver a personalised 'intelligent operations manual' to every desktop.  

For this client, BPM is its universal framework:

• it orchestrates and governs the activities of all the various stakeholders in operations, IT, HR and finance, just like the Constitution orchestrates and governs the executive, the legislature and the judiciary.
• it uses end-to-end process as its basic language, just like the Constitution uses English.
• it enables engagement in continuous improvement by end users and by Lean Sigma teams, just like the Constitution enables progress through legislation and Amendments.

And, like the Constitution, BPM is a framework for sustainable change. It overcomes the problems of 'snap-back' and 'revertia', where the benefits erode as the business transformation unwinds.  It provides the framework that McKinsey research shows is required to make cost cuts stick. It enables IT to seamlessly align with the Business, like the two hemispheres of the brain. And it integrates process with business controls, compliance and risk management to enable a common vision of the enterprise in 3D.

Whether those who promulgate the view that BPM is just automation, and that the Constitution must be re-written in BPMN 2.0, really deserve the privilege of being able to plead the Fifth Amendment we'll have to leave for another day...  Meantime, happy July 4th to American readers!

BPMN 2.0 and the Scissor Sisters

Just before BPMN 2.0 and the Scissor Sisters set on Saturday night, a quick apology to followers of this blog who were among the 180,000 revellers at the Glastonbury Festival this weekend. 

It must have been bitterly disappointing to find that the new Shangri-La area at the Festival is in fact nothing to do with this blog, but instead an area dedicated to drum and bass enthusiasts.  A shameless attempt to ride on the back of this blog's success. Needless to say, this blog's lawyers are already on the stopping train down to Somerset. Michael Eavis watch out.

On to more serious things. I seem to be developing a reputation as a BPMN skeptic. Which is a surprising position for me because I'm all in favour of collaboration and I understand the value of standardisation.

But I was uncomfortable with excitement among some of the Twitterati on Friday about the OMG Architecture Board's approval which, subject to some minor formalities, means that BPMN 2.0 is now a formal standard.  

I was quietly despairing that the Big Vendor marketing machines will now kick in, with huge claims for BPMN 2.0 as a complete global BPM solution.  Group-think will then make BPMN 2.0 compliance mandatory in many organizations.

I was reflecting what a pity this would be, what a waste of time.  It may take several years for the realisation to grow that BPMN 2.0 cannot do this.

Then I heard the intro to the Scissor Sisters set, which was inspired by Glastonbury Tor [a place where, legend has it, Jesus once walked - the inspiration for William Blake's poem]. 

It was a heart-felt and moving appeal to the crowd to 'be together in the moment, and for eternity'.  It made me reflect how much people long for unity and solidarity, and to be part of something bigger and purposeful. 

And - sad but true - my thoughts turned back to BPMN 2.0 and I found myself feeling more kindly towards its zealots. The truth is that many BPMN 2.0 enthusiasts simply want to contribute, to lend their support to something progressive - and there's nothing wrong with that.

My own view remains though that BPMN 2.0 is great but not in itself sufficient as a platform for sustainable process excellence.  Organizations need two equally important views of their reality. The left-brain IT and EA view and the right-brain Business Operations view - synchronized through a corpus callosum.

In that context, BPMN 2.0 is an improved language for the left brain. And that's great so long as we never confuse it with the whole organizational mind, which requires the right-brain view as well if it is to reach its full potential.

So, in the spirit of the legendary Stevie Wonder, who did a brilliant and joyous finale to close Glastonbury this year - Big Love to BPMN 2.0.  I'm a lovin' skeptic. 

BPMN: The Question Every CIO Should Be Asking

Ask my wife - I'm not your average dissident. Show me a rule and I'll want to stay this side of it. So it's not in my nature to be standing in front of the BPMN steamroller. But there is something disturbing about the way in which BPMN is heading for a landslide victory.

BPMN V2.0 is set for release next month. The big vendors are training their consultant cohorts in BPMN [and thereby able to re-brand their plain old 'Application Consultants' as 'Business Improvement Consultants']. The large SIs are investing in BPMN practices. Industry commentators are joining in to trumpet the praises of BPMN. It's a gold rush.

My earlier posts on BPMN drew a lot of fire. Why am I staring down the barrel again? What could possibly be the problem? Isn't this the answer we've been seeking for so long? After all, one of the key stated aims of the OMG, the creators of BPMN, is to bridge the IT:Business divide:

"...to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes."

I think we are drifting towards a consensus about BPMN that will surely take us backwards. And CIOs have an absolutely critical role to play in navigating this.

Vendors and consultants are heavily invested in BPMN.  For many, who are tech-savvy, it's what they understand. It's robust, it's integrated, it's a bit academic - it presses all their buttons.

But the idea that BPMN can be a common language for business and IT is a delusion.

BPMN is the language of IT. The BPMN V2.0 spec is 496 pages. It's complex - and needs to be because its eventual purpose is to create executable code. It has 63 Event symbols and 8 Gateway symbols. It has not just swimlanes but pools as well, and even the concept of a collapsed pool. And in BPMN, tiny variations in the way something is drawn can fundamentally change its meaning. No way is this a language for the business.

To be fair:

• authors like Bruce Silver have tried to translate BPMN V2.0 into something that might work in practice. But even his reduced palette of BPMN symbols - 'Descriptive BPMN' - is imho far too rigorous for business process stakeholders, and totally implausible as a means of reaching process end-users.

• many commentators and consultants embrace BPMN but recognise its flaws as a language for the business, and so feel free to be 'flexible' in how they use it - simplfying and adding new symbols if necessary to make it work.

But these attempts to make BPMN work in the world of business reality surely just demonstrate its limitations. If BPMN is actually the language that can bridge the IT:Business divide, it shouldn't need this. At some point it must become so simplified and 'flexible' that it's not a useful language for anyone.  It won't be intuitive enough for the process stakeholder and end-user, or rigorous enough for the business analyst.

Separately but equally important, BPMN is 'governance lite'. It was never designed to couple end-to-end business processes with risk management and business controls, within an operational governance framework. And it's hardly built with continuous improvement in mind either.

We're down to the wisdom of CIOs. They are being prompted by vendors, consultants and their own people to get on the BPMN bandwagon and declare a commitment. They have C-Level peers asking 'What is our BPMN strategy?'. They are under pressure to buy the dream and have an ambitious BPMN strategy.

But the best CIOs know that effective communication is the biggest single issue, and a fundamental cause of IT failures. The question that they will be asking of this new notation is this:

Will BPMN help me collaborate with the business?

And the answer must surely always be 'No'.

BPMN has value within IT, maybe even high value. BPMN may be good for compositional work at the design stage. It is a natural language for reference models in the Enterprise Architecture domain. It may make sense to develop a hybrid process model of the enterprise with the lowest levels of the model, unseen by stakeholders and end-users, in BPMN.  

But any organization looking to adopt BPMN as a universal language that can bridge the IT:Business divide is riding for a fall. And I'll offer two data points to support this:

• A global manufacturer and Nimbus client ran an exhaustive evaluation of tools to support its global BPM strategy. At that time, they saw BPMN as hugely important. It was central to both their RFP and the subsequent Proof of Concept. But, as they investigated further, their thinking shifted. Now, eighteen months after that evaluation and selection [and despite the fact that it is supported in Nimbus Control], BPMN has never in fact been used, nor are there any plans to do so.

• As a colleague put it: if BPMN is the answer now, then how come, after many years when ARIS has been the dominant market player, the ARIS EPC notation has never been embraced as a language that the business understands? After all, independent evaluations seem to confirm that EPC is a richer and more capable notation than BPMN - but, despite the prevalence of ARIS in the IT world for so long, the EPC notation still meets resistance from the business stakeholders, and mystifies process end users.

This is another example of where CIOs earn their salaries. Theirs it is to resist the easy option. They will want to cut through the BPMN hype, embrace what is valuable, and resist the waste of time and resources that will result from following the crowd. They know that business process is the right framework, and that further development of BPMN has value - but no way is BPMN the right language to engage and orchestrate the business.

Previous posts in this vein:

5 May Business in 3D: coming soon to an enterprise near you

14 April Making Enterprise Architecture into a strategic conversation

19 March Learning to speak process: the emerging universal business language

Learning to Speak Process: The Emerging Universal Business Language

Agreed, it's a bit cheesey to start with this: but it's a true remark from an industry veteran and it set me thinking.

A senior client in a global consulting services company paid a completely unsolicited compliment this week: 

"You guys at Nimbus are so far ahead. You think what you do is ordinary - but let me tell you: for many of my clients, process as a common language is real innovation, and desperately needed.".

Language is a defining characteristic of humankind. It is core to our wellbeing, prosperity and progress. If you and I want to communicate beyond gestures and signs, we need a common language.

To communicate outside of our native language, we have two options.  We can learn the language of the other person or we can use a widely-adopted common language - like French in the 19th century, or English in the 20th century - and like Mandarin might become in this century.

But our common language could also be a simplified lingua franca or pidgin language, or one of the surprising number of man-made artificial languages such as Esperanto, Ido, Interlingua and Laadan.  All that matters is that it enables us to communicate, and, ideally, everyone else speaks it as well. 

Until recently, Process was like one of those man-made languages that never really took off.  Process was used only by IT geeks and quality managers and later by the Lean and Six Sigma crowd. It was a back room language, often quite technical, and certainly never spoken in the board room.

Nowadays, process is embraced by everyone. And process, we are all violently agreeing, is often the key to business success and failure. Two recent examples - you'll be able to list many more: 

• Steve Diamond, senior director at Oracle, wrote last week that the long list of CRM implementation failures - by all vendors, not just Oracle - are not to do with CRM technology: 'As I looked down the list, they all seemed to relate to people or process.'

• Mark Trepanier, managing director at EquaTerra, wrote recently that a process focus is one of the four core principles for Shared Services success: ' The secret is to always talk to the customer about service, but to always think about process.'

So, good news - there is a growing realisation that operational excellence means being able to understand and manage the enterprise by function, by region, by product - and by process.

And we're increasingly agreeing that process should be the common language.  But there's a problem. Process is actually spoken in many dialects, depending upon the silo of the speaker -  IT, Quality, Six Sigma, Compliance. Even worse, the vocabulary of Process varies significantly between the dialects. A 'process' within SAP's widely used Solution Manager, for instance, refers essentially to a specific SAP transaction. Whereas a compliance manager would have a very different end-to-end definition for 'process'.

So Process isn't working as the lingua franca for the enterprise. What each group means by 'process' can vary enormously,and there is not much of a common vocabulary. We've all seen the confusion and frustration in practice: people talking 'process' but in reality using their silo dialect and each having a different understanding.

BPMN supporters will say that V2.0 is that common language, providing a fully featured vocabulary for process description and analysis.  But BPMN is a necessarily complex language, intended for business analysts and enterprise architects. BPMN is never going to work as a language to engage a much wider cross-section of the enterprise in process improvement.

Let BPMN prosper as a process language within its own silo. The enterprise needs a pidgin language - a simplified process language that enables communication across silo boundaries.  

Nowhere more so than across the IT:Business divide. Clay Richardson and Connie Moore wrote last month on the Forrester blog about 'the storming of the Bastille' - the increasing number of  'populist uprisings' in which business users are wresting control of process improvement initiatives back from IT. There is an urgent need for a common framework for collaboration.

So what's an ideal pidgin process language?

• It has to be simple, and graphical wherever possible, so that everyone can understand it - it's the enterprise lingua franca - and not require a software engineering mindset.
• It needs to offer an holistic and integrated view of the enterprise, not just what's automated, so people can see the whole.
• It needs to be real and 'live' - owned and embraced by the whole business, supporting day-to-day operations and managed as an enterprise asset.

I would say this of course but the Nimbus Universal Process Notation (UPN) has a lot going for it as a common language because it's proven as a collaborative framework across hundreds of organisations, around the world and in all sectors.

The first use of the word 'process' meaning 'a continuous series of actions meant to accomplish some result' was apparently recorded in the 1620's. As my [grown-up] kids keep reminding me, it's kind of amazing that, almost four centuries later, I could be making a living helping people to understand process. 'You mean you get paid to help people understand what they do? Isn''t that obvious?'  Well, no actually, not yet - as my client's remarks attest.

Process Democracy: Be Careful What You Wish For

Suddenly everyone's going democratic.  I was at a Microsoft pitch this week where Visio 2010 was branded as "The Democratization of BPM". And Gartner's latest magic quadrant report on Business Process Analysis (BPA) tools predicts that the next step will be "BPA for the masses". 

I won't argue against democracy - but, in this case, it's surely a blind alley.  Look at the powerful analytical features of Visio 2010 and other BPA tools like ARIS or Casewise. Leveraging them requires extensive training and a software engineering mindset.  They are tools built for business analysts and enterprise architects. Their focus is on what's automated. They were never intended to be enterprise platforms for collaboration on process improvement. 

Some future business generation may have the capacity that allows BPA to be embedded in the organization, as Gartner predicts. But, for the foreseeable future, I don't think so. Nicolas in Finance and Pushpa in Supply Chain really don't care about BPMN or data models or the subtleties of enterprise architecture - and nor should they. Let them focus on their particular expertise - on what they do best.

Imho Microsoft and Gartner are missing the point. The real potential value of democratization is not in rolling out BPA functionality,but in engaging people across the enterprise in process improvement. People want to bring their brains to work.  We thrive in creative, collaborative environments. We long for meaningful work.  We all want to be active participants in change.

Hey, don't get me going on this!  I grew up on Schumacher's Small Is Beautiful: Economics As If People Mattered. I'm not saying that Buddhist economics alone is the answer.  But that sense of involvement in work, which occupies some much of our lives, is precious. Any wise employer will want to embrace it.

So we need process democracy in the sense of engagement, at every level and across the enterprise, in continuous performance improvement. We need tools that enable process consumers like Pushpa and Nicolas, together with all the stakeholders, to collaborate in pursuit of operational excellence. And all within a governance structure that ensures end-to-end ownership, accountability and compliance. 

[And yes, sometimes, the ability to stop Nicolas making his tenth improvement suggestion of the day and force him to get back to his Finance day job ;-) ].

BPMN: Tasting Some Humble Pie

Paul Harmon of BP Trends wrote a thoughtful piece yesterday on BPM and Humility.  He calls for BPM practitioners to be ‘wise enough, honest enough and humble enough to recognize our limits’.

In that spirit, it’s time for me to taste a little humble pie as well.

My recent post on Process Improvement? Why BPMN is Irrelevant was unnecessarily confrontational.

It provoked a big response [not all of it hostile!] and deserves some clarification.

I support the BPMN initiative.  Hey, I read BPM The Third Wave from cover to cover when it first came out back in 2003. A single language for Business and IT has got to be the ideal for any organization.  For many years, Nimbus has been moving businesses towards being capable of a more structured communication with IT [and Nimbus Control supports the current BPMN standard].

The challenge with BPMN is how quickly it can become, in practice, the lingua franca in discussions between IT and the business.  My experience, working alongside clients around the world, is that the rigor of BPMN can be a significant barrier to IT engaging the business.

Bruce Silver’s ground-breaking book BPMN Method and Style points out that BPMN is focussed on executable processes, and that “BPMN is only one component of the business modeling needed to properly describe, analyze, transform, and optimize a company’s business processes”.

The dialog about BPMN as the search for a single language look sets to run for a long time to come.  My recent contribution to that dialog was high-handed and possibly offensive so I must apologise for that.  In mitigation, it was animated by a passion that IT’s contribution to process improvement is too important to be hampered by language.  Like many others, I want to see BPMN thrive for the right reasons – but not where it is at the expense of IT’s engagement with the business.

Process Improvement? Why BPMN is Irrelevant

Roger Sessions published a paper recently in which he estimated that $500bn is being wasted worldwide every month on IT failures.

Bruce Webster, another expert in the field, responded that Session’s estimates could be out  by up to a factor of 10 – which still means $50bn wasted per month on IT failures.  Webster himself points out though the C-Level debate underway about whether any IT project ever delivers a positive ROI.

However you cut it, IT failure is a huge issue – not just for corporations and for governments but for humankind. It’s an incredible waste of resources and human potential.

Michael Krigsman’s excellent blog on IT Project Failures highlights again this week a recurrent theme - the communications gap - concluding:

'Breaking through information silos is among the most difficult challenges facing any organization.'

There is a tremendous amount of research going into IT failures.  One of the root causes that consistently emerges is the familiar business and IT divide: more specifically, that IT doesn’t understand how to communicate with the business. 

IT vendors always have an answer.  Right now, as the BPM hype cycle diminishes and serious debate emerges about whether SOA is dead, the answer seems to be BPMN - Business Process Modelling Notation (BPMN v2.0), a new standard published by the independent OMG, and now nearing full release.  It has become fashionable to add ‘BPMN compliance’ to every RFP.

According to its charter, BPMN is designed ‘to enable understanding and communication across the enterprise’.

The publication last week of a BPMN V2.0 wallposter neatly summarises the problem.  It’s admittedly brilliant in that it manages to condense the 300-page BPMN spec onto an A1 poster.

And many a geek’s  bedroom wall will no doubt shed its UML and Metallica posters in favour of the splendid new BPMN V2.0 image. [which comes from BPMN Info, boasting ‘the sexiest process models’!].

But BPMN V2.0 as a language that will transform communication between IT and the business?  Phleeeeze...

BPMN is a huge diversion from what is really needed. BPMN may have real value as a language within IT, for Business Analysts and Enterprise Architects, and that’s well and good.  But the idea that the business will adopt BPMN, that it could become the language for process management and performance improvement across the enterprise, is frankly delusional.   

At a time when the need for a common language for business process management is becoming so self-evident, this BPMN hype is in danger of just locking IT further into its own world.

Which is a heck of a shame because in fact IT has so much to offer.