Process Modeling

Int. J. Process Management and Benchmarking, Vol. 3, No. 1, 2009 47

Elicitation techniques to overcome knowledge
extraction challenges in ‘as-is’ process modelling:
perspectives and practices

Soumya Suvra Bhaumik*
Cognizant Technology Solutions,
300 SW 24th Street,
Bentonville, Arkansas 72712, USA
E-mail: soumya.bhaumik@cognizant.com
*Corresponding author

Ramachandran Rajagopalan
Cognizant Technology Solutions,
1, Veeranam Road, Perungudi Bye Pass,
Chennai 600096, Tamil Nadu, India
E-mail: ramachandran.rajagopalan@cognizant.com

Abstract: Building an as-is process model requires the analyst to effectively
extract knowledge about the process from multiple sources. This paper
elaborates on the various elicitation techniques, including questionnaires,
interviews, workshops and role play, which may be employed to achieve this.
The paper looks at existing academic literature on requirements elicitation
techniques, leverages concepts from social science and combines these with the
authors’ own understanding of the techniques’ applicability, gained from
experiences in process modelling engagements. We conclude that process
knowledge elicitation is not a cookie-cutter process. Different elicitation
techniques need to be used depending on the context. The paper provides some
guidelines on how to successfully apply these techniques and also highlights
their potential pitfalls.

Keywords: process modelling; process knowledge; elicitation technique;
contextual interview; workshop; process management; benchmarking.

Reference to this paper should be made as follows: Bhaumik, S.S. and
Rajagopalan, R. (2009) ‘Elicitation techniques to overcome knowledge
extraction challenges in ‘as-is’ process modelling: perspectives and practices’,
Int. J. Process Management and Benchmarking, Vol. 3, No. 1, pp.47–59.

Biographical notes: Soumya Suvra Bhaumik is a supply chain management
and systems consultant at Cognizant Technology Solutions. He has worked in
the areas of requirements management and process modelling for retail,
logistics and distribution clients across Asia, Europe and North America.
His research on the Indian software services industry have been published in
conference proceedings at 2002 International Conference on Marketing of
Technology Oriented Products and Services in the Global Environment,
Bangalore and Spring 2003 Marketing Management Association Conference,
Chicago. He received his BE from Jadavpur University and his MBA from
Indian Institute of Management Calcutta. He is based in Bentonville, USA.

Copyright © 2009 Inderscience Enterprises Ltd.

48 S.S. Bhaumik and R. Rajagopalan

Ramachandran Rajagopalan is a Deputy General Manager – Business Solutions
with Cognizant Technology Solutions. He has been a process consultant for a
number of projects with major manufacturing, pharmaceutical and logistics
organisations. Currently, he focuses on design and improvement of outsourced
business processes for Cognizant’s clients in the retail domain. He has a BTech
from the Indian Institute of Technology, Chennai, a MS in Industrial
Engineering from Texas A&M University and a MBA from the Indian School
of Business, Hyderabad. He is based in Chennai, India.

1 The need for ‘as-is’ process mapping

Business Process Reengineering (BPR) can be defined as the analysis and design of
workflow and processes within and between organisations (Hammer and Champy, 1993).
It offers a systematic means of understanding and improving how organisations function
in terms of business processes. Business processes are any logically related tasks that use
the organisation’s resources to provide defined results in support of the organisation’s
business objectives (Harrington, 1991).
The initial phase of a BPR initiative involves defining the business domain to be
re-engineered and identifying the ‘as-is’ activities within that domain. This identification
must be followed by creation and elaboration of the workflow model by creating ‘as-is’
process maps which are diagrammatic representations of the processes being examined.
These process maps define the process boundaries, current work practices, alternate flows
and exceptions, the process owners/holders/clients, supporting systems, triggers that start
activities, outcomes – successful or otherwise – of activity completions, task volumes,
efforts, durations and resource capabilities. The ‘as-is’ process mapping exercise provides
the participants involved in BPR with a common understanding of work. It also
establishes a fact-based baseline for current process performance and creates a basis
for formulation of future scenarios (Carr and Johansson, 1995). A clear understanding of
these processes can be used to generate requirements for potential Information
Technology (IT) solutions that are increasingly seen as drivers of improved business
processes.

