Start a Discussion
BPM
user-pic

What makes a business process robust?

Vote 0 Votes
Read this on the MWD blog: "Clearly, this is a recognition that Barclays does not have in place robust processes."  So what makes a business process robust?

13 Replies

| Add a Reply
  • Flexibility, scalability, durability.

  • Robust in a process sense means it is clearly understood from the top to the coal-face what its intent is, what the goal is, and who is responsible. You have to educate what it means to be a part of a process, not a link in a very long and invisible chain.

    And by responsible I don't mean just a single 'process owner' but everyone who has a vested interest, which usually means the whole organisation and not some silo or functional entity either.

    Its interesting that Mark makes more mention of process management systems to prove compliance rather than process management as a whole. Reliance on automation and system driven checks alone does not absolve responsibility or make something robust. Attitude and education does.

    An ignorant man will still design an ignorant system, no matter how good it claims to be.


  • I agree with Patrick...and Theo. What makes a business process robust? I would add "clarity."

  • Transparency, collaboration, empowerment with accountability.....

  • Adding a few more “Abilities and ity’s” at enterprise level :
    - Availability
    - Reliability
    - Maintainability
    - Usability
    - Agility
    - Repeat-ability
    - Detect-ability
    - Security
    - Data and Process Integrity

    Also features like
    - Consistent high-level performance
    - Self-recovery & Self-repair
    - Anticipated vs unanticipated
    - “Not just strong” - Flexible| Idiot-Proof| Simple| Efficient

  • To be truly robust, a process has to be able to adjust to situations the designers may have never contemplated. So, as Patrick suggests, flexibility is key. A BPM solution has to support the ability for appropriately privileged users to alter in-flight processes to account for business or regulatory changes, or even to allow for simple variances, such as a manager who asks for an additional review of a request before release.

    Flexibility alone doesn't provide robustness in the sense that regulators use the term, however. In that world, robustness implies that any of these atypical process paths be appropriately recorded, reported, or if necessary, restricted. If the janitor is suddenly approving funds transfers instead of the SVP, it's not just a matter of the BPM solution being flexible enough to enable that: it's even more important that the mechanisms are in place to make sure that that flexibility has its limits.

  • Enough people following it so that it becomes "custom and practice". Then is is REALLY difficult to remove / change.

    So now for the far harder question. How do achieve the previous statement?

  • In the context of several recent banking debacles, a question on the
    definition of system robustness is a good question. It's a good question
    because at least one of the banking failures happened at the intersection of
    technology, business process outsourcing and business process management.
    This particular failure (in the UK) was very high profile because thousands
    of customers were locked out of their accounts for extended periods of time.

    Why is "robustness" a good question in the circumstances? Because this
    banking failure could correctly be characterized as a situation where the
    system "lacked robustness under conditions of outsourcing." The statement
    "conditions of outsourcing" gets to the formal definition of robustness.

    It's worthwhile then summarizing a formal definition of robustness, which
    will be an elaboration on Scott Menter's good item above. A system is robust
    if system states and outputs vary proportionally with the violation of
    system assumptions. In other words, when the unexpected happens, a robust
    system should perform reasonably well, as long as unexpected events are not
    too crazy. What we don't want is an unexpected environmental condition,
    which although minor in itself, causes a wildly disproportional change in
    system state and output. In a well-designed system, characterized by
    robustness, small violations in environmental assumptions should cause
    reasonably small, perhaps manageable changes in state and output.

    All well and good you say, that is, if you are still reading this! Systems
    theory is all very nice, and we'd all like to have robust systems, but gosh
    darn it all, isn't that what we pay the outsourcing company for?

    For the case in hand, this sort of hands-off approach might have been the
    problem. It's a type of "magical thinking". Because when an organization
    takes responsibility for building a system, it is always the case that you
    can never model all environmental states in which your system will operate.
    Modeling everything is both technically impossible as well as financially
    infeasible.

    Therefore, given that all systems are constructed in circumstances where
    assumptions are guaranteed to be violated, the question of robustness is a
    question for any system sponsor, from the get-go. How much are you prepared
    to invest in modeling and researching your environment, in support of
    minimizing your risk? And how much are your prepared to invest in software
    construction which has the characteristic of robustness?

    Lastly, what then is the performance of robust software under conditions of
    unplanned environmental events? We have said above that the software should
    react "proportionally". If someone in an BPO situation runs an overnight
    bank account updating job incorrectly, this error should not result in a
    lock-out of thousands of account holders, with the attendant bad publicity.
    Running a bad job, which violates the assumption that humans will always do
    their jobs correctly, should only require that the job be re-run, and
    perhaps some proportional remediation.

    This note has been rather longer than I planned. But I believe that the
    field of BPM is enhanced when we make the effort to clearly define the
    terms. System robustness is critically important and should be a key agenda
    item during planning for any new system.

  • Thanks Peter for picking up on the post and posing the question.

    In this context, I am not a mind reader, so of course I cannot know what Bob Diamond was referring to, but I can talk about the way I might interpret it.

    Firstly, I suggest we step outside the process domain to think about robustness and instead think about children's toys! Young boys are notoriously rough when it comes to play, so when choosing toys we think of things that will stand up to a great deal of punishment, continue to work even when misused, will last for a reasonable period of time, are able to be simply understood and used etc.. you get the idea, when thinking what a word might mean then let's look outside the process domain and see how it is used and then apply those characteristics in the process domain.

    So most of these would apply to process fro me. Especially the area of misuse or abuse, the Barclays processes clearly did not stand up to abuse and misuse and so might be seen as failing at that level.

    With regard to Theo's point about process management, I stand by the fact that they needed a good process management system, however this is not the same as a process automation system, which may or may not have been useful for parts of this process and which I am not sure that I did refer to?

  • I would say, the robustness of process means: there're robustness of loyal users, lower adoption rate is usually one of common failures for BPM projects.

    The robust process also means there's risk management well embedded into process, to make process and business as a whole more resilient.

    The robust process also usually enable innovation, empower employees, and deliver measurable business result. thanks.

  • I love this thread! There are at least two uses of the word "system" here, and confusion about that is one part of what makes this discussion a little hard to follow.
    When some people hear "system" they immediately think of IT.
    John and Mark, I think, are referring to the much broader concept: " (1) A set of connected things or parts forming a complex whole, in particular. (2) A set of things working together as parts of a mechanism or an interconnecting network." Those things could be people just as easily as IT components.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT