Speaking Engagements UPCOMING
Predict and Prepare sponsored by Workday 12/16
PAST BUT AVAILABLE FOR REPLAY
The Bill Kutik Radio Show® #171, 2/15
The Bill Kutik Radio Show® #160, 8/14
The Bill Kutik Radio Show® #145, 1/14
Workday Predict and Prepare Webinar, 12/10/2013
The Bill Kutik Radio Show® #134, 8/13
CXOTalk: Naomi Bloom, Nenshad Bardoliwalla, and Michael Krigsman, 3/15/2013
Drive Thru HR, 12/17/12
The Bill Kutik Radio Show® #110, 8/12
Webinar Sponsored by Workday: "Follow the Yellow Brick Road to Business Value," 5/3/12 Audio/Whitepaper
Webinar Sponsored by Workday: "Predict and Prepare," 12/7/11
HR Happy Hour - Episode 118 - 'Work and the Future of Work', 9/23/11
The Bill Kutik Radio Show® #87, 9/11
Keynote, Connections Ultimate Partner Forum, 3/9-12/11
"Convergence in Bloom" Webcast and accompanying white paper, sponsored by ADP, 9/21/10
The Bill Kutik Radio Show® #63, 9/10
Keynote for Workforce Management's first ever virtual HR technology conference, 6/8/10
Knowledge Infusion Webinar, 6/3/10
Webinar Sponsored by Workday: "Predict and Prepare," 12/8/09
Webinar Sponsored by Workday: "Preparing to Lead the Recovery," 11/19/09 Audio/Powerpoint
"Enterprise unplugged: Riffing on failure and performance," a Michael Krigsman podcast 11/9/09
The Bill Kutik Radio Show® #39, 10/09
Workday SOR Webinar, 8/25/09
The Bill Kutik Radio Show® #15, 10/08
PAST BUT NO REPLAY AVAILABLE
Keynote, HR Tech Europe, Amsterdam, 10/25-26/12
Master Panel, HR Technology, Chicago, 10/9/012
Keynote, Workforce Magazine HR Tech Week, 6/6/12
Webcast Sponsored by Workday: "Building a Solid Business Case for HR Technology Change," 5/31/12
Keynote, Saba Global Summit, Miami, 3/19-22/12
Workday Rising, Las Vegas, 10/24-27/11
HR Technology, Las Vegas 10/3-5/11
HR Florida, Orlando 8/29-31/11
Boussias Communications HR Effectiveness Forum, Athens, Greece 6/16-17/11
HR Demo Show, Las Vegas 5/24-26/11
Workday Rising, 10/11/10
HRO Summit, 10/22/09
HR Technology, Keynote and Panel, 10/2/09
Adventures of Bloom & Wallace
|
 Mohorovicic Discontinuity -- diagram by USGS, red line added by Geology.com
