Chuck Allen over at the HR-XML blog has been writing for a while and a post on employee indicative data caught my attention. If you think about all your most common interfaces, employee indicative data is the one used the most. In fact, pretty much every HR technology interface needs to push or pull this data-set.
While the stated mission of this XML specification is to provide outsourcers with employee data, I don’t see why we couldn’t use it for everything from getting data to obscure parts of the business (we all know how many employee data interfaces IT and Finance want), exporting nightly data to the shared services center, and even internally within HR technology between our own systems.
My clear concern is around the adoption of HR-XML specifications. As most outsourcers use batch mainframe systems, I don’t really know how many of them have adopted XML on a wide scale. In fact, I’m betting most traditional benefit and payroll outsourcers (the large majority of the outsourcing market) still use flat interface files. At any rate, it’s a great vision and a great spec. Perhaps it’s time for the outsourcers to get on the ball. HR technology is at a place where all our lives can be made easier. Outsourcers are supposed to limit the amount of transactional and technological work we do, not add to it.
What I’m really interested in is to see if/how newer technologies like RSS might be “tweaked” and utilized in data transactions. While I don’t know if RSS could be used for transactional processing, I don’t know if XML is the only way. I’m guessing in the next few years we’ll have new ways of transacting data.
Update: Check out this post and this article at a new blog.
8 responses to “XML Interfacing”
[…] Double Dubs 3.23.06 / 8pm […]
Hey Dubs, any chance fo you going back to full text feeds?
Anything for you Michael. Let me know if the new settings don’t apply in the next couple of days.
Thanks for the mention of the Indicative Data spec. I agree that with you in that this spec is not just for getting data to an outsourced HR system. We are already finding uses with the wide variety of systems that need to be provisioned with employee data — everything from a contact center to a learning management system.
Obviously, there are many HR system interfaces that use and will continue to use some pretty ugly flat-file formats. Your observations about payroll service providers are on point. Our investigation into interfaces between HRIS and Payroll outsourcers is that the interfaces frequently are proprietary — but they work, the costs are already sunk, and the requirements are stable — so understandably there is little reason to change.
So if the characteristics of a process are that it is batch and that the content and trading partners not particularly variable, moldy oldy interfaces will probably continue to work quite well. The point at which using a specification like Indicative Data within web services makes sense is where there is need to move from batch to near-real-time, and from a single, tightly coupled trading-partner relationship to something more distributed.
The forces for change are coming from both within and from the outside. At home, managers and employees can make travel arrangements and trade stocks in real-time — Why shouldn’t they be able to add/change in real time a name, address, contact, dependent info, effective date, status, etc. on an outsourced system and on the systems of downstream partners? Outsourcers themselves, as they wrestle with increasing client expectations, thinner margins, more competition, and the complex role of being the “general contractor,” are finding standards like Indicative Data attractive. Finally, there are pressures from the outside. For example, in the last several weeks we’ve had conversations with the “Medical Banking” community working on streamlining HSA transactions. There are only a few employer-facing interfaces the medical banking folks are concerned with, but they absolutely have expectations of loosely coupled and real-time connectivity.
So it is a mixed bag out there. I think you can debate the pace at which outsourcers will move from reliance on batch/flat-file interfaces to reliance upon XML web services, but it is difficult to debate the overall trend. It is also difficult to argue that the forces for change will not increase.
Chuck: Thanks for the great reply – I was actually waiting for your comments.
If I take ADP as an example, they do batch payroll on a fixed schedule. Running off of some ancient mainframe engine (not a commentary as to if it’s good or not – it really is just old), that has tried and true batch interfaces, upgrading 500,000 clients to an XML compliant platform doesn’t make much sense.
However, the very same vendor may be providing XML interfaces to their portal. So they have employee data, benefits transactions, time and labor all on a single portal tied together with real time messaging. (I’m not saying that’s true either – another example). It’s entirely possible that they have found it useful to upgrade certain parts of their application infrastructure to XML while other parts sit in dated mediocrity.
Mainframe systems aside, all of these outsourcers generally have front end applications. Unfortunately I think we have a mid-market problem here. Most mid market systems are not compatible with XML, but I’m optimistic the ADP’s and Ceridians will move there as the larger vendors. Having employees be able to access everything but payroll would simply not be an option. (note – I should add that this reply is not payroll specific. We could really find the same with benefits, recruiting, etc…)
[…] Decided it was time to write a post more related to my day job…I had a look at the post on systematicHR. I won’t comment on detail on HR-XML, cos I need to get up to speed with it again (I was closely involved 5 years ago, but not really since) , but I will comment on changes I see happening in the HR outsourcing-BPO space. […]
Thanks Dubs!
Just a quick follow-up. I think you are on-point that vendors will “upgrade certain parts of their application infrastructure to XML while other parts sit in dated mediocrity.” I think we are mainly on the same page.
The point I wanted to follow with is that the type of platform is relevant to adoption of “XML interfacing”, but isn’t always the determing factor. Perhaps a good comparison might be payroll and insurance systems. These are both domains where big iron still rules, but I see different adoption patterns emerging. Payroll is a batch process plain and simple with fewer interactions with arms-length trading partners. Insurance and outsourcers handling eligibility and enrollment data use the same type of mainframe systems and often the same vintage of COBOL-applications as the payroll vendors you describe. I think the difference is that there are increasing bottom-line driven use cases for handling some of the insurance eligibility and enrollment transactions in near real time. What we’ve seen is these “big iron” reliant outsourcers and insurers beginning to use XML interfacing in a couple of different ways. The first involves using existing proprietary message queuing infrastructure. The second is using the capabilities of specialized application servers to put a web services facade on old mainframe apps. (google and you can find crazy sounding things like tools to create WSDL from COBOL). I’m not saying putting a web services facade on old apps is always easy or ideal. What I am saying is that it isn’t the platform — it is the business needs that determine XML and web services adoption. If interactions are batch and with a handful of known trading partners – you are not likely to have a reason to change. If your needs are real-time and they involve opportunistic partnering at arms length, you obviously are going to be looking to XML and web services.