Four Methods to Identify Business Capabilities: Value Streams, Processes, Objects & Models

The article begins by recalling a previous discussion on the relationship between business capabilities and business processes, noting that readers asked how to identify business capabilities within Huawei's Y-model.

Y-Model Positioning

The Y-model is not a universal industry standard but a class of working models used in Huawei's business architecture and digital transformation practice. Public materials show at least three variants with differing structures and purposes. One variant unfolds along two tracks: a business value track (company-level value streams, professional-level value streams, operational processes) and a business capability track (business domains, capability categories, specific capabilities), converging at business metrics, roles, objects, and services before connecting to data, application, and technology architecture. Another variant emphasizes the relationship among business models, capability matrices, and functional processes, starting from stakeholders and business models to identify value streams and end-to-end processes while forming layered business capabilities mapped to functional processes, activities, and tasks. Despite visual differences, all variants address the same core questions: how the enterprise creates value, which capabilities are needed for value delivery, how processes invoke those capabilities, and how they land in data and IT systems. The author advises focusing on the "value stream – business capability – process – digital implementation" main line rather than adhering to a single diagram.

Method 1: Top-Down Along Value Streams

Value streams describe how the enterprise creates value for customers. Following the main value chain, one can first identify enterprise-level capabilities and then decompose them layer by layer. For a manufacturing enterprise, the primary value chain typically involves R&D, procurement, production, sales, and after-sales. Procurement capability can be further broken down into procurement demand management, sourcing and bidding, purchase order execution, and supplier full-lifecycle management. This method suits building the backbone of a capability map and verifying alignment with customer value and corporate strategy. It is commonly used in strategic planning, capability layout, and cross-department collaboration analysis. Value streams usually yield higher-level capabilities; further refinement requires processes and business objects.

Method 2: Inductive from Process Activities

When an enterprise already has a relatively complete process system, capabilities can be induced bottom-up from process activities. For example, a supplier admission process includes material collection, qualification check, capacity assessment, and fit judgment. These activities collectively accomplish "determine whether the supplier meets cooperation requirements," which can be generalized as the supplier qualification assessment capability. This approach stays close to the current state, reveals what positions actually do, and fits process optimization, risk analysis, and role capability modeling. Abstraction level must be controlled: naming every step produces an activity list; merging too broadly loses guidance for downstream construction. A suitable practice is to group activities that share similar goals and revolve around the same business outcome.

Method 3: Around Business Objects

Business objects are the people, events, and things the enterprise continuously manages—e.g., customers, suppliers, contracts, orders, projects, assets. Expanding around an object's lifecycle yields a set of capabilities with relatively clear boundaries. Taking contracts as an example, one can identify contract template management, contract compliance review, contract change management, and contract archive management. This method works well for cross-department objects such as contracts, projects, and suppliers. It helps check lifecycle completeness and uncover management gaps between departments. Business objects also serve as key connection points between business architecture and digital design: process activities handle business objects, data models describe object information, and application services provide create, modify, query, and approve operations.

Method 4: Reference Mature Industry Models

Frameworks such as the APQC Process Classification Framework, IBM Business Component Model, and consulting firms' industry capability models can serve as initial references. Mature models offer broad coverage, enabling rapid formation of a capability framework while reducing omission risk. IBM's model further categorizes related capabilities into three responsibility layers: strategy guidance, management control, and business execution. Industry models provide a commonality framework; enterprises must still select and adapt based on their own business model, value streams, and organizational characteristics, avoiding direct adoption of an external model as their own capability map.

Combining the Four Methods

Real projects rarely use a single method. A practical sequence is: first reference industry models and mature software to quickly form an enterprise-level capability framework; then verify backbone completeness along value streams; next supplement enterprise-specific capabilities from existing process activities; finally check lifecycles and capability boundaries around business objects like contracts, suppliers, and projects. This process simultaneously employs top-down and bottom-up paths. Top-down ensures capabilities stay linked to strategy and customer value; bottom-up ensures capabilities can land in processes and roles. Results from both paths must be repeatedly cross-checked—differences often signal missing capabilities, overlapping definitions, or inconsistent granularity. After forming the capability map, one must return to business scenarios for combination: different scenarios invoke relevant capabilities via end-to-end processes. Capabilities remain relatively stable, while processes are orchestrated according to customer, product, region, and risk conditions.

Granularity Management

Granularity management seeks consistent hierarchy and caliber, not uniform capability size. First unify capability levels: e.g., level 1 = business domain, level 2 = capability group, level 3 = concrete, buildable, assessable business capabilities. Below level 3, enter functional processes, activities, and tasks, no longer named as capabilities. In a manufacturing enterprise, procurement can be a capability domain, decomposed into procurement demand management, sourcing and bidding, order execution, and supplier full-lifecycle management. Supplier qualification check and material collection then belong to the process activity layer. Same-level capabilities should use similar naming and judgment criteria, typically checked via four questions: (1) Does it correspond to a clear business outcome? (2) Does it revolve around a relatively stable business object or professional responsibility? (3) Can it be repeatedly invoked by multiple business scenarios? (4) Can it be supported by a relatively complete set of processes, data, systems, and personnel skills? Further decomposition yielding concrete operational steps, role actions, or system functions indicates entry into the process activity layer. Conversely, a capability containing multiple disparate business goals and responsibility owners may be too coarse. One can also verify completeness across three responsibility layers: strategy, control, and execution. For supply chain, logistics warehousing planning and category procurement strategy are strategy capabilities; supplier quota and performance management are control capabilities; procurement demand, order execution, and logistics dispatch are execution capabilities. This classification helps discover whether the capability map focuses only on frontline execution while omitting strategy formulation and process management.

From Capability Map to Business Architecture

After identifying business capabilities, they must be linked to value streams, end-to-end processes, and functional processes. Value streams state what value the enterprise delivers; end-to-end processes combine capabilities per specific scenario; functional processes realize individual capabilities; data, systems, and personnel skills provide operational support. Different Y-model variants may emphasize capability planning, process design, or digital implementation. As long as the model answers where value comes from, which capabilities are needed, how capabilities combine, and how they land, it serves its purpose. The final deliverable should not be just a capability list, but a common language usable for capability assessment, organizational design, process optimization, and digital construction.