Between the Dots

When Processes Are Broken, Fault Lies Elsewhere

[tweetmeme source=”ashish_bhagwat” only_single=false]

I’m sure all have been witness to broken processes, sometimes as victims of those.

For instance, it’s not uncommon for customers requiring to call up and follow-up on a pending service request. It’s also not uncommon for organizations failing to make payments just until the point it starts hurting them in the form of penalty, if any. What is pretty uncommon though is for an insurance company making every attempt to close a claim in the fastest possible manner, the same organization that would want to close the sale in minutes if they had their way.

You probably may know by now what I’m getting at. This is one of those process management rants, but let me boil it a little bit…

Business Processes are a sequence or set of activities. They are also typically a bunch of transactions. Transactions are give-and-take, with one party as beneficiary of something – a service, payment, delivery or such. And organization will have business processes of all kinds, with transactions in every process area. In some of them they act as beneficiary, in some they don’t – directly or indirectly.

When a business process culminates in a transaction that has the organization as the beneficiary, they will find a way or the other to keep track of it, and keep making progress. In other words, not let the ball drop. They will have the notifications, escalations, and metrics set up so as to not let the process break. And that is regardless of whether they have automated their process execution through a BPMS.

On the other hand, it’s surprisingly common for the same organization, and same management, and same departments to turn their backs to the processes that may not be directly associated to an output that adds to their measured performance or coffers. And despite the fact that they have automated the process execution, the process may end up as broken. Priorities are not just set up to get those tasks float to attention.

It’s a matter of priorities and not presence of technology. Technology can add value where organization is focused. You can teach and preach Process Management, but you cannot force customer orientation. It’s another matter that organizations continue to harp on customer orientation “as means to” achieve market leadership, but you see that’s the point – as means, not an end. When you see a broken process, problem lies mostly with focus and priorities; not with their ability (technological or managerial) to manage processes.

, , , ,
, , , , , , , , ,

4 responses to “When Processes Are Broken, Fault Lies Elsewhere”

  1. Tweets that mention When Processes Are Broken, Fault Lies Elsewhere « The Eclectic Zone — Topsy.com

    […] This post was mentioned on Twitter by process2go and Ashish Bhagwat, Ashish Bhagwat. Ashish Bhagwat said: When Processes Are Broken, Fault Lies Elsewhere: http://wp.me/pN8i1-5T […]

    Reply
  2. @dougmow Avatar
    @dougmow

    Exactly, this is especially true in the US health care system. There is a short article in today’s NY Times on real time claims adjudication (http://www.nytimes.com/2010/06/27/business/27digi.html?ref=business).

    In the article, Randall Stross talks about a large number of diagnostic and procedure codes. This situation is going to become worse by an order of magnitude when the ICD 10 mandate hits. At that time, BPM driven efficiency is going to require ECM content support as well.

    Reply
  3. Ashish Bhagwat Avatar
    Ashish Bhagwat

    Doug, Thanks for bringing in a perfect example of how this works. Evidently making the process easier is only part of fixing the problem. There’re very specific ways in which various organizations, and inside them, departments add to the problem and the answer is simple: Depends on who the beneficiary is.

    Plus, there’s an additional complexity of internal operations of the company and the SLAs that make the processes ever so bottlenecked – Also see my other post: SLAs Drive Mediocre Services, not Customer Delight! http://wp.me/pN8i1-5D

    Thanks again for adding value to this.

    Reply
  4. Ashish Bhagwat Avatar
    Ashish Bhagwat

    Noticed an interesting discussion that’s got started on Linked In – Under “iCMG Architecture World” Group – http://bit.ly/avYa4m

    Some good viewpoints there on what constitutes a broken process! I’m putting below a comment a made there, relevant for a read in this post:

    —–

    This discussions has turned very interesting, and I actually did not expect some of the accurately brought out aspects to come in when I wrote the post.

    One premise of my post was that organizations many times “don’t even intend” to fix certain processes or build them robustly since, in the micro-context of that particular process organization has to give and not take…

    Second premise being that ability to manage processes is different from the overall business execution capability. One may have an excellent technological capability and management/operational caliber for managing the processes but those won’t help if the intent is not there.

    Some of these echo in the excellent points made above. (and where it seems to differ as David’s first comment highlighted – I sought to clarify that it’s not the overall managerial ability but the process management ability that is referred to in the abstract posted here.)

    One debate is around what would you refer to as “broken process”.

    Well, in strictly process management terms any process that fails to comply or complete as per the “defined” process would be termed as “broken”. In that case you can find fault with the people who are executing the processes or the technology that is being used to enable process execution. This is David’s PoV as well.

    From a more holistic perspective, a business process is expected to culminate in an outcome that serves the customer (recipient of service – internal or external), and in turn the business. And if that doesn’t happen, from outside (considering the internal process operations, or even what has been defined as the process, as black box) it will be termed as broken. (A Service Request that falls through the cracks due to poor collaboration between two related by interdependently running process threads, for instance).

    So, a broken process could be a result of any of the below:
    * Insufficient technological support for tracking, notifications, escalations, or just plain execution of the process

    * An organization structure that is not aligned to the defined business process, where the process participants are torn between the conflicting priorities

    * The defined process is divergent from the ground reality or the way the business operates (too idealistic or just ignorant or standard obsessed)

    * and many more (the list is long actually – And may seem like another blog post here 🙂 🙂

    And there was a point about failing to adopt to the changing ground reality or the needs of the times. Yes, if that is not done, a recipient will not get the desired service and it will be a broken process, or a process that is living in it’s own timezone…

    However, my central argument would remain that despite the ability of the operational – changed the term 🙂 – and technological ability, businesses continue to have broken processes in areas they don’t even want to focus on. And they wouldn’t know through direct measurements as to how much it hurts their business. So it’s not a decision, just a fault!

    Reply

Leave a reply to Ashish Bhagwat Cancel reply