- SAP Managed Tags:
You are about to transform your business by replacing or upgrading your 20-year-old Enterprise Resource Planning (ERP) platform. With a 'Cloud First' approach, you have presented the project's key objectives to management and chosen the SAP Business Suite as your future ERP. Your sandbox environment is set up with the Enterprise Management Layer and SAP Best Practices. Now, you are ready for transformation. What's next?
Fit-to-Standard (F2S) Workshops
As per the SAP Activate methodology, a few tasks happened during the explore phase.
- Define business architecture <blog>
- Perform a fit-to-standard analysis to capture Delta requirements (backlog) using SAP Signavio Process Manager.
Points to note for process design during Fit-to-standard workshops
- Create a structure of ‘Business Process Hierarchy’ before you begin workshops <blog>
- The hierarchy will help you schedule workshops and assign subject matter experts
- Hierarchy will help you to summarize/aggregate the findings at various levels
- Workshops are driven by business process owners who are transformation champions and complimented by strong IT SMEs
- Workshops are an opportunity for the IT team to understand what outcome the business wants to achieve
- Consider all relevant applications and steps to complete a business process
- Don’t just focus on SAP-relevant steps. Include other system steps/interfaces, and don’t forget to capture manual steps
Capturing Delta Requirements in Fit-to-Standard Workshops
Fit-to-standard workshops are structured around Business Capabilities (focused on business or functional areas) or End-to-End Business Processes (focused on processes). These workshops explore functionality, demonstrate how solutions and best practices meet business requirements, capture delta requirements, and enable business process experts to define ‘to-be’ processes.
Delta requirements are identified, discussed, and then added to the backlog. The backlog consists of documented requirements, improvements, or functionalities required to complete a process. These items are prioritized, iteratively reviewed, and refined. This prioritized backlog will be used for the development activities in the Realize phase.
Understanding Business Process
Before you conduct Fit-to-standard against a given process (business activity), you will need to understand what business activity is.
Business activity is the last layer in the business process hierarchy (refer to this blog for more details).
Anatomy of a Business Activity (modular business process):
- A 'granular business process' creates value for internal or external stakeholders.
- A business activity is a combination of the following:
- Applications: Which applications will be used?
- Data: What data will be utilized, analyzed, created or updated?
- Users: Who is going to execute it? (Role/agent/AI!)
- will have consistent naming conventions. (follow SAP reference or APQC Process Classification Framework)
- will have a unique process flow tefined using a ‘BPMN’ diagram.
- will have a clear 'start' and 'end'
- will have a unique sequence of tasks (level 5) to be performed. Each task is divided into steps (level 6) <see figure 1>
- Tasks (L5) will be performed by a user (in a given role)/agent. Users will utilize application/s where data is used/analyzed and output/value is created. Policies may exist, and the organization may have business rules to complete these tasks.
- Each task (L5) will be broken down into steps (L6). These steps are performed in a given application or used by an interface. Steps will include required business logic/rules.
Figure 1 - Understanding Business Activity Components
Understanding delta requirement collection
SAP provides standard solution flow diagrams and best practice diagrams. During the fit-to-standard workshop, delta requirements will be collected at multiple levels. The following diagram <figure 2> shows the level at which the delta requirements are captured.
Figure 2 - Capturing Detla requirements (backlog)
In F2S workshops, you are helping business users to describe requirements in the business language. This can be achieved by grouping delta requirements into these four categories. a) Process Focused, b) Application Focused, c) Data/Information Focused, and d) Role Focused. In the Realize phase, you will be able to group these into typical WRICEFW categories for development and work distribution.
a) Process Focused
1. Confirm whether a process is required at a process level. (scope confirmation)
- Examples:
- Create a purchase order for services > Required
- Creating sales orders for services > Not required
If additional processes are required, then it's a scope discussion with the project team. Beware of scope creep and the temptation to add/remove adjacent processes.
2. What other process variants exist
- Examples:
- Create a purchase order for the project purchase
- Create a purchase order for the stock purchase
- Create purchase orders for services based on contract
Caution: This is a slippery slope for future enhancements. More variants will result in more business logic and business rules, especially when different business units require variances to execute the same processes.
b) Application focused
3. Business rules: (expression of policy)
- Examples:
- Purchasing Approvals above a certain threshold
- Applying tax codes and calculation
Note: Challenge outdated policies or rules that are no longer relevant. SAP SMEs should focus on configurable rules.
4. Business logic (expected system behaviours):
- Examples:
- Status updates for an outline agreement
- Budget control checks
Note: Avoid convoluted and 'one-off' scenarios. Look for the intended outcome. Avoid adding rules that create detours and unnecessary stops.
5. Enhancement/extension requirement
- Examples:
- A field on the PO is required to indicate ‘recycled material.’
- Derive material handling requirements for dangerous goods
Note: If business rules and business logic can not be implemented by application configuration, then additional extensions and enhancements are required. Remember that Clean Core starts with simple processes and data structure!
Tip: Always ask clarifying questions while defining business logic/business rules to minimize enhancement/extension. Implementing legacy logic (or illogic) without rationalizing will create technical debt.
6. Interface requirement
- Example:
- Send purchase orders to a specific vendor via an electronic interface
c) Data/Information focused
7. Data requirement
- Example:
- Enterprise Structure: Company codes, Plants, Sale Org
- Master data: Material, Vendor, cost center etc.
- Transaction data: Purchase orders, Purchase requisition
- Data requirements can be captured here, e.g., Data quality, retention, and validation.
8. Reporting requirement
- Example:
- Report to see purchases from a vendor in a given time (for ATIP)
9. Output/Forms
- Example:
- PO printouts (including PDF) as per Canada’s procurement guideline
d) User role/Security focused
10. Automation:
- Example:
- Auto approval for PO/IR less than a certain amount
- Tip: Processes designed with clear business rules, business logic and data structure are prime for automation
11. Security/Access control
- Examples:
- The purchasing officer can not enter goods receipt or invoice receipt
- Mask credit card numbers
Rules of engagement during Fit-to-Standard (F2S) exercise.
- This exercise simplifies processes by minimizing variances, establishing clear business rules and logic, and documenting precise requirements to achieve desired outcomes. Avoid documenting requirements as ‘as-is’. The status quo is not your friend.
- Convoluted and contradictory rules/logic will result in messy processes with unnecessary coding that must be maintained for a long time.
- Simplify processes and data structures. This will positively impact user experience and reduce application management costs for years.
- Note that specific enhancements and integrations are inevitable if they must meet legislative requirements or interface with other existing systems. Focus on re/designing these extensions in a compliant manner.
- Once these requirements are reviewed, refined, and approved, SAP SMEs can work on developing process design documents and creating specs for configuration, enhancements, extension, and integration. Additional requirements, such as data conversion and non-functional requirements, can be captured at a higher level.
- Use SAP Signavio Process Manager attributes to capture requirements and notes. Define requirement categorization, priorities, dependencies, etc. Capture dependencies
- Don’t squander this opportunity to get close to the uses. Although you are not designing something from scratch, consider this as a ‘design thinking’ exercise.
Conclusion:
While consultants and the project team will eventually move on to other projects, the users will continue to execute these processes for the foreseeable future. Users are relying on you to define to-be processes that make them efficient and effective. Your thoughtful design will have a lasting impact on their daily 'work' life.
Users are counting on you to bring out their best!
1 Comment
