Posts Tagged ‘Consultants’

Unrealistic Demands


Image via Wikipedia

Today I received a couple of job proposals and while reading them I had to crinch about the ignorance and lack of knowledge of recruiters and HR departments when posting positions:

One position read:

1) Senior SAP FI Functional Consultant (AR, AP, Banking)
Ideal Candidate needs to have:
• At least 7 years of SAP FI implementation experience in AR, AP and Banking areas on ECC 6.0.
The problem here is that SAP ECC6.0 was not released until 2005/2006.

Release to Customer: Available 24.10.2005
Default Release: Available 06.06.2006

This makes it in my eyes impossible for somebody to have 7 years of experience in ECC6.0. Even if somebody would have gotten hold of the very first release on 24.Oct. 2005, this person would have less than 6 years of experience on this release.

I recall my first upgrade from 4.6c to ECC6.0 did not happen until early 2007.

No further comment on this. If anybody has similar experiences about recruiters or organizations having unrealistic demands I would like to hear about it.

Please comment below.

Thank you.


SAP Implementation Challenges / Part 2

by Oliver Schmid

Part 2: Potential Resource and Management Problems during an SAP Implementation

The following categories are all part of the overall project resources:

  • Infrastructure, which entails: Hardware and software components required to run SAP
  • Project Teams: The resource “Project Teams”, which may consist of internal and external team members who are participating in the SAP implementation project.
  • Support Personnel: the employees needed to support SAP during the implementation and after the going-live phase.

Internal resources are usually the so-called key-users that participate in the SAP implementation. A key-user is a employee that is intimately familiar with all business processes and requirements as it pertains to their job function and/or department. Problems may arise if such key-user is selected on seniority or workload within a department rather than on their individual knowledge and familiarity of the various business processes. Since these key-users know the internal business processes as it relates to the current infrastructure but have no or only very little SAP experience, it is imperative that these key-user learn the SAP functionality before start of the project.

Keep in mind that these resources are responsible of how a company transacts business in the future. These key-users must learn the functionality and configuration possibilities in enough detail in order to make intelligent implementation decisions. Key-users usually also train employees and act as first level support within their area of expertise.

There for it is important that the project team is staffed with the right employees.

Many companies today feel that they do not have the internal full-time resources available to participate in the system implementation. Companies that are already operating on a bare minimum staffing, due to downsizing or rightsizing, think that there are just not enough people left within a department to support the day-to-day business and support a SAP rollout. Here companies have to become creative. It could mean retrain some of the staff that is not actively participating in the rollout project to take over some of the functions a key-user would not be able to fulfill during the rollout project participation.

Sometimes it seems those internal resources, that seem to be able to balance the act between their day-to-day work and the SAP rollout project responsibilities will eventually burn themselves out.

This could be also be a point where careful budget planning can come in handy. Options could include retraining existing staff to take on the responsibilities of the key-users and additional temporary staff could be hired to do some low level work. Using interns to replace key-users could be another option.

External resources are usually skilled consultants that participated already in multiple SAP implementation projects and have the technical knowledge on how to customize the SAP System to the specific requirements. Skilled SAP consultants today come at a premium price. There for the proper management of SAP resources is even more critical in order to receive the most “bang for your buck”.

External Resource items to consider should be:

  • How many consultants are needed?
  • What is their implementation experience?
  • What is their industry experience?
  • At what time during the various phases of the project, are which resources needed?

Another important factor to consider would be not trying to do all at once, but rather in Phases. Many projects have failed or were bogged down by trying to do too much at once. Often, organizations are so used to, with what they have currently in place that they oversee the fact that some of the current functionality has grown over time and is not a drop-dead requirement to operate the business.

It is imperative to have a fact-finding session, to determine: “What would be the minimum functionality that is needed to operate the business and what could be done in a second or third phase?”

Change Management experts have also determined that organizations change more effectively through multiple cycles of learning (1).

The biggest problem I have so far encountered during any SAP implementation was the lack of management support. It is imperative that a project of this multitude has a sponsor that some sort of influence within the organization. This should usually be an executive team member that has an interest in the success of the project.

Another important governance of any major SAP implementation is the Executive Steering Board. The steering board will have the final saying if significant changes or existing business processes are required or if business impacting process additions have to be implemented.

The steering board or project management board usually consists of high-level executives, representatives of the systems integrator, a quality assurance representative and a change management representative. (2)

For the SAP Implementation to be a success management must understand, support, and eventually direct the new business processes under SAP.

Part 1: SAP Implementation Challenges / Part 1

Oliver Schmid

(1) SAP R/3 Implementation Guide: A Managers Guide to Understanding SAP

(2)     Keane Whitepapers: Getting it right the first time: 9 Best-Practice Guidelines for a Successful SAP Implementation

SAP Implementation Challenges / Part 1

Typical Implementation Problems:

Enterprise Packages or ERP Solutions have come a long way and progressed over the years. Today it is possible to keep track of most transactions in real-time across an entire enterprise.

SAP is a software package that is highly configurable and was developed building on Best Business Practices. Implementing SAP will most likely alter existing business processes for the better, as long as change is accepted. One of the most difficult issues during an SAP implementation is most often the reluctance to change. People become comfortable with the way things have always been done. To put the necessary changes in place a well laid out plan must be established.

Any ERP implementation has its challenges, which range from financial over functional to technical issues. During any implementation, problems can appear at all levels of the project. These can be business problems, financial problems, ERP systems functionality issues as well as conflicts between project team members. Combined these problems can make the management of the project a true nightmare.  There for it is important to deal with all problems in a timely manner. Procrastination may lead to a accumulation of problems, which can make resolution almost impossible without any delays in the overall project timeframe.

Anyone who has participated in multiple systems implementations knows that there is no such thing as a typical implementation. Every implementation is different. Every implementation has its unique risks and challenges.

It is important to have a defined project scope. The project scope is necessary to keep the entire project focused on delivering the implementation with its agreed upon functionality.  Usually projects start with a scope definition based on business functionality. Organizations usually put together a document specifying its requirements based on its current business model. This document is used to identify the proper ERP Solution. After selecting the ERP Solution of its choice this document is then used as project scope, meaning the attempt is made to make the ERP Solution to fit the existing business model. Again, here comes the reluctance to change in place.

For any SAP Project, it is recommended and better to define the scope by SAP functionality. SAP has been developed using standard business rules. A SAP implementation may require a change in current business rules in order to adapt easier to SAP and be able to stay as close as possible to the standard. Staying as close as possible to the standard will allow also for easier compatibility with future SAP releases and make any upgrade easier and less costly. Staying with the standard and following SAP project scope will help also to avoid ambiguity within the project team in regards to what SAP functionality is within the scope and what functionality is out of scope.

It may be difficult to manage the scope. During an implementation the implementation team will discover and learn more about the SAP functionality and the business itself, which may make it necessary to change the project scope periodically.

Part 2: Resource & Management Problems .

Oliver Schmid