The Infosys global supply chain management blog enables leaner supply chains through process and IT related interventions. Discuss the latest trends and solutions across the supply chain management landscape.

« April 2012 | Main | June 2012 »

May 25, 2012

SAP acquired Ariba, what does it mean for the on-demand, procurement and SAP world?

When a colleague forwarded the news of SAP (finally) buying Ariba past midnight India time on Wednesday ( ), my first response
was roughly on the lines of "better late to the dance than allow Oracle to steal your partner". That said, the "Ariba on the bid block" has been now a since-2006 story ever since Oracle kicked up some serious acquisition dust during the Peoplesoft, JD Edwards, Siebel years. With IBM acquiring Emptoris and folding it into the Smarter Commerce theme, all eyes in the procurement world was on Ariba.

Over the past few years, I've watched Ariba's stunning repositioning as a serious on-demand player (yes, cloud hadn't become so fashionanble in 2007-08) with a lot of admiration, though as an SI, this meant a steadily eroding revenue pie. I've always felt that this was one good management case study of charting out a strategy and staying true to it, in spite of quarter-on-quarter setbacks.

Supply Chain, as you know, is a collection of motley functions, with each having its own decision maker - demand forecasting, replenishment planning, sourcing & procurement, warehouse management, order management, transportation management...the works. In this vast realm of linked functions, over the last decade, we've only seen two functions being truly moved to the on-demand paradigm. The first has been Tranportation Management, with a myriad range of TMS providers, mostly in the range of $20-100 of revenue base effecting this change. The second? Sourcing & Procurement, primarily the indirect spend area.

Indirect spend as an enterprise function is interesting for multiple reasons. First off, this is more the domain of CFO's office than say a VP-Supply Chain, since it plays a role in the Sales & General Administration (SG&A) part of the P&L statement and not in the "Cost of Goods Sold - CoGS" line item. Effectively, you're taking cost out of the balance sheet, but not out of the core supply chain per se. Secondly, unlike more niche functions like Transportation which have low user bases, indirect spend (when truly implemented enterprise-wide) is usually one of the most widely used enterprise app in any organization, both in terms of transaction volumes and user bases.

The first point above meant that indirect spend is considered "non-strategic" enough to be moved to an "outside-the-firewall" mode. The second point puts in serious burdens around the whole nine yards of under-the-hood, non-functional requirements that go with such large user footprint - stuff around user experience design, application scalability, performance engineering, integration with other enterprise applications etc.

In this regard, Ariba's investments in this model including massive data centers over the years and the A few years back, SAP or anyone could've bought Ariba at probably less than a fifth of the price paid for the acquisition now, but its also a strong nod to the amount of value created by the Ariba management's dogged persistence on the new model of cloud paradigm.

While on-demand was catching on and this offered clients a chance to pay via alternative models of spend-based pricing, it also allowed Ariba a firm grip on all revenue streams, a far cry from the days it was selling licenses, taking annual maintenance contracts and providing some consulting support as needed by clients. By bunding hardware, software, consulting, integration, data management and everything else that goes with an implementation (while keeping customization to an absolute minimum), it was perfectly positioned to capitalize on its inherent strengths of a large user base, a market leading product and a solid understanding of how the domain works thanks to the Ariba marketplace offering.

In terms of product alignment with current SAP offerings, there are huge overlaps, the most glaring being the on-demand based Frictionless Commerce that was picked up by SAP a few years back for the upstream pieces of sourcing and contract management. Whether SAP SRM would be kept for on-premise clients and Ariba offered for on-demand is something that would be worth watching.

From a market standpoing, Ariba has been extremely strong in the pharma world, a vertical SAP is dominant apart from financial services, a vertical SAP would like to further strengthen. For all those who opted for SRM looking a one-neck-to-choke strategy, a smooth migration path to get onboarded into the Ariba world would warm it to many clients, so that could be an immediate opportunity. That said, indirect spend has a major user experience component, so one cannot miss out on the change management aspect that comes be default for such initiatives.


May 24, 2012

How to make Preventive Maintenance a way of life in SAP APO Support Projects - Part 2

In the previous blog, I had shared from my experience, the varieties of issues that we come across in a typical support project. Similarly errors can occur in master data area that affects SNP and PPDS planning. Some of typical errors I have seen are:

• In case of change in BOM components / work center in ECC, PPDS PPM gets updated in APO but SNP PPM does not get updated and continues showing consumption of old component;

• Transportation lanes or Means of transport that have expired or going to expire in near future will result in creation of purchase requisitions without any source of supply.
Careful examination of logs of daily CIF jobs can highlight the issues with PPM even before they are caught by the planners. Similarly a periodic query of t-lanes that will expire soon will help in preventing purchase requisitions without source of supply.

Above are some of the errors that I had experienced in the support project I worked. Some of these errors can be generic and can occur in any APO solution whereas some may be specific to the implementation of APO solution for a customer.

Similarly possible errors in terms of master and transactional data can be considered based on the past experience or thought through. Periodic data check processes with data checker tools and templates can be built to capture possible data issues.

Below some of the important checks that can be put in place to ensure preventive maintenance:
• Product codes having cyclic BOMs or cyclic T-lanes
• CIF delta reports that show planned order missing in R/3 with / without external key APO, PO missing in R/3, preq missing in R/3
• Planned order and preqs with missing source of supply
• PPDS orders in SNP horizon
• Logs of SNP / PPDS heuristics run
• History load from cube to planning area errors
• Forecast load from DP to SNP errors

Similarly master data checks such as below can be built using SQ01 queries
• Items with procurement type E /X but with no PPM
• SNP PPMs with more than one version of highest priority
• Transportation lanes with no means of transport
• Transportation lanes with same priority for multiple sources
• Resources where factory calendar is blank
• Quota arrangements <> 100 %
• Invalid safety stock or safety stock with wrong method
• SNP PPMs with no input components

This practice if followed regularly is bound to reduce support tickets raised by users. Hence it may impact the overall quantum of work as perceived by the client. However maintaining better quality data will ensure that planners always get a plan that is reliable. This will not only increase their usage of the APO solution delivering better quality plan, but also will open up more opportunities for implementing newer features that were un-explored so far. So the mantra for any SAP APO support project should be to spend more and more time doing preventive maintenance so that the occurrences of any support ticket (breakdown maintenance) are minimized.


May 18, 2012

Confluence of IT and Business Strategy for a Transformation program

Emerging business needs and stiff competition are forcing organizations to rethink on the business strategies, often leading them to identifying avenues for improvements and towards what is known as "Transformation".  Various reasons for a business transformation would include smart ways of working, effective information sharing, continuous improvement in the operation model, availability of vital information for better decision making etc. These forms key contributors to an effective transformation exercise.  For any transformation to be successful, it is important that the key contributors are identified and implemented effectively, but how often are we sure of completely meeting our transformation objectives?  The answer is, very rarely! What did we miss then?  Was there a flaw in charting out the transformation ideologies? Or did we completely lose the business context while implementing the transformation program?
Any transformation brings with it both cultural and technology changes, making an enterprise to be extremely cautious about implementing them. Let's have a closer look at the transformation layer, with heavy reliance on IT to drive the business process, predominantly two entities  co-exist within the transformation layer; they are Business Process by itself and the IT. Business transformation is definitely an eye catcher with the top leagues in management as it negotiates well with the top line, converting their short term and long term goals and adding value to their customers thereby enabling them to stand out in the competition. Business process once optimized, it enables better ways to do things going forward. No matter everyone likes it or not, this very idea resonates well with the management.
Business Process Blueprint once ready, the IT owns the onus of translating these business processes or so called rules to ensure that they get implemented seamlessly. IT strategies need to ensure that the business process is completely adhered to. As an IT consultant, I would have myriad way to meet "my understanding" of the expected business requirements but the question is how correct is "my understanding"? How sure I can be while tracing the requirements, all by myself, back to all such related processes which are impacted by the changes I make? How sure am I that the requirements tractability would always lead me to a correct requirement to IT strategy mapping? Who would and how to sign off on such a change? Complexity further aggravates if boundaries in terms of adherence to a best of breed IT solution or package is being pictured by the management. Restrictions get further placed on the IT Implementer to adhere to a safe implementation route, the so called best IT practices.
The Business and the IT layer, having their individual goals and hence their respective KPIs, are often heading towards meeting it and with a typical nature of their execution in which one precedes the other, there is a scope of conflict with little or no scope for corrections. Getting into such situation at a later part in the game creates problems by not allowing a timely retrofit option. IT Implementation often gets done without completely analyzing the business impact, a phenomenon not completely attributable to lack of business acumen but more to do with less or no Involvement during the business blue print phase of the project. What was thought to be a best of breed business process renders to be a mere IT solution without realization of the expected business benefits. What may look good from an IT strategy point of view could actually be a business problem in the future.  How do we make things work then?

A decision on implementing transformational changes entails both IT and the Business consultants to watch out for conflicts and collaboratively implement the change. A trade-off between changes in the underlying business process or negotiating on the permissible IT System changes is imperative but if the entities work in a constructive- Iterative way, it can bring about great benefits to the whole program. There sure are challenges involved like unavailability of all stake holders to validate the change, resistance to change owing to Impact in the multiple process areas requiring revisit etc. but the Impact of not having it is damaging. These challenges could be remediated to great extent by an early partnership in the transformation program, a mechanism to ensure a collaborative working model between the IT and Business entities. They are an integral unit for success of any transformation exercise and should go hand in hand.

How to make Preventive Maintenance a way of life in SAP APO Support Projects - Part 1

I started my career as a maintenance engineer in a leading paint manufacturing company in India. The maintenance work that we did was divided into categories such as breakdown maintenance and preventive maintenance. I still remember the words of my first manager- "we should be spending our maximum time doing preventive maintenance so that we don't land ourselves into business critical breakdown maintenance".

After working in software industry and SAP APO, when I look back, I feel compelled to compare the way we execute our support projects with the way we executed preventive maintenance in typical manufacturing industry. Just like any manufacturing industry, role of preventive maintenance cannot be underestimated even in software industry.

Speaking specifically of SAP APO, maintaining APO solution free of any master / transactional data issues plays very important role in ensuring that planner (who is the end user of the planning system) always gets a defect free system to begin with. Many a times, the lack of data accuracy in APO is the reason that planners tend to do manual planning using spreadsheet. They deploy complicated formulae in their excel sheets not realizing that even more advanced logic is available in APO. Ensuring data accuracy in the planning system is like maintaining basic hygiene.  This will not only increase planner's belief in supply and demand plans created by APO, but it will also give him / her more time to explore advanced features in APO that will in turn help maximizing value out of solution they have deployed.

In a typical support project, we come across varieties of issues. Many of them are repetitive in nature and can be avoided by careful study of the logs even before the issues are encountered / logged by end users.
• Batch jobs / process chains are deployed in any steady state APO project for performing tasks such as loading history, calculating forecast, releasing forecast from DP to SNP, SNP engine run, etc. Each of these batch jobs generate logs / spools that warn us about the logical / technical errors and potential issues that will be faced by planners.
• History load from APO DP cubes to planning area happens through standard transaction / sapapo/rtsinput_cube. If the CVC is absent for any reason, and then historical data (such as past orders / shipments) cannot be loaded from cube to planning area and hence will appear as an error. Careful examination of the product codes can highlight if the codes are obsolete (and hence no longer required in APO) or if they are new and will need to be setup as a CVC in APO. This can then be rechecked with the Demand Planners to ensure correct CVCs are created in time to prevent any data loss.
• Forecast creation process typically uses one or the other statistical forecasting models to create uni-variate forecast. Alerts can be created to calculate the measure of error and highlight in case of exceptional errors.
• Forecast release from DP to SNP happens at a product location level. If a particular product location is not setup in APO SNP, then the corresponding forecast will not get loaded from DP to SNP and hence a portion of the total forecast for that product may get lost thus resulting in in-sufficient planning.

In the next part, we will discuss on errors that occur in master data area and also focus on important checks that can be put in place to ensure preventive maintenance.

May 10, 2012

My own power Generation plant

The summer in this part of country is really hot and has this bright sunshine for most of the year. That's why one would see lot of Solar panels on the roof tops or even dedicated solar generation plants (though I don't see if there is any direct co-relation to the high temperatures out here to amount of electricity generated using solar panels). What is it that makes these installations popular these days? The federal government is promoting the use of Green energy and that's where the utilities have come up with the ways to use this opportunity for distributed energy generation. Traditionally utility customers owned and maintained the Solar Panels but various ownership and pricing models have emerged where in the Utility Company owns and maintains the solar equipment which is installed on the customer roof-tops. Some of the utilities have their own solar generation farms with vast number of solar panels spread across a large area. The pace with which the technology is emerging and the clean energy awareness is growing along with the federal government supporting it; day may not be far when every house is a distributed generation station for a utility.

 So with these things, what are the new problems that these installations are bringing to the customers and the utilities? These solar installations are done by the vendors who have expertise in installing them on the customer roof tops. These installations are managed as a turnkey projects wherein the utilities get little information about the assets that were installed and how customer is going to maintain these assets against the benefits that he gets for installing these assets. Also there is no defined standardization for these solar assets and every installer would do it differently. With the new concept of utilities owning these assets, the standards are being set and utilities are taking advantage of the research and implementations done throughout the world. 