This is the last, at least for a while, post in a series I’ve been doing that suggest some “killer” scenarios for HR leaders and their teams to use when considering how to design their HRM processes and their HRM delivery system. These are also excellent topics for the scripted scenario demos that I believe are the best way to evaluate HRM software and HRM BPO service offerings. Having now covered some critical object model and architecture-revealing aspects of work and workers, the worker lifecycle, and ongoing organizational complexities, this final post in the series tackles what I call discontinuous organizational changes.
Discontinuous organizational change scenarios are intended to demonstrate how the HRM delivery system, especially its software platform, copes with business-not-as-usual. Even though acquisitions, divestitures, and facility relocations are not that uncommon, each such event is truly a one-of-a-kind organizational change whose characteristics cannot be anticipated fully. With respect to HRM, each of these major changes not only creates the need for organizational design changes, but it ripples throughout the HRM domain model leaving a trail of policy/practice/plan issues and potential changes as well as considerable HRM delivery system impacts. All too often these types of discontinuous changes are an afterthought when considering HRM software or BPO, only to become the oopsy that nearly brings down the house.
This scenario group includes:
- Relocating facilities and equipment, within and across borders which bring changes in regulatory juridictions and, therefore, regulatory requirements;
- Downsizing, which requires workforce reductions, where deciding who to let go involves not only succession planning/execution on steroids but also organizational KSAOC planning and deployment analyses;
- Acquisition of a facility, including initial out-servicing;
- Major regulatory change, e.g. an overhaul of health care or environmental or corporate income taxes;
- New business startup by existing division, including short and long-term facilities planning, with or without opening up a major new geography;
- Startup of a new division with first ever global facilities (i.e. not just sales revenues but actual activities based in several countries) or with first ever facilities in a new country;
- Divestiture, including ongoing HRMDS servicing;
- Outsourcing of major business processes and related staff;
- Labor relations events, e.g. new union start-up, work stoppage, and/or facility closedown;
- Establishment of a partnership or joint venture, with or without ongoing HRMDS servicing;
- Major realignment, within and across divisions; and
- Acquisition, with or without full integration.
Given the move to SaaS and outsourced HRMDS components, be sure to consider these scenarios not only in the evaluation of software platforms but also in your service level agreements, pricing arrangements, and/or any software licenses.
Long before there was COBRA, long before family coverage included adult children, long before graduate school tuition included basic health care, and long before auto insurance provided adequate medical coverage, I had a small fender bender auto accident in Boston, where I was working days and getting my MBA at night. I was between jobs because of a layoff/termination for cause; there was most often cause in those days to avoid unemployment payouts, but I also had the bad habit (for those times ?) of questioning the user rather than just automating in place. When I was refused medical treatment — yes, refused! — I had no choice but to ask my parents for financial help, the first and last time after finishing college, for which I paid most of the bill by running a typing service (another quaint custom of that era was that very few students knew how to type or had a typewriter). My parents lent me the $700 I needed to prepay/as a deposit on some needed tests.
From the comfort of now having the best possible health care coverage via Ron’s NASA career and being able to afford without sacrifice the out-of-pockets, I’m on the healing side of rotator cuff surgery this Christmas weekend. But as the Senate’s health care bill (far from perfect but an important step toward universal coverage) was being denounced as the end of civilization as we know it by legislators and pundits who have NEVER worried about their own health care costs or access or quality, I viewed the debate through the prism of that long ago but never very far away experience of health care rationing (if you can afford it, you get it) and financial ruin. It took me two years to repay my parent’s loan, two years during which I couldn’t have afforded my graduate school tuition without the great good fortune to land a job at Polaroid with its tuition assistance program and working nights/weekends when school was out at the corner gas station.
Do I hate some of the likely final plan’s provisions? Of course I do. Do I recoil at the bribery, yes bribery needed to get Nelson and Lieberman and others on board? Absolutely. But the birth agonies of COBRA, which has saved the health care coverage of so many during this recession, are now long forgotten as are those of every progressive step our country has taken since ending slavery. If I’m fortunate enough to have a Cadillac health care plan, I can certainly give up a little of my peace of mind and pocketbook in order to cover those who have nothing. And if 2010 is a banner earnings year — once I’ve made a full recovery from my recent shoulder surgery — then I can certainly pay a little more in taxes to help those for whom 2010 is just another in a long string of tough years.
I know that we don’t have enough primary care physicians, let alone nurses, to handle millions of newly covered Americans. I know that we’re drowning the next generation in deficits. I know that there are honest insurance and pharmaceutical execs who are being subjected to unpleasant scrutiny. But I also know that it’s long past time for our health care problems to have been solved solely by market forces, and I say bravo to the Democrats for taking the political risk of action rather than giving way to the very loud voices of the status quo.
One of the toughest aspects designing or evaluating HRM software is hoe well it accommodates quite specialized but frequently observed organizational designs that go way beyond the traditional command and control model that’s hard-wired into the designs of many legacy ERPs/HRMSs. Although accommodating newer organizational designs has been a goal of these older platforms, when it wasn’t addressed as part of the underlying design it’s usually handled with various layered-on clunky devices, such as person-to-person and/or organization-to-organization reporting/supervisory tables or trees, which have to be administered/audited/reported on/etc. somewhat separately. Worse yet are the organizational design “enhancements” for positions, created to support an individual holding multiple concurrent positions, which force the use of primary positions in order to sort out benefits administration etc. when, from the perspective of each position’s manager, there is only that position. We won’t even go into the mess that some HRM software makes of project teams, standing committees, matrices, etc. And while your firm may not need all of these organizational designs right now, your HRM software better not run out of steam as your needs change and grow over time. For this post, I’ve focused on those organizational designs that are common to specific industries but appear, under different names and with interesting variations, in many to most industries. This is by no means an exhaustive list so be sure to include any “quirks” from your own industry/organization (or target market if you’re an HRM software vendor).
Bank Tellers (also foundational in Chain Retail/Chain Restaurants/Chain Hotels/Etc.)
In this scenario, an individual employee is working at Bank Branch A in a teller position. She always works in the same teller position at the drive up window because she has specialized KSAOCs that are required for that position. She always works 10:00 AM to 2:00 PM, five days a week, Monday through Friday, because that’s when her branch needs extra staffing at the drive-up window. In order to qualify for full-time benefits, she has a second teller position at a different branch (Branch B) working eight hours, 9:00 to 5:00 on Saturday, and an additional twelve hours scattered through the five days of the week, Monday through Friday, and scattered through the time period from 4:00 PM until 7:00 PM. Again, she is working the drive-up window because she has specialized KSAOCs.
Both bank branches are within the same geographic region, but they could easily be in different states in the US, and are therefore part of the same work unit, even though each branch is a separate work location. However, because Branch A is in a more difficult and dangerous part of the community, work at Branch A qualifies the individual employee for a hazardous duty premium on top of the normal base hourly rate. Teller jobs are classified as subject to FLSA (in the US) and are eligible for a broad range of common health and welfare benefit plans.
This employee started with the company 7/1/1997 as a part-time employee, working in a twenty hour per week teller position at Branch A. On 1/1/1999, she took on the second position (at Branch B) in order to work 40 hours, thereby becoming eligible for full-time benefits. Her position at Branch A has a higher job classification (Teller A) than her position (Teller B) at Branch B. Thus, she is paid at different hourly rates of base pay, at the two branches and, therefore, is entitled to different life insurance limits, etc. A further complication is that, at Branch B, this employee additionally has the role of safety warden on her shift. This adjunct role entails some additional responsibilities, creates eligibility for an additional rate of pay (on a monthly basis) for carrying out those additional responsibilities, and obviously requires additional training.
On April 1, 2009, this bank reorganized itself. These two branches, which had previously been within the same geographically-based retail bank work unit, have now been separated and are in two separate geographically-based retail bank work units. With this reorganization came some additional changes. Branch A has determined that it would be in its interest to have full-time bank tellers. The individual in question has been asked to become a full-time bank teller at Branch A effective 1/1/10. However, Branch B is not interested in losing this very valuable employee and so has offered, also effective 1/1/10, a promotion from an FLSA-rated teller position to a non-FLSA salaried branch manager role.
After some consideration, the employee in question decides that she would prefer to stay a bank teller, accepting a full-time teller position at Branch A, effective January 1, 2010, with an increase to the top step for the job grade of Teller A, plus a bonus based on performance to equal 20% of annual gross, depending on reaching certain performance targets on a quarterly basis. Please note that, for 2009, the gross pay etc. from both positions, paid on different schedules, must be aggregated for tax withholdings so that this employee is not over-withheld.
If you want to spice up this scenario, you might add: (1) having the two chain instances located across country borders and, therefore, subject to entirely different national regulations; (2) having the two chain instances located across state lines in the US and, therefore, subject to entirely different state regulations; (3) having the employee display “grounds for dismissal” but not terribly egregious behavior, such as having an attendance problem, in one position while performing very well in the other and then(4) the same with a truly egregious behavior, … isn’t this fun?
On The Road Sales (also foundational in any road warrior profession, including all forms of consulting/business services, widely-traveling repair/construction workers, sports team members and other entertainers)
This scenario involves a work unit called Eastern Sales Region and a second work unit called Western Sales Region. Eastern Sales Region is headquartered in New York City; the Western Sales Region is headquartered in San Francisco. By headquartered, we mean that the manager position for the sales region is physically located in these designated cities along with the support services for these on-the-road sales teams. However, all of the other positions in these sales regions, positions which are defined according to a single job called “On The Road Sales,” and then further defined in terms of the geographic region in which sales are conducted, have no physical work location other than the relevant employee’s home. They are literally “on the road.”
In addition to working out of their homes (or their car trunks, hotel rooms, or coffee shops) , they do have, of course, electronic addresses, because they have laptop computers and/or smartphones with online access to sales force automation and CRM software and relevant HRM applications, like sales commission calculators and accumulators. On the road sales people, for U.S. tax purposes, have to be taxed according to the rules that apply to both their state of residency and the state in which their salary/commissions were earned.
As of 1/1/2008, each region consisted of 25 sales districts to each of which was assigned a single sales person. On 7/1/2008, the work load was rebalanced. The Eastern Region was redefined to be 35 sales districts; the Western Region was redefined to be 24 sales districts. In the Eastern Region, some of the new sales districts were created by making some of the existing ones smaller. In the Western Region, one of the sales districts was simply moved to the East.
Given these changes, what are the work units and work locations of the sales people over time? How are taxes handled as salespeople roam the countryside? If you want to get a little fancier, (1)implement a sales contest or two; (2) consider having the Western Region spread into Canada and Mexico with their associated sales people being a combination of in-country nationals and cross-border expatriots; and (3) have some of them actually relocate while others live in the US and travel cross border to service their sales regions.
The Professional Services Model
At many professional services firms, only a very small number of job titles are used. These job titles are used (1) to describe very broadly the level of authority that a person with that title has to obligate the firm; (2) to help ensure equity of total compensation approaches across very different combinations of duties and responsibilities; (3) to mark someone’s progression, during their career, in overall responsibility so that people from other parts of the firm can make fairly safe assumptions about their capabilities, expected behavior and maturity when dealing with colleagues whom they don’t know; and (4) to help ensure that clients recognize that leadership roles on engagements or projects, which might be held by very young people, are in fact held by individuals whose job titles (which also imply a level of leadership) have been earned. Because of FLSA requirements and other special situations, members of the support staffs in these organizations often have job titles which describe their work with somewhat greater granularity and a more traditional, positional flavor.
In this type of organizational design, promotion from each title to the next, or hiring someone at a level above entry level, often require the submission of a nomination package and a vote by the relevant senior members of the nominee’s business unit. Equity across such firms is maintained by ensuring that the proportions of each title to the overall workforce stays where they are intended and that equivalent standards for promotion or titled hiring are used across business units. Great attention is paid to avoiding “grade” inflation. Professional services organizations also tend to have very codified procedures for setting performance goals, measuring progress against those goals, establishing career plans, measuring progress against those career plans, etc., but these highly codified procedures depend in the final analysis on the performance of the mentor and/or manager as viewed by his/her peers to influence how the performance measurement of the subordinates is interpreted.
In the professional services environment (consulting, information technology, law, medicine, accounting, and many other fields), the job title describes the employee (or even the vendor employee as with law firms that have partners who are at counsel or teaching hospitals whose residents are not employees in the usual sense) rather than the position. These are job titles in the sense that they form a unifying template over many different types of positions, unifying them not as to similar duties and responsibilities at the detail level but rather as to overall importance and value of contribution to the firm. Furthermore, such organizations usually have two very different types of roles for their professional (translate: directly billable or project) staff — ongoing, persistent organizational positions and constantly changing client project roles.
Roles that are fairly stable over time, as to duties and responsibilities, work unit, and work location, are usually defined as formal positions. For example, the manager/head position of a business unit is usually defined as a specific position for each business unit but with changing incumbents. While it might be the usual practice for the manager/head position of a particular business unit to be filled by someone with a particular job title, it could also be filled by a lower titled person on his/her way up or by a lower titled person in light of some downward movement in the business unit’s importance, complexity, size, etc.
Individuals who are working on one or more client projects also assume project-specific positions for each such project, often having very different positions on multiple, concurrent projects. If we think of those projects as teams, or as project work units, then each project position is really a project-based position whose duties and responsibilities are relevant only to that project and whose incumbent brings to that project role/position whatever job title they carry.
Since one employee (or vendor employee) could carry out the duties and responsibilities of a persistent position while playing several project-specific positions, it’s important to keep track of all of this for labor cost accounting, manpower planning, performance management, finding people with the relevant competencies for the next project, broader workforce planning, etc. Professional services organizations are a very good example of how, in a knowledge-based work environment, people carry out an ever changing set of assignments, only some of which are traditional positions.
My last true employment provides a good example. At one time during my last year at AMS, I was (1) a senior principal by job title; (2) head of the HRMDS Consulting Practice to the Federal Government by persistent position with profit and loss responsibility for the work unit of the same name; (3) the project supervisor for most projects in my consulting practice (but not for all); (4) the direct project manager for one specific, very high level consulting project; (5) an expert resource on two projects outside of my work unit; (6) the project reviewer on another project outside of my work unit; (7) the designated campus recruiter on behalf of the entire firm and under the leadership of the human resources work unit for William and Mary College and Brown University; and (8) a member of the business unit’s (the higher level work unit of which my consulting practice was a part) strategy committee. As you can imagine, I had a very complicated time sheet to complete each month (and we were still doing paper timesheets in 1986).
In this environment, it’s necessary to track hours that are billable to clients by project and perhaps task at a billing rate to that client which was set by the project’s contract and may or may not relate directly to the consultant’s job title. Furthermore, it’s important to know all that the person has accomplished so that career plans for the person, performance plans by project, and overall performance plans for the person can be set and measured. And then there’s the complication of where the work gets done, which sometimes matters only for tax and expense accounting purposes, not for managing the person, but can lead to all kinds of special compensation arrangements, e.g. eligibility for preferred provider rather than HMO health care plans because HMOs are restrictive as to their service areas, TDY (temporary duty elsewhere) payments over and above reimbursed travel and living expenses, and being permitted (or not permitted) to keep frequent flyer miles to purchase leisure travel.
The Health Care Model (This coming together of talent for a one-off project is similiar to the entertainment industry)
Hospitals in the U.S. have fewer actual employees than the number of people who work there. Most doctors are either self-employed or part of professional partnerships or limited liability corporations. When it’s said that a doctor is “on staff” at the hospital, it really means that he fills a position essential to the operation of that hospital, e.g. head of the cardiac unit. When it’s said that a doctor is affiliated with or has privileges with a hospital, it means that he is permitted to practice there, e.g. to deliver babies to his patients at that hospital. Nurses may be employees of the hospital or of an employee leasing firm that caters to the health care industry. It’s very common for a single person, qualified as a nurse, to work at two different facilities within the same health care system. Furthermore, a single person, qualified as a nurse, might work at the same facility but in two different, persistent positions, e.g. operating room nurse for a particular shift and type of surgery as well as emergency room nurse for a different (and non-overlapping) shift. Hospitals must define their roster of required positions depending on case load, type of surgery, etc., then fill those positions with qualified staff, many of whom are independent contractors or work for other organizations (i.e., vendor employees). When my Dad was hospitalized at the end of his life, the doctors on his case were from several different specialities and, therefore, from several different partnerships of doctors, while the nursing staff was a mixture of hospital employees and leased employees, all working different shifts while the doctors made their own schedules. What happens when there are multiple facilities in one healthcare system that happen to cross state lines, as is common in many areas? When you add the full range of health care modalities and related facilities?
The Transportation Industry Model
Imagine airline pilots, truck drivers, train crews, ship crews — all the positions whose duties and responsibilities involve moving or accompanying a vehicle from here to there, with constantly changing work location, routes, cargoes, schedules, etc. In some cases, the people who fill these positions are actual employees, e.g. most airline pilots. In other cases, they are independent contractors, e.g. many truck drivers (who may or may not own the trucks they drive). Train crews are particularly interesting because the individuals may fill different crew positions on different “runs” and even on different portions of the same “run.” I think this is also true for some pilots, who may be captain on a smaller plane and then 2nd pilot on a larger one within the same pay period. Often ship crews, on tankers for example, fill different positions at sea versus when they are in port to unload or load versus when they are in repair dock. While I’m not expert in any of the transportation industries discussed here, I see all sorts of position/job/assignment complications, including all the linkages to work location, work unit and non-HRM constructs. For example, pilots are limited in their number of flight hours, wait hours, on call hours, etc. by the FAA, but the location at which these different types of hours occur is a result of company scheduling.
The bottom line. Because we’re always talking about work and workers in human resource management, we’re talking about the most variable area of any enterprise in terms of trying to pin down all of the relevant scenarios. HRM is such a heavily regulated and contractually obligated domain that we’re never far away, in considering a particular scenario, from those regulatory or contractual requirements. And because of the vagaries of human lifestyles, domestic situations, health, religious practices, cultural expectations, tribal ties, and just the daily ups and downs of human attitudes and behavior, it’s more important in HRM than in most other enterprise domains to allow for the impact of the unexpected, the uncontrollable. Snow storms, power outtages, pickets at the gates, presidential motorcades, subway failures, family illness, and the list goes on of the many factors that can affect, at any moment, the otherwise smooth operations of an organization’s work and workers. Great scenarios attempt to probe how the software or services under consideration would respond to the most likely among these,either for a specific organization or, if you’re the vendor, for your target market.
 Worker bee lifecycle courtesy of www.bumblebee.org/images/lifecycle.jpg
