SAP & ERP Consulting from the Customer Point of View

Key Design Considerations for SAP Reimplementation

Bill Wood — Mon, 06 Feb 2012 12:50:35 +0000

SAP RE-implementation

Whether you are doing a single instance reimplementation, a system consolidation, or an upgrade rollout you will need to blueprint the differences between your current state and what needs to change for your future state. Depending on your SAP reimplementation approach there are several key considerations in the SAP reimplementation blueprint.

All three approaches require a few key steps:

rationalize your landscape,
consolidate your functionality scope,
evaluate data differences and consolidate custom field requirements,
inventory and eliminate as much custom code as you can,
design for usability

SAP System of Record

Probably the first decision will be the SAP system of record. This simple concept seems to escape many consultants, clients, and project managers. Deciding which system will be the “source of truth” for any particular processing stream is critical. That decision determines landscape architecture, how data conversion decisions are made, interfaces, and how to reconcile data. I’ve seen so many meetings and discussions which spin forever because there is no clearly defined “system of record” for a particular processing stream.

If you have a single instance of SAP and are looking to undo some of the prior custom coding then this decision is easy. If you have a diverse SAP landscape it would be hard to imagine that you do not have one of them that you do financial consolidations or house a central chart of accounts. That system would most likely be the candidate for the “system of record”.

Depending on how fragmented your SAP landscape is with multiple SAP instances in various locations the decision may not be so easy. Even with a central system where you do financial consolidations or official reporting it may not be the best candidate if there has been a lot of custom development work. One of the “satellite” SAP instances may be a better starting point if it has remained fairly close to standard. You will have to carefully evaluate which system works best for your needs. Ideally this system would be the one which has the least amount of custom coded requirements.

SAP Organization Structure

You will want to take a hard look at reconciling and adjusting your SAP organization structure. Whether it is a system consolidation, a rollout, or a single system reimplementation the organization structure is the base you build the system on. The organization structure becomes the foundation for your master data requirements, reporting requirements, and key functionality decisions.

A properly done organization structure can enhance reporting functionality without dramatically increasing the amount of master data maintenance. However when it is poorly designed, as you may have discovered, it can create a data maintenance nightmare and still not provide key actionable information. This raises another consideration for a re-implementation –, if you have a significant investment in custom developed reports they will need to be revisited.

In some cases, even the extra expense of the additional reporting requirements may be justified if the new organization structure provides you with enhanced reporting capabilities or simplifies some of your processes. The key to remember here is to look past the short term to the TCO (Total Cost of Ownership). If the changes might have a 3 – 5 year payback horizon it may be justified. Especially when you consider any future upgrades with the more “stable” organization structure, quicker turnaround, lower cost, less regression testing, outside talent which can come up to speed quicker, etc.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP Reimplementation Method Key Considerations

Bill Wood — Mon, 30 Jan 2012 13:15:40 +0000

SAP Reimplementation

Among three variations for SAP software re-implementations there are two key approaches. You either make the changes to your existing production system (or a cloned copy of it) or you make the changes in a pristine, newly designed environment.

SAP Cloned Production System “Re”-Implementations

Making changes in your existing production system (more likely in a cloned instance of it) helps ensure data consistency and ease of adjustment, however there are several difficulties involved. If you have a significant number of custom-coded solutions you will have to fight them every step of the way. You will have to work around them, deal with them throughout the process, adjust any out of date coding, and most likely will end up keeping many of them. As you can tell, I’m not a big fan of an SAP reimplementation in a production system with lots of custom coding.

You either make the changes in your existing production system or in a newly installed instance with no data.

For example if you decided to consolidate organization structures from a multi-system environment you might quickly discover lots of hard coded values in custom programs. These hard-coded values in the programs themselves, rather than using table driven values and parameters, can cause system consolidation nightmares. This is just one type of problem from many of the custom-coded solutions so often provided.

Another problem occurs with any of the existing system configuration. If you make changes to existing objects that are already in production you have the challenge of timing and coordinating your cutover to prevent disruption to existing processes. Depending on your circumstances if you decide to do a transition in your own production system with the eventual goal of moving away from it and into cleaner environment then it may be best to create all new custom configuration objects. You have to make that determination.

Clean SAP Re-Implementation with Old Legacy SAP for History

The other approach to SAP re-implementation is to do a re-implementation in a clean, non-modified system. That approach assumes that after conversion to the newly designed environment you will leave your old “legacy” SAP system in place for reference and historical data only. Using a new system for a re-implementation means that you do not have to work around any of the bad setup or design decisions that were made previously. You avoid all of the headaches with the custom programs and only bring in those custom programs that are really business critical.

If necessary, and if you already have a BI / BW / or other reporting system it will require some additional work to integrate old data structures with new. However even that will be easier with standard functionality. The SAP BI / BW / BObj reporting options already contain a number of standard extractors that can be used more easily and with less expense.

The Optimum Solution is a Phased SAP Global Instance Harmonization

The most cost effective way I have found over the years to do a reimplementation is to bring in an operation that is moving to SAP in a “clean” environment. It is not particularly complicated to integrate two SAP systems using ALE (Application Link Enabling). In this way you create a new environment, with more up to date and more standard functionality that you can eventually migrate other business units into.

As upgrade projects occur it is only incrementally more expensive to migrate the upgraded companies into the less customized environment. With an upgrade you still have to do the custom ABAP program reviews, code validations, etc. With a cleaner environment that does not have all of the custom coded artifacts it is much easier to pick and choose what is really of value and what can be replaced by new, or better understood functionality.

For additional rollout locations there is virtually no additional cost over the rollout project for bringing those companies or organizations onto the more standard SAP environment. In fact, the reduced custom coding would tend to be less expensive because the amount of time spent regression testing custom functionality, or fixing any organization specific settings, as well as training people how to deal with some of the custom functionality would be lower. Consulting time, and therefore consulting cost, would be lower as well because the closer you stay to standard the larger pool of resources there is available to make or adjust system settings rather than work with custom programs.

SAP Organization Structure and Master Data Harmonization

One other possible project approach is to do the SAP Org Structure harmonization in all of the separate SAP global instances and then agree on the common master data types. At “go-live” you extend all of the existing data in each production instance to begin executing with the new structure and master data types in each production instance. By doing this, the “legacy” data and “legacy” org structures stay in place so that little or no business disruption occurs. A transition period of approximately a year is needed to complete at least one full annual financial close under the new structures and data in the existing production system.

By using this approach you are actually making the transition in two-steps. First you build out the new state in your existing system, then after flushing out and adjusting most of the issues you do a conversion or cutover to a clean system after a financial close. This approach allows for an orderly transition from the old to the new with relatively little business disruption. While the old SAP org structure elements and master data types are being made “obsolete” they are still available for all processing and reference purposes.

Some of the key considerations for this approach involve what to do with custom coding and how to transition the master data. It is impossible to know what custom coding is in place that might be replaced with standard functionality. However some new data types may help resolve the issue of moving off the custom coding in the same system. Eventually the goal would be to upgrade away from the custom coding and into more standard functionality unless there is some clear business justification preventing this.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

How to Execute an SAP Reimplementation

Bill Wood — Mon, 23 Jan 2012 13:03:09 +0000

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:

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.

A reimplementation of a single SAP production instance.
Integrating a landscape with multiple SAP production instances onto a single global instance.
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:

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.”
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?).
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.
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.
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.
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).
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.
In some cases adding on brand new functionality is nearly impossible because of how much your system was “hacked together.”
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.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Why Use the SAP ASAP Methodology?

Bill Wood — Mon, 16 Jan 2012 13:40:49 +0000

ASAP Methodology Background

In the mid 1990’s SAP had gained a significant amount of bad press and publicity around several high profile project disasters that the company knew were completely avoidable. At that time Oracle, Baan, JD Edwards, and PeopleSoft all had sales people making the case that SAP was too expensive, too complicated, and took too long to implement. In response SAP released the ASAP Methodology in the mid-late 90’s (around 1996 or 1997) because of the number of SAP projects that were going over time, over budget, and were at risk. It has been refined, polished, enhanced, and adjusted with SAP’s supported R&D resources and efforts for about 15 years now.

The ASAP implementation methodology has leveraged the PMI (Project Management Institute) best practices around project delivery and the Carnegie Mellon CMMI (Competency Maturity Management Integration) approach for maturing the delivery process. The ASAP methodology also includes a number of ITIL (Information Technology Infrastructure Library) components in the Phase 6 Run and the ValueSAP portions of the methodology. Agile techniques are an option which can be “turned on” if you like.

The toolset includes an implementation “Roadmap” which is a WBS based project template. It has full explanations, templates, tools, resources, checklists, etc. Together with that the original version also included an MS Access, and then an MS SQL Database application for selecting your solution options which would then generate a list of processes, transactions codes, template BPPs, and a full SAP centered Blueprint document, etc.

Today all of that functionality is still available but it is housed in Solution Manager. The ASAP Roadmap is just ONE component of the entire ASAP Methodology. The Roadmap is focused on effective Program or Project Management for accelerated project delivery with high quality results.

My Experiences with the SAP ASAP Methodology

I was originally certified in the ASAP Methodology in 1998 while at Grant Thornton. In that time I have had the privilege of using ASAP on several projects and as the project manager on a few. One consistent result of using the methodology is that projects are delivered and they are usually delivered on time and on budget (although not always).

Every major SAP system integrator claims some methodology and nearly all of them are similar to, or variations of the SAP ASAP Methodology.

I have only ever seen significant problems with ASAP when a system integrator started to use the methodology and then abandoned it part way through the project. At one recent client I used it as the framework to support a LEAN implementation methodology. That LEAN methodology has served as an ongoing framework to significantly accelerate numerous rollouts at probably 25% of the normal implementation cost of other SAP projects. This was driven by the client project manager and facilitated by using the ASAP tools.

Starting with the ASAP Methodology

Even before the first consultant comes on board the ASAP methodology provides templates and resources to cover key project and program management areas such as

communication planning
decision making
risk management
project management master planning
resource planning
steering committee tools
external links to best practice resources for reference (PMI, ITIL, Internal SAP, etc., etc., etc.).

Why ASAP Instead of a System Integrator Methodology?

First, I have nothing against the system integrator methodologies and some are very good with great resources. Unfortunately my experience has been while they have them, and may start with them, they rarely stick to them throughout the project. Since it is their methodology you have little or no insight to cross-check or validate their methodology use. With ASAP it is yours to use as an SAP customer and you have full insight into it and control over its use.

One of the primary reasons for using the SAP ASAP Methodology is like all things SAP there has been a mountain of R&D spend, development, adjustment, and support. Every SAP client (large or small) who uses the ASAP methodology can avoid the “proprietary methodology lock-in” which the system integrators will walk out the door with. Another important reason is you own it as part of the standard Solution Manager offering.

As you probably know Solution Manager is already a required part of your SAP landscape. The SAP Solution Manager portion of the ASAP Methodology can house key items related to scope, configuration, documentation, the implementation roadmap, and all of the key deliverables. As the system integrator rolls off the project you have a centralized repository which is SAP specific for any future employees, support, upgrades, etc. You do NOT get that with a “custom” system integrator methodology which is probably based significantly on SAP’s ASAP Roadmap to begin with. Using an SI methodology you will NOT get the full configuration and development scope monitoring tools which Solution Manager contains either.

The entire ASAP Methodology is part of your application licensing and support you pay for. Why not at least take it for a test drive and see what it can do.

For more information on the SAP ASAP Methodology for SAP customers use your SAP OSS ID and log onto http://service.sap.com/asap .

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP IT Governance, SAP Program Management, SAP PMO Metrics

Bill Wood — Mon, 09 Jan 2012 12:45:35 +0000

: SAP Program Success

SAP Program and SAP Project Management can be tough. In a recent Focus.com expert discussion the issue was raised about who a Project Manager or a Program Manager should be accountable to on business application projects. Should it be the business or IT? To help clarify the accountability I asked a simple question of what deliverables, metrics, and tasks would be required? By knowing what mechanisms the program or project manager(s) would be accountable it would be possible to determine who they should answer to. There was a nearly universal lack of response. In other words, how do you measure performance and how do you help to ensure results if you don’t even know what the individual, group, program, or business endeavor is going to use to measure accountability?

The most frequent response around accountability for program or project managers was a call for ”independence.” So when I raised the issue of project manager or program manager accountability, metrics, performance, and how to ensure project messes are avoided there were no takers. Is it any wonder so many business application projects and programs get into trouble, go over budget and time?

SAP Program and Project Management Office Success

A good Program or Project Management Office provides the resources needed for delivery project participants to be successful. Without this focus the value of an SAP Program or SAP Project Management Office is not realized. The U.S. Department of Energy did a good review of performance and benchmarking for project management. And while this was applied to a government program there is a lot of valuable insight for any SAP project or business application project [FN1].

The U.S. Department of Energy had a committee evaluate success criteria and offered four sets or categories of performance measures to cover the 30 possible discrete measurements of project or program success. Those four sets or categories were [FN1, pg. 1]:

Project-level input / process measures. Assess the resources provided to deliver an individual project and the management of the project against standard procedures.
Project-level output / outcome measures. Assess the cost and schedule variables of an individual project and the degree to which the project achieves the stated objectives.
Program- and department-level input / process measures. Assess the total resources provided for all projects within a program or department and the degree to which program- and department-wide goals for projects and their management are met.
Program- and department-level output / outcome measures. Assess overall project performance and the effectiveness of completed projects in supporting program and department missions.

Without this type of analysis and evaluation your project may be headed for trouble before it even begins. When you start your large business application project what type of deliverables, output, or results do you expect from those who are leading the projects? How will you measure and evaluate their performance? If your evaluation of their performance is focused on how well they support the success of delivery teams, along with how well the projects are delivered (budget, scope, schedule, and quality) then you will be measuring the key project delivery values for success.

That same U.S. Department of Energy study provided guidance on the key components for a successful performance measurement system of program or project managers which can be applied to business software projects like SAP. They noted key components of an effective performance measurement system include [FN1, pg. 7]:

Clearly defined, actionable, and measurable goals that cascade from organizational mission to management and program levels;
Cascading performance measures that can be used to measure how well mission, management, and program goals are being met;
Established baselines from which progress toward the attainment of goals can be measured;
Accurate, repeatable, and verifiable data; and
Feedback systems to support continuous improvement of an organization’s processes, practices, and results.

The Answer for SAP Program and SAP Project Management Results

Over the years I have found the SAP ASAP Methodology helps to ensure SAP Project delivery. The entire methodology is focused on project participant success; budget, time, and scope control; and quality control for project delivery.

My non-cynical assessment for why it is not more widely used is because many SAP Program Managers and SAP Project Managers have not be trained to use these tools (or Solution Manager which contains them). On the other hand there are some SAP Project and Program Managers who have a financial motive that can not be ignored. They do not use the ASAP Methodology because it makes a client less dependent on them. After all, why do you need an expensive program manager to deliver tools, templates, resources, guidance, quality control, and measurement utilities if you have a methodology that already contains all of this with step by step instructions to use it?

==============

[FN1] Measuring Performance and Benchmarking Project Management at the Department of Energy. http://management.energy.gov/documents/performance_measures_final.pdf

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Series on SAP ERP Project Success Factors

Bill Wood — Mon, 19 Dec 2011 12:15:09 +0000

Through the Christmas and New Year Holidays I will be taking a short break and offer you these compiled sets of posts related to a particular topic. This week it is all about SAP project success criteria. So, without making much more of a fuss here are a number of key posts on SAP project success criteria.

==================

The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
http://www.r3now.com/the-top-5-erp-success-factors-by-project-stage-from-22-critical-success-factors

SAP Implementation Partner or Company Selection Criteria
http://www.r3now.com/sap-implementation-partner-or-company-selection-criteria

SAP Success Factors for Vendor Selection – Responsibility Matrix 1
http://www.r3now.com/sap-success-factors-for-vender-selection-responsibility-matrix-1

SAP Success Factors for Vender Selection – Responsibility Matrix 2
http://www.r3now.com/sap-success-factors-for-vender-selection-responsibility-matrix-2

SAP System Vendor Project Success Criteria 1
http://www.r3now.com/sap-system-vendor-project-success-criteria-factors1

SAP System Vendor Project Success Criteria & Factors 2
http://www.r3now.com/sap-system-vendor-project-success-criteria-factors2

SAP System Vendor Project Success Criteria & Factors 3
http://www.r3now.com/sap-system-vendor-project-success-criteria-factors3

SAP System Vendor Project Success Criteria & Factors 4
http://www.r3now.com/sap-system-vendor-project-success-criteria-factors4

SAP System Vendor Project Success Criteria & Factors 5
http://www.r3now.com/sap-system-vendor-project-success-criteria-factors5

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

An SAP ABAP Innovation Revolution Beyond HANA

Bill Wood — Mon, 12 Dec 2011 13:47:45 +0000

ABAP Development Revolution

Some time back I wrote about Opportunities for INNOVATION SAP, HELLO? At the time I wasn’t really expecting a lot and I’m guessing I didn’t have a lot of influence but I do find it coincidental that many of the suggestions I offered have been adopted. Some of them, like the switched framework to improve order management processing is included in ECC 6.0 EP4.

So, one thing that I have been chewing on for a long time is how to dramatically improve ABAP development and overall application enhancements. My own requirements were to find a way to make ABAP coding simpler, improve code quality, provide better overall system performance, and make it easier to troubleshoot. Tall order I know. Impossible? No!

Welcome to the “Big Data Revolution”

This post is more about a technical issue which SAP can “easily” address that would completely revolutionize its own internal development as well as external customer development.

The New SAP Development Revolution

I’m not an SAP ABAP coder but over the years I’ve had enough exposure to it to see some great tools, resources and improvements. This development effort has been mostly on the usage side of the existing syntax.

What if there was a way to revolutionize the way ABAP is coded that is 100% compatible with current syntax ?
What if it dramatically improved coding quality and solution development?
What if it improved the performance and consistency of customized ABAP solutions?
What if it simplified the entire coding process AND made troubleshooting easier?
What if it opened up a whole new world for coders to develop dramatically improved solutions?

You say that sounds crazy? Not only is it possible it would propel SAP’s place in the entire business application space to new levels.

Where Did This Crazy Idea Come From? And WHAT IS IT?

After many years working in SD (along with other modules) I had a client who needed help creating a new “smart” trade promotion execution solution. The solution had to do a LOT of things no standard SAP process handles. It needed to dynamically determine complex offers, with discounts, free goods, limits, caps, quotas, perform dynamic best price processing, provide loyalty points, etc. –, all while dynamically evaluating the customer segment and strata for offer eligibility. The solution had to be done across a large population of order items, with multiple promotions based on the mix of products and the number of discounts or promotions that had already been given to a customer over time. The mix of products or offers could bundle multiple free goods, multiple offer discounts, or other special items, in a many to many relationship, based on the customer purchase and purchase history. And performance HAD to be good because of the huge order volume.

The client had been asking for someone to deliver this for some time. A previous system integrator who did their upgrade couldn’t do it. I ended up spending 6 months working on a new custom coded ABAP “mini-module” in SAP that allowed them to achieve their goals by using mostly master data.

That process taught me more about ABAP programming and SAP coding than I ever anticipated. As I went through this process I was amazed at one simple thing that was completely lacking from all of this coding effort –, the amount of “VIRTUAL” SQL syntax for internal data processing in the form of loop, sort, read table (with key), append, move, move corresponding, index, etc.

Why not develop the syntax to handle all of this in the background through “virtual” select statements? Create a new “iSelect” syntax which performs all of these functions that can be exploded.

SAP already uses internal tables in memory for processing data during the transaction stream. By creating a new “iSelect” syntax much of this coding, looping, moving, etc., could be masked by fairly common SQL type commands. Since this would be compiled syntax the performance would likely be better and the quality would be FAR better while needing fewer lines of code to accomplish the same thing. For simplicity I will call it “internal SQL” or, iSQL.

This would be the perfect complement to SAP’s HANA in memory processing, and would help with reporting extractor and programming development of all kinds.

This type of iSQL could be developed to allow inner or outer joins on internal tables, external tables, or any combination of them. The normal SQL statements like Select Sum, Select Distinct, etc., etc., etc., could be employed throughout the entire ABAP processing stream. With internal tables in memory as well as the tables read from the database. Still more interesting would be the ability to “explode the code” underneath this new iSQL syntax. When finer detailed control, processing, or calculations are needed, within or across joins, the underlying loop, sort, append, etc., could be exploded out and adjusted to fit the specific need. This would speed up development efforts by being able to quickly rough-out a data processing framework and then explode the code to make more detailed adjustments.

By focusing on syntax that is like SQL for the internal loops, sorts, reads, sums, append to table, move, etc., the coding complexity is reduced WHILE also providing more flexibility and options. SAP would have greater control over the development of the internal / external table processing standards and programming knowledge around actual data processing would improve. This would be the perfect complement to SAP’s HANA in memory processing.

It would allow for faster, more reliable coding efforts with a higher performance result. Small performance tweaks or changes to the underlying compiled iSQL statements, along with that ability to explode the underlying code would create a revolution in the ability to more quickly and consistently deliver SAP solutions.

What is most important of all is this could be rolled out piecemeal and stay 100% backward compatible with no negative downstream effects. As new iSQL syntax is developed the original coding standards could remain in place without change. It would just add an additional set of power processing options. Think about all of the areas this would radically affect, custom coding, data conversion, SOA development, report development, function module creation, you name it. This could create HUGE customer benefits for outstanding development.

