Workforce screening and eligibility determination are also great killer scenarios.
In last month’s column, I said that the potential business benefits from the move to SOA and web services in HRM software and the software platforms of HRM BPO providers would only be realized if SOA and web services are done right. No surprises there. But how are business people, especially HRM leaders, to determine when SOA and/or web services are being done right?
In addition to the postal code structure change scenario discussed last month, this column presents two more scenarios to check for excellent rethinking of the HRM domain via rigorous object models; effective incarnation of those models as web services at the right level of granularity; and robust orchestration and management of those web services via SOA middleware.
Killer Scenario No. 2: Workforce Screening
Most often, workforce screening, including pre-employment and/or periodic criminal, financial, or other suitability background checking, pre-employment and/or periodic drug testing, and a wide variety of fitness for work assessments are performed by a third-party BPO provider. Workforce screening may be invoked within your (ideally) automated staffing processes within the context of a previously established service level agreement with one or more selected providers during:
• Pre-employment evaluation;
• Succession planning and/or the execution of a succession plan;
• When an individual assumes changed/greater responsibilities within the organization;
• When an individual returns from a long leave;
• During an internal investigation; and/or
• On behalf of a supplier’s employee or a potential contingent worker.
The right way for this to be handled with web services and SOA is for there to be a single (properly effective-dated and applicability wrapped) web service that incorporates the logic of invoking workforce screening services, the logic of workforce screening provider selection, and the related service menu presentation. Workforce screening SLA administration to include billing and collection deserves its own web service. Screening invocation should be “called” wherever it’s needed. Discover a new point of invocation and you just insert the necessary “call.” Decide to change the invocation web service to use a different provider and you just change the provider logic in that single web service.
Killer Scenario No. 3: Individual And Group Eligibility
Determining the eligibility of a specific individual and/or work unit to participate in or take advantage of total compensation plans, work environment programs, workforce development programs, and many other types of HRM programs occurs throughout the HRM software that supports these processes. In HRM software that hasn’t been built on solid object models that recognize the universality of eligibility determination, there’s likely to be a separate implementation of the eligibility process every place it pops up. Now imagine what happens when we make a fundamental change in our thinking about eligibility criteria, e.g., to include considerations of protected classes (age, gender, ethnicity, or sign of the Zodiac, all of which are relevant on a global basis) or about who may participate, e.g., to include contingent workers in a project team bonus plan. What you want is a single web service that handles every aspect of eligibility determination, is “called” from everywhere it’s needed (to include across HRM software from various vendors), and is rock solid.
Unlike previous “generations” of technology—e.g., from mainframe to client server to web-based—moving to SOA really does require rethinking/remodeling the underlying problem domains. This has never been done before by any major HRM software vendor on so grand a scale as is needed for effective and efficient web services. There’s bound to be a considerable data migration and process redesign workload to bridge between the older domain models embedded in legacy applications and the shiny new models upon which the best of web services and SOA are being built. From the old-fashioned, callable subroutines of my youth to the best of fully managed web services, the real work has always been in getting the domain models right. But that’s a topic for another column.
