SAP

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!

Main

March 30, 2015

Cloud or Captive - IT cost reduction strategy for SAP infrastructure

Two broad trends once can see in the SAP market.

Trend 1 - Working with SAP hosting partners and then move towards full-fledged SAP on the cloud

By and large organizations are moving away from an on premise SAP data center environment to having partnership with SAP hosting service providers. Basically companies lease server space and as well outsource BASIS Administration activities of their SAP systems to the hosting partners. These organizational can be expected slowly and steadily move towards embracing full fledged ERP on the cloud model as they mature and gain confidence with the hosting partners and also with the whole partnership model. Small organizations of $2 to $ 5 billion sized are the ones who are moving towards the "Public cloud" option which provide the most cost effective solution for them. Bigger organizations will tend to go for "Private Cloud" as they tend to have multiple SAP systems in their landscape and will see more advantage in the dedicated infrastructure even on cloud. "Hybrid cloud" is something that can appeal to bigger organizations as that addresses the risk and confidentiality aspect by moving only the development and quality environments into cloud while leaving the production environment on premise. To me the Hybrid cloud option is the ladder through which SAP user organizations can join the cloud bandwagon, build robust partnership model around risk and confidentiality for moving towards the Private cloud option which provides economies of scale.


Trend 2 - Keep the SAP data center on premise but move the SAP service department into a captive unit in a low cost location.

This option is sort of preferred for large SAP behemoths. Big companies in the order of sizes more than $10 billion will have huge SAP infrastructure and such systems tend to be dated and something heavily customized environments. It is these kind of organizations which consider going for cloud based SAP systems is too risky. These companies have large SAP systems and will keep adding new SAP systems or engage in spin-off activities due to regular merger and acquisitions. Over the time their data center have become too big and too complex, that any new CIO is threatened by the risk involved in even considering disturbing the functioning data center environment. So moving to cloud as a cost reduction strategy will have no buy in and even if implemented it will be on very small areas on ad-hoc basis. For such companies moving the IT support organization to low cost locations is safest bet on cost reduction. Having already outsourced many of the regular production support process, most likely these organization will have retained a core team of IT professionals who run the show with in house knowledge capability around core processes. It is these core process knowledge retention team that will become target cost reduction by way of opening a captive unit in a low cost country.


Is the second trend a viable?, given the rapid advances being made on cloud capabilities in the market and as well on the fast paced changes in the SAP capabilities. 5 to 10 years from now would the large SAP user organizations be better served by an in house data center or complexities will zoom to a level of tipping point where in move to cloud becomes a necessity. I read about a very similar story during the early industrialization due to lack of reliable power grids, big manufacturing industries had invested in building power plants on their own to ensure reliable electricity supply. But with the advancement made in power grids, and efficiencies achieved by utility companies, the concept of in house power plants vanished. It looks to me the same will be the case of data centers for large organizations. Given the advances being made by cloud service providers, it is going to soon become un economical to even have on premise data centers. SAP being the core ERP system for these companies, it is better addressed early for cloud migration. Investing in captives can be a strategy on IT cost reduction along with movement to cloud, but the latter will have larger impact on the bottom line and make large organization's IT nimble enough to react to market dynamics quickly and effectively.

September 23, 2014

MDG Integration


Recently Infosys implemented SAP MDG solution for introducing data governance on material master for one our clients that has an ERP landscape involving multiple SAP systems and non-SAP systems. We focused on the SAP systems first during the implementation and then came up with a scalable integration solution with non-SAP systems.


The requirement for integration was along the following lines

1.      Integration solution should be scalable to enable to add non-SAP ERP system into data governance as and when such systems are ready

2.      Initiation of integration should not entail any new development effort in the SAP MDG system

3.      SAP MDG user interface should be enabled to allow the data steward to pick and choose the target non-SAP ERP systems to replicate the material master data

4.      Receive and process acknowledgement carrying success or failure message

Scalability is the paramount requirement as the number of non-SAP ERP systems are around 30+, hence having a mini development project for each of such application as and when the regions represented by these applications join the global data governance process is not a feasible. So the integration solution needs to be designed in such a way that any new region joining the global data governance stream is just handled by a master data type extension. This forces us to think hard on coming up a viable solution that achieves this scalability and at the same time is not technical complex to develop in the first place.

