SAP & ERP Consulting from the Customer Point of View

SAP Reimplementation

Some time ago I started a series on doing an SAP reimplementation for little more cost than a technical upgrade.  While I have done these, there were also a couple of interesting scenarios that added new complexities which needed to be addressed.  For example, how do companies deal with a seriously fragmented application landscape?  This is esepcially true in large enterprises where each company code, location, business unit, or other area decided to implement their own SAP applications independent of the others.  Then there are the companies with rollouts or upgrades underway.  For them the situation is a little different.  As a result I have decided to try to wrap this up with a focus on three key types of situations outlined below.

To review the previous posts on this topic, please see:

• Technical SAP Upgrade or SAP Reimplementation
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2

This topic is difficult just because there are so many “dimensions” of options to consider. As a result I’ve narrowed the focus to a few key areas.

Primary SAP Reimplementation Approaches or Options

As I pondered it more, and looked at the re-implementations I’ve done, as well as some of the system assessments and options, I finally decided to “bracket” them with a few key approaches. Because the numbers of options for re-implementation are too significant to address here I decided to stay at the high level to cover the major approaches.

1. A reimplementation of a single SAP production instance.
2. Integrating a landscape with multiple SAP production instances onto a single global instance.
3. Rollout – whether it is an ongoing project that is not complete or a fully implemented system and you are considering an upgrade.

SAP Reimplementation Assumptions

As I wrote previously, one of the crucial considerations for a re-implementation is to move away from Software Engineering and toward business process engineering. First, let’s establish a few very basic assumptions about an SAP reimplementation:

1. After you went live, or as you continued to roll out your solution, you discovered several “if we had known “x” we would have done “y.”
2. Or, you may have incorporated a significant amount of custom code, or custom application development (inside or outside of SAP) and discovered that standard functionality would have met about ~90% (more or less) of your requirements (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).
3. You’ve already worked through the hard stuff in your original SAP implementation (see the section by this same title in SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1). In other words, the hard decisions around the processes, organizational structures and data types have already been made.
4. You may have additional functionality or other modules you want to implement and find that custom coded “solutions” are making them difficult to bring in.
5. The custom-coding is requiring significant amounts of time for break-fix testing, integration testing, regression testing, SOX or other regulatory compliance when any new change is added.
6. As new regulatory or other industry requirements are established, in whatever jurisdictions your company operates, you have to custom-code new solutions to meet them (rather than using SAP’s standard maintenance to add the new functionality).
7. The time to work around all of the customized “solutions” when you want to add new functionality, or new modules, takes a significant amount of time.
8. In some cases adding on brand new functionality is nearly impossible because of how much your system was “hacked together.”
9. You need to upgrade, but there are probably hundreds, and in some cases thousands of custom programs to evaluate, test, integrate, and update to the newer version of ABAP.

Coming up we will start to review the three key types of re-implementations: a single production instance, consolidating multiple instances into a single global instance, and a re-implementation rollout.

Related Posts:

• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• Key Design Considerations for SAP Reimplementation
• SAP Reimplementation Method Key Considerations
• Technical SAP Upgrade or SAP Reimplementation

SAP Project Leadership

SAP Project Management drives me crazy!  As I’ve often said, I don’t generally fault customers or clients who hire outside help for SAP project management.  If they believed they had the answers they wouldn’t bother with contractors for guidance.

Too often I see SAP project management treated as more project administration without much leadership.  Just about anyone can be a checklist administrator.  What is lacking from many SAP projects is the project management leadership to move things along.  

After managing a few SAP projects myself and the many projects I have participated in over the years I’ve learned an effective formula for SAP project success–, it takes a project manager who can actually lead the project.  What do I mean by leadership?  I mean someone who actually pitches in, rolls up their sleeves, gets busy, and gets their hands dirty.  They must be directly engaged with the project participants, they need to spend more time with their “ear to the ground” rather than serving as passive administrators. 

The key dimensions of SAP project leadership involves enough direct involvement in project coordination to:

