Skill Hub — Architecture

Capability Mapping

Map what the organization does, what systems support it, and where gaps exist between business functions and technical enablement.

What this skill is for

This skill produces a structured view of organizational capabilities and their system support. It answers three questions: what functions does the organization perform, which systems enable each function, and where is the coverage incomplete, duplicated, or outdated? The output is used during discovery, transformation planning, and vendor selection to ground conversations in observable reality rather than aspirational diagrams.

When to use this skill

  • You are starting a transformation project and no one can agree on what the current systems actually do.
  • A business unit claims a function is unsupported, but IT believes it is already covered.
  • You need to evaluate a vendor proposal against actual organizational needs, not just feature lists.
  • You are consolidating systems after a merger and need to identify overlap.
  • You are scoping an SAP module rollout and need to know which business processes it must cover.

Real work situations

Example 1: SAP S/4HANA migration scoping

A manufacturing division runs production planning on a legacy MES, inventory on SAP ECC, and scheduling on spreadsheets. The project team needs to know which ECC functions move to S/4, which stay with the MES, and which spreadsheet-based scheduling must be replaced or integrated. Capability mapping reveals that capacity planning is double-maintained in ECC and spreadsheets, creating a data consistency risk.

Example 2: Post-merger integration

Two companies with separate ERPs merge. The integration team must decide which system becomes the record for each function. Mapping capabilities shows that both companies perform supplier qualification, but one uses a dedicated SRM module while the other uses email and shared folders. The gap is not technical — it is process maturity — and the map makes this visible to decision-makers.

Example 3: Cloud procurement evaluation

A procurement director wants a new e-sourcing platform. IT lists 47 requirements from the vendor. The capability map shows that 12 of those requirements are already met by an existing SAP Ariba module that is underutilized because of poor training. The map prevents redundant purchase and redirects effort toward adoption.

Example 4: AI readiness assessment

A data science team wants to deploy predictive maintenance models. The capability map reveals that equipment sensor data is collected by SCADA but never reaches the data warehouse, and that maintenance work orders are created in SAP PM but not linked to asset condition. The map identifies the integration and data quality gaps that must close before AI can operate.

Inputs required

  • Organizational chart or business unit list (to know who does what).
  • System inventory with primary function descriptions (not just names and versions).
  • Process documentation, SOPs, or training materials (to understand how work is performed).
  • Interviews with at least one business representative and one IT representative per major function.
  • Existing architecture diagrams, if any (to validate or challenge them).
  • Project scope or transformation objectives (to know which capabilities matter most).

Questions to ask

  • What business outcome does this function produce? Who receives it?
  • If this system were unavailable for 48 hours, which functions would stop and what would the business consequence be?
  • Is this capability performed in one place or in multiple systems with different owners?
  • Who is the single person who could explain how this function works end to end?
  • What data enters this function, what data leaves it, and who owns each dataset?
  • Is this capability automated, semi-automated, or manual? Where are the handoffs?
  • What regulation, SLA, or audit requirement applies to this function?

Working method

  1. Define the scope. Identify the business domain, time horizon, and decision the map must support. A map for merger integration has different granularity than a map for module selection.
  2. Identify capability categories. Group functions into 5–10 categories relevant to the domain (for example: Plan, Source, Make, Deliver, Sell, Support, Govern). Do not use generic framework categories unless they fit the organization's language.
  3. List capabilities within each category. Name each capability as a verb-noun phrase at a consistent level of granularity (for example: "Manage supplier qualification," "Generate production schedule," "Process customer return"). Aim for 15–40 capabilities total.
  4. Map system support. For each capability, record which system or systems enable it. Use four support levels: Fully supported, Partially supported, Supported by workaround, Not supported.
  5. Record ownership. For each capability, note the business owner (who is accountable for the outcome) and the technical owner (who maintains the supporting system).
  6. Identify gaps and overlaps. Flag capabilities with no support, multiple conflicting systems, manual workarounds, or outdated technology. Classify each as: gap, overlap, risk, or technical debt.
  7. Validate with stakeholders. Walk the draft map with business and IT representatives separately, then together. Correct misattributions and missing capabilities.
  8. Produce the final artifact. Format as a matrix or structured document. Include a summary of top 5 gaps and overlaps with business impact.

Decision rules

  • If a capability has no business owner, do not assign a system to it until ownership is clarified.
  • If two systems support the same capability with different data, flag a data consistency risk, not just a duplication.
  • If a capability is supported by a spreadsheet or email workflow, classify it as a workaround, not as supported.
  • If a capability is required by regulation but unsupported, mark it as a compliance gap regardless of business priority.
  • If a system supports a capability but no one in the business uses it, classify as adoption gap, not capability gap.
  • If the map contains more than 50 capabilities, the granularity is too fine; merge related capabilities into higher-level groupings.
  • If a capability cannot be described in one verb-noun phrase, it is probably a process, not a capability; decompose or rephrase.

