Principles of Knowledge Work: Why Goal-orientation?

For some time we have tried to come to a kind of ‘Standard Model’ of ACM. Because there are so many approaches to ACM this has not been achieved. Some of the difficulty is that despite being performer driven, knowledge work still requires a planning perspective and effort. In what way can this planning be supported and still remain adaptive?

Planning work is not modeling!

Modeling is abstraction. But what the business needs is real world processes, not models in abstract language. I have proposed before that a business focused terminology has to be defined that describes both data and functional elements in terms that everyday people can understand. Many seem to believe that my fairly far-reaching considerations have to do with my skeptic stance towards BPM and that ACM will replace it. That is not the case, while that’s what will happen eventually, but it may no longer be called ACM.

To move away from that emotional hurdle, let me start like this: even if we look at it from the perspective that ACM only covers some subset of work (processes or not) that a company performs, then it still has to be aligned with the overall business strategy and operational plans, correct? Is there any work that should be kind of performed disregarding company objectives and management guidance? Clearly not. Much like documents we can dump work that is not linked to a process and in fact goal: WHY do we do it?

Now, if you give someone a rigid process, someone else has already thought about (in the governance bureaucracy doing process analysis) how to blend the business needs into the process flows. The performer just hammers happily away at his keyboard, ignorant to what the point of his work is. Great. Enter ACM and those poor sods, the so called knowledge workers. They are now expected to perform according to their knowledge of what the business or customers need to have at this point. In what way should that be less aligned with business strategy? Obviously they need to work towards it just the same, but unfortunately they are expected to do it kind of on the fly without strict step-by-step guidance. Mostly because of customers who are chaotic nitwits who can’t follow the process someone else considers to be ideal.

I propose that to achieve this, it is essential to create a top-down transparency of business objectives and targets for the value streams and the goals that process owners need to achieve. We define basically WHY we do what we ought to do and make it transparent to the performer. So the whole mumbo-jumbo of process optimization in the governance is suddenly a transparent exercise of everyone involved and it happens upfront before you even start to do the process. We still haven’t described any of the work, but we know WHY we should do WHAT for the customer. Knowledge workers are experts at the HOW and we tell them where to apply it and what the outcome of their work should be.

Knowledge Work: The only way is Up!

I have further proposed that the same concept is perfectly suited to be applied to change programmes, projects, plans, processes and cases? The higher you go in the hierarchy, the less flow-oriented work becomes. Adaptive management concepts can be applied at all hierarchy levels and on all time scales. Clearly, a project is not instantiated the same way fifty times, but the entities to describe a project are the same as to describe a process. We can spend a lot of time on abstract term definitions to describe the WHY, WHAT and HOW and we should, but in the end that term definition must be in business language. Regardless if they describe a project or a process. The entities and functions are the same.

One can have a very low-level conceptual definition that allows more flexibility but requires more knowledge by the user. Or you supply a limited functions set and with it a limitation in use. Some may be quite technical such as taxonomy, ontology, object, property, transaction, or assignments.  Properties might be used to identify (class), name (user) or link concepts together. Use that and you just lost the users!

It is important to use real world concepts such as activity, tasks, goals, documents, notes, times, business events or legal constraints. In terms of describing the work progression one can use events, decisions, calculations, rules, and conditions. Data types should be real world such as time, count, amount, and duration. For people we need skills, roles, hierarchy, and authority. To describe the environment that the user will interact with you have applications, processes, user interfaces, services, and forms. Keep it simple but unambiguous.

The main problem with the fundamental terms of ACM is that they have to be used ADAPTIVELY, meaning all elements must be open to change by the performer or basically anyone at any time. That does not mean to change the definition of the concepts itself. That is IT and architectural work. But in what way those concepts are assembled to represent knowledge work must be up to the business performer! While any kind of graphical editor is cute (flow or entity graphs) the whole point is to open the work descriptions of WHY, WHAT and HOW to business people: executives, management and performers. They want an intuitive, real-time representation of the ‘things’ that drive the business. Sounds easy, but really isn’t.

Goals, milestones, tasks and more …

Adaptive means that business people create the work tasks on the fly to achieve defined goals and can reuse those definitions in future when they want to work on those goals again. Goals ought to be linked to objectives and targets (KPIs and SLAs) to ensure that the business performs. BTW, ad-hoc tasks or allowing central changes that are immediately deployed to all processes DO NOT provide adaptive capability! That is still rigid, orthodox process management.

People tend to look at goals as milestones or sub-processes/cases. Keith Swenson recently suggested in a LinkedIn discussion that one can look at goals as tasks. Yes, one can but why should that make things simpler if it creates confusion? I propose that a goal in the sense of a business guideline is something quantitative, which does not have to be enumerable or measurable. Outcomes maybe quantifiable but still subjective. Operational targets are usually KPIs but they might still not be measurable. Service levels are typically measurable and enumerable as they are set up this way.

For projects a task could be used as a milestone but I propose to make it an explicit entity. A milestone is a time-line synchronization juncture and might be related to a goal, i.e. completion of all required tasks.  A milestone might be a decision point with or without a rule (i.e. once you reach runway speed V1 you must takeoff). It is still not a goal while you work towards it. I use the term objective for goals that are very abstract in the sense of a business strategy. ‘Increase revenue by 10%’ is an objective. Objectives are mostly achieved when the related targets, goals and rules are satisfied. But they can also be completely subjective and just checked off by the relevant person.

Without a clear term definition for the business users which I see as part of the Business Architecture, there won’t be real world use of ACM or BPM. Most of all business people won’t be able to describe their work without that language of process that reduces ambiguity. In the end the business choses to use the terms they want, but they should not be restricted by the limitation of a system that doesn’t allow goal definitions.

About Max J. Pucher

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

‹ Process Maturity versus The Real World of the Higgs Boson

Sapere Aude – An Age of Enlightenment for Business? ›

Tagged with: goal-orientated process
Posted in Adaptive Case Management, Business Architecture