2 Challenges in eliciting ‘as-is’ process knowledge

Increasingly, business processes are becoming a complex mosaic of interactions.
These interactions could be between humans or, more often than not, involve a
combination of software applications and humans – the application performing tasks
triggered by a human/system input and providing decision support through a user
interface. Communications take place between software systems that are often based on
disparate technologies and between people/systems that belong to different departments
or even different organisations. A major challenge in documenting ‘as-is’ business
processes is, therefore, collecting individually held tacit and explicit knowledge about the
process from multiple sources and integrating that into a set of maps that describe the
process to a level of detail that serves our purpose of analysis. Several factors compound
the elicitation problem. Some of these are:

Elicitation techniques to overcome knowledge extraction challenges 49

• Process stakeholders may have incomplete understanding of the process. They may
make assumptions about the parts they do not know but forget to state those
assumptions to the analyst.
• The analyst may have poor understanding of the business domain and cannot
construct directed questions for the stakeholder.
• The analyst and the process stakeholders may not have a common vocabulary.
This may lead to misinterpretation of key facts.
• The process stakeholder may omit information (particularly, domain-specific rules or
work done routinely) thinking it to be “too obvious to state”.
• The process stakeholder may provide ambiguous responses (for example,
“it takes a lot of time”).
• The analyst may not gather information from all sources. Information gathered from
only one group, or only one level, is likely to be biased by the level of abstraction
at which those people think of the process, their roles in the process, level of
knowledge about related applications and processes, personal preconceptions and
goals.
• The analyst selects an elicitation technique based on her experience or expertise of it.
This technique may not be the most appropriate for the situation.

3 Objective of the paper

Our purpose in this paper is to discuss a set of elicitation techniques that can be used for
extracting knowledge of a process primarily from process stakeholders who participate in
the process. We provide a discussion on a set of process knowledge elicitation
techniques, including introspection, interviews, workshops and role play. In doing this,
we draw from the diverse fields of software requirements engineering, knowledge
acquisition for expert systems and social sciences. The criticality of social context in an
elicitation process necessitates using social science concepts and we have attempted to
cite the relevant academic literature in this field where applicable. Since process
knowledge elicitation is not a cookie-cutter process, different elicitation techniques
need to be used depending on the context. Based on the authors’ understanding
of the techniques’ applicability gained from experiences in process modelling
engagements, the paper provides some guidelines on how to successfully apply these
techniques and also highlights their potential pitfalls. The result is a summary
of elicitation techniques that can help process analysts select the appropriate elicitation
technique(s), depending on the particular environment of the engagement. As research in
this area continues, we hope that in the future we may have a better understanding of how
improvements can be made on these elicitation techniques to fulfil the objectives of
‘as-is’ process modelling.


4 Elicitation techniques

4.1 Introspection
Introspection (Goguen and Linde, 1993) is the most obvious method for trying to
understand a process. It amounts to imagining what tasks are being carried out and how
they are supported by systems and people to achieve a certain process objective.
We suggest the use of introspection only when:
• the analyst has sufficient familiarity with the business domain being studied possibly
by virtue of their previous experience
• the analyst has access to sufficient documented knowledge of the processes being
investigated.
The existing documented knowledge may be in the form of policies and procedures
documents (for example, for an order-to-cash cycle, this could mean the business rules
applicable for buyer credit limit), organisation charts (for example, how the marketing,
contact centre, and post-sales services are structured), training material (for example,
training programmes for newly inducted field sales staff), task artefacts (for example,
invoices raised), Management Information System (MIS) reports generated, application
manuals (for example, Data Flow Diagrams created as part of application development in
the past) and even application screenshots and application code. A minimum level of
interaction with process stakeholders is required for the analyst to study these
documented sources of knowledge, combine them with their own idea of the process,
introspect and come out with a basic model of the process. The authors have benefited by
using this technique at the start of all process modelling engagements to come up with a
‘straw man’ like process model that can be used as a starting point for discussions with
process stakeholders. The benefit of this exercise, while being carefully conscious of its
limitations, is that it provides some direction to the analyst for a more efficient,
meaningful conversation with process stakeholders in the future. We must hasten to add
that there is a very high possibility that this technique, used in isolation, will fail to reflect
the experience of actual process stakeholders and, hence, should be used judiciously.

