Introduction

Purpose 

This document establishes the SyWay standards for business process modelling using SAP Signavio to ensure consistency, quality, and clarity in process documentation across all business processes. 

Objectives

List specific goals this standard aims to achieve. Include objectives like ensuring model reusability, standardizing process flows and improving model accessibility.

Key Restrictions

License Types

Modelling Restrictions

Syway Modelling Conventions

Introduction

Context

The SyWay project drives the implementation of new business processes across Syensqo’s organisation, utilising SAP Signavio to promote simplicity and standardization. 

Syensqo implements the BPMN 2.0 process modelling framework in SAP Signavio, utilising a modular hierarchy of process models to create the Syensqo Business Process Architecture, that visually maps how Syensqo's business processes, systems, and data work together to achieve its business goals. The methods by which Syensqo’s business processes are modelled are described here and defined as the Business Process Modelling Standard (BPM Standard).

Syensqo’s Business Process Architecture is a logical structure of business processes defined in a modular hierarchy. Focusing on good Business Process Management (BPM) leads to a greater, company-wide understanding of how the organisation works together in a continuous flow of value-creating processes.

Syensqo defines a business process as a series of logically linked activities, with a clear beginning and end, as well as clearly defined inputs and outputs. It is therefore a structure for action. 

Scope

These standards apply to all business process models created and maintained in SAP Signavio, including:

• Process landscapes
• Value chains
• Process diagrams (BPMN 2.0)

Key Design Principles and Guidelines

• Clarity First
  • Every model should be immediately understandable to its intended audience
  • Avoid unnecessary complexity
  • Focus on communicating the process flow clearly
  • Important for employees to understand how their work areas interface with others as part of process orientation, or if employees from different project phases are to work together successfully
• Standardisation
  • Use consistent modelling patterns, symbols, and layouts
  • Apply the same level of detail for similar processes
  • Ensure uniform naming and labelling
  • Creates a basis for effective communication between employees in different departments
• Appropriate Detail
  • Include only information relevant to the model's purpose
  • Maintain consistent levels of detail and granularity within a model
  • Create sub-processes for highly repeatable strings of activities within an L4, in order to facilitate ease of legibility and comprehension. See section 3.3.5. Sub-Processes
• Maintainability
  • Design models to be easily read and updated
    • Consider separating large and complex processes into smaller Level 4’s
    • Do not map optional paths
    • Maintain a neat and orderly layout of objects
  • Document modelling decisions and exceptions

• Key Benefits
  • Improved model readability and comprehension 
  • Consistent process documentation
    • Models can be used as a key foundation upon which training documentation can be built and maintained
  • Enhanced collaboration across teams
    • Security requirements can be captured through the use of swim lanes
    • Risks and Controls can be captured and linked appropriately
    • More comprehensive use of automated testing tools
  • Simplified model maintenance 
  • Accelerated onboarding for new modelers 
  • Efficient process analysis and optimisation
    • Allows for ongoing process improvement long beyond the project lifecycle.

Modular Business Processes

Process Model Definition and Usage

The SyWay Business Process Architecture is a structured inventory providing a hierarchical representation of all business processes against the scope of the SyWay Project. It describes “what we do”.

In Signavio, the Folder Structure provides a vertical list of Processes, a hierarchical decomposition from Level 1 Group Processes e.g. Finance, down to Level 4 Processes containing Level 5 Process Steps. By navigating through the four levels of Processes, you will understand how processes are functionally clustered, including the Process Steps that form the basis of our day-to-day activities.

Implementing a well-designed Process Architecture is essential to be able to define and understand integration points between processes, teams and departments.

Process Decomposition

For an effective enterprise system implementation, it is vital that the lowest level of process decomposition corresponds to Process Steps which are supported by a clearly defined set of Objects and Elements, such as transactions, documentation, systems, roles and more. A Process Step should describe a logical unit of work activity, carried out by one person, that can be measured in terms of time and cost.

The main model types used to describe the levels of the SyWay Process Architecture are:

• Value Chain Diagram at Levels 1 and 2
  • Modelled using the Value Chain
• Business Process Model at Levels 3 and 4
  • Modelled using the Business Process Diagram (BPMN 2.0)

• Level 1
  • Level 1 Processes, also known as Process Groups, are composed of subordinate Level 2 Processes, also known as Macro Processes.
    • Example: 06. Supply Chain
• Level 2
  • Level 2 Processes represent a group of highly cohesive Level 3 Processes.
    • Example: 06.04. Manage Global Trade Enterprise Structure
• Level 3
  • Level 3 Processes represent a group of Level 4 Processes, which describe activities that are ordered according to their position in time and space.
    • Example: 06.04.01. Create Administrative Unit
• Level 4 (Process)
  • Level 4 Processes consist of a precise and chronological sequence of Process Steps and are the foundation upon which the Syensqo Solution is built. They have predecessor and successor relationships to each other and should be modelled as such. The process flow is used to determine scope, boundaries and integration points with other processes.
    • Example: 06.04.01.01. Assign Plants to Admin Unit
• Level 5 (Process Step)
  • A Process Step is a logical unit of work at the lowest level of business process decomposition, carried out by a person in a defined business Role. Decomposing any further leads to a procedural level. A Process Step achieves a business result and uses data or information as inputs and creates data or information as outputs.
    • Example: 06.04.01.01.010. Select Plant

Modelling Standards

Syway Signavio Modelling Convention Checks

A modelling convention consists of modelling guidelines regarding notation, labelling, process structure and diagram layout. The modelling convention check can be run manually whilst modelling and by default, will always run upon saving changes to a model. 

Click the Review button when saving changes to open a pop-up window in which you can highlight each Error, Warning and Hint provided. All errors must be resolved prior to sign-off.

A Modelling Convention Report can also be run on one or multiple models in the explorer, containing a summary of Syway modelling convention violations.

General Layout

• Models flow from left to right, top to bottom.
• You should be able to sense the passage of time from left to right
• Model parallel paths one above the other
• Maintain consistent spacing between elements
• Avoid overlapping elements and connection lines
• Avoid crossing sequence flows wherever possible
• Align elements horizontally and vertically where logical

Model Size

• Limit diagrams to one page when possible (recommended max: 15-20 elements)
• Create sub-processes for complex sections
• See below for more detail
• Large processes may be candidates for separation into two (or more) smaller level 4 processes. Alternatively using sub-processes may be a good option.

Value Chain Object & Element Usage

Value Chains are a visual repository of subordinate processes, arranged sequentially, using the Collapsed Process object. No connections are required between these objects.

BPMN Object & Element Usage

The usage of the various structural objects and elements available in the Syway Business Process Architecture, as set out in this Standard, is enforced by Signavio configuration and governed by the Syway Signavio Modelling Convention checks.

Events

• Start events: Always begin a process with a labelled start event
  • Assign preceding process to Start Events via the Custom Attribute “preceding process”
  • Rename event to match the name of the preceding process
• End events: Always end a process with at least one labelled end event
  • Assign subsequent process to End Events via the Custom Attribute “subsequent process”
  • Rename event to match the name of the subsequent process
• Intermediate events: Use to model process integration
  • Every Start and End event must be paired with an Intermediate event
  • The final Intermediate event in a process must match the first Intermediate event in the subsequent process
    • See example below

Process Steps

• Process Steps should not be copied between process models, as each must be assigned a unique Level 5 identifier which assigns it to a single Level 4 process.
• Multiple process steps may be assigned to the same Process Step object in the Dictionary. 
• The Signavio Key Users and BPM team maintain the Process Step Dictionary category to remove duplicates and align the objects with this Standard.
• Use task types appropriately:
• A User task is used to depict a single action which is performed by a User accessing an application or system (e.g. SAP).

• • A Manual task is used to depict a single action which is performed manually. It is expected to be performed without the aid of any system or application.

• • A Service task is an automated action that starts automatically when the sequence flow arrives. If any User involvement is required, it should be a User task.

• • A Script task is used to depict an automated action for which there is no Executable e.g. it is part of Config.

Gateways

• Label all gateways with questions for decision points
• Gateways can be either one in, many out (diverging), or many in, one out (converging), but never both.
• Only the following Gateway types are to be used:
• Exclusive gateway (XOR): Only one path is chosen 

• • Inclusive gateway (OR): One or more paths are chosen 

• • Parallel gateway (AND): All paths are executed simultaneously

Connectors

• Use sequence flows (the default connection type) for the normal flow within a pool

• Use the different Association connectors to connect Data Objects to process steps, making use of the different directions to describe the nature of their relationships, for example, describing whether a document is an input to, or an output of a process step.
• Avoid using data objects and associations unless data flow is critical to understanding

Collapsed Sub-Processes

• Sub-processes can only be used to represent Level 4 process objects on L3 process models

• They cannot be used on Level 4 process models instead of further decomposition, only where the sub-process represents a highly repeatable, linear string of process steps that occurs within a particular L4 process. 
• A sub-process is a good way to summarize such a string, in order to make an L4 process model easier to read and digest
• Examples of when a sub-process could be used:
• Performing a Credit Check as part of the Sales Order process
• Performing a Quality Inspection as part of the Goods Receipt process

System Interfaces

• System Interfaces are used and referenced directly in the course of a process.
• They are modelled using an Intermediate Event between two Process Steps
• The systems assigned to the “sending” and “receiving” process steps must match the systems maintained in the sending and receiving system attributes of the event
• If the Interface you wish to model is not available, please contact either Alex Helme or Niclas Palmstroemer

Executables (Fiori Apps, T-codes, URLs, Programs, etc.)

• Executables are programs that can be run to execute a specific task. They fulfill process steps, and can be one of the following:
• T-codes
• Fiori Apps
• URL (SaaS)
• Program
• Assign Executables to process steps via the Custom attribute “Executable”
• Multiple Executables may be assigned to the same Process Step

Object Details & Creation

Object	Definition	Creation method Via tool dialog entry and/or on a specific diagram type.	Appearance on Process Diagram?
Gateway	Gateways are used to control how Process Steps and flows interact as they converge and diverge within a Process. Gateways must follow one of the following rules: One in, many out       Many in, one out	On a Process Diagram: Select the correct Gateway symbol from the Shapes window. Only three types are available for use: Exclusive Inclusive Parallel  To change the type: Left-click the Gateway Click the “Types” icon to the bottom-left of the gateway       Select the desired type from the list, ensuring it is one of the three types allowed	There are 3 types of gateways allowed by this standard:   Exclusive gateway is used to create alternative paths within a process flow. Only one path is taken.    Inclusive gateway creates alternative paths which are not mutually exclusive. One or many of the paths can be executed.    Parallel gateway is used to create parallel flows. Each path is executed simultaneously.

Naming Standards

Process Names

• Use verb-noun format (e.g., "Process Invoice" rather than "Invoice Processing")
• Be specific and descriptive
• Capitalise the first letter of each word (e.g., "Approve Customer Order")
• Avoid acronyms in titles unless universally understood

Process Step Names

• Use verb-noun format (e.g., "Enter Customer Data")
• Be concise but descriptive (5 words or less when possible)
• Use sentence case (e.g., "Review credit application")
• Avoid technical jargon unless required for clarity

Gateway Labels

• Phrase as a question (e.g., "Is credit approval required?") 
• Label diverging gateways with the decision question 
• Optionally label converging gateways for clarity 
• Label each sequence flow from exclusive gateways (e.g., "Yes", "No")

Event Labels

• Use past tense for events that have occurred (e.g., "Invoice received") 
• Use descriptive language (e.g., "Payment deadline reached" rather than "Timeout") 
• Keep labels concise but clear.

Model Organisation

The Folder Structure

In Signavio, the Folder Structure provides a vertical list of Processes, a hierarchical decomposition from Level 1 Group Processes e.g. Finance, down to Level 4 Processes comprising Level 5 Process Steps.

By navigating through the four levels of Process, you will understand how processes are functionally clustered, including the Process Steps that form the basis of our day-to-day activities.

• The Folder Structure is organised by process stream and then decomposed by logical process category 
• It is consistent across the organisation.
  • Changes to the folder structure can only be made by the BPM members of the Integration team. Please contact either Alex Helme or Niclas Palmstroemer
• Clear naming patterns are to be used for processes and process steps.
  • Verb-noun format

Revisions

• Whenever changes to a model are saved, a new Revision is created.
  • Use the Activity Feed to review Revisions, add comments and revert to previous versions
• Subscribe to a model or folder to receive notifications when a change is made
• Document significant changes in the model description, including reasons for change if necessary.

Links and Relationships

• Create links between related models via process integration
• Use glossary terms to ensure consistent terminology.

Documentation Standards

Process Model Metadata

Mandatory Attributes for all Level 3 & 4 Process Models:

• Custom Attributes:
• Process owner
• Main Attributes:
• Name (must match the Folder Name)
• Documentation (Description)

Process Step Metadata

Mandatory Attributes for all Level 5 Process Steps:

• Custom Attributes:
• Identifier
• The numerical identifier is used to make sure that the process or process step in the Syway Process Architecture can be easily recognised
• The L5 section of the identifier must be 3 digits, e.g. 06.04.02.01.010.
• The identifier must end in a full stop.

• Main Attributes:
• Task Type
• Name
• Use verb-noun format (e.g., "Enter Customer Data")
• Documentation (Detailed Description)
• Describe what the process step is doing.

Optional Attributes for all Level 5 Process Steps found in Custom Attributes:

• IT System (for User, Service and Script Tasks only)
• Executable
• GBS
  • Check this box if the task executed by this process step will be performed by GBS/Share Services.
• Process Standardisation
  • Check this box if the task executed by this process step is a single or standardized business process across all GBU's/functions (every L5 that is not GBU or function specific).
• Solution Standardisation
  • Check this box if the task executed by this process step is using standard functional capabilities of the tool or platform (every L5 step that is a system step that does not have a custom according to the WREFUN counting rules).
• Automation
  • Check this box if the task executed by this process step is to be automated in some way, for example, an interface replacing manual tasks; SAP tasks replaced by an automated workflow, batch jobs, AI, RPA, Machine learning, etc.
• Batch Job
  • Check this box if the task is executed by a batch job
• Batch Job ID
• Accountable
• Consulted
• Informed
• Risks
• Related Documents
  • Config Guides
  • Func Specs
  • Tech Specs
  • Input and output documents e.g. Reports

Decision Rules (Gateways)

Gateways are used to control how Process Steps and flows interact as they converge and diverge within a Process. For gateways and business decisions:

• Label all gateways with questions for decision points
• Document decision criteria in the relevant process step descriptions
• Include links to relevant business rules or policies
• Specify decision authority

Review & Approval Process

Quality Check

Signavio implements BPMN governance checks at the point of Saving. You may save changes without addressing the errors by following the prompts, however before any model can be approved, it must pass these quality criteria:

• Adherence to this Syway BPM Design Standard
• All Signavio Errors resolved
• Completeness of documentation
• Technical correctness (no broken links, correct use of gateways, etc.)
• Business accuracy (verified by process lead)

Approval Workflow

• Initial creation and revisions of each model are performed by the process modeller
• Internal team review performed by Signavio Key User (SKU)
• Technical review by BPM modelling expert from the Integration team
• Business review by process owner and any other stakeholders
• Final approval by Syway process governance team

Publication

• Only approved models should be published to the Collaboration Hub
  • Use the Preview option in the User Settings to view unpublished processes
• Publication includes communication to stakeholders
• Liaise with the Training team to ensure that training materials are updated to reflect new/changed processes.

Dictionary Management and Reusable Components

Dictionary and Glossary Management

• A centralized business Dictionary in is maintained Signavio Dictionary
• Link process elements to dictionary entries for consistent terminology
• Dictionary categories organize business terms by type
• Dictionary entries must include: 
  • Clear definition
  • Example(s) of usage
  • Owner/responsible party
  • Related business rules (when applicable)

Document Management

• Link relevant documents to process models using the document linking feature
• Use consistent document categories: 
• Process policies
• Work instructions
• Forms and templates
• System documentation
• Regulatory requirements
• Document references must include: 
• Document name
• Document type
• Version/revision number
• Location/system of record
• Owner/responsible party

More detail to be added by 09 May.

Change Management

Change Requests

• Document requested changes using the Syensqo change request process 
• Assess impact on related processes and systems
• Obtain approval from process owner before implementation

Revision Cycles

• Update models when business processes change
• All change requests and their status should be tracked

Archiving

• Archive obsolete processes rather than deleting them
• Archived processes by moving them to the 07. Process Archives folder
• Document reason for archiving and replacement processes (if applicable)

Collaboration Hub

More detail to be added by 09 May.

Change log

Workflow history