Contents

Ardoq’s Business Process Management (BPM) Solution enables organizations to document the business processes and the process activities within an organization and then connect them to the Enterprise Architecture. This solution addresses the following questions:

The answers to these questions can be achieved by:

By capturing and analyzing your processes across the organization you can realize several benefits associated with having a clear understanding of your processes and how they connect to the rest of the Enterprise Architecture.

Our goal with this Business Process Management solution is to capture or extract just the right level of information out of processes typically captured through business process modeling and modeling tools and connect it to the rest of the enterprise architecture to derive actionable insights from the data. Business Process Management allows for valuable insights without the large overhead of maintenance that comes with modeling. Another goal of the business process management is to support both customers who have external process modeling tools as well as customers who don’t. We do this by providing a metamodel and guidance on the right level of detail to maximize value over effort.

A business process is a structured set of activities that produce a specific service or product for a particular group of customers or stakeholders. This set of steps is designed to achieve a defined outcome, and it involves people and systems who often work across organizational boundaries.

A business capability, on the other hand, is a more abstract concept that describes the organization's capacity to achieve a specific business outcome or goal. Capabilities reflect the organization’s potential or ability to perform a set of related activities, regardless of how these activities are performed or what processes are used.

While processes are about the execution and the "how”, capabilities focus on the capacity and the "what." Together, they provide a comprehensive view of organizational performance and potential, guiding both strategic decision-making and day-to-day operations.

The key differences between business processes and business capabilities are:

In summary, business capabilities define what an organization must be able to do at a strategic level, while business processes specify how those capabilities are operationally executed through detailed workflows and activities. Capabilities provide the "what" high-level view, and processes provide the "how" tactical implementation details. Check out the What is the difference between Value streams, capabilities and process article to learn more about the definition and distinction between these 3 business architecture concepts.

When modeling business processes, it is important to structure and classify them for easy management. There are several ways that this can be done, and depending on your organization, this may vary. Process frameworks may share similar terminology with business capability models, making it difficult to differentiate between them. We recommend leveraging a process framework such as APQC because it provides you with the taxonomy, structure, and means for classification. This will make it easier to manage your processes. If you believe the APQC framework is too complex, you can remove what isn’t needed and start small.

To better manage and structure processes, we use the Process Category component type as a categorization component.

This component type is used to group related processes together and can represent the hierarchy that may exist at any number of levels above the process. This is similar to the Category and Process Group in the APQC framework. This allows for a clear distinction between the process and the grouping structure.

Determining the right level

The structure of the process hierarchy is dependent on the level of detail or granularity needed for your organization. The Business Process Management use case can be modeled down to the level of the process or process activity. If you just need the process then the leaf node (bottom-most component) of the hierarchy would be a Process component.

However, if you need to have a more detailed understanding of the process you can include process activities under the process.

With this approach the leaf node becomes the process activity. See the process activity section below for more details.

From the Process, you connect to other components in the EA graph such as role, technology, business capability and information. In some situations, integrations with process modeling tools may prevent this level of abstraction. Because of this we also support the connection of lower level process activities to role and technology. We always recommend connecting business processes to the business capability at the level of the Process rather than the level of the Process Activity. See the section Process Activity Mapping

Sub-processes are like activities, but ones that themselves are further broken down into constituent activities. We use the Process component type to represent them, but in all other respects, they can be considered similar to Process Activities. We model these sub-processes as Processes that support self-reference with the Is Supported By reference allowing these processes to support multiple Processes.

Process Activities are the operational tasks that support the Process. Because Process Activities are oftentimes unique to the process itself, they are represented as children components to the Process. This approach is much easier to maintain, reduces complexity and allows for the ability to map unique flows between activities. In situations where a process activity is similar to another process activity, evaluate the naming convention of the activity to avoid duplication.

Because Process Activities are unique to the process, you can use the Flows To reference to create process flows between the various activities.

Processes need to be connected to other aspects of the organization such as Technology, Roles, and even Data to show how they are delivered. Our recommendation is to map these connections at the Process level. However, sometimes there is a need for greater fidelity. Based on the needs of the organization those connections can be made to the Process Activity level instead of the Process level. While this approach has much higher maintenance it provides deeper context into what is happening at the level of the Process Activity.

When it comes to mapping business capabilities we still recommend mapping capabilities to the Process level and not to the Process Activity level. Mapping capabilities to the Process Activity level creates multiple references that need to be maintained and are often referencing the same capability.

Another key aspect of every process or process activity is understanding what data is leveraged throughout the process. We can surface this information by connecting Data Entity components to the Process Activity. Understanding this will help you know when a process might be processing certain types of protected data and need to follow certain data regulation requirements. See the Data Lineage metamodel for more information on capturing and structuring your logical data in Ardoq.

In some situations, you may find that business processes are used by multiple divisions or business units where the process is highly similar, but with slight variations. When there is a difference between two processes in technology, roles, or process activities we recommend creating a Process instance as a child of the atomic Process, similar to how we handle business capabilities instances in the enterprise patterns article here. An example of this is an Invoice Customer process used in both the US and the EU. Due to regulatory requirements, an additional Process Activity is needed in the EU instance. While the process is the same, the activities and possibly technology differ due to EU regulations. In this situation, we would create two Process instances (Invoice Customer - US, and Invoice Customer - EU) as children of the atomic Invoice Customer Process. For more information on atomic and instance components please read the Enterprise Patterns article

When you look at a process hierarchy and capability hierarchy they look very similar. A high-level process (ex. Manage Customer Service) sounds a lot like a high-level capability (Customer Service Management), and this can lead to confusion and the question: Which one is it?

Ultimately these are different, but connected lenses through which you can look at how your organization operates, and comes down to your organization’s ontology. If your organization is process-centric then using a process framework might resonate better with your organization. However, Ardoq has chosen to use the business capability as the primary lens to look at what the business does and to overlay analysis (cost, maturity, etc) on the capability through its connections into the rest of the EA graph.

If you are part of an organization that does not leverage business capabilities but uses the business process lens then it is possible to do a similar type of overlay of analysis that might otherwise be done with capabilities. However, because our use cases use the business capability lens most of our preconfigured analysis takes place on capabilities. The reports, fields, and gremlin would need to be adjusted to account for the difference in component type, reference types, and directions.

Document Version