You should never be implementing SAP for the sake of SAP. The investment should be directly linked to the realization of business benefits over the course of a payback period. Without benefits, SAP is just a stopgap. An expensive stopgap.
Stop-gap / stäp.gap/
noun. a temporary way of dealing with a problem instead of satisfying the real need.
More often than not, project managers find themselves in the situation that their organization ‘is going wall-to-wall SAP,’ and they are then left to implement the chosen application without a clear understanding of the expected benefits and the organizational changes that will be required.
Here is what happens next as the project managers work their way out: NT + OO = EOO (New Technology + Old Organization = Expensive Old Organization)
Any SAP implementation should be embedded in a fundamental business initiative to transform the business. You are not implementing SAP for the sake of SAP or because of its features like multi- currency, the ability to define sales organizations, reporting, etc. Good old Michael Hammer knew this as no other.
You are doing so because you want to gain benefits that are essential for the survival of the organization. Technology is an enabler on that path. But if you fail to paint a clear picture of the destination it is a stopgap. The technology is rolled out, there is a successful go-live; pizza, party and then everybody goes home.
It ain’t over ’till it’s over
Benefits formulate the goal of a program in terms of the success of your organization. These are the beacons, guiding the program to develop in the right direction. Benefits are the basis of the business case to justify the cost of the SAP implementation. They make outcomes concrete, measurable and above all: actionable.
The point is that the project ain’t over till the benefits are realized! Implementing SAP is just a step on the path towards realizing the benefits.
In an ideal world, the decision to implement SAP fits in an overall business strategic program derived from the company’s business vision. In many cases, however, the decision to implement SAP is based upon a combination of less compelling operational features, listed below:
- Legacy systems need to be replaced;
- More integration of information is required;
- Better integration of the IT landscape is needed;
- The current version of SAP will no longer be supported;
- Common ways of working need to be implemented;
- The supplier of current systems doesn’t provide proper support, or worse, is no longer financially stable;
- Data integrity;
- Improved continuity and enhanced disaster-recovery planning
Yawn-provoking indeed. But here’s the thing: unless you are able to convert the above mentioned reasons into benefits that serve the organizations strategy, you will not be able to win the hearts of your stakeholders. This means: a compelling vision AND actionable benefits that will prevent to see the SAP implementation as an end in itself.
In short: If you are unable to come up with quantifiable benefits, you should consider not moving forward with the SAP implementation. If you do, you risk getting lost in the fog without a beacon to steer for.
Outcomes are the destination postcard (you can see the picture and you want to go there), and benefits are the black-and-white writing on the back of the postcard (the exact coordinates). SAP is a fuel station on the way to the destination. If SAP is figuring either on the front or the back of your postcard you’d better cancel your travel plans. It’s not about stopgaping symptoms with SAP, it’s about treating the real causes with benefits realization!