Case study
Replacing a rigid vendor LMS with one that talks to its neighbours
Context
A hospitality and lifestyle group runs three HR systems: an applicant tracking system for recruitment, an HR portal for the workforce, and a learning platform. Between them sits the payroll platform, a vendor product that holds the employee master. Data has to move through all four in order. A hire in the ATS becomes an employee in payroll, appears on the HR portal, and is enrolled in the onboarding package on the LMS.
Everyone in the group uses it, across every property and outlet. I own the HR systems architecture.
Problem
The learning platform was a vendor product that stood on its own. It could not receive an employee from the portal or report anything back, and it could not be customised to the way the group works. So the chain broke at the last link: a new hire existed in three systems and had to be created again, by hand, in the fourth.
Options considered
Stay with the vendor. Rejected. The isolation was the problem, and it was not going to change.
Move to another vendor. Rejected. The group's way of working moves fast and changes often. A second closed product would fit this quarter and not the next.
Build in house. Chosen, because the platform had to follow the rhythm of the business rather than the other way round, and it had to speak to its three neighbours from the first day.
What I built
The learning platform itself, from the ground up: course modules, interactive material, quizzes, and two-way scenarios between participant and trainer. A direct supervisor sees their people's progress, and the record feeds the promotion process, so training is no longer a separate file from someone's career.
Integration with the HR portal and the ATS, so an employee is created once and arrives in the LMS with the onboarding package already assigned.
On the payroll side, an integration layer over the platform's API. The product did not model several relationships between employees and their data that the group needed: movement, promotion, demotion, changes of status and contract. The layer holds that model and keeps payroll in step with it.
Every exchange between the systems goes through an asynchronous queue on Redis with Laravel Horizon. Not for speed alone. Each job is visible and can be replayed, so when something goes wrong it can be traced, and there is an audit trail for the people who need one.
Result, and what I would keep
The vendor licence went with the vendor product. More useful than that: the processes that used to be complicated, a hire, a promotion, a change of contract, now run through without anyone re-keying, and HR's turnaround on them runs to a service level instead of best effort. Employees feel it; HR feels it most.
What I would keep: the queue with visibility, from day one. It is the difference between an integration people trust and one they work around.