The importance of being Simple @BPM @process

Tom Molyneux has just written a guest piece on Chris Taylor’s blog that I wholeheartedly applaud both for its message and the simplicity with which it is delivered…

With due thanks to Oscar Wilde for the title inspiration, this is a bugbear of mine that I see in many situations and constantly rail against, that is: people/industries delighting in using impenetrable language, abstruse words, deliberately complicated syntax, all with the express intent of showing just how clever they are, how difficult their subject is, and thus underlining their importance.

Which from my perspective does the absolute opposite; I find it childish and frequently ridiculous but it happens everywhere, and nowhere is it more prevalent than in the IT industry. To be fair I understand that there is often a big helping of job protectionism in this, but also what appears to be a desperate need for certain people to demonstrate their IQ. The person shall remain nameless (I don’t want to be accused of flaming) but there is a well known blogger in the process space who is a perfect example of the, “I understand most of the words you’ve written but have no idea what you’ve actually said” reaction to their blog posts….

However apart from the personal issue I have with this tendency, there is a much more important one which Tom eloquently points out, in the BPM world and talks to a point that I’ve frequently made in my posts. There is a need for two linked but different process descriptions in any organisation, and most companies haven’t yet understood the simplicity required in one of them…

Let me recap/reiterate the point: there MUST be two process descriptions in an organisation; one to define the executable processes for the process automation, the other for the humans to have both a complete end-to-end understanding and also to actually do the non-automated activities.

The problem is therefore twofold:

• the process practitioners that create and manage the description driving the process automation, often think – horribly wrongly – that process is process therefore why can’t you have one language for everything

and

• it is those same practitioners that drive the process creation for the human descriptions and they either deliberately or unconsciously forget the key learning that Tom highlights, i.e. “if stuff isn’t simple people won’t do it”

Why?

Well I think that there is some job protectionism going on; “I need to show that this is difficult to justify my daily rate/salary”, but also that people simply (pun intended) haven’t understood Richard Thaler’s basic truth:

“My number-one mantra from Nudge is, “Make it easy.”

It is widely understood that frequently the best communicators in life are those people that can make complex subjects simple, whereas I often see the direct opposite in the BPM world.

My lesson for all you BPM practitioners out there: if you are creating process descriptions that your end-users don’t understand and don’t use, then YOU are wrong not them!

And that in a nutshell is why in my experience the vast majority of end-user focused process projects fail.

P.S. Obviously it would make me feel suitably smug if you had to look up the meaning of some of the the words above….

So which language should we use then? #BPMN, #BPM

I’ve threatened (!) to blog about this before and haven’t got around to it, however I really do believe that we (the BPM community), need to clarify some thinking around the ‘process language’ question.

I’ve alluded to this before,  (BTW I apologize if the word ‘zealot’ displeases you; it appears to have a negative connotation in the US that it doesn’t here and in no way was meant as a negative comment) and I’m certain that my views are misunderstood, but far importantly that the BPM community as a whole isn’t thinking very clearly about this.

I am of the opinion that organizations’ efforts to deploy process is being actively harmed by this lack of clarity and it is hurting all our efforts to promote company wide process management.

Here’s the argument as I see it:

The company-wide process landscape

Firstly this conversation needs to be framed by reference to a diagram that I’ve introduced in a another post but that I’ll include again here for clarity:

Briefly it is saying that the majority of an organization’s activities don’t (and won’t/can’t) touch an enterprise app or process automation engine and that most processes are a combination of both manual (by this definition) and automated activities. Notwithstanding IBM’s message of automating processes that today are managed ‘over email’, this point doesn’t change; they are simply raising the automated/manual line a little bit.

So without question we have two different environments where the audience for the process information couldn’t be more different; humans and machines. It makes complete sense therefore that the requirements for the language used for each would be very different.

Below the line – automated activities

It’s a given that we need a standard language to allow interchange between toolsets etc., I don’t believe there’s any disagreement here.

