Process Documentation Methodology Guide

Introduction #

Process mapping in BluePrintBI (BPBI) is simple and effective. Once a process is mapped in BPBI, it provides a clear understanding of the process itself and how the process relates to other processes within the organisation. BPBI generates and stores all process documentation centrally and makes it accessible to all BPBI users according to the access rights applicable to them.
The BPBI methodology enables a process to be mapped efficiently adhering to a predetermined set of standards of quality. It enforces the capturing of a minimum amount of data to enable valuable business process intelligence and business intelligence. This document aims to outline these standards.
Process mapping in BPBI begins at process level and progresses to detailing each task that occurs in the process. In addition, it is also possible to define reusable processes in BPBI, which may be used as sub-processes in other processes.

1. Process Documentation Methodology #

BPBI has been designed to ensure all processes are captured in a standardised manner. All processes mapped in BPBI include the same mandatory information, allowing the process documentation output from BPBI to have the same format and expected level of quality.
Documenting processes in BPBI at process level requires an understanding of the terminology used and what level of detail is expected to be included in each process, which will be explained in this section.

1.1 Requirements For Capturing Process Level Information #

1.1.1 Mandatory Process Information #

The following information is required as a standard for capturing a process in BPBI:

  • Process Name
  • Process Frequency
  • Process Owner
  • Process Description
  • Goal
  • Success Measurement
  • Process Trigger

1.1.1 Process Name #

The name of the process must be unique, clear and concise, and give a clear indication of the purpose and outcome of the process. Process names are limited to 255 characters. Duplicate process names are not allowed.

1.1.2 Process Frequency #

The frequency of the process states how often the process is executed. Examples of process frequencies, include at month end, on instruction date, and weekly.

1.1.3 Proccess Owner #

The owner of the process is stated in terms of their job title. The process owner is the person who will be responsible to ensure that the documented process is accurate and complete and will also be responsible for authorising the process on BPBI.

1.1.4 Process Description #

The description of the process should be a brief, high-level description of the entire process. The process description is limited to 1000 characters and should contain enough information to explain the nature of the process to an executive level audience or an auditor.

1.1.5 Goal #

The goal of the process specifies what the process is aiming to achieve, i.e. the purpose of performing the process. The goal is usually defined in terms of accuracy and time. For example, the goal of a process could be “to successfully, accurately and timeously present the calculated monthly reports”.

1.1.6 Success Measurement #

The success measurement provides a measure to determine whether the goal of the process has been achieved. The expected outcome of the goal may be the measure of the process’s success. Success measures may also include other factors, e.g. customer satisfaction or the balancing of certain figures.

1.1.7 Process Trigger #

The trigger of the process outlines the cause of the starting of the process. Each process has a trigger based on some or other event that occurred, e.g. month end or the receipt of an instruction.

1.17.1 Additional Attributes #

Attributes add enrichment data to processes. Three of the most important attributes that may be added in BPBI on process level are process supporting documents, inherent risks and process control objectives. Each of these attributes are explained below.

1.8 Process Supporting Documents #

Supporting documents may be linked to a process to describe the process in more detail, e.g. standard operating procedure documents, or to add information to assist the operator in performing the process, e.g. screenshots or user manuals of the functionality of the relevant technology or system.

1.9 Inherent Risks #

On the Inherent Risks attribute tab, all the identified inherent risks associated with a process may be tagged on the process.

1.9.1 General Rules #
  1. Inherent risk weighting is allocated equally to all inherent risks on a process, automatically
  2. Inherent risk weightings may only be adjusted after saving all inherent risks that are to be added to the process
  3. The system will not allow the inherent risk weightings percentages to ever tally up to more than 100% and will automatically allocate an acceptable percentage to the risk if the total percentage tallies up to more than 100% (even before saving), therefore it is advisable to allocate inherent risk weightings in order from the smallest to the largest percentage.

1.10 Process Control Objectives #

It is possible to define multiple control frameworks on BPBI and apply these to processes and/or tasks. Examples of control frameworks include audit controls, internal controls or ISAE3402/POPI/FATCA.
Control objectives are set up as static information. Controls complied with are listed on process level and tagged on task level on BPBI, where it is applied on the process.

2. Requirements For Capturing Task Level Information #

Once the higher process level information has been defined, the SME (Subject Matter Expert) may now define the steps that are involved in the process. Each task should be specified in the correct order as it is performed in the process.

2.0.1 Mandatory Task Information #

The following information is mandatory for capturing a process on task level in BPBI:

  1. Task Name
  2. Task Description
  3. Task Frequency
  4. Operator
  5. Tool

2.1 Task Name #

The name of a task must begin with a “verb” and be followed by a “noun”. The task name describes the action to be performed concisely. The task name will be shown as a node on the process flow diagram and should be intelligible without the context of the task description. The name of the task is limited to 50 characters and should not include the operator.

2.2 Task Description #

The task description is mainly used for training purposes. The description of the task should provide a detailed explanation and all information necessary to enable the task to be performed. The task description is limited to 1000 characters. SOP-level instructions, screenshots and templates may be attached to the task as supporting documents to further aid in its execution.

2.3 Task Frequency #

The task frequency indicates when the task is to be performed. It usually correlates with the frequency of the process. Examples of frequencies are daily, weekly, and at month end.

2.4 Operator #

The operator of the task is the job title of the person performing the task. A single operator should be used per task unless both operators are actively involved in the task at the same time.

2.5 Tool #

The task tool indicates the technology used to execute the task. More than one tool may be utilised in performing the task. A task may also be indicated as “Manual”, if not technology is involved in performing the task.

2.5.1 Additional Task Attributes #

Attributes add valuable data to processes. There are several attributes that may be added to tasks to enhance the business and process intelligence that may be derived from the process information, which are explained below.

2.6 Day #

The day indicates the number of working/business days since the process was triggered until the task is performed. I.e. if the task is performed on the day the process is activated, the day would be zero (0). If the task is performed two business days after the process was initiated, the day would be 2.

2.7 Deadline #

Tasks may be given deadlines to indicate when the task should be completed by.

2.8 System Task #

A task may be identified as performed solely by a system task and indicated as such.

2.9 SLA Deadline #

The Service Level Agreement Deadline indicates an external deadline governed by an SLA agreement and/or a market cut-off time, e.g. the Finswitch cut-off time.

2.10 Task Control Objectives #

Control objectives may be tagged on processes and/or tasks. Control objectives indicate the process’s compliance with audit controls, internal controls or ISAE 3402.
Control frameworks are set up as static information on BPBI and applied on process and/or task level on processes in BluePrintBI. Control objectives on task level may be linked to objectives on process level.
On process level, the controls that are applied to the process are identified and listed. On task level, the exact step where the control is applied is indicated.

2.11 Risk Incidents #

In BluePrintBI, it is possible to indicate exactly on which task in a process a risk incident occurred and to capture detailed information and supporting documentation regarding the risk incident.
Cumulative losses are calculated and reported on per process.

2.12 Dependencies #

Where a task is dependent on the outcome or completion of another task in the same or another process, this dependency can be documented in BluePrintBI.

2.12.1 General Rules #
  1. More than one dependency may be added to the same task
  2. Dependent processes and tasks are selected from the work-in-progress process inventory
  3. Dependencies are listed on the Detailed Report in the “Task Description” column
  4. If the dependent process has never been authorised before, the dependency will not reflect on the authorised process documentation on the In Use screen and the Web Viewer. As soon as the dependent process is authorised, the dependency will show on the process documentation generated from the Web Viewer and In Use screens
  5. When a task that another process is dependent on is deleted, a warning is displayed to note that the task is a dependent task. The option is offered to select whether to continue or cancel the deletion. If the task is deleted, the dependency is removed from the other process
  6. When a process has dependencies noted, that process will be indicated in blue on the Process Hierarchy Diagram

2.13 Reporting #

Reports of data files generated or produced as the output of a process task, as well as reports or data files received as input to a task, may be linked to the relevant task in BluePrintBI. The following information may be documented regarding reports in BluePrintBI:

  1. Internal and external recipients
  2. Examples of reports

2.14 Task Control Adequacy #

Inherent risks of a process may be mitigated by tasks on processes. The measure to which the task mitigates the inherent risk is referred to as its control adequacy percentage.

2.15 Task Supporting Documents #

Supporting documents may be linked to a task to describe the action in more detail, e.g. standard operating procedure documents, or to add information to assist the operator in performing the task, e.g. screenshots of the system functionality or user manuals of the relevant technology or system.
Supporting documents are loaded into the BPBI library and referenced from processes and tasks. When a document in the library is updated, all processes utilising the document will automatically refer to the latest version of the document.

2.16 Inefficiencies #

Inefficiencies are identified weaknesses or opportunities for improvement in a process and may be may be logged in BPBI on a task. Inefficiencies are categorised in terms of the types of inefficiencies that are set up for the organisation on BPBI.

2.17 Cost #

Specific cost may be added on a process or task level, for example printing or stationary. Where the task duration is specified on a task, the cost of the operator may be calculated if the salary static data have been added to the system.

3. Standardised Reporting #

BPBI produces standardised reporting of process information in the following formats:

3.1 Process Hierarchy Diagram #

A high-level graphical representation of the operational structure in Adobe Acrobat (.PDF) and MS Visio

3.2 Process Flow Diagram #

A graphical representation of the process in Adobe Acrobat (.PDF) and MS Visio

3.3 Detailed Report #

A detailed description of the process which includes a step-by-step depiction of the process and links to all supporting documentation and process flow diagrams. The detailed report may be downloaded in MS Word, MS Excel and Adobe Acrobat (.PDF)

3.4 Summary Report #

A summarised version of the process, which may be downloaded in MS Word, MS Excel and Adobe Acrobat (.PDF)

3.5 Cost Reports #

A high-level graphical representation of the operational structure in Adobe Acrobat (.PDF) and MS Visio

3.6 Data Queries On Outputs Screen #

A high-level graphical representation of the operational structure in Adobe Acrobat (.PDF) and MS Visio

Powered by BetterDocs