Not Unstructured, Not Unpredictable, Not Ad-hoc Processes – Simply Knowledge Processes

There is an interesting converstaion going on at the Adaptive Case Management group in LinkedIn. It made me notice that people continually struggle with how to describe the kinds of processes covered by adaptive case management – people use the terms unstructured, unpredictable and ad-hoc interchangeably (I too am guilty of that). The problem is that all those terms either mean something is missing or wrong with the process, and insinuate that if only we would work harder or smarter we could change any process to a more structured, predictable, well-defined, recurring process – which just isn’t true for knowledge processes. Do we as a community really believe that knowledge work will be mostly defined by predefined structured process? I don’t think so. I think we should call these types of process “knowledge processes” (which puts them in a positive light) rather than unstructured (or any of the other related terms) processes.

The key issue in morphing technology support from structured processes to knowledge processes (interesting how the words structured vs. knowledge sound when said aloud -try it) is changing the mindset from one of control to one of visibility, guidance and tracking. Knowledge processes demand inversion of control – it isn’t the process (and its model) which controls the participants, but rather the participants which control process and its flow. Optimizing a knowledge process isn’t about counting steps – but rather optimizing outcomes and appropriately leveraging skills. Managing a knowledge process isn’t about control, it is about providing guidance about possible next steps, ensuring appropriate levels of visibility into process execution, collaboration between process participants and tracking process execution through its steps.

Both the vendor and analyst ACM communities are mistakenly worried about exactly what technical features need to be included or excluded in an ACM tool. No matter what we all think about our own aproaches – there is no single right answer. I think that is main problem of ACM  – both the vendor and analyst communities immediately drill down to the technical features of the tooling – losing the bigger business picture.


