Modelling Standards and Guidelines

Item

Details

Example

Business Process Area Diagram (BPAD)

Definition:

Business Process Area Diagrams (BPADs) are used to group and organise Business Process Diagrams (BPDs) and other BPADs.


Mandatory Fields:

  • BPADs must have a Name [Noun] in Title Case.

Guidelines:

  • A common organising principle used is to have a separate BPAD for each functional area of an organisation. For example:
    • Sales and Marketing
    • Production
    • Finance
  • Within a diagram if multiple items are connected, arrange the BPADs from top-left to bottom-right, as with standard text. This makes the diagram easier to read for the end user.
  • Incident Management
  • IT Knowledge Lifecycle
  • Graduate Development Program
Business Process Diagram (BPD)

Definition:

Business Process Diagrams (BPDs) are used to capture business process.


Mandatory Fields:

  • BPDs are to have a Name [Verb-Noun] in Title Case.

Guidelines:

  • Modelling items:
    • The general flow of the diagram should start at the top-left and end at the bottom-right of the allocated area.
    • All process exits should be aligned on the right hand side of the boundary of the diagram.
  • The page border (dashed blue line) is be used as a guide for the maximum width and height of diagrams. Modelling outside of the suggested boundaries may have negative consequences in printed reports and published websites.
  • Creating a Business Process Diagram whose name incorporates an “and” (Record and Update Customer Details) should be reconsidered, as it implies that two processes are in fact taking place in the one process diagram.
  • Processes should be broken up into logical units. Changing areas of responsibility (Finance vs. Maintenance) are a good guide to when a process flow should be split into different diagrams.
  • Other Process Diagrams cannot enter a given Process Diagram mid flow. If a process needs to join a diagram somewhere other than the first Process Role in the diagram, the diagram needs to be split to incorporate the new initiations.
  • Resolve Support Incident
  • Approve Asset Replacement
  • Evaluate Loan
Position
Internal Position
External Position

Definition:

A Position represents a job within the organisation. A Position is to be used on a Process Diagram when only one position can perform a Process Step. Positions can be modelled as internal and external to the organisation.


Mandatory Fields:

  • Positions have a Name [Verb-Noun] in Title Case.
  • Process Roles performed by the Position must be attached. 

Guidelines:

  • In large organisations employees will have slightly different job titles though they can perform exactly the same Process Roles. For example; A PR ‘Project Plan Creator’ on a BPD ‘Manage Weekly Project’, can be performed by both a Project Manager and a Financial Project Manager. Guidelines are to capture the job titles that exist for positions within the organisation.  Therefore both the Project Manager and the Financial Project Manager should be mapped as separate Positions and both should be attached to the applicable PRs.
  • Project Manager
  • Line Supervisor
  • General Manager
Process Role (PR)
Internal Process Role
External Process Role

Definition:

A Process Role (PR) is to be used when the Process Step (PS) can be performed by several organisational positions.

  • Differentiation can be made between;
    • Internal Roles – that is, roles that are “owned” or under the control of the organisation such as employees.
    • External Roles – roles that are outside of the organisation and its control such as customers and suppliers.

    • Mandatory Fields:

      • PRs have a Name [Verb-Noun] in Title Case.

      Guidelines:

      • It is an important distinction in modelling that Process Roles are not the same as organisational positions or members of an organisation.
      • PRs model business responsibilities (for performing Process). These roles may be performed by one or many organisational positions which may perform one or many PRs. Essentially; a PR is to be used when the Process Step can be performed by people with different job titles.
      • Thus, there is usually a many-to-many relationship between roles and positions.
  • Leave Approver
  • Credit Assessor
  • Safety Alerter
Process Step (PS)
Manual Process Step
IT enabled Process Step

Definition:

Process Steps represent units of work performed by a PR within the business process.


Mandatory Fields:

  • PSs have a Name [Verb-Noun] in Title Case
  • A description comprising of (at least 1 sentence detailing the actions taken to be taken to complete the PS)
  • An Enabling System, for IT Dependant Steps

Guidelines:

  • A PS name reflects what is happening and describes the output. A PS name makes sense as a PR’s or Position’s Responsibility.
  • Approve Loan
  • Assess Loan
  • Create New Account
Position Instance

Definition:

Position Instance represents an instance of a position within the organisation.


Mandatory Fields:

  • Position Instances  have a Name [Position] in Title Case.
  • Attach each Position Instance to a Position.
  • Attach each Position Instance to the direct line manager responsible.

Guidelines:

  • The number of Position Instances attached to a Position denotes the expected number of active position instances that exist within the organisation.
  • A single person should be attached to a Position Instance. If a person were to leave the organisation, then the person would be removed from the Position Instance. This would result in an empty instance of the position vacated.
  • If the Position Instance has been made redundant, the Position Instance is to be removed.
  • Position: Customer Service Officer
  • Position Instance 1: Customer Service Officer 1
  • Position Instance 2: Customer Service Officer 2
  • Position Instance 3: Customer Service Officer 3
