What Makes a Great SAP Project Manager?

A project manager’s job is to deliver a defined scope on time and on budget.  This expectation comes from the overall project leadership, the business community and the IT organization.  To do this an SAP project manager needs to know:

  • The project goals and success criteria
  • The tasks to be performed
  • The dependencies between the tasks

  • The resources and skills needed

  • The key milestones and critical deliverables

Coordination, execution, review and sign-off throughout the project lifecycle requires marshaling different resource types at different times including business team members, functional consultants, ABAP developers, PI/XI developers, the Basis team, technical infrastructure, network operations, production support, training teams, etc.  A great project manager needs to be comfortable and confident interacting with different audiences, communicating in their language and using terms and jargon they understand.  A great project manager has a rolling horizon always looking a week, a month, a quarter or more into the future anticipating needs and planning ahead.  A great project manager lives with the belief that fire prevention is far more desirable than firefighting.

A great project manager monitors critical tasks and recognizes when to be flexible and when to dig in. There is constant negotiation, evaluation of information to separate the important from the inconsequential, and refinements to keep the project on track.  A great project manager knows to cultivate team member engagement, motivation and drive and maintain a common vision of the end goal.

DataXstream project managers understand all of this.  They live it every day.

Upgrading your SAP System – Pitfalls and Processes for Success

Why Upgrade?

What compels a firm running multiple versions and multiple products of SAP to upgrade its ERP and other usage types? The (not always) obvious reason is the need for new functionality, which can better support company business needs and help them thrive in an ever growing competitive landscape. Basically, they want their business to run better than other businesses in their market. So a brief note on the release strategy for SAP applications, which follow a “5-1-2” maintenance concept: “5″ years of mainstream maintenance; “1″ year of extended maintenance at an additional two percent of the maintenance fee; and finally, “2″ years extended maintenance at an additional four percent fee. Not cheap, but it may be cheaper than a big upgrade project. After that, if you still don’t want to let go of the SAP release, there is always customer-specific maintenance, which is expensive.

I am sure that most of the decision makers are not aware of this information, and that is why I’m  writing this post.  SAP customers need to know of the additional investment they would have to make to keep their SAP system, running status quo.  I would encourage you, and your bean counters, to do the math on considering your SAP installations. After that, I am sure you would be compelled to focus on the upgrade (if not now, when?).

New Functionality

The main reason for upgrading has almost always been the additional functionality.  There are other reasons as well, like instance consolidation, virtualization, and requirements based on hardware, software and O/S.  Every SAP release brings new features, challenges and opportunities.  The need to upgrade is mostly driven by business needs, which in turn require new functionality in your SAP environments.  This empowers your company by transforming your processes and moving your company to higher levels of efficiency, richer reporting with new and improved analytic tools like BIA and HANA, and ability to make timely and informed business decisions.  The choice must be made whether to implement and develop the new functionality or perform an upgrade. This is not always an easy evaluation and the amount of customizing you do will certainly drive this decision.  This is the so-called “solution gap” and you have to ask, is the solution gap large enough to justify the SAP release upgrade?  And since SAP upgrades are time consuming and usually complex, is it worth investing time, money and resources to address this solution gap with an upgrade?

Yesterday’s Technology

SAP systems need to be constantly customized and enhanced in order to support evolving business needs. The time will come when the installed instances will no longer be able to suit your needs.  Staying on the same release is unsustainable from an infrastructure point of view as you will be required to stay on older hardware, software, and O/S.  If you have systems with many external touch points, it becomes more difficult over time to keep these working, especially if you are running much older SAP software. [Read more...]

Lessons Learned for Decision Makers and Leads from a Successful SAP Retail Project Part 2 – Client Resources

My first post of the SAP Retail Lessons Learned series, I provided some background information on the SAP Retail implementation project that will be used as the primary reference for the lessons learned. I also listed a few over-arching themes for the entire series as well as major Lessons Learned categories that will be featured in upcoming posts.

In continuing my series of lessons learned with SAP Retail I would like to cover the topic of Client Resources and Planning. Again, in general many of these lesson I have learned could be applied to any project and I can easily draw parallels from other SAP industry solution implementations that I have led in the past. I will do my best to highlight where I think there are specific retail differences.

There Are Never Enough Client Resources

This is the case on almost any large-scale project, not just SAP projects. It impacts smaller organizations and it impacts retail businesses more because they tend to run leaner IT organizations. So you might be saying to yourself, “big deal; what project not funded by the government doesn’t have enough resources?” This one point however might be the most important one I make in this series.

[Read more...]