After my initial post on “killer” scenarios, I’ve had a lot of positive feedback (more via email than via comments on the post, so perhaps some of my colleagues are a little reluctant to have their say in public?) on the value of that content and requests for more of the same. No problem. My Scenarios “Starter Kit” is chock a block with possibilities, and my HRM Business Model “Starter Kit” (we’re talking 3,000+ pages) is a scenario (or use case for the modelers among us) collector’s paradise.
These resources, which are intended to work for everyone with careful selection and adaptation, for users and HRM software vendors alike, cover a lot of ground that’s very specific to an HRM process, relevant to a particular industry/market segment, and/or too detailed for inclusion here. So I’ve pulled out — for a series of “killer” scenario posts — some of the most cross-cutting, applicable in most situation scenarios that also happen to be excellent choices for revealing (or suggesting to designers) the strengths and weakness of HRM software object models and architectural foundations. I’ll have a lot more to say about HRM object models and software architecture in 2010, but “killer” scenarios are first up.
In this post, I’ll be covering a wide range of employee lifecycle events with respect to the organization. Many of these, with suitable changes, should also be considered for the vendor employee (aka contingent or contract worker, but always vendor employee in my HRM domain model) lifecycle. As we come out of this recession, we’re already seeing growth in the use of vendor employees, and not just in the US, so every HR organization and HRM software vendor must have a robust approach to managing this large and growing segment of the workforce to the extent that they are applicable within the HRM processes of interest.
For those readers who aren’t HR professionals, this list, which is by no means all-inclusive, should giveyou a sense of the complexity of HRM. Needless to say perhaps, that complexity is exacerbated by the heavy regulatory impact on the business rules, reporting, and processes surrounding the employee and, increasingly, vendor employee lifecycle. And 2010 is going to be a banner year for regulatory activism.
Without further ado, here are just a few of those employee lifecycle events. Always be sure to include errors so that you can see how the underlying software handles errors, corrects them, provides an audit trail, deals with the ripple effects, including any needed retroactive processing, and updates the related reports and analytics:
-
New hire, with and without relocation;
-
New hire fails to report for duty — e.g., in the US, a position seeker with bona fide offer who has accepted verbally or online;
- Employee applies for an open position and is accepted or rejected;
- Employee is “reprimanded” for cause (e.g. put on probation);
- Employee is discovered to have falsified personal data;
- Employee is given a lateral transfer, with and without relocation;
- Employee is laid off, recalled, or granted special recall rights — if you’re unionized, there are many special rules in this area;
- Employee is evaluated and, perhaps, ranked, with and without a development plan;
- Employee fails a post-employment, pre-promotion or required periodic background check, or medical or drug/alcohol screening;
- Incorrect identifying information, e.g. SSN or spelling of last name, has been used to setup employee and must be corrected but with audit trail maintained and ripple effects unscrambled;
- Employee becomes a position seeker by expressing interest in a specific, posted or not posted position.
- Employee develops a competency-centric career plan;13) Employee develops a job-based career plan;
- Employee goes on LOA (consider leaves of absence by type) and does or does not return;
- Employee goes out on short-term disability;
- Employee is given a merit increase within the same position;
- Employee is assigned extra responsibilities as the Floor Safety Coordinator;
- Employee is assigned extra responsibilities as the Floor Safety Coordinator, with or without related compensation, training, equipment, etc.;
- Employee is assigned extra responsibilities as chairperson of the HIT task force, with or without related compensation, training, equipment, etc.;
- Employee works and/or doesn’t work specific hours, with or without changes to his/her “assigned” labor distribution rules;
- Employee takes a course, required (e.g. new supervisor training) or optional, and for each type of delivery method;
- Employee benefits from a salary action (e.g. as a result of a promotion) outside of applicable guidelines/rules;
- Employee is promoted to a newly created position, with or without relocation;
- Employee is identified as a named successor to a specific position under a succession plan for that position, with or within a readiness plan;
- Employee is transferred to an existing position whose incumbent is retiring (but with an overlap for training), with or without relocation;
- A high potential employee is transferred into a previously defined developmental position;
- Late “paperwork” leads to a retroactive merit increase for an employee within same position, with or without intervening, relevant rules changes;
- Employee changes his/her name, address, marital status, etc. — any personal data (which could affect total compensation eligibility or other HRM program participation);
- Employee changes his/her work schedule, employment duration, telecommuting status, etc. — any work circumstances change (which could affect total compensation eligibility or other HRM program participation);
- Employee requests shorter hours and agrees to share position with another employee who prefers a part-time schedule;
- Employee submits a voluntary termination, with or without vesting, with or without rehire eligibility, and with or without termination incentives;
- Employee dies at his desk, during work hours, after hours, or while attending onsite holiday party;
- Employee moves to or from a position that’s hourly/salaried, unionized/non-union, has grandfathered/not grandfathered entitlements, etc.;
- Employee is injured on-the-job, with and without major consequences;
- It’s time to retire — with or without early retirement incentives;
- Annuitant is rehired, with or without affects of early retirement incentives; and
- It’s time to collect your pension, with or without their being any money left to collect!
- Employee, wanting full-time hours, compensation and benefits, accepts two separate part-time positions, within same business unit, in two separate business units, and/or in two separate legal entities under the enterprise (corporate) umbrella;
- Employee, with no change in position, is granted permission to telecommute;
- Employee is suspended or terminated for cause;
- New hire/re-deployment administration, i.e. onboarding, including all linkages to orientation, total compensation enrollment, payroll setup, equipment assignment, provisioning, etc. as well as ny needed offboarding when the movement is internal;
- Termination administration, i.e. offboarding, including voluntary, involuntary, and with and without entitlements;
- Promotion, demotion, lateral transfer, reclassification, LOA, RIF, rehire, reinstatement, acting as, recall, additional duties as assigned, grandfathered, redlined, schedule change (with associated schedule premium change), relocation, … ;
- Every type of legal employment and contractual relationship that is relevant to your organization, including interns, welfare-to-work, when actually employed, rehired annuitants, duties as assigned, not-to-exceed $ or hours, government-subsidized training and/or assignments, on-call, seasonal, internal staffing agencies/pools, etc.;
- Position-sharing, temporary duty station, “acting in role,” etc.;
- Ongoing changes to total compensation plan eligibility, enrollment, use, etc.;
- Relocation management, including the use of specialized total compensation plans, work environment programs, developmental products and events, specialized onboarding and offboarding programs, etc.;
- Mid-period, prospective and retroactive deployment actions and deployment rule changes; and
- What if analyses of prospective and retroactive changes to all the relevant workflows, business rules, process designs, etc.
So you thought I’d never stop? If you’re an HR leader/end-user, please do not pay consultants for what you can get right here. But you will need to learn how to turn these scenario topics into full scenarios and to conduct a full HRM delivery system platform lifecycle, from HRM and HRMDS strategy to platform shortlists/evaluation/selection/implementation, all of which I’m planning to cover in this blog, so please stay tuned.
If you’re an HRM software vendor or outsourcing provider, I sure hope that your platform accommodates quite elegantly (i.e. in a highly automated, easily configured, easily extended by you and completely self service manner — just for starters) as many of these scenarios as are relevant to your process scope. When you brief me on your product/services, these are the kinds of scenarios you can expect me to use to get “under the covers.” And they are indeed “killer.”
 Camp Mar-Lin girls circa 1953 -- can you spot Naomi?
