Back Room Front Room 2

38
ENTERPRISE INFORMATION SYSTEMS VI
and re-formulation. Within this reasoning cycle, S 3
deals with strategic, service and support issues.
a. Strategic issues are organisational and
stakeholder goals for improving the
organisation’s performance.
b. Service issues are the levels of
improvement considered by the
organisation.
c. Support issues are the resources policies
and actions required to reach the desired
service levels.
The S 3 approach is a generic approach and
has been applied to a variety of different domains
and applications such as electricity deregulation
(Kavakli et al., 1999), profiling of customers in the
banking sector (Kardasis et al., 2000), electronic
procurement projects (Kardasis et al., 2004) and coordination
of systems in large-scale spectators’
events (Loucopoulos, 2003).
The S 3 approach is motivated by four ‘principles:
(a) Systems thinking in considering all interrelations
between different system components forming a
whole (Chackland, 1999; Richmond, 1993); (b)
Abstract thinking in moving away from the physical
manifestation of processes (Walsham, 1994); (c)
Operational thinking in considering the dynamics of
a business process and in particular their behaviour
over time (Sterman, 2000; Forrester, 1999); (d)
Solution-first thinking in attempting to identify
requirements by generating a provisional design
whose purpose is to highlight potential functionality
(Carroll, 2002).
In terms of method steps there are essentially two
activities: (a) model building and critiquing
(Andersen et al., 1997; Vennix, 1999) and (b)
simulation and group deliberation (Fowler, 1996;
Wolstenholme, 1995). Models are mainly built by
analysts with input from domain experts but are
critiqued and revised by stakeholders. Analysts also
facilitate simulation sessions where model
parameters are instantiated by stakeholders.
Consensus building stakeholder workshops develop
scenarios that facilitate deliberation of alternative
future realizations.
To demonstrate the way the S 3 approach can be
used to elicit and validate early requirements
consider a number of examples will be given
henceforth taken from a large application involving
requirements for venue operations for the Athens
2004 Olympic Games (Loucopoulos et al., 2003).
This problem domain is one of process integration
that was phased by the Athens Organising
Committee (ATHOC). There were many different
co-operating agents (e.g. the distribution of results
involves the co-ordination of systems concerned
with timing, information structuring, information
communication, reprographics, and physical
distribution). Different stakeholders had distinct
goals and expectations of systems (e.g.
transportation is solely concerned with safe and
timely arrival and departure of spectators whereas
catering is concerned with meeting demand during
the operation of a venue). Domain experts from 27
different functional areas had to arrive to a
consensus of the functionality of an entire venue
(e.g. transportation needs to be co-ordinated with
crowd queuing control which in turn need to coordinate
with security etc).
Co-development of business processes and
support systems for this problem led to a number of
complex decision making activities during early
requirements. For example, addressing issues such
as “what are the appropriate types and level of
resources that will be needed by each functional area
for each venue?”, “what are the interrelationships
and interdependencies of the various functional areas
in providing the required services to the various
customer groups?”, “what is the trade-off between
the desired service level and the resource allocation /
requirements for each activity involved in a
process?”, “what is the optimal operational
smoothing / resource levelling for the overall
process pertaining to a given customer group?”
Ultimately, ATHOC had to specify the physical
infrastructure (e.g. building works, public
transportation etc), support systems (e.g. security
systems, reporting systems, catering systems, ATMs
etc) and procedures (e.g. protocols for dissemination
of results, crowd control etc) in such a way so as to
satisfy both the individual requirements of each
functional area and the systemic requirements that
arise from the process-oriented view of venue
operations. It was therefore, profoundly important to
reach agreement between stakeholders from all 27
functional areas on the way that their interdependent
requirements were to be dealt in the most
transparent, quantifiable and effective way possible.
2.1 Model Building
In eliciting the goals for the venue operations
system, the aim was to understand what determined
the successful operation of the system. This
involved helping the various stakeholders
externalise the (sometimes implicit) goals that they
had, capturing these goals, and synthesising that
knowledge with information from other sources,
such as existing documentation, abstract
descriptions of various systems and procedures, and
so forth. Stakeholders’ goals were thus an initial,
high-level expression of system requirements
viewed from the perspective of ATHOC, i.e. the
service provider (as opposed to that of the user).