Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« November 2012 | Main | January 2013 »

December 18, 2012

Is RDS the answer for all SAP solution implementations?

Consumerization of business systems has been the latest trend that has impacted the next wave of technologies. SAP has been a trendsetter in this area by focusing on new trends like mobility and new UI technologies. This consumerization trend has also impacted on how businesses are looking at getting ROI from new solutions. In the new era, businesses are looking for faster time to value from their systems. The traditional waterfall methodology of implementing SAP solutions are being seen as roadblocks in terms of rapid adoption of solutions and deriving faster business benefits. Typically timelines for regular ASAP implementations run into months to sometimes several years. This means there is a huge investment on organization resources in terms of finance and human capital. Hence there has been a demand to disrupt the traditional methodology and bring forward an agile approach for implementing SAP solutions.
To meet this growing trend, SAP is offering a number of its applications as a package of preconfigured solution along with implementation services called RDS (Rapid deployment solution).

The concept is akin to having an all-in-a-box kind of offer, where a customer buys a bundled deal of solution as well as implementation services. The main attraction of the RDS is the promise of fixed time, fixed scope and fixed price. RDS implementations follow an agile approach and crunch the delivery time by leveraging tools and accelerators. The timelines for RDS implementations are in weeks (typically from 8-12 weeks) and make an attractive value proposition to customers by helping them jumpstart to new functionalities in a rapid timeframe. To top it all, SAP claims to provide its best practices through RDS solutions helping customer to adopt the processes without any customizations.

RDS can be an ideal launch vehicle for starting with pilot implementations before going for full scale roll out. The obvious benefits of going for RDS are reduced risk, faster time to value and reduced cost. Though this sound like an all win situation for customers, it is imperative that customers do a due diligence before opting for a RDS solution. One of the main themes of RDS is fixed scope, which means you take it only what comes with the standard solution. This is a tricky part, as there is hardly any scope for changing any features and new customizations. Once a solution is implemented and does not meet customer expectations, there can be lot of change requests which can mar an RDS implementation and lead to disappointments. Hence customers need to carefully check the offered process flows and make sure that they can adopt the same processes without any customizations.  Though these processes are formulated based on industry best practices, every organization would be having some unique processes which would be adding a competitive advantage for the company. Hence organizations need to weigh down their options of losing any competitive advantage when adopting processes as it is.
Secondly the technical limitations of an organization may be a hindrance to adopting an RDS solution as there can be incompatibilities with other systems leading to complex interfaces. RDS solutions specify technical system prerequisites for implementation. Customers should carefully examine the prerequisite landscape for an RDS offering with their existing landscape.

Organizations also need to assess their business process maturity vis a vis maturity of corresponding SAP products in their decision for RDS solution. RDS offering may not be a very attractive proposition, if an organization has matured processes and there is already a mature SAP product solution.

The below matrix can provide some guidance in selecting the right candidates for RDS solution implementation:
 

blog1.jpgIt would make more sense to go with RDS solution for a newer or niched functionality, as this would take care of any risks associated with new product implementation.  SAP has introduced variety of new cutting edge applications like HANA, SPM(Spend Performance Management) as RDS solutions which can be adopted by customers to jumpstart new functionalities in quick time frame.

To conclude, I believe SAP RDS offering can really be a winning proposition for customers, provided they make their choices by analyzing all the factors and their future outlook on SAP solution adoption.

December 15, 2012

Integrating Shared Services

The perspective on shared services as a concept has really evolved in the last decade. Close to 80% of the Global 2000 companies have tried to bundle their back-office processes to be operated under a common umbrella of a Shared Service Organization (SSO). The targeted benefits have been immense in terms of cost savings and process harmonization. The organizational investments in processes become easier and focused as opposed to investments in disparate local departments and business units. There is a significant improvement in performance metrics and the organization works with defined SLAs and KPIs which increases transparency. A year on year productivity growth has also been one of the secular trends established by most SSOs

Context

It is being increasingly seen that SSO's are moving up the value chain, from handling pure play accounting and HR processes to more support functions for Purchasing, sales and marketing. However, it can be argued that a majority of all shared service organizations have been established in the last 4 years and many of them support only single process areas like accounting. The way in which the evolution of an SSO takes place within an organization is very important.

Challenges on the way

    i.    The scale of operations: During the formative phase of a SSO, scale / volume of transactions is of utmost importance. The viability of the SSO rests on how rapidly the targeted number of transactions is brought within the fold. The catchment of business units and process areas which is defined in the overall strategic blueprint of the SSO has to be catered within a span of 12 to 18 months. 
    ii.    Lift and shift approach: In the pursuit of scale, a lot of localized processes from the various business units are added to the SSO without process alignments. In the medium term, operating similar processes in different ways for different entities results in inefficiencies and spiraling costs / activity. It is highly likely, that business entities who outsource some of their processes to the SSO experience discomfort and a sense of discomfort with the whole set-up. Typically, the business entity may experience a worsening of their critical metrics like time to pay invoices; interest accrued due to non-payment of invoices on time, slip in targeted SLA levels etc. The planned FTE rationalization or re-deployment within the business unit would also be impacted since the anticipated stability in operations has not been reached.
    iii.    Knowledge and people management: Due to the disparate nature of local processes, the SSOs have to invest in specific knowledge and teams to service these processes. Any transitions in the team are difficult to support. SSO's would also typically experience higher rates of attrition for the same skill-sets as in business units due to the inherent nature of the industry. In addition, attrition rates would be relatively high initially since people management practices are still in the process of getting refined. The effect of transitions and attritions further amplifies the inability of the SSO to meet its SLAs as committed to the business unit.
    iv.    Disruption in process chains: The process chain has to be re-built post transition to the SSO. The SSO typically takes over only a specific area of the entire process. E.g. in Procure to pay processes, only the accounts payables is shifted to the SSO. A completely new set of people will take over invoice processing and payment runs and due to a change in location; the accountants would be remotely connected with the buyers or the requistioners in other business units. This implies that the process maturity built up over many years in process chains before the transition to the SSO has to be built up from scratch. During the formative phase of the SSO, this would definitely impact performance.
     v.    Technology misalignments: Along with disparate processes, there is a high likelihood that disparate technological platforms are also inherited. E.g. if different optical archiving systems are used in different business units and there is an insufficient time for migration to a central optical archiving platform in the pursuit of scale, it can be seen that the SSO will be soon struggling with a multitude of archiving systems making an integration strategy even more cumbersome.
    vi.    Responsiveness to process changes: In a competitive environment, business processes provide a cutting edge in cost savings, customer acquisitions and customer retention. When process changes are triggered cutting across the organization with the requisite drive from the leadership, a high velocity of change is the first expectation. Unless the SSO operates with harmonized processes, it can prove to be a bottleneck and a risk to the whole change management initiative. The SSO will take ages to tweak all the localized processes which it has inherited in its pursuit of scale.

 
A Life-cycle approach to SSOs

The evolution of SSOs can be planned from a life-cycle point of view. The imperatives of scale should be as important as the attainment of SLAs, reduction in cost and process quality. These factors need to be considered in devising the growth stages for an SSO.
      i.    Formative phase: The pursuit of scale has for a viable business volume is important but has to be tempered with considerations of common technology platforms, process continuity and targeted SLAs.  A simple lift and shift approach has to be substituted with a carefully calibrated approach which includes:
a.    a move to a commonly defined technological platform e.g. SAP
b.    defined roles and responsibilities between the business unit and the SSO
c.    defined workflows between the different stakeholders throughout the entire process chain
d.    defined workarounds for exceptions in processes 
e.    communication framework to steer governance
The formative phase defines a major shift in terms of change management between the business unit and the SSO. Both the entities have to feel reassured about the model and should respect each other's roles and responsibilities. The future evolution of the SSO depends on the success of this phase. By the end of this phase, a significant percentage of the catchment business transactions would have shifted to the SSO.
    ii.    Harmonization phase: With scale attained in the formative phase, the SSO must ready itself for a scalable model which is based on a defined template of business processes which are acceptable to all business units involved. In case the SSO supports business units which run on a common IT template e.g. a SAP based financial template, the task becomes easier. Most of the business processes would already be harmonized but have to be re-aligned simultaneously with respect to the SSO. In general, this phase would involve:
