The Eclectic Zone

SLAs (Service Level Agreements) are great way to manage contractual obligations. They bring meaning to the definition of the service quality as a tool for agreement between the service providers and their clients (note, no end-customer here). So, that’s what they are – a measure of how often is the service provider meeting the “agreed” levels of services.

One would hope that SLAs would bring the much-needed quality of service in business, but that’s unfortunately not the case.  They are just not geared for “customer happiness”, They are designed, and used in a way, to keep the management from frowning!

How are the following for service quality? (we’re speaking customer experience here)

• Your wireless network goes down in the middle of an important email (Murphy never takes a break, remember!). You retry incessantly for five minutes, & then call up the customer service. You mention that this email needed to go out in the next five minutes, while you’d have already wasted 15 mins reaching them. The most polite (they are trained to be so!) voice says that the complaint is being “logged” and you could expect a response in the next 2 hours! And, the resolution could take “up to” 24 hours. You regret having called them and spending the last fifteen minutes bothering them instead of running to an internet kiosk!

• They implement a fantastic automated service management application, that is to help you from having to call someone and wait on hold etc. AC goes down, you log a call, an automated email response tells you that you would receive “the response” in the next 2 hours from some humans, and that this particular category has an SLA of 6 hours. Don’t hold your breath! Wait, you can’t scream because there are no phone numbers – the system is automated, you see!

• Your mobile service suddenly stops working. No dial tone. You call them. First up there’s a problem getting to the right menu because the phone you’re using is not registered with them and doesn’t belong there. When you get to the right person/menu, complaint is logged. You wait for the resolution. When you can’t hold any longer, you call again, go through the same trouble, but when you actually get to speak to someone, you’re told that the complaint was auto-closed at 4 hours SLA because they were not able to “reach” you. Well, there was no dial tone, and that WAS the complaint! How stupid can services get?

And these stories have become so common place that any freak resolution, exactly when I need it, makes me mighty delighted.

SLAs hurt customer service more than they really please the customers -

• If you have a 2 hour resolution time for an urgent service request, with a penalty and management attention for every violation thereof, most urgent requests “will” actually get attended to for completion within 2 hours. Not on As-soon-as-possible basis.

• Most SLAs now have multiple stacks and categories for application of the thresholds. It’s common to have first Response time SLA, resolution time SLA, Call closure SLA. It seldom seems to matter as how well the response was provided, whether the resolution really attended to the actual problem or whether the call was closed with the customer being “happy” with the service.

• The feedback channels for the “Bad Services” are mostly shut out of the systems. Most times you get to the feedback upon satisfactory closure of the service. It’s also startling to see that the “direct” escalation channels for a particularly bad service just don’t exist in most places. One hits the same customer service rep time and again.

• The whole concept runs on statistics. Higher the volumes, more robotic and mediocre the servicing behavior becomes.

• The mechanisms for getting the customer what they really want (in order to be mighty pleased) are minimal to non-existent in the SLA driven world.

Looks like, everybody is just happy serving their customers at their levels of agreement, and don’t work to please their customers. Are they training us to not expect good services and please us with one once in a while, who knows! As far as I know, SLAs (or with a benefit of doubt, badly designed ones) are the root cause of mediocre services.

Any-whichever way we look at it, technologically or as a way to make businesses better, BPM-the-social-way is much more than what Social BPM seems.

Keith Swenson, when asking ‘Who is Socializing in Social BPM?’, raised a pertinent question and stated that

If you think of BPM as a kind of application development (i.e. develop process applications for use by business people) then using social software to help with the development of applications means that the developers (i.e. process analysts, programmers) are the ones using the social media to make them more effective.  It is the developers who are socializing.

As for BPM being treated as application development, I blogged some time back to Not Treat Process Solutions as Applications. So, my point of view is very clear that BPM is not an Application Development approach. Refer my other posts on Defining BPM and BPM Ecosystem also on that.

There has been some real activity around collaborative process design environments (such as Alignspace, BlueWorks). Most have been quick to call it Social BPM. Well, that could be, but part of it.

In the whole lifecycle of BPM, Process Discovery or Process Design is only the beginning. And my experience shows that spending more effort than required in process discovery without really doing anything about executing the (right) process doesn’t get one anywhere.

So far as I can see, these collaborative techniques around Process Design may be making the templates or process resource repositories richer right now. Of course there are actual and live process discovery projects being driven on these platforms, but all that is just a tiny portion of what all could be made possible with social platforms and BPM coming together.

