A Practitioner's List of Common Business Capabilities

Key Takeaways

• The same eight or nine capability domains, customer, product, operations, finance, HR, IT, risk and compliance, and strategy, recur across almost every industry; what differs is the sub-capabilities underneath each one and how much weight it carries.
• A generic capability list saves the first few weeks of a mapping effort but can't resolve ownership disputes or settle the right level of granularity for your organization; that still takes stakeholder workshops.
• Treat a generic list as a checklist to react to, not a template to adopt unchanged; most organizations rename, merge, or split a third or more of it before it reflects how they actually operate.
• The common failure mode isn't missing capabilities, it's capability sprawl: lists that balloon well past a hundred entries at the second level stop being usable for investment decisions.
• Business should own the final list and its names; IT and enterprise architecture are consumers of the capability model, not its authors.

What a Capability List Is Useful For, and What It Isn't

A generic list is a checklist, not a deliverable.

Building a capability model from a blank page is slow. Someone has to interview a dozen stakeholders, reconcile conflicting terminology, and work out where one department's account management ends and another's begins. A reference list of common capabilities shortcuts that first pass. Instead of asking what capabilities does the business have, the team asks which of these do we have, what do we call them here, and what's missing. That's a faster, more concrete conversation, and it tends to surface disagreements about scope sooner rather than later. What a generic list can't do is tell you the right level of granularity for your organization, resolve who owns a capability that spans two departments, or decide whether something specific to your business, a claims capability at an insurer, a formulation capability at a chemical manufacturer, belongs on the map at all. Those calls need people who know the business, not a checklist someone downloaded.

The Domains That Repeat Across Almost Every Enterprise

Despite industry differences, the same handful of domains anchor most capability models.

Customer-facing capabilities cover how the organization acquires, serves, and keeps customers: sales, marketing, and customer service, typically. Product or service capabilities cover what the organization builds and sells, or the services it delivers. Operations capabilities cover how the product or service actually gets produced and delivered, which in a manufacturer means supply chain and production, and in a services firm means service delivery and fulfillment. Finance capabilities are close to identical in name across companies, because financial regulation and standard accounting practice push most organizations toward the same structures. Human resources and information technology capabilities look similar for the same reason: most organizations manage a workforce and run technology in recognizably similar ways, whatever they sell. Risk and compliance capabilities scale with how regulated the industry is, light in a mid-size retailer, extensive in a bank or insurer. Strategy and governance capabilities sit above the rest, covering planning, portfolio management, and performance measurement. What differs between industries usually isn't the domain, it's the emphasis and the sub-capabilities underneath it. A hospital's operations domain is dominated by clinical capabilities that don't appear anywhere in a retailer's model; a bank's risk domain is far more elaborate than a software company's.

A Representative List, by Domain

The names below are common labels, not a fixed standard. Plenty of organizations split or merge these differently.

Treat each line as a starting point for one domain of the model, not as the final word on what belongs in it.

• Customer: Customer Relationship Management, Customer Service & Support, Customer Data & Insight, Channel Management, Loyalty & Retention Management
• Product & Service: Product/Service Development, Product Portfolio Management, Pricing Management, Product Lifecycle Management
• Marketing & Sales: Marketing Management, Brand Management, Sales Management, Partner & Channel Management
• Operations & Supply Chain: Supply Chain Management, Procurement & Sourcing, Inventory Management, Production/Manufacturing Management, Logistics & Distribution, Quality Management
• Finance: Financial Planning & Analysis, Accounting & Financial Reporting, Treasury Management, Revenue & Billing Management, Procure-to-Pay Management
• Human Resources: Talent Acquisition, Workforce Planning, Learning & Development, Compensation & Benefits Management, Employee Relations
• Information Technology: Application Portfolio Management, Infrastructure & Cloud Management, Data Management, Cybersecurity Management, IT Service Management
• Risk & Compliance: Enterprise Risk Management, Regulatory Compliance Management, Audit Management, Business Continuity & Resilience Management
• Strategy & Governance: Strategic Planning, Enterprise Performance Management, Portfolio & Investment Management, Enterprise Architecture Governance

Why the Same List Won't Fit Two Companies the Same Way

A shared domain name hides real differences in scope once you look closer.

A direct-to-consumer apparel brand and a big-box grocery chain both have something they'd call Merchandising. Ask each to describe it and you'll get two different answers: one is largely about buying decisions and vendor negotiation, the other is as much about shelf space and store-level replenishment. Same label, different capability underneath. The same thing happens with Customer Service at a software company versus a utility, or Risk Management at a retailer versus a bank; the name travels, the actual scope and sub-capabilities don't. This is why handing a generic list to a team and asking them to confirm it rarely works well. The list gives people a shared starting vocabulary, but each capability still needs to be defined in the organization's own terms, with a scope statement that says clearly what's in and what's out.

Turning the List Into Your Own Capability Model

A generic list becomes a real model through a fairly small set of steps, done in order.

Working through these in sequence keeps a team from arguing about names before they've agreed on scope.

1. Start with the domain, not the leaf-level capability. Confirm the eight or nine top-level groupings apply before arguing over what sits underneath any one of them.
2. Rename items in the business's own language. If the organization calls it Member Services, not Customer Service, use that name; the label needs to be recognizable to the people who'll use the model.
3. Test each capability against a real value stream or two. If a capability doesn't show up doing anything in any value stream, it's either misnamed or doesn't belong yet.
4. Merge or split until no two capabilities describe the same thing twice. Overlap is the most common defect in a first-draft model built from a generic list.
5. Assign a business owner to each capability before calling the level final. An unowned capability tends to drift out of date within a year.

Where Generic Capability Lists Go Wrong

The mistakes are more about how the list gets used than what's on it.

The most common failure is treating the generic list as finished work rather than a draft, so the model never gets tested against the organization's own value streams or systems. Close behind is capability sprawl: teams that keep adding sub-capabilities until the model has more entries than the organization has meaningful investment decisions to make, at which point nobody actually consults it. A model with thirty well-defined, owned capabilities beats one with a hundred and fifty that nobody can hold in their head. A third mistake is letting IT own the list. Capabilities are business constructs, and when the enterprise architecture team writes the names and definitions without the business in the room, the model reads like a system inventory with better labels; the business stops recognizing itself in it and stops using it.

Frequently Asked Questions

Q: What's the difference between a business capability and a business function? A: A capability describes what the organization needs to be able to do, independent of who does it, while a function is an organizational grouping, a department or team that exists in the org chart today. The same capability can be delivered by different functions over time, or by more than one function at once; the capability doesn't change when the org chart does. Q: How many business capabilities should a typical enterprise have? A: There's no fixed number. It depends on how finely the second level of decomposition is done and how many distinct business lines the enterprise runs. What matters more than the count is that each capability is distinct and has an owner; a model that's internally consistent at thirty capabilities is more useful than one that hits an arbitrary target because someone thought it should. Q: Should IT or the business own a common capabilities list? A: The business should own the names, definitions, and scope. IT and enterprise architecture typically maintain the model and use it to inform application and data decisions, but the capability itself is a business construct and needs business sign-off to stay credible. Q: Can two departments each claim ownership of the same capability? A: No. A capability needs one accountable owner even when several departments use or contribute to it. Shared use is normal; shared ownership tends to mean nobody is actually accountable when the capability underperforms. Q: Is a capability list the same thing as a capability map? A: No. A list is just names, useful as a starting reference. A map arranges those capabilities hierarchically, usually with a defined level of decomposition, and often overlays maturity, performance, or investment information on top.

Pro Tips

• Run the first workshop with the generic list already filled in and ask stakeholders to cross out and rename, rather than starting from a blank whiteboard. It surfaces disagreement about scope faster than an open-ended discussion.
• Keep a running parking lot for anything that comes up in conversation but doesn't clearly belong at the level you're working. Most of those turn out to be processes or systems wearing a capability's name.
• Don't finalize a capability's name or scope until you've tested it against at least one real value stream. A name that sounds right in isolation often turns out to be two capabilities once you trace how it's actually used.