a.    Learning from the experience of running multiple processes and defining common processes derived from best practices
b.    Putting in place a change management framework in order to transition to the To-Be processes
c.    Defining clear value and a sound business case to justify the movement to the new processes
d.    Deriving efficiencies, transactional cost reduction and process simplification as compared to As-Is scenario, thus also reducing knowledge management and people transition risks
The harmonization phase enables the organization to focus investments on entities like SSO and derive cascading benefits in multiple business units simultaneously in terms of responsiveness to change, compliance and costs.
    iii.    Expansion phase: With the required template of processes, the SSO is now also geared up to expand its foot-print to new business units and also to new process areas. By this time, the model and business case would already have been proven across the length and breadth of the organization. Business units (BU) would now carry mandates from the leadership to join or involve the SSO in some way or another. The expansion of the SSO would typically entail rollouts of the existing template processes and reducing as much as possible, the scope of localized processes, except for extraordinary reasons like legal or statutory reasons. 
    iv.    Continuous improvement phase: With new ways of doing business continuously emerging, the SSO will be challenged forever to adapt itself for new changes in business processes. There could be template changes, local changes and efficiency drives depending on business cycle. One such event could be outsourcing with the SSO. By now the SSO would have been able to calibrate its operations and activities in terms of complexity, costs and value. Process leaders within the SSO would focus on more on process design, monitoring and control and providing the crucial interface to the business units which are their internal customers. However, there would be a scope of many transactional activities which could be outsourced further to a third party provider. In case the third party provider is established in an offshore location then a new kind of integration framework will be needed which connects the business units, SSO and the third party provider.


IT needs for SSO integration

The key technological components needed for SSO integration are as follows:
      i.    Authorization framework: Defined roles and responsibilities are the bedrock of a successful BU-SSO relationship. Segregation of duties and four eye principles are the guiding consideration for creating authorization profiles which prevent any overlap of tasks between the BU and the SSO. When similar processes are being executed at the BU as well as the SSO, there is a high chance of incorrect transactions and duplication. Transactions which need approvals should not be allowed to be posted without requisite approvals. There is a distinct change in working model. When all processes were in the BU, some of the checks could be ensured offline. However, when processes also involve the SSO which has a separate location, such checks have to be mandatorily ensured in the system to be audit compliant. This topic is particularly important where payables are involved. When Third Parties are involved in SSO outsourcing, the authorization profiles becomes even more complex as external teams may be needed to have display or edit rights in the system.
    ii.    Workflows: The traditional role of workflows is limited to messaging, alerts and prompts. However, with SSO in picture, workflows can assume a whole new meaning. They can be leveraged to run the entire process blue-print involving activities which start in BU, travel through the SSO and land up with the business partners. Workflows are now instrumental in routing processes as per compliance standards and automating transactions to such an extent that manual intervention is requested only when an exception is identified. A successful workflow implementation ensures that an SSO is able to meet its SLAs and KPIs productively. The workflows enable rapid rollouts to new business units if existing processes are involved. When Third Party service providers get involved, then workflows will need to be enhanced for compliance and efficiency.
   iii.    Reporting: With a transfer of processes to SSO and then to Third Party service providers, effective reporting is necessary to track the transaction statuses. Since disparate parties are involved and connected by workflow, it is highly probable that the process will complete correctly without exceptions. However, workflows may be stuck while they are waiting for an event which is dependent on a user action and the process may be delayed. Reporting would be needed identify delays, bottlenecks, number of exceptions in the process and how the exceptions are being handled.
   iv.    Enhancements: Typically external documentation to business partners like purchase orders, dunning letters, remittance advises, invoice documents, proformas, terms and conditions etc would undergo basic changes. This is particularly relevant if the front desk and business partner communication is shifted to the SSO. Additionally, interfacing and enhancements may have to be changed to reflect new business rules, validations and increased automation.

Conclusion

Shared service organizations are becoming the backbone of transaction processing in large businesses. They are gaining critical mass, entering new processes and increasing their footprint across the length and breadth of the organization. An effective SSO allows the business unit to focus on their core activities, reduce process costs, increase process quality and service levels as well as bring agility for process changes. However, there are many crucial lessons learnt for the evolution of SSOs so far which can definitely enable new initiatives in this direction to fast track their return on investment and provide an all round satisfactory working model.

IT can play a crucial role in enabling the SSO initiative meet its targeted objectives and provide a launch pad for its rapid expansion within the organization. A well defined IT architecture goes hand in hand with the SSO life-cycle. IT enabled solutions can provide answers to problems arising out of process deadlocks, responsibility and role conflicts and above all achieve compliance without sacrificing on efficiency, achieving scale without foregoing process standardization.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter