Skip to Content

The buzz around integrating core SAP HCM with SuccessFactors is spreading fairly far and wide these days. About half my clients have mentioned they are ‘looking into SuccessFactors’ – often at the urging of their SAP accounts reps it seems. Integrating these two pieces of HR software so that clients get real value instead of real headaches is challenging, but not impossible. SAP HCM consultants have been integrating the product with other HR systems their whole careers; I’m not quite confident that developers without that experience can create an effective integration model. And the ease with which clients will be able to take advantage of any sort of integration pack from SAP will primarily depend on how well they have stuck to SAP’s delivered HR data model. I’ll explain why.

Every SAP HCM implementation project contains significant tasks for data conversion from the old HRIS and interfaces with various other systems. The technical part of these tasks isn’t so complicated but the data model mapping sure can be. I’ve worked with clients to convert historical data from almost every legacy HRIS platform into SAP HCM, and most of that work is determining how to translate the legacy data model to that in SAP. For example, we have to determine how to map the data from an Integral system into an SAP system with Concurrent Employment, or from PeopleSoft into SAP HCM, or  Tesseract, JD Edwards, Infor – pick a vendor. They each have different data models. Mapping from system X to SAP HCM is something SAP HCM consultants do often.

The other type of data model mapping we do is to support interfaces from SAP HCM to other providers, and every implementation has them: external TM systems, Talx, Fidelity, Merrill Lynch, Schwab, ADP and even internal systems. And they all want it their way – we can’t just send unfiltered and unformatted infotype changes to them and there is a dreadful lack of standards among vendors. Most of the time we are mapping to a flat-file type of structure, but the main task is still to determine how to map SAP HCM objects to and from the target system. When this isn’t done well, issues abound! It really does benefit clients to put good effort into making sure the data models are mapped well before coding anything.

If every SAP HCM client implemented the software the same, this wouldn’t be so big of a task. Do it once and reapply. But of course, SAP HCM gives clients a lot of flexibility and many of them stretch that to the limit. And honestly, some get poor consulting that leads to poor implementations of the SAP HCM data model. I’ve seen OM and PA infotypes misused in many implementations and just all messed up. And once clients have production data and processes in place, it’s difficult to straighten out those data model issues. Difficult but not impossible.

So as I think about SAP and SuccessFactors creating a comprehensive real-time integration model, those real-world issues and experiences come to mind. If they deliver something that is developed to fit a perfect-world situation then there may be a lot of unmet expectations from clients, and considerable consulting effort needed to make it work. I hope they learn from the consulting community about how their systems have been implemented in the wild, and build those lessons into the integration functionality they choose to deliver. Clients will sure benefit more from the latter approach.

To report this post you need to login first.

24 Comments

You must be Logged on to comment or reply to a post.

  1. Jarret Pazahanick

    Great blog Steve and I know that SAP has went into the “wild” and are working with customers via co-innovation but many times the “wild” isnt common enough to be included in the standard integration offering which is why SAP will roll out a “integration hub” in Q4 for customers to enhance the standard.

    That said we can see how long it is taking SAP to deliver a baseline integration offering with SuccessFactors (I dont consider the CSV mass file load in May as an offering) given the different data models and it has always been a HUGE pet peeve of mine when 3rd Party HR vendors of their sales team say “we are integrated with SAP” (as none REALLY are) just because one of their customers went through the painful exercise and build a custom interface.  One thing I have seen time and time again as SAP customer choose best of breed vendors outside of SAP for the speed and innovation (will be less now with SuccessFactors) and after months of getting the initial integration in place many cant or are willing to change the “working interface” so in fact they often can take advantage of this great new and ongoing functionality in their SaaS offering.

    (0) 
    1. Steve Bogner Post author

      Thanks for the comment and info, Jarret. This integration will be more of a journey than a destination, that is sure. This sort of stuff (‘we are integrated’) always sounds easier than it really is.

      (0) 
    2. Chris Paine

      Hi Jarret, Totally agree that the current extract tool is not really an integration solution.

      Have we heard anything about the pricing of PI onDemand that I assume will be used as the hub for the forthcoming integration? I’m concerned that the view from the people I speak to is that integration between SF and ECC will be “free” for existing customers of both solutions, but not sure if this will continue to be the case once we get past CSV file extracts.

      (0) 
      1. Jarret Pazahanick

        Great comment thread and as far as your question Chris the information around PI OnDemand it this use case has been very minimal to date.  I think we both know that the “free” solution is likely to continue to be the very basic CVS file and using PI to integrate SAP and SuccessFactors will be an extra license (sure hope I am wrong)

        (0) 
  2. Luke Marson

    Hi Steve,

    This is a great blog and you raise some great points about the difficulty in integration. SAP have taken a bit of a rap for their integration packages (there is some detail about the first package in a blog I wrote Integration Add-on 1.0 for SAP HCM and SuccessFactors), but SAP are well aware that it’s not a straight path to go from virtually no integration to full-on, bi-direction, secure, genuine integration. SAP will be going via interfacing initially, because it is the best that can be offered after only 6 months.

    During my work with Nakisa solutions I have watched the evolution of their integration from a non-flexible, fixed integration (e.g. a static set of fields) to a fully integrated solution where the customer’s choice of data fields can be extracted in real-time, leveraging SAP security and in the format that th customer wants. This took Nakisa nearly 4 years to achieve and goes to show how tough even more “simple” integrations can be to achieve.

    I hope SAP are able to reach out to some existing SuccessFactors clients who have spent months building their own integration because I think there were some painful lessions learnt and SAP doesn’t want to be at the heart of creating or experiencing painful integrations.

    Best regards,

    Luke

    (0) 
    1. Steve Bogner Post author

      Thanks for adding to the discussion Luke. I agree that it’s not a straight path and it will take some time. And yes, hopefully SAP will learn from some of those painful customer lessons before turning loose the s/w on others!

      (0) 
  3. Chris McNarney

    Thanks for the blog and comments all.  This blog represents subjects near and dear to my heart; interfaces with SAP HCM and specifically with SuccessFactors.

    One of the things that made the SAP/Nakisa integration so seamless was that Nakisa to a great degree just had a login to SAP and then called SAP code.  This was a real victory because it was all the same codebase.  In this new world order, given that SAP said “SuccessFactors will continue to support an open approach to connecting with third-party solution providers” I’m not sure we should expect to see SFSF retrofit to go in and run ABAP.

    As far as the .csv file dumps go… I’ve seen worse.  A great many software providers do data integration quite successfully the same way.  For instance, if you go out and buy Taleo tomorrow, in a few weeks you’ll be starting up your design of how you’re going to build and send them 5-7 full dump .csv files each night.  File imports like this are an integral part of how SaaS providers like SFSF get populated with data.  A tour around the admin section of SFSF will give you numerous places to execute XLS/CSV imports.

    Since SAP already put it’s line in the sand that the SFSF data model needs to remain flexible, I can’t see us getting around the world of .csv files from SAP.  With the delta file change coming to the integration soon, that will alleviate some of the full file headaches that a large company would endure.  However my gut tells me that long term we’re going to be looking at something close to how SAP runs ALE today.  Change pointers from SAP generates an IDOC, then PI turns IDOC(s) into a file and sends it off to SFSF to await an import from the SFSF scheduling tool (Quartz).

    Could you do a real time connection from one of the SFSF talent modules with SAP on premise HRIS?  That’s technically possible, but I’ve done synchronous XML interfaces with PI before and they’re inherently risky.

    Easily my biggest struggle with this acquisition was that SAP took it’s integration between core HRIS and the talent modules from being instantaneous to working just as well as they would if you went out and bought another software provider’s tool.  I used to harp about this all the time, but lately I’ve decided this means SAP decided that by the time 2020 rolls around they will have a LOT more cloud customers on Employee Central (and whatever other functional disciplines are in the cloud by then) than they will with on premise core HR SAP, rendering this hybrid integration mostly moot.

    I have digressed. 

    In general, while I’d never give a demo of this first integration package to a customer with some inspirational music in the background, I wouldn’t be afraid to recommend it either.  The primary reasons are that it a) will work and b) will evolve.  Once there’s a delta file and bi-directional movement back into SAP, we might be cooking with gas.  But until SFSF decides manipulate it’s data model to fit SAP HCM (which will happen right around the same day the sun burns out), a .csv interface is what we should expect to see.

    (0) 
    1. Steve Bogner Post author

      Thanks for your thoughtful comment Chris! I like the idea of a more-real-time integration via PI – it’s a great tool for such things. It’s also another license for SAP, though it’s a tool most every SAP client can benefit from. I agree that good integration can come from flat files, but I just don’t like taking that approach – as a long term solution – when we can do better. Maybe I’m too optimistic in thinking the data models can be bridged via some abstraction to a common model; but then, there are a lot of smart people working at SAP and SFSF, as well as in their client & partner communities, so there should not be a shortage of brainpower to make a good design work.

      (0) 
    2. Luke Marson

      That is a good point you make about Nakisa integration and that is one of the benefits of on-premise technology. SAP’s integration for on-premise to cloud will use different technology and is unlikely to use RFC integration. Web services and other services provided by SAP NetWeaver Cloud and SAP NetWeaver PI OnDemand will be the way forward.

      One thing that interests me is how SAP will make it’s core HR system work with the SF MetaData Framework. This is a new concept in the SAP world and doesn’t really align with SAP’s data model. I can’t see SF changing their data model, but expanding it to include parts of SAP’s data model (whether customers use it or not) would certainly aid the integration aspects.

      We’re in an age where technology is changing rapidly and there are platforms not yet available that could make this integration work “easily”. Whether this type of technology will be around by 2020 is not yet known, but SAP will no doubt be working on ensuring it is available as soon as possible. I hope that if they release it then it has less bugs than everything else they release (there are over 12 SAP notes for the SF integration package already and it was only formally released on GA this week).

      I think the point from the comments on this thread prove Steve’s point: that integration is not an easy topic!

      (0) 
  4. Stephen Burr

    I echo some of the other comments but would also add that I do not believe the aim is to seamlessly integrate SFSF and SAP HCM with real time integration.  Technically possible (without doubt),but not the current aim.  I anticipate that any longer term solution (above the CSV “interface”) will still be based on the principle of moving data between the two systems.

    i.e. move employee’s name from SAP to SFSF, not read the employee name for display in SFSF as/when required

    or

    move the SFSF pay change to SAP HCM for payroll.

    As Chris says, the data models are the challenge.  SFSF data model supports the suite of applications they have.  SAP HCM’s data model supports theirs.  No-one wants to rip it up to align the two.  Remember only 25% of SFSF customers uses SAP … they are in the minority (for now!).

    As Chris says, I think the closest we might get to real-time is the use of change pointers, ALE and PI to move data safely and securely between systems in close to real time. 

    Another point, I wonder how much integration is bothering the top people in SAP (sure, it is important, but is it the most important thing).  What I mean to ask, is whether the main upshot of the SFSF acquisition is to sell SFSF to SAP HCM on premise customers (i.e. hybrid solution)? Or to sell SFSF to new customers (i.e. so SAP have an on demand offering)?

    … but I am digressing from Steve’s original topic!

    (0) 
    1. Luke Marson

      I know from senior SAP executives that their aim is for seamless, real-time integration between SF and SAP HCM and they intend to move this forward aggresively once SAP NetWeaver Cloud and SAP NetWeaver PI OnDemand are released in Q4. However, SAP’s integration roadmap is largely high-level and doesn’t specify points such as “move employee’s name from SAP to SFSF, not read the employee name for display in SFSF”.

      This is an important point that you raise – while SAP need certain data to reside in one system (such as Talent and workforce planning data – for Workforce Analytics), certain data does not need to reside in one system (static data such as name, address etc). While you are right that a small % of SuccessFactors customers (30%) are SAP customers, SAP intend to push their solutions to SAP customers and therefore must offer much better integration than the current model. Quite simply, SAP has been pushing real-time integration for a few years now and this was one of the selling points of the Nakisa solution. Retracting on this stance now will only make people wonder whether what SAP says is right.

      Ultimately, SAP’s top management will be more concerned with selling the solution to any customer (existing SAP customer or otherwise) than whether it is genuinly integrated. At the end of the day, and I think you will probably agree, license fees make the SAP world go around, not integration!

      (0) 
    2. Steve Bogner Post author

      Thanks for adding to the discussion Stephen – much appreciated. The data model differences are challenging, and my point is that consultants have faced many such challenges as we help clients migrate to SAP. So I know the data models can be bridged, and yes it is complicated. But then, LIFE is complicated, yet we’re still living.

      (0) 
      1. Stephen Burr

        I actually don’t think it is that hard to technically do it.  There are plenty of techniques for this and also there aren’t that many fields that need to be moved (in the Integration Add On 1.0 there are 29 mandatory fields to move).

        However, my point was more about what the desire and intent is.  I’ll explain another way … say you are an SAP customer wanting to use SFSF Talent Mgmt (to make it easy I’ll say you are happy to use all SFSF TM, not some modules in SFSF, some SAP … that would be another complication!).  In an ideal world, they’d want it to be seamless and not to have to manage any type of data movements (no PI, no monitoring of flows, interfaces, etc).

        Ideal solution … set a setting in SFSF that says “core” HCM is managed in SAP.  Every time SFSF needs a piece of core HCM data then it calls SAP to get that data.  To re-use my previous examples ….

        SFSF Talent Profile would show SAP HCM core data (name, current/previous positions held), etc alongside SFSF talent information (readiness, ranking, etc).

        or

        When SFSF compensation mgmt results in a pay change it is written directly to SAP to affect the payroll, etc.

        No movement of data, no middle layer. 

        My conversations with SAP people have indicated that this is not the envisaged solution due to the complexities of supporting that magic “switch” between having core HCM from SAP (magic switch on for 30% of customers) vs from SFSF (magic switch off for rest).  Their current thinking seemed more akin to moving the data (seamlessly) in “near” real time.  I guess time will tell.

        (0) 
        1. Luke Marson

          I think in an ideal world we would like data to be read directly from SAP (like we have with Nakisa’s solutions), but I think because of the nature of SAP this is going to be difficult. I don’t think it’s quite as easy as you suggest – I’ve worked at many global and local organizations and I’ve seen amazing (and bizarre!) data models that are not compatible with other organization’s data models. This is the biggest problem SAP will have in creating integration – a “one size fits all” approach is not enough. Even within talent, customers using pre-EhP4 data models don’t have the same data model, infotypes, field lengths, data types etc – although a performance rating is still a performance rating. The first package has only 29 fields – but this will increase with each package and module introduced. How many fields does core HR use? My guess is more than 29! 😉

          I’m interesting in the response you have from SAP  because I can’t see it being a large task to have a “switch” or setting, since largely this setting just tells SF what integration layer to use (and I can’t see them skipping out an integration layer if they are going to allow SF to openly connect with other systems). As you know from configuring SOVN OrgChart, it is simply just a small configuration to set the data source and then the application uses the appropriate integration layer.

          The topic is quite fascinating and with so many challenges and so many options it really does make for an interesting road ahead. SAP have to make sure they cover a number of bases and stick to their core principles (integration first, right?) and this is maybe the biggest challenge of all. I’m not even 100% sure that SAP know how they will achieve it in the long run, but I guess they will figure it out!

          (0) 
          1. Chris Paine

            I’d have to disagree about the “in an ideal world” bit Luke 🙂

            In my ideal world, nothing would be in the ECC system any more – but all in the cloud, and that includes the payroll.

            @Steven I can understand why you’d want to do ALE style replication rather than single source of truth views. Imagine the response time of a report that needed to bring back the age of all employees if it had to go and fetch that data from the ECC system, it certainly wouldn’t fit the HANAlytics name-tag.

            @Luke – you must remember how long it has taken to get “real-time” org-charting into Nakisa, and the number of iterations that it has had to go through to become something close to high performing – even now, building a org-chart in real-time in ABAP is not something that runs lightning fast.

            (0) 
            1. Luke Marson

              I suppose it depends on who’s ideal world it is! 🙂

              I think I am referring to the number of customers who are likely to retain SAP R/3 as their master data system. I imagine over time some will choose to remove theirs, while others may have a legal obligation to keep their data out of the cloud.

              In the case of the latter, real-time integration is an option that clients are going to want to realize in this scenario.

              I mentioned in the comments of a previous blog (I don’t remember which one off the top of my head) that the Nakisa integration has taken 3 years to get to where it is today, which is pretty close to full integration (it’s not quite there yet). Whether the introduction of SAP NetWeaver Cloud or PI OnDemand will speed things up for SAP I don’t know, but the complexity of the different customer data models and high volume of data fields means there is a huge challenge that dwarfs that of Nakisa’s challenge. SAP’s in-house expertise and number of resources will no doubt make it more manageable, but I think it’s still going to take some time and effort to realize.

              (0) 
  5. Chris Paine

    Great blog Steve, and I’m loving the excellent comments here too!

    I’m doing a little “chat” at the SAUG Summit next week here in Melbourne around my worries and hopes for integration of SAP ERP into SuccessFactors (and ultimately the rest of SAP’s forming Cloud LOB Suite).

    Hope you and the others commenting in this blog don’t mind if I grab a couple of your great points to kick off the discussions?

    Thanks for the great content!

    Chris

    (0) 
    1. Steve Bogner Post author

      Thanks for adding to the discussion Chris! I’m glad this content started some discussion – and am fine with you using it at SAUG, with attribution as Luke said.

      All this discussion reminds me of how important integration is in these hybrid environments – we’ve talked about it before and I wrote about it in Jan 2011. For many clients, a hybrid environment is going to be a given, and integration will have to happen. They will demand it, and rightfully so. Their operating environments – on-premise, cloud, mobile & analytics – will demand that level of integration. Clients should not have to wait years (four, three?) for good, near-real-time integration – however it is implemented technically. So I’m hoping SAP delivers something robust, soon.

      (0) 
  6. Srinivas Mandgi

    Hi Steve,

    A very very interesting discussion. With your permission I would like to add

    my views. SAP HCM with the NetWeaver platform

    would have a lot of third party vendors wanting to

    Integrate and have a two way free flow of data. However,

    every new vendor means a new pipe connection which is making

    SAP HCM messy and scary to customers. A common

    Integration database as a part of PI or for that matter

    MDM could be resigned to optimize its customer usage

    and via package extensions new integrations could be added

    depending on the customer choice.

    (0) 
    1. Steve Bogner Post author

      Hi Srinivas and thanks for adding your thoughts to the discussion. I agree that a template or some standard PI configuration for common HR interfaces is a great idea. It would make implementations of SAP HCM easier and less expensive, which is good for clients.

      (0) 

Leave a Reply