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

These are important for employees to understand how their work areas interface with others, and enhanced cross-functional collaboration. 

Standardisation

• Use the consistent modelling patterns, symbols, and layouts described in this document. 
• Apply the same level of detail for similar processes
• Ensure uniform naming and labelling

Following these principles 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 imperative models to be easily read and updated
  • Consider separating large and complex processes into smaller Level 4’s
  • Do not use "optional" processes and tasks - instead model these as different paths in the process using Gateways. 
  • 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
• IT Systems are captured through the integration with LeanIX
• Enhanced collaboration across teams
  • Security requirements are captured through the use of swim lanes
  • Risks and Controls are 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 in 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, one will understand how processes are functionally clustered, including the Process Steps that form the basis of the 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)

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.
• One 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

Overlays

Overlays are created to display different layers of information when viewing a process model. Look for the icon in the top right of the process model window to toggle overlays on and off.

Depending on the size of your window, you may have to click the chevron first to display the remaining ions.

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:
  • 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.
• Identifier

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

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
  • Business review by process owner and any other stakeholders
  • Final approval by SyWay process governance team
• Internal team review performed by Signavio Key User (SKU)
• Technical review by BPM modelling expert from the Integration 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

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

Change log

Workflow history