Skip to main content
All CollectionsArdoq Use Case SolutionsBusiness Process Management
Business Process Management: Purpose, Scope and Rationale
Business Process Management: Purpose, Scope and Rationale

Ardoq's Solution for Business Process Management, why it's valuable for organizations, and how business processes can be documented in Ardoq

Jon Scott avatar
Written by Jon Scott
Updated over 4 months ago

Contents

What is the Purpose of Ardoq’s BPM Solution?

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:

  • What are the business processes across my organization?

  • What technologies are used to deliver those processes?

  • What processes enable business capabilities?

  • How effective/efficient are my processes?

    • How mature is the process?

    • What is the duration of the process?

    • What percentage of the process is automated vs manual?

  • Who is responsible for the business processes?

  • What processes deal with sensitive data?

The answers to these questions can be achieved by:

  1. Documenting business processes across your organization

  2. Mapping processes and activities that realize Business Capabilities

  3. Documenting the technologies used to deliver the processes

  4. Documenting which roles is responsible for parts of business processes

  5. Capturing key metadata around each process and activity

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.

  • Facilitates Process Standardization and Consistency: BPM helps to standardize processes across the organization, ensuring that tasks are performed consistently and efficiently. This is particularly important for companies who want to streamline operations across multiple locations or comply with industry standards and regulations.

  • Aligns Processes with Strategy: BPM helps align business processes with the organization’s strategic objectives. By mapping processes, identifying inefficiencies, and streamlining workflows, BPM ensures that operational activities are aligned with strategic goals.

  • Improves Visibility and Transparency: BPM provides visibility into how various processes function within the organization. This visibility allows decision-makers to understand how each process contributes to the overall strategy and where improvements can be made.

  • Improves Compliance and Risk Management: For industries subject to regulatory compliance, business process management helps ensure that all necessary steps in a process are followed and documented appropriately. It also aids in identifying and mitigating risks associated with various business processes.

Scope and Rationale

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.

What is a business process and how does it compare to a business capability?

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:

  1. Focus: Business processes focus on the "how" - the sequence of tasks, decisions, roles, and systems involved in executing a particular operational workflow. Business Capabilities focus on the "what" - the overarching abilities an organization needs to successfully run its business and achieve its goals.

  2. Level of abstraction: Business processes are more granular and detailed, outlining the specifics of how work gets done. Business capabilities are higher-level and more conceptual, representing the collective skills, resources, and knowledge required.

  3. Stability: Business processes tend to be more fluid and changeable as operations evolve. Business capabilities are typically more stable over time, as the fundamental abilities a company needs may not change drastically even if processes are redesigned.

  4. Scope: A business process has a defined start and end point. A business capability is broader, often comprising multiple processes and cutting across different functional areas.

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.

Ardoq's Modeling Approach

Modeling Processes

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.

Process Category

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.

Processes

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

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

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.

Flows between Process Activities

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

Map to the Process or the Process Activity

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.

Information in the Processes

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.

Process Instances

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

Process Framework vs Business Capabilities

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

Version

Date

Responsible

Rationale

1.0

7/26/24

Jon Scott

Published

Did this answer your question?