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

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

3. 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

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

5. Documenting an activity and the associated management systemIS

6. Activity Analysis Worksheet

7. Activity Cost WorksheetIS

8. 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

9. Performance
Factors IS

10. 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

11. 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

12. 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

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

14. 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

15. 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

16. 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

17. From assembly line to consultant?
Can this really be automated? Under what conditions? IS

18. 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

19. 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

20. 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

21. 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

22. 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, s
Mining of payroll or PM systems to determine project assignments
Some of the better Customer Relationship Management systems IS

23. 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

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

25. 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

26. 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

27. 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

28. 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

29. 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
Blame free environments
Accept ideas from ‘below’ IS

30. 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