Work Instructions (WI)

Definition:

Work Instructions (WI) document individual units of work by providing step-by-step directions for completing a task.

Mandatory Fields:

  • WIs can either be written internally within model or attached as external source locations.
  • External WIs have a name identical to the original document title, in Title Case.
  • Internal WIs documented within the models description field have a name [Verb-Noun] in Title Case.
  • WIs should be linked to a Process Step. A Process Step with a linked WI will show a chain link on the Process Step (in Modeler).

Guidelines:

  • WIs can be reused on multiple Process Steps. For example; Process Steps, “Enter Customer Loan Details” & “Edit Customer Loan Details” may use the same generic WI “Maintain Loan Manager Details”.
  • Maintain LoanManager Details
  • Update Optimizer Service Request
  • Check Customer Details in LQuotes
Person

Definition:

Person Items are used to capture real, live people who hold position instances within an organisation.

Mandatory Fields:

  • Person Items have a name identical to the person’s full name.
  • Person Items must be attached to a position instance, if the employee is actively holding a position instance.

Guidelines:

  • Person Items should only be attached to one position instance.
  • Dermont Ripples
  • Ashe Singh
  • Drake Davids
External Document Reference (EDR)

Definition:

An External Document Reference (EDR) is an internal reference that links an external document to the library. EDRs may be created to link charts, procedures, checklists, forms guides and other important documentation to a Process Step.

Mandatory Fields:

  • External WIs have a name identical to the original document title, in Title Case.
  • An EDR must have its Source Location completed.
  • A Process Step with a linked EDR will show a chain link on the Process Step (in Modeler).

Guidelines:

Adding applicable EDRs to each Process Step helps build a single, contextual, unified knowledge repository for the project or organisation.

  • Biller Investigation Form
  • Participant Guide
  • Loan Restructuring Checklist
System

Definition:

A System represents technology used to enable and support a Process Step. A System is linked to a Process Step. A System is non-trivial and specific. Generic and interchangeable software such as text editors, mail clients and the like are not included as Systems.

Mandatory Fields:

  • Systems have a Name [Title Case].
  • A Process Step with a linked System will show a chain link on the Process Step Item.

Guidelines:

  • Attach an Enabling System as well as Supporting Systems wherever multiple systems are used. In this case, the Enabling System should be the piece of software that is most instrumental in the completion of the activity.
  • Oracle
  • SAP
  • TechCert
System Function

Definition:

A System Function breaks a System into smaller components that require separate identification.

Mandatory Fields:

  • System Functions have a Name [Enabling System Name - Function Title] in Title Case.
  • The System Function item needs to be linked to the System Item of which it is a function.

Guidelines:

  • System Functions are usually closely correlated with user permissions for different Enabling System functions. For example; A Process Step which involves using ‘SAP – Cross Application Timesheets’ is executed by a single Position.  It would make sense to capture the System Function rather than simply the system ‘SAP’, which is too large and generic to accurately portray the functions that need to be carried out.
  • Examples of large Systems which would need to be broken down into System Functions including; MYOB, Maximo and SAP.


  • Business Warehouse
  • SAP – Cross Application Timesheet
  • Oracle -  Work Order Management System
System Process Diagram

Definition:

A System Process Diagram is a specialised BPMN diagram that depicts the logic used by an Enabling System. It may also detail the interactions between an Enabling system and any Supporting Systems.

Mandatory Fields:

  • System Process Diagrams have a descriptive Name [Noun] in Title Case with the text, ‘System Process Diagram’.

Guidelines:

  • System Process Diagrams are used to capture the logic behind the operation of a System. Therefore, they must be logical and show as much detail on the data being processed as possible.
  • System Process Diagrams are generally used in the context of System Requirements gathering, design of IT solutions or workflow automation.
  • Loan Simulation System Process Diagram
  • Insurance Claim System Process Diagram
Issue

Definition:

Issues are used to record problems related to Business Process content which either fall outside of the scope of the current modelling project, outside the scope of knowledge of the modeller or need to be discussed before amendments are made to the process.

Mandatory Fields:

  • Issues have a name which summarises the task at hand.
  • Issues should have between 5-10 words as a title.
  • Issues are to be assigned to review the issue using the ‘Owned By’ section.
  • Issues must have a ‘Resolve By’ date.

Guidelines:

  • Issues are helpful to record identified problems that arise when documenting As-Is Processes. Issues that are raised must be actioned appropriately and cleared out from the model before the model is published as a Business Management System.
  • Issues can be placed throughout the model on any type of diagram.  It is recommended that issues are attached to their relevant process BPADs and BPDs, with their description visible on the diagram.
  • Faxed loan applications have no flow channel in the current As-Is process.
  • As-Is process does not factor in changes in weather patterns.
Glossary Items
Glossary Term
Glossary Abbreviations
Glossary Acronym

Definition:

