From Enterprise Design with EDGY
No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
<small>[[Capability Modeling Guidelines]] | [[Capability_Modeling_Guidelines:_How_to_Structure_a_Capability_Map|How to Structure a Capability Map]]</small>
<small>[[Capability Modeling Guidelines|Capability Modelling Guidelines]] | [[Capability_Modeling_Guidelines:_How_to_Structure_a_Capability_Map|How to Structure a Capability Map]]</small>


=Ensure Clear Names and Descriptions=
=Ensure clear names and descriptions=


You want Capability Maps to be created collaboratively and understood in a broadly consistent way by “everyone.In a large group, however, a truly shared understanding of the concepts behind terms rarely exists; they are often used and interpreted in surprisingly subjective ways, with each department maintaining its own jargon.
You want Capability Maps to be created collaboratively and understood in a broadly consistent way by 'everyone'. In a large group, however, a truly shared understanding of the concepts behind terms rarely exists; they are often used and interpreted in surprisingly subjective ways, with each department maintaining its own jargon.


To achieve the clarity necessary for aligned action, you must choose the language used in names and descriptions with meticulous care. Keep in mind that working with language is a challenging part of your modelling journey.
To achieve the clarity necessary for aligned action, you must choose the language used in names and descriptions with meticulous care. Keep in mind that working with language is a challenging part of your modelling journey.


==Establish a Glossary==
==Establish a glossary==


Maintain a well-established glossary and define all relevant terms as simply as possible. This way, you create a clear and consistent set of definitions for key concepts across the [[organisation]].
Maintain a well-established glossary and define all relevant terms as simply as possible. This way, you create a clear and consistent set of definitions for key concepts across the [[organisation]].
Line 19: Line 19:
Over time, [[enterprises]] develop their own terminology, which may not always align perfectly with dictionary definitions. It is usually more effective to use terms that are already in everyday use than to impose strict syntactic rigour on people.
Over time, [[enterprises]] develop their own terminology, which may not always align perfectly with dictionary definitions. It is usually more effective to use terms that are already in everyday use than to impose strict syntactic rigour on people.


''Example: use “Finance” as a capability name instead of “Manage Financial Assets” if the shorter name is well understood.''
''Example: use 'Finance' as a capability name instead of 'Manage Financial Assets' if the shorter name is well understood.''


'''Don’t accept poorly defined concepts.'''
'''Don’t accept poorly defined concepts.'''


We have seen [[enterprises]] where concepts such as “customer”, “product”, and “train schedule” were defined inconsistently across departments. When people disagree on the meaning of core terms, communication breaks down, data becomes unreliable, [[processes]] grow inefficient, projects lose alignment, and decision-making suffers.
We have seen [[enterprises]] where concepts such as 'customer', 'product', and 'train schedule' were defined inconsistently across departments. When people disagree on the meaning of core terms, communication breaks down, data becomes unreliable, [[processes]] grow inefficient, projects lose alignment, and decision-making suffers.


Start with the existing use of language, but improve it gradually to make it more consistent.  
Start with the existing use of language, but improve it gradually to make it more consistent.  
Line 31: Line 31:
It takes time for a large group to understand and adopt a new term. [[People]] only make sense of new concepts in relation to what they already know. If you need to introduce a new term, you must translate it into the existing vocabulary.
It takes time for a large group to understand and adopt a new term. [[People]] only make sense of new concepts in relation to what they already know. If you need to introduce a new term, you must translate it into the existing vocabulary.
<br>
<br>
==Capability Names==
==Capability names==


Depicting many [[capabilities]] on a single page requires names that are as concise as possible while still expressive enough for [[people]] to grasp what each [[capability]] represents instantly. The following tips will help you manage this trade-off:
Depicting many [[capabilities]] on a single page requires names that are as concise as possible while still expressive enough for [[people]] to grasp what each [[capability]] represents instantly. The following tips will help you manage this trade-off:
Line 51: Line 51:
At the higher levels (typically levels 1–3), concise naming is essential to present the [[enterprise|enterprise’s]] [[capabilities]] on a single page without overwhelming [[people]].
At the higher levels (typically levels 1–3), concise naming is essential to present the [[enterprise|enterprise’s]] [[capabilities]] on a single page without overwhelming [[people]].


