sbogner's blog

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.

When Tax Reporter is run to produce tax forms such as W-2's, 1099-R's, 941's and so on, it creates a number of different outputs. The log files and mag media files are produced as TemSe output - which is intended to be stored only temporarily. Each time a TemSe output is created, the system puts an expiration date on it. Subsequent maintenance programs run to delete all the TemSe objects that have expired. The default expiration date is today + 30 days.

So for tax reporting, you might want to retain those logs and mag media files longer (though you can always regenrate the mag media files, even after they have expired). This setting is controlled in the feature TEMSE. Use transaction PE03 to maintain that feature.

There are three objects for the feature that relate to Tax Reporter:

For the mag media file objects simply specify the number of days you want them to stay in the system before being deleted. The Tax Reporter log setting works a bit different - if you specify one number, that will apply to the logs for both production and test runs. If you want to specify a different number of days for each of those, separate them with a '/' symbol. For example, to keep production logs for one year and test logs for 60 days, use 365/60. Once the settings are made, save and activate the feature, and test it as you would any other change management item.