User-Centric Perspective UCP Working Group Our approach to this - - PowerPoint PPT Presentation

User-Centric Perspective

UCP Working Group

Our approach to this theme

• We started by defining concepts and terms we thought were

relevant

• We told stories/use cases of user-centric process models

“in the wild” as well as counterexamples (we found way more counterexamples)

• We found many links to the purpose of modeling
• We shared our assessment of the literature to date and

which gaps exist

• We developed questions that we think are worth asking in

research

What we know

• The process of modeling
• The roles involved in

modeling

• Many variables about

“the user” and “the model” (e.g., characteristics of the modeler)

Examples discussed of user-centric process modeling “in the wild”

• The checklists always used in aviation
• The evacuation procedures that are never meant to be used
• Cooks that use or do not use recipes
• Process modeling can be a way of knowledge management. It

may not require a completely consistent repository but it is simply a way to explicate tacit knowledge

• Often the value for users stems from the act of creating

the model (ie the process of process modeling) more so than from the artefact (ie the model)

What we don’t know

What we don’t know

• What is user-centric process

modeling? What is it not?

• What is the role of the user

in user-centric modelling?

• Are there differences

between models for user groups vs. individuals?

• What are relevant constructs

for UPC?

• How do we observe and

measure the constructs? Which of these have we not measured at all so far?

• What can we learn from how
• ther fields regarding

constructs and measuring?

Questions we think are worth asking in BPM research

• What would user-centric process modeling mean? What makes a

process model user-centric? Do we actually need to make modeling user-centric? Do we need to involve users in modeling? Should we let the users model?

• Is the model the interface between the actual process and the

user? Do we need this interface always and for all users? Can we create better ones?

• What can we learn about process models from the ways that users

appropriate “process model-like” artefacts such as checklists, recipes, manuals etc?

• What happens when we don’t look at individual users but instead

at collectives (groups, organizations, units, etc.)

Questions about Research Conduct

• What are the relevant constructs (comprehension, shared

understanding, performance, engagement, utility, consensus, effort, purpose, value, etc.)

• How do we observe and measure them (interviews, questionnaires,

model analysis, etc.)? Which of these have we not measured at all so far? How to link these constructs with the purpose of a model for a stakeholder?

• What can we learn from how other fields measure these or similar

constructs?

• Which advances in methodologies could we utilize better?
• Which recommendations/prescriptions/design theories can we

derive from this?

Suggestions for the BPM research community

• We suggest to develop a set of recommendations for BPM research

conduct and reporting, such as ○ Always identify and name the users or user groups in focus ○ Delineate the specific purpose of a model ○ Identify the relevant variables of interest ○ Clarify whether a study is about the model, about the process being modeled or about the process of modeling itself ○ Separate process design from process modeling

Suggestions ctd.

• We suggest to encourage modes of research that assist an

understanding of “the user” (and in particular “groups” thereof), such as

○ Ethnography / descriptive field studies ○ Inductive field studies ○ Qualitative research ○ Development of measurement scales for use in a BPM context

• Convince a BPM-friendly journal to publish a special issue
• n user-centric BPM

Backup: for our continued discussion

Evolution of Emergent Processes

• Magic: Someone figures out how to do something, it is

intransparent to outsiders - there is an unknown model

• Heuristic: Over time, rules/constraints/sequences emerge

that achieve the outcome in a more consistent/predictable fashion - the model is a rough approximation

• Algorithm: The process can be described in a formal

fashion, and repeated even by those unfamiliar with the domain - the model is detailed and precise The user community changes alongside this evolution

Personal processes without models (but modeling?)

Examples for existing research on user-centric process modeling

Tangible BPM initiative (e.g., HPI & Stanford) Collaborative process modeling tools (e.g., Peter Rittgen, QUT, SAP) Human factors in BPM (e.g., HC-PAIS, work by Kathrin Figl) Work on process model reuse (WU Vienna, QUT and others) User-characteristics: creativity, experience, knowledge, cognitive load, learning style, cognitive effectiveness, expertise, self-efficacy, attitude, task preferences

The Formal Modeling Process

• Gather: Obtain information necessary to create a model

○ Through interviews/questionnaires (asking SMEs to express themselves) ○ Through observation (human or mechanical) ○ Through reconstruction (mining)

• Construct: Create the model

○ Note: Sometimes this is the “use” of the model - create consensus

• Use: Apply the model

○ Note: Some models are created, but not enacted (example: evac plans)

• Assess: Evaluate the utility of the model

○ Question: What are good measures for utility?

The Roles

• Modeler

○ Expert modelers versus domain experts vs. end users

• Engineer

○ Is the engineer the same as the modeler?

• User

○ ‘clerical’ workers (manipulate data according to fix rules of the

• rganisation, no addition of knowledge or insight - transactions)

○ ‘knowledge’ workers (create new relationships, concepts, ideas, and logical arguments - judgment, problem solving, new strategy) ○ direct users (interact w/ model or system derived from model) ○ indirect users (obtain benefit from direct users’ model use)

• Organization