Business Capability – CIO Wiki

Business Capability is the expression or the articulation of the capacity, materials, and expertise an organization needs in order to perform core functions.[1]

Business capabilities provide an abstraction of the business reality in a way that helps to simplify conversations between interested stakeholders. Defining a business capability’s supporting components (roles, processes, information, and tools) provides a business context for those supporting components. Creating a business capability model for the enterprise promotes more of a common understanding of the business.[2]

A business capability (or simply capability) describes a unique, collective ability that can be applied to achieve a specific outcome. A capability model describes the complete set of capabilities an organization requires to execute its business model or fulfill its mission. An easy way to grasp the concept is to think about capabilities as organizational level skills imbedded in people, process, and/or technology.[3]

Business Capability
source: omg.org

Business capabilities encapsulate what a business is doing right now and what it needs be doing in order to meet current and future challenges. They define “what” a business does, rather than “how” it does it (which is described by processes). Most modern companies might have goals around having a competitive workforce. To “recruit talented employees” is one business capability necessary to achieve this goal. “Recruit talented employees” tells us what we need to do, but leaves it open how to do it. There could be a Human Resources process from attracting employees via a recruiting website to interviewing candidates to the administration of hiring. Or everything could be outsourced to a third party. In a more abstract way, according to Gartner, Business Capability Modeling “is a technique for the representation of an organization’s business anchor model, independent of the organization’s structure, processes, people or domains.” Business capabilities help to abstract from the organization’s fast-moving parts. We can imagine them as the sum of people, processes and technology needed to achieve a certain goal. If we come back to the above example, “Recruit great employees” comprises the people (HR Team), the process (e.g. attract, screen, interview, hire) and technology (e.g. online assessment center, digital personnel file) into one capability of the organization. Properly defined business capabilities are fairly stable over time. While the way we recruit has changed quite a bit over the last 10 years, the basic necessary capabilities have stayed the same. When we speak about fairly stable, we should emphasize the fairly. In the digital age it is not uncommon that entire business models change. Amazon started as book retailer, developed into the largest provider of cloud storage to a provider of online content and much more. Still, capabilities have the advantage that they are constant enough to build a plan around them. Business capabilities form a crucial part of great IT strategies: They specify how we are going to win and how IT is helping along the way.[4]

As companies launch business capability building exercises, many business architecture teams struggle with the issue of what is or is not a capability. Determining if something is or is not a capability, differentiating capabilities from other capabilities and validating these issues within the context of your business model can be challenging. The following guidelines provide insights into how capabilities can be identified and differentiated when establishing your capability map:

  • Determine if a capability is actually a capability because it describes what; not how; something is being done. Faxing and emailing are not capabilities because they describe ‘how’ a capability fulfilled. Similarly, mailing an invoice is not a capability. Capital Management is a capability because it describes what is being done.
  • Capabilities have outcomes: Communication with a client or customer is not really a capability because it has no clearly defined outcome. A Customer Information Management capability would, however, have the outcome of ensuring that a customer has high integrity information associated within it at all times. Lower level capabilities have more specific but related outcomes to their parent.
  • Make sure a capability is not a process or value stream: Topic categories that require movement, such as the concept of authorizing, validating or engaging in some sequence of activities fall into a process category. A process or value stream stands out because it veers into “how” something is being done.
  • Capabilities must be clearly defined.: Capabilities must have clear definitions at every level. Calling something Account Management requires not just a definition of the management portion but also the account portion of the term. This forces a common view of your business.
  • Capabilities are unique in terms of intent: If two capabilities seem alike, question their intent. For example, if a Customer Management capability appears to be the same as a Partner Management capability, consider that customers are inherently different than partners (the fact that they may be one in the same notwithstanding) and demand a different set of management capabilities. Conversely, managing customer information could easily double for managing prospect information if the business can align it terminology and thinking around this concept.
  • Capabilities are framed by their parents: The relationship within a given capability between a parent and its children is not process centric but just a detailed refinement of the parent. For example, if a capability called Risk Rating is contained within a higher level capability called Solution Management, then this case of risk rating is focused on delivering or furthering a solution. If a Risk Rating capability is shown under a Risk Management capability within a Capital Management capability, it is mostly likely furthering an aggregate view of risk management that is not tied to a given solution.
  • Capabilities are unique based on the information they require and use: One capability may use or produce certain information that a similar sounding capability may not require or use. Again, an aggregate view of Risk Rating when decomposed may only look at a country or a class of customer while a similar sounding capability within the context of Solution Delivery looks only and entirely at information that is tied to that specific solution. In addition, a capability definition must align with the corresponding definition of that business asset. Account must be defined in the same way as it is in the definition of Account Management.
  • Capabilities can be framed by the roles and resources that have those capabilities: Can two people switch jobs and still perform adequately well in relation to two similar sounding capabilities? For example, if the corporate risk manager switches jobs with an underwriter, will each person still be able to fulfill their roles within an equivalent level of effectiveness?
  • Capabilities are purely business views of the business: It does not matter if a capability is automated or not. It is a capability if the business can and does have this ability – even if it is weak. Keep the discussion of systems on the sidelines as you go through this exercise. Later, when your capability map has matured, you can begin validating and using it through value stream, organization and IT asset mappings.[5]

Drafting Business Capability[6]
While there is no one-size-fits-all approach, firms can use a top-down or bottom-up approach, or a combination of the two. The Figure below illustrates a four-step, top-down approach.

Business Capability Top Down Approach
source: Sapient

Business Capability vs. Business Process[7]
Generally speaking, a business capability is the abilities needed by an organization in order to deliver value. It’s the ability of an organization to do things effectively to achieve desired outcomes and measurable benefits and fulfill business demand. Business Process Management is the way you manage the processes to achieve operational excellence. However, many times, even the industry experts are not always on the same page regarding definitions of business capability or business process, how some of the standard artifacts for business capability management might be developed; how broad scope the process management should go for; or more fundamentally, how to differentiate the interdependent concepts such as business capability and process?

  • Strategic vs. Executable: Broadly there are two different perspectives/views of Capabilities:
    (1) Capabilities are processes and competencies viewed strategically.
    (2) Capabilities are the resources required for a certain mission/purpose. Capability and process are two viewpoints of an organization. An organization has the capability to deliver outcomes; an organization executes processes to deliver an output.
  • Abstract vs. Detailed: Capability is an attribute of a system – so it is used largely as an abstraction of a system. The capability is used in the context of assessment – capacity to realize an outcome, existing or intended, or potential – which is in stark contrast to the use of the process. With the capability view, being more abstract, no detail is provided as to the means by which the transformation occurs, nevertheless, the system has external interfaces which deal with inputs and outputs. With the process view, being more logic and detailed, the process shows the receiving processes, the distributing processes, and the transforming processes. Both views can logically show inputs and outputs – it simply depends on how the viewpoint is being used, as to whether inputs and outputs are included. For example, business systems and information systems each has inputs and outputs, and the system is the means by which the inputs are transformed into outputs. In this context, a capability is an abstraction of a system and therefore also has inputs and outputs just as the system-of-interest for which the capability is referenced.
  • What vs. How: Capabilities are WHAT abilities/ competencies an organization has/needs. Processes are HOW an organization does something. The fundamental difference between Capabilities and Processes is “What vs. How.” Adding inputs and outputs to a Capability (a What) turns it into a Process (a How) as Inputs and Outputs imply/indicate transformation. It makes no difference if a process is described a system, its purpose is still to transform/process inputs into outputs. Capability and process viewpoints consider different characteristics (what vs how outputs vs. outcomes). What and how much you model for business capabilities depends on what you intend to use the model for. Capabilities can be mapped to the processes that instantiate the capability, the technology used, the information required, organizations, etc. They can also be assessed for maturity, costs (based on the technology, systems, labor, etc.), relationship to strategy.

Both capability view and process view are useful in managing business transformation, which to use depends on the purpose you have in mind: Strategic re-think of ‘What’ vs. “ Executable knowing ‘How’; and the high mature and high performing business depends on its differentiated sets of dynamic capabilities which are underpinned by the well-managed business processes matrix and portfolio within the organization.

Between Capabilities and Processes, which is more important?[8]
If you do not belong to a particular school of thought and are not wedded to either the business process camp or business capabilities camp, the reality is that each of them has their value in modeling and encapsulating the essence of an enterprise.

  • The business process camp argues that a company is interested in how to get things done and process models are an excellent depiction of how the business flows. They claim that since capabilities are self-contained and abstract concepts, they only capture the structure, but not the flow. Furthermore, they lament that just because one uses a noun instead of a verb, a process does not become a capability.
  • The business capability camp argues that since processes can change frequently – due to technology advances, regulation, internal policies, channel preferences, etc – they are volatile and hence it is not wise to model an enterprise on process models. Instead, they profess that business capabilities capture the essence of what a business does and focuses on the outcomes. A well-defined capability set is mutually exclusive and collectively exhaustive and hence a more stable base for modeling an enterprise.

There is truth to both arguments. However, it is also important to note that capturing the essence of a complex enterprise into a single overarching model is impossible. Instead of hoisting either capabilities or processes on a pedestal, at the exclusion of the other, the best path is to adopt an “all of the above” model with a specific set of deliverables based on specific needs.

How and Where can Business Capabilities be Used[9]
Business capabilities can be used across the board in a variety of business situations, such as:

  • Post merger and acquisition (M&A) IT consolidation. For M&A integration projects where cost synergies can bemachieved by consolidating certain core and support functions, a business capability map for both organizations can act as a starting point to identify areas of overlap.
  • Strategic planning and IT investments. Business capabilities provide a foundation to the capital budgeting exercise for multi-year, long-term planning. A gap between current-state and future-state business capabilities can identify key areas of investment and allocate planning dollars appropriately.
  • Product definition and roadmap. A new service, product or offering that needs to be launched can use a capability map to conceptualize the overall offering. In an agile- and Minimum Viable Product (MVP)-based product culture, a capability map can keep the final product vision in perspective while defining and articulating the product roadmap.
  • Application portfolio rationalization. Many instances of the same functionality may be duplicated by different applications within different business units of the same organization. Any business case for application portfolio rationalization could benefit from a business capability map as the primary input.

The Business Capability MetaModel that defines an emerging perspective of capabilities and how these relate to both the enterprise’s strategy and business process architectures.

Business Capability Metamodel
source: Confiance Group

From the above model, the following observations can be made:

  • One or more business capabilities support a corporation’s strategic objective, and one or more strategic objectives may be supported by the same business capability.
  • One or more business capabilities support a capability outcome, and one or more capability outcomes can be supported by the same business capability.
  • A business capability network hierarchy can be developed showing which internally-driven business capabilities support which customer-driven business capabilities.
  • It is possible for a business capability to be enabled by one or more business processes, and a business process can enable one or more business capabilities.
  • Business processes are made up of data, products and services, an org structure, locations and a technology infrastructure.
  • IT capabilities are enabled by one or more business processes and one business process may enable multiple IT capabilities.
  • IT capabilities define a technology ability so as to either satisfy an internally-driven or customer-driven (or both) business capability. However it is possible for an IT capability to exist without relating back to a business capability.
  • One or more IT capabilities support a capability outcome, and one or more capability outcomes can be supported by the same IT capability.[10]

See Also

References

Further Reading