With the solar installations getting very common in United States regulatory commissions would soon have some guidelines for maintaining them and also for reporting the solar generation (which I guess already they have to).  This is the time when the utilities should start thinking about the maintaining these solar assets and define the strategy for their future maintenance and regulatory needs. Unlike the other traditional generation methods, this involves management of vast number of assets that are geographically scattered. The warranty and maintenance contracts for this huge number of assets should be handled using an appropriate work and asset management system. The solar technology is rapidly evolving and the manufacturers are providing long term warranty which is not forcing utilities to have a concrete maintenance policy but with time and complexity building up the utilities will eventually need to have a better control over it.

Utilities now have to view these solar assets as their regular generation assets and maintain them by defining the strategy for their optimum output. It's not just the case with the Solar but all the distributed generation technologies that are evolving over the years. Wind generation also needs similar asset management practices to get the maximum benefit out of it. This would also help the utilities to come up with the cost benefit of using these alternate methods of generation and lay down the future road map for its usage.


May 9, 2012

Supply Chain Visibility: The need & qualities of an effective system

In today's world, supply chains are no longer localized to an organization's four walls. As companies go more global for their demand and supply markets, there comes with it a spider-web of partners and dependencies. The situation gets more complex as partners may have their own processes, systems and work in their own time zones. This easily has a potential to lower the supply chain efficiency due to lack of collaboration between partners and non-availability of timely information. As a result, organizations end up either under stocked (that leads to lost customers) or overstocked (leading to unwanted inventory carrying costs).