I’m tired of crappy, poor performance, system choking code from poor development, aren’t you? Come on SAP, YOU CAN DO THIS!!!!

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

7 Tips for Effective Client Management of SAP Consultants

Bill Wood — Mon, 05 Dec 2011 12:45:40 +0000

Manage SAP Consultants

Over the years the most successful SAP projects I have participated in had strong client side leaders. They had some knowledge and understanding of how to deliver large, complex, or difficult projects. Not just SAP projects but large complex undertakings. Their ability to deliver projects came from their ability to manage, direct, and engage with project participants. They took the initiative to directly manage their own projects.

Many of these leaders had something else in common, they understood you can become overly reliant on consultants to deliver a project –, it creates an artificial sense of security.

One project and leader in particular stands out from my past because of the attitude about SAP project delivery. That project’s senior leader used a phrase about consultants I found a little insulting but have since learned to appreciate. He had a “rented skills” attitude about consultants and frequently referred to us in that way. Along with that attitude he and the senior leadership of the company chose very strong leaders from within the company ranks to manage each module or key area of the project. And by strong leaders I mean REALLY strong leaders. During the course of the project a number of consultants were replaced when they did not perform up to the company’s expectations. That project was probably one of the best delivered projects I have ever seen:

It had one of the largest SAP scope and functionality footprints.
That project’s first phase replaced nearly 60 homegrown legacy systems.
It was delivered ON TIME and WITHIN BUDGET.
It met every business requirement.
It was delivered across international company codes and business units (including foreign trade).
And for similar sized companies, with similar scope, similar time frames, etc., it was delivered for probably 10 – 20% of similar projects.

That project was very different because the level of automation and how smooth the go-live went, and even the post-production support issues were far fewer than any other implementation I had participated in.

I participated in this implementation’s post production support as the SD lead and to help with reporting for about 6 months after we went live. They had slightly more support issues than many companies have with “stable” SAP implementations. This senior leader went on to become CTO and nearly all of the company’s leaders involved in that SAP project went on to senior level leadership positions.

How Clients Can Effectively Manage SAP Consultants to Deliver Results

The background I just provided illustrates one of the most important factors necessary for successful SAP project delivery. The Ivey Journal published by Harvard Press about “Leading Consultants to Exceed Expectations” (PDF file) went into detail on this issue. The key is in aggressive client management of SAP projects for companies that want meaningful results and value.

For me this involves a few critical components:

Develop a project or team set of values and expectations for project delivery. The expectations should be focused on action and execution.
Provide a training course to client participants on the latest SAP ASAP methodology. It can be made available through Solution Manager or as a stand-alone HTML download from the SAP Service Marketplace.
Define clear boundaries, tasks, and roles for all project participants. No one should have to try to figure out what they are supposed to be doing.
Every client project participant should be trained in how to manage and work with consultants. Use RACI charts to help manage consultants.
Every client project participant should be spelling out the specific tasks, assignments, and expected completion of deliverable for each project participant.
Each person on the project, whether contractor or employee, should have clearly defined deliverables, tasks, and criteria for success.
The client project participants should capture and regularly discuss lessons learned on dealing with consultants, including challenges and soliciting ideas on managing them.

Client and consulting leaders should accept responsibility for the delivery and execution of those they are responsible for. Be on guard for excuses, deflection, and blame-shifting. At times these are common consulting tactics to hide a skill, talent, or capability gap.

One key thing to consider is that any decent SAP consultant who has managed to deliver SAP project results can be difficult to manage at times. Because of their type “A” personality tendencies they need input and awareness of anything within their domain of influence. To manage high performing consultants the use of a RACI chart cannot be underestimated. Because of these tendencies project managers must activity work to solicit their input and feedback, and well as keeping them in the loop on what is happening in the project. If you fail to do this you are setting yourself up for trouble and unnecessary conflict. This is why a RACI chart is a useful tool on an SAP project.

For an overview of the key SAP project success factors, including allocating responsibility, please see this table which provides an overview of success factors:

Critical Vendor Management Success Factors for SAP Project Success

For a detailed explanation of each of these success criteria you may wish to review the series which analyzed them from the consulting selection point of view:

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

More SAP Project Leadership Tips for Managing Conflict

Bill Wood — Mon, 28 Nov 2011 14:15:19 +0000

Managing SAP Project Conflict

