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

Are Business Processes Detected or Invented?

Vote 0 Votes
Peter Brand: Can Business Processes (formally representable in terms of some processing-language, BPMN or other) be detected in real-world business activity? Or do they come into existence only by a certain kind of intentional abstraction from real-worl business activity?

27 Replies

| Add a Reply
  • Sorry, but I really dont like this question, it implies that the answer should be one or the other. In my experience the answer is both.

    With BPM you really need to keep an open mind, this includes understanding that some processes you will be able to design, and others you will miss or be unaware of. The latter will eventually be detected. These reasons are why I am such a strong advocate or agile and adaptive solutions. Such solutions allow processes to be invested, and also detected...

    • Andrew, Francis, Doug,

      before you can 'detect' any weakness/deficiency in a 'process' you are working on, you must have knowledge about that process. What kind of knowledge is this? Where does your knowledge of the 'process' come from? What does it refer to?

      Does it refer to the past? Then it's usually abstracted from 'non-process' business activity. Or does it refer to the future? Then it will typically be knowledge about hitherto non-existent 'processes' to be created. In both cases, the 'process' is invented, not detected.

      So, if you perceive the question this way, Business Processes are always invented, either by abstraction (from the past) or by design (into the future) - or by both, you are right.


  • At least in the firm I'm working with, we are detecting business processes through a paper-chase. A filed paper record is evidence that a process exists, and I just have to chase the paper to understand whether the process warrants any additional investigation.

    I blogged a couple of weeks back about what I mean: http://blog.consected.com/2010/06/avoiding-rat-holes-by-working-backwards.html

    Of course, you can invent business processes, but I think you only do that to abstract/extract a process that has been discovered from the brain of a person that just does the work without thinking.

    Phil Ayres

  • Business processes exist in reality executed by the technology and/or people in the Enterprise.
    These business processes are sometimes documented to enable change and Enterprise transformation. The abstract business processes we document are coming close but seldom 100% to the process executed in real life.
    We design, sometimes, (abstract) processes to model the operation of a system we need to implement. These processes may never be implemented as such.

  • Andrew is right on the money. Both. We pay good people to think on their feet and the detection is then the invention for others to follow - when it's shown to be repeatable and more successful. Things also change, that's life.

    The key to reducing what you miss is monitoring. It is now possible to virtually eliminate the old six sigma, random, sampling time and motion studies with live Desktop Monitoring. The monitoring is adaptive and misses nothing. It's watching all users proceesses, 24x7x365 and it's key to next gen T&M. You can then choose to report on when business processes are being changed (for the good or bad) in the field and determine whether the change is a compliance issue or a detection of a new invention. Either way, Desktop monitoring to compliment BPM and BAM is not only important, it ought to be mandatory.

  • I have to side with "the guys" on this, it's both. I've been involved in many situations where the process we detected was riddled with problems resulting in poor quality execution. In those cases, we used the starting point and ending point and reinvented the middle.

    In one of the most severe cases, we cut down a lead gathering and tracking process from 6 weeks to half a day. It took several iterations and runs to do it but eventually we had it down to a science.

  • Most business processes are neither detected nor invented. It is important to keep this perspective, though I know you mean something else.

    You have clarified that you are only talking about the tiny percentage of business processes which are actually representable with BPMN or other programming language.

    Scientific Management tells us that there is a separation between the "thinkers" and the "doers". The thinkers come up with the precise way that work is to be done, and the doers are like cogs in the machine. For certain types of very routine work, (e.g. factory work with unskilled labor) this is appropriate. In these situations automated process discovery will tell you only how imperfectly the managers in the past have realized their directions in the organization. Of course, if you have lost the original designs, such discovery can be helpful.

    When such a process is discovered, it almost always needs some improvement before it is automated. Simply adding visibility to what is going on always evokes suggestions for improving it, from every level of the organization. Thus it is inappropriate to say that any automated process is purely discovered. There is always a follow-on design job.

    The difficulty I have with the question is the restriction only to automated processes. So much of business depends upon knowledge work, which includes processes which are invented on the fly by the person doing the work. There is no separation between "thinkers" and "doers" -- the work itself involves planning which is a kind of invention of the process. These processes can rarely be represented by BPMN or any other programming language. My experience is that process discovery is a valuable tool for improving these processes, even though they are not automated. The visibility can cause changes in practice to eliminate inefficiencies even though the process is not automated. And this visibility helps even in the cases where the processes are purely invented.

    I know this is not the question that you asked, but we should be aware that in many ways BPM practitioners are locking themselves into a box, and addressing only business processes which can be programmed. This was the important low-hanging fruit a decade ago, but today it is less and less relevant, and we need to start thinking outside the "can I program it" box.


    • Keith,

      I am speaking of a processing language - not programming language. And I allow any processing language you like, if only it can properly delimit the term 'process'. BPMN is just an example. You could take 'EPC' (Event-driven Process Chains) from ARIS as well, which is for modelling, not programming.

      The question BP invented or detected seems important to me because of the following connotation:

       -  If Business Processes are invented, we are in need of justification of proposing the     BP-paradigm to business.
       -  If Business Processes are just discovered (detected), we are not responsible for their     existence - only for their improvement.

      • Peter, yes, I purposefully used the term "programming language" to emphasize how BPMN is being pushed to become exactly that. The question glibly implies that BPMN might be something other than a programming language.

        Given your clarification, I would say that it is impossible to invent a process without first detecting (discovering) how an organization is working today. Again that depends on who the "we" is that you speak of. If you envision a "process consultant" visiting an organization, then the job is mainly one of detecting.

        How did that process get there? Clearly someone invented it, and I would suggest that business processes are the result of collaborative invention. Smart people work together to invent properly functioning business processes. This certainly is an intentional abstraction from the real world: people make up forms with check boxes that map to something specific in the real world. Those check boxes don't appear without being invented.

        While the business process is in a continual state of being invented, a consultant would need to detect or discover the process. Clearly a consultant who invented a process without detecting the specifics of the organization would likely cause a disaster. On the other hand, automatic detection of activity without any understanding of the goals or desired outcomes would be similarly fruitless.

        In conclusion, I think we are responsible only for the improvement of (existing) processes.

    • Keith, I just feel like you're bringing into the discussion your knowledge work vs. factory workers argument. You've written many interesting posts on the subject of both BPM and ACM. But characterizing BPM process participants as unskilled labor is not only inaccurate it just seems condescending when it is repeated so often. You know quite well that most of us implementing BPM are implementing BPM around "white collar" processes and knowledge workers - not unskilled labor, and yet you persist in labeling them cogs in the machine. Sometimes the "thinking" in the "doing" doesn't require designing the process, but yet requires sophistication about executing the activity. And the process simply helps organize the work, track the results, and allow for opportunities for testing for improvement in outcomes later.

      A simple example: in a "recruiting" process, an interview may be conducted. You could call this interview step and the interviewer a cog in the machine. But actually the interviewer exercises a great deal of discretion in terms of what questions they ask, how they judge the answers, how they adjust their interview based on the answers, and how they overall judge the outcome of the interview. And yet, to the BPM process, it is a simple step "interview" with some fairly structured output(s). You might say that the interview itself is an example of "knowlege work" and you'd be right. But it is managed by a process (BPM) and that is also right.

      And contrary to your last statement about the low hanging fruit being gone - gone or not, there is more opportunity than ever in BPM and process consulting (whether or not you consider ACM to be part of BPM market), and these opportunities still appear to be growing at a very high rate.

  • It depends on what you are trying to detect. If you are looking for current state architecture definitions then yes, you can detect these processes "in the wild". One could examine the outputs of sophisticated reverse-engineering tools on source code. But I think that would be far too low-level for meaningful analysis.

    If one is going to engineer the enterprise, as John Zachman might say, one needs to take concerted effort to drive out waste and non-value-add steps in the processes. They need to be either 1) documented and triaged or 2) tossed out and re-engineered from scratch. The latter could certainly come from industry-accepted reference models if they exist and are easily modifiable.

    • Eric

      It depends on what you are trying to detect. To me this is the key phrase, in that it says: You have

      -  to know, what you are searching for, in advance,
      -  to abstract from virtually all you are not searching for,
      -  to anticipate, where to look to strike it rich,
      -  to understand the implicit assessment associated with your kind of searching.

      Sure, most probably we will not search re-engineered source code. But what about those innocient-looking enterprise-wide processes ('end-to-end') containing waste and non-value-add steps to be driven out?

      Where do they come from? From which kind of searching and which field of search? On what footing are their steps assessed as 'waste' or 'non-valued-add'?

      According to my understanding, whenever we are trying to detect patterns in 'running business', in particular some 'process' pattern, we are 'inventing' a specific interpretation of 'running business'. Do you agree?

      If so, while this invention (change in interpretation, if you prefer) is certainly illuminating in many respects, for me trying to re-organize a company, so it will be aligned to 'process thinking', is never advisable without a proper assessment, revealing for which parts of a company such a re-organization would be beneficial, for which detrimental? What do you think?

      Thanks for your clarification.

  • Detect vs. intentional abstraction? Hmm.

    "Detection" can be something that is accomplished by systems, similar to automated process "discovery". Certainly a possibility for STP environments.

    Detection becomes more difficult with manual human-centric processes where detection requires identification of manual tasks, undocumented workarounds, verbal interactions with others, etc. In these circumstances, "invention" of the process might be accomplished through intentional abstraction of the process through close observation.

    Great conversation overall. Thanks for posting the question.

    • Derek,

      You are addressing the point I have in mind: To map 'business procedures involving humans', you call it 'manual human-centric processes', into 'processes', manageable with BPM-methodology, we are forced to according, intentional abstraction.

      Since this mapping is from 'un-delimited procedures' to delimited processes (in terms of some process-description language), I would suggest to re-formulate: In these circumstances, "invention" of the process can only be accomplished through intentional abstraction of the original procedure through close, biased observation.

      Thanks a lot

  • I agree, it cant be one or the other, but depends on which state of maturity a particular process is to start with. But with respect to semantics, the exercise is more of process 'discovery'.

    I would like to put forth a different arguement for "inventing processes" - do you not invent processes when you perform an exercise of re-engineering? A BPR if you will, where you analyze current state to achive radical improvements in quality of some kind. Which then brings us to another discussion - is achieving BPR possible through the process discovery normally conducted in BPM? Or are they two separate concepts?

    • Jaisundar

      A difference between BPR and BPM, seen as approaches, is certainly: BPM is analyzing 'running business' (by whatever methodology), while BPR is analyzing 'running programs' (code of programs running in business).

      • Just for clarification: you see Business Process Reengineering, as proposed by Hammer and Champy, as the analysis of running code? I certainly don't associate that with BPR.

        Or did you mean some other "BPR"?

        • Keith, Let me respond to this - What I had meant was indeed Business Process Reengineering as proposed by Hammer and Champy - but I should have made that explicit in my comment; sorry about the confusion

          Note to Peter: Pl accept my apologies!

          Note to myself: Too many 3 letter acronyms. Take care not to add to the confusion!

  • OK - I will wade in. I dont think it is either detection or invention. Sure you can follow that strategy if you like, but in the end you often shuffling the deck chairs on the titanic.

    In a give business domain, it is possible to "Derive" the needed operational processes and relationship between them. You could think of the given business domain as a "Purpose" and the operational processes as the necessary components to implement that purpose.

    Following that thinking, you would then agree that all car manufacturing companies would need the same set of processes (their purpose is the same). Of course, how they implement those processes will be wildly different.

    Be careful - avoid legacy thinking that reinforces the very functions and silos that you are trying to break down.

    • I think Derek hits it on the head. Process is derived from the goals and objectives of the business domain - and if there is already something existing it can be examined or referenced in that light. Great point.

    • Derek

      I agree, the processes 'coming to light' in the BPM-framework are mostly (if not always) derived from a purpose: to achieve a kind of 'Knowledge-Worker' assembly-line.

      But that purpose is our 'invention' (purposeful setting, if you prefer). Clearly, any process derived from a setting is itself just set ('invented', if you allow).

      That's the point: If we say (or think of) Business-Processes, we already do some 'purposeful' abstraction.

      Sure, next we are going to 'detect' such a thing in the domain of collaboration of people inside a company. But in doing so, we are intentionally screening the plethora of phenomena we become aware of, to retain only what we are interested in, given that purpose. And by screening primary phenomena, systematically, we are creating our beloved processes, rather than disvcovering or detecting them.

      However - as the conversation reveals, the term 'invented' was not the best choice. It seems 'created' would have been more to the point. Excuse me, please.

  • Processes are seldom, if ever, invented.

    Processes pre-exist as a result of activities that happen, whether predictable or unpredictable (I know there is a debate around predictable/unpredictable and this is not the forum for it). Inventing a process and documenting is done through a delimiting bias as Peter points out. Sometimes we try to manage activities in a highly controlled fashion (Keith's factory style) and we document the proposed path with a model that supports our perspective. We may “invent� new ways that processes behave and we may document those as a newly invented model and even possibly the preferred sequencing for the process. But there are a large number of knowledge processes that don't subscribe to the constraints of a defined model.

    To me it is almost like the iceberg effect. There is a mass that is visible and that you can map to avoid risk, but there is a large body that is there but not visible on the map. “Detecting� by bumping into them these can have catastrophic consequences if you are not aware and look out for them.

    So to me, processes are detected or discovered rather than invented. But there remains are large number of process combinations and exceptions that we may never discover if we attempt to document them and therefor claim that we invented them. The document does not have to be a BPMN model though.

  • Considering the definition of process as “explicitly-defined coordination of services to create a particular resultâ€? (and service is “explicitly-defined and operationally-independent unit of functionalityâ€?) I saw in practice the following variations:
    - Derived from a newly defined particular result or goal (Thanks Derek)
    - Detected to make the implicit coordination explicit
    - Invented to change the coordination (maybe with a small change of the goal)
    - As well as some combinations of above

    The coordination itself can be expressed with different coordination techniques: control-based (strong coordination as in classic workflow), data-based and event-based (last two are weak coordination as in case management). In the reality, a mixture of those techniques should be used. Control-based and event-based coordination can be "coded" in BPMN.

    Another observation of the reality is that to carry out the permanent changes in the business, processes should be _architected_ with a coherent set of principles for process design, implementation and evolution.


  • The closer you come to observing the process, the less certain you can be that you have observed the actual process. Even with a process like ERP Integration, by detecting the process you end up inventing it in part and neither detection or invention are a fully accurate reflection of reality. (Full credit to Werner Heisenberg's uncertainty principle).

    • Very Nice, Glenn!

      Reflecting on your remark, I would guess, mutual exclusiveness, in case of a Business Process, is between 'accurately observable' and 'accurately imaginable'.

      The more accurately I observe what is going on in a running business within the domain of collaboration, the less I can have a clear picture - several 'images' become intertwined. And the more rigorous I have that 'Business-process vision' in mind, the less I can completely follow all observable events - I have to do some suitable coarse-graining.

      Credit to Glenn!

  • Many business processes evolve over time to assume a position of relevance, and in some organizations no one person really understands a process from end-to-end. People may understand the ultimate purpose or objective of the process while being unaware of how it evolved to be what it currently is. In this case, it would be safe to say that defining (or detecting) the end-to-end process to improve is in order.
    Of course there are also business processes that are defined up front, documented, implemented and then improved. Ultimately, businesses processes need to be fully understood to be truly effective and must be refined to actualize their full potential. With the plethora of BPMS tools available today every business should strive to continuously monitor and update every meaningful business process regardless of how they came to be.

    • Tom, let me recall:

      While it's right that 'no one person really understands a process from end-to-end', it's also true - as we have seen - that every professional person should understand a BPM-process, 'mature' or not, as being always and inevitably a biased abstraction, that needs justification.

Add a Reply

Recently Commented On

Monthly Archives