| Status | |
| Owner | WENNINGER-ext, Sascha |
| Stakeholders |
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
Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.
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.
Incumbent Tools
Prior to the commencement of the ERP Rebuild program, Solvay had started to implement Celonis for process mining, process analysis and the creation of some operational reporting dashboards. However no licenses for the business process modelling module had been purchased. Some business processes had been drawn in Visio or other diagramming tools in isolated cases, but without a consistent structure or levelling.
Assumptions
Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited.
- 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
Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.
Impacts
Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.
Business Rules
The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order".
Options considered
List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.
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
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option C: Celonis
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option D: Option Title
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Evaluation
Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.
Option A | Option B Signavio | Option C Celonis | Option D | |
|---|---|---|---|---|
| Criterion 1 |
|
|
|
|
| Criterion 2 |
|  Con |
|
|
| Criterion 3 |  Pro | Con | Con | Pro |
See also
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.
