The Eclectic Zone

During the #crmjam organized by Forrester few days back, concerns around silos came up too frequently to ignore. The challenges around silos were brought up in different contexts, which I have tried to capture below:

• Departmental silos  not helping the customer objective

• IT working in silo while creating the solution to business problems

• Technological silos and communities working in isolation toward the next big thing in their areas

In my previous posts on Convergence in BPM Ecosystem and on using the social networking context for better technological synergy, I have addressed some aspects around convergence and synergy across various technologies and disciplines.

Behind the Organizational Silos

As for the silos within the organizations, it boils down to plain WIIFM (What’s In It For Me?) thought process, the way organizations measure performance and the type of behaviors they encourage.

Businesses do a decent job in defining their own objectives at high level. Then, based on how they are structured (most are by departments and functions), the objectives get broken down into what those sub-components of business are supposed to target. So, it comes down to quantitative and qualitative parameters that the functions are measured against, which are aligned with the strategic objectives beautifully.

In the world of machines, that might work well.

But, we’re dealing with people like you and me! Here’s what happens. For every function (read, people leading the function) there are a set of objectives. One or two are the primary, and others are equally important, but not so primary – calling them secondary would be inappropriate. For instance, sales are responsible for revenue and margin. Operations are directly responsible for Efficiency and Throughput stuff. Business actually “expects” Sales to be equally responsible for the bottom-line as well but someone else (here Operations) ends up being primarily responsible, why would Sales care!

Measurement, Expectations, Inspection, Incentive Alignment

It’s not difficult to find out what’s happening with these objectives. Everything gets measured, data exists for everything but a typical sales review will typically consume 90% to 200% of the allocated(!) time on revenue & related parameters – sometimes Margins, and seldom on customer satisfaction or Defect Ratios. So, that is one problem – even though everything gets measured, questions are asked only on the direct parameters for the function.

The expectations on synergy are conveniently overlooked because “People only do what you inspect, and not what you expect!” (I think I read this in Lou Girstner’s Who Says Elephants Can’t Dance?)

But even if you indeed start inspecting (read reviewing and grilling) these functions on those indirect objectives too, it won’t make them do any bit more on such objectives when they get back to their offices. The reason? Incentive.

In whatever ways the performance management process, compensation reviews, bonuses and incentives are worked out, it is almost always on the basis of direct objectives for the function that the leader or worker belongs to. There’s simply no (direct) incentive to collaborate and synergize. And to complicate this further, this also works like a racket where the bosses want their area to look clean and sweep the dirt from under the door to the adjoining ones that are supposed to be their primary collaborators!

The incentive, to act in a particular desired manner, may range from financial, social, or even moral. Many companies use the integrity and social cause messaging to tame the unethical and unsocial behaviors. And “to collaborate”, primarily falls under social incentive and sometimes promotions also have this built in – with the clause on acceptability among peers. In reality, collaboration factor ends up being a manipulation tool used just enough to get you across the line, while your primary objectives still remain the focus.

What can be done?

How can we solve this conundrum? Here’s what I think:

• The linkage between the business objectives, departmental objectives and their underlying KPIs need to be more clearly identified, defined and measured. Clue: Look at BAM, Analytics. KPI has “Key” not without a reason!

• Process Way of thinking needs to go beyond the departments. BPM can help achieve some of that by putting a Process Layer just enough to tie in those disjointed systems. There are ways to get this done with BPM methodologies without spending a whole lot of money in redesigning the systems and processes. Clue: Look for visibility and tied-in processes, leave other BPM mumbo-jumbo initially.

• Think hard on performance management process. Is the performance being measured on conflicting objectives across various departments? Is there any alignment possible? Clue: Think what customer would want that department to do in a typical scenario. Leverage Process flows to drill down such scenarios and simulations – they may not be processes but would still work for getting the required visibility on conflicting (and not aligned) expectations.

• Translate the “expected action” into an “incentivized action”! Fuzzy? Clue: Go back 4 paras and read again!

• Reading Freakonomics & Superfreakonomics may help!

PS:

Too many words…? I know my tweet during the jam looked like:

{“Incentive Alignment” <- Objective Setting <- Mgmt by Objectives <- Strategy align} + KPI (Ppl do what u inspect not wt u expect)

Yesterday in Forrester #crmjam on Twitter, Social (networking, not cause!) aspects got a lot of attention. Theo correctly points out the possibilities of convergence between BPM and CRM. One of the converging points, as per him, is around social BPM and social CRM – again correctly.

During the same jam session, I tweeted about the fact that “social” seems to be an underlying theme around lot of disciplines/practices/technologies. And, in this rare event when we had folk from BPM, BI, and Collaboration towns of the world trying to collaborate with the CRM cause, we still were using terms that ended up pointing back to our living areas or “silos”. So, I wondered why we continue to look at the themes as Social BPM, Social CRM or Social XYZ (where XYZ could be any technology or discipline). My note there ended with a statement – “Social is a Phenomenon, and not a discipline”. (And I ended up committing to Connie and Clay that a post on the same is coming up, so I had no option but to post this )

So, this point actually aligns well with what Theo pointed out that social could be one underlying theme that could make some of these traditional silos to work together.

However, when we start looking at social aspects as the phenomenon, and not tie with a separate discipline, it has ramifications for better, such as:

• Social BPM or Social CRM will not look like a destination, but a context-setting for the passing set of events of current times

• It will prevent us from creating further sub-silos within our current silos (Social BPM under BPM, Social CRM under CRM), and hence help converge than alienate

• Social as underlying theme or phenomenon will help us focus on the actual objective behind the concept – that is, collaborate in the best interest of the customer

• Hopefully, prevent duplication of effort across disciplines (Do you really need a separate collaboration technology for usage in BPM vis-à-vis CRM or anything else?)

• And, save us from wasted energies in new terms, clarification of those, and more saving in terms of getting rid of those when this context-setting phase has passed.

What should remain – when we are done with this phenomenon –  is the set of disciplines that are better placed to collaborate and synergize toward customer centricity.

We had an active discussion on ebizQ and on LinkedIn in Gartner BPM Xchange group on whether we have reached a point in BPM where only incremental improvements are possible.

Peter’s Q on ebizQ: has BPM evolved to a point where only incremental improvements can be made? Does innovation need to be re-introduced to process design?

And Elise’s Q on LinkedIn: Has BPM evolved into just tweaking and incremental improvement? Did we dump the baby with the bathwater and lose the innovation that came from BPR? How do re-introduce innovation in process design?

My reply on ebizQ turned out a little long, so I thought I’d reproduce it here as a post – it reflects some of my thoughts on BPM itself as well as how organizations interpret and use BPM.

So, here it is:

I’m interpreting this in two ways:

- Is it no longer possible to have the big leap improvements like the ones made popular by TQM, JIT, BPR…? And if yes, is it due to the way BPM has evolved or to the point it has reached?

- Has the BPM technology/Discipline/Approach reached a point that it cannot make a big leap? Is incremental (not disruptive) innovation the only way forward?

Answer to both is No.

Process Improvement that can be done incrementally on shorter (and faster) spurts have been primarily enabled by BPM. The way the business has always been run it was always desirable to be able to make changes efficiently and not with huge costs and effort. Business Agility has always been valued. In the pre-BPM era the overheads associated were much higher, so a larger goal had to be often targeted to offset some of those big fixed and overhead costs to do with change. With BPM, came that ability to make incremental improvements, and businesses latched on to it.

But that’s not to say that the big leap improvements are not possible with BPM. I have seen big initiatives involving major turnaround in the processes – enabled at core by BPM. But those are rarely advertised and sold as huge initiatives – with the prying eyes everywhere in these Q-to-Q era. The larger goals are broken down into incremental improvement initiatives and we should be thankful for BPM to enable that. But, it doesn’t mean that we cannot have big leap improvements with BPM (in past, at present, or in future), it’s just that those might not be advertised as such.

