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.

I am the founder and Chief Technology Officer of ISIS Papyrus Software, a medium size software company specializing in communications and process management. I wrote several books and hold a number of patents. My quest is to bring common sense to IT, mostly by focusing in human quality issues rather than cost saving, outsourcing and automation. I am also Chief Architect at VIPorbit software which provides mobile relationship management.

Tagged with:
Posted in Adaptive Case Management, Business Architecture
5 comments on “Principles of Knowledge Work: Why Goal-orientation?
  1. […] ACM and Goals – Max J. Pucher Without a clear term definition for the business users which I see as part of […]

    Like

  2. Lorenzo says:

    Dear Max,

    Very interesting post. I really appreciated your explanation.

    I agree with your definition of goal. But when you are talking about “define goals”, who is responsible to define them and how could they be defined? The business user or the person who is responsible for the process (as I understood the former is the user who performs activities within an organization)? Usually dealing with ACM means starting with a template that could be arranged during the execution of a particular process. Does your “define goal” mean to make explicit the goal within the template or somewhere else? How to achieve it?

    Thank you in advance.

    Regards,
    Lorenzo

    Like

    • Lorenzo, thanks for reading and commenting.
      Typically the business has to identify a responsible process owner. In most cases the relevant performers would report to him/her. The process owner coordinates the definition of goals with other POs in the complete value stream (handovers) and aligns them with the strategic business objectives and operational targets and KPIs. Yes, the goals are an explicit enumerable definition (to verify if it is reached or not) for one part of the process. Necessary tasks can then be attached to the goals. Once a goal has been reached it can also be saved as a template again. This would be decided by the PO.

      Regards, Max

      Like

      • Lorenzo says:

        Dear Max, thank you for your reply.

        As I understood you are saying that the PO is responsible to create the template and define the goal(s). About the goal definition, do you adopt a specific language (e.g. a Goal-Driven Language)? Define goals is a quite complex mechanism since goals can vary based on the process under control.
        In my opinion there are different mechanisms to define goals. For example, goals could be specified through a specific language (I’m not sure about this), could be defined as a state of the process (like a sort of ECA rule) or could be specified as an event occurence. What do you think about this? Am I totally wrong?

        Furthermore, goal(s), as a process(es) does, can evolve during its execution. The business user (I consider it as a synonim of the Knowledge Worker term) could decide to change a goal based on her/his experince.

        Thank you in advance.

        Regards, Lorenzo

        Like

  3. Dear Lorenzo, you are right on the money. A language would be best but semantics are difficult. We use a goal object as part of the case definition and if desired the user can add a goal-defining rule. The rule writing is guided by the terminology in the ontology and by the data attributes used in the case. We use that approach so that the data are actually available to compute and the semantics are firm. Yes, the goal achievement might be influenced by events in both directions. If allowable the goal might be changed or even substituted by another one. The authority to allow or disallow that has the PO. Adding goals to deal with events is most normal. The state of any case object is accessible by the rule language. Regards, Max

    Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

Max J. Pucher
© 2007-16
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 200,855 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 8,157 other followers

%d bloggers like this: