Supplementary specification

Deliverable and dependency specification

Generic artefact attributes required

Every deliverable and dependency (unless described in another document) will need to be specified in this section.

These artefacts can be identified as the objects in the process design. The purpose of the scenarios is to show procedure, responsibility and interaction, so to specify these artefacts as part of the scenario would dilute this purpose. Instead they are specified here.

It can be generally assumed that all these artefacts will undergo some for of audit scrutiny, so formalising them in one place will pre-empt many of the questions that will later be asked.

Clearly it is important to keep the name/term used in the scenario, consistent with the one used in this section.

These artefacts can be

	Reports
	Mapping tables
	Nofications
	Reconciliations
	Data
	Exception resolution business rules
	Queries

The following information is common to all of these deliverables:

	Primary Owner: The role and designated contact who is responsible for producing it, reacting to information in it or maintaining it.
	Purpose: What is this deliverable for?
	Control: What controls are in place to satisfy and key risk (e.g. access, authorisation etc)
	Evidence Basis: How is this artefact evidenced? Is there an audit trail for the item? Is it printed and filed? Note this may be judged “N/A” in many cases.
	SLA: What criteria will this be judged by
	Nature/Location: What type of output is it? Where is it kept/stored/recorded?
	Technology: In particular if this is tactical report that needs to be productionised, or an existing report that requires a change of platform, this must be made clear here. See also next point….
	Maturity: Is this deliverable already agreed by all parties or is it speculative/process reengineering? What actions are required to formalise the adoption of this deliverable.

The remaining information is specific to the specific to type of artefact, as described in the following sections.

Reports (general)

There must be a clear description of what the report is for, who will look at it, and logically what the information will contain. Much of this is covered in the generic artefact attributes, but in addition to the common information discussed in the last section the following is required:

	Columns
	Sources of data
	Aggregations or summary information
	Relevant data ranges
	Relevant data restrictions (e.g. specific products)

Reports should be segregated by the key reporting types of:

	Reconciliations
	Validation
	Quality

Reconciliations Reports

This can be treated as a specific report type, and will thus share its characteristics. In addition it must clearly show

	Source
	data category
	how to reconcile

Validation Reports

This is a specific report type. It must clearly show:

What is being validated, and should be cross-referenced by any business rules or exceptions referenced elsewhere in the document.

Quality Reports

This is a specific report type, in addition to above it must clearly show:

SLA (Quality measure and metric) it is tracking, and how this measure is to be interpreted.

Notification

Notifications can be considered a special type of report, so in addition to the generic report attributes the following needs to be described:

	The mechanism of notification,
	The recipient.

Data (general)

This a generic term to cover any requirements to describe business information, tables, attributes.

	Tables and key attributes
	Where more than one table is described then relationships to be shown, either in

An entity relationship model (3^rd normal form) where the data is relating to de-normalised data in tables, or…

A star schema (fact tables and dimensions) where the data is relating to information held in data marts or warehouses

· The SLA here will be primarily interested in defining integrity, availability requirements

Mapping tables

This is a specific category of data, in addition to above it must show:

	System
	Mapping tables
	Attributes derived in platform
	Key values

Queries

This is a specific category of data. The specific SQL should not be shown, but it must cover enough information regarding what it is a function of:

	Parameters
	Source of information
	Output

Exception Resolution Business rules

It there are standard instruction to follow to resolve exceptions these should be described here. The following should be described:

	Condition
	Response

Exception specification

The ability to identify and manage exceptions are a key part of any business process. Whilst the scenarios do reference and distinguish the exceptions in summary, further detail is required to allow parties to effectively manage them:

	Reason exception occurs: What triggers the exception
	Prime responsible party: Who is responsible for managing the exception to completion? Note this person is not necessarily involved in “fixing” the exception directly and may require the assistance of other parties. It is vital that each exception has one designated coordination role.
	Supporting parties: Who is required to assist the above in expediting the exception.
	Possible corrective actions: How are the ways in which the exception can be resolved? This should reference the exception resolution business rules.
	SLA: How quickly does the exception need to be resolved?
	Impact if not corrected: What happens if the exception is not resolved in the SLA timeframe.
	Escalation path: If exception is not resolved who does the exception need to be passed to and what further action needs to be taken.

Control specification

Internal controls identified in the process and owner document, together with those identified by the scenarios must be described in this section

	A link between the control objective and the local control
	A description of the local control which clearly describes how the local control prevents the associated key risk from occurring or detecting it if it does (i.e. achieving the control objective)
	A description of how the local control is to be applied, who is responsible for performing the control, how frequently the control is performed, and where it is evidenced

For an internal control to be properly designed, it needs to have an appropriate answer to each of the following qualitative questions:

	Control Type: What is the control being performed?
	Control Objective: Which control objective/risk category is being satisfied?
	Control Owner: Who performs the control?
	Control Frequency: When is the control performed?
	Control Evidence: Where is the control evidenced?
	Control Procedures: How is the control performed? Note these procedures don’t need to be restated if covered in enough detail in the scenarios. A cross reference to the scenario steps is adequate here.

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