Longer names are more useful for the "specific [[capabilities]]" level, especially when designing future scenarios.
Longer names are more useful for the 'specific capabilities' level, especially when designing future scenarios.


'''Use acronyms with care.'''
'''Use acronyms with care.'''
Line 57: Line 57:
Acronyms can help shorten names, but use only those that are widely recognized within the enterprise. For example, you may use ''HR'' instead of ''Manage and Develop Human Resources'' if the acronym is commonly understood.
Acronyms can help shorten names, but use only those that are widely recognized within the enterprise. For example, you may use ''HR'' instead of ''Manage and Develop Human Resources'' if the acronym is commonly understood.


==Capability Descriptions==
==Capability descriptions==


Co-creating [[capability]] descriptions provides the necessary clarity and strengthens shared understanding among stakeholders. For each [[capability]], the description should explain what needs to be done to produce its output.
Co-creating [[capability]] descriptions provides the necessary clarity and strengthens shared understanding among stakeholders. For each [[capability]], the description should explain what needs to be done to produce its output.


''Examples:''
''Examples:''
*''<u>Build Railway Assets:</u> Capability of designing, constructing, and implementing the physical infrastructure required for railway operations, including bridges, tunnels, tracks, stations, signaling systems, operational technology, and energy supply.""
*''<u>Build Railway Assets:</u> Capability of designing, constructing, and implementing the physical infrastructure required for railway operations, including bridges, tunnels, tracks, stations, signaling systems, operational technology, and energy supply.''
*''<u>Maintain Railway Assets:</u> Capability concerned with ensuring the proper functioning, safety, and longevity of all railway system assets. This includes inspecting, servicing, repairing, and upgrading infrastructure such as bridges, tunnels, tracks, stations, signaling systems, operational technology, and energy supply.''
*''<u>Maintain Railway Assets:</u> Capability concerned with ensuring the proper functioning, safety, and longevity of all railway system assets. This includes inspecting, servicing, repairing, and upgrading infrastructure such as bridges, tunnels, tracks, stations, signaling systems, operational technology, and energy supply.''


Line 69: Line 69:
Use concrete and actionable language expressed in unambiguous terms that operators would grasp.
Use concrete and actionable language expressed in unambiguous terms that operators would grasp.


'''Express “what”, not the “how”.'''
'''Express 'what', not the 'how'.'''


Focus on ''what'' needs to be done to produce a [[capability|capability’s]] outputs, but avoid specifying ''how'' the work will be carried out, ''who'' will perform it, or ''where'' it will take place.
Focus on ''what'' needs to be done to produce a [[capability|capability’s]] outputs, but avoid specifying ''how'' the work will be carried out, ''who'' will perform it, or ''where'' it will take place.


''Example:''<br>
''Example:''<br>
''How statement: <s>“Utilize Social Media to engage with passengers”</ds''<br>
''How statement: <s>'Utilize Social Media to engage with passengers'</s>''<br>
''Rewritten as “does what”: “Engage with passengers to build relationships."''
''Rewritten as 'does what': 'Engage with passengers to build relationships.' ''
 