17 Responses to “Not Unstructured, Not Unpredictable, Not Ad-hoc Processes – Simply Knowledge Processes”

  1. Business Process and Adaptive Case Management News and Information » Not Unstructured, Not … Says:

    […] Link to original post […]

  2. Max J. Pucher Says:

    Hi Jacob, as we promote the linking of ACM with a business architecture and its strategy, cabilitities, targets and goals. I don’t think one can say that we are loosing the bigger business picture.

    I have promoted that for process management before the term ACM was defined. Particularly my proposal that ACM has to be goal-oriented shows that. But it does require a discussion of how to implement it in technology as otherwise it is purely a methodology.

    • Jacob Ukelson Says:

      The problem is that we got into ACM feature\function discussions way too early – before the traditional process community understood exactly what ACM was (see my response to Scott). I firmly believe that ACM was supposed to be the process community’s reponse the challenge of managing knowledge worker processes. I think you agree with that – but you need to answer that yourself.

      What has happened since is that because the conversation became technical so quickly, and lets face it, and was driven by a bunch of techies – everyone went off and defined their own feature-function list for ACM – from Forrester through IBM, and no one called them on it. So by calling it ACM, rather than what if really was supposed to be (an attempt at getting to root of managing knowledge processes) – we shot ourselves in the foot.

      In the end there will be an architecture and some basic functionality that every knowledge management system will need to embrace, but I believe by getting to that conversation too early – we allowed it to be usurped into a BPMS feature-function discussion.

      Just look at ACM’s step brother Dynamic Case Management – it completely misses the point about managing knowledge work. The waters around ACM are getting muddier and muddier – so I think we should just call it what it is:

      ACM is a set of methodolgies and tools to manage knowledge work by managing knowledge worker processes. Then we can define first priciples around that, and only then should we try to define the architecture.

      You are just ahead of everyone else in your thinking. You can’t have a baby run a marathon – you need to spend a lot of time and effort to help it mature first.

  3. Marco Brambilla (@MarcoBrambi) Says:

    Dear Jacob,
    interesting post. Besides the terminology problem, I was trying to figure out whether the term knowledge process would also implicitly say something more.
    Is it the case that knowledge process would actually apply to complex tasks that are performed by “knowledge workers”?
    That would actually make sense, because most of these processes would fit in your definition.

    • Jacob Ukelson Says:

      Exactly right. I believe that ACM’s main “Raison d’être” is to enable the process and case community to focus on the unique problems faced by knowledge workers in their everyday tasks. That is why I chose the name “knowledge process” – to use words that I hope are immediately clear to everyone (at least intuitively).
      Focusing on knowledge work, and the tools needed by knowledge workers to get their jobs done is the clear differentiator between ACM and BPM – at least for me.

  4. Scott Francis (@sfrancisatx) Says:

    Setting aside Max as an outlier, I’d say actually ACM vendors have been largely silent on the issue of what technical capabilities make ACM unique or different at all, except that they *won’t* have certain capabilities that a BPM suite would have. Or to define these capabilities in such flowery language that it doesn’t mean anything (“must have good collaboration capability” – really? )

    I’d welcome a vendor or two to spell out the technical features of their ACM offering that make it interesting and relevant to the ACM space. I thought ActionBase did that. Don’t see much from the other folks… and I think largely the features that are required are pretty reproducible across a wide range of software including a BPMS. Note: the only reason I’m “concerned” about this is because I’m genuinely interested in understanding whether this is a new software market or just a new spin on existing software market. I suspect it is the latter. I’m waiting for that hypothesis to be disproved. That may not matter in the end, per se, but if it isn’t really a new market there’s really no need for ACM to constantly be defensive about “not being BPM” 🙂

    2 cents.

    • Jacob Ukelson Says:

      I agree. I believe that ACM (as it was kicked off in the WfMC meeting that Keith Swenson organized) was originally supposed to be the process community’s response to the challenge posed by knowledge work. I believe that ACM has now been usurped by the BPMS community (vendors and analysts) to define certain features and function of BPMS that make it a bit more social, or as few extensions that allow it to more easily meet the needs of a classical case management tool. The original intent of ACM (at least in my opinion – and Keith Swenson and Max Pucher can correct me if I am wrong) as the tools needed by knowledge workers has been lost. We didn’t use the term “knowledge” because of all the negative implications related to “knowledge management systems”. I now think that was a mistake – because by not calling a spade a spade – certain vendors and analysts have muddied the waters so much that everything looks like various shades of brown.
      That is why I think we should start using the term “knowledge process” and “knowledge process management” which I think is at least intuitively clear to most people in the process community. As I keep reiterating (as does Max and Keith) when you talk about knowledge work – a BPMS isn’t the answer. I do believe that managing knowledge work is the real challenge for the process community – the company that figures that out will be the next powerhouse in enterprise\business software – and I can honestly predict that it won’t be an extended BPMS.
      That is why I think we need to get away from discussion of specific features needed for an ACM. I believe that there are a few principles that any knowledge process management system will need to adhere to – but I know there are many different ways to skin that cat.

  5. Scott Francis (@sfrancisatx) Says:

    As I mentioned on twitter, I don’t think the problem is that they got in the weeds on features. The problem is that ACM folks got too caught up in trying to prove that BPMS can’t do ACM – which is silly. Or worse, that ACM was superior/above/better-than BPM – which again, is just a silly argument to get into. Like arguing that BPM is better than SOA – they’re either complimentary or competitive and if they’re not competitive than better doesn’t really have meaning.

    Knowledge work is business work, last I checked. business people describe knowledge work as being part of their business processes. Fighting a definition battle that isn’t worth fighting. Go ahead and convince customers that they don’t have a sales process. That it is, instead, a sales knowledge process or a sales case management. Or that they shouldn’t apply process improvement techniques to aggregate outcomes.

    So. forget BPMS for a minute. Will there be one ACM vendor that wins, or will there be several successful companies? will it be more like twitter or Facebook? and is it impossible that one of the existing BPMS vendors will be the dominant vendor instead of an upstart?

    I keep hearing from people about what isn’t the answer… but not hearing much about what is 🙂 unless it is a plug for “read the book” or very high level – as you say – principles – which of course could just mean “use email”.

    I think the ACM discussion has been useful in that it reminds people that BPM shouldn’t be just about automation and eliminating human work. But to me, separating ACM from BPM is a bit like saying that what’s good for the goose isn’t good for the gander- that some work (usually whatever work we envision ourselves doing) isn’t subject to the same general rules as the work others are doing. My work is creative, but their work is not. My work is knowledge work but their work is routine.

    I promise you, all work that involves people involves creativity, passion, skill, energy, pride – or the lack thereof. Our goal should be to reduce the mundane and routine, and allow the people to focus on the creative and expressive and decisive. We could argue over ACM vs. BPM or just agree that BPM and ACM are two slices of bread in the same loaf.

  6. Jacob Ukelson Says:

    Hi Scott,
    I also left this as a response on your blog.

    You are right – knowledge processes are business processes – and in theory every business process could be a knowledge process. For many BPM vendors the goal is make business processes “non-knowledge” processes so that even untrained workers can do them by relying on centralized control driven by an absolute model. That is why there is so much focus on the process model in most BPMS tools and the focus is on automation. In my opinion the part of the process that gets modeled is the least important part of the process and the part that can be automated is even less interesting from a business perspective. Not that it isn’t important, it just isn’t what makes the business special.

    I think work is segregated. Sometime by the type of work needed at different times in the lifecycle of a business process but that in most processes both types of work are needed at different times. I also believe that if most of your work is rote work you will need a different set of skills than if most of your work is knowledge work – and dare I say a different set of tools.

    I firmly believe that there is a type of work which many people call knowledge work that would benefit from a new set of tools that are better than plain old email and documents. Just like we could have remained in a world of Cobol and Fortran (there was no program you couldn’t write) – but for the sake of productivity it made sense to move up to languages with higher level of abstraction. A BPMS can do anything – but should it? Object-Cobol anyone?

    I think it will be a new vendor that makes it happen – I hoped for it to be ActionBase but that failed, or maybe Google Wave – but that too failed. Maybe Asana will do it – don’t know enough details about what they are doing. I still think the right approach is to morph email and documents into a paradigm more suited to this type of work – and I know it can be done from a technical perspective – the business side is a lot tougher.

  7. Max J. Pucher Says:

    Jacob, Scott, while it is great that you also ‘get’ the point behind ACM, you make it sound as if the discovery that we focus on knowledge workers is a new one. And yes, a lot of knowledge work in a business is business results focused. So we have to convince the business user by gving them the right abilities. We have to make doing business with it really easy.

    Saying that we ACM pundits went for technical solution too quickly is like saying that Facebook was wrong to deliver a product before they had convinced 500 million peple to use it or that Apple should have signed a 100.000 developers before making the AppStore available. You really need to get off the methodology train …

    Solutions are driven by adoption not by forcing people to use something. If we define BPM to be flowcharts then ACM is not BPM. If we go by those who say that BPM is about achieving outcomes then ACM is a lot more BPM than a BPMS supplies! Google Wave, Trello or At-Task are products that focus on worker collaboration and they would be much better to enable collaboration than BPM or most of the ACM products, but what they miss is the link to a business architecture (strategy, targets, and models), a verifiable goal-orientation, the backend link into business data and by-the-way, the ability to handle the business content (not just attaching a file) that makes the process a business process. It is amazing that I have to keep saying these things and no one gets it …

    I have said long before the ACM acronym was agreed upon (and I voted for ‘Adaptive Process’) that process management must have a human focus and be about technology empowerment. So I find this newly found recognition what ACM is about rather amusing … 😉

    But thanks for covering and discussing it and taking it further nevertheless! Max

    • Jacob Ukelson Says:

      Glad I could make you smile!

      The fact that ACM is supposed to be for managing knowledge work is not new, but I am always surprised the number of people that don’t really understand it – including most of the process community, many of which claim that ACM is just a small variation of BPMS. I could just claim “everyone doesn’t get it” but I don’t see the benefit in that – I think that maybe the problem is the terminology. We need to continually remind people we are talking about managing knowledge processes.

      I am not against architecture and technical feature definitions – all I said is the discussion of architecture came much too early. I don’t think a public discussion around architecture needs to be a prelude to building or using tools, so I don’t really understand your methodology comment. I know I am not advocating a methodology only approach – but on the other hand business users don’t give a hoot about technical architecture. I am not even sure that the problems solved by ACM are widely recognized by the business. Until that happens there is no way ACM will take off – unless someone comes up with a knowledge process management paradigm so compelling that everyone just starts using it and it becomes viral (ala Facebook). In other words someone solves a problem that people didn’t even know they had – which sounds a lot like what you would expect a successful startup to do. Facebook solved a problem that people had, but they didn’t know it – no architecture discussion, no deep analysis of how it fits into the ecosystem, even no real feature function discussions until it became popular.

      The only ACM applications that even approaches this level are, sadly, email and excel.

      • Max J. Pucher Says:

        Hi Jacob, we may have an issue with the term ‘architecture’. For me architecture is related to business not to technology. Without a defined business architecture no one will know what the outcomes, targets and goals of processes are supposed to be. If you don’t define rigid flows that is however essential. if there are no goals defined how should business know when they are achieved?

        I am with you on technology empowerment a’la Facebook. I am promoting it since day one! The problem is that in business you have executives and IT management who don’t get it and demand immediate and measurable ROI that you don’t get initially from viral solutions because they need a minimum number o people using it to pay off.

        Fact is that everything that is not automatible is a knowledge process. Email and excel are not ACM because they aren’t process or goal oriented. That is the biggest issue that people don’t get the point of ACM long before we start the feature discussion. It has to do with so many people claiming that ACM is something different because it suits their marketing and sales.

  8. BPM and Case Management Quotes « Adam Deane Says:

    […] ACM – Jacob Ukelson Both the vendor and analyst ACM communities are mistakenly worried about […]

  9. kswenson Says:

    Jacob, I wanted to comment on this last week, but there were some other thing I had to get straight first.

    My position is that it should NOT be called knowledge process. I like the knowledge part, but I don’t like the process part. I think Max said it best: “everything that is not automatible is a knowledge process” But to most people (myself included) a process is something like an assembly like: automated, predictable, routine. A person will say “just follow the process” and they mean that you should do it the proscribed and defined way that everyone does it.

    Knowledge work is the antithesis of this. Yes, there is a process, meaning that there is a sequence of actions, but it is not at all like what we normally mean by a process.

    Let me give you an example: A doctor has patients with a particular condition. There is some evidence that drug X will will help, so he prescribes and monitors their condition, modifying the dosage and frequency. He might have to try different patterns on different people. The knowledge work is the “trying to figure out the right treatment plan” and not the treatment plan itself. Of course, to figure out the treatment plan, he has to DO the treatment.

    Let’s say the treatment is successful, and a pattern emerges that can be codified into a fixed treatment plan. Once the treatment plan is drawn up, the knowledge work ends. The patients are still getting treated, but it is no longer knowledge work for the doctor. It has become a routine.

    I think most analysts get confused about the difference between the treatment plan, and the knowledge work that is done to develop the treatment plan. The treatment plan seems like a process, but the way it is developed seems like anything but a process. The goal was always there: “find some way to help these patients.” A clinical trial of a drug has a fairly routine process, but deciding WHEN to have a clinical trial does not.

    I wrote up more of this using an analogy of an artist: The conclusion is that once the knowledge work becomes routine enough to make a process, it ceases to be knowledge work.

    I know a lot of people who deeply misunderstand what knowledge work is about. They don’t understand why software projects are late. They don’t appear to understand that money for research (e.g. Solyndra) does not always produce results. They believe the problem is that the process is not formalized, and efforts should be redoubled to do this.

    There are many reasons to like the term “knowledge process” but it will be completely misunderstood by most people. “Emergent Process” is slightly better, but the concept of “emergent” is too philosophical. That is why I focus on “unpredictable” because the knowledge work that the doctor performed was, indeed, unpredictable. It is down to earth, and people basically understand the concept. I prefer “unpredictable work” or “knowledge work” and leave the process part out.

    • Craig J Willis Says:

      Keith I disagree that ‘most people see a process as something like an assembly line’. I believed this once but just under 10 years ago I started getting more involved in software training and the sustainability of user skills on CRM systems. What became painfully clear is that most of the people I met, who actually had to use this software on a daily basis, DID NOT see process in this way.

      In fact they saw process as everything they did that went way beyond the systems they used. These users were ever skeptical of new software exactly because SIs and vendors tended to have this narrow view of process and often ignored what was going outside of their systems. And too often their fears were realized as the processes embedded in the systems did not fit with the way they worked. And the perception was that the systems didn’t do what they were supposed to do.

      This doesn’t mean that either was wrong, it was because they simply weren’t aligned. And this was because each had their own definition of process. So my disagreement is not that you are wrong and someone else is right, it’s that we all have our own understanding of what process means. When making generalizations we can make certain assumptions based on the fact that we work in the same area (e.g. IT) but once you go beyond that generalizations quickly fall apart.

      I think we have to be much more holistic when talking of process and I think that when Max uses the term Business Architecture this is what he means. And that’s why I’m struggling with this definition of ‘Knowledge Process’. Because in real life a knowledge process may often contain elements of the highly structured kind. I also don’t like the term ‘Unstructured process’ as this suggests a broken process. These processes are not unstructured, the minute you set a goal, define a trigger or delegate a set of tasks to a specific role (e.g. only an anesthetist can decide the type and dose of anesthetic) they become structured to some degree. Just because there may be no system involved recording these steps does not mean they are unstructured.

      And perhaps this is one of the reasons preventing a wider understanding of ACM by the larger business community. No-one, at least not many, would dispute the benefit of the ACM approach, but it takes a long time to understand how it’s different from what’s gone before. And I can’t help wondering if that’s because the language used by the main proponents of ACM does not adequately describe the problems it fixes in terms a majority of business users understand.

  10. Flipping the Process Life Cycle | Collaborative Planning & Social Business Says:

    […] specific knowledge to that specific particular situation.  These are what Jacob Ukelson calls a knowledge process, and they do not have the same characteristics as routine business […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: