Within TVH Parts, we are in the process of implementing Business Capabilities, Business Processes and Use Cases. In this article we'll have a closer look at the theory behind these concepts, we will discuss how they are related to each other and how we are trying to put them into practice at TVH Parts. Please note that this article is not about how you should create Business Processes, Use Case or Business Capabilities.

So let's start:

• Business Capabilities define WHAT a business needs to do to be successful/achieve their business goals
• Business Processes describe HOW things are done (so that the Business Capabilities are realised)
• Use Cases describe how Business Processes are REALISED by means of software systems/applications

(If you want to learn more about the details of Business Capabilities, Business Processes or Use Cases you can use the hyperlinks provided in this article)

When we combine these 3 concepts in one map, we can offer an enterprise overview of which Business Capabilities are covered by our processes and our applications (you can even reverse it and offer a view of what isn't covered yet so we can identify the missing gaps for future IT investments).
The Enterprise Map also offers different views/perspectives/lenses to our user-base: a strategic perspective, a business perspective and a system-/IT-based perspective:

• Enterprise architects, Enterprise Strategists and Decision Makers can benefit from the Business Capability Maps and their correlation to the processes and the IT landscape
• Business users may benefit from a pure business-oriented description/model of their Business Processes (modelled in BPMN)
• (Functional) Analysts and Developers can have an interest in the more system-oriented perspective of the business process realisation (modelled in Use Case Diagrams)

All these different models are complementary allowing users to drill down/go up to the desired level of abstraction when needed.

Now how did we come to the enterprise-level map and the different underlying models? The most common way is to start from the Business Strategy and the Business Capabilities (the WHAT) and drill down to the lower levels (the HOW). Here at TVH Parts, we did it the other way around starting with the Application/IT Systems, because of the following reasons:

1. the historical reason: over the past years the company grew very fast, as a result of which documenting did not get the highest priority
2. the modelling skill set reason: when it was decided to start with a dedicated analysis team at TVH Parts, most of the analysts at that time came directly from the Business, as a result of which the modelling skills and knowledge were more "pragmatic" than "theoretical". The main focus was on documenting the "lower level", meaning the systems and the functional requirements (via UML Use Cases and UML Activity/Sequence Diagrams)

At some point in time, we realised we also needed a "higher level" of abstraction: describing how the processes as such worked and how these are implemented by our IT systems. Therefore we started an exercise to model our Business Processes (using the BPMN standard).
This exercise was done via several workshops involving business users, system support users and business analysts. Via these interactive workshops, the business tasks/activities were discovered, defined, discussed and linked together in a logical sequence so that they formed the blueprint of the actual business workflows/processes. This BPM exercise was performed on different levels going from Level 0 (the top level) to Level 3 (the more in-depth / task-related level). In this way, we could walk through the processes from a high (abstract) view and drill down to the daily tasks performed on the shop floor. This already resulted in a high-level mapping of our (critical) Business Processes. 

Currently, we are in the process of constructing the TVH Parts Business Capability Map. This should allow us to map our Business Processes to our Business Capabilities to discover whether they indeed support our business goals/strategy (and more important where there is a gap).

Going through this procedure, we've realised that constructing an enterprise-level map is not a straightforward exercise that you perform from A to Z. The most important thing you need is to train the (right) people in the different modelling techniques and (theoretical) frameworks and that they are willing to put this into practice in their daily work. We also realised it's not a "first time right" exercise: we've needed several iterations to go through the different modelling levels before coming to an enterprise map.

As of today, this exercise is not fully completed but we are confident that we will arrive where we want to be: a blueprint of the enterprise from different viewpoints.