A spreadsheet, a legacy departmental database or a prototype built with AI already holds real rules and criteria validated in day-to-day use. That work is recovered and turned into a process with forms, tasks, owners, integrations and an operating model the organization can sustain.
01 · The problem
A team built what it needed: a spreadsheet holding the approval rules, a local database with years of requests, an internal procedure, or a prototype assembled to test an idea. Those pieces solve a real problem, and they hold criteria nobody else ever wrote down.
The approval rules live in Microsoft Excel formulas that only one person can read; the history sits in a Microsoft Access database with no documented backup; the procedure is spread across Microsoft SharePoint lists and email threads, with a separate copy of the file for each person. The Microsoft Power BI dashboard shows the backlog: it reports status, but it does not assign the work or leave a record of who approved what.
The business area can no longer change a rule without asking someone for a favor. IT takes support calls on something it never designed, with no documentation, no test environment and no way to answer for its availability.
The starting point is not a mistake. It is a ceiling: what stopped scaling is not the rules, it is the operation built around them.
02 · The solution
The work starts by recovering what already works: which fields users complete and how each is validated, which conditions trigger an approval, and which exceptions are still handled by hand. That content is worked through with the team that uses it and checked against the historical cases held in the application. No rule is migrated automatically: a rule nobody can explain is recorded as an open decision rather than copied blindly.
The flow is then redesigned on top of those rules: forms with the agreed validations, tasks with an owner and a deadline, authorizations by rule and by amount threshold, and statuses that separate what was requested from what was executed. BPMflow runs the workflow — cases, assignment, deadlines, authorizations and evidence. The Operational Graph supplies the surrounding context — legal entity, business area, responsible role and the documents that apply — so the rules rest on current definitions approved by the organization rather than on a copy buried inside a form.
When what needs modernizing is a repository of process or architecture models — diagrams, legacy notations, attributes and relationships — the route is a different one: Legacy Modernization and Process Knowledge. When the process starts from a deviation that today shows up only on a dashboard, the way in is From Reporting to Action.
03 · Starting points
The starting point changes how much can be reused on day one, not where the work ends up. And it does not always start from something already built: the same approach applies to creating a capability that does not exist yet, or to replacing a legacy application whose scope is already well understood.
The calculations and the criteria live in the spreadsheet; everything else happens over email.
What is kept
The criteria, the calculations and the categories the team has already validated in day-to-day use.
What changes
A single instance of each case, with a named requester, reviewer and authorizer, and no parallel copies to reconcile.
Forms, logic and years of data, with permissions that accumulated one exception at a time.
What is kept
The historical data and the logic that still holds; the application can keep running through the transition.
What changes
What is kept, what is adapted and what is replaced is decided as part of the scope, with permissions reviewed and every integration documented.
It works, but nobody today can change it or answer for its availability.
What is kept
Its real scope: what it resolves, who depends on it, and what happens if it becomes unavailable.
What changes
An owner is assigned for operations and ongoing change. The scope is then either sustained or replaced by an explicit decision, never by neglect.
It already demonstrates the idea; what is missing are the conditions to run it day to day.
What is kept
How the flow was designed, the product decisions behind it, and what the team learned while testing it.
What changes
Integrations, permissions, error handling and testing are completed, and a support model is put in place. The prototype is not thrown away.
04 · Capabilities
The business area gets back the ability to change a rule through an agreed procedure, and IT takes on an application that comes with documentation, permissions and named owners. Max answers questions about a case within the authorized context: it shows the status, the evidence on record and the rule that was applied.
Fields, validations, approval conditions and exceptions are worked through with the team that uses them, and checked against the historical cases already held in the application.
Forms with the agreed validations, tasks with an owner and a deadline, and statuses that distinguish what was requested, what was authorized and what was confirmed.
The process pulls in the context it needs and writes the outcome back where it has to be recorded, with the confirmation agreed for each step.
If a system does not respond or a value fails validation, the case records and keeps an open issue visible, with an owner and a route to retry or resolve it manually.
The new scope can run alongside the current application, with an agreed cut-over criterion, testing on cases from the current period and a rollback plan.
The agreement records who operates the process, who changes a rule, how that change is approved and what happens to the cases already in progress.
05 · Roles
Provides the rules and decides which ones still apply.
What they see
The process with its rules written out, the cases in progress and the open items in their area.
What they do
Explains how the work is done today, agrees which rule gets implemented, and requests later changes without depending on one individual.
Knows the detail that was never written down.
What they see
The recovered rules, and the cases where current behavior does not match what was written down.
What they do
Corrects the interpretation, supplies the history, and validates the flow against past cases.
Takes on what IT cannot support today.
What they see
The agreed integrations, the permissions, the environments and the open technical items in scope.
What they do
Agrees on access and approved source systems, participates in testing, and accepts the process handover with its documentation and support model.
Does the day-to-day work.
What they see
Their own tasks, the committed deadline and what information each case is still missing.
What they do
Completes the form, addresses review comments and provides the confirmations assigned to them.
06 · Implementation
The application in use today, its recent cases and the team that operates it are enough to start: no prior architecture project and no complete process documentation are required.
1 · Agree scope and outcome
Which rules stay exactly as they are, which ones need to be revisited and reapproved, who authorizes, and what counts as a confirmed outcome.
2 · Recover the rules and connect the sources
Fields, validations and exceptions are drawn out of the current application and its historical cases; the context sources and the system that records the outcome are agreed.
3 · Test, run in parallel and hand over
The process is tested with cases from the current period, rules and deadlines are tuned, the cut-over criterion is agreed, and the client team takes over day-to-day operation.
Illustrative example
The database holds the form, the numbering, the amount calculation and an approval rule by amount threshold that only its author fully knows; the authorization sits in email. The redesigned flow keeps the form and the thresholds, records them as rules of the process, and connects them to the legal entity, the cost center and the owner currently responsible.
The exception that matters appears when the amount changes after approval. The case does not start over. If the revised amount crosses a threshold, the case is routed to the authorizer for the new approval band, while the earlier approval and its rationale remain on record. Through the transition the database stays available read-only until the open cases finish on the old route. Closure is confirmed by the record returned from the system where the investment has to be booked.
The example describes how a scope is framed. It does not describe an existing deployment.
07 · Typical scenarios
A low-volume process still justifies the work when the cost of an error is high, or when the operation depends on a single person.
A departmental application is modernized when its rules are explicit, the process has named owners, and the outcome is confirmed where it belongs. The practical way in is one specific process, starting with the rule only one person can explain.
Departmental Application Modernization is an EAFlow cross-industry solution on the Operational Graph, supported by BPMflow automation capabilities. Legacy Modernization and Process Knowledge cover model repositories; From Reporting to Action covers a deviation spotted on a dashboard. The examples on this page are illustrative.
