Workflow seems to be the holy grail of functionality in HRMS these days: every vendor has it, wants it, or is working on it. One vendor touts “120+ Off-The-Shelf Workflows” in their product, which strikes me as really odd for reasons I’ll discuss in a moment. My question is, how did HRMS vendors miss the BPM train? Knowing there’s a more comprehensive approach out there, why are HRMS vendors bragging about their shiny new workflow technology that’s at least one generation behind the curve?
To be fair, there’s a big difference between true Business Process Management (BPM) and application-centric workflow. The latter is what HRMS vendors are implementing (at least the ones I’ve seen), and the best objective here is to automate some of the common tasks within their products. For example, in most HRMS systems terminating an employee might require going into 3 or 4, perhaps more, screens and doing the edit-change-save routine. Application-centric workflow can make this process more consistent, allowing the user to terminate the employee in in a more consistent action, and perhaps also do some fancy things like sending notifications and assigning tasks to other people for review, approval, and the like.
If you think I’m about to advocate replacing application-centric workflow with a BPM platform, you’re a bit off base. Application-centric workflow has it’s function, place, and applicability. But it also has its limitations, as its bounds of responsibility and reach tend to end when you log out of the HRMS product it resides within. Instead I prefer to advocate that HRMS application-centric workflows be thought of as specialized tasks within an overall BPM approach. If your overall business process doesn’t require tasks, activities, or participants outside of the tasks provided in your HRMS system’s workflow, then you haven’t yet demonstrated a need for a BPM platform. If your business processes need tasks, activities, or participants outside of that provided by the HRMS system, you’ll inevitably need to consider a BPM platform, at least until the HRMS vendors embrace true BPM.
My favorite example is a customer with a very simple process concerning discretionary bonuses. In this case, the process is that a field manager can submit a request for a bonus for one of his workers in any amount desired (hence discretionary); an approval request is sent directly via email to the CEO, who can reject, approve, or revise–depending on the CEO’s decision, the workflow may result in an email being sent back to the requesting manager, a pay request being sent to payroll (an automated request, not just an email), or both. This is about as simple a process as they come, and their HRMS vendor eagerly said they could do it. Except for one problem: the CEO isn’t a user of the HRMS system and wasn’t about to become one. The process was automated via BPM (our PAN product, actually) because BPM (PAN’s underlying technology), unlike the HRMS vendor’s application-centric workflow, wasn’t confined to process participants being users of the HRMS system.
BPM is no panacea for HR business processes and workflows; like a boat, it can be a hole in the water you throw money into. Off-the-shelf BPM, for example, doesn’t take into consideration the organizational structure (though in our PAN product, it does). Also, you can’t mention the BPM acronym without also mentioning the SOA acronym shortly thereafter (SOA = Service Oriented Architecture): BPM is in its element as a useful technology when it can utilize the functions (services) of the system it needs to interact with, such as HRMS, but also payroll, recruiting, LMS, IT, and the myriad 3rd party vendors you might need to interact with. Precious few HRMS vendors have architected a SOA-based product, which means BPM is somewhat hamstrung. An answer may be an HR-centric BPM product such as our PAN product (Personnel Action Notices), allowing you to apply a true BPM platform to HR processes in the proper context.
A key objective of both BPM and workflow–if you’ve successfully read between the lines here–is flexibility, or the system’s ability to adapt to your particular business processes. A BPM approach is inherently flexible, but this is not a guarantee with application centric workflows. Given the objective of flexibility, isn’t it curious that a vendor would promote their “120+ out of the box workflows”? How applicable are they off-the-shelf? How easy are they to customize if they need to be adapted to your requirements, as they almost certainly will?
In the next few blogs I’m going to discuss some of these related topics: SOA, Integration, and HR-centric BPM. Stay tuned.