Every process lives in the EA repository, wired to its capabilities and services — change one step and you see who gets hit before you press save.
This site uses cookies to improve your experience and analyze visits.
Document the process in BPMN, measure how long it really takes, then redesign it around the beneficiary, not the org chart.
The work has three parts: document the process as it actually runs, measure performance with numbers (not feelings), then redesign it to ship faster at lower cost. BPMN is the shared language between business and IT. You walk away with an execution roadmap, not a binder that sits in a drawer. Inside Saudi entities, two angles meet: the Operations perspective in Qiyas and the Business Architecture (BRM) domain in NORA.
Pin down which processes, units, and beneficiaries are in. Whatever falls outside stays outside.
Document each in-scope process at a uniform L2 — same template, same vocabulary.
BPMN 2.0 at L3 for critical processes, with cycle-time measurement, bottleneck detection, and value-add analysis.
Design the future state and put a number on what automation actually saves.
A prioritised list of initiatives with KPIs and delivery milestones on a calendar.
Every process lives in the EA repository, wired to its capabilities and services — change one step and you see who gets hit before you press save.
Outputs slide straight into Business Architecture in NORA in their original form, feeding the as-is diagnosis and the future-state design with no middle step.
Executable BPMN: a .bpmn file ready to import into ABACUS or any workflow engine, and KPIs your team computes from your own data so you do not stay dependent on us.
Process engineering takes what you have and improves it in steps. BPR throws the process out and starts from the outcome you want. We pick between them based on the size of the performance gap.
BPMN is an OMG standard for drawing processes. The real value: an analyst and a developer read the same diagram and reach the same conclusion. That ends the "what did you mean here" debates. Good for modeling, simulation, and workflow automation.
Yes. The process catalog and its links to services, units, and capabilities drop into Business Architecture as-is. Nobody rewrites anything after the fact.
A unified process inventory, BPMN models for the critical processes, a cycle-time report, a RACI matrix, KPIs, and a phased roadmap. Every deliverable gets an owner on the entity side before we hand it over.
Mid-sized projects run 12 to 24 weeks. We slice them into phases, each phase ending in a specific deliverable. If a deliverable slips, we know exactly where the work stopped.
No. We work with both public and private sector. The framework is the same; what changes is the examples and the type of beneficiary. The practical gap between the two sectors is smaller than people assume.
Yes. Processes sit in the ABACUS repository linked to their capabilities and services. Change one process and you see immediately what else gets touched across the architecture.
You leave the meeting with a realistic plan, a known budget, and a fixed timeline. No fluffy promises.
Back to all services