Capability
Enterprise applications
Build and extend ERP, CRM, operations, workflow and portal systems around how the institution actually works.
Page purpose
What the Enterprise applications capability delivers and how it connects to the modernization lifecycle.
Enterprise applications should reflect accountable work, not merely digitize existing forms or copy a package's default process. Design starts with roles, decisions, records, exceptions and handoffs, then establishes which system owns each responsibility.
Configuration, extension and custom engineering are treated as explicit choices with lifecycle consequences. The result is a usable product boundary that connects to systems of record without duplicating their authority.
When to use this capability
Situations that call for this delivery capability.
- Differentiating workflows remain in spreadsheets, email and local tools because the core package does not fit them.
- Customization accumulates without a clear distinction between justified operating need and avoidable variation.
- Users cross multiple applications to complete one task, causing re-entry, unclear status and weak exception ownership.
Service scope
Outputs a buyer can inspect.
- Service blueprints and workflow models covering roles, states, decisions, exceptions and handoffs.
- Functional scope and product backlog with acceptance criteria and process-owner decisions.
- Application, information, integration and access design showing systems of record and responsibility boundaries.
- Release, adoption and operating model covering support, ownership, change control and lifecycle review.
Delivery pattern
From discovery to acceptance evidence.
- Observe representative work and exceptions rather than relying only on policy documents or feature lists.
- Simplify the process and assign record ownership before deciding whether to configure, extend, build or retire.
- Prototype critical journeys and rules with users, including accessibility, Arabic and mixed-direction needs where applicable.
- Deliver coherent process slices, validate end-to-end behavior and establish product ownership beyond launch.
Operating value
The operating change that should remain.
- Role-based journeys aligned to real decisions, records, controls and exception paths.
- A deliberate system-of-record and application-boundary model that prevents uncontrolled duplication.
- A prioritized product backlog balancing process value, usability, integration effort and lifecycle cost.
Performance evidence
Evidence of impact, not activity completion.
- End-to-end completion time and manual handoffs for the in-scope journeys.
- Task success, exception resolution and user-error rates across representative roles.
- Share of application changes delivered within agreed product and lifecycle guardrails.
Delivery boundaries
Boundaries that keep delivery honest.
- Digitizing a poor process can make waste faster and harder to change.
- Uncontrolled customization can increase upgrade cost and bind the organization to scarce knowledge.
- A polished interface can conceal unresolved data ownership, authorization and exception handling.
Decision questions
Questions that bound the capability before engagement.
Do you replace the existing ERP or CRM?
The first decision is where each responsibility belongs: in the core product, an extension, a connected application or a redesigned process. Replacement follows only when that boundary and the evidence justify it.
How is custom development kept under control?
Every customization needs an accountable owner, a documented reason, a tested boundary and an understood maintenance and upgrade consequence.
Related decision