Use of Models

Use of models

Background

Given that a process design document is written for each key stage of a process (usually at a sub-process level), which are themselves fine grained deliverables, it is important to give the reviewer an appreciation of where the document fits into the big-picture.

Models are an effective tool for setting this context in different ways. The Unified Modelling Language (UML) is an industry standard modelling language. To enhance the understanding and re-use of such models, this technique will be used where possible in the following three areas.

	Organisation view: Highlights the roles that will be interfacing (or impacted by) this sub-process. Responsibility will be further detailed in the document.
	Dynamic view: Shows where the sub-process fits in, what led up to it, and what follows on from it.
	Static view: Summarises the key concepts that are material to the sub-process, such as information, documents and reports; and how they relate to one another

For all the above models it is important that they are present only to enhance the user understanding of the sub-process and to give assurance that the sub-process is complete and accurate. They are not for system design purposes, so the level of detail must be kept at appropriate levels. The temptation to spend large amounts of time over-engineering the models must be similarly resisted.

The following three sections describe models to support the above three views.

Use case model

The UML Use Case model is an effective way of describing the context of the sub-process to the roles within the organisation.

A use case states different ways (or cases) in which the systems within the sub-process are to be used by those outside it (the “actors”).

This differentiation of what is in scope and what is out of scope, and to whom our dependencies are with is a key benefit of using use cases[1].

The components of the use case are shown below:

Characterising the use case

This is not a functional breakdown: only key areas that result in some perceived goal by the actors need be considered. Since this is a similar concept to the scenarios described earlier, the scenarios can be used as a starting point, however it is permissible to combine any of these for clarity.

Note also, that as the process design document is not an architectural document do not model different component systems within the framework. Instead treat the system as one entity.

The use case model is primarily sourced (and should not contradict) the goals section of the process and owner document.

Actors vs. process participants

It is important to distinguish the difference between actors (as shown as the stick men above) and participants of a business process.

Actors: these are any party (system or human) external to the (sub)process being described by the process design document. The sub-process has therefore a dependency to and from these parties. External agencies are a good example of such an occurrence: whilst they interface with the sub-process they are not directly involved in the actual execution, and contractually we cannot tell them how to produce the things we need

Participants: these, on the other hand are “part-and-parcel” of how the sub-process is executed. We can (and must) define how they should perform their actions. In the above model business users such as finance are not shown as they are included “inside” the sub-process so are not considered an actor!

Note that both types will require definition in the responsibility summary section.

Will all process and owner documents require a process design deliverable?

Process owner documents are concerned with the what, and in particular, agreeing ownership of any dependencies. So it is entirely proper to get actors (remember these are parties external to the sub-process) to sign-off on what we expect them to do.

However it is not appropriate to tell such external parties how to they fulfil their deliverables (i.e. our process’s dependencies). The external parties process can be as efficient of inefficient as they desire – as long as they meet their agreed SLA’s that is our only concern. Thus, it is only the participants that we have the authority to say how things will be done, will be subject to process design.

Another area where there may not be a prcess design document is concerning technical automation. Since some sub-processes are fully automated you may find there are cases where a process owner document does not require a process design document.

Activity model

The UML activity model with swimlanes is an effective way of describing handovers, interaction and the relationships of the current sub-process to other sub-processes.

Depending on the relevance of SOX to you process, guidelines suggest a 2x2 swimlanes approach, with one direction describing the roles supporting the activity, the other handovers (input and output) together with a number of relevant “significant areas” it belongs to. These significant areas are useful from an audit perspective and include:

	Initialise
	Authorise
	Records
	Processes
	Reports

Note that only the relevant significant areas need be shown. E.g. If there is no authorisation taking place in this sub-process, then no authorisation column is needed.

The activity model is primarily sourced (and should not contradict) the inputs/outputs section of the process and owner document, as well as summarising the detail from the scenario steps themselves.

An example of this approach is shown below:

Do not try and model all the intricacies of the sub-process, such as conditionality and branching – as this may only confuse, and are an unnecessary detail for this deliverable. Just describe the key activity steps (at a suitable high level) and a basic indication as to their sequence.

Business Domain model

The purpose of this model is to give the reviewer a static “snapshot” of what is relevant to the sub-process. Whilst the UML class model is the basis of this model it is not being used for detailed modelling or design.

Its purpose is not to model all tables and attributes as in an Entity Relationship Model (ERM) rather just to highlight the business significant “artefacts”, such as:

	Reports
	Files
	Business Information (only describe data in tables at a conceptual level)
	Signoff Documents
	Physical deliverables
	E-mail attachments
	Etc

These models are very useful for highlighting any re-engineered aspects to a business process. For example, if a new element of a business process would be to formalise rules in which to apply tolerances to exceptions (as opposed to purely a judgement call), this could be emphasised by showing it as a new concept as shown in the example below:

The domain model is primarily sourced (and should not contradict) from the scenario steps themselves. It can be considered a “visual glossary” of all the things the users will encounter in completing the steps.

[1] Strictly speaking, what we are defining here is actually a business use case as those interacting with the system to get the job done are not considered actors

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