I can tell you a few things about aging. The best way to express my philosophy of aging is through the words of an unknown writer: Life should NOT be a journey to the grave with the intention of arriving safely in an attractive and well preserved body, but rather to skid in sideways, chocolate in one hand, wine in the other, body thoroughly used up, totally worn out and screaming “WOO HOO what a ride!”
If you’re wondering which little girl is Naomi, I’m in the 2nd row, 2nd from the left. If you’ve spotted me, it should be obvious why I didn’t invest my early years in beauty pageants. How well I remember these girls and miss mightily the ones who didn’t make it this far.
Living every day as fully as possible, living large, is how we honor those who, through accident of birth or bad luck along the way, didn’t get the chance. I’ve lost so many friends and family, so many wonderful people with whom I had hoped to share much more of my life, that there’s a little bit of survivor guilt mixed in with the sheer joy of watching each day’s sunrise.
But it hasn’t all been easy. One of the toughest things about aging is that required maintenance increases, if not exponentially then certainly at a quickening pace. I remember when I could leap out of bed, breeze through a shower, and be dressed and out in fifteen minutes. Arthritis has long since ended my leaping, long hot showers have gotten longer because of the relief they bring, and I can’t even remember where I’m going in fifteen minutes, let alone be ready to go there.
I’ll be pretty much offline for a few weeks to do some of that maintenance, not scary, just time-consuming, painful, and expensive. I’m blessed indeed to have great health care coverage and just wish that everyone were as fortunate. If you’ve had a rotator cuff repair, you know what I’m facing. If you haven’t, I wouldn’t wish this on my worst enemy — well, that’s not true, I’d like to see all of the despots, serious criminals, wingnuts, and other undesirables have complete breakdowns of all their rotator cuffs. Perhaps the human race could make some real progress while they were in physical therapy, screaming in pain, rather than doing their day jobs.
If you need to reach me while I’m pretty much offline, or if there’s breaking news I shouldn’t miss because I’m off Twitter, send me an email at naomibloom@mindspring.com. Flowers are always appreciated, but there’s no need to get carried away. I’ve got a few backlogged posts that will show up while I’m “gone,” but who knows if they’ll get tweeted, so please do so if it’s convenient.
One of the biggest challenges in any attempt to apply information technology to the human resource management (HRM) business is that we don’t yet have an industry, geographic and vendor neutral vocabulary for discussing its major concepts, let alone the details. Is my candidate your applicant? Is my contractor your contingent worker? Is my total compensation plan your total rewards program? Where does compensation leave off and benefits begin? And let’s not even get started on how job and position are used and misused within HRM.
Without clear and consistent terms and definitions for HRM concepts, events, data, and processes, as well as their relationships and the relevant metrics, it’s little wonder that the HR community is challenged to discuss process innovation or data analysis let alone to compare HRM software from different vendors. Pieter Brueghel the Elder captures our dilemma perfectly in this famous painting of the Tower of Babel (1563).
If you’ve found yourself on the receiving end of this confusion, let me offer a very simple but hard to execute solution. What’s clearly needed is a domain model, which is a formal description of the HRM domain, complete with clear and consistent terminology and definitions. A domain model describes the domain (the overall subject matter under consideration) from the perspective of the business events that are addressed, the processes that address those business events, the data created by and used by those processes, the relationships among these events, data and processes, and the metrics needed to measure not only activity levels and timings but also the far more important business outcomes. And it does this with the precision and specificity needed to support process innovation, software design through development and implementation, and every form of HRM practice/policy/plan design.
If you come from a software background, you know that I’m talking about the highest levels of a logical HRM object model before all sense of the forest is lost in the trees of decomposition. If you come from an HRM subject matter background, you know that I’m talking about exactly the kind of clarity that you’ve spent your lives trying to achieve just to do a headcount report that knows what kinds of heads to count. And for everyone involved in HRM delivery system planning, design and/or operations, whether in-house or outsourced, I’m talking about the very precise language needed to define service delivery models and service level agreements. Our colleagues in financial management are pretty far along here, which is why you never hear jokes about the CFO who couldn’t explain the difference between an asset and a liability.
In a perfect world, such a domain model, at least at the higher levels of detail, would be developed, vetted and provided “free” to all by a professional association. In that same perfect world, I would be twenty-five again and know what I know now. The really scary thing is that much of today’s HRM software isn’t based on domain object models at all but rather on the much older techniques of separate process and data modeling (we’re talking early 80’s techniques here) or, G-d forbid, no models at all (“we know the domain so well that we’re able to develop our software intuitively!”).
In the early days of packaged HRM software, I advised clients to request the vendor’s data model as the best way to see quickly (long before we could use scenarios to reveal them through a modern UI)the assumptions the vendor was making about the HRM domain and, therefore, to test how good a fit those assumptions would be to the customer’s needs. If there were no person object, there would be no way to distinguish properly between persons who were our employees and those who were non-employee workers. If there were a one-to-one relationship between an employee and a position, then there would be no way to support properly the common practice of having an individual work part-time in each of two part-time positions in order to secure full-time employment and benefits. Those of you who read my post on the work and worker “killer” scenarios and know a little about object modeling will have seen that those scenarios were designed to reveal, among other things, today’s software’s underlying object model through its self service UI.
The bottom line. An HRM software vendor’s domain object model tells you a great deal about that vendor’s understanding of and assumptions about the domain – and here’s the real point – with what cost-effectiveness and speed they’ll be able to meet your needs and support changes to their software over time. Good domain models are a necessary (but not sufficient) condition for good HRM software. HRM software vendors with poor domain object models or worse, no such models, should not be on your shortlist. And if you’re already running such software, you may want to check out my post on planning for its retirement.
 Remember This HRM Software RFP?
In an earlier post, I suggested the use of scripted scenario demos to determine the fit between HRM software and an organization’s needs. But what are scripted scenarios and demos based on them? How do you create effective scenarios? And how do you avoid scenario overkill?
Scripted scenarios are very much like mini-Harvard MBA case studies in which you describe a specific business context, place a business situation within that context, and then ask questions about how the offered software would respond to that business situation. But instead of prospective software vendors submitting written answers to your questions, vendors are required to demonstrate exactly how their software responds. This type of scenario is called a scripted scenario because it provides a script for the vendor’s demonstration, not in terms of the mechanics but in terms of the customer’s view of the requested capabilities.
Think of these scenarios as calling for an automated dialogue between the customer, who might be an employee, contingent worker, manager, HR professional, or any other HRM stakeholder/user, and the vendor’s software. The most effective scenarios are those which not only demonstrate needed user capabilities but also help to differentiate between vendor products. And the secret to avoiding scenario overkill is to know, based upon considerable knowledge of HRM, the HRMDS and the competitive landscape of vendors, what can be safely assumed about vendor products, and what must be tested. For example, if the vendor is a long-established, national payroll software vendor, it’s reasonably safe to assume that their software can calculate accurately most withholding taxes (always being wary of some of the more obscure US local taxes and reciprocity agreements). But if you’re looking at talent management software, where beauty is definitely in the eye of the beholder and there is a rapidly evolving set of customer expectations, you will need to probe deeply to get at the heart of what a vendor can and cannot do.
A scripted scenarios package will be used internally and externally, but with certain details “hidden” in the external presentation. The initial sections are:
- Scenarios context — this is a short writeup describing the organization which will be the context for all of the scenarios which follow. It’s really a mini-version of your real organization provided as a microcosm within which the scenarios make sense. I find that it’s usually easier to write the scenarios first, at least in rough draft, and then collect here all of the facts that you found yourself repeating in more than one scenario as well as all of the other information that an outsider would need to make sense of your scenarios.
- Terms of reference — this is a glossary for terms used in the scenarios, whether industry or organization-specific, for which you’ve developed very precise definitions. What is an employee? A competency? A business unit? A cost center? If you’re using B&W’s HRM Business Model “Starter Kit” or the work of the HR-XML Consortium, you can include the relevant concepts and terminology here. Rather than presume that every reader will understand your terms as you intend them to be used, it’s best to define them here.
Then, for each included scenario, provide the:
- Context — the business context specific to this scenario;
- Scenario — the actual scenario;
- Basic demonstration points — with the expected business value or result by item or group because these are the specific points that the provider must demonstrate credibly to remain in the running;
- Extended demonstration points — with the expected business value or results by item or group because these are the specific points whose demonstration by a provider will help illuminate their competitive advantages;
- Evaluation expectations — this section is to be shared only internally and with evaluators because it describes how you will interpret what you see in the provider’s demo. What are you hoping to see and why? Are there particular architectural behaviors that you’re trying to illuminate? Specific underlying data structures or processes for which you’re looking? And don’t forget response times, elapsed times to closure, and response quality; and
- Evaluation notes — to be completed during evaluations and shared only internally and with evaluators.
Wrapped around your scenario package will be the processes and additional materials you use to identify potential providers, create your short list, orchestrate the scripted scenario demos, orchestrate your evaluation based on those demos, and then proceed through the rest of the vendor evaluation process. Whatever the rest of your software evaluation and “acquisition” process, an excellent scripted scenario package provides a solid foundation for comparing offerings as well as understanding the strengths and limitations of specific offerings. It’s easy to promise results; it’s much harder to demonstrate them.
You can use my “killer” scenarios from this recent post, as well as many more that I’ve written about in articles you can find on this blog and that I’ll be writing about in future posts, to get under the skin of and differentiate among current HRM software products. Always include those HRM business processes, business rules and data which have been a source of unneeded variability, complexity, misinterpretation, administrative effort and/or confusion, high cost, and/or personal frustration. Scripted scenarios should be very specific to your organization and expanded as needed to hit your HRM “hot buttons.” They must also be fleshed out so that evaluators really understand what each scenario means and what you’re expecting to see.
The bottom line. These aren’t easy to write well, and some vendors would much prefer to give you their boilerplate responses to the boilerplate RFPs that outdated consultants continue to favor rather than do the heavy lifting of setting up and demoing your scenarios. But the time you spend putting your scenario package together is time very well spent. Not only will scripted scenario demos help you make more informed package selections but they will also help you understand and plan for the implementation to come. So let’s get started!
Two of my long-standing HRM software architecture preferences have gone mainstream:
- True multi-tenancy, a required foundation for successful HRM SaaS products or BPO platforms; and
- Highly configurable tenants, to include the effective-dating of those configurations, full inheritance across and within tenants, and no disruption of configurations as the vendor applies new releases.
Sounds wonderful, and many HRM software vendors are on this path, as are the BPO providers wise enough to use this type of software for their delivery system platform. But even in configuration, all those available choices have to be analyzed, selected, tested and implemented, individually and in combination with other choices. And this must be done not only during the initial implementation but also every time business needs change, software upgrades are applied (even when applied as SaaS mostly opt-in updates), regulatory rules appear/change including retroactively, new executives bring new perspectives, etc.
Every time those hand-done configurations must be changed, all those choices must be re-evaluated against the needed changes, and then new choices made, tested and implemented. Furthermore, the implications of each configuration change for the downstream processes must be analyzed and actions taken to at least inform users of those implications. So, while we may be able to eliminate most of the programming implementation work by having great configuration tools delivered with our HRM software, we have by no means reduced the business analyst time and expertise needed to keep things running properly. And great, models-based HRM business analysts are really scarce.
This is the business case for automating as completely as possible the configuration of highly configurable, multi-tenant HRM SaaS, to include when used in BPO platforms. It’s the business case for Naomi’s interrogatory configurator, something I’ve been working on for at least ten years and which, thanks to advances in the underlying software development technologies, is getting very close to fruition.
 Studying The Talmud
Interrogatory configuration is easy to explain but VERY difficult to do, at least for complex HRM software. Basically it’s a piece of software which poses questions to the client ‘s business analyst (which could be a 3rd party, including the vendor’s implementation services person), provides a context for those questions along with the implications of selecting from among the available answers (e.g. explaining what types of organizational structures use what types of position to job relationships and why), and then, based on the selections made (and all such are of course effective-dated and subject to inheritance where appropriate), it does the configuration of the base application without manual intervention of any kind.
More Talmudic than Socratic, this question/answer dialogue continues, with each exchange doing one set of configurations while setting up the next set, until the customer has implemented fully the set of capabilities/business rules/coding structures/workflows/etc. that will be their implemented software as of the selected effective date. An interrogatory configurator is designed to work prospectively, so that you can see how a partially to fully configured application will look/behave before committing those configurations to take effect. For those configurations that are permitted to be changed retroactively, with the attendant retroactive processing once they are approved for implementation, the interrogatory configurator is also intended to work retroactively.
Now imagine that the interrogatory configurator is a integral part of the marketing to sales cycle, allowing for a high degree of self-provisioning, at least for less complex organizations (notice I didn’t say small or quote headcounts). And even for the most complex organizations, imagine how much configuration could be done with data gleaned during the sales cycle so that a usefully configured application could become a sales cycle tool which blends seamlessly into the actual implementation once agreements are signed. To the extent that SaaS vendors proceed down this path, the whole dynamic of the sales to implementation processes, not to mention the role, staffing and economics of the systems integrators (SIs), are changed substantially, to the benefit of both the customer and the SaaS vendor.
The bottom line. Reducing dramatically the elapsed time and cost of HRM software sales and implementation is an important enough business outcome for HRM SaaS vendors and BPO providers to justify building interrogatory configurators. Doing this requires underlying software architectures which enable configuration without miles of procedural code. It also requires the product’s designers to know and be able to express the patterns of good practice in a whole range of HRM areas, from organizational designs to hiring practices, and the good practice combinations of same. But haven’t they been saying for years, along with their SIs, that they have the market cornered on “best practices?” If your vendor/provider isn’t working on this, won’t it be awkward for them when their competitors make the leap?
He’s not my type, nor am I his, but I’ve met several Tigers in my forty plus years “on the road.” Early days, while I was still in graduate school and single (yes, I really was young once and quite a hotty), he was a Boston Bruin star. I was working full time days as a programmer trainee at John Hancock Life Insurance and going for my MBA nights at Boston University. With limited time for a social life, why not go for intensity? Picture me in the wives/girlfriends box cramming for my production management exam while keeping one eye on the ice. That relationship was doomed, but it was sure fun while it lasted. Smart, independent, career-oriented, Jewish girls didn’t marry Boston Bruins, at least not in the early 70’s, but then not all relationships have marriage as their goal (or goalie?). 
If I had had nothing more to look forward to than a dead-end job and a short “prime,” I might have seen marriage to my Bruin as a real step up in the world, as did all the other girls (we weren’t called women then) in the wives/girlfriends box. With one eye on the ice, and production management on my brain, I still couldn’t help but overhear those girls talk — and talk they did — about life as a sport star’s girl. Yuck! They might as well have been high priced hookers they way they acknowledged the infidelities, abuses, and generally bad behavior of their beaus/spouses in the same breath as they discussed first class travel and shopping expeditions. I cringed then at the very thought of what these gals were willing to put up with in order to live in the limelight with plenty of spending money, but I’m sure they were equally put off by my life.
I hadn’t thought about that briefest of relationships until the Tiger Woods mess was being discussed among the Enterprise Irregulars. Remember his gorgeous, blond, former bikini model wife? Unless he confesses to goat lust or child abuse or bizarre behavior with his clubs, trophy wife may well not leave given the $$ at stake. If she’s like those hockey wives/girlfriends of so long ago, she knew the life bargain she was making. Tiger didn’t marry her for her education or career accomplishments, and I doubt that she’s entirely surprised by his penchant for gorgeous women. But even trophy children — and his certainly are — have the right to expect their parents to care more about them than about their own careers or comfort. Where’s the communal outrage about the impact that all this nonsense will have on those two little kids?
Of course Tiger’s a $HIT. And if he were my husband I’d have gone after him with a lot more than a putative golf club! But everyone who was involved closely with his career/business, including those who managed his relationships for sponsors, must have known something was up because there are no secrets in our always on/always watching/captured electronically/replayed forever world. As for his privacy rights? He gave up most of those when he invited us to trust his taste in everything from consulting firms to sports drinks. Just like the priest, who’s all about celibacy, denouncing fornication from the rooftops, who gets caught sexually abusing children, you can’t set yourself up as Mr. Clean star athlete and not expect to get hammered when women start coming out of the woodwork with putative evidence that you’re not.
My Bruin was a real gentleman, and I remember him fondly. Fortunately, my life before maturity was not recorded for everyone’s amusement. It was a simpler and much more private time, but I was nonetheless painfully aware even then that the reporters asking me questions about our relationship weren’t interested in anything but selling newspapers. Smut (what a lovely, old-fashioned word) and voyeurism sold as well then as it does today, just through fewer outlets and with no eternal electronic memory, complete with video. The behavior of many of today’s star athletes, really celebrities of all kinds, makes me gag. Worse yet is the behavior of the media and the public who alternate between fawning over folks and being titillated by the details of their bad behavior. All the more reason to support PBS.
 Queen Elizabeth With President Obama