Glossary Items create a glossary of terms, definitions and acronyms that are commonly used throughout the model. The model’s entire list of glossary items can be viewed via the SOP dashboard. Glossary Terms can also be automatically linked to text fields to provide an online reference guide.

Mandatory Fields:

  • Each glossary item must have a name, which is the term, abbreviation or acronym being described. Use case appropriate to the item being described.
  • Each glossary item must also have a description which expands abbreviations and acronyms and describes the item. Context and usage may also optionally be provided.

Guidelines:

  • Hyperlinking to a glossary item ensures the term is always spelt the same way.
  • Changing one glossary item changes all hyperlink-references to the glossary item.
  • Using hyperlinks to a glossary item allows cross-referencing and drill down functionality for a term
  • Using hyperlinks to a glossary item allows the term to be tracked throughout the model.
  • Glossary items can be inserted as hyperlinks in any rich text field.
  • Example 1:
  • Term: Dining Room Equipment Cart
  • Abbreviation: QuipCart
  • Acronym: DREC


  • Example 2:
  • Term: Call Activity File
  • Abbreviation: Call Act File
  • Acronym: CAF


  • Example 3:
  • Term: Initial Public Offering
  • Abbreviation: Placement
  • Acronym: IPO
Business Rule

Definition:

A Business Rule defines or constrains one aspect of its subject’s behaviour. A Business Rule is intended to govern the behaviour of a role, position, or system as they perform or support a process step.

Mandatory Fields:

  • Business Rules have a name [Applicable Stakeholders and Rule Description]

Guidelines:

  • A Business Rule such as ‘All employees should work hard’, would be considered an ambiguous statement. Business Rules must have titles that are non-ambiguous, specific and easy to recognise.
  • All employees must sign a confidentiality agreement.
  • All employees must complete a timesheet weekly.
  • All employees must take 2 weeks consecutive annual leave a year.
Rule Set

Definition:

Rules Sets represent a way of grouping together Business Rules that share a logical relationship.

Mandatory Fields:

  • Rule Sets have a Name [Noun] in Title Case, dictated by the Business Rules which they encompass.

Guidelines:

  • Business Rules are compiled into logical groupings called Rule Sets, which are assigned to a subject. Ensure that there are no ambiguous rule sets created.
  • Rule Sets are intended to be reused  in situations where the same or similar sets of rules apply to a number of processes.
  • Employee Leave
  • Internet Protocol
  • Contract Negotiations
Regulation

Definition:

A Regulation item captures a regulation or part thereof. Regulation is legislation that constitutes or constrains rights and allocates responsibilities.

Government and industry bodies may put in place laws, regulations and voluntary guidelines that define acceptable and prohibited practices.

By ensuring that Regulations are documented, stored and displayed with the appropriate processes, process performers can quickly and easily refer to the regulations which govern their activities and regulatory bodies can easily be shown the processes which comply with their regulations.

Mandatory Fields:

  • Regulations have a name [Regulation Abbreviation] in Title Case.

Guidelines:

  • Regulations should be linked to the Business Process Areas they govern whenever possible.
  • ASIC RG 241  - Electronic trading
  • ASIC RG 97  - Disclosing fees and costs in PDSs and periodic statements
  • Financial Sector (Business Transfer and Group Restructure) Act 1999
Policy

Definition:

A Policy documents an agreed position from  decision makers on how to handle issues as they arise. Policies eliminate ambiguity that exists during the execution of business activities.

Up to date Policies lead to business activities that align with the organisation’s agreed position on a subject.

Mandatory Fields:

  • Policies have a name [Noun-Verb] in Title Case.

Guidelines:

  • Applicable policies can be attached at a BPAD, BPD or Process Step level. It is suggested that that policies be attached only to BPAD and BPD levels.
  • Every time a new Policy is created, determine if the policy is driven by external regulation. If so, attach and/or create the appropriate Regulation item.
  • Data Management Guidelines
  • Investigations Code of Conduct
  • Loan Restructuring Policy
Risk    

Definition:

A Risk documents the possibility of an unfortunate event or circumstance arising that may adversely impact the organisation.

Mandatory Fields:

  • Risks must be linked to a Process Steps, BPD or BPAD.
  • A Process Step with a linked Risk will show a chain link on the Process Step (in Modeler).


  • Risks have a name [Noun - Verb] in Title Case.
  • At a minimum, the Inherent Risk Likelihood and Inherent Risk Consequences should be completed.

Guidelines:

  • If there are any risk mitigation strategies available, they should be documented in the Available Risk Treatments area.
  • If any of the available risk treatment measures are in place and being used, an assessment of the Treated Risk Likelihood and Treated Risk Consequences should be undertaken and recorded, as should the risk mitigation strategies being used.
  • If information on best case scenarios is available, Residual Risk Likelihood and Residual Risk Consequences should be recorded.
  • Failure to deliver agreed revenue targets to Government
  • Resources are unavailable