4.2 Questionnaire interviews
Questionnaires are typically used to gather data from a large user population.
Accurate phrasing of the questions is very important in this technique. The nature of the
expected responses should be defined in advance for interpretation of the responses,
be it preferences, facts, beliefs, feelings or descriptions of past behaviour. However, the
method is not always able to replace stakeholder interviews and may suffer from
problems of inaccuracy and low response rates. Pre-supposition of certain facts
by the interviewer and multiple interpretations of the meaning of, both, questions
and answers are possible (Suchman and Jordan, 1990). In a normal interaction,
the ambiguity of interpretation can be negotiated real-time between the participants.
But, in a questionnaire, such negotiation is absent, leading to incomplete and, perhaps,
incorrect understanding for both the subject and the interviewer. The authors have,
however, found some very interesting applications of the questionnaire technique
in process reengineering exercises. One is in prioritising processes following the


high impact approach. When attempting to prioritise among many possible process
candidates for reengineering, process stakeholders were sent questionnaires to
identify process dysfunction (which processes are functioning the worst) and
importance (which processes are the most critical in terms of customer satisfaction).
These perception responses were then interpreted using a decision analysis framework
(in this case, Kepner-Tregoe) to determine core areas of improvement, identify the
quick-win candidates and evaluate the sequence of capability rollout.

4.3 Interviews
In both requirements analysis and knowledge acquisition, the interview continues to be
the most favoured elicitation technique (Alvarez, 2002). In trying to understand a
process, there is no substitute to interviewing process stakeholders and learning from
them in person the tasks they perform to fulfil the process objectives. There are two types
of interviews: closed interviews, where a pre-defined set of questions are asked and open
interviews, where there is no pre-defined agenda and a range of issues are explored with
stakeholders (Sommerville, 2006). Closed interviews, while providing the benefit
of focus and efficiency, run the risk of limiting the interviewee’s natural expression.
The analyst may miss out on issues that are relevant to her study but were not mentioned
because of her insistence on ‘following the script’. We propose the middle path – having
a pre-defined agenda of what needs to be achieved in the interview and a repository
of potential questions that the analyst seeks answers to but at the same
time allowing the subjects flexibility in answering the questions however they want to.
The interviewer may probe deeper, clarify doubts or seek more relevant details.
In this way, many of the inadequacies associated with the questionnaire technique can be
avoided (Goguen and Linde, 1993).
Browne and Rogich (2001) propose a classification of prompting techniques needed
for Information Systems (IS) requirements elicitation. Adapting their ideas to suit the
needs of effective question formulation for as-is process mapping, we may define two
sets of questions – domain-independent questions and domain-dependent questions.
The domain-independent questions, as the name suggests, are independent of the business
domain context and are exportable across projects in different business domains. Such a
framework can be very helpful in constructing questions that help us understand the
process characteristics when the analyst has limited prior exposure to the business
process area she is studying. These are, however, less effective than domain-dependent
questions that can be more relevant and focused on the particular process that is being
modelled. A significant level of business domain expertise is required to construct
domain-dependent questions and one may need to create different sets of such questions
for different projects. An interesting future research direction may be to build a repository
of domain-independent questions for process knowledge elicitation and then involve
Subject Matter Experts to supplement these questions with domain understanding and
expand the questions repository. Some of the strategies used for eliciting knowledge from
interviewees include (Browne and Rogich, 2001):
• scenario building: ask the process stakeholder to construct a business scenario and
explain his actions in that scenario
• applying conditions: use ‘if-then’ clauses to encourage the process stakeholder to
come up with alternate and exception flows in a process


• elaborating with instances: ask the process stakeholder to illustrate a task by
providing examples
• hedging: ask the process stakeholder to design contingency plans or alternatives
when exceptions occur in a process
• generating counterarguments: help the process stakeholder question his assumptions
or beliefs about any process element
• summarising: provide the process stakeholder with a summary of what the analyst
has understood, thereby minimising potential misinterpretation.
Sometimes, interviews may fail to produce the desired value in terms of accurate and
complete process knowledge extracted. Some of these risks and possible mitigations are:
• Interaction conflict. In an empirical study, Alvarez (2002) uses Critical Discourse
Analysis to examine the narratives that emerge during interviews. A discourse unit is
the linguistic unit directly above the sentence. The discourse unit of interest here is
the oral narrative of personal experience. If a speaker has negotiated permission to
produce a discourse unit, such as a story, a second speaker may not change the
discourse unit and topic in progress until the unit is recognised as completed.
Questions and appreciations may, however, be offered during such a discourse by the
second speaker (Goguen and Linde, 1993). Most interviewees in the Alvarez (2002)
study followed a storytelling frame, while the analysts mostly resisted and reframed
the interaction. For the analyst, the encounter is a ‘professional’ encounter and he
looks for brevity and directness. For the interviewee, it is about personal work
experiences and dilemmas that they express through storytelling. The author
indicates that the storytelling frame would definitely evoke a “more involved and
animated person” willing to “share subjective interpretations” of what he believes
constitutes expertise.
• Inconsistencies in interpretation. Typically, interview data get collected from
different communities participating in the process. The analyst must integrate these
different interpretations, goals, objectives, communication styles and use of
terminology into a single set of maps that represent the process. This integration is a
difficult task unless the interviews are structured in some way (Christel and Kang,
1992). The use of a glossary of domain-specific terms (both business as well as
system) may reduce the number of inconsistencies in interviews that subsequently
have to be resolved by the analyst.
• ‘Say-do’ problem. Goguen and Linde (1993) argue that, at times, interviews may hit
a roadblock because people know how to do many things that they cannot describe.
They also provide a classic example of a question from social studies that generates
such linguistic incompetence – “how do you tie your shoelaces?” (Goguen and
Linde, 1993). The analyst should appreciate the limitations of the traditional
interviewing technique in this regard and explore the possibility of alternate
techniques that are described later.


4.4 Protocol analysis
Having the interviewee vocalise his thoughts, as he works, explaining what he is doing,
may seem to help the interviewee express his process knowledge in an easier fashion.
In Protocol Analysis (Goguen and Linde, 1993) or the ‘think-aloud’ technique, a subject
is asked to engage in some task and concurrently talk aloud, explaining his thought
process. Protocol analysis is also used to reflect on problem solving, or some other task,
retrospectively; that is, after it has been accomplished. However, Goguen and Linde
(1993) argue that protocols are an ‘unnatural discourse form’ and are “not a reliable guide
to what subjects are thinking”. We feel that a variant of the method may be used
somewhat effectively only in conjunction with interrupting ‘what-if’ questions
(for example, “What if the data doesn’t match?”, “What if you do not have that
information?”). This way, the interviewee can be encouraged to think of the exceptions to
the typical work process and explore descriptions of alternate flows to his work.
The sequence of cognitive events that occur between the introduction of information
stimuli and the decision outcome can be recorded and transformed into a business
process flow.

4.5 Contextual interviews
The problem arising out of a process holder’s inability to articulate certain aspects of the
process flow may find some answers in ethnography. Understood as a naturalistic
approach, ethnography is concerned with seeing the social world from the point of view
of participants before standing back to make a more objective assessment (Fielding,
1994). As the name suggests, the approach can be used to produce a detailed account of
what it is that people do, and how, in particular settings (such as the workplace,
for example). This social science method can be incorporated in process knowledge
elicitation and can be very ‘authentic’ in understanding workplace practices because it is
drawn from the first-hand experience of a field worker rather than interviews conducted
away from the workplace in a conference room.
The technique (or variations of it) is known as contextual interviews, contextual
inquiries, participant observation, and apprenticing. Participant observation is a method
in which the observer attempts to become part of the community of interest,
by developing a legitimate role within that community (Goguen and Linde, 1993).
Beyer and Holtzblatt (1998) also call this apprenticing. The apprentice observes what the
master craftsman does, asks questions and then tries to learn the task by doing it. Due to
constraints of time, in a contextual interview (as opposed to apprenticing), the analyst
does not do the work but simply tries to observe and learn about it. So, contextual inquiry
is apprenticeship compressed in time (Beyer and Holtzblatt, 1998).
In a contextual interview, the analyst alternates between watching and probing
as the process holder performs her tasks. The analyst does not usually impose tasks or
scenarios on the process holder, but frequently requests for task artefacts to provide
context and also asks questions and seeks clarifications to gain greater understanding of
what the process holder is doing and thinking. The result is a much richer explanation
of the process. We find contextual interviews to be the most useful of all techniques
when the need is to learn details of each step in the process from an individual subject.
In the study of customer contact centre processes for a logistics company, we had
conducted multiple preliminary open ended interviews before starting with contextual


