Companies committed to SAP often find themselves faced with hard choices when it comes to the user experience: accept the consequences of asking employees to learn and use the less than optimal SAP interfaces; limit the rollout to power users in specific roles (sacrificing the value of end-to-end ERP); or develop custom front-ends to the SAP system, leading to a proliferation of point solutions that must be supported and maintained.
Whichever option you choose, you may experience trade-offs:
Taking the hit from the learning curve. After deploying SAP, Lumber Liquidators attributed significant losses to complicated user interfaces, which required extensive retraining of sales associates. The company estimates that the new point-of-sale and inventory management system developed by SAP led to millions of dollars in reduced productivity and lost sales, resulting in up to $14 million in unrealized net sales during the third quarter of 2010. That amounted to a drop in net income of 45 percent relative to the previous year—not the ROI anyone would hope for from an ERP implementation.
Limiting the rollout. As discussed in an earlier blog, Avon has curtailed deployment of its new SAP system. The project—slated for a global implementation spanning the U.S., UK, Brazil, Mexico, and Russia—was stopped because a pilot deployment in Canada caused “significant business disruption in that market, and did not show a clear return on investment,” according to the company’s SEC filing. This leaves Avon with disparate systems, rather than the unified global enterprise it had envisioned when it embarked on its ERP initiative.
Developing alternative front ends. At Microsoft, we use SAP for certain core financial processes, however while most employees exchange data with SAP on some level, a very low percentage of employees ever see a native SAP screen. We have over time developed or acquired and integrated a large number of applications that employees will use and that subsequently feeds SAP. One such example was our employee expense reporting application which originally featured two purpose-built front-end applications: a custom, browser-based portal interface (used by employees in the U.S) and a Microsoft Office-based application that allows employees outside the U.S. to track expenses in Excel spreadsheets, which then transmit the data to SAP.
Most CIOs & CTOs will recognize that building and maintaining a growing suite of custom point solutions around SAP isn’t an optimal long term approach; as we found, it can leading to spiraling costs and increased burden on IT and over time restrict organizations from implementing new strategies.
How we made it work: At Microsoft we are in the process of consolidating many of these non-SAP applications onto AX to allow for a better user experience, lower TCO, increased flexibility, etc. In fact we have a clearly defined strategy that helps guide us in when to use what solution. One of the areas we have already consolidated is the before mentioned expense reporting systems which we replaced with out of the box functionality in Microsoft Dynamics AX & SharePoint. Besides from the benefit of standardization and common user experience, this approach has allowed to easily add mobile expense reporting capabilities for all employees, while still offering the same secure exchange of data with SAP. And as an added benefit Dynamics AX provides a platform for rapidly deploying additional applications—without increasing the demands on our internal development & support teams that we were used to.
We’ve maintained our core SAP processes, while actually driving increased adoption, enhance productivity, and user satisfaction. And we’re not alone. SAP customers including Hunter Douglas and the Wuerth Group have experienced similar success, consolidating applications and delivering fantastic user experiences—without disrupting their core SAP implementation.