DEV Community: Crismo Team

How to Share Process Models with Non-Technical Stakeholders

Crismo Team — Sat, 20 Jun 2026 11:08:50 +0000

You spent hours modeling a process. The BPMN is clean, the swim lanes are organized, and the decision logic is airtight. You send it to the operations manager for review.

Silence.

A week later you follow up. The response: "I looked at it but I did not really understand the symbols. Can you just explain it to me?"

This is the stakeholder alignment gap. Process analysts speak BPMN. Most stakeholders do not. And yet stakeholder buy-in is what determines whether a process improvement actually gets implemented.

The methodology side of stakeholder alignment is covered in detail in the ProcessCamp stakeholder alignment guide. This post shows you how Crismo makes the sharing and collaboration part practical.

The Problem: BPMN Is Precise but Not Accessible

BPMN is an ISO standard for good reason. It removes ambiguity from process documentation. But that precision comes with a learning curve. Exclusive gateways, intermediate catch events, message flows between pools. These concepts take time to learn.

Your stakeholders should not need to learn them.

What they need is a way to see the process, understand their part in it, and tell you when something is wrong. Crismo is built for exactly this workflow.

View-Only Sharing: Give Access Without Risk

Crismo lets you share any process model via a view-only link. The recipient can:

See the full diagram in their browser (no account required)
Zoom in on specific sections
Click on elements to see descriptions and annotations
Navigate between process levels if you use L0/L1/L2 landscapes

What they cannot do: move elements, delete anything, or break the model. This is the key distinction. Stakeholders get visibility without the risk of accidental edits.

For organizations that need tighter control, Crismo workspaces let you set permissions per role. Analysts can edit. Managers can comment. Executives can view. Each person sees the same model with different capabilities.

Comments: Feedback Where It Matters

When a stakeholder reviews a process model, their feedback is most useful when it is attached to a specific step. "Step 4 is wrong" is more actionable than "something in the middle seems off."

Crismo supports comments directly on process elements. A team lead can click on a task, leave a comment like "This step actually takes 2 days, not 2 hours," and the process analyst sees it in context.

This eliminates the round-trip of exporting a PDF, emailing it, getting feedback in a separate email thread, and trying to match vague descriptions to specific diagram elements.

Embedded Diagrams: Bring the Process to Where People Work

Many organizations lose stakeholder engagement because the process model lives in a tool that stakeholders never open. The model sits in a specialized BPM platform while the team works in Confluence, Notion, or SharePoint.

Crismo lets you embed process diagrams directly into the tools your team already uses. An embedded diagram stays in sync with the source model. When the analyst updates the process, the embedded version updates automatically.

This means stakeholders encounter the process model during their normal work, not only when someone sends them a link.

A Practical Workflow: From Model to Sign-Off

Here is how teams use Crismo to move from a finished model to stakeholder approval:

Model the process in Crismo using BPMN. Add descriptions to key elements so non-technical viewers understand what each step means.
Generate a view-only link and share it with reviewers. Include a short message: "Please review the process below. Click on any step to see details. Leave comments on anything that looks wrong or incomplete."
Collect feedback through in-context comments. Resolve each comment by updating the model or responding with an explanation.
Share the final version with decision makers. For executive stakeholders, pair the link with a one-paragraph summary of what changed and why.
Embed the approved model in the team wiki or project documentation so it stays visible and current.

This workflow maps directly to the stakeholder alignment framework described in the ProcessCamp guide: share after discovery, co-create during design, get explicit sign-off before implementation, and close the loop by making the final model accessible.

Why This Matters for Process Adoption

The best process model in the world is useless if the people who execute it have never seen it, or saw it once and could not understand it.

View-only sharing removes the access barrier. Comments remove the feedback barrier. Embedded diagrams remove the visibility barrier.

The result: stakeholders stay engaged, feedback flows in context, and process improvements actually get implemented instead of collecting dust in a modeling tool.

Try It

You can explore Crismo's modeling and sharing features in the free playground. No account required. Build a simple process, generate a share link, and see how it looks to a non-technical reviewer.

For the full methodology on stakeholder alignment, read the ProcessCamp stakeholder alignment guide.

From Interview Notes to BPMN: The Crismo Discovery Workflow

Crismo Team — Sat, 20 Jun 2026 11:08:14 +0000

Discovery workshops are where process knowledge lives. Someone explains how work gets done, and a facilitator captures it in notes, recordings, or sticky notes on a wall.

The problem comes afterward. Turning those raw notes into a clean BPMN diagram takes hours or days. Details get lost. The modeler interprets what they remember instead of what was said. By the time the diagram is done, half the nuance from the original conversation is gone.

Crismo's AI discovery feature closes that gap. You paste a transcript, and the system extracts tasks, decisions, roles, and handoffs into a structured BPMN draft. Not a finished model. A draft that captures the right structure so you can refine instead of rebuild.

The problem with manual translation

Every process modeler has been through this cycle:

Run a 90-minute discovery session
Take notes (or record the session)
Go back to a desk and try to reconstruct the process from memory and notes
Realize the notes are ambiguous on three key decision points
Schedule follow-up calls to clarify
Finally produce a diagram, days later

The translation step, from notes to diagram, is where most information loss happens. It is also the most tedious part of the job. The discovery conversation was rich and specific. The notes are sparse and ambiguous. The modeler fills the gaps with assumptions.

How AI discovery works in Crismo

The workflow is three steps.

Step 1: Paste the transcript

After a discovery workshop, you have raw material: interview notes, a meeting transcript, a voice recording transcript, or even bullet points from a sticky-note session.

Open Crismo and paste the text into the AI discovery panel. The system accepts unstructured text. It does not need a specific format or template.

Step 2: Review the extracted structure

Crismo's AI analyzes the text and extracts:

Tasks with descriptive names (not generic labels like "Step 1")
Decision points where the text describes branching logic ("if the amount exceeds 10,000...")
Roles and participants mentioned in the conversation
Handoffs between people or systems
Start and end conditions for the process

The result is a structured BPMN draft displayed on the canvas. Elements are positioned, connected with sequence flows, and assigned to lanes where the transcript mentions specific roles.

Step 3: Refine the draft

The AI-generated draft is a starting point, not a finished product. You will need to:

Adjust naming to match your organization's terminology
Add exception paths that the transcript only hinted at
Split or merge tasks where the AI grouped things differently than you would
Validate the model against what participants actually said

This refinement takes 15 to 30 minutes instead of the hours you would spend building from scratch.

When this works best

AI discovery is most useful when:

You have a transcript or detailed notes from a real conversation (not a theoretical process description)
The process has 10 to 30 steps with clear roles and decisions
You want a first draft fast so you can iterate with stakeholders
Multiple discovery sessions need to be modeled and you are short on time

It is less useful when:

The source material is a single paragraph or a few bullet points (too little context for the AI to extract structure)
The process is highly technical with system-level detail that requires domain expertise
You already have a clear mental model and just need to draw it

A practical example

Imagine you ran a discovery workshop for an employee onboarding process. A participant described the flow like this:

"When we get the signed contract back from the new hire, HR creates their profile in the system. Then IT gets a ticket to set up the laptop and accounts. At the same time, facilities assigns a desk. Once everything is ready, the manager sends a welcome email with the first-week schedule. If the new hire is remote, we skip the desk assignment and ship the laptop instead."

Paste that into Crismo. The AI extracts:

Start event: Signed contract received
Tasks: Create HR profile, Set up laptop and accounts, Assign desk, Send welcome email, Ship laptop
Parallel gateway: IT setup and facilities assignment happen concurrently
Exclusive gateway: Remote vs. on-site determines desk assignment vs. laptop shipping
Roles: HR, IT, Facilities, Manager
End event: Welcome email sent

The draft lands on the canvas with lanes for each role, parallel paths for concurrent work, and a decision point for the remote/on-site split. You refine the naming, add an exception path for missing equipment, and the model is ready for review.

From discovery to documentation

The AI discovery feature fits into a larger workflow:

Prepare using the process discovery workshop guide on ProcessCamp to structure your session
Run the session and capture a transcript or detailed notes
Paste into Crismo to get a structured BPMN draft in seconds
Refine the draft with your domain knowledge
Validate by sharing the model with workshop participants
Iterate using as-is/to-be modeling to design improvements

The guide on ProcessCamp covers steps 1 and 2 in detail: how to scope the session, who to invite, which questions to ask, and how to structure the 90 minutes. Crismo picks up at step 3.

Try it yourself

Open the Crismo playground and paste any process description. No account required.

Open the playground

Start with a real transcript from your last discovery session. Or use the onboarding example above. See what the AI produces and how much editing time it saves compared to building from scratch.

How Teams Use Crismo to Harmonize Processes Post-M&A

Crismo Team — Sat, 20 Jun 2026 11:07:23 +0000

After a merger, every process area has two versions. Order management works one way in Company A and another way in Company B. Both are documented (hopefully) in different tools, different formats, and different levels of detail. The integration team needs to see both, compare them, and design a harmonized target state.

This post walks through how teams use Crismo to bring that work into a single workspace. For the methodology behind process harmonization (when to harmonize, how to prioritize, common mistakes), read the comprehensive guide on ProcessCamp.

The Problem: Process Documentation in Silos

Most post-merger integration teams face the same situation:

Company A has processes in Visio, SharePoint folders, and the heads of a few key people
Company B has processes in Confluence, some in draw.io, and a handful in an enterprise BPM tool
Nobody has a complete landscape view of either organization
The integration deadline is measured in weeks, not months

The first challenge is not harmonization. It is visibility. You cannot compare what you cannot see.

Step 1: Create Separate Workspaces for Each Entity

In Crismo, start by creating two workspaces: one for Company A and one for Company B. Each workspace represents one organization's process landscape.

This separation is deliberate. You want to preserve each organization's process documentation as-is before making any harmonization decisions. Mixing them too early creates confusion about what belongs to whom.

Step 2: Import from Multiple Sources

Crismo imports BPMN files from any standards-compliant source. For non-BPMN formats:

Visio diagrams: Export from Visio and convert using the free Visio converter
draw.io files: Use the draw.io converter to produce BPMN XML
Undocumented processes: Use AI Discovery. Paste interview notes or a process description and Crismo generates a BPMN draft

For each import, place the diagram in the correct L1 process group within the workspace. The landscape structure tells you where everything belongs.

If neither organization has a formal landscape, build one. Crismo's landscape view makes this straightforward: create L0 areas ("Order to Cash", "Hire to Retire"), then add L1 groups within each area. Even rough groupings are enough to start the comparison.

Step 3: Compare Side by Side

With both workspaces populated, the integration team can now compare:

Open Company A's "Order Processing" diagram in one view
Open Company B's equivalent in another
Look for structural differences: approval chains, decision logic, role assignments, system touchpoints

In Crismo, both diagrams are real BPMN models. That means the comparison is structural, not just visual. You can see that Company A routes orders through a 3-level approval while Company B uses a single threshold-based check. You can see that Company A handles returns as a separate process while Company B handles them inline.

These structural differences are exactly what the harmonization framework from the ProcessCamp guide helps you evaluate.

Step 4: Build the Target State

Create a third workspace: "Target Operating Model" (or whatever your organization calls the harmonized state). For each process area, create the to-be version:

Start with the stronger of the two as-is processes
Incorporate elements from the other where they add value
Adjust roles and responsibilities for the combined organization
Document the rationale for key decisions (why this approval chain, why this system)

Crismo's collaborative editing means the integration team, process owners from both entities, and subject matter experts can work on the target model simultaneously. Comments and version history capture the reasoning behind design decisions, which matters when someone asks "why did we do it this way?" six months later.

Step 5: Track Progress Across the Landscape

The landscape view in Crismo shows the harmonization status at a glance:

Which L1 process groups have target-state models?
Which are still in comparison mode?
Which have not been started?

This is the integration PMO's dashboard. Instead of tracking harmonization progress in a spreadsheet, the landscape itself tells the story. Leadership can see which areas are on track and which need attention.

When This Approach Works Best

Crismo's workspace model is designed for scenarios where:

Multiple sources of process documentation need to coexist during analysis
Teams from different organizations need to collaborate on shared models
The integration timeline requires fast import and comparison, not months of manual redrawing
Process landscapes need to be visible to non-technical stakeholders (executives, PMO, auditors)

For large-scale enterprise integrations with thousands of processes and complex governance requirements, dedicated enterprise platforms like ARIS or SAP Signavio may be a better fit. Crismo works well for mid-market integrations and for specific process areas within larger deals.

Try It

Open the Crismo playground to explore the workspace and landscape features. No signup required.

For the full harmonization methodology, read the Process Harmonization Guide on ProcessCamp.

Process Governance in Crismo: Owners, Reviews, Versions

Crismo Team — Sat, 20 Jun 2026 11:07:19 +0000

Process documentation without governance decays fast. Diagrams drift from reality, nobody knows which version is current, and ownership is unclear. Within months, the process library becomes a collection of historical snapshots that nobody trusts.

Crismo builds governance into the modeling workflow. Process ownership, version history, review tracking, and permissions are part of the tool, not a separate spreadsheet or checklist. This post walks through how each piece works.

For the methodology behind process governance (how to assign owners, set review cadences, track maturity), see the Process Governance Playbook on ProcessCamp.

Process Ownership in the Landscape View

Governance starts with ownership. In Crismo, ownership is assigned at the process group level (L1) within the landscape. Each L1 group has a named owner who is accountable for all diagrams inside that group.

To assign an owner:

Open your workspace and navigate to the landscape view
Click on any L1 process group (for example, "Order Processing")
In the group settings, assign a team member as the process owner
The owner's name appears on the group card in the landscape view

When a new diagram is created inside a group, it inherits the group owner. No orphaned processes. No diagrams that belong to nobody.

This matters because ownership at the diagram level does not scale. With 50 or 100 diagrams, tracking individual ownership becomes a full-time job. Group-level ownership keeps things manageable: 10 to 15 owners for the entire organization instead of ownership scattered across every file.

Version History: Every Change Tracked

Every save in Crismo creates a version. There is no manual versioning, no naming conventions to follow, no risk of overwriting someone else's changes.

The version history panel shows:

A timeline of every change to the diagram
Who made each change and when
A visual diff between any two versions
The ability to restore any previous version with one click

This is critical for governance. When a process owner runs a review, they can see exactly what changed since the last review. They do not need to rely on memory or ask the modeler "what did you update?" The history is there.

For audits and compliance, version history provides the evidence trail that regulators expect. You can show that a process was reviewed on a specific date, what changed, and who approved the change.

Review Tracking

Crismo tracks the review status of each process group:

Last reviewed date: When the process owner last confirmed the documentation
Next review due: Based on the review cadence set for the group (quarterly, semi-annual, or annual)
Review outcome: Confirmed (no changes needed), Updated (changes applied), or Flagged (needs redesign)

The workspace dashboard surfaces overdue reviews. Process owners see which groups need attention. The process excellence lead sees the full picture across all groups.

This removes the most common governance failure: reviews that are scheduled but never happen. When the tool tracks review status visibly, overdue reviews become visible to the team and to leadership.

Permissions: Who Can Edit What

Not everyone should be able to edit every process. In a governed environment, process owners control who can modify diagrams in their group.

Crismo's permission model works at two levels:

Workspace level: Control who can access the workspace at all. Invite team members, consultants, or auditors with specific roles.

Group level: Within a workspace, process owners can restrict editing to specific people. Others can view and comment but not modify diagrams.

This prevents the common problem of well-intentioned edits that break a reviewed process. If a team member notices something wrong, they leave a comment. The process owner reviews the comment and makes the change (or delegates it to the assigned modeler). The review trail stays clean.

For organizations with compliance requirements, permissions also enforce separation of duties. The person who models the process is not the same person who approves it.

Maturity Tracking Across the Landscape

Each process group in Crismo can be tagged with its maturity level:

Ad hoc: Not yet documented
Documented: BPMN diagrams exist but no review cycle
Governed: Owner assigned, reviews on schedule, versions tracked
Optimized: Performance metrics defined, continuous improvement active

The landscape view shows maturity as a color-coded indicator on each group card. At a glance, you see which areas of the organization are well-governed and which need attention.

This creates the maturity heat map that process excellence leads need for prioritization and leadership reporting. Instead of building the heat map manually in a spreadsheet, it updates automatically as you assign owners, run reviews, and model processes.

Sharing for Stakeholder Review

Governance reviews often involve people who do not model processes: department heads, compliance officers, subject matter experts. These people need to see the process and provide feedback without learning a BPMN editor.

Crismo supports sharing process models with view-only access. Share a link to a specific diagram or to an entire process group. Recipients see the model, can leave comments, and can confirm that the documentation matches reality.

No license required for reviewers. No software to install. This removes the friction that kills review participation in tools where every reviewer needs a seat.

Putting It Together: The Governance Workflow

Here is how the pieces work as a connected workflow:

Build the landscape with L0 and L1 structure (see Build Your Process Landscape in Crismo)
Assign owners to each L1 process group
Set review cadence per group (quarterly for high-change, annual for stable)
Model L2 processes within each group, with version history tracking every change
Run reviews on schedule: owner walks through the model with performers, records the outcome
Track maturity across the landscape to prioritize investment
Share with stakeholders for validation without requiring tool access

Governance is not a separate activity. It is part of the modeling workflow. Every time you open Crismo, the landscape shows you ownership, review status, and maturity. Governance becomes visible instead of invisible.

Try It

Open the Crismo playground to see the landscape view, version history, and collaboration features. No signup required.

For the complete governance methodology (ownership models, review frameworks, maturity assessment), read the Process Governance Playbook on ProcessCamp.

BPMN Is the AI Interface That Nobody Ever Had to Build

Crismo Team — Sat, 20 Jun 2026 11:06:52 +0000

I pasted a BPMN process model into Claude last week. 14 tasks, 3 gateways, 4 lanes. It understood every element. It identified the approval bottleneck. It suggested parallelizing two tasks that were unnecessarily sequential.

No plugin. No API key. No custom connector. Just a standard BPMN XML file and a standard language model.

That should not be surprising. But based on the marketing I see from newer process tools, it seems to surprise a lot of people.

BPMN Is Already in the Training Data

BPMN 2.0 is ISO/IEC 19510. The specification has been publicly available since 2011. Thousands of tutorials, millions of XML examples, decades of academic papers, Stack Overflow threads, Udemy courses (including mine, with 40,000+ students), all of it is part of the corpus that every major LLM has ingested.

When you export a process model as BPMN XML, the element names are meaningful: userTask, exclusiveGateway, parallelGateway, sequenceFlow, messageFlow. An LLM does not need a translator. The notation is self-describing.