This needs to be a graphical programming language that is sufficiently abstracted to allow business analysts to use it without being computer scientists. Given that we don’t need many business analysts (as a percentage of the company’s employees) the training that is necessarily required for BAs to be able to exploit the language should be manageable, both from a cost and logistical viewpoint. The ideal is for BAs and a subset of the end-users concerned to be able to build a process diagram , verify it and export to the automation engine for it to execute.

I’m no expert but it seems that BPMN fulfills these criteria, is becoming the de facto standard and therefore is a good choice.

The business analyst therefore must have a deep appreciation of how the business operates; indeed in my experience the best BAs are technically trained normal business people, rather than IT people who have had some ‘business’ training.

The vast majority of the business end-users however never need to see this process description at all. As mentioned, a subset will work with the BAs to create/validate what is to be built, that’s all. The end-users are actually the audience for the eventual automated process and therefore the BPMS’ user interface is way more important to them.

Above the line – manual activities

Here we have a completely different set of requirements; remember that normal, non-process expert humans are the audience here. At a basic level they need to to understand how to do their jobs. Period.

The process descriptions here need to be the simplest, easiest way for people to find the information to do their jobs. If you don’t capture process sufficiently simply and make it available in a personalized manner this part of  your process program will fail.

This process documentation (electronic operations manual) requires an extremely simple process view with ‘click to access’ the relevant documents, spreadsheets, videos, etc. to help them perform their activities. The graphical representation of the processes should be so simple that it doesn’t require training to understand. Bear in mind that we have 5000, 50,000, 500,000 employees that need to see and use this information on a regular, sometimes daily basis.

Any training requirement at all is a massive overhead.

Two languages

I can’t see how it’s possible to disagree therefore with the view that we need very two different descriptions of process for these two audiences. Nobody in their right mind would build process information that is destined for normal end-users in a graphical programming language, and the simple end-user view of the process won’t execute in an automation engine.

Ah hah!! some of you may say; you can use one language, BPMN for everything!

But in reality I’d argue that’s not true: the subset of symbols that are used in what I’ve heard called BPMN Lite do not provide you with an executable process. For that to happen, some highly trained person needs to take that process description and modify it.

In essence therefore you actually have two languages, (even if they’re both called BPMN), because you need a translation from one to the other to fulfill the need for which each is designed.

There is no way around this: regardless of what you’re calling them, you need two languages. You’ll notice that I’ve defined the difference between two languages as the need for translation between them. (Actually a linguist would call them LSPs, a language for specific purposes, which can be derived from the base language) but regardless of the semantics, the practical upshot is that you need human intervention between the two.

Which language ‘above the line’?

So if BPMN is the de facto language ‘below the line’, the question then is which language is best suited for ‘above the line’, or the process descriptions that are designed for human consumption. It seems to me that we have 3 major candidates:

• BPMN Lite (apologies if the name isn’t right but it works for this discussion),
• EPC (event driven process chains)
• UPN (universal process notation).

The closest I can find for a definition document for EPC is Wikipedia, the UPN description document is here, BPMN here.

All 3 are non-proprietary notations, EPC and UPN are most often associated with Software AG ARIS and Nimbus Control respectively, however can be used by anybody with any software.

I’m not going to go into an exhaustive examination of each, suffice it to say that in my experience both BPMN Lite and EPC are in some ways too complicated to be used widely for business end-users, in other ways they don’t contain the information required.

Both appear to have come from too technical a heritage to really cut it as a human focused language. If the proof of the pudding is in the deployment (sic…) then I’m not aware of any examples of either EPC or BPMN Lite being used on a daily basis as the staple process description in an electronic operations manual deployed to tens of thousands of people.

You might think that I would say that given my Nimbus link however I have no commercial axe to grind here, as mentioned anybody can use any of these languages FoC with any software.

