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)

Signavio Process Manager vs Signavio Collaboration Hub

Signavio Process Manager - Modelling

Signavio is the primary tool used for creating process models via the Quickmodel function, and editing via the BPMN editor. 

A folder structure is displayed on the left hand side of the screen, which is used to navigate the Signavio architecture, including the modular, SyWay process decomposition, as described in the section above. The process process models are maintained in the 02.Shared Documents folder. 

Revisions of process models can be viewed by expanding the pane at the bottom of the window. Use this functionality to compare different revisions of the same model, to revert back to different revisions, and collaborate on best design.

Predefined reports are available via the reporting tab, and diagrams can be exported or printed in various formats.

Signavio Collaboration Hub

Signavio Collaboration Hub is the primary tool for reviewing and sharing process models with a wider audience.

When first launching Collaboration Hub, click your initials in the top right of the screen and select View > Preview to access process models still in the Design phase. The folder structure on the left has tabs for Reports, Favourites, and within Shared Documents, the 02. Detailed Design folder structure seen in the Process Manager view.

Navigate through the folder structure down to level 4, view process models, leave comments for other team members or view Fact Sheets on individual processes for review and learning.

The same Predefined reports are available via the Reports tab, and diagrams and fact sheets can be exported or printed in various formats.

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

Large processes may be candidates for separation into two (or more) smaller level 4 processes.

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

• 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

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
• Interfaces are captured as part of the Custom Development Register in JIRA
• 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 either of the two Custom attributes “Primary Executable”, or "Associated Executable"
  • Only one executable can be assigned to the Primary Executable field. It is the executable that is always required to perform the step.
  • Associated Executables include T codes executed in the background, drill down apps, display apps, any other secondary apps that can be triggered in the execution of the assigned 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")
• The identifier should be before the name in the correct format (full stop at the end of the identifier then a space before the name e.g. 04.01.01.01. Process Invoice)
• 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

Event Labels

• Use past tense for events that have occurred (e.g., "Invoice received") 
• Use to describe multiple outcomes of a process step
• Use descriptive language (e.g., "Payment deadline reached" rather than "Timeout") 
• When used in process integration, the intermediate event should describe the outcome of the final step or steps. It is then copied to the beginning to the next process, where it becomes a starting condition for a path in that process.
• 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
• Release
• POD
• Sub Function
• Main Attributes:
• Name (must match the Folder Name)
• Documentation (Description)

Process Step Metadata

Mandatory Attributes for all Level 5 Process Steps:

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

Custom Attributes to be reviewed as necessary for every Process Step:

• IT System (for User, Service and Script Tasks only)
• Primary Executable
• Associated Executable
• GBS
  • Check this box if the task executed by this process step will be performed by GBS/Share Services.
• Standard
  • 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).
• Syensqo Standard
  • 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 WRICEFUM 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
• Risks
• Related Documents
  • Config. Guides
  • Func. Specs
  • Tech. Specs
  • Input and output documents e.g. Reports
• Loop Types
  • Standard - a User task that can repeated until a different outcome is achieved.
  • Parallel - a Service task that can run many times at the same time
  • Sequential - a Service task that can be repeated many times one after the other

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:

• 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
• Peer reviews performed by Key Users and SMEs
• Technical review by BPM modelling experts from 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)
• Functional teams may only create Dictionary items in respective "Suggestions" folders.
  • These items are reviewed bythe Integration team for suitability and approval.

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)

Change log

Workflow history