Fooled ya. This isn’t about me but about your HRMS — my own retirement planning will be addressed in a future post, dated sometime after the 2nd coming.
With a new generation of ERP/HRMS in release or coming next year, a reasonable question is when and how to plan for the retirement of your backbone HRMS, of your official system of record? The fact that software graveyards exist and, to some extent, prosper on the maintenance revenues rather than from doing new licenses of long-outdated business applications demonstrates that many firms are still running on HRMS’ whose architectures are several generations behind the current state. But this wouldn’t be a very useful post if I focused solely on retirement planning for the true antiques, for those brands that are so far past their shelf life that they’re only of interest to software historians and a few old industry watchers like me. No indeed.
Instead I’d like to address that much larger group of organizations running current or close to current releases of PeopleSoft, Oracle EBS, SAP ERP, Lawson, and many other still selling HRMSs whose owners have already or will soon announce/release their next generation products. The reality is that any HRMS vendor which intends to keep selling/subscribing their software is being forced to re-architect their products for a world of Web services, SOA, SaaS, models-based development, embedded intelligence and complete self service etc. on the technology side and for a world of free agency, workforce rather than employee management, total compensation, KSAOC-based and integrated strategic HRM, and dynamic and concurrent organizational designs etc. on the business side. And whether you’re accessing these soon to be obsolete HRMSs via your own license and in-house or hosted deployment or you think you’re out from under these concerns because you’ve convinced a BPO provide to “run your mess for less,” there’s no place to hide from retirement planning.
Let me use PeopleSoft as an example. There’s no secret about Oracle’s plans to release a complete Fusion HRMS some day, but there’s still limited public information about the architecture, data model, or delivery dates for this next generation HRMS. What we do know or can surmise is that it will NOT have exactly the same data design as PeopleSoft, let alone the same architecture. We can be fairly certain that PeopleCode won’t be reincarnated in Fusion. There will certainly be some features in Fusion that are familiar to PeopleSoft customers, and Oracle will make a sizeable investment in migration/implementation tools, but I’m prepared to bet my professional dignity that every current PeopleSoft HRMS customer that decides to go with Fusion HRMS will be facing a completely new implementation. Such is life.
Have you written any PeopleCode, and who hasn’t? At a minimum, you’ll have to decide how to reincarnate that functionality in Fusion, using newly delivered functionality or creating Fusion-based add-ons. Have you added any customer-defined data fields, and again who hasn’t? These too will have to be reincarnated in Fusion, whether using delivered functionality or creating a new set of Fusion add-ons. And what about all of your historical data? Will you migrate it into the very different data design of Fusion or keep it locked up and accessible only via some frozen version of PeopleSoft? What about those dozens of outbound and inbound “interfaces” that you’ll be moving to Web services strung together in real time? Those important analyses which will have to be redesigned around a new object model? And did I mention a completely new user experience into which you’ll have to embed all those edits, content, guidance, etc. that you’ve embedded in your current user experience? These and many more questions will need to be answered as Fusion’s HRMS design reveals itself, for those PeopleSoft customers who expect to migrate eventually to Fusion, and for each of these your retirement planning initiative must find answers.
In my view, it would be very naive to believe that answering these questions is no different than planning for the next release of PeopleSoft. Either Fusion will be a major leap forward and, therefore, not be upwardly compatible, or it will be a failure, and what we have seen thus far does not look like a failure. More importantly, when faced with what I believe will be a major body of implementation work to get from PeopleSoft to Fusion, much more work than doing a “routine” PeopleSoft upgrade, you’d best consider whether or not there are other, better options before your CFO or CIO wonders why you didn’t.
The bottom line. The new generation of HRMSs are as fundamentally different from the last generation as that last generation was from the classic HRMSs of yesteryear, and no one would suggest for a moment that going from Tesseract to Oracle EBS or to SAP ERP was a walk in the park. Fusion is coming, and it looks to me like a terrific time for all those PeopleSoft customers to plan a retirement party or wake, depending on your point of view.
|
|