Your back office, your choice

Over the years, more and more of how an organisation works ended up inside its systems. A process became a workflow in the ERP. A responsibility became an authorisation profile. A business rule became configuration, or custom code. A collaboration between departments became a chain of statuses and interfaces.

As long as the work stays the same, nobody notices. You notice when you want to change. A new service, a partner you want to work with, a different way of planning: suddenly it isn’t only the organisation that has to change, but the CRM, the ERP, the interfaces and the integrations too. Even when everyone knows what has to be different, it can take months before the software follows.

We chose software to support the organisation, and ended up adapting the organisation to the software.

That doesn’t mean your systems have to go. An ERP is excellent at financial transactions. A CRM keeps customer data. A planning system calculates capacity, an archive keeps documents. Rebuilding all of that would be pointless, and expensive.

What changes is the place those systems have. They stop being where your way of working is decided, and become what they are good at: suppliers of data and services.

The new service, the work with a partner, the process that keeps changing: you build that in CaseFlows, as a layer on top of what you have. The caseflow describes how the work goes, who does what, and what each role sees. The data and services it needs come from the systems you already have. People and AI use those same services, within the responsibilities and permissions the caseflow defines.

The caseflow organises the work. The back office supports it. Not the other way round.

The obvious alternative is to stay where you are: configure another workflow into the ERP, add a workflow tool next to it, or have AI build a custom application for the new process. Each of those can work, and each is quicker to start.

But each lays your way of working down in an application again. The next change runs into the same wall: someone has to find where the rule lives, change it there, and test what it touched. With AI-built custom code that happens faster, but the way of working ends up in code that nobody reads before it runs.

In CaseFlows the way of working is in a specification you own and can read, which the runtime executes as written; your systems keep doing what they are good at. The difference shows in the second and third change, not the first.

We don’t have figures yet that show what that saves compared with extending; that is what the first pilots are meant to measure.

The caseflow doesn’t talk to your CRM directly. It works with its own concepts: a customer, an opportunity, a quote, each with a fixed meaning. And it asks for services: look up this customer, give me the hours on this project.

Between those and your systems sits a connector per system. It translates what the system calls things into the concepts the caseflow works with. Gripp’s offer becomes an opportunity with a stage; a different CRM would get its own connector into the same opportunity.

That middle layer is what makes the rest possible. The process depends on the meaning of a customer, not on the screens and fields of one particular product.

Two systems that both think they own the customer record is how integrations go wrong. So before anything is built, you decide per concept which system is the source.

Usually the back office stays the source where it is strongest and where rules apply, such as the accounts. CaseFlows records the operational work: the case, who did what, and why. Where the two overlap, such as a customer or an employee, you agree which side leads, and the connector keeps the side that follows up to date.

Romion Health keeps its offers, projects and hours in Gripp, and its accounts in Moneybird. Both stayed. On top of them, CaseFlows runs the sales work:

1. An opportunity is registered in Gripp, or started in CaseFlows when it doesn’t exist in Gripp yet.
2. The sales pipeline in CaseFlows organises the follow-up: the stage, the next step, the probability, who is on it.
3. The quote, its amount and its status come from Gripp.
4. When the client accepts or rejects the quote in Gripp, the opportunity moves to won or lost by itself.

Alongside that, the financial overview takes its figures from Moneybird. Offers and figures no longer have to be typed over from one system into another.

And Romion has decided to go one step further: Gripp will be phased out over time, one part at a time. The pipeline already runs in CaseFlows, and new opportunities can start there. Quotes, projects and hours still come from Gripp for now; each of those moves when it is ready, without the sales process having to be redesigned. The full phase-out hasn’t been shown yet; what has been shown is the pipeline.

Not every back-office system needs replacing. Many will keep doing their job for years, while CaseFlows organises the new work around them. That is how it runs today.

Others reach the end of their useful life. Because the caseflow describes how the work is organised, changing a back-office system then doesn’t automatically mean redesigning the process. A replacement still has to supply the data and services the caseflow depends on, and that takes work: a new connector, and a translation into the same concepts. But that work can be done separately from the process, and one concept at a time.

The first route runs in production today. The second is under way at Romion Health, which is phasing out Gripp concept by concept. It isn’t finished yet, so we can show the route, not yet the end of it.

You don’t have to model or replace your systems first. You start from one process:

1. Choose the process you want to improve.
2. Read, through a connector, which data and services your systems already have for it.
3. Decide which concepts the caseflow needs, and which system is the source of each.
4. Build the caseflow and connect it to those systems.
5. Walk through real scenarios on the development environment before anything goes to production.

Reading real data on the development environment shows what is really in your systems, not what the documentation says. That environment is your organisation’s own, behind the same sign-in and the same roles: who may see what there follows the same rules as in production.

Runs today

• Gripp and Moneybird connected in production at Romion Health, with the pipeline, quotes and financial overview built on top.
• Other systems connected as services, such as a database platform and a learning management system.
• Connectors that translate a system into the concepts the caseflow works with, with an agreed source per concept.
• New connections read on the development environment before anything is built on them.

Where we’re heading

• Phasing out a back-office system concept by concept, without redesigning the process: under way at Romion Health, where Gripp is being phased out. The pipeline has moved; quotes, projects and hours are next.
• More systems that can be connected without new work for each one.