We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is it Possible to Create and Sustain an Enterprise-Wide Framework That is a Single Source of Truth About Process?

Vote 0 Votes
Is it possible to create and sustain an enterprise-wide framework that is a single source of truth about process?

8 Replies

| Add a Reply
  • I have two opposite opinions within myself.

    1. Modeling the entire enterprise-wide processes should be very complex. And processes are ever changing. I'm skeptical if anyone could ever finish such a project.

    2.There are very common business processes, verifying and registering parties (suppliers, customers, employees), transferring money, rolling up hazardous substances, etc. For such business processes, why every enterprise should have a single source of truth? A single source of truth on the earth could be enough.

    What do you think?

  • This question can be answered from a number of different perspectives, because 'process' means something different form different groups across the enterprise.

    We recently wrote a blog called "What Hat Are Your Wearing" http://bit.ly/bFYCQF which looked at process from 4 perspectives
    Green Hat - end users (operational manual)
    White Hat - IT (information architecture)
    Blue Hat - IT system (transaction)
    Red Hat - Compliance (busniess controls)

    Each group wants to have a single source of truth that is consistent and agreed within their domain.

    Take the Green Hats. There is huge value in every one having a shared, understood and adopted set of processes (working practices) across the world. But before you start shouting at me, of course there will be local differences, but lets keep those down at the lowest level of detail. So every retail store working in the same way. and when a better way of working is discovered, every one else gets to benefit; new product releases, customer returns, stock takes, staff induction, resourcing for Christmas rush, credit card fraud and the list goes on. If you want to see this in practice watch this video http://bit.ly/csfpln

    The same approach could be said of the White Hats. The company wants only one Information Architecture and as few applications as possible, ideally not customised for every division, department or country operation.

    And the Blue Hats and the Red Hats.

    So the question is can you have a Single Source of Truth shared across all 4 coloured hats. If you are small organisation, then the answer is probably yes. But if you are a major multi-national, which is most of Nimbus clients, the answer is no. You may have Green Hat models for each business unit, one White Hat model, one Blue Hat and a Red Hat for each Green Hat model.

    What is CRITICAL is that each model has linkages with the others, so if one changes the impact on the others is easily identified and understood. This can be achieved by a single tool/application/repository with each Hat making some compromises as to functionality. Or is could be 1 or 2 tools with integrations.


  • It is possible but not useful unless that unifying framework is a proper Enterprise Architecture which adds technology and human resources to the picture and assigns distributed ownership of processes to stakeholders (for maintenance).
    The EA and BPM function should work together.

  • Considering that process is pervasive across an enterprise it touches everything from people to applications. Entangled in processes are controls, risk and compliance measures, regulation, continuity plans, collaboration with business units, service management, people, change…the list is exhaustive. Now everyone knows Einstein spent a lifetime looking for a unified theory of everything and certainly I'm not going to waste years doing the same for BPM but if a strategy is effective and robust enough you can certainly try to manage as many disparate frameworks or methods under a single house.

    The trouble is who gets to rule this roost ?

    It no longer becomes solely a process discipline or does it ?

    If I build a house I need a foundation, bricks, cement, timber frames, steel rods yadda yadda. Everything pretty much plays its part in ensuring that the house is stable and robust, and so your enterprise is stable if we translate that into a real process strategy. If you build a house without cement then it's not safe. If you create a process without controls or compliance it's not safe. Similarly if you materially change the house, knock a wall in or extend it for example you're going to need planning and understanding of how that change will affect every part of the house. And there's the crux of the argument. With so many processes intertwined to create the fabric of a business entity if you change one without a proper management or planning strategy in place do you know the impact of that alteration across the organisation ?

    Now we get to IT. It's the plumbing system, the heating system, the electrical wiring of the house. It's another level entirely but still integral.

    Then there are the occupants of the house, what happens to them, how are they affected ?
    Rip out a wall and where do all the pipes go, the wiring extend to ? Build a new room and the occupants have something new to explore and utilise.

    Stripping out process steps until you get to one box on a process map means nothing without the entire picture. So for a BPM framework to work on an enterprise level you are going to enter Enterprise Architecture territory.

  • I think the simple answer is yes, if certain conditions are met. The framework would have to include the ability to continuously improve and all the usual elements of process definition associated with the chosen methodologies or approaches. However we should all keep in mind that just because there is a source (or single source) of process truth it does not mean that any processes will be improved. Process improvement is hard, it takes dedication and commitment to the task, it requires change and lots of leadership at all levels. It requires empowerment for the people that have the best knowledge. It requires that the executive management set the tone and direction and then get out of the way. Improvement is hard but well worth it once the company culture is in place the single source of process truth is in place, working and continuously improving.

  • No - and I think it might ultimately be very dangerous given the networked and adaptive world we're rapidly transitioning to. Firstly I believe that processes are the wrong place to start when carrying out business architecture and that you first need to understand _what_ you do (in the form of business capabilities and outcomes) before looking at _how_ you realise them. More broadly our enterprises will increasingly come under pressure to disaggregate such business capabilities and source them entirely from 3rd parties - as transaction costs fall because of Internet-related technologies so the incentive for doing most work in house disappears to be replaced by a massive dis-incentive (since consumption of specialised services brings massive capability benefits once the transaction cost tipping point is reached).

    If we imagine our future enterprises as a set of collaborating business capabilities both inside and outside of our ownership then we will never have a complete end to end view of the detail of a process but rather only of our coordination of outcomes at the highest level (and indeed to try to understand the processes involved at any deeper level would constrain the innovative capacity of everyone involved and remove the whole benefit of specialisation in the first place). Furthermore different business capabilities will need to be optimised differently based on their characteristics and so the idea of enforcing a standard way of doing things across the whole value network doesn't seem tenable - we want capability owners to choose different skills, organisation, processes and technology if that leads them to provide a better realisation of their outcomes and thereby lift the quality of all networked capabilities.

    To realise such a model each business capability will obviously need to understand its own position and context (including the degree to which its network are meeting their outcomes) but no more than that. As a result I feel as if it will be more fruitful to pursue standards for understanding external factors (e.g. contracts, costs, service levels, exception behaviors etc.) to enable capabilities to be integrated against outcomes rather than on standardising the way in which you implement things.

    For all of these reasons I also agree with Adrian that in this context design of the business structure (so the first level of EA) is the most important task; beyond that, though, we have to recognise that EA will increasingly be fractal, practised at different levels and increasingly about coordination rather than implementation alone.



  • Capabilities are useful, but they are not enough without processes.

    Capability is the possession of characteristics required to produce a particular outcome. It covers both “right things? (assets) and “done well? (performance, reliability, etc.) aspects of a function. Capability is WHAT TO DO and WHY TO DO (including desired performance).
    Process is an explicitly-defined coordination of services (or capabilities?) to create a particular result. Process is WHAT TO DO, HOW TO DO and WITH WHAT EFFORTS (actual performance).

    As some capabilities (e.g. an enterprise) are implemented as a set of collaborating capabilities it is important to know how to guarantee that set delivers the performance of the “composite? capability? A possible approach is to “glue? them in a formal, explicit and executable way, i.e. the process. So, the actual performance of that set can be “calculated? via simulation of such process.

    Can processes deliver flexibility? – Sure. Have a look at “Let us architect the use of existing technologies instead of blaming them for bringing complexity/inflexibility/etc. in enterprises? http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html

    And everything is linked via EA, of course.


  • I would say yes...

    I agree with all the comments about the need to tie it in with EA.

    BUT, you must first write the process in a common and simple-to-understand language that ANYONE can read & write. Without training, without misinterpretation and without boredom! Otherwise - it just won't happen IMO.

    I'd suggest that you take a look at Knowledge Genes:
    Knowledge Genes
    Knowledge Genes ~ Process Mapping


Add a Reply

Recently Commented On

Monthly Archives