Seven common myths about SAP—and the reality they hide

Lizelle Pauw examines seven of the most common myths about SAP, and contrasts them with the reality.

February 7, 2013

“SAP is hugely successful and trusted by many great companies—and yet there are persistent myths and misconceptions that circulate about it,” says Lizelle Pauw, project director at Barnstone and an SAP veteran. “When you examine these myths, however, you tend to find that there is a better way of thinking about SAP—the way taken by the many companies that rely on this software to fuel their success.”

Pauw examines seven of the most common myths about SAP, and contrasts them with the reality.

Myth: It takes a year or longer to implement SAP.
Reality: There are many examples of SAP implementations that have taken four months or less.
Long implementation times are common but, says Pauw, that’s because projects tend to kick off with laborious client workshops around each process. The result is inevitably scope creep as the team puts together the blueprint for a Rolls-Royce process that entails extensive, time-consuming development and customisation that needs documenting and testing as well.
“New approaches, like SAP’s Rapid Deployment Solution, preconfigured templates from companies like Barnstone and better project management all address this challenge—very successfully,” says Pauw.

Myth: SAP projects always run over budget.
Reality: Across many industries, SAP projects come in under budget as well as under time.
As noted above, traditional SAP contracts have been structured on a time-and-materials basis with clients taking the lead in creating each process. The project thus ends up being something of a moving target as clients pursue perfection and consultants test new boundaries. By taking a standardised approach and charging for customisation and special reports upfront, it’s easy to keep within the original budget.
“You’d be surprised how unessential most customisations turn out to be when there is a specific cost attached to each one,” Pauw remarks.

Myth: Once an SAP system goes live, functionality does not work.
Reality: SAP works—if you leverage its built-in best practices and processes.
Like the previous two myths, this one can be traced back to the traditional approach of customising SAP excessively to enable existing (or ideal) processes. Wrenching the system into a new shape is not only time-consuming and expensive, it creates unexpected inconsistencies. Again, current thinking, as epitomised in the Rapid Deployment Solution approach, is to reduce customisation to essentials, thus avoiding this problem. “Standard SAP works!” avers Pauw.

Myth: To implement SAP, the business has to supply a full project team.
Reality: Businesses need supply only small teams—provided they are following a standard approach.
Providing a business resource to shadow each member of the consulting team is a general practice that imposes a huge burden on the client, and is only necessary if one is redesigning processes. By adopting the best-practice processes embedded in SAP, the business need supply only ad-hoc resources for process verification, user acceptance testing and training.

Myth: Users have to know how SAP works the moment the system goes live.
Reality: Users can learn SAP quickly within the context of their job’s requirements.
Following the new approaches, traditional pre-go-live training is supplemented by on-the-job training with users on the live system. In this way, users can quickly grasp how SAP works in relation to their own tasks. As important, they learn how to correct mistakes—an important skill that simply can’t be practised in the training environment.

Myth: It’s best to implement all the SAP modules at once.
Reality: Incremental implementation of SAP is easier to control—and less risky.
Beloved of consultants, the big-bang approach causes projects to balloon in size and expense—greatly increasing the risk as well. The better approach, says Pauw, is to lay a solid foundation by implementing those modules that cover the core business processes. These would invariably include finance and procurement, and then, depending on the industry, modules like production or plant maintenance. Non-core processes like business intelligence, or governance, risk and compliance should wait until the basic system has bedded down, and users start to call for them.
It’s vital that the system is set up from the beginning to accommodate this phased approach.

Myth: SAP is only for big companies.
Reality: Small and mid-sized companies are using SAP successfully.
Many of the myths noted above help to create the widely held belief that only large, well-funded companies have the resources to benefit from SAP. Nothing could be further from the truth—and SAP has been extremely proactive in developing versions of its software (like SAP All in One and Business One) to give smaller companies the ability to compete on equal terms with global giants in today’s increasingly integrated, global markets.
“Problems with SAP can usually be traced back to flawed thinking around the implementation, and not the software,” Pauw concludes. “By correcting our thinking, we can better take advantage of the software’s inherent functionality—and finally explode these myths.”