I’m simply trying to bring some clarity of thought to this issue as I see companies trying to standardize on one process language when in fact it’s a futile exercise to begin with. You must have two languages and a way of managing the exchange of content between them which involves intelligent humans.

The decision of which two languages to use is clearly yours, however as a business user, don’t be brow-beaten into using BPMN simply because your IT department wants to standardize on it. In essence by doing that they are enforcing two languages, one for them one for you, without being aware if it and the consequence (no process adoption by your end-users).

Summary

Two dramatically different  audiences can’t be served adequately by one language, there is always translation required between the two.

Assuming that you use BPMN ‘below the line’, you need to make an informed decision of which language you are going to use ‘above the line’ (human focused, manual activity process descriptions) and ensure you build a translation mechanism between the two with appropriate governance.

So you see I’m not anti BPMN at all!!

Some further food for thought… #BPM #Process

So my challenge did elicit some good discussion, and also the note on Taylorism on the following post (thanks Regis ) prompted some further thinking on my part.

Firstly, and I think most importantly dear readers, although we may differ on our definitions of BPM, you need to understand my definition to ensure that you understand my thoughts. And I think from reading some of the comments  we are at odds as to the scope of the topic on which we’re trying to communicate!!

“communication is not what you say, it’s what the other person hears…”

Max’s reply to one of the comments on his blog illustrates this nicely:

“…what I see from Social being tacked onto orthodox BPMS today I wonder how that would happen with all the complexity and bureaucracy needed ….”

I however, am NOT talking about BPMS; I am NOT restricting my use of the term ‘process’ or ‘BPM’ to mean just the automation of processes.

I blogged here about it so I won’t repeat myself in detail, suffice it to say that in my mind BPM should mean exactly what it says; Business Process Management, i.e:

“the management of all of an organization’s processes”

NOT  something like this which (euphemistically) appears to be most people’s definition:

“management of those processes that we can automate in some kind of system, typically called a BPMS”

Clearly the second definition is a subset of the first, but also implies much more structure (a transactional IT system) and is what I think Max and other commentators rail against when they talk about the rigidity of the systems.

Let’s also pick up the comment about Taylorism above. As a brief FYI it was considered to be the first real attempt to apply science to management thinking, had apparent influences from reductionism and suffered from a similar backlash (as did scientific reductionism) as evidenced by Regis’ comment.

However, as in most things in life, a black and white perspective doesn’t serve us here as there is no question that a certain amount of reductionism in analysis and Taylorism in design is extremely useful in creating more efficient business processes. Indeed these  ideas have without doubt had an enormous impact in improving operational efficiency over the last century.

The big question (;-)) however is how much to apply to which processes in an organization. Max, I think we disagree on some things however on this we can totally agree;

“I propose the best businesses are those where the innovative powers come from within and from the bottom of the hierarchy – from its people!“

and therefore building process structures that stifle people’s innovation and ideas are worse than useless.

However, (again black-and-white thinking doesn’t serve us) to therefore say that standardization is blanket wrong is unthinking dogma driven from principle, rather than the informed result of some sensible thinking.

The Customer Operations Director of Best Buy Europe said;

“Standardization liberates people”

meaning that removing the operational pain of not having the easy, standard process information to hand about how to do things , directly related to the Customer Journey, freed people up and gave them more time to interact better with their customers. The results have been not short of astonishing in terms of Customer Satisfaction scores, volume of sales etc, as I mentioned in the original ‘argument‘ post

Standardization therefore doesn’t disempower people, on the contrary, if done right, it empowers them!

Why mapping as-is can be quite a good idea…

If this doesn’t frighten you and/or make you extremely skeptical about so-called ‘experts’ then I don’t know what will, however I promised to tell the story in an earlier post …

Names and places have been removed to protect the innocent.

We were introduced to a large hospital group that was about to implement SAP. The CIO was an ex SAP person, IBM Global Services was the SI and numerous people from SAP were involved in the project;  it was apparently one of the largest implementations to date into a healthcare business and accordingly had a very high profile.