interview sessions with the same set of process holders. Several process facts of
importance were revealed during the course of these contextual interviews that were
missed out during the more traditional conference room style interviews. These facts
included key steps in the process that the process stakeholder had assumed were too
mundane to discuss, decisions that were taken based on established norms rather than
documented policies, and deviations from the application user interface flow because the
user had discovered a more efficient way of using the system in the past.

4.6 Workshops
Joint Application Development (JAD) is a powerful elicitation method that brings
analysts, developers, and customer representatives together in a facilitated workshop
(Wiegers, 2001). JAD is used in the IS development context, but its principle of
close collaboration between multiple stakeholders can be applied for eliciting
knowledge of as-is processes. A facilitated workshop aims to gather a set of process
stakeholders – who, collectively, have the right mix of skills and knowledge to participate
in a stimulated discussion about the process – for a short but intensely focused period.
Parallel activities may be conducted at times. Sub-groups can work on different aspects
of the problem and reconvene in a plenary activity to share and examine the output
(Gottesdiener, 2002).
The composition of the workshop team is of paramount importance. The right people
have to be involved, and the presence of a skilled facilitator can keep the session focused
and can minimise unproductive emotional attacks and defences (Christel and Kang,
1992). Having all or most stakeholders working on a focused topic in the physical
proximity of one room for a defined period of time serves many purposes. It overcomes
slow communication and promotes immediate feedback. Conflicting responses from
stakeholders get spotted and are immediately resolved. Where processes cut across the
bounds of organisational units, workshops can help remove ‘Murphy blinds’ that afflict
process stakeholders present at the session and encourage them to have a shared
ownership of the process. At a large multi-format retailer with operations across
countries, we conducted workshops to understand the disparate warehouse processes
in different business units and come up with an improved global process model.
This brought process holders, including logistics directors, operations managers,
warehouse administrators and application technologists from multiple markets together in
a room to discuss the ‘as-is’ processes: what works, what does not and what best
practices from one market can be adapted to another market. What followed were weeks
of intense and extremely productive workshop sessions where participants discussed
ideas and experiences, learnt from each other, determined priorities, developed a sense of
shared ownership for the business vision and came up with a global process model that
reflected all of the business units’ needs. To achieve the same results through any other
means would have been a much longer and drawn out process – possibly with many
review cycles and disagreements on the way.
However, one must remember that there is a cost associated with bringing too many
stakeholders into one room for one day. So, the analyst needs to be clear about the
business case of the value to be derived from that exercise. Also, it is very important to
identify a workshop sponsor in advance, otherwise it is unlikely to have the necessary
commitment to ensure that the right players participate and prepare for a successful
session (Gottesdiener, 2002). Because participants may have widely different status