Lessons Learned for Decision Makers and Leads from a Successful SAP Retail Project

I have spent the last 2 years working on an SAP Retail implementation.  An SAP Retail project is the last place I could have ever imagined myself working.  I have always been drawn more to SAP manufacturing, distribution, and A&D projects.  Being a manufacturing engineer by trade, I am always a little more comfortable with a manufacturing line or warehouse near by.  Even the facility that we ran the SAP project out of had a manufacturing line in it and a warehouse, so it helped to ease my inner engineer.  It also broke my 12 year streak of not having a project in the state I live in.

I have been working with SAP for over 15 years.  This was my first SAP Retail project and once again SAP has proved to me that it can be successfully leveraged and become a competitive advantage for those companies that implement it.  Each time I start a new project in a new industry I think about the vast differences in how the new company will need to leverage SAP and the challenges that unique business will create for the SAP application.  Time and time again a reasonable solution path is achieved and SAP becomes a solid foundation from which the business operates.  The diversity of my own personal experience working with successful SAP customers demonstrates this point.  There are not a lot of similarities in how A Flooring Retailer, Rocket Manufacturer, Pharmaceutical Manufacturer operate, yet they are all very successful at leveraging SAP.

[Read more...]

It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 3.

In my final post on this topic, I will discuss some of the techniques that I use to “discover” information about customizations in an SAP system, even in the absence of any documentation.  The information available to be discovered may include such details as the object name, object type, user name of the person who made the last modification, date and time of the last modification, usage statistics, where-used, and for code-based objects, even the versions and their code differences.

[Read more...]

Discussing SAP SOLMAN Service Desk Integration Scenarios

When you purchase SAP ERP, you get SAP Solution Manager (SOLMAN) as part of the deal – ostensibly for free (although it is really included in the purchase price).  SOLMAN provides a wealth of functionality to help manage the technical environment as well as project processes like testing.

Service Desk functionality is delivered as part of SOLMAN for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes, which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management. [Read more...]

SAP Go-Live Lessons Learned

In real estate the key factors in making the sale are location, location and location.  In an SAP project I’m coming round to believing that success requires testing, testing and testing.

A Short Selective Retrospective on Key Constituencies

All project events and project success stem from testing and testing well.  I’ve written about various types of testing before and how that can lead to some confusion because of issues with definitions.  Here I want to discuss some areas where testing really can make or break a project and ideas for how to minimize the chances of things turning out badly. [Read more...]

Integrate SAP Service Desk with a Third-Party Service Desk

When companies implement SAP, Solution Manager (Solman) is also included in the installation.  Companies need to make a conscious decision of what they plan to use from Solman.  One of the features in Solman is the Service Desk ticketing system.

SAP service desk is usually getting introduced in an environment in where an existing Third-party Service Desk is already in use.  Because of this, companies need to make a decision on how they will integrate SAP Service Desk with their existing Third-party Service Desk.

In this blog, I will describe Service Desk integration scenarios and DataXstream’s involvement in the Service Desk integration space.

[Read more...]

Lumber Liquidators’ SAP VMware Virtualization Case Study

Going Virtual: How Lumber Liquidators Optimized Its IT Investments and Lightened the Demand on Its IT Organization

The April 2011 issue of SAP insiderPROFILES magazine will feature an editorial on the virtualization of Lumber Liquidators’ SAP implementation. The piece takes you inside the thought process of Lumber Liquidators’ IT team as they recount the factors that led them towards virtualization, the selection of DataXstream as their implementation partner, and how they feel today about about the decisions they made a year ago during the virtualization process.

SAP Mid-Month Go-Live: Got the T-shirt

Conventional wisdom says you don’t go-live with SAP financials in the middle of the month (strictly speaking I should say the middle of the accounting period, but I’ll say month as a generic term for the posting period).  I recently went through a mid-month SAP financials and logistics go-live and so far it has been a success.

Initially the project team had the expected you-can’t-do-that reaction when the idea of a mid-month go-live was suggested.  We took three main steps to determine whether or not we were crazy or had a viable go-live option:

  1. We asked SAP.  As one of the main participants on the project we got them to do an internal review with some platinum consultants with the objective of telling us why we could not go-live mid-month.
  2. We asked our project team, both client and consulting resources.  Again, the goal was to tell us why we couldn’t do it.
  3. We Googled like maniacs to find something to support and justify the conventional wisdom.  We failed to find anything substantial that would deter us.

Armed with the conviction that there was no reason we couldn’t go-live mid-month we set about defining the details of how we would pull it off.

[Read more...]