Enterprise IT: Inside an SAP customer
Mead Johnson Nutrition, a public spin off from pharmaceutical giant Bristol-Myers Squibb, is an SAP customer currently in the middle of a large business transformation project. To gain an insider perspective, I spoke with Paul Ritchie, who runs the company's global project management office (PMO) and reports directly to Mead Johnson's CIO.
Paul is responsible for Mead Johnson's IT budget, vendors, projects, infrastructure, and business process outsourcing. In his previous position, Paul headed SAP's global PMO, and helped develop various methodologies and tools used by SAP projects around the world. This combination of vendor and customer experience gives Paul a unique perspective on life in the SAP world.
Please listen closely to this valuable podcast by clicking the player at the top of this post. The recording contains a wealth of information and advice that is useful for enterprise IT customers, software vendors, and system integrators. The following notes reflect the podcast recording but are not a transcript.
==========
On customer accountability and system integrators:Customers should control the conversation with their integrators and lead from that premise.
Customers and software vendors cannot expect the system integrator to take final accountability for project success. Although vendors may be responsible to complete certain work, the customer must lead and drive the result. Customers cannot expect their integrator to prioritize, escalate, direct, and drive topics to closure.
The integrator's primary interest is managing the contract and scope of work, so the customer must remain responsible for managing the integrator's performance.
On the SAP brand:
The SAP brand is so powerful that it overwhelms even unrelated parts of a project. For example, people think of infrastructure as an "SAP project," even though it has almost nothing to do with SAP (except for hosting the system).
SAP and other large software vendors do not always understand the power of their brand over the integrators. The integrators need the software vendors at least as much as they vendors need them. For example, our integrators clearly owe a great debt to the methodology, documentation, and best practices developed by SAP.
On enterprise software maintenance:
At 17-22 percent of the license fee, maintenance is a very expensive form of insurance or, to be less charitable, it's a tax on the customer from the vendor.
Even though some of our systems are mission critical, the maintenance money funds other applications that the vendor then requires us to license separately. Expensive maintenance is one reason that SaaS is attractive.
On negotiating with SAP and other vendors:
To obtain a reasonable total cost of ownership (TCO) over time, you must be aggressive negotiating your license deal. You have to be very careful at license time, and it's a big risk, which explains the discomfort customers have (or should have) dealing with software vendors. If you make a mistake, your company can end up with unused licenses (shelfware) or an overly high license fee against which the software vendor will calculate maintenance.
On software as a service (SaaS):
We use SaaS-based enterprise applications, but are reluctant to consume our core value- or supply-chain apps on demand. Our SAP system is on premise, of course.
SaaS offers an attractive model because the pricing is very transparent, although often the deal is not quite as good as you hope. If you understand pricing, you can negotiate roughly equivalent deals for on-premise and on-demand software.
However, SaaS does offer a cleaner, more transparent model than on-premise.
On data lock-in with SaaS:
You lock yourself in with SaaS just as surely as with on-premise.
Sure, you can drop the subscription, but with enterprise applications, you must migrate data out of the old system and into the new one. It's not as "no-fuss no-muss" as SaaS vendors would suggest. Data migration is one reason most on-demand applications remain at the edge, where you can get in and out relatively quickly.
THE PROJECT FAILURES ANALYSIS
We can draw several conclusions from the discussion with Paul. These lessons are applicable to customers, system integrators, and software vendors:
1. Customers are responsible for their own success. Technology buyers ultimately take the risks and reap the rewards for their enterprise projects. While third-party vendors and integrators can share the workload and bring in specialized expertise, final responsibility for successful project completion remains with the buyer.
2. Maintenance is a sore spot. Perhaps not surprisingly, vendors and customers have different views of maintenance fees.
From the customer perspective, maintenance is an expensive "tax," as Paul described it. On the other hand, software vendors see maintenance as a legitimate means to offer the high level of service that customers demand on their mission critical business systems.
As Paul suggests, the customer's best defense is to negotiate carefully with vendors.
3. SaaS is growing but not yet central to the large enterprise. Mead Johnson uses SaaS-based enterprise applications from several vendors. Although it prefers the on-demand business model, the company still uses on-premise software for core applications.
==========
Thanks to Paul Ritchie for participating in this podcast discussion and recording. Disclosure: Mead Johnson is a customer of Asuret, where I am CEO.