1. Create a sense of urgency to build momentum.
2. To maintain that sense of urgency and maintain momentum.
3. To eliminate obstacles, roadblocks, and impediments which slow (or even stop) SAP project momentum.
4. To manage conflict (which WILL happen if sufficient momentum is gained).
5. To set, manage, and maintain expectations with both the project participants and the broader areas affected by the SAP project outcomes.

1.  Creating a Sense of Urgency

I’m still amazed at how often SAP project managers or program managers avoid using project plans with WBS structures, tasks, activities, and the assorted milestones, etc.  The only sense of urgency they create is reactive firefighting.  Everything will always be last minute, single-threaded, chaotic, disjointed, panicked, and difficult to follow.  Without a structured project plan any dates are just aspirations at best and timelines will continuously be missed.  This avoidance may be from a lack of ability, fear, or an attempt to evade accountability, whatever the reason it happens too often.  Maybe you should be asking yourself what deliverables, tasks, and execution activities your contracted leadership should be providing.

The Effective SAP Project Plan and Project Structure

The most appropriate method to create a sense of urgency is to have a fairly tight timeline but with very clearly defined milestones, tasks, deliverables, templates, and instructions on how to support project execution.  Those deliverables must help to measure project progress and they must be carefully managed.  Communicating and then supporting the message that as an SAP project manager your goal is to ensure the success of the project participants (then living it out) will bring badly needed leadership.

Without a project plan and proper templates any sense of urgency that is created is really reactive firefighting.

For each project phase or upcoming milestone an SAP project manager must have well defined presentations of what is coming, the timeline,  templates, instructions, and the resources to accomplish each set of tasks.

Nearly every contract SAP project manager somehow manages to put together steering committee presentations so why do they have such a hard time putting together critical project supports?  What are they really presenting to the steering committee if they aren’t providing meaningful project guidance?

If SAP Project Decisions Need to be Made Get Them Made Immediately!

Over the years I’ve been blessed to have several pretty decent mentors.  Back when I was an early manager in industry, long before consulting, I got a major schooling from our GM (and a senior VP).  We had a problem come up and the GM wasn’t around to consult so I did nothing.  I was the operations manager responsible for all shop floor production areas–, over a dozen leads and over 200 employees at the time.  My lack of decision-making brought large portions of the production floor to a halt. 

A “manager” who doesn’t make decisions isn’t managing or leading anything.

When the GM/VP got back he immediately set about to get things going and made a number of snap decisions and provided immediate direction.  After things got going again he called me into his office and we had a short discussion about my career.He was polite but firm and provided me a very valuable lesson. 

The GM expected me to make the decision I believed was correct even if it turned out wrong.  He said that 8 or 9 times out of 10 it would probably be right and that 1 or 2 that might be wrong or maybe not the best decision it was easier to correct than doing nothing.  He promptly let me know if I made a bad decision he would hold me accountable but it would not be as bad as making no decision at all.  He would hold me accountable for my decisions to help me learn to make better decisions but if I couldn’t make a management decision to keep things going he didn’t need me because I wasn’t managing anything.

That was a profound insight.  As an SAP project manager if you won’t make the tough decisions to get things going and keep them going then what are you managing?

Decisions must be made as quickly as humanly possible.  Delaying key decisions, or delaying any decision making, creates the appearance of indecisiveness, reduces confidence in your ability to lead, creates constant “swirl” around key issues, and slows the project.  It also creates an atmosphere where others avoid decision-making and become embroiled in analysis paralysis (or “swirl”) because that is the culture you as the project manager are creating.

Next week, more on building and maintaining momentum and the sense of urgency.

Related Posts:

• More SAP Project Leadership Tips for Managing Conflict
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• SAP System Vendor Project Success Criteria 1
• Series on SAP ERP Project Success Factors
• 5 More Leadership Tips for Successful SAP Project Management

Business Systems

The day after I released my last post (SAP IT Governance – Achieve Business IT Engagement) techrepublic.com published a review of the CIO future direction. While I do not agree with all of the Gartner conclusions they published I certainly agree with the “new CIO manifesto” (TechRepublic: Get drastic: 15 IT best practices to kill). Reading through the comments left on the TechRepublic post was enlightening, most of the comments focused on the details of one or two points of disagreement while missing the focus of the entire message.

Denial of the purpose of any IT initiative, especially SAP business solutions, will only lead to significant levels of outsourcing. IT areas and functions that become more like “commodities,” or, as one commentator calls these functions “taxes” on the enterprise are quick to be outsourced. While these “taxes” are necessary infrastructure components (such as e-mail, phone, wide area networks, and even PCs or laptops), other areas are starting to be seen as commodities subject to significant cuts.

SAP Consultants Must Get Serious About Customer Focused Value (or find another career)

Unless more functional SAP application consultants get serious about understanding business and helping stop the fakes then enterprise applications will become a commodity as well. This isn’t just idle speculation. Those of us who have been around SAP for 10 years or more (and some of us approaching 20 years or more) remember the days when ABAP skills were sky high–, now they are a commodity which is frequently outsourced to India, Malaysia, or China. The same commodity status is true of SAP Basis–, it is outsourced overseas or to hosting providers. Without real value SAP (or Oracle, MS Dynamics, etc.) are soon to follow.

The Coming SAP Business Technology Revolution

The TechRepublic post hit on a key theme which is the focus of this site–, helping business realize (and recognize) value from their SAP projects. Under the subtitle “New CIO manifesto” TechRepublic notes:

“information [may be] more important than information technology” and the majority of IT spend will be used to “measurably improve… financial conditions of an enterprise” by supporting “revenue generating rather than expense related business processes.”

This manifesto is more aligned to sales, marketing, and innovation. These areas of the enterprise are in line with CEO priorities (see e.g. What is the Proper Relationship for the CIO, CEO, and CFO?). The TechRepublic post then goes on to note that:

“IT has to stop thinking of itself as a business utility and start seeing itself as a business catalyst. In order to do that, it’s going to have to think in business terms and economic impact for everything it does…”

What Can Skilled SAP Consultants Do to Prevent Becoming Commodities?

FIRST do what you can to educate clients around consultant screening (for details see Protecting Yourself from SAP Consulting Fraud). For example, if you find out a client is looking for consultants ask them if they have received that candidate’s references from their last three projects and whether they directly asked for confirmation of experience from those references?

As clients continue to see marginal or substandard results from so many of these frauds they will consider you the same and rate pressure will quickly move you to commodity status. Worse still, you may be on a project where you have to do so much clean up and correction behind an incompetent consultant just to get your own area working that you do not have the time to deliver on real value that will set you apart.

SECOND make sure you focus your consulting efforts on delivering value to your clients. When I say value I mean in terms of business benefit and return on what you are being paid for. Don’t just do some configuration because that is what you are being told, or because that is what is in scope. Do it in such a way that it helps the client long term. For example, just because SAP supports a particular type of functionality the ongoing maintenance after go live may not be in the client’s best interests. Carefully consider the short and long term effects on your customer of what you do. If you take this approach you may lose out on a little extra billable time in the short term, BUT you will stand out to them as someone who looks out for their interests. When it comes time to upgrade or add on additional functionality a call from you could land you a direct client without the middle man staffing firm. You can avoid competing with so many of the frauds the staffing companies try to place which may destroy a client project and damage the value you can add.

The choice is yours. You can start working to be more client and customer focused to generate value or you can watch the marketplace move you to commodity status. In the end no matter how good you are as the marketplace erodes your value in it does as well. It’s time to start acting like a consultant, a paid advisor to give your client the best possible direction you can and in doing so you also help to protect your own future as well. For more insight on delivering SAP enterprise value focus on the components of ERP II or ERP III (see ERP vs. ERP II vs. ERP III Future Enterprise Applications).

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• Using SAP to Improve Revenue and Profitability
• SAP IT Convergence Beyond Business to IT Alignment