Social BPM is a shortened term (and could be a misnomer) for what in actual interpretation should be “BPM leveraging Social Networking technologies, disciplines and contexts”. Now, we can mix and match this with various ways in which BPM can be done and get enormous leverage. I had earlier blogged that in the context of how it related to BPM, Social is a Phenomenon that should enable BPM and supporting technologies to collaborate and synergize better toward customer centricity.

Forrester’s Clay Richardson, here, maintains that, Social BPM, apart from collaborative process discovery, delves also into more collaborative Process Development as well as better optimization techniques such as enhancement tagging. He does go on and cover the lifecycle, but lot of it still sounds a lot like an IT side of the story.

The objective of business process is to get the expected throughput as efficiently as possible to the beneficiary of the process, namely, a customer. It is here, that I will diverge slightly from what Keith mentioned that the way to conduct business should change in the sense that customers become part of the process in getting the end-product. I agree to that, but there would still be whole lot of business processes that traverse within the organization before they eventually end up with the customer. You still have lot of opportunities for dealing with the processes in a traditional way with better social leverage, even in that quantum leap context.

Take, Retail sales call centers, for instance. It is not uncommon for multiple calls from the same company to a prospect within the same day or over few days. Customer ends up repeating the same thing over and over again to every one of them. In a social leveraged environment, this simple process can be made enormously more effective with the tagging of comments from the customer, so that any other rep working on the same list can accordingly act on it. Simple, but effective.

The same applies to customer services. It’s evident that every request or complaint, when traversing through multiple routes and through various stages, keeps losing the context. A more efficient collaborative process (within the company or even involving the customer) should prevent the information loss through the process. Another great way to make this more efficient would be to use the available tools (similar to, if not the same) such as Twitter, Facebook. A lot of companies are already using Tweet hash tags as a funnel for the possible complaints (except that they choose to automate the ping – hey do you have a problem – part right now!). And there are many other ways to leverage these.

Another area that appeals to me is on managing, optimizing and automating business rules. Most business rules go from completely manual decision making to completely automated one over time by the system (or someone in the system) recording the most commonly adopted practice by the experts that become policies and then fixed and then automated rules over time. A simple “FB – Like this” kind of a feature can be internalized within the system every time an expert makes decision in the context. It’s pretty much an artificial rule automation intelligence built around simple tagging mechanism.

I also see the mash-ups as a great mechanism to pull together all the information that the process participant would need while completing the task. Even better, the widgets could be driven by the user choice than dictated by the process. In fact, some of these things don’t need to be captured in the process at all, only the scope of what the participant may or may not be able to include in the task/activity.

There are plenty of ways in which the process paradigm should drastically change as we embrace social networking as the way of life for process participants. However, the BPM vendors would need to also decide which capability of the product they need to “not bother about” rather than building all the technological components within the product. They need to leverage certain basic and simple technologies available elsewhere better, and that’s why I earlier said that social is a context setting in which we should expect the BPM technologies to synergize better for customer centricity. I think that’s what Sandy is also hinting when referring to 2.0 Reality Rehab!

Time to don our Green and Blue Hats! BPM-the-Social-Way is much more than what Social BPM seems right now…

Frankly, I don’t like that “v/s” thing between Case Management and Process Management – because the way I see it, everything could be a case and everything could go through a process. It just depends on how you look at it, and how you “intend” to handle “things”.

Take, for instance, Service Requests, one of the most prominent use cases for operational efficiency that BPM drives. You go to a company, preach them process adherence, and you get efficiency by training people on sticking to the process. (Of course you’ve got the tool that gives you all the capability: model – execute – monitor – optimize). You go to another company, the culture is different – they want to handle every case on its own and give its due importance – especially given the possibility of Fraud. You end up doing Case Management.

What this tells me is this. There are tools that have capability to do Process Management in structured manner, and there are tools with capability to perform dynamic case management. What you need depends on how you want to treat the situations and incidents. You want Case Management culture or Process Management culture – that’s the key. Everything could be treated like a case, and everything could follow a process. What do you want?

PS: Most of the time, it’s not an either/or scenario. A Culture that promotes Process management still needs Case Management, and vice-versa.

A quick update on what’s up at Eclectic Zone…

Last week, I have started blogging at Redux Online as guest blogger. I feel excited about being able to share my thoughts through more channels.

I already have few posts there, check them out!

• There’s one on BPM-SOA confusion titled “And We Thought BPM V/S SOA Blur Was Already Beaten To Death…” where I illustrate through an experience as to how this confusion plays out in reality.

• And there’s one on the fact that the various styles of process management (including case management) have existed for some time, I refer an old picture from Gartner. The post is titled “Old Wine Sells For Itself, Who Needs A New Bottle?”

I have also been commentating at ebizQ and on other blogs – I think I will add the blog roll here sometime soon.

Highlighting some posts that have been most popular here:

Is this Data for BPM?

Do not treat Process Solutions as Applications

Defining BPM and State thereof – The Perspectives at Play

BPM Ecosystem – Blurring Boundaries or Systematic Convergence

Which flavor of COE is right for your Enterprise BPM Strategy

BPM in Cloud? Really? Not anytime soon…

Dynamic Process Capabilities are powerful, but use with caution

Thanks for being with me. Keep coming back and share your experiences! There’s a lot to come and I guess I have just started

In what looks like a new standards wave that IBM wants to drive after BPEL, they have published a new research topic and a wanna-be standard called BEDL (Business Entity Definition Language), the theme is named Data4BPM.

This is just Part 1 of what we’re going to see in a series of four parts. So, some of my comments could be premature. But later won’t be timely enough!

They start off on the right foot when the authors say –

In most business process management tool suites, data is treated mostly as an afterthought. Activities and their flows are the main abstractions and the data manipulated by the processes is essentially hidden in process variables. The presentation and aggregation of data is handled outside of the process definition, and implemented through generic service calls. This process-only approach ignores the important data perspective during business operation analysis, often obscures key aspects of the operations, and can lead to costly re-factoring throughout the solution life-cycle.

I agree to this in parts, not verbatim, but somewhere we do have a consistent concern on handling the UI and data aspects when dealing with BPM solutions using a process layer on top of existing systems and applications (Pl remember this as I’m going to revisit this point). I had highlighted some of these in my post “Do not treat Process Solutions as Applications”.

The research paper introduces the concept of Business Entity and the four main components (Information Model, life-cycle Model, Access Policies and Notifications model), provides examples around Courier Shipment and provides certain details (sometimes somewhat superficial or high level and sometimes getting to the details of hinting at what XPATH could achieve in a situation) around the structure of BEDL, how it can work with BPEL or any other execution language, and of course advantages of using BEDL.

I’m not sure what they are trying to do, except for one (fear) that it may spin-off another industry or set of products (may be within IBM?) that would be looking for the white space in an industry that is already overcrowded with such noise.

Here’s why?

One, the concepts being introduced here are not new, and in fact, done and dusted with in most enterprises that look at data as a critical aspect of operations management. What is being proposed here, as a component that really addresses this standard, is already implemented in many organizations along with the data architecture and data governance. There are more comprehensive sources available on Data modeling, data architectures, and how they can be addressed in Enterprise operations.

Two, if one assumes this is only in the context of BPM, one needs to understand that Process Layer can sit on top of existing applications through some hooks and plungers, but the data control layer needs to sit under the applications and systems that process layer integrates with. Big difference! It is difficult to imagine the implementation of this standard at the process engine level unless it’s a green field. And this article dodges the question on the non-green field implementation and put it on the lap of “Linkage Data Persistence” that is still under research. So, this standard doesn’t really address the real concern, the one that I brought up earlier in the post (remember?).

Three, in the context of what BPM vendors  need to do, you cannot expect them to drop everything they’re doing and jump to this, especially when this ends up becoming more of an implementation level item as against the product design level. Any product design level changes will also not happen just because you have a new standard. In fact, most of the concepts being introduced here are not alien to any product architect, there just isn’t a way to really address this in conjunction with the target enterprise architectures. And obviously vendors had their own priorities and constraints.

Having said all that, I think there’s one reason that vendors as well as organizations would move towards data and resource oriented architectures, and that’s because of the unstructured process and collaborative operations getting better attention. A state-event model, or Event driven architecture are conducive for business entity driven data models. With the industry taking note of the impact of such business problems requiring solutions in case management, complex event processing, dynamic process management, etc. this effort to revitalize the Data Architecture may be timely.

Or maybe it’s not just a coincidence and IBM is indeed making conscious attempts to address this market with ACM and BEDL, will know soon with IBM Impact just around the corner!

But, standard? I wanna-be yes, but wouldn’t call this one really yet! This is Data modeling redux. And please do not call this as Data4BPM – right concepts but not applicable to current state of BPM!