A Knowledge Worker Cockpit

In my last two blogs, I noted the shift of the work force from production workers to knowledge workers.  Most routine work has been automated.  The work that now dominates is to resolve problems and exceptions, and to implement changes that address new opportunities or requirements.  In the future, improving the efficiency and effectiveness of knowledge workers will be key to achieving competitive advantage both through improving the delivery of greater value at competitive prices, and through the ability to quickly adapt to changing business needs.  Current technology—e.g., the Internet, mobile communications, hand-held computers—have enabled more powerful support for knowledge workers.  I believe a knowledge worker can become much more effective with controls at his/her fingertips to access information and supporting services along with interactive supports for planning, decision-making, communication, collaboration and coordination—a knowledge-worker cockpit.

The following are a few examples of knowledge work that are representative of much of the work of running and managing an enterprise.

·         Customer support

·         Process improvement

·         Professional services

·         Product development

·         Product introduction

·         Business transformation

·         Application development

·         Facility construction

·         Process improvement

·         Marketing campaign

·         Claim resolution

·         Audit

The diversity of these forms of knowledge work illustrates the potentially broad scope of application of technology to support knowledge work.

Knowledge work is not predictable.  Each situation may require a variation in the necessary tasks and decisions, but it is also necessary to plan the work for timely, coordinated action.  I believe knowledge work is most often work that requires collaboration, and that participants are often involved in multiple collaborations at the same time, with different teams.

In the Object Management Group (OMG) we are currently working on a specification proposal for modeling a case management environment that we (the submitters) call Case Management Model and Notation (CMMN).  This specification defines a language for modeling a type of case to support planning, decision-making, collaboration and coordination on individual cases. 

The following are definitions of terms used for a number of key concepts in CMMN.  These terms are incorporated in the discussion of knowledge worker cockpit functions later in this blog.

Case. A situation to be managed or resolved that may involve multiple participants and occur over an extended period of time.  In different contexts, this may be called an “initiative,” a “pursuit,” a “project,” a “campaign,” etc.

Case file.  Records or references to data relevant to a specific case that represent the history and current state of the case.

Task.  A unit of work or a delegation to an independent application, service, process or case.  A task may be performed by one or more participants, or it may be automated.  A complex task may encapsulate multiple, related tasks.

Fragment.  A reusable pattern of related tasks that occur together.  A fragment may be adapted for a particular case plan.

Event.  Specification of a change of state or occurrence in time that triggers an alert or action.

Gateway. A decision activity that may be manual or automated where subsequent actions must be determined based on current circumstances.

Plan.  Tasks, fragments, events, other elements and dependencies between them that represent the current plan for a particular case.  The plan may be revised and extended as the particular case evolves.

Role.  A specification of the involvement of a participant in the case.  Multiple tasks may reference the same role indicating that they are to be performed by the same participant.

Pallet.  A collection of the elements that are available for planning in a particular case. Such elements may be dragged and dropped into a case plan.

Lifecycle.  The phases of a case that reflect progress and determine the nature of work required during different periods in the life of a case.

A case type model will contain specifications for the case file, commonly occurring tasks, process fragments, alerts for delayed actions, decisions with suggested alternatives, events that are triggered by changes in the case file, rules that validate inputs and control when tasks can be enabled, tasks that engage multiple participants in a collaboration, and so on. 

The case type model will facilitate planning and incorporates best practices by defining templates of the above concepts for a particular type of case. This will be a significant step toward providing a knowledge worker cockpit that puts information, connections and controls at the fingertips of the knowledge worker and assists him or her in keeping track of multiple responsibilities and collaborative relationships.

In earlier blogs I have discussed case management automation as a technology to support the work of knowledge workers, but my focus has been on modeling.  In this blog I approach the issue from a different perspective—exploring ways that information technology could improve the efficiency and effectiveness of knowledge workers in both their individual and collaborative efforts. This is broader in scope than the proposed CMMN specification.  In particular, this discussion includes features that would be part of an interactive case management system, not just the modeling of a case type as defined by CMMN.

I have organized features of a knowledge worker cockpit under seven general categories that are discussed in the sections that follow.  These are features to be experienced by knowledge workers when they are doing their knowledge work.

Planning and decision-making support

Knowledge work involves planning and decision-making to organize what will be done, when and by whom.

·         Interactive planning and display options.  Planning of activities for a case requires an interactive facility for structuring a plan with display options that provide different ways of looking at the plan.

·         Filtered pallet.  There may be a number of different types of elements that may be incorporated in a plan.  A filtered pallet will offer the elements that are valid both in that context, such as the current lifecycle state, and for the person doing the planning.

·         Best practice patterns.  Relevant patterns of activities that represent best practices are provided as tasks and fragments in the pallet to make it easy to apply best practices.  Historical data can be analyzed to identify new or evolving patterns.

·         Guidance on alternatives.  When planning is required or a gateway is encountered, a list of alternatives that are based on the particular situation can be offered for consideration.

·         Contingency plans.  Contingency plans can be included in a plan to be put into immediate effect if the associated circumstances occur.

·         Estimates of cost and duration. Computations can be performed on plan fragments or proposed plan alternatives to compute estimated costs and durations.

·         Risk factors.  Risk factors for tasks or fragments can be obtained from reference information and potentially can be adjusted for particular circumstances or for consideration of alternatives.

·         Priority scheduling. Planned activities can be automatically scheduled based on duration estimates and resource availability so that priority activities may preempt lower priority activities.

Support for collaboration with others

Knowledge work typically involves collaboration with others to determine a course of action and coordinate the delivery of results.

·         Meeting scheduling and notices. Meetings can be scheduled based in appropriate participants, their availability and priority of issues.

·         Specialized collaborations.  Information, queries and conversations can engage appropriate personnel based on their role assignments and collaboration topics.

·         Teleconferencing with shared display. Ad hoc teleconferencing with shared displays can be immediately available as appropriate to circumstances and availability of participants.

·         Access to experts.  Experts on relevant topics should be easily identified and engaged in ad hoc collaboration using appropriate modes of communication.

Monitoring

Connectivity of participants through various devices and locations enable them to provide timely updates and be kept aware of evolving circumstances.

·         Tracking and follow-up.  Participants should be connected so that the current state of the case is immediately available and can be monitored to identify delays, disruptive events and variations from the plan.

·         Progress reporting.  Problems, accomplishments and progress should be reported to concerned individuals according to their interests and authorization.

·         Event alerts.  Certain changes in the state of a case should be recognized and trigger actions or awareness for appropriate persons.

·         Scheduled alerts.  Failure to accomplish actions within a specified time period, or the need to initiate actions on a schedule or at a specified point in time, should be automatically triggered and brought to the attention of appropriate people.

Control

·         Validation of actions. Certain actions (e.g., prescribing a medication) can be validated against facts of the particular case.

·         Authorization.  Restricted actions or decisions can be automatically directed for approval.

·         Checklists.  Lists of potential actions or requirements can be adapted to a particular case to generate follow-up tasks and tracking.

·         Signatures.  Electronic signatures can provide assurance that a document was created or approved by the designated person and that the content has not been changed. An electronic signature can also include specific versions of documents the signer relied upon when endorsing the primary document.

·         Prerequisites.  Planned tasks can be deferred or enabled based on the state of the particular case. Prerequisites may determine activities that must be completed or data that must be available before a planned activity can become active.

·         Planning constraints. Availability of elements for planning can be restricted based on the authority of the planner, the facts of the case or the current lifecycle phase.

·         Application of policies and best practices.  Policies and best practices can be presented to participants when relevant, and can be expressed as rules that restrictor provide guidance for plans, decisions and actions.

Management of participation

·         Resource acquisition, assignments.  Resources and personnel can be acquired and assigned based on availability and priorities.

·         Shift-based teams.  In multi-shift operations, participants must be scheduled as active in their roles during their assigned shifts.

·         Assignment changes.  Alerts and pending actions must be redirected when an active participant is replaced.

·         Sub-teams.  On large projects, multiple teams will work on the same initiative with different plans requiring coordination and shared case information.

·         Participant availability.  Task assignments must reflect participant availability recognizing competing responsibilities and time allocations.

·         Separation of responsibilities.  Persons must not be assigned to roles where there may be a conflict of interest or loss of checks and balances.

Participant personal support

·         Personal viewpoints.  Individuals must be presented with personalized information about their involvement in multiple cases including their personal work list and schedule of tasks.

·         Schedule management. Individuals can modify their schedule to reflect personal preferences and constraints.

·         Priorities.  Participant assignments must have priorities with visibility of effects of delays.

·         Resource requirements.  Participant’s tasks must reflect supporting resource requirements, such as equipment or raw materials, with support for obtaining or scheduling required resources.

·         Progress notes.  Participant progress notes should be included with task records.

·         Record of conversations.  Participants should be able to retrieve threads of messages and meeting notes related to specific topics.

·         Data input requirements. Tasks must provide forms and instructions for entry of appropriate data.

·         Input edits.  Entered data should be validated for syntax, spelling and possible values (e.g., valid state names for a state field) as well as other measures to eliminate inadvertent errors.

·         Computations.  Where appropriate, tasks should include computations to provide supporting information.

·         Personal library.  A participant may capture task specifications fragments and other elements in a personal library to be re-used in the current or other cases.

Information access

·         Case file.  Data on the state of the case must be available and retrieved automatically when appropriate.

·         Reference collection.  A collection of reference information, relevant but not specific to the case, should be available through appropriate searches.  Reference information should be automatically retrieved when particularly relevant.

·         Support for conditional expressions.  Conditions of rules and constraints must be expressed in terms of appropriate case data to implement restrictions or trigger actions.

·         Searches and queries.  Participants must be able to easily find information that is relevant to particular circumstances for current analysis, planning and decision-making.

·         Analyses.  Participants must have access to analysis and modeling tools along with supporting data to properly analyze the current situation, identify historical patterns, and anticipate potential consequences of decisions.

·         Event-driven updates.  The case file should be automatically updated as external events are reported so it reflects the current situation as accurately as possible.

Summary

This list of functions represents a vision of future support for knowledge workers.  Many of these functions are performed in some way today, some with assistance of information technology. Those supported by information technology are seldom integrated to provide a seamless onnection of the knowledge worker to the case and other participants. 

Many of these functions are considered in the proposed CMMN specification for modeling case types.  A case management model will also provide a context for access to supporting functions such as related services, computations and identification of risks.  However, CMMN only addresses modeling of case types, so availability of many of these features will depend on the particular implementation of a case management system.  In addition, the full support of knowledge work will require supporting infrastructure, integration with related systems, and development of additional standards.  For example, development of electronic health record standards is a key requirement for automated patient care management.

In the long term, these functions should be provided in an integrated environment, a cockpit, that surrounds and links knowledge workers with appropriate information, collaboration support and controls as appropriate to the type of case and their particular responsibilities. 

For additional perspectives on case management and the nature of knowledge work, see Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done, by Keith Swenson, et al.