Issue

The ERP Rebuild program is explicitly tasked with simplifying and standardising the business processes of Syensqo. This means that the definition, through structured modelling, and ongoing management of business processes is essential not only to the success of the program, but to the ongoing sustainability of the solution. Business processes drive system behaviour, authorisations assigned to users, and operational process KPIs. It is thus important that processes are defined in a structured way using a formal modelling notation, rather than a drawing tool like Visio, so that they can be used as the basis for downstream processes such as the authorisation design.

Recommendation

Background & Context

The ERP Rebuild program seeks to simplify and standardise Syensqo's business processes. The program thus requires a modelling tool which supports the creation of business process models using hierarchical process decomposition approaches: The tool must support modelling of high-level end-to-end value chains which are then iteratively decomposed into increasingly detailed process models. The level of detail increases with each level, until ultimately resulting in "Level 5" process models depicting a task-level flowchart with process steps, decisions, swimlanes for different process roles (i.e. actors), etc. For more details on the levels in a process decomposition, refer to APQC - Understanding the PCF Elements.pdf

Process steps used to perform work, either by manual execution of steps in a system, or automated execution by a background job, must support linking to the application system and executable transaction/function used to execute the step. This is necessary in order to derive application authorisations from the process models and ensuring that business processes are imperative. 

The program intends to use SAP-standard "best practice" process models as a foundation for modelling, and only deviate from these for genuine business reasons. This is aligned with the program charter which explicitly seeks to adopt SAP's standardised business processes; as a result the ability to use SAP's business process models and other collateral in the modelling tool becomes critical. 

During the execution of the ERP Rebuild program and beyond, business representatives and other stakeholders must be able to easily view and comment on business process models. This practically requires an online, browser-based UI where process models can be published by authors, browsed, navigated including by following links and drill-downs to lower levels, and which supports commenting functionality. This requirement also demands a simple and cost-effective licensing model so that broad display-only access can be given without undue cost. 

Assumptions

• Process models should be maintained using BPMN 2.0 (an open industry standard notation for business process modelling) in order to reduce lock-in and ensure processes can be migrated to other tools if needed. 
• Simpler tools with more constrained functionality have a shorter learning curve and thus a higher likelihood of adoption, compared to fully-featured modelling tools that support many different types of models (e.g. ARIS). 
• The deployment of the tool must be simple enough to support the timeline of the ERP Rebuild Conceptual Design phase; tools which are hosted in a Syensqo server are thus not considered. 
• Process models should be widely accessible to Syensqo staff to display, but need only be editable by a relatively small group of people. 

Constraints

Impacts

Business Rules

Options considered

Option A: Bizagi

Bizagi is a SaaS-based process management and automation suite. The product originated as a desktop application for business process modelling targeted at smaller companies which could not justify the large investments in infrastructure, tooling, and skills demanded by ARIS. 

Option B: Signavio

Option C: Celonis

Option D: 

Evaluation

	Option A Bizagi	Option B Signavio	Option C Celonis	Option D
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

See also

Change log

Workflow history