Exactly one year ago, Fred Cummins published a blog post called “A Knowledge Worker Cockpit” which remains today one of the best descriptions of the kind of information system that an active knowledge worker needs to keep on top of unpredictable processes. Over the year I have started a couple of time to critique the article, and finally here it is. There is a lot to agree with, but a few things I would suggest differently.
Overall it is an excellent vision of what a knowledge worker needs and might use. If you haven’t already, link over there and read it now. It is not (in my admittedly opinionated eyes) completely perfect, and I will spend the bulk of this post criticizing some niggling aspects in detail. You should not, however, conclude that his original proposal is riddled with problems.
Synopsis
After defining terms, there is a description of a case folder and the kinds of things you would find there. Earlier posts had focused on modeling, which might be appropriate for Production Case Management (PCM) but not for Adaptive Case Management (ACM). This post is on planning while you work, something that knowledge workers are forced to do because the process can not be precisely predicted ahead of time — something he calls “Interactive Case Management“. He makes it clear that this is broader in scope than the OMG’s Case Management Modeling Notation (CMMN).
He lists capabilities needed:
- Planning and Decision Making Support
- Support of Collaboration with Others
- Monitoring
- Control
- Management of Participation
- Participant Personal Support
- Information Access
Positives
I like the specific mention of “planning” as a primary activity of the knowledge worker. It is not called “modeling” as so often BPM discussion do, and for a good reason: the knowledge workers do not see themselves as modeling their work, but rather they are doing their work which happens to be planning. That is an important point of view.
I like the depiction as a “cockpit” which symbolizes a central place where all the control are available, and does not symbolize the automation. The pilot is still the pilot and makes the decisions and in this way you leverage the knowledge and expertise of the knowledge worker.
I like the focus on the how the case manager sees it, and not on how the developer sees it. Instead of being described as a “system” which supports many case managers, it is a cockpit for an individual case. This viewpoint is important, because different case managers are going to using different systems for different kinds of work, and thinking that an organization will get a single “system” for all the knowledge workers will end up frustrating many workers. The cockpit is an individual space tuned to a particular kind of work.
Design Consideration
While you read about the cockpit, there is one thing you need to keep in mind: knowledge workers (case managers) are in a hurry. They are busy. They just want to get the job done as quickly and effectively as possible. They often already work long hours. When they are in the middle of an important case, they are not thinking about other cases that might benefit by a change in plan. If they see the need to get something done, even something they have never done before, they want primarily to get that done.
A doctor designing a treatment plan for a patient does not want to address the added complication of how future patients might use a variant of this plan. They don’t have to time to sit and write a conditional expression that determines whether this activity is needed or not in future cases. Any time they spend worrying about future cases is taking time away from their current, urgent case. If adding an activity to a case plan takes more trouble than a phone call (& follow-up) to ask someone to get something done, then the case manager will opt for the phone call instead.
This single design consideration is probably the most important factor in determining what a knowledge worker cockpit needs to do. It puts an extreme limit on how much trouble you can expect a case manager to take.
Negatives
Some of these are quite subtle, but I will start with the more obvious.
Support for Innovation
It seem that the knowledge worker is still a second rate citizen when it comes to planning. The descriptions are that there are “palettes” of types of activities available, and the presumption is that there will be so many that they will need filtering. I don’t see a mention of making a task from scratch.
For example, Jeanette, who is responsible the launch of a large budget movie, hears that Apple has announced the new “iShades” which are wearable iOS devices, and determines that new version of the promotional game will need to be created to fit this new format. The case manager want to create a task and assign it to someone. There won’t be a “Create iShades App” task in the palette. How does one get one? Does Jeanette have to call in a programmer? Let’s assume that the cockpit has a way to create a new type of activity at any time.
Validation of Task Placement
This is further supported by the idea that the system will validate whether the activity is appropriate or not for the context. Great idea, but consider the implications. There must be a large set of rules that can tell when an activity is valid. Who enters these rules? Who tests them? Consider again the above example, when a knowledge worker constructs the “Create iShades App” activity, how does the knowledge worker specify the contexts for which this activity is valid? More important, why would a knowledge worker bother? The knowledge worker knows that it is valid for this particular case — based on their expertise and knowledge of the world. It would be a much greater amount of work to determine all the possible situations that you might need the task. We are seeing an attempt to automate the judgement of what activity to do — but that is the job of the knowledge worker. Presuming to know precisely what situations you are going to need this activity, means that you are not really addressing unpredictable processes in the first place.
Validation of activities is a kind of Holy Grail: conceptually it would be a great way to make life easier for the case manager. We can think of a few trivial cases that work well: wouldn’t it be great if the system could tell the doctor when he was prescribing too much medication. But knowledge workers, by their very nature, are not doing trivial, predictable tasks! It would be impossible to make such a rule base for unpredictable tasks, and in any case it is a lot of effort with very little value. It is simpler, and much more cost effective, to simply let the knowledge workers decide what they want to do when.
This does not mean that the case manager is completely without guidance. Fred also mentions the idea of mining the history to find out the sort of activities that are typical according to what has gone before. These are suggestions, and not validations.
Role of the Case Manager
My final criticism is much harder to pin down, so please bear with me. The tone of the entire piece is one that the knowledge worker is a user, and there are designers elsewhere who “set up” the system. You see this in the knowledge worker “picking” the activity from a list, but no mention of creating from scratch. You see this in the description of things that are going to be done “automatically” for the konwledge worker, but no description of how the knowledge worker sets up this automation. The knowledge worker will need to contact the IT department in order to get any change to the system. The article does not say this exactly, but it is strongly implied in many places.
Perhaps this is just an oversight that was accidentally left out of the article, but you will notice a tendency to see the knowledge worker not as an innovator of tasks, but instead as an operator who plugs things together that were provided by someone else. Who is that someone else? In an adaptive system, there should be no distinction between design time and run time: all options should be available all the time.
Notice that it describes a separate facility to create plans. I have found that even just making someone go into a separate mode from working, is enough to prevent use. Remember what I said above about knowledge workers being in a hurry and just wanting to get the current job done. Going to a separate mode to make a plan when all you really want to do is ask “Joe to do X”, is a barrier.
The knowledge worker needs an integrated cockpit where planning is not separate from working, where planning is an integral part of completing daily work, not a separate mode.
Conclusion
Essentially it is the right idea, but it needs to emphasize the knowledge worker as the primary innovator with ability to most things without any IT support, and to de-emphasize the role of “automated” tasks and “validation” which take coding that the knowledge worker is not likely to do.
Thinking Matters 
Hi Keith, good critique!
I have posted about a knowledge worker cockpit as a ‘social workplace’ in 2010 – http://isismjpucher.wordpress.com/2010/12/18/the-social-workplace-on-your-ipad/
The ‘Social Workplace’ for the knowledge worker needs to provide:
1) A user-definable GUI with dashboard features that can also be auto-deployed to different tablet and mobile technologies.
2) Enable workers and their customers to register, link-up, define roles/skills, assign tasks and delegate authority.
3) Information about individuals such as role, skill, calendar, tasks, contacts, notes, and reports while retaining security and privacy.
4) The linking of individuals into value stream capabilities to create a goal-driven organization in which process owners can define their desired outcomes that link capabilities.
5) Adaptive Processes that are created by the business performers with definable rules that feed knowledge and experience back into reusable templates.
6) Individual solution to problems provide emergence, but have to be guided towards the common business goals – linked to strategic objectives and operational targets (KPIs and SLAs).
7) Task and check lists linked to goals and outcomes replace the BPMN diagram for the business user. No need for validation of flows but it is needed for user defined rules and goals.
8) Business entities and content mapped to exposed back-end transaction services must provide the business context.
Max. Thanks for the comment. Those are all key points on required capabilities, and from what I know about what you do, it probably a better summary of what a knowledge worker needs than Fred’s. But one thing I liked about Fred’s description was the “individuality” of the cockpit. It is ironic that I see individuality as key to collaboration. (There is probably another blog post in that idea.) A social workplace still sounds centrally provided. If I use my social workplace, and you use your social workplace, there is no guarantee of interoperability. But the “cockpit” concept says that if I can use my cockpit to collaborate effectively, it does not matter what kind of cockpit you use. I know this is a nit-picking distinction reading way too much from what is really just a metaphor, but do you see what I mean?
HI Keith, thanks. I absolutely agree on individuality. Under 1) I do state that the GUI is user-definable (up to a point in terms of authorization). It is in principle role-based and provided centrally. Not sure what more individuality you are thinking of. There has to be functional compatibility, which is also provided by the common data models and the case management.
Keith,
Thanks for the feedback.
Maybe I did not make it clear, but my intent of the “cockpit” is not to control the knowledge worker, but rather to make the job easier, making it unnecessary to repeatedly create similar plan elements and plans, and to provide some useful guidance much as we might provide a check-sheet to help avoid oversights.
Certainly the knowledge worker should be able to create any task they want, but for much of what they do, they have done many of the same tasks before and a palette of common tasks or sequences of tasks should make the job easier.
For specific types of action like a doctor writing a script, it’s useful to have the form to fill in, and this also provides the opportunity to advise of errors such as medication interactions, allergies, atypical dosages and inappropriate diagnostic codes (for billing). For collaboration, pre-defined actions can delegate responsibility, facilitate meetings, message exchanges or concurrence and obtain required approvals on decisions, minimizing the coordination, tracking and follow-up effort. It would be nice if a doctor did not need to spend time on the telephone taking to an insurance clerk to obtain prior approval for a medication or procedure. Such collaborations could a least be coordinated and tracked to minimize demands on the doctor..
As you note, most knowledge workers focus on getting the job done, not designing future jobs, but at the same time, they should have the ability to create their own “personal library” of tasks and fragments they find useful–to innovate. They should also provide input and participate in improving the pre-defined tasks and fragments, and I don’t see the design of those tasks and fragments as an IT (i.e., programmer) responsibility although some analysis, design, problem-solving and collaboration skills, along with business knowledge, will be important.. This is about the operation of the business, and the case models must be owned by the business organization.
Of course, some tasks will define the connections to traditional business processes of supporting services. These tasks just make it easier to initiate an action and follow-up to ensure it gets done.
I do believe people distinguish their efforts at planning from doing. Of course some things get “planned” ad hoc–and the action may precede updating of the record. There is a need to design the user interface so that recording actions completed is easier than creating a plan for what you have already done and then “pretending” to execute it.
Again, it must be about making the job easier and getting better results. If it means taking away control, or creating more work, it will fail.
Fred Cummins.
Fred,
Thanks for commenting! I am sure there are many things I read wrongly and misunderstood, so I appreciate the clarification. I am sure there is plenty of ground for a lot more ongoing discussion about this.
Forms: There are many situations when I am sending email that I would LOVE to have a form to fill in. A properly constructed form, with all the right fields for what I am currently doing would help a lot. The problem is that it is too much trouble to create the form, and I am not sure I am going to get enough benefit from the form. In many cases the form I need probably already exists, but finding it is a lot of work as well. So, I write prose because I can do that quickly and without delay. It seems so low-tech, but it works. One of the conceptual mistakes I see people make is over emphasizing the value of a form, and under valuing the cost that it takes to create / find / maintain those forms.
For example, if it is going to warn of errors, then I have to put in logic to determine when something is an error. This can be hundreds of times more expensive than just writing the email in prose. Of course there is a benefit, but I can’t see a doctor writing this kind of thing.
By the way, I don’t see other forms of BPM going away, for routine tasks that need forms, validation, etc. I fully expect they will use traditional Human Process Management (HPM) and Process Driven Server Integration (PDSI) for that. Those applications will NOT be replaced by a Knowledge Worker Cockpit. Given that those exist, there is far less reason for the cockpit to have this capability.
I think we are mainly on the same page.
Keith,
Keith,
I agree with you that there are limitations to using forms. However, I think that as we recognize the value of the concept of forms for consistency, completeness and validation, we will find ways to make data entry more flexible and accomodating. The definition of tasks and process fragments as well as the “case file” (including relevant information from many sources) will also help put forms and rules into context and thus easier to identify, and the feedback on input should become more immediate and meaningful.
I expect the cockpit to engage a variety of capabilities including data query and visualization along with repeatable processes that are outside the scope of ACM, per se, but enhance the ability of the knowledge worker to do his/her job. Well-defined actions should be easily identified and engaged without the need for ad hoc analysis and design by the knowledge worker.
The technology to provide this basic environment should lead implementers to improve ease of use and effective feedback for competitive advantage. The business analysts that develop the case models will require a new level of skills and insights to provide useful elements that are easily identified, easy to use and are appreciated by the end users.
Fred, Keith, forms and rules need to be linked to data and forms without rules are usually not valuable. A form makes only sense when there are predefined work items that are going to be used very frequently. Without rules there won’t be immediate feedback. In most cases forms are used to provide input to case rules. In dynamic work situations user-definable natural language rules using the data set of the case are a lot more realistic and practical to use, because they can be ad-hoc.
Fred, I disagree that data queries, visualization and repeatable processes are outside the scope of ACM.
If the business analyst who defines the case models will require new sets of skills then I think the whole idea is doomed to fail. The business analyst must need no more skills than his analytic ability. The business analyst is an enduser! To create new cases must not need business analysts either but can be defined by performers. The analyst just helps to link goals to targets and objectives and helps the process owner to define customer relevant handovers and outcomes. What needs special (IT) skills is to map the business and operational data (via SOA) into the data model of the ACMS.
Let me also say that I am not talking about what would be nice to have in a knowledge worker cockpit, but about functionality that is available and used today. Thanks, Max
Reblogged this on Things I grab, motley collection .