This is not a feature someone built. It is a property of using a standard that has been documented publicly for over a decade.

The Adapter Problem

Some newer process tools use proprietary formats to store process models. The element names are internal IDs. The structure is undocumented. The schema has never appeared in any public training data.

When these tools want AI to understand their processes, they need to build an adapter: an MCP connector, a plugin, an API translation layer. They are solving a problem that their choice of format created.

With BPMN, the standard is the adapter. The format is the interface.

This is not a small distinction. Building and maintaining a custom connector means depending on a vendor to keep it working. Every time the AI landscape shifts, every time a new model comes out, someone at that vendor needs to update the integration. With BPMN, every new model arrives already trained on the standard.

From Readability to Integrated Workflow

Native AI readability is the foundation. But a foundation is not a workflow.

Pasting XML into a chat window proves that AI understands BPMN. It does not give you visual feedback on the canvas, version history, team collaboration, or the ability to iterate on a model without leaving your modeling environment. The gap between "AI can read this" and "AI helps me work with this" is where integrated tooling matters.

That gap is exactly what we built Crismo to close.

Why This Matters for Tool Choice

If you are choosing a process tool in 2026, this is worth considering. A tool that exports standard BPMN 2.0 XML gives you native AI interoperability as a baseline. A tool with a proprietary format requires you to depend on the vendor's connector.

Portability compounds. Your BPMN files work across Camunda, Signavio, Crismo, ARIS, bpmn.io, and any future tool that speaks the standard. They also work with any current and future AI model. A proprietary file works with one tool and one connector.

The question is not whether AI integration is important. Every vendor agrees on that. The question is whether AI integration should be a feature you wait for or a property your format already has.

For a neutral look at why BPMN matters for AI agents across tools, read the guide on ProcessCamp.

How We Built On This

We built Crismo's AI features on a straightforward bet: that BPMN would be the process language AI understands best.

When someone pastes interview notes, workshop transcripts, or process descriptions into Crismo's AI discovery panel, the system generates a real BPMN 2.0 model: tasks, gateways, lanes, sequence flows, all laid out on the canvas and backed by valid XML. This is not a diagram that looks like BPMN. It is BPMN. Export it, import it into Camunda, paste the XML into Claude for analysis, or keep working in Crismo's collaborative editor.

The AI does not just read the model after it exists. It helps create the model from unstructured input. And because the output is standard BPMN, everything downstream works automatically: validation, simulation, export, further AI analysis.

Other BPMN tools let you export models that AI can read. Crismo also lets AI help you create the model in the first place. The standard works in both directions.

This also means your data is never locked in. If you leave Crismo, your processes leave with you as portable, standards-compliant BPMN files that any AI model can still read and understand.

The Best Infrastructure Is the Kind You Do Not Build

BPMN's value as an AI interface was never planned. Nobody at the Object Management Group in 2011 was thinking about large language models. It is an emergent property of being a well-documented, widely-adopted open standard.

If you want to see the integrated version, open the Crismo playground and describe a process. The AI generates a BPMN model on the canvas. You refine it visually, collaborate with your team, and export whenever you are ready. That is the difference between a proof of concept and a workflow.

SAP Signavio Pricing Decoded: What You'll Actually Pay

Crismo Team — Sat, 20 Jun 2026 11:06:47 +0000

SAP Signavio doesn't publish prices. The official pricing page tells you to contact sales. That's deliberate, and it's why every Signavio renewal conversation starts from zero - you have no anchor for what "reasonable" looks like.

This post decodes the Signavio licensing structure based on public sources, prospect conversations, and the patterns that show up across teams evaluating alternatives. It won't give you a single number (anyone who quotes you a single number is guessing), but it will give you the structure you need to compare quotes meaningfully and estimate before you ask.

If you're past the estimate stage and looking for a way out without losing your workspace, the free Signavio .sgx converter and migration playbook cover that side of the decision.

The Three Eras of Signavio Pricing

Pre-2021: Standalone SaaS

Before the SAP acquisition, Signavio sold like a typical mid-market BPM SaaS product:

Per-user, per-month pricing
Tiered by user role (modeler vs reviewer vs viewer)
Annual contracts with a small multi-year discount
Quote-based, but reasonably consistent across customers of similar size

Reported list prices in this era ran in the €50-150 per modeler per month range, with reviewer and viewer tiers significantly cheaper. A 50-person workspace with ~10 active modelers and ~40 reviewers might land in the €20-50K annual range.

Nobody loved the contact-sales motion, but the structure was understandable.

2021-2023: Transition Under SAP

After SAP closed the acquisition in early 2021, the rebrand to SAP Signavio took ~18 months. During this transition period, existing customers largely kept their original contract structure on renewal. New customers started seeing the SAP enterprise pattern: longer sales cycles, more stakeholders, bundled offers.

2024-2026: Full SAP Enterprise Model

The current state. SAP Signavio is sold as part of the SAP Business Transformation Suite. What that means in practice:

Contact sales for everything. No published prices, no self-service tier.
Bundled deals. Signavio rarely sold standalone anymore - typically packaged with SAP Process Intelligence (formerly LANA), sometimes with adjacent SAP licenses.
Enterprise contract terms. Multi-year commits, MSAs, procurement workflows that take months.
Volume-based pricing. Tied to SAP's broader commercial framework, where your existing SAP spend influences the Signavio quote.

The shift isn't unique to Signavio - it's the standard pattern when a focused SaaS product gets absorbed into a megasuite.

What's Actually in a SAP Signavio Quote

Based on what teams report seeing in renewal quotes, the line items typically include:

Process Manager (the BPMN modeler)

The core product - what most users think of as "Signavio." Priced per modeler license. Reviewers and viewers have separate tiers, often cheaper but still licensed per seat.

Collaboration Hub

The read-side portal where stakeholders consume published process models. Sometimes included, sometimes a separate line item depending on the contract era.

Process Intelligence

The process mining product (formerly LANA Labs, acquired by Signavio in 2021, then folded into SAP Signavio). Priced based on data volume and number of process miners. Often bundled into Signavio quotes whether you need it or not, especially for SAP customers using S/4HANA event data.

Process Insights

A newer offering that uses pre-built SAP process content for benchmarking. Often included in larger SAP-stack deals.

Process Transformation Suite