Second part regarding BPM itself is relatively easier to refute. We are at a point of time which is most conducive in recent few years for big leap innovation in BPM (as technology as well as discipline). Actually, I feel that major part of the last few years since the first few burst in BPM, technology vendors as well as approaches did not have major innovations. Variety of reasons: milking the initial investments, consolidating their positions, experimenting with caution due to lack of maturity, and as mundane as just sitting as acquisitions targets…!

We’re now in a time when a lot of those reasons are slowly making their way out. Consolidations are happening, and may continue but majority of the potential ones are out of the way. Positioning of BPM related technologies have gotten more stable in Enterprise Architecture. And one of the major aspect being that the converging lines are getting clearer (see my post http://wp.me/pN8i1-30). We see many supporting and converging factors (Emergence of Web 2.0, Collaboration, Social Networking, Unified Communication, CEP, Cloud Computing, advances in analytics) that will almost force such innovation upon BPM ecosystem.

I’m sure such leaps are still possible, and actually will happen. And if Incremental Improvement is so much loved by business stakeholders, it’s not because BPM cannot do otherwise, they just like it that way!

I think we’re in for exciting times ahead in BPM…

I read with immense interest, the point made by Theo on how salesforce.com fluked the BPM model right and Jim’s post on Heathrow airport case study.

There are two reasons I found these interesting. One, both of the above make a similar point on what makes up an effective BPM solution and Two, and more importantly, none of the two might have actually started off as a solution qualified as a BPM solution.

The second point is very important and probably one of the most important questions that we all, in BPM community need to delve on. I have seen many a successful BPM solution that has been more so in hindsight. And a lot of hyped up solutions/initiatives that started off as BPM solutions ended up as duds.

So, how do we qualify a solution as a BPM solution or a problem as screaming out for a BPM solution? Sample some of these:

• A bank looking to unify their customer experience on sales and services across the product catalog. In the stack, apart from the portals & collaboration technologies, we have an important placeholder for workflows, orchestration, & integration. Vendors in the short-list – Platform, Case Management, Pure-play BPMS, & other internet channel vendors with backend capability on integration and workflows. This one doesn’t go to the BPMS vendor. Is this a case for BPM, you bet! Why would a BPMS vendor lose out? Hmm… (And interestingly, it happened in at least two places with the same scenario playing out again, with the same result and similar conclusions)

• A telecom giant from one country and an infrastructure behemoth from another form a venture to offer telecom services in one of the two countries. The Telco brings in the processes from experience, and starts laying down everything from scratch (almost) in the new place. The series of workshops ensue around processes, the scenarios, the best practices, the technologies; and finally around the vendors that could come down and get those running in possibly a record time with their off-the-shelf solutions. Process models are created in Word, Visio, Power point and whatever made sense for program teams. The flows would go everywhere, from Siebel CRM to Oracle stack to Kennan. Launch happens, everyone is happy. Successful story for BPM? You did processes, yes, very well… and did you use any of the BPM (or supporting technologies), actually in hindsight. But does anyone look at this as BPM? In hindsight, some do. Well, did they qualify it as BPM at any point of time? No.

• A very successful directories publishing company, facing immense demand & cost pressures thinks of an innovative way to get their artwork done (all of us would have seen the different types of ads that appear in the yellow pages, a lot of them have artwork involved – the kind one would get professionally designed from ad agencies). Once the sales rep closes a particular requirement with a customer, the scanned copy of the sketch, along with a bundle of requirements and specification is outsourced to a more cost-effective studio, across continents. The collaboration happens for thousands of those artworks, with varied degrees of complexities and in time for the publication to be done for the city. This happens for every city and state covered by the company across the year with calendared publication. Central to this collaboration is a strong workflow engine combined with an equally strong content management system. All done in-house over two years. BPM? Oh, yes! Did they call it so, now they do 8 years after they did it!

• An Insurance company, after years of establishment and successful operations, decides it needed to re-define the processes. Redefine? Well, know what’s happening on the ground, across divisions-across geographies, record everything, find out what could be done better, and do some refinement. Sounds simple? No, scary actually if you consider the hundreds of ‘identified’ processes – not to count variations. But, wait, you have these BPA tools & all of our technologies that would make this easier to collaborate and work out the models across the geos and divisions. Well, BPM to the rescue. One year down the line they were still drooling over this, trying to make some headway. But, in the mean-time, some one, in one of the divisions went ahead and published the process models using PowerPoint, SharePoint and some tweaking with .NET? Everyone jumps, calling it an achievement. Successful for sure, call it BPM – in hindsight. Was this one done the way we like calling it BPM technology or methodology, still drooling…

• A big telco decides to re-architect its whole stack. Yes, the whole stack. Huge program, crossing multiple towers, with two distinct towers dedicated to the BPMS, Integration and Process Definition. A deeply involved exercise on platforms short-listing ensues and decisions made. One of the leading Integration vendor and another leading pure-play BPMS vendor selected. The methodologies, architecture, design, process implementation – all follow and with some brilliant minds involved, 1 year hence they go live with bunch of processes. A whole bunch of BPM practices followed, and whole bunch of them just scrapped or left in a bin (leading to some noise by hard-core BPM folk but work went on). All goes well – esp. in the context of the ambitious plans involving lot of bravado. BPM? Yes. In intent, in Design, in execution, and in result. Is it publicized as much as one? No.

Few more examples are doing a ticker in my head, but I think these are sufficient for me to come to the point that I’m making. It’s not so important to qualify something as BPM, for it to be a successful BPM implementation.

We see a whole lot of energy being spent (within the customer/vendor/SI/consulting organizations, and among analysts & BPM community) on qualifying the initiatives as BPM, identifying the best practices and trying to enforce them. I’m not saying that it’s not important to identify and follow the best practices. But, what’s important is to remain true to the BPM drivers and objectives. And that is, to make an impact on customer experience and measurable parameters that really matter. If you do that, you will end up doing what’s best for the objective, call it BPM then if you wish! Pre-qualification of a problem (as a BPM candidate) or solution (as BPM implementation) isn’t as important as it seems, in hindsight.

Human Centric BPM, Integration Centric BPM, Collaborative / Social BPM, Content Centric workflows, Simulation based Process Improvement, Lean approach for BPM, BPM for Rapid Application Development, BPM for Composite Business Applications, BPM in Cloud, Platform vendors acquiring Pure-play BPM vendors, BPM vendor acquiring CRM vendor, Outside-In v/s Tactical BPM v/s Agile methodology, BPA and BPMS interoperability,… (Headache!)

The list goes on. In the initial years of BPM, we thought we had few problems that would slowly disappear with maturity in the discipline / technology.

Come 2010, and we are dealing with more variants and more convergence areas. Depending on where you look from and where your stakes lie, this could be a case of blurring boundaries or of significant convergence in BPM ecosystem.

I will not waste a lot of time spitting blabber as my statements will start blurring into each other

However, I have attempted to visualize the situation through this –

BPM Ecosystem - Blurring boundaries or systematic convergence?

So, we have various paradigms all blurring the boundaries. The circles of BPMS (as Software and as Suite) are expanding (as depicted by outgoing arrowheads) to include more and more of what we need to make BPM work in real life systems and processes. On the other hand we have the business domains and disciplined pushing to align the technological progress with the needs of business.

Pictures should speak a thousand words, but in this case I find it still difficult to say all I wanted to through just one graphic. Well, I got limited by the space and dimensions in a similar way as our process models’ inability to satisfy all stakeholders views and needs! Well, I could not somehow significantly illustrate one big gap that divides the BPM fraternity – and that is between business paradigm and technology paradigm – difficult to understand the conflict actually, since all mutually need each other!

Anyway, what looks like a “blurring of boundaries” otherwise, to me is “a systematic and very methodical convergence” of complementary disciplines and technologies around BPM. I see it in the picture above, do you? And can we all “converge” and leverage on our best opportunity in recent times to really take BPM to where it belongs?

There’s been a lot of talk about Social BPM recently (with IBM’s Blueworks and Software AG’s Alignspace being two notable efforts in that direction), and there’s enough buzz around collaboration and BPM in cloud (BPMS-in-cloud is more appropriate term to use as I noted in another post, but important nevertheless).

As for social BPM (now, even that term needs some demystification – but more about that later), most of the focus is around Web 2.0 and social networking. It’s amusing that Unified Communication (UC) has been overlooked. Or it may be hinted upon when someone brings up, say, telepresence or video conferencing but ignoring the fact that there IS much more than just that. UC community, on the other hand, is pretty articulate about offerings in Business Process Integration.

UC , by definition, is integration of real-time communication services with non real-time communication services. These real-time communication services could be very diverse such as instance messaging, telephony, conferencing (audio & video), telepresence, and even presence information and speech recognition. Non real-time services could be emails, fax, SMS, voicemail and unified messaging environments. In other words, UC allows an individual to send a message in one medium and receive on another. One can also receive the message (say, an email) in one medium and access it using another.

This can be really powerful technology for enabling reach of messages regardless of the recipients’ location and availability in a particular medium. For instance, a notification of SLA violation could be sent out just once, but made available to different people in their preferred medium (or the one driven by a set of rules governed by time of the day and the preset calendar).

How does this become crucial for achieving a social BPM objective? People may not be always available for a particular collaboration instance at the same time and place. Now, Social media are mostly targeted to make the real-time and non real-time collaboration possible and effective. Social media do their bit in terms of bringing people together on some of these media. But, a whole lot of duplication of collaboration effort can be reduced drastically when such media are powered by UC. You see?

There’s a lot of progress on UC, and some vendors like IBM, Microsoft, CISCO are already offering these services. It’s a matter of making them available and leveraging them. Beneath this, there is even more work happening on what is referred to as ABI (Appliance Based Integration). UC and ABI could become the fact of life not too far in future (without many of us being consciously aware of underlying technology) – just as we use VOIP phones or Skype today.

So, I’m convinced UC will play a prominent role in (social) BPM as well but could it happen just underneath the surface, again? Or would we benefit more by making conscious attempts to leverage it right from now?

To have capability to define and execute dynamic processes on the fly is really powerful, and we see a lot of progress in this area. This support for the dynamic processes or Ad-hoc process definition could also gain more relevance in a collaboration driven businesses, and in lot of new areas  where BPM has traditionally not been actively pursued.

However, I faced a situation that keeps me warned of an undesired implication of such capability. We had a similar functionality built up at one of our BPM implementations wherein the exceptions were supposed to be handled by kicking off a quick dynamically created sub-process. When faced with a scenario that the defined process didn’t handle (quite possible in early cycles of an interactive and incremental BPM approach), the user could define a sub-process right there from the execution browser and kick it off. This was pretty innovative and users really loved it.

And they loved it a little too much, this seemed like freedom! We saw these ad-hoc processes kicking off everywhere. One of the business managers even came up and wanted that capability built into every activity throughout her processes. We had a hard time convincing the users for not using it with such indiscretion, and rolling back this feature became nearly impossible even after processes became more mature in those particular areas. The problem is that none of those processes had any characteristics of being unstructured or dynamic.

Such dynamically created processes are difficult to manage, the metadata is inconsistent, one finds it very difficult to benchmark the processes and define KPIs. And process adherence becomes a huge challenge.

So, one has to be cautious with such capabilities, here are some of my suggestions:

• Draw a balance between process flexibility & process adherence objectives. You want user-friendly processes, but the rule-books cannot go away. Process flexibility cannot be at the cost of process adherence.

• Consciously and carefully evaluate whether the processes in question are truly dynamic. Apply the dynamic process kit only at the processes that show the characteristics of being dynamic.

• Question why those processes are dynamic? Is it due to the weaker process adherence culture? Are the variables causing the process to be dynamic out of your or organization’s control?

• Do you have a well-defined Process Exception handling approach? Sometimes, a standard approach to exception handling helps tame uncontrolled exceptions floating around.

• Define the roles that would be able to make the changes to a running process. Simple and obvious, but still very important.

• Remember that just because users like something doesn’t certify that as a good thing. Users know what they do, they know their processes, but they may not know what’d good for their processes and organizational efficiency.

With some caution, we could prevent the right & powerful solutions from being applied to wrong problems, Dynamic process kits are meant for truly dynamic & unstructured processes only.