In the last entry I wrote “that the only HR departments that go on SAP are the ones that are forced to do so by their CEO.” While there’s some truth to this, I’ve also written in the past that if I were a CIO, I’d go out and buy Oracle financials, PeopleSoft HR, SAP supply chain, etc… and hook it all up in the back end with whatever API’s I’m using and some nice web services for portal and Cognos for business intelligence. While that’s all well and good, it’s just not reality. (and every now and then I need to be realistic)
Reality states that SAP and PeopleSoft are incredibly different to integrate. So while you really do have options when you’re selecting your HR vendor, what the rest of your organization is on does matter. No matter how your vendor presents the technology, in the back end, SAP is a real time system and PeopleSoft is a batch system. There is good and bad to both of these processing philosophies both for HR processing and broader organizational integration.
SAP being a real time system sounds great, and it usually is (assuming that you are on SAP for all your ERP systems). However, true real time integration creates havoc all too often. While we love real time, the truth is that once the employee record has been updated, a dozen other HR fields have also updated, and a cascading tidal wave of change has gone out to finance, operations, etc. By the time you realize that the initial employee record change was in error, it’s too late, and rolling it back 5 minutes later means rolling it back in 20 downstream consumers of that data. All in all, real time data integration is a great thing, but you really do need to understand what it all means.
However, I should talk about PeopleSoft (considering I pissed everyone off by calling it batch). I’ll stand by the batch part, but I’ll concede that you can put in as many hooks as you like making workflow real time. So when you hire an employee, the workflows go out in real time to manage tasks. However, anyone who has ever implemented payroll, ben admin, or whatever will probably wholeheartedly agree that most system processing and data integration between the ERP modules happens in those fabled batches. So while you eliminate some of the problems we noted for SAP, much of the native integration within the ERP suite isn’t so timely.
What’s the point? We started this article saying that mixing and matching ERP modules may not be the best thing. Honestly, it’s hard to get a real time system to talk to a batch system and vice versa. On top of that, within a consistant ERP suite, the vendors have built in the API’s for HR to talk to finance (and whatever else) pretty seamlessly. Visions of XML are great, and they do simplify the old worlds of async interfaces. But true effectiveness in your ERP suite is greatly simplified by staing within the ERP suite.
9 responses to “PS vs SAP: Part 2”
PS vs SAP: Part 2 August 11, 2006 on 2:00 am | by Systematic HR In the last entry I wrote “that the only HR departments that go on SAP are the ones that are forced to do so by their CEO.” While there’s some truth to this, I’ve also written in the past that if
. Thanks for your readership and I look forward to another year. 1. Sleepless Nights in HR parts 1, 2, 3, 4, 5, 6 2. The Wrong HR Silos 3. HR Function Commoditization – The Future of HR 4. Hewitt’s Lessons Learned 5. PS vs SAP parts 1, 2 6. Independent Consulting: Perception or Reality? 7. Oracle versus SAP – 2008 8. The #1 and 2 Factors for Successful HRMS Implementation 9. Vendor or Client: Who’s Fault is it? 10. Talent Series:
look forward to another year. You can view current (daily) posts at systematicHR.com. Sleepless Nights in HR parts 1, 2, 3, 4, 5, 6 The Wrong HR Silos HR Function Commoditization – The Future of HR Hewitt’s Lessons Learned PS vs SAP parts 1, 2 Independent Consulting: Perception or Reality? Oracle versus SAP – 2008 The #1 and 2 Factors for Successful HRMS Implementation Vendor or Client: Who’s Fault is it? Talent Series: The Rules of Talent
“But true effectiveness in your ERP suite is greatly simplified by staying within the ERP suite”
This notion is behind the push (read: heavy investment) toward total talent management vendors, who are duking it out across function points with all the ATS, assessment, background, performance, onboarding, etc. specialists who really dig into each area.
DD clearly thinks that IF the integration challenge would be met, the pieces parts approach would be better technology, but DD says that you still should buy the whole smash because mix and match is not “realistic”. I think we can break realistic down to ‘way too expensive’ and ‘nobody around to do the work’.
Technology has a funny way of getting cheaper, so the raw costs for IP will go down. In my mind, when there are people around to do the work, organizations who mix and match will end up spending less and being more competitive.
Why / How / When will there be people around?
Just as no major company would run without financial analysts, I dont think big firms can run much longer without dedicated HCM analysts as an everyday role.
Talent management can be very complex, but in the computing sense, not so much; and nothing like the volume and complexity of logistics, production, and enterprise-wide accounting those ERP systems automate.
Integration should be a more approachable idea with HCM, and the point vendors are by nature getting better and better at integrations every day. It may be interesting to see how things go between the really good point vendors and the Total Talent Management devotees, and what ‘typical’ practices around HR data will be in the next few years.
Martin: Thanks for the reply – I just wanted to clarify my position.
I’m not fully advocating the purchase of an entire ERP suite because it should be more integrated. I’m simply saying that SOA and web services may be too immature at this moment in history to provide easy integration at not only the data level, but also business process, work rules, and user experience.
I agree that the last sentence requires a re-word, and I’m certainly a fan of the point solutions. I just think we’re still a year or two away from really making these systems sizzle all together.
Hey, Systematic, long time no speak:
Your post was compelling enough to rouse me from my summer stupor to say that I think you’re spot-on. In ginormous compainies like mine the devil is in the integration and data flow between the ERP and point solutions, and the impact on the scores of downstream systems. Services are coming along but there’s a lot more to building them out on an enterprise scale than usually gets much airtime, especially around responsiveness of the services bus for huge transation volumes and data privacy/location issues.
A related issue is the user pain inflicted by multiple interfaces. It impacts self-service users more than our professionals and it’s something that I’m spending a lot of my time on.
Same as you, I can’t drink the full ERP kool-aid but if you do ERP does avoid some stickiness that the multi vendor environment gets into.
Hopefully I’ll get back to weekly posting Real Soon Now.
Ciao,
The Other Systematic
DD-
I think your optimistic about being a just few years away from easy integration and widespread availability of required competencies- I think it will be more like six or eight years, but that’s still pretty soon. It’s mental (i.e. slow) change away from the idea of ‘applications’ and toward the idea of made-to-order interactions with data- this may accelerate with greater interface transparency in devices and solution design. It won’t be wild west raw data- more like a menu of choices for end users based on their needs and tastes.
And also, with the nature of staffing, tons of activity will always occur within organizations too small to support a real ERP- they will be running many kinds of qusi- ERP mashups extended from what we see today.
Martin: I am ever the optimist. it’s the only reason I can have a site like this – I assume everyone is right there with me and putting all these ideas into practice immediately! (yeah right…)
[…] 5. PS vs SAP parts 1, 2 […]