within the organisation, there is a danger that some will not feel free to say what they
really think (Goguen and Linde, 1993). Asymmetry in values, information, concerns and
assumptions among participants may mean that the technique will fail if subjects are
asked to discuss topics that they do not wish to talk about or that which may be
conflicting with others’ ideas. The facilitator must be sensitive to these organisational
dynamics and work within such constraints to extract the maximum possible knowledge
out of this group. In fact, the criticality of the role of facilitators and their experience in
managing group processes in a workshop cannot be overstated. They should explain
the goals and agenda of the meeting and lay out the ‘rules’ at the outset of the meeting.
They must step in, where required, and enforce the rules to help keep the meeting on
track. They have to strike the fine balance between facilitating a process of decision and
consensus-making and, at the same time, avoid participating in the content. To get the
best out of the workshop, all stakeholders must participate and have their inputs heard.
To ensure this, the facilitator must implement appropriate turn-taking. Turn-taking
implies that there should only be one speaker at a time, with no gaps or overlaps.
The turn-transition may be triggered by a socially determined noticeably long pause or
the selection of another speaker verbally or through gesture by the previous speaker or
the facilitator, or self-selection as the next speaker (Goguen and Linde, 1993). A good
facilitator should be able to facilitate turn-taking by participants at appropriate discussion
points without giving the impression of being imposing.
The facilitator may have a scribe with them to assist in notes-taking. Aids to the
recording and display of information and ideas may be through whiteboards, post-it notes
and flip charts for example. The scribe may even use a mind mapping tool on a computer
and project it for everyone to see. The mind map can be an excellent tool to represent and
expand on ideas, tasks or other items linked to and arranged around the central theme of
the workshop. With a mind map, the scribe can use words, colours, symbols to capture
and structure discussion points in an easily understandable manner.

4.7 Role playing
Role-playing exercises are used extensively in interactive teaching methods. These are
also used in IS requirements elicitation and can be extended to elicit process knowledge.
At times, the analyst may not get access to all the process stakeholders due to various
reasons. In such cases, the analyst may try to meet with several surrogate representatives,
and use role-playing techniques to enact the stakeholder workflow. The exercise
encourages the role-player to reflect on his beliefs and knowledge about how another
person in the workflow will react in a given situation. The success of the technique rests
on the assumption that the role-player is sufficiently aware of the work practices of the
stakeholder whose role is being played. We have met with some success when we applied
this technique to understand sales and customer support processes at an electronics
component distribution company. We did not have access to real clients of the
organisation. So, the next best thing was to request one of the salespersons to assume
the role of a customer and have him enact different customer interaction scenarios with
another sales person who played himself.


5 Discussion

In this paper, we have looked at a set of elicitation techniques that may be applied
to understand an ‘as-is’ process. In this, we have borrowed from concepts from
requirements engineering and social sciences. Although many academic publications
have explored the applicability of social sciences in IS requirements elicitation, most
real-world IS projects have restricted themselves to using only classical experimental
psychology (for example, the use of red as a display colour for something requiring the
user’s attention). We believe that the elicitation of process knowledge from process
stakeholders is an exercise in motivated social interaction and the use of social science
concepts can have an extremely positive impact on the process of motivating and coaxing
information out of people. Analysts can benefit from learning some of these concepts
outlined in this paper.
A large part of the comparisons drawn between the different elicitation techniques
and conclusions that have been presented in this paper is based on our own practitioner
experience of creating large process models for Fortune 1000 companies in the supply
chain domain. In our experience, most analysts base their decision of using a particular
elicitation technique on whether they had success in their previous use of the technique.
However, that technique may not be the most appropriate for the situation. Here,
we summarise the list of various elicitation techniques that are worth considering in
process knowledge extraction. This matrix (Table 1) presents the relative merits, demerits
and best possible situations for applicability, and we hope will enable a process analyst to
select the most appropriate elicitation technique(s) depending on the particular
environment of the engagement.

Table 1 Summary of application situations

Elicitation technique Pre-conditions Advantages Drawbacks When to use
Introspection Analyst is Does not require Fails to reflect the As a preparation
familiar with process holders’ experience of actual for efficient future
business domain time process interactions with
Documentation stakeholders if used process
on processes and in isolation stakeholders
systems exists
No access to
process holders
Questionnaire Large user Inexpensive Possibility of low Quantitative
population Allows statistical response rate and research
Possibility of analysis of results ambiguity of Identifying pain
standardised interpretation points
answers Process
Prioritisation


Table 1 Summary of application situations (continued)

