Hi everyone,
we are currently reflecting on how we best involve stakeholders (e.g. process owners and process managers) while processes are still in draft / under development.
Our current setup separates:
- a “work in progress” database for modelling and refinement, and
- a “published” database for validated and approved processes.
This works well from a governance and clarity perspective. However, our modellers increasingly report that it is difficult to align with stakeholders during the drafting phase, as viewers typically do not have read access to the work‑in‑progress database.
At the same time, we are hesitant to simply grant broad read access to the full WIP database for all viewers, as this comes with a risk of confusion around what is valid and what is not yet agreed.
One idea we are currently considering is a script that runs overnight, granting read access in the WIP database only to the assigned process owner(s) and process manager(s) of a model. This would allow targeted stakeholder feedback without opening the entire database to all viewers.
Before going further, I want to ask the community:
- Do you face a similar situation?
- How do you enable collaboration and alignment on processes that are still work in progress?
- Do you allow stakeholders to access draft models — and if yes, how do you avoid confusion with published content?
- Have you implemented technical or governance patterns (e.g. scripts, dedicated review databases, model status flags, conventions)?
I am interested in learning how others tackle this balance between early stakeholder involvement and clean governance / clarity for consumers.
Thanks a lot in advance for sharing your experiences!
Alexander Cherednichenko on
Hi Olaf,
In my experience, there are basically two common approaches:
Both approaches have their pros and cons. Usually, I explain both options to the client, and then they choose the “lesser evil” for their governance model 😊
If we take your current approach of using two databases, I do not see a major problem explaining this to stakeholders. One database is the officially published repository, where everything is validated, approved, and up to date. The second is the working database, where processes are still under development and temporary or targeted access can be granted for review purposes.
I have not really seen serious confusion from users in such a setup, as long as the message is clear: “this is the published source of truth” vs. “this is the working area”.
Regarding the script you mentioned, I would personally be careful. It sounds elegant in theory, but in practice, it may become more complicated than expected. You would need to maintain logic around assigned process owners, process managers, groups, model moves, deleted assignments, changed responsibilities, exceptions, etc. And there are also risks: somewhere access is not granted when it should be, somewhere too much access is granted, or some old permission remains longer than expected.
For me, the simplest governance pattern is usually based on process statuses + approval / audit dates.
For example, in one setup, we used statuses for Level 4 process models:
Colors were used only for visual identification; the actual status was stored in a custom attribute selected by the process manager. Different clients use different status models — for some, three statuses are enough; for others, they need six or seven.
Typical examples could be:
Then you can generate reporting from this structure:
Even a simple process register with model name, owner, manager, status, approval date, last review date, and next review date already gives a very good overview of what is happening.
This register was generated by custom ARIS scripts and later connected to dashboards, so stakeholders can clearly see which processes are official and which are still in progress.