It is imperative then, that companies can no longer bank on traditional solutions that only track inventory and its associated cost within the company's boundaries. Today's companies need to act on sudden changes/disruptions occurring in the supply chain that could otherwise have negative impact. Hence there arises a need to implement a system/process that can collaborate and obtain information from various sources, analyze and help formulate strategies for a more 'visible' supply chain.

Today's ever expanding supply chain environments have forced companies to think beyond traditional techniques of partner collaboration and information management which otherwise only increases latency and inconsistency. Systems not only need to be able to collaborate and provide data rich solutions but at the same time be nimble when expansion and changes occur. This is where most modern supply chains are automated - and Visibility is no exception.
However, leveraging the right technology is quintessential. The rules, flexibility and exceptions associated with supply chain information have created large volumes of data for companies to evaluate. The right technology can analyze data and produce valuable business intelligence, which can ultimately lead to better, more informed supply chain decisions.

Following are some points that can help choose a best-in-class Visibility system:

Ease of on-boarding: This is a step that needs to be executed with utmost caution and with ease. A challenge modern companies face is in onboarding partners onto their network. In some cases of modern Visibility implementations, this has been a deal-breaker! Not all partners of customers are gung-ho about painstakingly making themselves part of new networks.

Collaborate & Integrate: Firstly, to achieve total visibility it is very important for all partners of the network to share their side of information on the proceedings. Secondly, since different partners work on different systems, each of them may have their own data standards. The visibility system should collaborate and consume data in various forms from across all partners and use it in the best possible way.

