Blogs

SAP made a big deal of In-Memory Databases (IMDB) at SAPPHIRE NOW this year. And, it is a big deal - this technology transfers the database from disk into main memory, which frees it from time-consuming disk actions while also enabling more sophisticated database structures. The gain in performance and flexibility will transform how business data are used for all sorts of processes.

So what does this mean for customers using SAP HR (or HCM, take your pick)? Maybe you have BW, Business Objects or both. Maybe you are considering using them in the near future - how are those technologies impacted? Or perhaps you are looking at creating more event-enabled processes in SAP HR - something that IMDB is supposed to be really good at. What does IMDB mean for the current data framework in HR - infotypes and clusters?

At this time there are many more questions than answers. SAP is releasing an IMDB appliance that will work in conjunction with the R3 system; it's a quick-fix approach designed to get customers using and familiar with the concept. But aside from that, there are not many details on what will be released and when it wil be available.

One thing is certain, in my opinion: Integration of SAP HR with IMDB will lag the rest of the modules. Three points lead me to this conclusion.

First, HR has lagged in every new technology released by SAP. When most other modules had switched to transparent tables, HR was still using PCL1 clusters for infotypes (yes, I've been around that long; and that cluster legacy still persists deep in the infotype processing). When most other modules were using ALV for operational reporting, HR still had plain text lists. When other modules had substantial BW content, HR was just getting started.

Second, the implementation of the data model for SAP HR is so entrenched in the system that transforming it to IMDB is going to be a huge effort. The current HR module is based primarily on Infotypes and Clusters. Under the hood, HR is still using all sorts of old programming methods for accessing and processing data. When was the last time you programmed a macro in TRMAC or used a straight database import to read transactional data? Those methods are still around in HR, along with function modules and classes/methods. The technical transformation is certanly feasible, but daunting.

Third, and finally, many HR departments don't think in terms of what IMDB can do for them so the business demand for IMDB development resources will be overshadowed by Logistics, MM, SD, FI and the other modules. HR business processes, and even more important, HR department philosophy, are mostly blind to what features like event-based triggers and real-time decision-making can do for them. Many HR groups are doing well to take a few, tentative steps into simple business analytics. Maybe if they push hard, in three or four years' time they would be ready to take on the benefits IMDB can provide, but by far the majority of HR departments are nowhere near ready for that.

So I believe it will be at least three years before we see meaningful, substantive and production-ready IMDB functionality for SAP HR. The IMDB appliance will make some HR functionality available prior to that, which is useful for early adopters and those who are interested in prototyping the functionality. IMDB certainly is one of the most significant changes in SAP technology; it deserves a good deal of respect and inspection because of the impact it will have on SAP and its customers. We will keep an eye on it and advise our clients to do the same.

As the economy comes back and demand picks up, the pace of business activity quickens - and that leads to increasing demand for talented employees. This is typical of most economic recoveries, so most HR and IT leaders won't find this surprising.

A recent survey by McKinsey found that 30% of companies are increasing their focus on retaining their R&D talent in 2010, while 17% plan to aggressively pursue hiring from sources such as universities and competitors. Only 25% plan no changes in hiring at all. The survey didn't address other business functions, but I think it can be safely assumed that top talent in sales, management and manufacturing will also be highly recruited as the economy recovers.

I've received questions from a few customers on how the HIRE act is going to be implemented in SAP US Payroll. And the answer is: I wish I knew! They haven't released anything yet. Since this is a regulatory requirement, customers should expect (or maybe demand) SAP to release a transport or note that will have all the system customizations needed to implement it. It seems like a fairly simple update to me; if I was going to do it, here's what it would look like:

1. Create a statistical wagetype for IT 0014 Recurring Payments & Deductions, and name it something like 9HIR. Set processing class 20 to a 4 to make sure it gets saved to the RT before taxes are calculated. This is your flag to designate which employees are subject to the HIRE act tax credit. Enter the wagetype on the eligible employees from the date of hire to the end of the last payroll period of 2010; set the amount field to 1.00.
2. Create two more statistical wagetypes - one to represent the employer-paid Social Security taxes that are exempted and one for the Social Security wages; let's call them 9404 (Exempted Taxes) and 9704 (Exempted Wages).
3. We need to post the tax credit to accounting. For wagetype 9404, map it to the same symbolic accounts as your /404 (or whichever user wagetype is used for posting Social Security tax) - and make sure that it is posted with the opposite signs. Normally, /404 will post to an expense account with a + and a liability with a - ; so 9404 ought to post to expense as a - and liabilities as a +.
4. Create a rule that is triggered by the presence of wagetype 9HIR, that copies wagetype /404 to 9404 and /704 to 9704. So if the rule sees 9HIR in the RT, copy /404 to 9404 and /704 to 9704; otherwise don't do anything.
5. If you are using 3PR (Third Party Remittances) to pay your taxes, add wagetype 9404 to your HR Creditor and make sure its sign gets reversed so that it reduces the payable amount.

And that's about it. When payroll runs for an employee with wagetype 9HIR, it will create copies of the employer-paid Social Security wagetypes, which you can then use to post the tax credit to FI and also have them present for reporting on the 941 and W-2.

There are other ways to do this - for example, how to designate the employees subject to the HIRE act process - which I'm glad to discuss. It will be interesting to see how SAP implements it.

p.s. Thanks to Jarret Pazahanick for the email thread that led to this.