The short answer from our meeting with the CIO was the following:

• can absolutely see that approaching the implementation this way makes complete sense…
• ….can completely see how this would help our company…
• …can’t possibly do it as we’ve already signed the contract with IBM GS and we can’t modify it now

We graciously retreated and waited for them to call back.

18 months later….

IBM GS have gone home with a ‘successful’ implementation to the contracted ‘on-budget, on-time’. The client has been left with a disaster…..

IGM GS have, in their wisdom, decided not too confront the as-is/to-be issue and therefore haven’t actually realized that a hospital is a hospital and the core processes is the same everywhere, PIPOHA (patient in, patient out, hopefully alive). They decided that since there were 9 different regions (same country, same laws, no sound reason for much process variance) they should therefore implement the system in 9 different ways…

Would it be cynical of me to suggest that it was in fact in their interest to do this as it would clearly result in many more chargeable days? (bear in mind that this would have been decided before contract signature and therefore the budget would have reflected this).

Unsurprisingly the call back arrived.

The client invited us back in to try to help sort out the mess as they had a system that nobody was using and had cost multiple millions to implement, (one of the IT group joked: “It’s the most expensive holiday booking system I’ve ever seen”). SAP had given them an estimate of the training rollout which was incredibly time consuming as they had to train differently in each region (it was measured in years!).

In short – Nimbus Control was deployed as a process layer on top of the SAP system displaying end-to-end processes with both the manual and automated steps shown and the training was delivered dramatically faster.

But that’s not really the point of the story.

Had IBM GS actually had the client’s best interests at heart they would have mapped as-is first and would have realized  that each region was in essence the same and that they only needed one instance of SAP to support the whole company.

Of course this would have meant that their consulting days would have reduced dramatically as well…

‘magic wand’ or ‘the usual crap’?

My colleague Chris Taylor recently returned from a Nepalese hiking holiday with some useful and relevant perspectives on the old thorny issue of ‘as-is’ versus ‘to-be‘, inspired bizarrely by hiking boots!!

I thought I’d weigh in briefly as I’ve seen lots of companies struggle with this issue. On balance I’d agree with Chris and I’ll state a few additional reasons  to what Chris has already mentioned (read his post to get the rest of what I think):

• gaining buy-in for process change is hugely important, we all know that. Presenting a crap ‘as-is’ process is a fantastic way to gain shop-floor buy-in to change, as people are metaphorically smacked in the head about how bad the existing process can sometimes be. It becomes apparent to everybody that change is required and the resistance frequently magically vanishes.
• baselining processes change is usually not easy to do however is often crucial to further process initiatives within an organization. If you can show a valid and valuable ROI on completed process change your internal business case is dramatically simpler to get by the people holding the budget. Obviously mapping ‘as-is’ gives you the tool to help this business case.
• IT implementations -I’ll explain in another post a real world example where mapping as-is would have potentially saved literally millions

You’ll note above that I said ‘on balance’, let me clarify: In an ideal world I think it is absolutely the right thing to do, however most of us don’t live in one. I’ve seen countless situations where senior executives will not be convinced as they want the ‘magic wand’ picture as quickly and as cheaply as possible.

Sometimes we need to be pragmatic, which might mean lying  being economical with the truth…. a ‘skunk works’ workstream building a certain amount of as-is in order to baseline, hidden from prying financial eyes, can be immensely valuable to the ongoing project/program and to your chances of being able to continue…

The ‘new world’ of enterprise process

I’ve mentioned before that the world of process understanding is changing and we’re seeing both companies and analysts wake up to the new paradigm.

Firstly the realization goes something like this:

• The large majority of activities in businesses are not logged in any transactional system (ERP, CRM, BPMS etc)
• Processes are combinations of both automated (in the transactional systems) and non-automated activities
• To both delight customers and increase operational efficiency we need to understand, see and use both the automated and manual activities to allow us to manage holistic end-to-end processes
• Modern companies have spent millions on understanding, managing, standardizing, etc.  the automated activities…
• … they have spent orders of magnitude less on the manual ones
• Thus there is a compelling need to apply the same level of rigor across the manual activities as well
• Business Process Management should be defined as managing the processes across the whole enterprise, both manual and automated, as shown below:

There are very few people who dispute this perspective (SAP, Microsoft etc agree with this picture) and there is also little doubt that increasing the number of automated activities is beneficial. However the vast majority, if not all of the BPM vendors and experts are exclusively focused ‘below the line’ ‘ i.e. increasing the number of activities that are automated, see Phil Gilbert of IBM talking recently.

However laudable and necessary, it’s absolutely fundamental to understand, as evidenced by the picture above, that the contemporary ‘BPM’ vendor’s view of BUSINESS Process Management is incomplete. In order to manage all of the company’s processes you will need a stack of technologies; any sales person peddling one software to manage all of your BPM needs is either lying or doesn’t understand.

So, what do we need to manage the ‘other 80%’?

• appropriate software
• implementation methodology
• a language

I’ll deal with these in  a later post.

For the vast majority, process improvement is the wrong focus…

OK, this is a long post, tea and biscuits needed…

Reading Brad Power’s article, (what a name!!! Brad, you missed your calling, you should be a film star…)  http://blogs.hbr.org/cs/2011/03/uniting_the_religions_of_proce.html, and I can’t help thinking there’s some key understanding that’s missing here, which, not incidentally, is also missing from virtually every other ‘expert’ that bangs on about process improvement.

‘Run before you can walk’ is a logical refrain and yet reading this piece on process improvement (yet another) it seems as though we are exhorting people to do exactly the opposite.

Standardization is the key word: If you have a workforce of, say, 10,000 people how do you know what processes they are actually executing today? I can virtually guarantee if you talk to any random employee in,  to take Brad’s  example Shell, and ask what they do they will be able to describe the processes they are involved in. Then ask them to show where it’s written down and they’ll struggle to find the documentation. When they eventually find it, the documentation will say something different from what they actually do. Oh and by the way let’s go and ask another employee who does the same job in a different location and you’ll get another answer again… and again… and again.

If you don’t believe me ask Carphone Warehouse; during their keynote presented at Nimbus’ IP09 event, they showed how big this problem was for them: they asked 20 of their branch managers each with more than 5 years experience how to reconcile sales contracts – each had a different answer!

This is a massive, apparently undiscovered issue  for so many businesses, and impacts critical functions within businesses (covered in a future post, however here we’ll stay with Brad’s process improvement focus).

The ‘running’ referred to earlier is the process improvement, the ‘walking’ is standardization.

Given that we can’t get people to work the way we want them to now, what is the point in trying to improve what are patently non-standard processes today? Which one of the many (unwanted) variations are we going to improve? Or are we simply going to think big thoughts in small groups and do our cool analysis and then abdicate responsibility for actually deploying the processes and then ensuring that people actually do them?

BTW you would be amazed (or quite possibly shocked, horrified, reduced to fits of giggles – take your pick) if you knew what we have actually heard time and again in global companies; i.e. process practioners, BPM ‘experts’, who do not believe that it is their job to deploy, and then sustain process changes. This is core reason why companies are disbanding their BPA practices, referred to in an earlier post.

Let me spell it out: there is no point in trying to improve process unless you standardize first. In order to standardize you must have a process platform to allow you to do that. It needs to make working through process part of people’s day jobs otherwise the standardization you want won’t happen. And I don’t mean the output from a technical BPA tool or Powerpoint exported to your intranet; we all know that doesn’t work.

In doing the process discovery and making the decisions on to which existing process to standardize, you will make improvements simply by reducing huge inefficiencies of lots of people doing the same thing in different ways. Best Buy Europe saw a 5% improvement simply from this standardization.

