We build an inventory of your processes, map them as they really are using BPMN 2.0, and define an owner and a measure for each one. We then run them on a process engine (BPMS) and measure cycle time, waiting points and bottlenecks. If a single flow is all you need, we will say that plainly too.
In a company a quote is issued, an order is opened, production is planned, the goods are shipped and payment is awaited. Each link in that chain is run by a unit, and each unit usually knows its own job well. What nobody knows is the time that passes between the links. How many days the quote waited in approval, what happened between the order dropping to production and being planned, why the shipment slipped by a week — none of it is recorded anywhere. When you ask how many days on average you deliver in, the answer given rests on memory rather than measurement, and every unit gives a different number. The problem is usually not in the units' performance but in the gap between them; and that gap has no owner. In most companies, this unmeasured gap is also the source of the most expensive delays.
In these companies the processes are in fact written down. Procedures, flow charts and instructions prepared under ISO 9001 sit in a folder. But the written process and the process that actually runs drift apart over time: one has three approvals, two of which are skipped on the ground; in one the job starts with unit A, when in reality unit B starts it. When the audit comes, the version on paper is defended, and the next day everything goes back to the old order. Digitisation efforts do not fix this on their own either: individual approval flows are built, each runs on its own, and there is no shared rule and no shared measure between them. As the number of flows grows, rules that contradict one another pile up and nobody can see the whole.
Business process management (BPM) is first of all a management discipline: making an inventory of the processes that exist, assigning an owner to each, measuring the process and improving it at regular intervals. BPMS is the software that runs that discipline; it is also called a process engine for short. The engine takes a process modelled to the BPMN 2.0 standard and actually runs it: it drops the task to the right role, escalates it when the time is up, applies the defined rule at decision points and records how long each step took. The difference matters. A BPMS installed without the BPM discipline turns into an expensive forms application; the software does not improve the process by itself, it makes improvement measurable and repeatable. And improvement made without measurement remains a claim.
That is why we draw the line up front. Workflow automation runs a single flow: a request comes in, moves on by rule, is approved and is recorded. BPM addresses the whole set of flows; it makes visible which processes exist, where they hold each other up and where the total cycle time is lost. If there are a handful of flows in your company that need automating, the right answer is workflow automation and we will not propose a BPMS to you; at that scale, installing a process engine is unnecessary weight. BPM's turn comes when processes start running across units and systems. And we have to say one more thing: we have never seen an engine survive where process ownership was not assigned. That is why our first question is not technical but managerial.
Medium and large companies where sales, planning, production, quality, dispatch and finance each work well on their own but the handovers between them are not recorded. The real loss here occurs not inside the units but at the handover points; that is usually the first thing process measurement reveals. Putting the handover points on record is the starting point for improvement.
Businesses with procedures prepared for ISO 9001 or customer audits, but where the written process and the practice on the ground have drifted apart. When the process moves onto the engine, the procedure stops being a document and becomes the flow that actually runs, and the audit trail accumulates by itself. The most concrete gain is the quality system ceasing to be a separate piece of work.
Businesses using an ERP, a CRM, a production tracking system and a few separate panels side by side. If a process does not finish inside a single system, that system's own approval flow cannot see the process end to end either. The process engine sits above these systems, sequences the tasks and leaves their data in the source systems.
Companies where the work has long been run through individuals and newcomers only learn the process by asking someone. In the transition from founder to professional management, or during periods of rapid hiring, that knowledge gap is expensive. Having processes both written down and running turns handover from a personal matter into an institutional one.
A list of the company's processes is drawn up: name, start and end point, which units and systems it passes through, roughly what volume it has and what complaints are known about it. Then not all of them, but the three to five that hurt most are selected. Producing the inventory is valuable in itself; in most companies this is the first time it becomes visible that the same job runs in two different ways in two different units.
The process is mapped as it actually runs, not as it ought to; the target state is drawn as a separate model. For modelling we use the BPMN 2.0 standard: the notation for tasks, decision points, events and pools is standard, and you do not have to learn a drawing language of our own. The difference between the two models is the improvement list itself. Mapping is done with the people who actually do the work and in their language.
The modelled process is run on the engine: the task drops to the right role, is reminded when its time is up and escalated if necessary, and delegation is defined for leave and holiday situations. The user does not see BPMN; what comes in front of them is a task list and a screen to fill in. The only thing the engine owns is the process itself; master data stays in source systems such as the ERP and the CRM.
Approval limits, classification thresholds and routing rules are not hard-coded; they are held in decision tables (DMN). When a limit changes, no new version is written — the table is updated and who made the change and when is recorded. In companies with frequently changing rules, this separation is one of the decisions that most reduces the system's long-term maintenance cost. The history of rule changes is kept in the same place.
Because the start and end of every step is recorded, total cycle time, waiting times by step and the points where work piles up become measurable. It also becomes visible how many times a job was sent back and at which step the most rework is done. The discussion thereby moves off who is right and onto the point the data indicates.
Measurement is possible even before the engine is installed: how the process actually runs can be derived from the timestamps of records in the ERP and other systems. This analysis, known as process mining, reveals the shortcuts nobody mentioned in the mapping meetings. If the timestamps on the records are inadequate, we say so up front and do not force the analysis. This piece of work can also be commissioned on its own, before deciding whether to install an engine at all.
Processes change. When a new version is published, jobs already in progress are completed on the old version and newly started ones enter the new model; that way half-finished work is not broken. What each version changed and who approved it are on record. In an audit, the question of which rule this job ran under can be answered together with its date. The model files stay with you and are not locked into one tool's format.
We draw up the list of processes by talking to unit managers and to the people who actually do the work: where it starts, where it ends, which systems it passes through. The scope is then narrowed and the three to five most painful processes are selected for the first round. The inventory stage usually takes 2-4 weeks depending on the size of the company.
The selected processes are drawn in BPMN 2.0 as they actually run and, where possible, verified against system records. In the same exercise it is decided what will be measured: cycle time, waiting, rework rate. Nobody can prove that a process without a defined measure has improved. The accuracy of the map is confirmed by the approval of the people who actually do the work; the flow management describes and the flow on the ground are often not the same.
An owner is assigned to every process; we do not put a process without an owner into software. The owner is responsible for the process's measure and for change decisions. This step is a managerial decision rather than a technical one and is taken within the company. Our job is to set up the framework and put the points requiring a decision in front of you. The ownership table is shared in writing and kept up to date throughout the project.
The process engine is installed, the first selected process is run end to end and connected to the existing systems. The pilot is kept narrow: one process, a limited set of users. The typical duration for taking the first process live is 6-10 weeks; the number of systems to connect and the complexity of the approval chain determine it. Throughout the pilot the old method stays open as a fallback for a while.
Process dashboards are opened; the first real data is read together with the process owner and the first improvements are made. How the model is to be updated, how a rule is to be changed and how a new version is to be published are handed over to the team in writing. Subsequent processes are added in turn within the same framework. After handover we will, if you wish, continue to attend process review meetings at set intervals.
Workflow automation runs a single flow: a request comes in, moves on by rule, is approved and is recorded. BPM addresses the whole set of flows. It manages which processes exist, where they hold each other up, where the total cycle time is lost and who the owner of each process is. In practice, workflow automation is the execution layer inside BPM. If you have a few flows to automate, the right starting point is workflow automation; if processes run across units and systems, the BPM layer starts to make sense.
If your process runs from start to finish inside that ERP, then most of the time you do not, and we will tell you so. The ERP's approval flow works well on its own data. The problem starts where the process leaves the ERP: a customer email, a quality record, a supplier document, a field approval, a signed form. Because those steps happen where the ERP cannot see, the total duration cannot be measured either. The process engine is installed to close that gap, not to replace the ERP.
No. Process ownership is not something that can be delegated; which approval stays, which step is removed and what the limits will be is your management decision. Our job is to capture the current state accurately, show the contradictions and the unmeasurable points, and set out the alternatives together with their consequences. We do not start a project where no process owner has been assigned, because in a process without an owner the software is abandoned before long. That comes less from preference than from what we have seen happen.
For the everyday user, no. All the user sees is a task list and a screen to fill in; the model behind it is not visible. For process owners, being able to read the model is useful, because change discussions run over the model. The part of BPMN 2.0 needed for reading can be conveyed in a short training session, and we do that as part of handover. If you would rather keep modelling capability entirely in-house, we will teach the same framework to your team as well.
No. Processes are versioned: when a new version is published, work in progress is completed on the old version and newly started work enters the new model. The frequently changing parts, such as approval limits or routing rules, are already held in decision tables separate from the code; you can update those without commissioning development. Changing the flow itself does require development, but that concerns only that model, not the whole system.
A process inventory and an ownership table; current and target models of the selected processes drawn in BPMN 2.0; an installed process engine and a first process taken live; business rules held in decision tables; cycle time, waiting and bottleneck dashboards; a version and change log. If you later want to continue running the engine with another team, the handover documentation is prepared for that. The source code, the models and the process data that accumulates belong to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We build the layer beneath the report: data is pulled from source systems by ETL or ELT, modelled across raw, processed and presentation layers, and stored together with its history. Metric definitions are fixed in a single data dictionary, and quality checks catch silent corruption while the data is still being loaded.
Details →We repair the record-keeping in which the same customer has been created three times and the same material sits under two codes. With matching rules, a similarity score and a review queue, duplicate records are deduplicated, a golden record is produced and distributed back to the source systems, and a similar-record warning steps in whenever a new record is created.
Details →We do not build diagnostic imaging software; your existing PACS stays where it is. What we build is the layer that closes the gap between the device worklist, the patient record, the order, the report and sharing: the image is linked to the right patient, pending orders become visible, and the retention and backup status of the archive becomes auditable.
Details →We build student information systems that bring admissions, enrolment, class placement, timetabling, attendance registers, marks, report cards, parent communication and instalment tracking together on a single record. It is designed around your institution's own calendar and your own fee policy; you do not have to fit into the mould of an off-the-shelf package. The source code and the data belong to the institution.
Details →We build laboratory information management systems that run every step on a single record, from the moment a sample is received through to the certificate of analysis: barcoded sample tracking, a method library, instrument connections, specification checks, staged approval and an audit-ready record structure.
Details →We bring the chain of quote, project, time record, milestone claim and invoice together on a single record. In agencies, consultancies, engineering practices and software firms, who spent how long on which job, resource utilisation and project profitability become visible while the work is still running, not once it has finished.
Details →