If you are determined to gain and then maintain SAP project momentum you will see stress. Part of the requirement for momentum includes asking people to reach for stretch goals which can challenge (and deepen) their capabilities but also causes tension and even conflict.

One author says conflict is “a situation of competition in which the parties are aware of the incompatibility of potential future positions and in which each party wishes to occupy a position which is incompatible with the wishes of the other.” [FN1]

In plain English, conflict happens when there are competing expectations and priorities. Put another way, I want what I want and you want what you want and the level of our conflict depends on just how much each of us wants “it”.

Without hands on, active SAP project management it is likely that stress and conflict will destroy your SAP project momentum. Active SAP project management is not about micromanaging people or their activities but rather finding the right balance around task execution and delivery while working through the stress that will arise. As a project manager part of your key responsibility is to work through conflict to maintain momentum. At its most basic project SAP project management is like babysitting adults who at times act like squabbling children (and I’ve been guilty of childish squabbling as well at times!).

Key Phases of SAP Project Stress Which Can Create Conflict

In relation to physical and life stress Canadian Physician Hans Selye (1907 – 1982) proposed 3 stages of stress in his 1956 book “The Stress of Life”:

Alarm
Resistance
Exhaustion

On an SAP project the alarm or panic stage occurs when you attempt to create a rapid project delivery pace. The resistance stage occurs when the alarm does not slow down or stop the momentum that is gaining. Exhaustion or “checking out” can occur when the stresses and pressures of an overly aggressive timeline continue beyond what the project participants are able or willing to deliver. A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

The key to good SAP project management is to maintain a sense of urgency that is strong enough to keep momentum high but no so urgent or so stressful that it causes people to burn out or check out.

There is a healthy level of tension which is needed to keep momentum going but knowing where that line is requires a project manager to be directly engaged with the project participants. Even though it is critical to gain and then maintain momentum at times you also have to know when to ease up to allow the stress level to moderate.

It is equally important for a project manager to know whether the alarm and resistance are from unskilled project participants who are trying to hide their lack of experience, or from unrealistic demands, or from the project as a whole.

At First Most People Try to Deal With SAP Project Stress in a Productive Manner

Regardless of the reason for the stress, and ultimately what the conflict is, most people do attempt to mitigate the initial source of the stress. The research shows they may:

apply extra effort to compensate for the greater demands,
they may attempt to overcome the stress by fixating on the task(s) which create the stress, or,
they may become anxious, worry, and then avoid the tasks.

If a project manager is skilled and recognizes these signs they can quickly intervene and help to alleviate the source of the stress. Although it is critical for momentum to keep a forward looking perspective throughout the project there are times it is more productive to pause, reflect, and allow stress levels to lower. When you see tension and stress building to an unhealthy level it may be time for a special recognition of how much progress has been gained to help people regain a sense of perspective and give them a chance to “take a breath.”

A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

Knowing when to back off the gas and recognize accomplishments and when to press the gas and push ahead is the most difficult skill for any project manager to develop. It is like a professional race car driver who must know when to step on the gas, when to let off, when to apply the brakes, and when to step back on the throttle. A project manager who is able to perform that balancing act demonstrates their experience and their people skills. This requires direct engagement with the project participants on a day to day basis.

This type of engagement by the SAP project manager needs to be in the project participants’ work environments, not just in planned meetings where people may not be as candid or forthright. That direct engagement requires the project manager to serve as an active umpire, counselor, decision-maker, expediter, and all around gopher to help coordinate many of the integration activities.

A Good SAP project manager GENUINELY UNDERSTANDS that their success depends on every other project participant’s success and will directly engage in activities which help promote the success of project participants. Sometimes this means giving some project participants the opportunity to be successful on a different project :)

As a final thought, an SAP project manager who needs a separate “integration manager” should be more carefully considered. It may be necessary but do you really need a Microsoft Project administrator or a meeting monitor or do you need a manager for your project? Needing an ”integraton manager” may be a way to avoid the day to day involvement that is critical for SAP project success.

============

[FN1] Capozzoli TK. Conflict resolution-a key ingredient in successful teams. Supervision (60:11), 1999, pp 14-16

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

5 More Leadership Tips for Successful SAP Project Management

Bill Wood — Mon, 21 Nov 2011 13:29:36 +0000

Of the previous 5 tips I reviewed last week the first 3 are all related to project momentum. Let’s look at a key to maintaining that momentum while also reducing the impediments.

