IS 788 [Process] Change Management Lecture: Activity modeling + a brief introduction to cognitive engineering IS 788 6.2

Modeling Activities An activity is the smallest (sub)process analyzed in a process design effort MORE than a process however; at the activity level the behavior – of human actors or IT systems – becomes significant and needs to be described IS 788 6.2

Activity description level of detail Frequently activities are not modeled graphically but rather by action (step) lists in text form (see fig. 6.2) If simulation is to be performed on the process model, cost and time details for many of the steps will need to be gathered Some steps will require decisions and the rules governing these decisions will need to be documented (see fig. 6.2) IS 788 6.2

A simple activity example Often forgotten in process design What the performer must know Data that must be available to perform the activity. IS 788 6.2

Documenting an activity and the associated management system IS 788 6.2

Activity Analysis Worksheet

Activity Cost Worksheet IS 788 6.2

Human Performance Analysis This area of analysis is invaluable – it literally makes or breaks a process – yet it is rarely if ever considered in IT systems analyses. Steps and rules for aspects of human performance analysis should be made part of the process or processes that monitor the modeled process IS 788 6.2

Performance Factors IS 788 6.2

Discussion Who works for a company that implements management plans along with revised processes? Who works for a company that implements a performance analysis for activities? IS 788 6.2

Managing the performance of activities An operational manager’s responsibilities Identifying goals to be accomplished Communicating these goals to employees Organizing activities to accomplish those goals – including insuring adequate resources Monitoring the activity output wrt goals Diagnosing and fixing problems with the activity IS 788 6.2

Performance analysis – a simple example – a typical sales process Consider the sales activity shown in figures 6.6 and 6.7 A simple improvement plan Document the activities at a high level Using historical records, document the performance of all employees Address low performers If there is a large gap between best performer and average, analyze (human) performance variables Reference the performance analysis on Figure 6.8 Is this analysis applicable to any other processes? IS 788 6.2

Modifying a process to include automation – expense report 2 Compare this with Figure 6.1. What has changed? IS 788 6.2

Process Analysis vs. IT systems analysis Note the interfaces in figure 6.9 – every arrow between the system and the human actors Depth of analysis of interfaces for process work might include a sketch of the screen(s) and a use-case However, the system itself is treated as a black box It is implicit that IT will require more information – but process analysis assumes the work is performed by an intelligent person. Much background is assumed. IS 788 6.2

Activities vs. jobs (see Fig. 6.10) Only in the most simple and ideal cases will an activity (or a process) correspond to a single job (employee) Most employees will perform multiple activities, each in a distinct process. This complicates (inevitably): Monitoring performance Training Activity assignment (or reassignment) Process change – everything is connected to everything! IS 788 6.2

Automating knowledge work and business rules There is a knowledge continuum from simple (i.e. retail sales) processes to expert (i.e. software architect) processes An increasing amount of work in the US is knowledge work, potentially defined by the number of rules and the amount of judgment required in its execution IS 788 6.2

From assembly line to consultant ? Can this really be automated? Under what conditions? IS 788 6.2

Knowledge workers vs. experts It takes ~ 10 years and 1000’s of ‘chunks’ of information to become an expert (medical diagnosis ~ 10,000 rules) Knowledge work is intermediate between routine and expert tasks and is important because of the growing number of persons involved. Makes a difference in determining the type of processes to support IS 788 6.2

Knowledge workers vs. experts (2) Expert systems are much less popular than 15 years ago – they proved impractically difficult to maintain. Knowledge evolves constantly. However, both expert (and knowledge) workers can be supported by knowledge management systems IS 788 6.2

Modeling knowledge work Difficult due to The number of rules involved The need for judgment (ambiguity) The rapid change of knowledge However, it is precisely the rapid shift in knowledge combined with high turnover in many KW fields that makes modeling KW beneficial Examples – hi tech workers in the military and in industry So there is a payoff, even though the modeling of KW processes and construction of support systems is expensive. IS 788 6.2

KW modeling is beyond this course It involves Cognitive task analysis – what cognitive processes are involved Knowledge documentation and capture Rule (knowledge analysis) capture and documentation Development of training systems Specification of KW support systems IS 788 6.2

Some KM systems Which require process and cultural changes to support them: Lessons Learned Systems Organizational Expertise Systems Mining of the unstructured text in memos, e-mails Mining of payroll or PM systems to determine project assignments Some of the better Customer Relationship Management systems IS 788 6.2

Business rules For both routine and knowledge work, capturing business rules is integral to the modeling effort Notationally, rules are represented by decision ‘diamonds’ IS 788 6.2

Expert rules & business rules (examples?) Business rules derive from policy Expert rules derive from observing what an expert does. IS 788 6.2

The merest introduction to cognitive engineering (from Norman, The design of everyday things) For IT systems the field is called HCI (human-computer interface) For process design it doesn’t even have a name yet. We’ll call it HPD (humanized process design): the incorporation of error detection and appropriate user feedback in processes IS 788 6.2

Humans make mistakes The same abilities to generalize from limited information that make humans adaptable to new environments – cause them to make mistakes The ability to “automatize” a set of steps and so require less cognitive effort is good many times but – causes people to make mistakes And so it goes. IS 788 6.2

Good processes anticipate error Whenever possible, feedback on performance of a task should be built into the task. This applies primarily to the design of activities. Self correcting (feedback producing) activities are far more effective than after-the-fact monitoring Be sure you are monitoring and providing feedback on the appropriate action and level of the task (see Norman’s example on page 111.) IS 788 6.2

Specific design points Ideally it should be possible to recover from errors in every process step (no ‘delete *.*’ activities) Make your decision points either Wide and shallow (few steps, many alternatives to each) Narrow and deep (lots of steps, each easy) If too much cognitive effort is required for a single activity, refactor! IS 788 6.2

Minimize social pressure If you allow process actors to do the right thing, they will If you pressure them – subtly or overtly – to take shortcuts, they will Discuss examples, Norman pp. 129-131 Blame free environments Accept ideas from ‘below’ IS 788 6.2

Forcing functions If a sequence of operations is critical, force it! Or redesign the critical activities to be non-critical. Do not expect training to take the place of good process design. The lower cost the labor, the more true this is. (Challenger exploded because the wrong ‘o-rings’ were installed by mechanics who were well trained, but not in the critical activity of o-ring selection.) IS 788 6.2