Clearly you could use some improvement techniques during this process, fine, but you must have some way to deploy and embed the changes made.

I had a surreal experience a few years ago at a conference in Philadelphia. A fantastic presentation from the head of internal consulting at Coca-Cola, which, in my eyes rapidly degenerated into farce at the end: When asked what the key KPI was for her consulting group she said (I’m not kidding),

“how quickly we can fix a process issue that we’ve already fixed before”.

Asked for clarification she said that her team would use PI techniques in a certain part of the operation, improve things and then move on. Over time the ‘improved’ part of the business would drift back to old ways and they would be called in to fix it again. This was such standard practice that the time taken to re-fix was her core KPI…

The utterly frightening thing was her calm, normal demeanor and the fact that everyone nodded sagely as though this was OK. I was frankly astounded, even more so when I to spoke to her afterwards and couldn’t get her to see that this acceptance of the status quo was complete madness; “insanity is doing the same thing time and time again and expecting a different result”.

One other point Brad makes (although in fairness he may simply be repeating what he thinks the BPM religion believe) is

“Shell Oil’s downstream (refining and retail) businesses have rolled out a global implementation of enterprise software SAP with standard global processes”.

Let’s be clear: deploying ERP does not standardize business processes. In most organizations no more than about 20% of activities are automated in ERP and process automation software, and given that the vast majority of processes require both manual (no transactional system involvement) and automated activities, ERP/BPMS software can only automate a small fraction of the whole. Anybody who tells you otherwise is either sadly misguided or a SAP salesman…

Phil Gilbert’s never seen process chaos

Which is the only conclusion I can draw from his comments regarding Centres of Excellence etc. in, amongst other places, this really good presentation he made last year.

But instead of ridiculing his stance I actually think it’s totally understandable and probably very similar to most BPM “experts”. To paraphrase the immortal Donald Rumsfeld (no, strike that; the world absolutely doesn’t want him around for ever…), “you don’t know what you don’t know”.

Huh?

Here’s my thinking; If you’ve come from the world of BPA and BPMS/process automation, (which is the enormous majority of people in the process space, so I think this probably applies to pretty much every BPM commentator), then you are unconsciously incompetent to talk about massive deployment of process into an organisation.

The 4 stages of learning:

unconscious incompetence – you don’t know what you don’t know. This applies in skiing all the time; people go off piste/into the backcountry with no idea of whether what they’re doing is dangerous or not.

conscious incompetence - you know that you don’t know. I remember this feeling the first time I went into the African bush and wanted to go to an adjacent camp on foot. I knew that I didn’t know if walking there was dangerous or not.

conscious competence – I know how to do it but I have to concentrate. Learner drivers.

unconscious competence – I can do it without thinking. Experienced drivers.

BTW I’m only using the word ‘incompetent’ in the nicest possible way

What I mean is that BPA/BPMS projects are focused on small centralized groups building processes. A few people with brains the size of a planet doing desperately clever things in small groups. If the content is deployed outside the group then it is done in a very structured manner. And that means that the people involved (the BPM specialists referred to above) have no notion of what devolving the creation and deployment of process content out to tens or hundreds of thousands of people is about and the challenges it holds. They don’t know what they don’t know, but frighteningly are giving advice nonetheless.

Well we (Nimbus) do, warts and all; we have hundreds of implementations with a central repository and thousands of people accessing and creating content on a daily basis. And here’s a bit of advice for free; unless you have a well structured CoE you will have chaos and little or no value. We have seen a (fortunately small) number of our clients, big, sometimes global companies, ignore our advice and do exactly what Phil is suggesting with his seductive tag-line, “the democratization of process”, i.e give people easy and powerful tools to use and somehow it will all be alright…

And it might sound warm, fuzzy and attractive to western sensibilities but I can tell you it is an utter mess. You get exactly what Phil is proposing; loads of people building content, really getting into it, communicating like mad, and guess what? No value and ultimately frustrated people. This is one case where out of the chaos no beautiful order emerges…

Whatever software you use you should absolutely be collaborating, devolving process creation, using social tools and principles.

However please, for your own sake, don’t do it without sensible strong governance…

Is BPA (Business Process Analysis) dead?

An article on GigaOm (http://gigaom.com/2011/03/31/when-is-a-tech-company-dead/) prompted this thought; is BPA dead?

Of course it isn’t I hear you say, most of the companies in the space are growing (albeit slowly), Gartner has a Magic Quadrant, heck my company has just bought some BPA software!

That may all be true, however for different but related reasons I think that it might be ‘dead’ in a tangentially similar way to the ‘dead’ companies written about in the article.

Why? Well for a number of reasons:

• what is the size of market for BPAnalysis? I emphasis the word analysis deliberately because that’s really where the heritage, the thinking and the philosophy  of the BPA toolsets has come from. However, really…. the number of people actually doing analysis on business process in most companies is a tiny percentage of the company’s popoulation. Not to say that it isn’t useful, simply that analysis isn’t an end in itself it’s a means to an end. What do I mean? Well the best most perfectly honed process in the world is of absolutely zero value if the X thousand people in the company concerned aren’t actually doing it. Therefore analysis only has value if the result is actually deployed/used, otherwise it’s a waste of money and time.

  And therefore it’s hardly surprising  that BPA tools that were conceived and built for the A bit aren’t actually very good at the deployment bit. Show me an operational i.e. used deployment of ARIS or Casewise to, let’s say, 10,000 people…

  Many companies (I could point to at least 10 global companies off the top of my head) are waking up to the fact that analysis for analysis’ sake is pointless and adds no value. They are/already have disbanded their BPA groups and thown away countless man/woman-years of work.

• BPA is being subsumed into BPMS Look at the acquisitions in the last couple of years and you’ll see that many of the standalone BPA vendors have been swallowed, presumably with the aim of simply becoming the precursor software to the BPMS. and in many cases the BPA software revenues are a tiny part of the whole, witness Software AG and the revenue that the ARIS toolset adds to the whole…..
• The Gartner BPA MQ is on it’s way out This is unconfirmed and may not actually happen but apparently there are loud voices inside Gartner that have seen the writing on the wall and that the next BPA MQ will be the last.

 

What appears to be happening is that the world is waking up to a picture of enterprise process that looks different and has a different set of requirements…. to be discussed in a future post.

Socialist BPM

There’s me sitting in Beijing talking to 2 people from one of our clients, a massive Chinese bank. Slightly odd (to my western sensibilities, don’t take this as any kind of slur) almost military type people, very straight-backed and not even the merest inkling of the tiniest possibility of the smallest chance, that a smile could even begin to ponder approaching their lips…

For a whole 1.5 hours. (which seemed a lot longer…)

However there is always something to learn and this is what I got…

Apparently in many Chinese organisations the whole of concept of a cross-functional process is as alien as it is to some western companies (still…) however their problem is much bigger. You can define a cross-functional process and attempt to implement it, however feedback and any changes you might need to make are going to be painful:

If you’re a middle manager and you see something that should change, you absolutely can’t go and talk to your colleague in the next silo down the process, you must escalate to your silo head, who in the fullness of time may deign to communicate it to your colleague’s silo head, who may in turn pass the info to your colleague. Clearly the message may have become distorted by then (insert your own favourite chinese whispers joke) and may never even reach it’s intended target.

All of which poses some (!) organisational challenges to process collaboration and improvement, but also to collaboration features in software which are probably designed (by western companies) to assume that collaboration is a many-to-many construct. Therefore nobody’s action list gets too big.

The comment from one of my Chinese colleagues was that they were finding it difficult to use the collaborative functionality as about 5 people were getting actions from about 1 million employees….