Implementing SAP: Successes and Opportunities
Implementing SAP, or any ERP application, should be thought of and planned for as a journey, not an event. Just like when you go on vacation, you need to have an idea of where you want to go and how you want to get there. Without a roadmap, any road will take you somewhere, but you could be surprised where you end up!
With SAP, there is no such thing as “just turn it on” and start training people on the new business process. We’ve all heard the stories or experienced the implementations that go on for years, run over budget, and in the end fail to return the expected value, but this can be avoided. Successful implementations have a defined scope, support business operations, streamline processes and enhance productivity; they don’t implement technology for the sake of technology.
At Tronox, we are aligning our SAP roadmap and implementations to the areas that add the most business and customer value. One of the first steps in the implementation plan is defining the business need we are trying to solve and gaining alignment and commitment for support of the program. For a successful outcome, it is critical to have business commitment and dedicated support throughout all stages of the program; without dedicated, committed business support, don’t start the program.
Once the business need is understood, including the business processes and operating model, and commitment is aligned, the application of technology, while not trivial, becomes the easy part.
Another area where we are changing our approach is around implementation cycles. Traditional ERP programs are done in a “waterfall” methodology which includes gathering the requirements and waiting several months, or longer, while the designers and developers do their thing before delivering a finished product for review. Only then do you get to see if your requirements were understood and if this new applications actually meets your needs. The approach we are taking at Tronox with all new projects leverages an iterative development methodology where we deliver pieces of functionality much sooner on a regular release schedule.
While this approach doesn’t necessarily reduce the overall program delivery time frame, it does allow users to see progress more frequently and also minimizes the impact of rework as changes in design can be incorporated in one of the next iterations. Again, this all needs to be part of your roadmap so that interdependencies are understood, but there are significant efficiencies that can be gained from early course corrections. Additionally, more frequent releases of capabilities aids in keeping the teams engaged and energized.
As you define your overall program requirements, don’t overlook the need for testing and reporting. In many programs there is a tendency to put off testing and reporting requirements until a “later phase” of the development process as there is a perception that they aren’t critical to the design. I have been on programs where we made this mistake, and yes, it is a mistake that should be avoided. While it may not be possible to gather detailed requirements for every test case or how a report has to look, it is important to have the conversations about how you will test new functionality. These test cases should include the definition of what would be a successful test outcome and what would be a failed test outcome. Without defining test cases up front, you are more likely to test for the expected outcomes, not the unexpected outcomes. It is these unexpected outcomes that usually have the biggest impact on program timelines and user perception. On the reporting side, driving the conversation about metrics, performance indicators, and operational and analytical reporting needs is helpful for defining the overall development portion of the roadmap, but it also can elicit additional requirements that may have been missed if the focus was only on the transactional need. Reporting can also help showcase the success of a program as well as identify areas where improvements can be made.
“In many programs there is a tendency to put off testing and reporting requirements until a later phase” which is a mistake that should be avoided”
Other key activities that must be part of your roadmap and every program include training, and change management. While SAP has made great improvements to the user interface, successful programs include training to make sure users are aware of the new functionality and know how to use it effectively. Training is even more critical if the program delivers process change in addition to the new technology so that users understand how the transaction and the new process work together. Change management is also key to delivery of a successful program. The introduction of process change and new technology can be disruptive, even if it ultimately enhances productivity and streamlines processing. Making people aware of the changes that are coming and explaining the value of those changes helps set the expectations for success of a program.
Delivering a world class solution that no one knows how to use or why they are using it will certainly not deliver the expected business value. So, you’ve aligned your roadmaps with business value, defined your programs, secured your sponsor’s commitment, and delivered your program; congratulations, it’s time to celebrate! Make sure you take time to celebrate; these programs are hard work and touch a lot of people, so be sure to recognize their contributions. Ok, now the celebration is over, but the work is far from done. Before you can get back to delivering the next initiative on your roadmap, transitioning this program from implementation to support must be done to be truly complete. SAP, and your business processes, are always evolving, so it’s time to update your roadmap to include enhancements, support packs, patching, etc. Don’t overlook this last step; keeping SAP current and aligned to your business needs is key to continued successful delivery.