So, you’ve bitten the bullet and decided to replace your legacy ERP with a modern cloud-based HCM solution.
If you’ve a level playing field, you’ve probably concluded that the best product out there is Workday. You’re going to move to consistent global business processes, eliminate paper, empower your managers and produce sophisticated analytics that deliver real insight into your business and drive decision-making. Great stuff! But you’re also planning to build interfaces to other systems based on batch processing. Why the sudden lurch back to the 1970s?
With Workday, as well as the unified data model and the approachable user interface, you get a set of integration technologies that are designed for modern computing, and this means that you can move beyond the constraints of yesteryear. But surprising numbers of customers don’t take the opportunity to do so. History may indeed be the clue here – since legacy ERP systems need separate data structures for dealing with transactions (OLTP tables) and providing reporting (OLAP tables), batch processes needed to be run periodically to update the reporting tables with the latest changes made to the transaction tables. And legacy systems such as many payroll solutions expect or demand batch files – hence it is the default mindset of many HR technologists.
There is another way
So what is or should be the modern approach to interfacing? What I’m talking about here is near-real-time asynchronous messaging (NRTAM). Simply put, this means that your Workday systems generates a “one row” interface file every time a transaction is processed and sends it off straight away to be processed by the receiving system. Instead of waiting until the end of the day or some other arbitrary time period, data goes out to update target systems as soon as it is valid, and the target systems process them as soon as they get to them in the queue – hence why it is called near-real-time rather than real-time. Think of it like time it takes for your Active Directory password reset to take effect in all the systems in your company that use Single Sign-On – because this is, in effect, how that is done. This approach is widely adopted in other areas of IT, albeit not appropriate for all applications, but seems to have been neglected in HR Technology, which is a big pity because it is ideally suited to most interfaces in the HR landscape where the source system does not require a response from the target system in order to proceed. And the benefits are, I think, clear to see.
The first case that springs to mind is the updating of an employee termination “for cause” – it’s obvious I think that organisations would want that transaction reflected in all target systems as soon as possible to prevent sabotage, theft of IP etc. But other examples further underline the benefits of near instant interfaces – above all when they are corrections requested by employees themselves or management. It’s very frustrating that a new employee who sees her name spelled wrong in your Learning Management system and reports it to your help desk has to wait until the following day to see that it has been changed and to make sure that this time it is correct. It’s very annoying to have to tell a senior manager who has received a report on expat contracts and spots someone they know has returned from assignment that the correction will only appear on the report the following day. I’m sure all of you in HR operations can come up with even better examples than these.
Better use of infrastructure resources
We shouldn’t also forget the possible benefits in terms of technical infrastructure. Batch processes have a tendency to hog system resources, and most of us will have experienced user responsiveness deteriorating when batch processes are running, and when batch processes fail, they tend to reject all the updates in the batch en masse, which means that often 99.9% of correct updates are prevented by one rogue transaction. The biggest potential constraint to widespread adoption of this approach to interfacing in HR is inertia. Often it is assumed that target systems don’t have the capacity to handle near-real-time asynchronous message-based interfaces – this is undoubtedly true in some cases, but increasingly they do, and as customers, I think organisations should be demanding that they do. And if you are looking to bring your HR systems landscape up to date, you should be taking the opportunity to challenge that batch process thinking.
In conclusion you should be looking to eliminate batch processing and adopt near-real-time asynchronous message-based interfaces wherever you can in your HR system architecture