- SAP Managed Tags
Problem Statement:
You are embarking on transforming your business by replacing/upgrading your 20-year-old Enterprise Resource Planning (ERP) platform. You are in the Explore phase and looking for a realistic scope and budget for implementation.
Your goal is to implement effective and efficient processes on a new platform. However, in practice, processes are often inadequately documented. Significant uncertainty arises without a clear understanding of the degree of changes required to redesign and implement processes. This uncertainty complicates the estimation of scope and budget. A business architecture that provides a structured approach to understanding and estimating the transformation required at the process level must be created to reduce this uncertainty.
Why it’s essential to understand Business Processes
Every organization (business, government, not-for-profit) follows business processes to create value by completing tasks in a given sequence. Using processes, business users exchange information, money and materials to create value (by completing a given task). The success of the business is dependent on the efficiencies and effectiveness of these processes. They may complete all steps using paper, phone calls, and fax or use 100+ well-connected systems. These processes may not be documented at all, partially documented, or not updated in years.
Small businesses don’t formalize or document business processes, as an individual task processor's memory can hold ‘how things are done here.’ Their record-keeping systems are simpler, and transaction volume is low. They rely on an individual’s capability to get the job done. It doesn’t mean they don’t have to deal with complexities during transformation, but due to the smaller scale of their operation, they can ‘manage’ transitions in technology and market conditions.
However, in large organizations, processes span various business units, departments and IT applications. Data/process steps overlap between systems, often managed through swivel chairs (duplicate entries) and barely linked interfaces. Many process variances arise due to individual preferences as they slightly twist/bend/adapt the system to accommodate their way of working. Often, this results in adding extra business rules/logic to the application. Over the years, as people change jobs and processes evolve, this extra logic becomes ‘illogical/redundant/burden’, aka Technical Debt. It's challenging to eliminate the technical debt because you don't know what skeletons you will find.
Typical reasons for not documenting business processes:
- There is no clear ownership for documenting end-to-end processes. Business analysts often work in silos of their expertise and do not cross departmental boundaries. System analysts often focus on 'system steps' and interfaces, and ignore manual tasks.
- Business users go through the daily motions of process execution based on ‘how things are done here,’ and they have a hard time describing end-to-end processes.
- Users and analysts are so busy completing assigned tasks that they lack the time, energy, and motivation to stop and document the process.
- Documenting business processes seems enormous when you extrapolate 100s of processes across 10s of departments utilizing multiple systems (applications).
Defining business architecture iteratively early in the project will resolve the above issues.
How do you define a business architecture for your transformation project?
Two separate artifacts define business architecture
1. Business Capability Model (BCM) that describes the complete set of capabilities an organization requires to fulfill its mission. It’s typically structured hierarchically in three levels and describes WHAT an organization needs to deliver business value and succeed.
Figure 1 - SAP Reference Business Capability Model (BCM)
2. A Business Process Model (BPM) describes the business processes of an enterprise based on a standardized set of value-creating activities. It’s typically structured hierarchically in levels and describes HOW these value-creating activities will be performed
Figure 2 - SAP Reference Business Process Model (BPM)
Linkage between BCM and BPM:
- The lower process levels will identify which set of capabilities a process needs to execute effectively and which processes a particular capability will serve.
You can use hierarchical elements of BCM and BPM for various purposes. A few advantages of building hierarchies are:
- Group higher levels into ‘Strategic,’ ‘Core,’ and ‘Supporting,’ per the organization's strategic objectives.
- Performing heat mapping for capability maturity, risks, and investment requirements
- Ease of scheduling workshops and assigning capability/process owners and subject matter experts.
- Estimate implementation and change management efforts at various levels of the hierarchy
Note: SAP Reference Business Architecture provides template/industry variants for BCM and BPM - SAP Signavio Process Collaboration Hub.
The Business Roles catalog and Business Data catalog are two other business architecture artifacts created in the explore phase. They can be utilized as input to create business activity flowcharts. This blog does not cover business capabilities (L3) linking to Solution capabilities.
Why do you need to create a business process hierarchy?
According to the SAP Activate methodology, the business scope is defined in the Explore phase of the project. You will need the following to estimate the transformation scope/effort.
- List of business processes that are generally in scope (to be refined in Fit-to-Standard [F2S] workshop)
- Scope of change at a process level, including a) effort to configure the system for to-be processes and b) change management efforts
The above is achieved by capturing delta requirements during fit-to-standard workshops.
A business process hierarchy (BPH) can structure a list of business processes that are part of the project's overall scope (also called a business process catalog). This process is iterative and typically incomplete until all F2S workshops are complete.
How do you create a business process hierarchy?
You can utilize BCM or BPM to create BPH.
Option 1: Business Capability Model (BCM) based grouping:
- Business Domain (L1), Business Area (L2), Business Capability (L3) + Business Activity (L4)
- A functional view of the business [difficult to stitch together E2E process]
- Assing business process (L4) to one prime business capability (L3). Typically, there is more than one capability required to perform a given process, so assigning a prime will make it easy to visualize the hierarchy
- Easier to identify links between business capabilities and solution capabilities
Option 2: Business Process Model (BPM) based grouping:
- Business Process (L1), Business Process Module (L2), Business Process Segment (L3) + Business Activity (L4)
- Process-centric [difficult to tackle duplicate capabilities within an organization]
- It is easier to accommodate process variances at higher levels in the hierarchy.
- It is difficult to assign a single end-to-end process owner as processes span multiple functions.
- The nested nature of BPM makes it challenging to visualize in a tabular list.
Figure 3 - Business Process Hierarchy example for "Manage Purchase Order"
A Business Activity (L4) can be referenced in multiple higher-level processes/process variances. Business activities can be nested inside other business activities to break complex business activities with many steps into manageable activities.
Business Activity (Level 4):
- A 'granular business process' creates value for internal or external stakeholders.
- will have consistent naming conventions
- further broken down into tasks (level 5) and steps (level 6)
- will have a unique process flow that is defined using a BPMN diagram
- Steps to perform in a given sequence with decision points
- Application/s [input from Application catalog]
- Data utilized/analyzed/updated/produced [input from Business Data catalog]
- Roles/agents responsible for the activity [input from Business Role catalog]
Fit-to-standard workshops will evaluate business processes at this level. During these workshops, define 'to-be' Business Process, create flowcharts (in BPMN), and capture delta requirements (backlog). Use SAP Best Practices as a starting point (reference SAP Signavio Process Navigator).
Figure 4 - Understanding links between BCM, BPM, Business Activity, Task and Steps
Tips:
- Start with the SAP reference content and tailor it to your industry/organization needs.
- Defining the first three levels before diving into listing business activities (L4)
- Involve the Business and IT user community
Caution:
- You can start this exercise on a spreadsheet, but it’s not scalable and not great for collaboration.
- Get the right tool to manage BCM (e.g. #SAP LeanIX), BPM and BPH (e.g. SAP Signavio)
- Set up naming standards.
You have now defined the Business Process Hierarchy and have the list of all required business activities (L4). You are ready to execute a fit-to-standard workshop to capture the backlog <blog - Conduct F2S>. You can summarize the backlog at various hierarchy levels to scope the estimated project cost and change management efforts.
Conclusion:
Defining a business architecture is a crucial step in any transformation project. It provides a structured approach to understanding and improving the processes that drive your organization. By mapping out these processes, you can identify inefficiencies, streamline operations, and ultimately achieve your transformation goals. Remember, the success of your project depends on transforming business processes (they need to attend the party!). So, take the time to get it right; your efforts will pay off in the long run.
Reference:
- TOGAF Value Streams Guide
- SAP Signavio Process Explorer – Accessed Jan 20, 2025 SAP Signavio
- Process Mapping Basics: Guiding Your Organization Toward Effective Process Mapping - SAP Signavio - Accessed Jan 20, 2025
- The Top 5 Mistakes You Can Make When Naming Business Processes - Accessed Jan 20, 2025
- Book: Business Architecture: Collecting, Connecting, and Correcting the Dots, by Roger Burlton. Technics Publication
Bluesky
