Blogs

There is no such thing as a 'plain vanilla' SAP HR implementation. When customers start their SAP implementations it's common to hear project managers and sponsors say that this will be a 'plain vanilla' implementation. Customizations and programming will be kept to a minimum, and modifications will be strictly forbidden. Those are fine intentions, but back in the real world: there is no such thing as a 'plain vanilla' SAP HR implementation.

Why can't we have plain vanilla SAP HR implementations? Because HR policies and processes are implemented differently at each customer – for good, valid business reasons. Companies vary in their recruiting, training, and hiring processes; they have different benefit plans and policies; they have special compensation schemes. Yes, much of all this is the same from one customer to another – there is a base of common policies and practices; however, the remaining differences require thought (i.e. analysis and design) to implement into SAP HR – or any other system.

A more realistic goal for SAP HR implementations is to implement their processes and policies into the standard framework provided by SAP. The system has a flexible and functional framework for accommodating a wide range of customer requirements. Companies run into implementation and maintenance issues when they go outside that framework. Knowing that framework is the job of SAP Education (who will train your company's staff) and whichever implementation consulting team you choose. Though you won't end up with vanilla, you will get your company's flavor in a good SAP HR implementation.

If you're like most companies using SAP HR, by now you've invested millions of $ in licensing, support, maintenance and enhancements. SAP HR now provides functionality for pretty much every HR function, from recruitment to payroll, though most companies haven't implemented all of it. You've established a support organization that knows how to configure SAP HR and accomplish most of your ABAP and Portal development.

So let's assume you want to implement something new now - Recruitment, Compensation Management, Workforce Analytics, etc. The HR organization likes the user interface and breadth of functionality in some 'best of breed' software package that is not SAP. The equivalent SAP functionality meets 80% or 90% of HR's requirements and it doesn't have as good of a user interface. Which way do you go? License new software, build interfaces and integration from it to SAP HR, install new infrastructure (hardware, training support staff, etc); or use the SAP HR software you already have, spend some development effort to bridge that 10% to 20% functionality gap, and do some things to make it look pretty? How formal do you get in your cost/benefit or ROI analysis?

Some companies have a policy that if the functionality is in SAP HR, they use it. If the functionality doesn't quite meet their needs, they develop enhancements or bolt-ons to fill the need - but it is clear that you better have a really good reason not to use SAP HR. At the other end of the spectrum, SAP HR is simply one piece of software to achieve some functional needs - it does the HR administration, for example, and other software modules are used as needed for specific purposes. The HRIS landscape is a collection of best-of-breed systems that are interfaced and integrated to achieve the HRIS function.

So which way is the best one? They can both work fine! Though my preference is to use as much of the SAP HR software as possible, either method can work if done correctly, with planning, purpose, and discipline. If either approach is done haphazardly, well, you get some haphazard results. The important thing is to do it well - the nuts and bolts of determining business needs, defining requirements, implementing them in the software, and change management both for process-users and the HR/IT staff.

In a previous blog post I wrote about the two most important success factors for SAP projects: upper management support for the project, and the quality of the people on the project teams. It's sort of odd, but I've found over the years that project managers often have a hard time sorting through consultant applications to find the right ones to bring on the project. Here are a few things I recommend to help make sure you get the best qualified consultants:

1. Try to avoid hiring consultants who are fairly new on the part of the system you need help with. Sure, every consultant is new at some point, and they have to learn not only by training but also experience. But, you don't have to be the one they get their experience from. Look for experience not only with the technical system but also with business processes and business terms; for example: if your Time/Payroll candidate doesn't know what FLSA is and how it affects you, it might be best to keep looking.
2. Just about every consulting position is important. It used to be that the least experienced consultants would get assigned to the Personnel Admin (PA) or Organization Management (OM) modules, since those modules are widely viewed as simpler than Benefits, Time, and Payroll. But that is a mistake: PA and OM form the foundation for the rest of the system, and you need experienced consultants to help make sure it is put together correctly.
3. Communication skills are critical! The consultant needs to be able to communicate well not only with their immediate project team, but also with end-users. If possible, include an end-user on your interview team (you need to have interview teams!). Communication is a two-way street - the consultant needs to be able to express themselves clearly as well as understand what others are telling them.
4. Be sure to check some references! Give them a call and talk to them about the consultant. If your phone call is not returned, that probably means the customer doesn't want to give a bad reference - so take that as the bad reference it is. In my experience, customers don't mind giving references for consultants that did a good job for them. It's amazing to see how many consultants get hired without even a few basic reference checks. And these reference checks are also a great way to start networking with others who have gone down the road you are about to travel!
5. If a consultant isn't working out, give them some feedback and a chance to improve - but be firm about setting a follow-up review. If they still are not working out, cut them from the project. Project teams can't afford to waste a lot of time and resources - or achieve an inferior work product - for very long, so move swiftly.

Eventually, you will find the right consultants for your team. Remember when negotiating rates, you get what you pay for. The penny-wise/pound-foolish maxim holds true for project teams. In fact, inferior consulting can hobble your SAP system for years, driving up maintenance costs while restricting flexibility to meet new business requirements.