Describe the Problem
Home Business Change Analysis & Design Agile Testing Templates About us

Introduction
Determine the Scope
Determine Stakeholders
Describe the Problem
Analyse the Problem
Present the Findings
Define the Procedures
Back

Describe the problem

Once an understanding of the scope is known, the problem domain can be described.

All of the following questions need to be answered or else vulnerabilities will be introduced. They apply equally to system and departmental stakeholders in the business process.

bulletWhat are the goals of the business process – and how is this currently realised by the stakeholders?
bulletHow could this be improved?
bulletWho owns the business process?
bulletHow do they enforce compliance of activities performed by other internal stakeholders?
bulletWho does each stakeholder interact with?
bulletWhat do they give?
bulletWhat do they expect?
bulletWhat is the stakeholder responsible for doing?
bulletWhat is the stakeholder required to know?
bulletWhat are the SLAs?
bulletAre there any benchmarks that could be defined?
bulletWhat is the typical process (“happy” day scenarios)?
bulletWhat is the exception process (“sad” day scenarios)?

Unfortunately given the “open” nature of the way people/departments interact together (it is not typically just “one” way), to answer the above questions using just “words” is extremely difficult/complex. This is especially so since both completeness and visibility is sought.

Fortunately they are  relatively simple to model.

But in order to drive (and later validate) this modelling, it is first useful to establish a narrative “script”, typically in a workshop with all the internal stakeholders present.

bulletEnd-to-end, “cradle to grave” narrative should be established first
bulletSupport and exception narratives defined where necessary to show any significant deviations from the base end-to-end narrative.

A segment of a typical end-to-end scenario is illustrated below[1]:

Figure 3: Business Process Narrative example

Administer Credentials – End to End Scenario Overview

Narrative

Security Administrator has the ongoing responsibility for
maintaining a working stock of credentials for internal and external
use, as well as “spares” and for ensuring their secure storage. This
involves both the physical side of the credential such as the token,
dongle and any printouts of initial PIN; and electronic sides of the
credential such as an electronic register of initial PIN.

Security Administrator is responsible for liasing with other parts
of the business to determine demands on the stock levels. If
required, they will liase with Finance who in turn will order
additional credentials

Security Administrator is responsible for initialising credentials
on their receipt, assigning them an initial PIN and either registering
them for internal or external use. In the latter case they are
registered to the relevant company/individual.

Etc…..
 

Back Next

[1] If there are major groupings of stakeholders (e.g. those outside of the process owners control) these can be colour coordinated.

© 2002-2005 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com