Present Information Effectively: Data accumulation & management still remains a key ingredient to a successful Visibility program. Equally important for Visibility systems is to provide a platform that helps evaluate KPIs, compare information using scorecards and create strategic dashboards that can be utilized to take better decisions and improve overall supply chain performance.

Manage surprises: As organizations resort to more globalization and outsourcing, there is always an element of surprise embedded into the supply chain. As long as Visibility systems are able to keep key participants informed of key events, the system has proved its worth. A valuable visibility system also tells you what you SHOULD know in addition to what you already know. Most modern Visibility systems term this as 'Event/Alert Management'.

Be Near Real-time yet Scalable: A typical Visibility solution interacts with multiple systems to acquire, assimilate, churn and present data in a comprehendible way. Common challenges in this area are reading partner data in different formats and still adhering to different business rules that govern data processing. In trying to do so, performance should not be compromised.

'Partner type' dependent: Visibility is every single partner's problem. A competent Visibility solution should be able to present same data to all participants of the supply chain network, with their individual perspective. Example: For a shipper, number of shipments at a 3PL warehouse might be a relevant metric while the 3PL provider may be more interested in the number of shipments for all serviced shippers. However, processes within an organization should clearly outline owners of specific areas that are able to respond and take action in case of surprises.

Having considered the above points, the onus then is on companies to conduct a detailed study on existing processes, identify opportunities to streamline them and at the same time, evaluate the best of technology vendors that enable successful Visibility programs. For any modern day supply chain, technology enabled visibility system is not to be treated as an overhead but as a backbone of operations.

May 2, 2012

Supply Chain Control Tower Readiness- Part Two

Joint Post by

Gopi Krishnan GR, Practice Manager - Business Application and Services, Retail CPG, Logistics and Life Sciences, Infosys

Arun Kumar, Principal Consultant - Business Application and Services, Retail CPG, Logistics and Life Sciences, Infosys

In part 1 of this interview blog series with Supply Chain Matters, we have already analyzed the readiness of both IT and supply chain functional industries for the need to go for broader visibility, more timely and accurate decision-making, and predictive process capabilities which are more frequently expressed in the context of supply chain control tower (SCCT) capabilities.

In part 2 we have shared our views on the mode of expression of SCCT and our view for the best approach for adopting SCCT. Please read part 2 here.

Supply Chain Control Tower Readiness- Part One

Joint Post by

Gopi Krishnan GR, Practice Manager - Business Application and Services, Retail CPG, Logistics and Life Sciences, Infosys

Arun Kumar, Principal Consultant - Business Application and Services, Retail CPG, Logistics and Life Sciences, Infosys


With the current scenario of rapidly increasing base of business in terms of geography, customer base, varied suppliers and voracious line of products, the complexity of the global supply chain is becoming more difficult to manage.

In lieu of this, modern organizations are spending a lot to re-define the needs for broader visibility, more timely and accurate decision-making, and predictive process capabilities in their supply chain methods. These needs are more frequently expressed in the context of supply chain control tower (SCCT) capabilities.

We have expressed our views in an interview with Supply Chain Matters and posted it as a 2 part blog series on "Supply Chain Control Towers Readiness". In part 1, we have analyzed the rationale for SCCT in the IT industry as well as supply chain functional areas; and whether the readiness is coming from specific industry sectors. Please read Part 1 here.


Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter