Glages: One Model, Many Uses
A formal process model is useful during execution, but its value begins before runtime and continues afterward.
The same model can support readiness assessment, requirements, testing, controlled execution, self-service, verification, certification, and product design because all of these activities need a common definition of the business process.
Before Development
A model can be compared with the company’s documents, data, systems, and execution mechanisms.
This reveals missing facts, conflicting rules, unsupported states, unclear authority, unavailable APIs, and cases that still depend on human interpretation.
The result supports automation-readiness assessment and technological due diligence. A company can estimate the real scope of work before committing to a large implementation.
During Development
The model can define requirements and contracts more precisely than prose alone.
It can identify participating Entities, required Inputs, permitted transitions, valid Results, stopping conditions, and trace requirements. Those structures can guide test cases, acceptance criteria, API contracts, state matrices, and user instructions.
The development team does not have to infer the process independently from several conflicting documents.
During Execution
The model determines which facts are required, which rules apply, which action is permitted, which change is allowed, and which results are valid.
Different interfaces can initiate the same process. A customer may use a website, an employee may use an internal application, and an AI agent may interpret a message. The model preserves the activity across all of them.
This makes transactional self-service possible. The customer is not limited to receiving an explanation; the system can execute a permitted process under the same conditions used elsewhere in the business.
Verification of Documents and Software
Policies, contracts, APIs, data structures, and software implementations can be compared with the model.
A policy can be checked for missing authority, facts, conditions, and results. An API can be checked against the process it claims to support. A software implementation can be tested for conformance with permitted states and changes.
The model becomes a shared reference across representations that are otherwise difficult to compare.
Certification and Compatibility
A reference model can support conformance tests, certification suites, partner-extension requirements, and repeated verification after updates.
A product vendor may allow several partners to extend a process. Instead of reviewing each extension through informal documentation, the vendor can test whether it remains compatible with the model.
New Product Composition
Compatible process models can be combined into new products.
reservation
+ payment
+ identification
+ access management
→ contactless check-in
The product begins with already defined process foundations rather than a blank page.
Organizational Redesign
A model may also reveal manual work created by legacy software limits rather than by the business itself. Duplicate checks, unnecessary handoffs, and informal workarounds become visible when the activity is represented directly.
The organization can then decide whether those steps belong to the desired process or merely reflect the limitations of the current environment.
One model supports many uses because each use depends on the same thing: a machine-checkable definition of the activity.