The full bundle - Manager + Collaboration Hub + Intelligence + Insights + Governance. This is increasingly the default offer for new enterprise deals, even when the customer only needs the modeler.

SAP Build Process Automation overlap

SAP also sells SAP Build Process Automation (formerly SAP Workflow Management). These products have overlapping capabilities with Signavio for execution-side workflow. Some quotes try to bundle both, which can double-count what you're actually using.

Why Your Quote May Have Climbed

If your renewal quote is meaningfully higher than your current spend, here's what to check:

You moved from per-user to bundled pricing. If your old contract was a clean per-modeler deal and your renewal proposes Process Transformation Suite, you're paying for capabilities you may not use.
You're being right-sized to SAP's customer benchmark. SAP commercial teams price based on company size and total SAP spend, not just the Signavio capabilities you actually need. A €5K per-month deal can become a €15K per-month deal because that's what "a company your size" pays in SAP's framework.
Process Intelligence got added. Signavio Process Intelligence is a powerful product, but it's also expensive. If your team primarily models BPMN and doesn't need process mining tied to SAP execution data, you may be paying for it anyway.
Multi-year discounts evaporated. Your previous contract may have included transition-period multi-year discounts that don't carry forward.
Strategic pricing. SAP knows that switching costs are high (the .bpmn export is lossy, the .sgx converter is new and not widely known), so renewal quotes often reflect that leverage.

How to Estimate Before the Call

SAP won't give you a number until they've talked to you. You can estimate before that:

Rough order of magnitude

For a mid-sized workspace (20-100 active users mixing modelers, reviewers, and viewers), expect SAP Signavio pricing in the €30K-€150K annual range, depending on:

Modeler count (this drives the bulk of the cost)
Whether Process Intelligence is included
Your organization's overall SAP relationship
Geographic region (US deals tend to run higher than EU)

For enterprise-scale workspaces (500+ users, multiple business units, SAP-integrated process mining), six-figure annual deals are common.

What to ask the account team

Modeler count and tier breakdown. What does the per-license price look like for modeler vs reviewer vs viewer?
Standalone Manager pricing. If you only want Process Manager (no Intelligence, no Hub bundle), what does that cost?
Multi-year vs annual. What's the discount for a 3-year commit?
Process Intelligence opt-out. Can you remove it from the quote if you're not using SAP execution data?
True usage data. Ask SAP for your actual modeler count over the past 12 months. If you're paying for 50 modeler seats but only 18 are active, that's a negotiation lever.

Comparable benchmark

Mid-market BPM tools without the SAP overhead typically run in the €5-30 per-user per-month range. Self-service tools with transparent pricing (Crismo's free tier, Lucidchart's flowchart pricing, draw.io's $0) anchor the low end. Enterprise platforms with dedicated process intelligence (Celonis, IBM Process Mining) sit at the high end.

The SAP Signavio Process Manager modeler tier alone, stripped of bundled Intelligence and viewer licensing, often comes in at the upper end of mid-market BPM pricing - but rarely at enterprise process-mining tier prices. The bundling is what drives the larger numbers.

The Real Cost: Not Just the License

License fees are the visible cost. The hidden costs that actually drive evaluations:

Procurement cycle time. SAP enterprise contracts take weeks to months to renew. That's calendar time your team spends on procurement instead of process work.
Implementation overhead. SAP's deployment model assumes consultants. For teams that just want to model, that overhead is dead weight.
Change management. SAP Signavio updates ship on SAP's release schedule, with the testing and approval rituals that imposes.
Vendor management overhead. Multi-vendor SAP relationships require account managers, MSAs, security reviews. A standalone tool from a focused vendor often eliminates this.
Training and modeler licensing churn. As team composition changes, swapping licenses in an enterprise contract is harder than in a self-service tool.

For smaller teams, these hidden costs frequently exceed the license cost difference between SAP Signavio and a focused alternative.

When SAP Signavio Pricing Is Worth It

This post focuses on teams evaluating alternatives. To be honest about when SAP Signavio pricing pencils out:

You run on S/4HANA. SAP Signavio Process Intelligence with S/4HANA event data is genuinely powerful. If process mining tied to SAP execution is core, you're paying for an integration that no alternative can match.
Your organization has a strategic SAP-everywhere mandate. Bundling discounts and unified procurement may make the math work differently for you.
You need DMN, CMMN, simulation, and the full suite breadth. Some alternatives don't cover all of these.
You have regulatory constraints that mandate SAP infrastructure. Some financial services and government customers need a specific vendor profile.

If none of those apply, the math usually favors a focused alternative.

The Migration Path

If your renewal quote doesn't justify itself, the friction has historically been the lossy .bpmn export. Signavio's built-in BPMN export strips the structured glossary, all 41 metadata field definitions, exact docker waypoints, lane geometry, revisions, and cross-diagram links. Without those, "migrating" means re-modeling years of work from scratch.

The .sgx workspace archive preserves all of it. The free Signavio .sgx to BPMN converter parses that archive directly - currently in closed beta, request access via the form on the converter page. The migration playbook covers the 6-phase process from inventory through decommissioning.

If you're earlier in the decision process and want a feature-by-feature comparison with citations from Signavio's own documentation, the Crismo vs Signavio and Crismo vs SAP Signavio pages cover that ground.

A Note on This Pricing Information

SAP doesn't publish Signavio pricing, so everything in this post is reconstructed from public sources, prospect conversations, and patterns reported by teams evaluating alternatives. Your actual quote will depend on factors specific to your organization that we can't see from outside.

If you have access to a recent SAP Signavio quote and want to sanity-check it against an alternative, the comparison pages above include the relevant feature mapping. For a direct conversation about your specific situation, request access via the converter waitlist and mention your workspace size in the email - we'll respond within 48 hours.

Process Mapping with Crismo: From Import to Shared Workflow

Crismo Team — Wed, 22 Apr 2026 08:33:11 +0000

Most teams already have some form of process documentation. It lives in Visio files on a SharePoint drive, in a Lucidchart folder nobody has opened in two years, or in draw.io diagrams scattered across Confluence. The problem is rarely that there is no documentation. The problem is that the documentation cannot be compared, reused, or trusted.

This post walks through how to do process mapping in Crismo end to end. For the neutral methodology first (what process modeling is, which notation fits which situation), start with the Process Modeling Guide on ProcessCamp.

Step 1: Start with a Workspace

In Crismo, every process landscape lives inside a workspace. A workspace represents an organization, a business unit, or a scope of work. The workspace gives you shared context and structure: your processes sit inside a value chain, not in a folder tree.

Step 2: Import What You Already Have

Process mapping rarely starts from scratch. Crismo imports from:

BPMN XML files - any tool that exports standards-compliant BPMN 2.0
Visio diagrams - via a free converter
Lucidchart exports - via a converter
draw.io diagrams - via a converter

Import does not mean perfect translation. Visio and Lucidchart diagrams are often informal flowcharts. The converter produces a best-effort BPMN model that surfaces the ambiguity so you can fix it.

Step 3: Model in BPMN with Workspace Context

Crismo produces valid BPMN 2.0. What makes this different from a generic BPMN editor is the context around the diagram: the process lives in a value chain, elements reference entries from a shared dictionary, the document has an owner, a status, and history.

For a first process map, focus on the happy path: start event, main activities, decisions, end event. Add exceptions in a second pass.

Step 4: Reuse Definitions Across Processes

Process maps accumulate. The same terms appear across all of them: "Customer", "Order", "Fulfillment Team". In most tools these are ad-hoc labels. A rename in one diagram does not propagate.

Crismo includes a workspace dictionary. When an element references a dictionary entry, renaming that entry updates every diagram it appears in.

Step 5: Place Processes in a Value Chain

Individual processes make more sense when they sit in a landscape. Crismo's value chain view lets you lay out L0 segments ("Order to Cash", "Hire to Retire") and assign each process to a segment.

Step 6: Share for Review

Three sharing modes: view-only links, comment access, full collaboration. A process map nobody reviews is a process map that does not get used.

Step 7: Govern and Iterate

Process maps go stale. Every diagram has an owner, a last-updated timestamp, and a version history. Set a review cadence per process; when a diagram crosses its review date, the owner gets a reminder.

When Crismo Is the Right Fit

Fits well when you are mapping more than a handful of processes, multiple people collaborate on the same models, your processes will feed automation or audit evidence, or you want to consolidate Visio, Lucidchart, and draw.io documentation into one place.

Not the right fit for sketching a single diagram for next Tuesday's meeting (draw.io is faster) or replacing enterprise platforms like ARIS or Signavio when you need thousands of diagrams with SOX-grade governance.

The sweet spot: teams of 3 to 300 people who want real BPMN and collaboration without running an enterprise platform.

Try the Crismo playground (no signup) or read the neutral methodology at ProcessCamp.

Process Stakeholder Alignment: Getting Sign-Off Without the Politics

Crismo Team — Mon, 20 Apr 2026 13:15:51 +0000

The hardest part of process improvement is not drawing the diagram. It is getting the people who need to change their work to agree that the change is worth making.

Why most process changes stall

You run a discovery workshop. You produce a clear as-is model. You design an improved to-be state that saves the team hours every week. You present it to leadership. They nod, say "looks great," and nothing happens.

Three months later, everyone is still running the old process.

This is not a modeling problem. It is an alignment problem.

Step 1: Map your stakeholders before you map the process

Before you touch a modeling tool, list every person or group that will be affected by the process change. For each stakeholder, answer three questions:

What do they care about?
What do they stand to gain or lose?
What level of involvement do they need?

Use a simple 2x2 grid: influence on one axis, impact on the other. High influence + high impact stakeholders need co-design. It takes ten minutes and saves weeks of politics.

Step 2: Frame the change in their language

The number one mistake: explaining the process change in process language.

For executives: Focus on outcomes and numbers.
For team leads: Focus on workload and clarity.
For frontline workers: Focus on daily experience. Be honest about what gets harder.
For IT teams: Focus on integration and system impact.

Step 3: Align at the right moments

Alignment is not a single meeting. It is a series of touchpoints:

Before discovery: Set expectations
After discovery: Share the as-is model in plain language
During design: Co-create the to-be state
Before implementation: Get explicit sign-off in writing
After implementation: Close the loop with results

How to handle resistance

Resistance is information about what you missed.

"We tried this before" - Ask what specifically failed. Usually it was the rollout, not the design.
"This will create more work" - Quantify current vs projected workload.
"My team was not consulted" - Own it. Late involvement beats no involvement.
"The current process works fine" - Show the data if it does not.
"I do not understand the diagram" - Translate into narrative. The model is a visual aid, not the deliverable.

Five alignment anti-patterns

The big reveal - Working in isolation then presenting a finished design
Consensus theater - Meetings where everyone nods but nobody commits
The BPMN lecture - Explaining gateway types to people who never asked
Ignoring the silent objector - The person who says nothing but undermines later
Alignment without authority - Getting the team excited without securing the decision maker

Checklist

Stakeholders mapped by influence and impact
Change framed in stakeholder-specific language
Alignment touchpoints scheduled at each phase
Process model translated for non-technical audiences
Sign-off documented in writing
Results reported back after implementation

Read the full guide on ProcessCamp with instructor tips, detailed resistance handling, and FAQ.

The Process Governance Playbook

Crismo Team — Mon, 20 Apr 2026 13:09:20 +0000

Process documentation without governance is a snapshot that goes stale the moment it is published. This playbook gives you the framework to keep processes owned, reviewed, and aligned with how your organization actually works.

Originally published at processcamp.io

Why process governance matters

Every organization has process documentation somewhere. SharePoint folders, Confluence pages, Visio files on a shared drive. The problem is rarely that documentation does not exist. The problem is that nobody maintains it.

After a few months, diagrams drift from reality. People invent workarounds that never make it back into the model. New hires read the documented process and then learn that "we do not actually do it that way."

Process governance is the set of roles, rules, and rituals that prevent this decay. It answers four questions:

Who is accountable for each process?
How often does each process get reviewed?
What happens when a process changes?
How do you know which processes need attention?

The three pillars of process governance

1. Ownership

Every process has a named owner who is accountable for its accuracy, performance, and improvement. Ownership is assigned at the process group level, not at the individual diagram level.

A process owner has five responsibilities:

Accuracy: The documented process reflects how work actually happens.
Performance: The owner tracks whether the process meets its objectives.
Improvement: When gaps appear, the owner drives redesign.
Compliance: For regulated processes, the owner ensures control requirements are met.
Communication: When a process changes, performers need to know.

Process owner vs. process steward vs. process modeler

Role	Focus	Typical person
Process owner	Accountability for performance and design	Department head
Process steward	Day-to-day documentation maintenance	Business analyst
Process modeler	Creating and updating BPMN diagrams	BPM analyst

2. Review cycles

A process review is a scheduled check where the owner and stakeholders confirm that documentation still reflects reality.

Frequency	When to use	Example
Quarterly	High-change, customer-facing	Customer onboarding
Semi-annual	Moderate-change, cross-functional	Order fulfillment
Annual	Stable, low-risk	Fixed asset accounting

A review produces one of three outcomes: Confirmed (matches reality), Updated (changes applied), or Flagged (needs redesign).

3. Process maturity tracking

Level 1 (Ad hoc): Process exists but is not documented.
Level 2 (Documented): Modeled and accessible, but nobody checks accuracy.
Level 3 (Governed): Owner assigned, reviewed on schedule, changes tracked.
Level 4 (Optimized): Performance metrics drive continuous improvement.

Rate each process group on this scale. The result is a maturity heat map that shows where to invest.

Implementation roadmap: 90 days

Days 1-30 (Foundation):

Build or validate your process landscape (L0 and L1).
Assign owners for the 5-10 most critical groups.
Rate maturity for each group.

Days 31-60 (First review cycle):

Run initial reviews for critical groups.
Update documentation where reality drifted.

Days 61-90 (Scale):

Extend ownership to remaining groups.
Set review cadence per group.
Publish maturity heat map to leadership.

Common mistakes

Governance by committee: One name per process group, not a committee.
Treating governance as a project: It is a continuous practice with no end date.
Ownership without authority: Owners need mandate to act on findings.
Reviewing for compliance only: Verify accuracy, not just existence.
Skipping the landscape: Without structure, you cannot assign ownership systematically.

Choosing a tool

Look for: ownership assignment, automatic version history, review tracking, permission controls, and frictionless sharing for stakeholder review.

Read the full guide with FAQ and structured data at processcamp.io/guides/process-governance-playbook.

Process Harmonization After a Merger: A Practical Guide

Crismo Team — Mon, 20 Apr 2026 13:09:08 +0000

After a merger, two organizations bring two sets of processes, two sets of tools, and two sets of assumptions about how work gets done. Without deliberate process harmonization, those differences persist long after the deal closes.

This guide covers the practical framework for harmonizing business processes post-M&A: how to assess both organizations' processes, identify overlaps and gaps, design a target operating model, and manage the transition.

Why Process Harmonization Matters

Most M&A integration plans focus on systems, headcount, and financial consolidation. Process harmonization rarely gets its own workstream until something breaks.

A customer order falls through the cracks because the two fulfillment processes have different approval logic. Finance cannot close the books because procurement runs on different controls. Support tickets get routed to the wrong team because escalation paths were never aligned.

McKinsey estimates that 70% of mergers fail to achieve their projected synergies. Process misalignment is a primary contributor.

What Harmonization Actually Means

Harmonization is not about picking one company's process and forcing it on the other. True harmonization produces three types of outcomes:

Adopt: One organization's process is clearly superior. The other team adopts it.
Merge: Both organizations have strong processes. The target combines elements from both.
Redesign: Neither process works for the combined entity. Something new is needed.

A Step-by-Step Framework

Step 1: Build Both Process Landscapes

Before you can compare processes, you need to see them. Each organization should produce a process landscape at the L0 (value chain) and L1 (process group) level.

Use the same leveling convention for both. If Company A uses "Order to Cash" and Company B calls it "Sales Operations", normalize the naming before comparing.

Step 2: Identify Overlaps and Gaps

Place both landscapes side by side. For each L0 area, ask: does the other organization have an equivalent? You will find full overlaps, partial overlaps, and unique areas.

Step 3: Assess at the Detail Level Where It Matters

Focus the detailed analysis on overlapping process areas that are on the critical path. Typically: order management, customer service, procurement, financial close, and employee onboarding.

Model the as-is state from both organizations using BPMN. Look for differences in approval chains, system touchpoints, exception handling, and roles.

Step 4: Design the Target Operating Model

For each overlapping area, design the to-be state. Involve process owners from both organizations. The people who run the processes daily have context that no integration consultant can replicate.

Resist the temptation to optimize during harmonization. The goal is alignment, not improvement. Get to one stable process first.

Step 5: Plan the Transition

Cover training, migration timeline, parallel-run periods, and rollback criteria. For complex processes, consider phased rollouts by region or business unit.

Step 6: Govern and Iterate

Assign process owners for each harmonized area. Schedule quarterly reviews. Track whether the synergies projected in the deal thesis are materializing.

Common Mistakes

Winner takes all - Forcing the acquirer's processes destroys institutional knowledge
Harmonizing everything at once - Prioritize by business impact
Skipping the landscape step - You cannot compare what you cannot see
Confusing harmonization with optimization - Align first, optimize later
Ignoring culture - Processes carry cultural assumptions about risk, speed, and control

When to Harmonize (and When to Leave Alone)

Harmonize: Customer-facing processes, financial processes, processes tied to shared systems, employee-facing processes with consistency requirements.

Leave alone (for now): Business-unit-specific processes, back-office processes that can run in parallel, processes scheduled for sunsetting, areas with regulatory constraints.

Read the full guide with tools comparison, FAQ, and cross-links: Process Harmonization Guide on ProcessCamp

How to Run a Process Discovery Workshop

Crismo Team — Mon, 20 Apr 2026 13:02:07 +0000

Discovery workshops are where process knowledge lives. Someone explains how work gets done, and a facilitator captures it in notes, recordings, or sticky notes on a wall.

The problem comes afterward. Most process improvement projects fail before the first diagram is finished. Not because the modeling tool was wrong, but because the modeler never talked to the right people, asked the wrong questions, or mapped what they assumed instead of what actually happens.

This guide covers the most common format: a facilitated workshop with 3 to 8 participants.

Step 1: Pick the process and define the scope

Before you invite anyone, decide what you are discovering. A discovery session that tries to cover "everything the operations team does" will produce nothing useful. Pick one process. Give it a name. Define where it starts and where it ends.

Use the trigger-to-outcome pattern: "This process starts when [trigger] and ends when [outcome]."

If the process is large, break it into sub-processes and run separate sessions for each. A 90-minute workshop can usually cover 10 to 20 steps with reasonable depth.

Step 2: Invite the right people

The room needs people who do the work, not just people who manage it. Managers describe the designed process. Frontline workers describe the real one. You need both, but start with the people who do the work.

Aim for 3 to 8 participants. Fewer than 3 and you miss perspectives. More than 8 and the session becomes a meeting where half the room checks email.

Role	Why they need to be there
Frontline workers	They execute the process daily
Team lead / supervisor	They see the bigger picture
Upstream / downstream contact	They hand work in or receive it
Process owner	They are accountable for the process

Step 3: Prepare your questions

Good discovery is structured conversation, not free-form brainstorming.

Opening questions:

"Walk me through what happens when [trigger]. Start from the very beginning."
"Who touches this process? In what order?"
"How do you know when this process is done?"

Drill-down questions:

"What happens if [step] goes wrong? Who handles it?"
"Is there a decision point here? What determines which path is taken?"
"How long does this step usually take? What causes delays?"
"What information do you need to start this step? Where does it come from?"
"Is this step always done the same way, or does it vary?"

Validation questions:

"Let me play it back: [summarize]. Does that match how it works?"
"What did I miss?"
"If a new hire joined tomorrow, what would surprise them about this process?"

The best question for uncovering the real process: "What would you tell a new colleague on their first day?" People drop the official language and describe what actually happens.

Step 4: Run the session (90-minute structure)

Minutes 0 to 10: Frame the scope. State the process name, trigger, and outcome. Confirm participants agree on the boundaries.

Minutes 10 to 50: Walk through the happy path. Ask one participant to describe the process from start to finish. Do not discuss exceptions yet. Park them visibly.

Minutes 50 to 70: Add exceptions and decisions. Go through the parking lot. For each exception, ask: "How often does this happen? Who handles it?"

Minutes 70 to 85: Validate and assign roles. Read the process back to the group. Mark who owns each step.

Minutes 85 to 90: Wrap up. Summarize open questions. Assign who creates the clean diagram.

Step 5: Capture notes in a way that translates to BPMN

Each sticky note or line item should answer: Who does what, when, and what happens next.

Some teams model live during the workshop using a projected BPMN tool. Others prefer sticky notes first and model afterward. Both approaches are valid. The key is that whoever models the result was in the room.

Step 6: Clean up and validate

Within 48 hours of the workshop, produce a clean diagram. The longer you wait, the more context fades. Send it to all participants and ask: "Is this what we discussed?" and "What did we miss?"

Five mistakes that derail discovery workshops

Jumping to solutions. Discovery maps what IS, not what should be.
Inviting only managers. Frontline workers describe the real process.
Boiling the ocean. One process, one session.
No visible capture. Make the model visible throughout.
No follow-up. A workshop without a clean diagram within a week was a wasted meeting.

Discovery workshop checklist

Process name, trigger, and outcome defined
3 to 8 participants invited (including frontline workers)
Opening, drill-down, and validation questions prepared
Capture method chosen (sticky notes, projected tool, or recording)
Happy path mapped before exceptions
Parking lot for improvement ideas
Roles and handoffs marked on the model
Clean diagram produced within 48 hours
Validation review scheduled within one week

FAQ

How many processes can I discover in one workshop?
One. A 90-minute session can cover one process with 10 to 20 steps.

Should I model live during the workshop or capture on sticky notes?
Both work. Modeling live is faster if the facilitator is comfortable with the tool. Sticky notes are better when participants are not familiar with BPMN notation.

What if participants disagree about how the process works?
This is expected and valuable. Document all variants as separate paths. Do not force consensus during discovery.

Can I do process discovery remotely?
Yes. Use a shared screen. Record the session (with consent). Keep remote sessions to 60 minutes.

What is the difference between process discovery and process mining?
Discovery uses interviews to map how people describe their work. Process mining uses system event logs. They are complementary.

Process Landscapes: From Value Chain to Detailed Processes

Crismo Team — Mon, 20 Apr 2026 13:00:14 +0000

A single BPMN diagram tells you how one process works. A process landscape tells you how the entire organization fits together.

The folder-of-diagrams problem

Most process documentation starts the same way: someone models their first diagram, then their tenth, then their fiftieth. Before long you have 50 BPMN files in a folder structure that only one person understands. No overview. No hierarchy. No way to see how a customer order flows from sales through fulfillment.

What is a process landscape?

A structured hierarchy with three tiers:

L0: Value Chain — The 5 to 10 major end-to-end process areas. "Order to Cash", "Hire to Retire", "Procure to Pay". No BPMN at this level.

L1: Process Groups — Each L0 breaks into 3 to 8 named groups. "Order to Cash" becomes Lead Qualification, Order Entry, Fulfillment, Invoicing.

L2: Detailed Processes — The actual BPMN diagrams with pools, lanes, gateways, and tasks.

How to build one (5 steps)

Step 1: Define the value chain (L0)

List the major "noun-to-noun" flows: Lead to Customer, Order to Cash, Idea to Product, Hire to Retire. Use the "X to Y" naming convention.

Step 2: Break down into process groups (L1)

Each L0 gets 3 to 8 process groups. Each group should be assignable to a single process owner.

Step 3: Map detailed processes (L2)

This is where BPMN lives. Do not model everything at once. Start with the most critical processes.

Step 4: Connect the levels

Each L0 links to its L1 groups. Each L1 links to its L2 diagrams. Two clicks from value chain to any process.

Step 5: Validate with stakeholders

Show the L0 to leadership. Ask: "Does this cover what we do?" You will get corrections that make the landscape real.

Common mistakes

Starting with L2 — Build the structure before modeling detailed processes
Too many L0 areas — If you have more than 10, some are L1 groups in disguise
Inconsistent naming — Pick a convention and enforce it
No process owners at L1 — Every group needs an accountable person
Modeling everything at the same depth — Not every process needs full BPMN detail

Which tools support process landscapes?

ARIS — Enterprise, deep process architecture. Expensive.
SAP Signavio — Repository with hierarchies. Enterprise pricing.
Crismo — Landscapes as default. Free tier. Real-time collaboration.
Bizagi — Desktop modeler with grouping. Free tier.

Most open-source editors (bpmn.io, draw.io) work at the individual diagram level and do not support hierarchical navigation natively.

Read the full guide with FAQ and framework details. Part of the ProcessCamp BPMN guides.