In Organizations running ERP systems as their backbone applications incur sizeable efforts and investments in implementation and provisioning ongoing support and developments. With an aim of reduced operational cost structure and continual improvements in processes along with seeking gains in operational efficiency, organizations often outsource operational support and development services to partners in low-cost economies. Very often these partners are not involved in the initial implementation and/or rollout services.
The need to transition knowledge and services to the incoming vendor imposes dual costs to organizations with the existing team (more often implementation team) and the incoming vendor teams involved jointly in the transition process. Situations where the implementation that has freshly gone live and is going through a stabilization phase adds risk to customers who are trying to (a) balance speed of stabilization, (b) initiate service benchmarks, (c) contain dual costs of running the operations and those incurred during transition.
Understand to customize
In the modern day business world, understanding of ERP packages has rapidly matured and the rules on which the application is built is no longer a black box within customer organizations. The modern day business is ever so focused on arriving at a cost and service value optimality within the business ecosystem and this encompasses provisioning of IT services across the spectrum of service requirements.
The need to transition knowledge and services to the incoming vendor imposes dual costs with limited benefit of service delivery to organizations with the existing team (more often implementation team) and the incoming vendor teams involved jointly in the transition process.Speed of service deployment is an imperative factor since the industry has progressively witnessed crunching of Implementation lead times, emergence of multi-vendor service models with a distinct service value proposition and service separation amongst various IT vendors.
This spill over effect extends into managed services and in this context, traditional transition models appear time and cost intensive.
The upswing of ERP maturity in customer organizations, standardization of ERP systems and experience based best practices developed by consulting organizations/ IT vendors, provide an opportunity to design ERP transitions for Managed services in a manner that the transition is accomplished in a leaner, faster and risk managed model.
Traditional transition models have a linear approach to knowledge acquisition. Conventional transition models rely on a sequential approach to transitioning of knowledge and services. These are characterized by linear investment of efforts in knowledge acquisition followed by a phased approach to assuming full responsibility of application management services before the incumbent vendor team is de-linked. Although this approach reduces the risk of impact to operational services for the customer, it builds up redundancy by having two external partners engaged in execution of the transition program.
Traditional transition models broadly rely on variants of a serial model built on Transition Initiation phase followed by Knowledge Transfer, Secondary support phase and finally moving into a primary support phase leading to steady state service. A typical transition model is depicted below:
Leverage reverse engineering
The inherent assumption relates to an understanding that the ERP (SAP) implementation and the knowledge contained in the system is largely a black box and a serial transition methodology with sufficient handholding is essential to ramp upknowledge from incumbent to the transitioning-in partner.
Whereas various cost models are in place to help customers minimize the impact of transition costs ranging from apportioning of costs over a longer period of the AMS engagement to execution of transition at base cost, these solutions are characterized by commercial considerations. Hence they inherently lack the ability to provide customers with confidence that arises from a mature awareness and familiarity of the processes, functionality and customization of the customer SAP environment.
Understand the patterns
A robust understanding of an implementation is possible by investigating the usage pattern of processes by business users, investigation of functionality from the configuration and constructing a process scenario map that is representative of processes and functionality of an implementation. This exercise creates a platform to enable the transitioning-in partner to identify the areas of simplification and improvements in processes as the transition progresses through steady state service into a mature engagement.
As against the traditional model outlined above, the transition methodology leveraging Reverse Engineering of ERP (read SAP) implementations would be as follows:
Learn the Processes
In contrast to the traditional models, the transition inputs from incumbents and hence the cost and efforts from incumbent are lower by an order of 40-50 %.
How do we reduce the reliance of transition lead times on traditional models, yet make the knowledge acquisition process more robust?
As a packaged application built on rule based algorithm, SAP provides an opportunity to reverse engineer the rules configured in the application and understand the business process design arising out of a particular system configuration.
Organisational Entities and Relationships
Tool based extraction of data within SAP related to organizational entities and their relationships, provides clarity on the legal structure of the organization, Organization of Sales, procurement, distribution and logistics functions and production facilities. This data sets the stage for further understanding of how business rules are configured and constrained for the different entities in the corporation.
Business Rules by Process Areas
Reverse engineering of the process configuration within SAP in relation to global processes and processes within each organizational entity provides a detailed understanding at a functionality level. The knowledge that is hidden in the configuration can be extracted and interpreted at various levels typically at a business scenario level, process level and at sub-process level depending on the depth and detail of the knowledge acquisition process. This stage is a building block for building a process map if one does not exist in the customer organization.
Multidimensional Data Analysis
The extent of usage of the functionality configured in the application across different entities in the organization is only evident when an analysis of transactional data is undertaken. This exercise can be automated by toolsets that can read the transactional documents in the system and categorize them based on pre-defined attributes for analysis such as location, business entity, process area, document type etc. For Managed services transition, this data provides useful insight on the focus areas for knowledge acquisition as it provides data on the dispersion of transactional density across the various parts of the organization thereby enabling a decision on where efforts need to be focused during transition. The figures depicted below, provide a snapshot of how reverse engineering by investigation of SAP transactional data provides insight into the usage pattern of process and a view into the technical aspects of system configuration and related process scenarios.
The pattern of production orders and the break-up by type of production is outlined below. Further investigation of the system will provide inputs on key knowledge areas, some of which are outlined below:
Production Strategy adopted in each plant and the related planning strategy
Materials that are produced in specific plants
Relation between the production and distribution strategy.
Shrinking the need for Formal Transition
Leveraging reverse engineering towards a Transition closure formal transition
The analysis of implementation and SAP environment by adopting the reverse engineering technique supplemented by detailed review of documentation to the extent available, should be able to provide a critical understanding of the implementation along with a knowledge transition coverage in the range of 60- 70%.
The remaining portion of transition would be a short and crisp formal transition in the form a very focused and mature knowledge exchange with the incumbent partner(s) based on query resolution and system walkthrough for complex processes and technical components thereby leading to convergence of the knowledge aspect of transition comprising of balance 30- 40 % of the efforts.
This is the only phase in this transition model where involvement of incumbent team(s) would be required as a sustained effort, thereby reducing the overall transition efforts and involvement of a larger team.
Conclusion
Consideration towards application of reverse engineering to ERP (sap) transition programs
While the ability to reverse engineer provides information on the unstated aspect of the implementations and a more data centric understanding of the processes and scenarios, it is nevertheless important to consider a few key parameters before a decision on the extent of reverse engineering is considered for ERP transitions. Some of these parameters are outlined below:
The extent of reverse engineering that can be undertaken depends on the maturity of the IT organization towards understanding of the business functionality applicable for Industry segments.
The benefits that can be leveraged from reverse engineering is dependent on the extent of SAP footprint in the organizations application landscape. A large SAP footprint implies a greater benefit in leveraging this technique towards rationalization of efforts, timelines, costs and reliability of transitions.
Custom add-ons and third party products interfaced with the ERP applications require an interaction based approach to transition that aligns closely to the traditional transition models.
The success of reverse engineering is largely dependent on the maturity of the IT organization in carrying out the analysis and interpretation of the business data generated during the process. Ability to model a business process out of this transactional data is the key factor for a rapid understanding of the functionality implemented in the system.
Customer participation is the key to deploying this technique effectively. Adoption of reverse engineering as core element of transition programs requires considerable customer maturity, participation and change management efforts.
Prior to embarking on a transition it is essential to conduct a due diligence and make an assessment of the quantum of reverse engineering in your transition programs. Nevertheless, reverse engineering holds the key to reduce transition costs and redundancy, minimize transition risks, make the understanding of customer SAP implementations more robust and enable a focused and mature exchange with incumbent(s). The latter is especially true when managing transitions in a multi-vendor and multi-geography landscape.
The author is a Senior Solutions Architect - Enterprise Application Services, Patni
Add new comment