Deliverables

  • Capability Map Matrix — Categories, capabilities, system support levels, owners, and gap flags in a single table or diagram.
  • Gap and Overlap Register — Prioritized list of gaps and overlaps with business impact, risk level, and proposed action.
  • System Coverage Summary — Per-system view of which capabilities it supports, partially supports, or should support but does not.
  • Stakeholder Validation Notes — Record of who reviewed the map, what corrections were made, and what remains disputed.

Templates

Capability Map Matrix (Markdown table)

| Category | Capability | Business Owner | System | Support Level | Gap Type | Notes |
|----------|------------|----------------|--------|-------------|----------|-------|
| Source | Manage supplier qualification | Procurement Director | SAP SRM | Fully supported | — | — |
| Source | Evaluate supplier performance | Procurement Director | Excel + Email | Workaround | Gap | No central record; audit risk |
| Plan | Generate production schedule | Plant Manager | SAP PP + Excel | Partial | Overlap | Scheduling done in both; data mismatch weekly |
| Deliver | Process customer return | Customer Service Lead | SAP SD | Fully supported | — | — |
| Govern | Maintain material master data | MDM Lead | SAP MDG | Fully supported | — | — |

## Gap and Overlap Register

| ID | Capability | Gap Type | Business Impact | Risk Level | Proposed Action | Owner | Due Date |
|----|------------|----------|-----------------|------------|-----------------|-------|----------|
| GAP-001 | Evaluate supplier performance | Missing system | Audit findings, delayed sourcing | High | Implement SRM supplier scorecard or Ariba module | Procurement Director | YYYY-MM-DD |
| OVL-001 | Generate production schedule | System overlap | Weekly reconciliation effort, planning errors | Medium | Consolidate scheduling in SAP PP; retire spreadsheet | Plant Manager | YYYY-MM-DD |

Quality checklist

  • Every capability has a named business owner who can confirm its accuracy.
  • Every system listed is identifiable by name and version or instance.
  • Support levels use the four standard categories consistently.
  • At least one gap and one overlap are identified and classified.
  • The map has been reviewed by both business and IT stakeholders.
  • Capabilities are described at a consistent level of granularity.
  • The top 5 gaps and overlaps are summarized with business impact.
  • No capability is described as a system feature or a process step.

Common mistakes

  • Mistake: Mapping systems instead of capabilities. Consequence: The map becomes a system inventory with no business meaning, and gaps remain invisible because every system is "present."
  • Mistake: Using generic framework categories that do not match the organization's language. Consequence: Stakeholders cannot validate the map because they do not recognize their work in the labels.
  • Mistake: Treating spreadsheet workarounds as supported capabilities. Consequence: Transformation projects underestimate integration and data quality effort.
  • Mistake: Creating the map in isolation and presenting it as final. Consequence: Business stakeholders reject the map because it misattributes ownership or misses shadow processes.
  • Mistake: Including too many capabilities at too fine a granularity. Consequence: The map becomes unreadable and the gaps are lost in detail.

Agent instructions

When using this skill, an AI agent must:

  1. Gather context first. Ask for the business domain, scope, and decision the map must support before producing any output.
  2. Use the organization's language. Do not impose generic framework categories unless the user confirms they are used internally.
  3. Separate facts from assumptions. Label every capability and system assignment as confirmed, inferred, or disputed. Do not present inferred mappings as validated.
  4. Produce the matrix and register. Generate the Capability Map Matrix and Gap and Overlap Register as structured Markdown tables. Include placeholder rows with realistic examples.
  5. Flag missing inputs. If the user cannot provide business owners, system names, or process descriptions, explicitly list what is missing and how it limits the map's accuracy.
  6. Avoid generic language. Do not write "the organization needs to align its capabilities with its strategic objectives." Write "Procurement needs supplier performance evaluation; current workaround is Excel and email."
  7. Link to Atlas diagnostics. If the map reveals integration gaps, reference SAP Integration Architecture or Composable ERP for SAP Operations for deeper diagnostic context.

Related skills

Related Atlas pages

Verification status and limitations

This skill is a public working interpretation of capability mapping practice. It is not official TOGAF or ArchiMate guidance. It focuses on the practical subset used during enterprise discovery and SAP transformation projects. It does not cover detailed business architecture modeling, value stream analysis, or strategic planning at the portfolio level. Use it as a structured starting point for capability discovery, not as a comprehensive enterprise architecture methodology.