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

Does the Language of Process Matter?

Vote 0 Votes
Does the language of process matter?  Why should a CEO/CTO give it a moment's attention?

7 Replies

| Add a Reply
  • Like any language, it is not the words you say (shapes/symbols), the sentences (diagrams) but what you are trying to convey which is important. ie the result or outcome.

    This is why you need to explain to senior execs "Why" you are (or want to) conducting the project rather than "What" or "How". For them the outcome is such things as reduced risk, reduced costs, better customer or employee sat or higher NPS (net promoter score).

    Only once they understand Why, and only if they are interested should you get into What or How.

    And you should avoid using the word process.

    So for Nimbus the Why is "To make work easier, faster and more valuable for millions of people". Enough said.


  • When you get to that CEO/ CTO/ CIO level the picture and view of the organisation is very different and the only way to truly understand how the business *really* operates is to think in process terms.

    A map of the World is not going to tell you enough information but if you switch to Google Streetview that's when it comes to life. Same goes for process and how to understand your business.

  • I largely agree with Ian but might express the answer slightly differently.

    I don't think that the CEO should be overly concerned about the language of process. His concern should be that his team has an effective medium for communication about the operations of the business. In most businesses of reasonable scale, getting a common understanding around operations will certainly entail some form of process modelling.

    The CTO (and the COO) have different concerns because they not only need to foster a common understanding of the operating model but they are the individuals tasked with executing the model. There might be advantages in more formal 'process languages' when it comes to converting the shared understanding of process into action.

    A CTO with a BPMS or workflow solutions implemented is going to find it easier to implement technology around formally modelled processes and it would be useful if the business owners where using the same process diagrams in their daily life. Nothing is more frustrating than having a team of analysts whose sole job is translating a set of visio diagrams into more formal process diagrams and back again while correcting errors in both.

    Ultimately, businesses need to find an appropriate working level on these questions but its important to remember that the employees will need to learn the language. It will take training, coaching, mentoring and patience for business and technical staff to first learn then collaborate in a new language.

  • Yes, the language matters because all the actors must be able to communicate to each other.

    In some occasions I "dressed" ideas with inappropriate "clothing" just to have them understood.
    Once I presented sales and service level analytics dressing them with a value chain format, because those people knew that idea but never heard about analytics.

  • Leaders can't define themselves as such, but their followers do. Criminals are not created by their actions but by the law. Language is not created by utterances but by interpretation of those. We speak of body language that has no utterances and it is more effective than words.

    Even with the most intricate ontology of terms, it is the interpretation that makes the language. Rule number one of communications: 'What I say, is not what I mean and it is not what the listener understands.'

    Therefore the meaning of language is not created by one-way utterances, but by a protocol of communications that try to align the meanings of the terms in the ontology as closely as possible. This is the fallacy of thinking that XML makes program to program communication simple, because the meaning of the embedded tag is not defined (XSD is just data typing) and it has to be encoded in the receiver of the message.

    Additionally one has to consider that the meaning of language is always an approximate abstraction of real world concepts and when it describes actions these cannot fully describe something that will happen accurately.

    Applying these issues to process-defining languages it becomes clear that the choice of language is virtually irrelevant because they are all incomplete or inaccurate. Yes, all models are wrong, but some are useful.

    So the problem of process languages lies not in their syntax or structure, but in their intent to fully abstract real world problems into activity flows that will neither represent reality nor will they lead to actions that can be executed as intended.

    Process is about people communicating and not about rigidly defining flows of activities. Process is about empowering people with authority, goals and means. Process is about making business goals, data and content transparent in the process context.

    Everything else is just another form of programming and it really does not matter what kind of language you chose.

  • If the CEO is getting involved in the detail of process, business leaders need to be worried. When processes are getting this level of visibility, you've probably left process improvement too late.

    Now is time to show how good process practices lead to customer retention, lower cost of sale, and improved efficiency. Not just in marketing terms, but tangible improvements that fit together in understandable ways of working. If you can't voice what you are going to do differently to your husband or wife, you probably can't justify what the new process will do and benefits it will deliver to the CEO.

  • 1) If we focus on outcomes (which are perception and need to be rated) or simpler goals, why aren't they put into the process, but just remain some abstract point of discussion? I see only a limited benefit in both a verbal process description (too soft) and a hard-coded process execution on the other hand (too rigid)!

    2) Because of the need for goals and targets the executive and management have to be involved in process goal definition, but obviously not in exceution detail.

    3) The execution detail should not be nailed down at all but the process participants must be able to perform all activities that lead to a goal satisfaction.

    4) Because the goals have to be defined and resolved the language of process must empower the participants to do so one way or the other.

    5) A CEO today must be to some extent IT literate. The future of a business depends on how it uses IT and strategy should be aligned with what IT can deliver and not the other way round. There is no sense in having a strategy and IT simply can't do it. IT is today too slow to be able to follow strategy. So it is the CEO's job to be concerned with this.

    6) Anyone in a business must understand the concept of process, as otherwise trying to do processes is a waste of time. Only techies must understand the infrastructure detail and maybe some flowcharting tool for some complex functionality, but for BPM so succeed NO IT SKILLS must be necessary to create and adapt processes according to their authorization.

    7) It would be important for BPM to become "the art of doing business" that it no longer requries a process bureaucracy that has to worry about a process language while they are doing process. The process language must be continuously expandable and adaptible as well.

    8) Most BPM is still about cost and efficiency and therefore language, goals and outcomes are irrelevant.

Add a Reply

Recently Commented On

Monthly Archives