Interview Access to Allows process holder Requires Studying the same
process holder flexibility in considerable process area but
describing her work analyst skill and from different
procedures and issues experience perspectives due
Allows analyst to Depends on to differences in
probe for more details interpersonal process
and ensure that dynamics that stakeholder
participants are develop between experiences and
interpreting questions the analyst and the opinions
the way they were subject Familiarity with
intended Challenges in business domain
integrating to construct
different domain dependent
subjective questions
interpretations
from multiple
subjects
Say Do problem
Protocol Analysis Access to Possible to identify the Time consuming Study of dynamic
process holder exact stimulus, the to conduct reasoning
during the sequence of decision Time consuming behaviour
execution of points and tasks based to analyse and
the decision on those decisions interpret
process being
studied
Analyst is
familiar with
business
domain
Contextual interview Access to Produces a detailed Time and effort Study of detailed
process holder account of what and intensive steps in a process
during the how of a process in Intrusive technique rather than simple
execution of actual work settings – may interfere outcomes
the process with process
being studied holder
performance
Workshop Skilled Overcomes slow Time and effort Study of
facilitator communication and intensive processes cutting
Right set of promotes immediate across different
participants feedback organisations or
Share best practices departments
Committed
workshop Remove Murphy Resolving
sponsor blinds conflicts and
promoting shared
understanding


Table 1 Summary of application situations (continued)

Role Play Access to May be the only Subject may not be Not possible to
process holder option if all process sufficiently aware get access to all
holders are not of the work the process
available practices of other holders
Encourages one process holder/s
process holder to think Subject may be too
more deeply about self-conscious to
what other process play the role
holders’ motivations
or actions may be,
thereby providing a
better response to the
analyst

We close this paper with some research tasks that seem to merit further investigation.
These are:
• building a model for process knowledge documentation that provides the analyst
with directions on appropriate documentation selection that correspond to the
elicitation technique used
• building a repository of domain-independent questions and supplementing it with
supply chain domain knowledge questions
Academics and practitioners are encouraged to take up these further research
opportunities to further enhance our understanding of knowledge elicitation challenges in
‘as-is’ process modelling and how elicitation techniques can be better utilised to address
these challenges.

References
Alvarez, R. (2002) ‘Discourse analysis of requirements and knowledge elicitation interviews’,
Proceedings of the 35th Annual Hawaii International Conference on System Sciences
(HICSS’02), Vol. 8, p.255.
Beyer, H. and Holtzblatt, K. (1998) Contextual Design: Defining Customer-Centered Systems,
Morgan Kauffmann, San Francisco.
Browne, G.J. and Rogich, M.B. (2001) ‘An empirical investigation of user requirements elicitation:
comparing the effectiveness of prompting techniques’, Journal of Management Information
Systems, Vol. 17, No. 4, Spring, pp.23–249.
Carr, D.K. and Johansson, H.J. (1995) Best Practices in Reengineering: What Works and What
Doesn’t in the Reengineering Process, McGraw-Hill, New York.
Christel, M.G. and Kang, K.C. (1992) Issues in Requirements Elicitation – Technical Report,
CMU/SEI-92-TR-12 ESC-TR-92-012 Software Engineering Institute, Carnegie Mellon
University, September, http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf
Fielding N. (2008) ‘Ethnography’, in Gilbert, N. (Ed.): Researching Social Life, Sage, London.
Goguen, J. and Linde, C. (1993) ‘Techniques for requirements elicitation’, in Fickas, S. and
Finkelstein, A. (Eds.): Proceedings, Requirements Engineering, ’93 IEEE Computer Society
Press, pp.152–164.


Gottesdiener, E. (2002) Requirements by Collaboration: Workshops for Defining Needs,
Illustrated ed., Addison-Wesley.
Hammer, M. and Champy, J. (1993) Reengineering the Corporation: A Manifesto for Business
Revolution, Harper Business, New York, NY.
Harrington, H.J. (1991) ‘Business process improvement: the breakthrough strategy for total
quality’, Productivity and Competitiveness, McGraw-Hill, New York.
Sommerville, I. (2006) Software Engineering: (Update), 8th ed., Addison-Wesley.
Suchman, L. and Jordan, B. (1990) ‘Interactional troubles in face-to-face survey interviews’,
Journal of the American Statistical Association, Vol. 85, No. 409, pp.232–241.
Wiegers, K.E. (2001) Requirements When the Field Isn’t Green, http://www.processimpact.com/
sarticles/reqs_not_green.pdf

Process Modeling

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Process Modeling

Ähnlich wie Process Modeling (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Process Modeling