One key to maintaining momentum requires an SAP project manager who is fully integrated in the day to day project activities. That hands on approach to project management is crucial for overall project success. Unfortunately there aren’t very many SAP project or program managers who are engaged in the day to day project execution activities.

“An SAP project manager or SAP program manager must focus aggressively on removing obstacles, encouraging success, and fighting against those things that would slow momentum” (SAP Project Manager – SAP Program Manager, Lessons from the Trenches):

Develop project deliverable and task tracking tools that are simple, easy to understand, and forward looking. If a status tracking tool has more than 10 columns for a deliverable or particular task it is probably getting too involved, if it has over 15 columns (not task rows but details, status, and note columns) it will probably kill any momentum.
Set, then communicate, then reinforce an expectation that anything slowing down project momentum must be raised by project members immediately.
Create a formalized but simple decision escalation process. If any project execution process is overly complicated it will reduce momentum or not be used. This is especially true for decision making.
All project activities MUST focus on execution because it is execution and action that maintain momentum.
Continue to communicate the timeline, and use presentations for all key upcoming project activities–, have templates, deliverables, and instructions in plenty of time for project members to transition to the new tasks (a RACI chart can help here).

A Key Psychological Affect on SAP Project Momentum

Some time back I read an interesting study by a researcher about high performance teams that consistently met “stretch” goals. The key difference between consistently high performing teams was in how they approached their assignments. High performance teams consistently looked ahead at what needed to be done next to achieve their goals. One of the interesting discoveries was when these same high performers were allowed to focus on their achievements and accomplishments their performance suffered. They discovered when people stop to reflect on how much they have achieved and how far they have come they tend to become more satisfied where they are and naturally slow down. That sense of achievement causes them to pause and become more content and therefore their forward looking productivity suffers. However, as we will explore next week, there are times this is an effective project strategy to reduce tension and stress.

We see this all the time in the high performance area of professional sports. How many times have you seen a professional team start out strong and gain a lot of ground on their competitors only to ease up and then lose that ground by the end of the game. Sometimes these large gains are even erased and the other team wins! The team that started strong started to look at where they were and relaxed a bit while their opponents, who were behind, started to look ahead and focused on how to turn things around. The coaches and players of the team that was behind started looking ahead and planning for how to systematically win the game.

You SHOULD celebrate SAP project milestones and achievements but ONLY as a passing measurement point. Part of that celebration or recognition of a milestone must be about the passing of that mark and looking forward to, or celebrating, how the next upcoming milestone or major achievement will be met. You can also use these recognition events to relieve project stress and pressure at the appropriate times.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP Change Management Strategies and Knowledge Transfer [Digg]

Digg — Thu, 24 Jun 2010 08:36:16 PDT

Continuing change management strategies and ongoing knowledge transfer activities are critical after an SAP go live for business transformation. \r\n\r\nBusiness transformation,change management strategies,competitive pressures,knowledge transfer,learning organization,learning organizations,process improvements,SAP

SAP & ERP Consulting from the Customer Point of View

Key Design Considerations for SAP Reimplementation

SAP System of Record

SAP Organization Structure

Related Posts:

SAP Reimplementation Method Key Considerations

SAP Cloned Production System “Re”-Implementations

The Optimum Solution is a Phased SAP Global Instance Harmonization

SAP Organization Structure and Master Data Harmonization

Related Posts:

How to Execute an SAP Reimplementation

Related Posts:

Why Use the SAP ASAP Methodology?

ASAP Methodology Background

My Experiences with the SAP ASAP Methodology

Starting with the ASAP Methodology

Why ASAP Instead of a System Integrator Methodology?

Related Posts:

SAP IT Governance, SAP Program Management, SAP PMO Metrics

SAP Program and Project Management Office Success

The Answer for SAP Program and SAP Project Management Results

Related Posts:

Series on SAP ERP Project Success Factors

Related Posts:

An SAP ABAP Innovation Revolution Beyond HANA

The New SAP Development Revolution

Where Did This Crazy Idea Come From? And WHAT IS IT?

Related Posts:

7 Tips for Effective Client Management of SAP Consultants

Related Posts:

More SAP Project Leadership Tips for Managing Conflict

Key Phases of SAP Project Stress Which Can Create Conflict

At First Most People Try to Deal With SAP Project Stress in a Productive Manner

Related Posts:

5 More Leadership Tips for Successful SAP Project Management

A Key Psychological Affect on SAP Project Momentum

Related Posts:

SAP Change Management Strategies and Knowledge Transfer [Digg]