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

Should the language of BPM be the language of business?

Vote 0 Votes
An interesting question raised in this blog, BPM is business performance dressed to kill, do you think the language of BPM should be the language of business?

13 Replies

| Add a Reply
  • BPM is many things, as has been said on this column before.

    BPM - definition of how people (end users) do things needs to be described in terms my mother (carbon based life-form) would understand. For example UPN (Universal Process Notation) http://bit.ly/gmeXR1 which seems to work for millions of end users across the world

    BPM - definition of processes that are automated needs to be described in terms silicon-based life-form understands and also the process analyst; so BPMN, XPDL, BPEL or UML

  • As Ian has stated, BPM is many things, and organisations will take what they need from it.

    However as a consequence BPM has no common language, it can't even define itself after over a decade of existence, so every company talks in a different BPM dialect.

    So no, BPM should not be the language of business unless you want to create something like a chaotic United Nations address and have 100 translators standing at the ready....

  • BPM is has no common langauge because it is mostly a flawed idea if implemented in any kind of flowchart notation.

    I have yet to meet a normal business person who is capable, interested and willing to describe what he is doing in flowcharts. For efficiency we need a hierarchy in terms of seperating work into skilled activities. But if one performer has to be bothered with all other activities, or if we get a top-down command structure then we create bureaucracy and inefficiency.

    Not only is a flowchart a way to look at how things happened, it further will never be a view of how things WILL BE. Maybe how some process analysts might think it should be, but it rarely is. A 4D world of dynamically interacting people and event-driven objects can't be expressed in 2D directed flows.

    Flowcharts do further not provide the essence of a process definition, which are goals, data, content, rules, events and role-oriented presentation. Process definitions can only be used by business people if they are defined in business language. Each business must actually have their own process language for people to understand it. I propose to define it as part of a business architecture.

  • BPM is part of the language of business. Let's say its one of the letters in the alphabet. There are 25 other letters and together they can but put together into words that tranlate into a language. What I'm trying to say is that BPM is 1 piece of the puzzle, but other "components" are needed to define the entire business architecture.

  • If common sense prevails, and BPM is an acronym for "Business" Process Management, it must be the language of business. The language of business simply meaning whatever vocabulary is used by business people within an organization.

    BPM has been allowed, by most, to reside on the technology side or sphere of organizations for far too long.

    For BPM to be successful or at the very least add some modicum of value, it must first be owned by the "business". So logically, if it is to be owned by the business it should represent the language of the business.

  • Kathy I am right there with you. Today's BPM tools are capable of being implemented by none technical business analysts who can use Visio or Excel. They are even able to be used by business users as those users expect technology to run their business and are familiar with its capabilities.

    Four decades ago my chief programmer said to me "Don't do: document" as his way of encouraging me to make processes repeatable. I'd like to update his mantra to "Don't document: automate." Today's BPM tools are excellent process documentation tools and have the distinct advantage of being the process execution rules. Change the documentation, change the rules. No memos, no meetings, just improved process.

    So yes, emphatically yes, BPM should be the lingua franca of business.

  • BPM should not be the language of business. A big failing is that we try to force business people to use our own generic process terms for everything they do. Instead we should bother to learn the language of the business and apply BPM concepts, not terminology to making what they do better.

  • In my experience, it is the best option so far. BPM (how to use processes to manage the enterprise) is good as the language of business for the following reasons:

    1. BPM main “tool” -- process (an explicitly-defined coordination of activities to create a particular result) – makes the business EXPLICIT.
    2. BPM makes its processes EXECUTABLE (what you model is what you run) – thus predictable (if you want).
    3. Processes in BPM can be rather flexible (see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html ).
    4. BPM uses the business artefacts: events, rules, roles, data, documents, KPIs, audit trails, activities, etc. – practically everything from business architecture (see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html ); .
    5. With BPMN, BPM may express different practical patterns which are applicable in different business areas (those patterns are easier than well-known workflow patterns).
    6. Proper implemented BPM can considerably speed up the evolution of the business.
    7. If the business wants to share its language with the IT then BPM works well with EA, PMO, SDLC, SOA, etc.

    Sure, that BPM is in favor of control-based coordination which is not sufficient in all cases. Nevertheless, BPMN allows also some event-based coordination (see http://improving-bpm-systems.blogspot.com/2011/01/explicit-event-processing-agents-in.html ).

    Although BPM has no commonly-agreed-between-BPM-gurus terminology but those differences are not dramatic.


  • I would go with the two most popular words in a consultant's lexicon - "It depends!"

    It depends on whether the business views BPM as a core business management discipline or a technical automation platform or anything in between. If BPM is the former, then the answer is a resounding yes! After all, all businesses have processes and all processes can be improved - an obvious way of impacting both the top-line and bottom-line of your business. So BPM must be boardroom-speak and the language of the business.

    If, however, the business views BPM as a technical workflow automation platform, then in all likelihood the business would not understand (or care much about) the language of BPM as long as they can give their requirements to IT - be it scribbled on the back of a napkin or a flowchart or in BPMN 2.0 format. In this context, the language of business and the language of BPM are very different.

    To me the situation is quite similar to the famed parable of the blind men and the elephant (http://en.wikipedia.org/wiki/Blind_men_and_an_elephant) where everyone is right and yet nobody is right. BPM is like the elephant and once you appreciate the whole beast, it can do all the heavy lifting for you (or trample you if you rub it the wrong way).

  • BPM should contain a language set that transfers from business to business regardless of the domain they reside in.

    The idea is to ensure that technical consultants are not required to craft the process, that should be left to the ones who regularly work in the domain and know the elements of "what if's" should they arise.

    If you force a domain to change a process to fit with BPM, the BPM has just missed the point completely in my opinion.

  • Hey Peter - thanks for the plug to my latest research project (do you have trojan horse installed on my PC ;-/)

    "The Strategic Language of Business Transformation Unlocks The Power Of BPM (Part 1)" explores the relationship between strategic intent and BPM programs, tying together the language of Value Chains, Target Operating Models (Capabilities, Business Services, Processes, Tech, Customers, etc); Balanced Score Card and Lean and Six Sigma.

    Part 2 - focuses on the implementation level, fleshing it out from the Target Operating Model into the different process modeling perspectives - orchestration (e.g. BPMN, EPCs), choroegraphy (eg RADs), State transition models such as OSTN in IDEF3, Value Streams, etc. Rules, Roles, Policies, etc ... it all has a place in the language that BP Pros need to master if they want to succeed in BPM

  • IMO, BPM as a Business Process Management technique cannot and should not form the language of business. The reason is very simple - business is about business functionality: functions, features and capabilities. Business Process is nothing more that particular implementation of the business functionality.

    If at some moment in the past when the corporate business needed to implement a particular function it would have different instruments (than it had that time), the Business Process might be absolutely different while the business function is the same.

    BPM has to construct the language of management, which it is doing already, and this all we need from the BPM.

  • BPM is the only common language for business...all that we do at work is use business processes, it is just unfortunate that many are informal and not written down, causing entropy and distraction. Spreading that language through frameworks like APQC and others give this an end-to-end capacity that doesn't exist in silo'd organizations.

    Watching people struggle to know what to do in large, distributed organizations is painful when we know that it doesn't have to be that way.

Add a Reply

Recently Commented On

Monthly Archives