HIM and New Way of Working
•Download as PPT, PDF•
1 like•861 views
Human Interaction Mgt. & the Future of Work
![Human Interaction Management & New World of Working Pascal Ravesteyn Universiteit Utrecht – 2011 [email_address]](https://image.slidesharecdn.com/bpmuu2011-2012-himandhnw-111221033710-phpapp01/85/HIM-and-New-Way-of-Working-1-320.jpg)
![Outline ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to HIM and New Way of Working
Similar to HIM and New Way of Working (20)
Recently uploaded
Recently uploaded (20)
HIM and New Way of Working
- 1. Human Interaction Management & New World of Working Pascal Ravesteyn Universiteit Utrecht – 2011 [email_address]
- 3. BPM project - Sales process diagram, normalized view
- 4. Applying BPM technology - Workflow management A4 Exceptions… Process engine - Orchestration Business Activity Monitoring Trx Klant Trx Trx Trx Trx A1 A2 A3 A5 D1 Rules
- 5. BPM project – Workflow process model for Sales
- 6. A possible typology of processes Process predictability Highly predictable (Design time context defines possible Process paths) Somewhat predictable Unpredictable (Dynamic Context drives Process) Collaborative intensity No people Involved during runtime 1 person at the time, Serial coordination Multiple persons - Highly concurrent collaborative Human Centric Processes Note: processes will often have fragments that fall in different areas For instance: simple process with complex exception Source: Loggen, 2008 Straight Through Processing E-Forms Workflow management Case management Human Interaction Management Collaborative BPM
- 7. Examples HUMAN CENTRIC PROCESSES: Knowledge intensive Adhoc, adaptive, dynamic Collaboration intensive Human interactions Complex B2B Solution Selling (Agile, Iterative) Software Development Complex Medical Case Police investigation or Legal trial Organizing a Scientific Conference But please… Compliant Transparent Aligned with strategy Productive, efficient Product development
- 8. Relevance: McKinsey and Drucker “ The most important, and indeed the truly unique contribution of management in the 20th century was the 50-fold increase in the productivity of the manual worker in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and the knowledge worker” Peter Drucker
- 9. The issue….. Highly predictable (Design time context defines possible Process paths) Somewhat predictable Unpredictable (Dynamic Context drives Process) Collaborative intensity No people Involved during runtime 1 person at the time, Serial coordination Multiple persons - Highly concurrent collaborative Human Centric Processes Note: processes will often have fragments that fall in different areas For instance: simple process with complex exception Today’s reality: Emails… Spreadsheets… Documents… Actionlists… Phonecalls… Meetings… Information overload Process predictability Source: Loggen, 2008 Straight Through Processing E-Forms Workflow management Case management Human Interaction Management Collaborative BPM
- 10. Relevance: Key questions How often do you receive email? Scroll through it? How often do you get CC-ed? Do you use email as coordination tool? How quickly do you understand context, status, role and required action? How often do you need to (re)assess it? How much effort does it take? How much time versus time spend on the value added activities? How often do you fit in a (simple) design-time flowchart? How often are you involved in human centric processes? How much time (%) compared to more predictable processes? Key question: Is there a way to make collaborating knowledge workers more productive?
- 12. New Way of Working (NWoW)
- 18. Het Nieuwe Werken – Aanpak HNW 4 Vlakken Model
- 20. Cultuur Baby Boomers Generatie Y Generatie Nix / X Net Generatie / Z
- 29. Socio-Technical Theory The term sociotechnical systems was coined in the 1960s by Eric Trist and Fred Emery , who were working as consultants at the Tavistock Institute in London
- 31. HPT Model D.M.Van Tiem, J.L. Moseley, and J.C. Dessinger, published by ISPI in 2004
- 32. Speech Acts (SAT) Source: http://openebxml.sourceforge.net/Index.html
- 33. Design & Engineering Methodology for Organizations (DEMO) Source: DEMO kenniscentrum 2008
- 34. Role Activity Diagrams (RAD) Source: http://www.instream-dev.co.uk
- 36. Example HIM vs. BPMN Request for Proposal Figure - Respond to Request for Proposal (An attempt to capture the process using BPMN) Source: Keith Harrison-broninski BPTrends December 2008
- 37. Figure - Respond to RFP (Executable process diagram in HIM notation) Source: Keith Harrison-broninski BPTrends, 2008 HumanEdj
- 38. Source: Keith Harrison-broninski BPTrends December 2008
- 40. Gaming – Community Building
- 41. Towards a new look on human processes Objectives Events Presence Documents Policies & Rules Roles Planning & Commitments Network Earlier patterns & Best practices Automated Services Context Driven Interactions & Communication Knowledge People and their behavioral patterns in collaboration & knowledge work Human Interaction Management System Agents Power Context & Status Leadership Influence Control Company strategy Actions & Decisions People Meaning & Relevance Information “ Story” Decision Support ASE’s Collaborative Patterns Entities Channels History & Audit trail
- 43. References
Editor's Notes
- 12/21/11
- 12/21/11
- 12/21/11
- 12/21/11
- In organizational development , socio-technical systems (or STS) is an approach to complex organizational work design that recognizes the interaction between people and technology in workplaces . The term also refers to the interaction between society's complex infrastructures and human behaviour. In this sense, society itself, and most of its sub-structures, are complex socio-technical systems. The term sociotechnical systems was coined in the 1960s by Eric Trist and Fred Emery , who were working as consultants at the Tavistock Institute in London . Work design Work design or job design in organizational development is the application of socio-technical systems principles and techniques to the humanization of work. The aims of work design to improved job satisfaction, to improved through-put, to improved quality and to reduced employee problems, e.g., grievances, absenteeism. Job enrichment Job enrichment in organizational development, human resources management, and organizational behavior , is the process of giving the employee a wider and higher level scope of responsibilitiy with increased decision making authority. This is the opposite of job enlargement, which simply would not involve greater authority. Instead, it will only have an increased number of duties. [1] Job enlargement Job enlargement means increasing the scope of a job through extending the range of its job duties and responsibilities . This contradicts the principles of specialisation and the division of labour whereby work is divided into small units, each of which is performed repetitively by an individual worker. Some motivational theories suggest that the boredom and alienation caused by the division of labour can actually cause efficiency to fall. Job rotation Job rotation is an approach to management development, where an individual is moved through a schedule of assignments designed to give him or her a breadth of exposure to the entire operation. Job rotation is also practiced to allow qualified employees to gain more insights into the processes of a company and to increase job satisfaction through job variation. The term job rotation can also mean the scheduled exchange of persons in offices, especially in public offices, prior to the end of incumbency or the legislative period. This has been practiced by the German green party for some time but has been discontinued Motivation Motivation in psychology refers to the initiation, direction, intensity and persistence of behavior. [2] Motivation is a temporal and dynamic state that should not be confused with personality or emotion. Motivation is having the desire and willingness to do something. A motivated person can be reaching for a long-term goal such as becoming a professional writer or a more short-term goal like learning how to spell a particular word. Personality invariably refers to more or less permanent characteristics of an individual's state of being (e.g., shy,extrovert, conscientious. As opposed to motivation, emotion refers to temporal states that do not immediately link to behavior (e.g, anger, grief, happiness). Process improvement Process improvement in organizational development is a series of actions taken to identify, analyze and improve existing processes within an organization to meet new goals and objectives. These actions often follow a specific methodology or strategy to create successful results. Task analysis Task analysis is the analysis of how a task is accomplished, including a detailed description of both manual and mental activities, task and element durations, task frequency, task allocation, task complexity, environmental conditions, necessary clothing and equipment, and any other unique factors involved in or required for one or more people to perform a given task. This information can then be used for many purposes, such as personnel selection and training , tool or equipment design, procedure design (e.g., design of checklists or decision support systems ) and automation . Example An information system is a communication system using artefacts in support of a given human activity system. Hence, it could be considered as a classic example of a socio-technical system in that it bridges between a human activity system and an ICT system. An information system is fundamentally concerned with communication in support of human activity using artefacts to represent, store, manipulate and transmit data. The essence of an information system therefore lies not purely in the technology or in the activity: it lies in the way in which technology is used in support of purposeful action [3] .
- What is Human Performance Technology? Human Performance Technology (HPT) uses a wide range of interventions that are drawn from many other disciplines including, behavioral psychology, instructional systems design, organizational development, and human resources management. As such, it stresses a rigorous analysis of present and desired levels of performance, identifies the causes for the performance gap, offers a wide range of interventions with which to improve performance, guides the change management process, and evaluates the results. Taken one word at a time, a description of this performance improvement strategy emerges. Human: the individuals and groups that make up our organizations Performance: activities and measurable outcomes Technology: a systematic and systemic approach to solve practical problems Principles of Human Performance Technology Human Performance Technology (HPT) has been described as the systematic and systemic identification and removal of barriers to individual and organizational performance. As such, HPT is governed by a set of underlying principles that serve to differentiate it from other disciplines and to guide practitioners in its use. HPT focuses on outcomes. Focusing on outcomes, that is results, allows for questioning, confirming, and reconfirming that people share the same vision and goals, the job procedures support productivity, efficiency, and quality, and that people have the knowledge, skills, and motivation they require. Where is there an opportunity or a performance gap, a difference between the present and the desired levels of performance? Outcomes or results of an intervention will be measured to determine whether or not performance has improved. Sometimes it is necessary to challenge the assumed answer to a problem or the expected event or activity of an intervention and instead focus on the accomplishment or business need that is the client's true priority. To learn more how others have applied this principle, visit "GOT RESULTS?" . HPT takes a systems view. Taking a systems view is vital, because organizations are very complex systems that affect the performance of the individuals that work within them. It is important to distinguish a systems approach from a process model. A process contains inputs and outputs with feedback loops. A system implies an interconnected complex of functionally related components. The effectiveness of each unit depends on how it fits into the whole and the effectiveness of the whole depends on the way each unit functions. A systems approach considers the larger environment that impacts processes and other work. The environment includes inputs, but, more importantly, it includes pressures, expectations, constraints, and consequences. HPT adds value. This is an assessment that clients will be asked to make. Clients should be offered a process that will help them fully understand the implications of their choices, set appropriate measures, identify barriers and tradeoffs, and take control. While HPT requires a focus on intermediate goals (such as improving quality, customer retention, and cost reduction), its success is measured in improvements in desired business outcomes (such as sales, profitability, and market share). Alignment of individual performance to intermediate and business outcomes is critical to the HPT methodology. Measurement of results at both of these levels serves two important purposes, that of communicating the importance of what is being done while also assessing the amount of performance improvement. HPT establishes partnerships. Performance improvement professionals work in partnership with clients and other specialists. A collaborative effort involves relevant stakeholders in the decision-making process and involves working with specialists in their areas of expertise. Working collaboratively includes sharing decisions about goals, next steps to take in the process, and implementation strategies as shared responsibilities. Partnerships are created from listening closely to clients and colleagues, trusting and respecting each other's knowledge and expertise. Be systematic in the assessment of the need or opportunity. Analysis occurs in the beginning of the project. Needs or opportunity analysis is about examining the current situation at any level or levels (society, organizational, process, or work group) to identify the external and internal pressures affecting it. This process will determine the deficiencies or performance gaps that are to be remedied. The output is a statement describing the current state, the projected future state, and the rationale or business case for action or non-action. Be systematic in the analysis of the work and workplace to identify the cause or factors that limit performance. Cause analysis is about determining why a gap in performance or expectations exists. Some causes are obvious such as new hires lack the required skills to do the expected task. This step in the systematic process will determine what should be addressed to improve performance. The output is a statement of why performance is not happening or will not happen without some intervention. Job task analysis includes the identification of the important tasks that employees must perform and the knowledge, skills, and abilities to perform them. The output is performance objectives that describe the desired performance, delineate the conditions under which the performance is done, and identify the criteria for successful performance. Be systematic in the design of the solution or specification of the requirements of the solution. Design is about identifying the key attributes of a solution. The output is a communication that describes the features, attributes, and elements of a solution and the resources required to actualize it. Be systematic in the development of all or some of the solution and its elements. Development is about the creation of some or all of the elements of the solution. It can be done by an individual or a team. The output is a product, process, system, or technology. Examples include training, performance support tools, a new or re-engineered process, the redesign of a workspace, or a change in compensation or benefits. Be systematic in the implementation of the solution. Implementation is about deploying the solution and managing the change required to sustain it. The outputs are changes in or adoption of the behaviors that are believed to produce the anticipated results or benefits. This standard is about helping clients adopt new behaviors or use new or different tools. Be systematic in the evaluation of the process and the results. Evaluation is about measuring the efficiency and effectiveness of what was done, how it was done, and the degree to which the solution produced the desired results so that the cost incurred and the benefits gained can be compared. This standard is about identifying and acting on opportunities throughout the systematic process to identify measures and capture data that will help identify needs, adoption, and results.
- Overview The Design & Engineering Methodology for Organizations (DEMO) is a methodology used to describe business processes and was developed by J.L.G. Dietz. The DEMO methodology is used to model organizations from a responsibility and communication oriented perspective. More information about the methodology can be found on the website: http://www.demo.nl Theoretical foundation The basis of the theory behind DEMO is the framework below. The "world" is broken down into business processes. These in turn can be broken down to actors and interaction. The actors and interactions can be further broken down to coordination acts and action rules. An actor is the basic unit of responsibility. An actor is the responsibility, knowledge and authorization to perform a single type of act, for instance 'bake a pizza' in the case of a pizzeria. Actors are units of responsibility. They can be fulfilled by subjects - A.K.A. people. A subject can perform the role of more than one actor, and more than one subject can perform the role of the same actor. Interaction is the communication that is performed between actors to allow them to perform their tasks. For instance, the 'bake a pizza' actor might have to communicate with the 'supply ingredients' actor to get the required ingredients to bake a pizza. Coordination acts are the basic acts that allow actors to coordinate their work; that is, to interact with other actors and to perform their tasks. More on this later. Action rules are rules that define how an actor responds to interaction and what interaction an actor initiates in response. Acts and facts An organization is made up of subjects performing acts. These acts fall into two categories: C-acts (coordination acts): these acts bring about commitments between subjects; P-acts (production acts): these acts produce things in the world (these things do not have to be material). Coordination acts are usually performed by executing communicative acts, in other words, subjects communicate with each other to coordinate their actions. By definition, the communicative act is the communication between two subjects about a certain proposition . One subject (the performer) initiates the act. The performer informs the other subject (the addressee) about the intention and proposition of the communication. The proposition is the fact about which the two communicate and the timeframe concerning that fact. For instance, one subject wants another subject to 'bake a pizza in the next half hour'. The intention determines what the performer wants to communicate concerning the proposition. For instance, the performer wants to promise that he will 'bake a pizza in the next half hour'. To give a complete example of a communicative act: if a customer orders a pizza from a pizzeria, he makes a request to the pizzeria for a pizza P to be provided to him in half an hour . For this act: "He" is the performer; "The pizzeria" is the addressee; "Request" is the intention; "Providing a pizza P" is the fact; "In half an hour" is the time window; After a communicative act has been performed a communicative fact has been created (in the example "Providing pizza P in half an hour has been requested"). This fact, in correspondence to the C-act, is a C-fact. Corresponding to this, the Result of a P-act (Production) is a P-fact. P-facts can be anything, ranging from "Pizza P has been provided" to "Paper P has been graded". The nature of these acts differs from the communicative acts. A production act creates something in the world, a production fact, where a communicative act concerns only the communication about this production fact. The responsibility to perform one (and only one) type of P-fact is what we call an actor . In the discussion so far, I have spoken of subjects performing acts; actors perform act types . More than one subject/person could bake a pizza, but there is only a single 'bake pizza' actor. An actor does not simply perform its P-act over and over again. An actor will only perform a P-act (for example providing a pizza) if another actor requests the actor to do this. In other words, an actor only performs a P-act in response to a series of C-acts (see the next paragraph). An actor's job boils down to the following cycle: Once a certain performer completes a C-act, a C-fact is created, which forms a part of the cycle of the other subject of that act. This cycle handles a C-fact and creates a new one (or even more than one), which makes it the motor of the whole process. Which acts the actor can choose from and which should be chosen, is determined by the action rule related to the intention and/or proposition of the C-fact the actor is performing. Actors and transactions Now, we'll have a look at sequences of C-acts, C-facts, P-acts, and P-facts. Such a sequence constitutes a transaction . In other words, a transaction is a chain of acts and facts with the purpose of having an actor perform one production act. In the order phase one actor (the customer) places an order with another actor (the producer) for the creation of a P-fact. In the production phase the producing actor performs the P-act. In the result phase the two actors try to agree whether or not the P-act was completed correctly. Sometimes the conversation will not be successful at first, or it will fail completely. This has been incorporated by a discourse layer and a failure layer. Using a PSD, or Process Step Diagram (a special type of Petri-net), all possible sequences of acts of a transaction can be shown. When the facts produced in a transaction are documented, they are stored in a so called information bank. Conceptually, every transaction has a communication bank where its C-facts are stored and a production bank where its P-facts are stored. When actors need P-facts or C-facts as information (see the actor cycle), they inspect the contents of these information banks. Organizations (systems) A system / organization consists of a number of actors. The transactions that these actors can perform form a business process. A business process is defined as a composition of connected transactions. The transactions link the various actors together, just as molecules are connected to form matter. The entire "DEMO universe" is a vast lattice of actors interconnected by transactions. When we model a single organization, we only focus on those transactions and actors of the world that are related to that organization: the business process. When creating a DEMO model, the first thing to do is determine what (part of an)organization you wish to model. Whatever is chosen, there are always various layers in the business process. In DEMO a separation into three layers of interest is made: essential, informational and documental. To explain these layers, I will use the following example: Person A walks to the counter in a library and requests to become a member. Employee B behind the counter might ask the person his name and some other information. When employee B has the required information, he or she goes to the back and asks employee C to make a new library card. Then that card is given to new member A. This example involves three transactions: Becoming a library member, initiated by person A; Getting personal information, initiated by person B; Making a library card, initiated by person B. The first transaction results in a production fact in the object world. The second transaction results only in the exchange of information. The third transaction only concerns the documentation of information that is already available. But, all the above exchanges are transactions: there is a request, a promise, a production act, a statement, and an acceptance. The difference is in the nature of the production act and fact. This difference is expressed by distinguishing three kinds of transactions: Essential transactions; Informational transactions; Documental transactions. The corresponding actors that are producers of these transactions are also called essential, informational, and documental actors. Combined, these actors and interactions form the essential, informational and documental layers of an organization; the B-system (Business system), I-system (Informational system), and D-system (Documental system) . These three systems are hierarchical, meaning the B-system is supported by the I-system and the I-system is supported by the D-system. DEMO Diagrams The DEMO methodology consists of various diagrams and tables that can be used to visualize the model of an organization. Keep in mind, though, that all these diagrams represent aspects of a single model. There are five diagrams, three tables and a specification language defined in the DEMO methodology: Name abbreviation Actor-Transaction Diagram ATD Actor-Transaction Table ATT Process Phase Diagram PPD Process Step Diagram PSD Object Property Table ARS Object Fact Diagram OFD Actor-Bank Diagram ABD Actor-Bank Table ABT Action Rule Specification ARS Of all these, I will only explain the Actor-Transaction diagram, Process Phase diagram, Process Step Diagram and the Object Fact Diagram. The other diagrams, tables and the specification are very interesting and relevant, but they are also used for very detailed descriptions. The diagrams mentioned above are more than sufficient. Perhaps I'll get around to a description of the full set at some point. To explain the diagrams I'll use the following example of a (fictional) pizzeria: Mia and Marco own a pizzeria. When a customer comes to the counter he or she gives his order for a pizza to Mia. Mia then passes a white and pink written order forms to the kitchen. Marco starts baking the pizza. When he's done, he passes the pizza along with the pink form back to the counter. After the customer has paid for his or her pizza, Mia hands the customer the pizza. Actor-Transaction diagram The actor-transaction diagram is used to show the various actors of a system and the transaction between these actors. This leads to the following set of entities in the actor-transaction diagram: The Aggregate actor and system entities are used to group actors together. The aggregate actor and system entities are equivalent in that they both contain an aggregation of actors and the interactions between them. The difference is that the internal structure of the system is known, where the internal structure of the aggregate actor is not (white-box versus black-box). The inspect line is used to show that an actor inspects the contents of the information bank of the transaction. This is called interstriction. It is used to display which information an actor uses during its transaction. The example yields the following actor-transaction diagram: Process phase diagram The process phase diagram is one of two diagrams used to visualize the process model. The process phase model shows the conversations (phases) of the transactions, and how these are related. The diagram has the following elements: The process line shows which process is initiated during which other process. The wait condition shows which process has to wait for which other process to finish. For the example, the following diagram emerges: The execution of the providing of a pizza (T1), can only be completed (i.e. stated to the customer) if the pizza has been baked (T2). And the providing of the pizza can only be completed when the pizza has been paid (T3). Process step diagram The process step diagram is the other diagram used to visualize the process model. Here we zoom in a little further and show the individual acts and facts of a transaction or proaction. It is possible to show the relationship between individual acts and facts. The process step diagram contains the following elements: As an example, take a look at the process step diagram in the 'actors and transactions' section above. Object fact diagram The fact diagram is a variation of an ORM diagram . It is used to visualize the fact model. The fact diagram relates various objects by relations. I will not rehash an explanation of this type of diagram here. In DEMO the ORM information model is linked to the various transactions in the system. when a transaction is finished, the result is the creation of a new instance of a fact. This simple rule allows a modeler to tie the static information model to a dynamic organization model. Below is the Fact diagram for the pizzeria example.
- Example RAD Diagram Role Activity Theory originated through the study of co-ordination by Anatol Holt and others in the early 1980's and taken up by the UK government-sponsored IPSE2.5 project during the period 1985-89. The focus was on processes that involve the co-ordination of inter-related activities carried out by people in organisations. Although intuitively simple and easy to read, Role Activity Diagrams providing a powerful modelling technique that uses a number of notational primitives to express very complex process behavior. RADs have proved an extremely useful as a tool in the discovery, discussion and agreement of how people work together. The RAD notation is easily understood by business people who can describe their work in a very intuitive and natural way. Their usefulness in ensuring a clear and common understanding about work is true whether they have been captured using a white board, pen and paper, a drawing tool or our own modelling products. Over the last twenty years RADs have been further developed and activively promoted by Martyn Ould through his workshops and two of his process management books: "Business Processes: Modelling and Analysis for Re-engineering and Improvement" published in 1995 His most recent book "Business Process Management: A Rigorous Approach" published in 2005 provides what is regarded as the reference notation for RADs. We work closely with Martyn Ould on the need for any changes, extensions or refinements to the RAD notation.