How to approach Platform based development in SAP (BPO services)

[Former Member]

NexGen BPO – Platform BPO

We all know about traditional BPO services offered by a host of service companies.  They have caught on well and are at a cusp given the given the advances in cloud computing, co-location and software-as-a-service. So what’s next? It is Platform BPO.

In traditional BPO, the company hiring the outsourcing firm is in control of what gets outsourced. With platform BPO, the outsourcing service provider that runs the applications gets to dictate the platform, which includes an array of hardware and operating systems and a very standardized version of the application.

With SAP’s multi-tenant architecture (in place since the 80’s), where a unique identifier is used at the database level to segregate data between various organizations sharing the same Operating System on the same hardware (servers, storage, etc.), this has been a hot bed for many outsourcing firms.

What are the prime candidates for Platform BPO? The same non-core business functions which are candidates for traditional BPO – the cost centers that should be standardized as much as possible like Human Resource, Procurement, etc.

Why should we treat the project differently?

There are several reasons why a Platform BPO implementation should be treated differently from a traditional project – both from the service providers’ perspective as well as the customers’ perspective. The simple reason is the fact that the standardized platform already has been built to cater for the industry best practices which should be a standardized process across organizations sharing the platform and the model does not allow for a lot of customizations. But this is easily forgotten and the results are widespread failures for such initiatives. In this article, I will discuss about the nuances for a Platform BPO implementation with respect to HR Outsourcing (HRO). I will discuss the specific points to be taken into account at the various stages of the project and also discuss what should be taken into consideration when the platform is nascent (still maturing) versus a matured platform.

The 4 D’s

Typically, a platform BPO transformation has 4 stages:

• Discover
• Design
• Develop
• Deploy

Note: From a traditional ASAP point-of-view, the Discover and Design phases will probably be most aligned to Project Preparation and Realization, Develop will be aligned to Realization and Deploy will be aligned to Final Preparation and Go-Live.

Points to consider during Discover

1. Organize Project Kick-Off  Meeting with all Stakeholders – discuss on key similarity/differences of HRO Implementation vs. Custom implementation
2. Have discussion with HRO Product Team to clearly understand capabilities of the platform
3. Agree on Project Scope with Key Stakeholders – what can be achieved on a Platform vis-à-vis a Custom implementation
4. Factoring HRO Product capabilities during Project Roadmap definition
5. Defining Platform Product Team role in project Organization Structure (in Project Charter)
6. Defining/Agreeing on scope with respect to HR/Payroll Outsourced model (Service Delivery)

Nascent State consideration vis-à-vis a matured state

• Overall Project Plan will not be solid as Product is under development
• Clear definition of important Lessons Learned in other engagements will not be possible (to set Customer expectations)
• There will be increased dependency on Product Team during planning and subsequent phases

Key Deliverables

• Project Kick-Off presentation
• Project Charter
• Communication Strategy
• Sales-to-Delivery Checklist
• Project Management templates
• Status Reporting Mechanism
• Meeting agenda/minute template
• Quality Plan
• Documentation standards
• Risk/Issue management process (critical)
• Decision management process (critical)
• Baseline Blueprint Plan
• High Level overall Plan
• Acceptance criteria for Blueprint
• Baseline Scope Document

Points to consider during Design

1. Conduct Platform specific trainings for the project team – who would have come from traditional customer implementation background
2. Document missing customizations
3. Modify standard HRO product flow charts to reflect customer specific process (will not work as well in initial nascent stages)
4. Institute cross-team integration through integration layer
5. Fit-Gap analysis has to be against the HRO product – not standard SAP
6. Go agile as much as you can – demonstrate incremental prototyping
7. Critical strategies to be defined:
   1. Implementation Approach – Big Bang vs. Phased (critical: this will have bearing on various deliverables)
   2. System Landscape and Integration Strategy (focus should be to minimize changes to HRO product)
   3. Portal Strategy (assess level on customization required on vanilla SAP EP)
   4. Data Conversion and Cleansing (usage of Platform standard conversion tools)
   5. Testing (critical: Parallel Payroll Governance)
   6. BI/Reporting (applicability of HRO Analytics)
   7. Data Archiving (platform solution)
   8. Audit and Regulatory Compliance (SOX)
   9. Security and Roles Strategy
8. Demonstration of vanilla product functionality after initiation
9. Starting point should be Platform BPML, Standardized Business Processes with incremental changes to accommodate Customer specific requirements
10. Guiding Principle should be to minimize customizations in the base HRO Product
11. Validation of solution by Platform Design Authority
12. Identification of customizations to be incorporated in the HRO Product
13. Parallel prototype creation by Platform Build Team
14. Implementation Strategies should be defined in synchronization with Platform Standards
15. Realization Plan should imbibe Product Development Plan – inter-dependency between Product Team and Project Team

Nascent State consideration vis-à-vis a matured state

• Starting with Platform BPML and standard Business Processes might need flexibility
• There will probably be increased customization identified to base Product initially
• The Implementation Strategies will require greater flexibility initially even if it violates some Platform standard as the Platform evolves

Key Deliverables

• Business Process Flows
• To Be Requirements
• Organization Structures
• Process Description with activities/roles
• Configuration Design
• Baseline Level-5 BPML
• Prioritized PRICEFW List
• Solution Approach to major Gaps
• Functional Design Specifications
• Implementation Strategies (as defined in the SOW)
• System Landscape Definition
• OCM Blueprint (Service Delivery activities, Role Definition with Authorization, Communication, etc.)

Points to consider during Develop

1. Create Development client by replicating HRO Base Product

(Note: This section needs to be expanded and synchronized with Platform Methodology for Transport Management. The primary flow should be:

• Start with the Base Product version
• Perform IMG Configuration – both Customer-independent as well as Customer-specific
• Perform Application Enhancements (both Customer-independent as well as Customer-specific)
• Transport both the Customer-independent Configuration and Enhancements to the Base Product0020after testing and approval)

1. Perform iterative Unit Testing of configuration (To be done in the Development client and will be primarily performed by the respective Functional Consultants)
2. Perform String Testing (To be done in the Unit Test Client where Master Data has to be created and should involve Service Delivery Team long with respective Functional Consultants. This exercise is to be synchronized with the Development Stream if Process-String involved Enhancements)
3. Define detailed Role Definition Matrix and Role to Position Mapping based on BPML (Initial comparison to be done with Platform standard Roles – new Roles to be added when necessary. This exercise involved synchronization between the OCM Team and the Security Team.)