==Related Patterns==
*[[Human Language|#28: Human Language]]
<br><br>
{| style="width:100%;"
| style="text-align:left; width:50%;" | [[Capability_Modeling_Guidelines:_Shared_and_Change_Capabilities|← Previous page]]
| style="text-align:right; width:50%;" | [[Capability_Modeling_Guidelines:_Two-Dimensional_Layout|Next page →]]
|}

Latest revision as of 14:48, 13 September 2025

Capability Modelling Guidelines | How to Structure a Capability Map

Ensure clear names and descriptions

You want Capability Maps to be created collaboratively and understood in a broadly consistent way by 'everyone'. In a large group, however, a truly shared understanding of the concepts behind terms rarely exists; they are often used and interpreted in surprisingly subjective ways, with each department maintaining its own jargon.

To achieve the clarity necessary for aligned action, you must choose the language used in names and descriptions with meticulous care. Keep in mind that working with language is a challenging part of your modelling journey.

Establish a glossary

Maintain a well-established glossary and define all relevant terms as simply as possible. This way, you create a clear and consistent set of definitions for key concepts across the organisation.

Make maintaining the glossary a team effort.

Make it easy for people to add or edit terms and descriptions (for example, by using a wiki). Run term-clarification workshops with co-creators to foster shared understanding. Test definitions with someone who is unfamiliar with the term.

Embrace the enterprise’s dialect.

Over time, enterprises develop their own terminology, which may not always align perfectly with dictionary definitions. It is usually more effective to use terms that are already in everyday use than to impose strict syntactic rigour on people.

Example: use 'Finance' as a capability name instead of 'Manage Financial Assets' if the shorter name is well understood.

Don’t accept poorly defined concepts.

We have seen enterprises where concepts such as 'customer', 'product', and 'train schedule' were defined inconsistently across departments. When people disagree on the meaning of core terms, communication breaks down, data becomes unreliable, processes grow inefficient, projects lose alignment, and decision-making suffers.

Start with the existing use of language, but improve it gradually to make it more consistent.

Introduce new terms with care.

It takes time for a large group to understand and adopt a new term. People only make sense of new concepts in relation to what they already know. If you need to introduce a new term, you must translate it into the existing vocabulary.

Capability names

Depicting many capabilities on a single page requires names that are as concise as possible while still expressive enough for people to grasp what each capability represents instantly. The following tips will help you manage this trade-off:

Use simple common terms or verb-noun action phrases.

To express what a capability is about, you often need a verb (e.g., sell, prepare, plan, build, maintain) combined with a noun (e.g., ticket, contract, product, passenger, track). Use a simple verb–noun structure when naming capabilities (e.g., build tracks). When widely recognised one-word terms exist (e.g., finance, marketing), use them instead.

Vigorous verbs.

Choose the most vigorous possible verb. Avoid weak verbs like manage.

Well-defined nouns.

Ensure that the nouns used in capability names are clearly defined in the glossary (see previous section). Avoid ambiguous nouns like management.

Use short names at the higher capability levels.

At the higher levels (typically levels 1–3), concise naming is essential to present the enterprise’s capabilities on a single page without overwhelming people.

Longer names are more useful for the 'specific capabilities' level, especially when designing future scenarios.

Use acronyms with care.

Acronyms can help shorten names, but use only those that are widely recognized within the enterprise. For example, you may use HR instead of Manage and Develop Human Resources if the acronym is commonly understood.

Capability descriptions

Co-creating capability descriptions provides the necessary clarity and strengthens shared understanding among stakeholders. For each capability, the description should explain what needs to be done to produce its output.

Examples:

  • Build Railway Assets: Capability of designing, constructing, and implementing the physical infrastructure required for railway operations, including bridges, tunnels, tracks, stations, signaling systems, operational technology, and energy supply.
  • Maintain Railway Assets: Capability concerned with ensuring the proper functioning, safety, and longevity of all railway system assets. This includes inspecting, servicing, repairing, and upgrading infrastructure such as bridges, tunnels, tracks, stations, signaling systems, operational technology, and energy supply.

Clarity.

Use concrete and actionable language expressed in unambiguous terms that operators would grasp.

Express 'what', not the 'how'.

Focus on what needs to be done to produce a capability’s outputs, but avoid specifying how the work will be carried out, who will perform it, or where it will take place.

Example:
How statement: 'Utilize Social Media to engage with passengers'
Rewritten as 'does what': 'Engage with passengers to build relationships.'

Related Patterns



← Previous page Next page →