After studying multiple solution options we went ahead with standard SAP Classification based solution. The contours of the solution are

  • Every material created by the MDG solution will have a default material class assigned.
  • The class will have characteristic whose value represents the non-SAP ERP system.

    • This way any new non-SAP ERP system is just handled by addition of one characteristic value.

    • Some amount of work in the middleware SAP PI is needed once the characteristic value is defined in MDG but does not involved very detailed development effort in PI too.

From a solution development perspective only major drawback we faced was due the fact that SAP creates a separate idoc (intermediate document) message for material classification values for integration with external systems, which means the middleware has to process to two idoc messages for each material and that can make it complex for middleware. So to eliminate this we had to enhance the standard material master idoc message with additional segments to carry the classification values too. But still this is an one time development effort and we found that there is good amount of effort and cost savings compared to alternate solution which might need a development for each non-SAP ERP application addition to data governance and went ahead with this approach



Recently we presented this solution at ASUG (Americas SAP user group) St. Louis, USA conference. The solution idea and the benefits were well appreciated by the august audience.

Some of the interesting comments received were

From a Monsanto executive

"We have millions of material masters in our system and all the challenges and issues you highlighted are very much there and I seriously yearn for your solution in our system"

From an EATON Corporation executive

"We have a high priority requirement to create material master workflow, I am now convinced after listening to your presentation, MDG is the way forward"


 










Continue reading " MDG Integration " »

April 15, 2014

Flexible Data Governance - Oxymoron or Practical need?

 

The need for data governance which actually means establishing control on data source to obsolescence has become a need for many organizations. I would be surprised if any CIO is not mentioning establishing data governance or enhancing data governance as one his primary IT investment objectives in the short term or long term. Lot of organizations have a baggage of multitude of IT systems each of which serves a specific business need and designed to serve it by sourcing the needed data all by itself. All organizations always keep evaluating the conflicting need to rationalize IT systems or building more robustness in the interfacing part so that the hold on to the best of the breed IT systems even though collectively they create lot of weak links. So if an organization is able to rationalize IT systems, then data governance is taken care by the rationalization itself but in case of the need to maintain the best of breed IT systems, then data governance becomes paramount as it can really break the weak links and exponentially increase the pain of maintaining such heterogeneity.

 

So the context of data governance is to arraign the sources of proliferation of data elements and data values and bring in much needed control. Basically strengthen the weak links in the heterogeneous IT systems landscape which I had mentioned earlier. As anybody can guess this is easier said than done. Additionally data governance needs harmonization as pre-requisite which can also turn out to be tough to crack. So achieving one source of truth and one value across all the IT systems is a tall order, but then is it not the fundamental requirement to be achieved through Data Governance. It is here my topic bears significance of having flexibility in data governance. I would say "Flexible Data Governance" is indeed an oxymoron but it is a practical need too. Let me explain with an example.

 

In a recent data governance implementation project we came across the field "Division" having available values as 10, 20, 30 & 40 in one SAP system and in other SAP systems there were multiple values additional like 60, 15 and even alpha numeric of two character length. Keep in mind all the systems involved are SAP, so it should be a piece of cake to harmonize this and that is how it started. We standardized the values as 10, 20, 30 & 40 in the data governance system and mapped the additional values available across all systems to these 4 values. But then we found case of hard coding in interface programs, middleware program, enhancement programs and even values in this field being used in user exits to execute specific activities etc. which ruled out harmonization of one value of after another. So what to do? Continuing with harmonization means costly program changes, elaborate testing efforts, risk of introducing production issues etc. Here comes the concept of "Flexible data governance" where-in we introduced scalable data governance where-in within a master data object we allowed values to be harmonized and controlled on a certain fields while in other fields it is allowed to have different values in different systems. So the data object is part of data governance but not all fields in it are controlled by the data governance tool.

 

I am sure each of us would have seen such conflicting requirements, but in a data governance project where-in the fundamental need to conformity, flexibility is a bad word but then life thrives in the gray. Please share such examples in your project experience.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter