According to Forrester, Capability Map is a model of the firm associating the business capabilities, processes, and functions required for business success with the IT resource that enables them.
A business is characterized by the capabilities required for that business to accomplish its objectives. Each capability is itself a collection of actions the business takes — like responding to a customer’s service request or defining sourcing strategies for new products.
In a business capability map, each business capability is associated with -
- Business goals. The importance of a capability is characterized by expected outcomes resulting from the capability, expressed as strategies, objectives, and metrics. These work best when business management defines specific results for each capability — like reducing cost per package-mile for a shipping capability. But outcomes will inevitably cross multiple capabilities — like the goal of speeding idea-to-product time, which spans market research, product development, and manufacturing capabilities.
- Processes and functions — and the information they work on. Business capabilities comprise business processes and functions that flow within and across them — like the process order-to-ship, which spans capabilities like sales, order taking, inventory management, and shipping. And the business processes and functions have information they work with — like order-to-ship process and associated applications, which manage a list of goods requested by a customer against finished-goods inventory or manufacturing capacity.
- The “bill of IT.” A business capability map employs a “bill of IT” — the collection of the hardware, software, and IT services required to enable a specific business capability. The bill of IT is simple when there are dedicated systems but becomes complicated when a single system supports multiple capabilities — as in a virtualized data center.
- Future-state capabilities. Capability maps can be the basis for comparing the “as is” and a “to be” state, yielding a picture of capability, process, and bill of IT gaps between these two states. And because the model maps capabilities to business goals, organizations, processes, and information, the future-state capabilities can form the basis for both IT and business planning.
{ 1 trackback }
{ 4 comments… read them below or add one }
Hi, courteous posts there
through’s exchange for the interesting word
Reading about the “Bill of IT” it sounds “wrong” to me. It assumes the business runs on IT alone. Under the assumption that IT is no more than a facilitator for executing processes (as a whole or partially), it sounds like the “Bill for IT” should read “Bill for PI” – where PI is Process Infrastructure. refering to Process Infrastructure will allow inclusion of all facilities and resources that are required to achieve the business goal. Examples besides IT may include skills and capacity for labour in manual process steps, location/mobility/availability of resources, etc. Using PI instead of IT will allow “Enterprise” wide architecture. It also helps facilitate the transalation between strategic and teactical levels in the organisation. It makes the requirements for a business capability clear and allows easy creation of business roadmaps / prioritisation of business initiatives.
Absolutely go along with Jurriaan’s comment above, business capabilities do not necessarily require information technology, though they need ‘systems of information’ of some kind, e.g. language and signaling for control. Enterprise architecture is about defining a structure of business capabilities, enabled by business processes, enabled by systems of information, which may be enabled by IT.
Agree with the previous posts. Capability Maps can only be seen within the wider context of Business Architecture (as a subset of EA), comprising also business strategy, organizational structure, business entities, and business processes. Ideally such an architecture follows the principles of a building’s architecture that doesn’t describe how the bricks are being laid or the steel is being welded nor how exactly which work steps people will perform in which room.
This means that IT-focused models like TOGAF, CISR and the like are completely useless as long as they don’t take into account what business is all about, namely people and interaction. And once you look at people it is not standardization and reuse that is delivering benefits but knowledge, skills and diversity, which an architecture must support and enhance.