From Enterprise Design with EDGY
Revision as of 11:18, 2 September 2025 by Stephan2 (talk | contribs)

Capability Modeling Guidelines | How to Structure a Capability Map

Designing Capabilities Around Activities or Objects

As mentioned in the previous section, capabilities should always be designed around “what belongs together and is distinctive from other capabilities.” While this may sound obvious in theory, designing for togetherness is challenging in the reality of complex enterprises. Among the thousands of processes that occur in an enterprise every day, which ones are similar enough to be grouped within the same capability?

The best way to identify processes (and their required people and assets) that belong together is to look for specialisations - where do we need similar, special skills? Where do we need similar, special assets (like machines, applications, raw material, buildings)? Once you have identified these specialisations, you need to ask questions such as: “Is building railway assets so similar to maintaining railway assets that we should put it in the same (level 2) capability?”, “Is building a track similar to building a station?”

Depending on the answers we have two options:

1.) Grouping by Activity

Planning railway assets differs significantly from building and maintaining them. However, building and maintaining all types of railway assets may be “similar enough” to categorise under a single capability group. In this case, we group by activity: “Railway Asset Management” with lower-level [[capabilities: “Plan Railway Assets” and “Build and Maintain Railway Assets”.

2.) Grouping by Object

Building and maintaining tracks is very different from building and maintaining stations. These Capabilities require different engineering skills, Processes, and machines. Therefore, we group “Build & Maintain Railway Assets” into lower-level Capabilities: “Build & Maintain Railway Tracks” and “Build & Maintain Stations”.

The following example illustrates how grouping the elements of Capabilities always requires intentional design decisions between “grouping by similar Activities” and “grouping by similar Objects”: