What’s True SaaS And Why The Hell Should Customers Care?

Why Buy The Cow?

When I was barely into my teens, my mother’s (every mother’s of that era) version of the sex talk was captured in this expression: “Why buy the cow when you can get the milk for free?” This was long before birth control pills were invented, years before the “Summer of Love,” and decades before most of you were born, and I’ve often wondered if contemporary Moms still make this pitch.

What was so very insulting when applied to their daughters was central to persuading us that those nasty boys wanted something which, by our controlling the supply, we could trade for the financial security and social position of marriage. Yuck! Just be thankful that those of us in the front lines of women’s liberation did indeed free our younger sisters from being treated to this demeaning crap.

Roll the camera forward about fifty years, and it’s little wonder that I couldn’t stop laughing when I saw this visual for SaaS. The vendors of traditional licensed/on-premise enterprise software succeeded mightily by following in the footsteps of my mother’s advice, and it has provided them with considerable financial security and market position. By not letting you have the milk of enterprise applications unless you were willing to take on the cow of data center ownership and operations, applications management and upgrades, and so much more, the big ERP vendors and many others of that generation have served themselves and their investors very well. But the times they are achangin’.

Enter true SaaS. Why do I call it that? I have long since felt forced to make a distinction between the muddled marketing of everything under the sun as SaaS, faux SaaS, and what I think was always intended by that term because there are huge differences in terms of the business benefits, to both customers and their vendors. So what is true SaaS? In my view, true SaaS must include all of these:

Software is subscribed to customers by the vendor;
Software and data are hosted/operated/managed by the vendor; and — this is critical —
Software architecture is multi-tenant with a single code base and data structures, including metadata structures, shared by all customers — a requirement of true SaaS; and
The vendor pushes out multiple, functionally rich, new releases per year on a mostly opt-in basis.

Well, that’s all very interesting, but why should customers, especially HR leaders, care? What is it about true SaaS that really matters? Before offering a list of those potential benefits, let me note that, just as you can screw up most business as well as technology initiatives, it’s entirely possible to produce true HRM SaaS software that’s unprofitable, unusable, badly architected, built on outdated or just plain wrong object models, etc. — and it’s being done all around us. So I’m going to talk about the potential benefits of true SaaS here with the understanding that these benefits are only realized if the vendor provides half-way decent true SaaS software.

Those potential benefits include:

Improved economics for the vendor — can be passed along to the buyer;
Improved economics for the buyer — SaaS always turns CAPEX into OPEX;
Improved time-to-market, quality-to-market, cost-to-market — innovation and agility matter;
Much more frequent and lower cost/risk upgrades, bringing new capabilities much faster and with much greater adoption;
Value added and/or new offerings via inheritance and aggregation across tenants;
Ability to share a single instance of 3^rd party embedded intelligence by those customers/tenants who select that option, thus reducing greatly the cost/pain of doing so;
Vendor’s ability to focus, via crowd-sourcing, on areas of greatest functional need/interest/ROI, to include transformative ideas in HRM;
Customers’ ability to share best practices, issue resolution, configuration artifacts, etc. with every other customer because whatever one does works with exactly the same software as all other customers; and
Vendor and customer agility, with vendors being able to respond much more quickly to market requirements, to include the pace of change in mobile devices, and customers being able to respond much more quickly to the needs of their businesses.

Are there more potential benefits? I’m sure there are, and it’s early days for realizing all of them. Do the benefits outweigh the risks? Yes, but only when you pick the right vendor/product with which to partner. So how do you recognize the vendors and products which are making these potential benefits a reality? Stay tuned for my next post.

A Bloom’s Christmas: Inventory Management And Retail Retold

A Page From Bloom's Camera 1950 Catalog

On Christmas Eve, my Dad’s retail camera shop closed early, and we knew we’d have him with us all that next day. Really just with us, even if he was too tired for much conversation after working the very long hours of the retail Christmas season. New Year’s Day was for taking inventory, and it was all hands, even my very small hands, to the wheel. But Christmas Eve and Christmas Day were really special. Time alone with my father Jack Bloom, who ran a modest camera shop with his brothers Paul and Herman (who published his “romantic” novels under the name Harmon Bellamy), was rare and precious.

When I was really young, my Dad left for work before dawn and rarely got home before I was put to bed. Friday nights were usually spent having Shabbat dinner, with all my Bloom aunts/uncles/cousins and even great aunts/uncles (those without their own children), at my grandmother’s house. After dinner, Dad went off to Schul with his brothers. On Saturday mornings, we were all off to Schul, but we were orthodox so only my one male first cousin Elliot got to sit with his Dad. The store was open on Saturdays, so my Dad, in spite of the Orthodox prohibition against working on Shabbat, went from Schul to work on many Saturdays, especially if they were short-handed by employee illness or vacations. Summer Sundays were for golf in the mornings and family time in the afternoons, often spent visiting family who lived far away. In those pre-turnpike (yes, before there were highways, there were turnpikes) days, the trip to Hartford, less than thirty miles away, took well over an hour. But on Christmas Eve and Christmas Day, we didn’t go visiting; we stayed home so that Dad could rest, and that meant me sitting beside him as we watched TV (once we had one) or read from the World Book Encyclopedia. My Dad was a great reader, something my sister and I have “inherited” from him.

In the run-up to Christmas, everyone worked long hours, and it was rare to see my Dad during December. My cousin Ronni and I, from about age seven, ran the strange machine in the open mezzanine above the shop floor that took addresses on metal plates and transferred them to labels for the Christmas mailing of catalogues (like the one pictured here) and calendars. Long before it was fashionable for small businesses, Bloom’s Photo Supply was into direct marketing, and we carefully collected the names and addresses of every customer and caller, all of which were entered in the perpetual address files that my Uncle Herman kept.

Sitting in the mezzanine, Ronni and I bickered over whose turn it was to load the metal plate (not fun), load the next item to be addressed (not bad), or turn the wheel (most fun) and discussed what we saw going on all around us. Excess inventory, the bane of every retailer then and now, was a major topic, along with fanciful ways of getting rid of it profitably. While I can never be sure, I think those conversations with Ronni must have been the origin of my now famous story about the invention of Christmas as an inventory management scheme. In that story, the wise men were retail merchants who saw in the humble birth of Mary and Joseph’s son a solution to the already age-old problem faced by retailers everywhere of how to ensure that the year ended without extraneous, highly unprofitable inventory. This is one interpretation of the Christmas story that my Christian Wallace family had never heard until they met me.

By the time we were ten, Christmas season found Ronni and me, the two youngest Bloom cousins, helping behind the counter after school and on weekends, ringing up sales, selling film and other simple products, watching for shop-lifters (you thought that was something new?), recording those sales in the perpetual inventory files kept by my Uncle Herman (there never was nor ever will be again a filer like my Uncle Herman!), and generally learning the business. Everyone worked, including our mothers who were otherwise traditional homemakers, during the month before Christmas, and by Christmas Eve, we were all exhausted. But the lifeblood of retail is the Christmas shopping season — always was so and still is — so our family budget for the next year was written by the ringing of those Christmas cash registers. And I can still hear, ever so faintly, that special ka-ching when I’ve made a big sale.

My Dad was buried on my 50th birthday. My cousin Ronni, just four months younger than me, died in her mid-thirties. Cousin Elliot took over the business from our fathers, built it into something completely non-retail but VERY successful, and sold it many years ago. But if you’re ever in Springfield MA, you can still see the four story mural of long gone camera and photographic supply brands on the exposed wall of Bloom’s Photo Supply’s last retail address, on Worthington Street just up from Main Street.

For me, sitting in my usual place at the keyboard, Christmas Eve will always be special. Years after my Dad retired and I had a business of my own, we talked daily, with me updating him on my business in response to his questions. You can’t fail to hear the ghosts of a retailer’s Christmas past even as my very non-retail business thrived. ”How’s business?” “Business is great.” “Are your clients paying on time? “They sure are, Dad.” “And are their checks clearing the bank?” “Absolutely.” This Christmas Eve, I’d give every one of those checks for another Christmas with my Dad.

Disclosure: If you think you read this last Christmas, you’re quite right. And you may read it again. I learned so much about business through my pores as I worked at Bloom’s Camera (later, Bloom’s Photo Supply and then just Bloom’s, Inc.), lingered at my grandmother’s kitchen table after Friday night Shabbat meals where all the important decisions were made for that business, and was then apprenticed to all the other small businesses run by various non-Bloom relatives. I went on buying trips to New York for the fancy ladies wear shop run by one aunt (they used to model the dresses at high end shops), learned the uniform business from another aunt, and was taught the basics of the Borscht Belt hospitality business by a great cousin. By the time I got to my MBA program, cash flow, supply chain, human resource management and more were already baked into my world view.

Lars From Mars, The Wookey, Carmen Miranda And Me

Island Of Lost Souls -- 1932

When Ron and I moved near DC in 1977, there was a late night TV program, called “Creature Features,” that we loved. It was hosted by Dick Dyszel who, for reasons lost in the mists of marital life, I nicknamed Lars from Mars. Dick played rarely shown early SciFi films, many black and white and loaded with zombies and other scary creatures. A particular favorite of mine was the 1932 Island of Lost Souls (the trailer is here).

Now this host was as much of a draw as the films he played. He was outrageous in many ways, but what always struck me about him was that his movie critiques were VERY astute, very well-informed, very sophisticated. Lars from Mars, as I called him, was one smart cookie, especially when it came to promoting his program. So perhaps that’s why, from my first awareness of Lars Dalgaard and his ambitions for SuccessFactors, I’ve always called him Lars from Mars (not to his face — yet!). I’ve considered him a force with which to be reckoned — and not just in terms of strategic HRM software.

So, when I got the press release around noon on Saturday 12/3 (and notice that I’m not fussing about the intrusion into my weekend), nothing could have made me happier than the ensuing orgy of attention paid to the importance of HR tech in the wake of SAP’s enthusiastic, some even suggested desperate, acquisition of SuccessFactors. The sheer joy of having every major business news writer focused on how HCM “in the cloud” is going to lead SAP to that promised land for the rest of their product portfolio was almost too much to bear. Yes, my friends, HR technology is going to lead SAP to the SaaSy promised land, and Lars is on point to get them there.

Then, just as the excitement over all things HR tech appeared to be dying down, none other than Marc Benioff, CEO of Salesforce.com and the cloudiest of cloud potentates, took us even closer to the pearly gates. Marc declared that not only would HR tech take us to the cloud, but it would socialize us along the way. With his acquisition of Rypple, and putting one of the most well-respected applications development leaders, John Wookey, in charge of a new business unit dedicated to cloudifying and socializing HRM in one fell swoop, Marc reinforced the belief — true of course, but not everyone knew it before 12/3 — that I’ve been living at the center of the known enterprise software universe throughout my career. I may even, as a result of my first payroll programming efforts, now qualify for an IT pioneers badge a la Rypple.

So now I’ve got this movie in my head of The Wookey, Lars from Mars, Carmen (aka Steve) Miranda (Oracle’s Apps leader), “Stan the Man” Swete (Workday’s products and technology leader), Al (aka Mike) Capone (ADP’s products and technology leader), Buck (aka Adam) Rogers (Ultimate’s products and technology leader) and (in my movie, it’s a crowd scene) more, all wearing their Naomi Bloom t-shirts (you know, the ones with my avatar on the front) and doing the HRM SaaS InFullBloom rumba. And now you’ve got my movie in your head!

What Just Happened To The Talent Management Technology Spend?

What Happened To The Rest Of My Pie?

Updated 12-16-2011 after the 12-15-2011 announcement of Salesforce.com’s acquisition of Rypple. If there was any doubt left in your mind that I’ve been working in the hottest, sexiest corner of enterprise software, you’ve been living under a rock. After all, in a world of subscribed software where subscription pricing is most often correlated with “seats,” there’s no group of applications that touches more people, that can be priced with more “seats,” than HRM. We touch absolutely everyone. And in an enterprise software push toward the consumerization of the user experience, nowhere does this create more stickiness at subscription renewal time than when you’ve touched everyone in an organization — and beyond. With Salesforce.com now focused on expanding their product offering into my space, let me welcome Marc Benioff to the neighborhood and wish him well. And please don’t hold your breath on my ever completing a magnum opus on the consolidation in the HRM enterprise software market. If last night’s email/DM/etc. flood is an indicator, there’s no way even my fabulously nimble fingers can keep up with all of this while the rest of me has a life.

I’m still working on my magnum opus (perhaps never to be finished?) post on the SAP/SFSF/Jobs2Web/all things consolidation in the HRM enterprise software market, but one question keeps pushing its way to the surface, demanding a quick post. It’s a much broader question: what just happened to the talent management (TM) technology spend? SFSF faced some impressive headwinds and did the best possible deal — an incredibly good financial deal — before those headwinds were obvious to all. But they’ve been obvious to me for some time — and not just those facing SFSF. One of those headwinds goes like this:

Especially for larger companies with a big investment in their ERP/HRMSs, they’re now getting (something that wasn’t true even a year ag0) a very plausible “stay with your current partner” for TM story. Oracle now has Fusion TM ready to go — lots to build out, but it’s moving — and now SAP has SFSF. With both of these “stay with your current vendor” stories, there are the usual enticements, including (1) fewer vendors with whom to deal, (2) fewer moving parts to integrate, (3) a good bit of the integration, if not done by at least made easier by vendor-provided tools, and (4) “have we got a deal for you” on pricing.
These same companies, if they decide it’s time to “rethink, rip & replace,” also have a new set of options. Workday, for example, is ready to take these folks on with considerable organically built TM and fully integrated, “in the cloud,” partners for the parts of staffing and learning that Workday doesn’t, as of WD15, do.
And, these same larger companies still have the option of staying with their ERP/HRMS vendor and augmenting what that vendor delivers with one to many TM applications, from one to many vendors of same, to include getting several from a so-called talent management suite vendor (knowing that some of those are truly integrated suites and many others are not).

As recently as a year ago, a considerable portion of the total flow of TM software $$ was going to TM software vendors. Now that flow is going to be split among (1) Oracle and SAP pushing their own new TM products into their installed base, (2) more “rethink, rip & replace” deals where there’s a lot of TM functionality and more coming every day from a next generation ERP/HRMS vendor, and (3) those TM single and suite vendors. So while I’m absolutely not a financial analyst, this sure sounds like a smaller proportion of the overall talent management spend will be going in the future to TM vendors than has been going to them over the recent past. If so, wouldn’t you expect those vendors’ revenue growth trajectory to be affected? Their costs of customer acquisition to be higher? The value of these companies as acquisitions or via stock market valuations to be lower?

If I’m right, then there’s another 1+1=3 aspect to the SAP/SFSF deal. But that would also mean that the remaining independent TM vendors will be sharing a smaller piece of the overall pie. Hmmmm..

SAP/SuccessFactors — Help Me Count The HRM Codebases

Shall We Leverage Your Code Or Mine?

[Update 12/5/2011 @ 1:40 PM EST — After an always great conversation this morning with Paul Sparta, Chief Integration Officer at SuccessFactors, here’s his update (as confirmed by Paul) on some of the important product and technology questions arising from the SAP acquisition of SuccessFactors:

1) “SAP and SFSF are committed to providing a high degree of speed and transparency in regard to future product and technology plans post close. The team is hugely excited about the breadth and depth of assets that both parties bring to the table, are committed to bringing a complete suite of applications to the cloud, and recognizes the complexity and effort involved in doing so.”
2) “The team also believes that its go-to-market position today is broadly the best in the industry, despite the broad set of different technologies and delivery models.”
3) “The deal isn’t closed yet, and the companies will operate independently until the deal closes. This is to be expected, so many key decisions will not be made until then.”

Of course, there are many unanswered questions, including the “how”, “what”, and “when” of everything from product roadmaps to go-to-market across all their combined HRM-related products, and those answers are what we really need. But, if you take Lars and team at their word — and we’ll all be watching this closely — those answers, per Paul, will be forthcoming soon in 2012. End Update]

I’m working on a mega-post about the SAP/SuccessFactors deal, but in the meantime I could use your help in making sure I’ve got the full list of HRM-related codebases that must be addressed — strategically and tactically — as a part of this deal. Much of this post is written from (my aging) memory, old notes, and possibly conjecture, and I’m sure it’s flawed. Your help in getting this right and up-to-the-minute would be much appreciated.

So far I’ve counted (but this is based on information gathered after the Plateau acquisition by SFSF but without benefit of knowing what dramatic changes, if any, may have been made by SFSF/Plateau in the last few months):

Plateau LMS on-premise — this is the codebase that was the heritage of Plateau in the LMS business long before it became SaaSy, which it did with an architectural overhaul and adding talent management modules to its LMS prior to its acquisition by SFSF — the generous view (prior to the SAP deal) was that SFSF would support those on-premise customers and this codebase while working hard to migrate as many of them as possible to a SaaS LMS codebase even as some competitors were getting pretty snarky about SFSF’s having lost their SaaSy street cred by doing so.
Plateau’s newer and quite SaaSy integrated talent management with LMS codebase just prior to its acquisition by SFSF — here the general view has been that SFSF stopped all marketing through sales of Plateau’s talent management modules, but I’m not sure for how long SFSF is (or was, before the SAP deal) committed to supporting existing customers (were there any?) who weree using the pre-SFSF acquisition Plateau talent management modules.
Then there’s SFSF’s core, organically grown code base, to include Employee Central (although this may well have been built somewhat separately and it certainly required significant extensions, however underestimated, to the talent management object model) as well as all the talent management modules — all of this is SaaSy but does not have the most modern architecture (e.g. business rules are embedded in procedural logic rather than being entirely abstracted to effective-dated metadata) or object model (e.g. it doesn’t address both job and position as the separate and critical objects that they are), although I suspect that the SFSF/Plateau codebase rationalization efforts (pre-SAP deal) would have been considering how to infuse the best of SFSF’s core with the best of Plateau’s (#2 above) — and now I’ve used that fuse word.
SFSF’s acquired codebases beyond Plateau, which I’m lumping together because, important as they were, they were more add-on or enabling technologies rather than purely HRM functionality codebases — nonetheless, these acquired codebases will need some level of attention post-SAP/SFSF deal closing.
SAP BS7 — this is SAP’s current licensed/on-premise HRMS codebase, with its enormous heritage, breadth of functionality, globalness of business rules/regulatory and compliance support, etc. I can’t imagine that SAP is going to mess with this, having now extended support through 2020, until they’re ready to replace it with their not yet obvious next generation codebase (but more on this in my mega-post which may be like waiting for Godot).
SAP R/3 — SAP made some important changes in its core HRMS object model some years ago, e.g. to handle multiple concurrent positions, as well as incorporated the full NetWeaver underpinnings, which then became part of their BS-sequenced releases, but I believe there are still SAP customers running on various earlier R/3 versions for which SAP provides at least basic regulatory/compliance support and, therefore, which codebase is still being supported.
SAP Career OnDemand — this is reported to have been built on the Business ByDesign architecture but with sufficient use of or similarity to the BS 7 HRM object model to enable an easy attachment of Career OnDemand (and such further OnDemand HRM modules as may have been planned) to BS 7’s HRMS — while I think this codebase will be killed off early days in the rationalization of SAP/SFSF’s HRM codebase assets, there’s a lot of really valuable ideas/learning here that I hope will be conserved.
SAP ByD — last but by no means least, the HRM components of Business ByDesign which, while not ready for enterprise prime time, are nonetheless their own code base which competes, at least spiritually, with SFSF’s modest Employee Central.

With many thanks to http://perro.si/spaghetti-code for the amazing illustration and discussion on his post.

Full disclosure — Neither SAP nor SuccessFactors nor Plateau have been Bloom & Wallace clients over the last many years although I have done work with SAP as recently as Q1/2007.

Eight Characteristics Of Effective HRM And HRM Delivery Systems

In my last post, I told some all too typical business stories in which it was easy to recognize, in situ, really bad HRM policies and practices, HRM service delivery and HR technology use. Every manager has their own favorite such tales of woe, and my HR practitioner colleagues are awash in the fallout from such debacles.

But recognizing what’s wrong won’t make it right. To do that, we must recognized the patterns of great HRM policies and practices, of great HRM organizational design, and of great HRM service delivery and HR technology use. And that’s what I’ve spent much of my career trying to do because, if we can see those patterns, we can deliver them in the most cost-effective as well as business-effective ways. Automating the patterns is what modern software architecture and development are all about.

There are many such patterns that can be teased out of the HRM domain when you apply object modeling techniques to it, and I’ve tried to present as many as possible of those patterns in my licensed HRM domain model/architectural “starter kit.” But for this post I’ve chosen eight patterns which I think bear heavily on delivering effective HRM and thereby delivering great business outcomes. They’re by no means the only possible such patterns, just a few on which I’ve been very focused in 2011 and which I expect will dominate my work in 2012.

(1) Administrative and strategic HRM are inextricably intertwined. It’s simply not possible to deliver effective HRM unless your administrative underpinnings and their more strategic overlay, independent of specific technology choices, are deeply integrated as to processes, data, business rules, user experience, analytics and much more. Therefore, it’s simply not possible to deliver effective HRM unless your HRM delivery system’s core software platform is also deeply integrated. Here are just a few of the reasons:

Administrative and strategic HRM depend on the same global foundation of organizational (job, position, work unit, KSAOC, tasks, work location, legal entity, etc.) and person (position seeker, contractor, employee, community member) data.
Two-way interfaces across disparate data or object structures are costly and fragile to build/maintain — and those interfaces grow in number and complexity as you layer more and more strategic HRM functionality on top of a non-integrated system of record/administrative HRM foundation.
Strategic and administrative HRM processes interact with the same set of users — managers, employees, position seekers, etc. – and those users don’t want to learn (and can no longer be forced to learn) multiple protocols (even with single sign-on and a superficial commonality of the experience), master multiple data vocabularies, or remember what goes on where or how.
The business outcomes of strategic HRM processes are at the mercy of effective administrative HRM processes — mess up the administrative and you’ve sabotaged the strategic. Ever lose a hot applicant prospect because your interview scheduling and communications with that prospect were a mess? Ever watch an entire executive leadership meeting dissolve into a discussion of why last month’s salaried payroll used the wrong incentive pay formula and whether or not and how to do a clawback?
While it’s certainly possible to piece together some level of integration across semantically and architecturally dissimilar applications, great care is needed to understand where only modest and occasional synchronizations are needed, e.g. when calling a background checking application from various staffing processes, versus where real depth and almost real-time integration are needed, e.g. when considering the ripple effects that are an inherent part of succession plan development and execution. And don’t be fooled here by the magic of middleware. Semantically different concepts of data, let alone of objects, cannot be mapped in an automated fashion. Full stop.

(2) Talent management processes are inherently integrated such that changes in any one process produces ripple effects across all the others. It’s simply not possible to manipulate one lever of talent management to achieve improvements in business outcomes without considering and adjusting the others as needed. Therefore, it’s essential to design and deliver talent management processes holistically and with careful attention to their integration of data, analytics, and the user experience. For example, if we pay too much for a hire, we may disrupt pay equity across the organization resulting in more flight risk and/or loss of productivity due to disengagement. If we don’t have the right KSAOCs and overemphasize workforce development, then we may risk missing the performance leverage and insights that can come from excellent outside hires. If our performance processes aren’t tailored properly to our workforce, then the resulting dis-engagement and/or attrition may put pressure not only on our staffing processes but also on our attempts to manage total compensation creep. This is truly a case of the knee bone’s being connected to the thigh bone!

(3) Effective HRM isn’t just about reducing costs/errors/elapsed times; it’s about driving business outcomes. There is no purpose or justification for HRM except to create business value. Therefore, we must be able to make a metrics-based connection between what we do in HRM and the specific business outcomes that are impacted, positively or negatively, by our actions. In this context, embedded analytics are the key to improving HRM decisions and driving business outcomes.

Earlier generations of HRM service delivery, including our early attempts at automation, focused, quite correctly, on doing payroll calculations, compliance reporting, and employee data management correctly, on time, and cost-effectively. With those important but primarily administrative processes long since automated and optimized (or they damn well should be), today’s HRM and the HRM delivery system must be focused on driving business outcomes.

Unfortunately, must of the HRM software still in use was designed (yes, I was there!) when computing power was costly relative to human power, but just the reverse is true today, even with offshore resources. So saving administrative HRM costs isn’t much help when actual workforce labor costs, especially health care costs, continue to rise despite the recession. While it’s always important to think in terms of cost-effectiveness, as well as error and elapsed time improvements for primarily administrative HRM, what really matters, what moves the dial in terms of business outcomes, is everything about strategic HRM.

So let’s not be penny wise and pound foolish. Scarce competencies continue to be scarce despite the recession, and flight risks are growing for the most valuable workers. Since the only sustainable competitive advantages are the capabilities and accomplishments of your workforce, let’s make sure that the bulk of our HRM effort and investment is directed toward those roles and those individuals who drive those business outcomes.

(4) Building, sustaining and deploying professional networks to achieve business outcomes are important workforce KSAOCs, as are the actual networks of workforce members. Many workforce members use their networks routinely in doing the organization’s work, for the organization’s benefit. Therefore, we must support creation, maintenance and deployment of these networks where they are needed KSAOCs even as we protect the organization from the related risks. And lest you think this is a radical idea (separate from the clearly new technologies involved), think again:

We’ve always valued individuals who brought their personal networks to the table — social technology unleashes those networking competencies exponentially, in the right hands.
We’ve always valued individuals who worked collaboratively to make 1 + 1 = 3 — social technology unleashes collaboration across every business, when you have the right HRM policies and processes to nurture/shape collaboration.
But social technology can also become a bottomless pit of self-indulgence, voyeurism, brand damage, IP loss and more — strong HRM policies, training and enabling automated controls are needed to encourage positive uses of social technology and react quickly and severely when a member of the workforce violates organizational policies, e.g. behaves unethically online or in contempt of regulatory requirements which apply to their role.

(5) Work and workers are anywhere, everywhere, and highly mobile — and so must be the delivery of HRM products/services. Mobile communications make it increasingly possible, cost-effective, and essential to weave HRM into the daily lives of workers. Therefore, HRM service delivery must go mobile, not as an afterthought, not as a technical add-on, but rather by rethinking service delivery from both a mobile process effectiveness and business outcomes perspective. And here the lessons of the past can save us a ton of work:

Do you remember when we debated should we or shouldn’t we do self service?
Then we debated to whom should we extend what capabilities behind the firewall?
Then we debated what/how we might consider delivering to laptops when they were roaming outside the firewall?
Now the only question is how fast can we catch up with a world of work gone mobile.
In many developing economies, wired infrastructure, which was the last generation’s online highway, has being skipped entirely in favor of wireless — and many there cannot afford laptops.
Even in the developed world, smart phones and tablets are now the mobile devices of choice for many business transactions, for Web browsing, for content consumption.
Do you know where your workers work? How and when they work? What they’re trying to accomplish?
Do you know how to redesign HRM with mobility first?

(6) To make better HRM decisions, all the relevant business rules, content, guidance, and expertise must be embedded directly into HRM processes. Embedded expertise at “point of sale,” so where/when/how the decision is being made, enables far better and more timely decision-making. Therefore, HRM service delivery must embed sufficient intelligence within the self-service experience to drive business outcomes-based decisions-making throughout the organization. Great examples include:

What interview questions should I ask to reveal needed KSAOCs?
What health care plan should I select to provide the best coverage for my family at the best possible cost?
How might the different members of my team react to limited bonuses?
How should I handle Naomi’s comment about feeling harassed?
What would be my best combination of employees and contractors for this new, perhaps temporary, project? What are the contractual and/or regulatory implications of using contractors?
What types of developmental programs and/or work experiences would produce the maximum global leadership capability improvement in my bench?

For a lot more information on embedded intelligence, please look here.

(7) Beyond embedded intelligence, truly predictive and actionable analytics are needed, again “point of sale,” to ensure that the wisdom of the organization is applied to every business decision. Knowing the probable outcomes of business actions and decisions before making them is the holy grail of driving improved business outcomes. Therefore, HRM service delivery must be able to do the enormously complex calculations in this area of analytics fast enough to present them “point of sale” within the user’s response time expectations. One of the biggest arguments in favor of going in-memory for HRM production data processing is to be able to answer, on the fly, these types of questions:

What are the best predictors of a worker’s performance that we can use during the hiring/contracting process?
Why do some managers produce more results per unit of labor than others? How could we spread the “magic?”
What could we do to reduce workplace absenteeism? What are the characteristics of workers, work schedules, and managers that produce the best results?
What total comp plan designs will produce the maximum behavioral impact for our sales teams?
Which key employees and/or employees in key roles are the greatest flight risks? What would be the impact of losing each/all of them? What could we do to minimize that flight risk, person by person?
Why do some teams function more effectively than others? How could we spread the “magic?”

(8) All business has become global, to include not only global sales and business operations, with their attendant workforce deployments across geographies, but also the requirement that business, product, sales etc. leaders have the competencies to think and operate globally. Where once most businesses were purely domestic in their operations/sales/workforces/regulatory and cultural requirements/etc., businesses of any size now operate more globally. And even when a business is still primarily domestic, everything from its cost of capital and labor costs to its transportation and risk management costs are influenced directly by global events. Therefore, for many to most organizations, HRM data and processes must be truly global along with the related service delivery.

For those of you who operate entirely within one country, you may still be doing business globally without realizing it. A good bit of HRM work has long been outsourced, from background checking and health care claims processing to competency assessment tools development and expatriot compensation, and many to most of those providers have moved as much work as possible to where it can be done at the best combination of cost, quality and risk. But for most organizations of any size, you’re selling outside your home markets; sourcing materials, goods, services and talent internationally; and learning to operate across a wide range of regulatory, cultural and physical borders. And you can’t be successful on the world stage unless your HRM processes and data can travel with you.

The Bottom Line

Have I covered here absolutely everything that goes into creating effective HRM? Absolutely not. Just making sure that the “trains run on time” can consume all the energy that many HR departments have, and when this isn’t done well there’s simply no energy available — or delegation of authority or earned credibility — to do the really important, more strategic parts of HRM. Furthermore, making sure that managers don’t commit any egregious ethical lapses is also paramount. And there are myriad more detailed HRM processes needed to achieve any of the major characteristics of effective HRM noted above. This post was never intended to describe the entire body of work which, taken together, may deliver effective HRM. Rather it was trying to suggest some very specific indicators that effective HRM may be or may not be operational in a given environment.

Clowns To The Left Of Us, Jokers To The Right: It’s Easy To Spot Ineffective HRM

: Clowns To The Left Of Us, Jokers To The Right Of Us…

I’ve been collecting stories for years. Family stories, stories about friends, about trips Ron and I have made, about colleagues and others with whom I’ve crossed paths professionally, about the highlights and lowlights (and lowlives) in my personal and professional lives. Now, with encouragement from the Enterprise Irregulars, who’ve been discussing the power of stories to illuminate, educate, and galvanize an audience to action, I thought I’d take those stories out of my files (don’t you have zillion notes on same that are just waiting to be used?) and turn them into posts. And since I’ve written so much here about dysfunctional HR technology, I thought I’d tell a few tales of dysfunctional HRM.

This is best read while playing this music in the background:

The “how to lose great candidates” story — as a hiring manager, we’re frustrated by our inability to hire a great candidate. Hiring them would require a perfectly reasonable customization of the relevant incentive compensation plan, but someone in the HR department has determined that the needed change would be too difficult to implement because of our antiquated payroll system. Compounding our frustration, we know instinctively how important it is to fill this position as quickly as possible with a well-qualified candidate, but we don’t have the predictive analytics to quantify the negative future business impact of our not being able to do so. Our organization also doesn’t have the data that would have helped us make the business case for getting rid of our antiquated payroll system on the basis of constrained business outcomes rather than often mythical headcount savings. Our organization then adds insult to injury by making it impossible for managers, who are often on the move, to provide the HR executive with quick feedback on the incentive compensation plan issue and their request for an override via a smart phone or tablet.
The “how to hamper new businesses/new markets” story — as an executive, we’re prevented from launching an important new line of business or entering a new market quickly enough to seize the opportunities presented because the available talent management tools aren’t adequate to find already onboard workers with the requisite capabilities. Furthermore, HR’s recruiting team hasn’t maintained an adequate pipeline or effective sourcing networks in advance of our need for these types of scarce KSAOC workers. And if we shake our personal network within the firm to find candidates via phone calls and email in the absence of more social/collaborative tools, we may well violate our organization’s commitment to diversity and equal opportunity because our personal network looks very much like us. But even with those social/ collaboration tools in place, executives on the move must be able to shake their networks whenever, wherever and on whatever device is most convenient for them — and we don’t do mobile except for time recording.
Another “how to lose great candidates” story — as an applicant research scientist or salesperson, who relies heavily on her personal network to source information and connections needed to deliver maximum results, we’re astonished to discover that your organization blocks social technology access to our professional networks for “security reasons.” When we further discover that you don’t support our preferred mobile technology platforms, the ones on which we’ve relied long enough to have built up very productive work habits, we decline to proceed with your interview process because we’re convinced that your HRM policies represent a significant barrier to our effective performance should we be hired. And that’s over and above your having the worst imaginable applicant experience at your Web site, e.g. although you claim to be a globa organization which values diversity, your career site couldn’t imagine someone holding two passports, tried to force mi nombre de Espana into your damn anglo format, and made no provision for my having achieved degrees that have no direct US equivalent.
The “how to ruin a performance review” story — as a supervisor, we’ve found our carefully prepared performance feedback to an employee falling on deaf ears because that employee knew we had not taken into account, for lack of good tracking and sufficiently granular organizational roles data in our system of record, their involvement in and accomplishments on an emergency “fix the roof” project that took time away from their achieving the objectives of their primary position. The review goes from bad to worse when, again because we don’t have the data, business rules and embedded content that would support a better decision, our recommended compensation increase is so out of step with the contributions of this employee that we turn an otherwise engaged worker into a flight risk.
The “how to screw up diversity” story — as an international employee, we’ve wondered why our US-headquartered employer, while espousing the importance of global thinking and the value of diversity, forced us to cram our non-Anglo name into the Anglo format of first name, middle name, last name in all of their systems (yes, we’ve had to enter it seven or eight times for reasons unknown) and used only US-centric cultural examples in their first line supervisor training. With more growth outside the US than within, the impact on business outcomes of losing, either outright or through disengagement, highly qualified international employees is substantial. But that flight risk is compounded, for many countries, when we insist HRM service, delivered now entirely self service, cannot take advantage of that country’s having better wireless than wired broadband connectivity.
The “how to hobble any project” story — as a project team member, we’ve spent precious time tracking down relevant information/expertise across our personal network, the old-fashioned way, with email trails and phone calls, because our employer made it difficult to use social technology to build, sustain and deploy our personal networks in support of our work. When the project is intended to deliver breakthroughs in design, manufacturing, or any other area where it’s clear that the organization doesn’t have a wealth of knowledge and experience, the barriers to this project’s success are compounded when team member access to their external networks is similarly thwarted. But even the best team, which may well include contingent as well as employee workers, many of whom tele-commute, will stumble when their access to essential training on the new tools they’ll be using cannot be delivered except when they are at the office.
The “how to make HR look bad” story — as an HR professional, we’re frustrated at our inability to make the business case for needed investments in everything from improved compensation plan designs to upgrading our HR technology because we don’t know the bottom line impact on business outcomes of past investments in HRM and we can’t predict reliably which HRM investments will produce the biggest future impact on the organization’s business outcomes. There’s nothing more uncomfortable than being grilled by that number savvy CFO whose statistically literate team can link everything done in finance and elsewhere to the organization’s business results, and we can’t provide diddly squat.
The “how to frustrate CEOs” story — as the CEO, we’re overwhelmed with the cost of health care coverage for our workforce, frustrated with our inability to build a sufficiently international management bench to support needed growth in new geographies, alarmed at the lack of statistically relevant analyses linking HRM costs to business outcomes, and fed up with the constant requests from the HR department for new technology investments which don’t appear to do more than address the administrative costs and inconvenience of running the HR department. And our frustration is increased every time we meet with peer CEOs in our industry only to see them tap a few keys on their smart phone or tablet to get today’s status on the filling of key positions, the hours lost to accidents, or the likelihood of the Canadian sales team achieving their sales targets. Enough is enough!

Bloom & Wallace is going through a super painful (not to mention expensive in $$ and near-term lost productivity) rip & replace of long-standing business technology, and my sympathy for others facing such disruption in huge. But there really does come a time when the pressure of what you can’t do easily, of innovation that you can’t seize quickly and cheaply, of applications understood only by folks near retirement (or long since gone), of vendors who have been gobbled up and whose products have languished, znd of so much hobbling technical debt creates a true burning platform business case. Such a business case pushes you forward, and the promise of improved business capabilities pulls you to the future. These and other stories like them, with their impacts quantified, are needed to help you make the business case for your own “crossing of the chasm” when it comes to HR technology. For Bloom & Wallace, the burning platform was our inability to support (really the risks of our not being able to support) the increasingly mobile, global, collaborative and always on expectations of colleagues and friends — and the increased threat of abandonment by our tech support team (aka The Wallace).

Thanks And Giving — Reflections For Thanksgiving 2011

Classic Windowsill Tzedakah Box

It’s that time of year again when American’s reflect on how very fortunate we are to live in this amazing country and on what we can do to make it better. For all the problems we’ve got, and they are daunting, we are so very blessed to be here.

For the past two Thanksgivings, I’ve done a post that focused on counting my own personal blessings, and I plan to do that again. But I’d like to start with the second part of this holiday’s message, the giving part. And I’d like to give credit where it’s due, to a Facebook entry by Ron’s first cousin Barbara Wallace Schmidt of Washington State, for getting me focused on the giving part of this so American holiday.

Having grown up in an orthodox Jewish home (well, modern orthodox), I learned from a very young age that philanthropy (tzedakah) isn’t about extra credit. It’s an obligation. The window sill over our kitchen sink was the home of five or six tin boxes, called pushkas, into which my Dad deposited his pocket change each night after work. Periodically, a representative of one of the charities that distributed these pushkas would stop by to collect them, have a cup of tea and something sweet with the lady of the house, and leave a bright new empty box to be filled up again.

And then there were the naming opportunities. Maybe we Jews didn’t invent this concept, but we sure as hell perfected it. There’s not a tree in Israel or a toilet stall in a Jewish nursing home that doesn’t bear a plaque with the name of the donor whose funds paid for it. With my dimes, brought every week to Sunday school (Hebrew School was on weekdays, and then we wrapped up all that learning plus on Sunday mornings), I must have filled dozens of folded cards with enough slots for two dollars worth of dimes that could then be turned into my very own tree for Israel.

It’s been many years since I saw my Dad empty his pockets into those pushkas and I put my dimes (which I would have preferred to spend on candy) into the “plant a tree” card, but I remember them like they were yesterday. The Hebrew term for philanthropy is tzedakah, literally fairness or justice, and we learned it young and continuously where I grew up.

And lest you think that all philanthropy is equal, Maimonides offers a hierarchy of giving, with the first item listed being the most worthy form, and the last being the least worthy. I find it interesting that the most worthy form is to help a person in need to become not only self-sufficient but also to join the circle of tzedakah in their own right, not unlike the later Christian notion of teaching a man to fish. Translated from Maimonides:

Giving an interest-free loan to a person in need; forming a partnership with a person in need; giving a grant to a person in need; finding a job for a person in need; so long as that loan, grant, partnership, or job results in the person no longer living by relying upon others.
Giving tzedakah anonymously to an unknown recipient via a person (or public fund) which is trustworthy, wise, and can perform acts of tzedakah with your money in a most impeccable fashion.
Giving tzedakah anonymously to a known recipient.
Giving tzedakah publicly to an unknown recipient.
Giving tzedakah before being asked.
Giving adequately after being asked.
Giving willingly, but inadequately.
Giving in sadness (it is thought that Maimonides was referring to giving because of the sad feelings one might have in seeing people in need as opposed to giving because it is a religious obligation; giving out of pity).

I think that this view of giving, of philanthropy, of tzedakah is the flip side of the Jewish notion of success. We believe (at least those of us who haven’t gone so far off the rails as to believe their own press releases — but that’s another story) that your successes are not solely of your own making and that one should not take too much credit for them. As it happens, we are all either blessed or cursed by the good fortune of our birth and by the good fortune, the mazel, that has accompanied our journey through life. Born in the US? Mazel. Born healthy, intelligent, and loved? Mazel. Wanted by two reasonably together and prepared parents? More mazel. Managed to get through school, university, life-to-date without dread diseases, terrible accidents, loss of your freedom or life in civil unrest? Pure mazel.

What you build on top of all that good luck through your own hard work and perseverance is absolutely yours for which to take credit, but it’s important to remember just how much of what we become, of who we are, and of what we have is just plain dumb good luck. Thinking about life this way, as a three-legged stool (the good fortune of our birth, the good fortune of our lives, and what we ourselves accomplish through our own efforts) of which we only control one leg, makes clear why tzedakah is an obligation for those of us whose stools have three good legs.

And now for the thanks part of this post. My list doesn’t change much over time, but my appreciation for these blessings has grown so much over the years. For those of you who haven’t started your list, here’s mine for Thanksgiving 2011:

Ron Wallace — if you haven’t met The Wallace, you’re in for a treat. He’s smart (and never flaunts his far greater intellect than mine), beyond funny (especially when doing those imitations of all the satellite systems he’s helped design), kind to everyone even when they’re not, 150% behind me in everything I do, an enthusiastic dancer, able to design/fix anything electronic/mechanical/plumbing/etc., infinitely patient, very slow to get anywhere close to angry, doesn’t complain no matter how ill/uncomfortable he is, shares my love of travel/adventure/British mystery DVDs/boating/the list of shared interests is very long, understands my need to “fly” solo at times, never asks me what anything costs (knowing I won’t go overboard even when we’re buying me great jewelry), likes many of my friends and is happy to have them travel with us, provides full infrastructure support so that I can pursue my dream career and other interests, still a hunk after all these years (Ron went through college on gymnastics scholarships), and thinks I’m the best thing that ever happened to him. What more could any woman want?
Friends and family who are also friends — I value friendship above diamonds, and those who know me realize that’s high value indeed. No one gets through life unscathed, no one! And it’s your friends who not only share your triumphs but will also see you through the really tough times. You know who you are.
Good health and great health insurance — Ron and I have watched the whole health care reform discussion with just one point of view: everyone should be as free from worry about their health care costs as we have been, even as we’ve battled a number of expensive health issues. I can’t even imagine having to fight with an insurance company in order to get what Ron needed when he was diagnosed a few years back with non-Hodgkins lymphoma. He’s fine now, but the bills were enormous and would have broken even our generous budget if not for great coverage. And I’ve had so many joint repairs that the staff at the surgical center know me on sight, and that’s only the beginning of what aging has done to my lambada. But thanks to Ron’s NASA career, we’ve got the same kind of private insurance our Congressmen have, converted now to our supplemental plan while Medicare is primary. We’d like to see everyone have this level of financial protection and peace of mind, but what do we know about health care? For the record, Medicare is income adjusted so I’m paying a ton for it, and that’s entirely fair.
My career, clients and colleagues — I’ve had an amazing run, and the best is yet to come. Imagine being in on the very ground floor of the use of computers in business and still being able to contribute? For those of you worried about your career, and who isn’t in these trying times, please take heart. There’s always opportunity for those who are willing to work their butts off, invest in their KSAOCs, and do the heavy lifting. To all the colleagues and clients from whom I’ve learned so much, and those yet to come, I’m very grateful for the opportunities and hope I’ve given as good as I’ve gotten. And I’d like to say a special thank you to my much younger colleagues who have welcomed this digital immigrant with open minds.
The accident of birth — I come from pioneer stock. My grandparents were refugees (aren’t all Jews?) from a shtetl in Lithuania. They came to the USA at the turn of the 20th century to avoid conscription into the Czar’s non-kosher army as well as to escape the pogroms. Like every American except our native Americans, we’re all refugees of one sort or another, even those who think they’re special because they came first or brought some wealth with them. Were it not for my grandparents having the courage to leave the familiar behind, to make what was then quite literally a trek across Europe to get bilge (they thought steerage was first class) passage to the USA, to arrive with no English and just the bundles they carried to a gentile America which was still quite hostile to Jews, I would never have had the opportunities that so many of us take for granted. Freedom isn’t free, and democracy isn’t a birthright, so count your blessings that you’re here — and thank those who never rest so that we can.
Our military and their families, our first responders, those who work the midnight shifts in emergency rooms, there are so many who won’t be having as peaceful or comfortable a Thanksgiving as you and I will have. My thanks to every one of them.

Although Thanksgiving isn’t really a religious holiday, I think it’s prayer-worthy. So here’s mine for all of us. Life is short, fragile and amazing; live large. G-d willing (now we’re back to mazel) we’ll live long and prosper and be the life of the party at the old farts home.

The Scourge of HRM Software — Technical Debt

Where Does Technical Design Debt Originate?

I spent a very intense week last July in Silicon Valley meeting mostly full days each with Workday, SuccessFactors, Taleo, Saba and SAP, and would like to start this post with a huge and very public thank you to all of these vendors for their time, their preparations, and their hospitality. I’ve also been doing many vendor briefings and deep product dives this year (see here, here, here and here for those observations) , and those vendors also deserve a big thank you for their time and prep.

But in spite of these previous posts, and perhaps because all we’ve heard this year is debt ceiling, national debt and deficit spending, I’ve been thinking a lot about our own industry’s technical debt. Now it’s time to surface this important and complex issue. And if you think this is only of interest to techies, please think again. What end-users don’t know about what lurks in the corners of their software definitely hurts them.

Technical debt, which comes in both a design and a code flavor, is the build-up of outdated designs, badly written code, object model short-comings (or never-comings for those vendors whose products were designed around either the data models of an earlier era or, heaven-forbid, without formal models at all), architectural flaws, lack of support for newer delivery devices and modes, and more. This is the build-up of flaws or simply outdated work that many to most software vendors accumulate as they progress from initial product concepts through product delivery and, hopefully, through ever more product releases if they are reasonably successful. It’s the sludge at the bottom of your vendor’s software “tank,” and it’s creates a considerable drag on vendor profitability, speed to market for new functionality, operational stability and error-free updates, etc. And buyers are paying for all of this with their licenses/subscriptions/maintenance, not to mention their manual work-arounds, customizations, add-ons, duplicate systems, disengaged workforces, impossible to change business rules, etc.

Great vendors are constantly paying off this debt through ongoing refactoring and redesign of their current software. When needed, and often in parallel, these same great vendors (but they are the minority) completely rethink, re-architect, and rebuild their products, thereby launching their own next generation. But many vendors don’t do nearly enough to pay off this debt. They prefer to invest in new features, new technologies, marketing and sales — in things buyers and investors can see. And who can blame them when many market influencers/analysts, let alone buyers, rarely mention or even understand what’s under the covers.

Eventually, vendors who don’t pay off their technical debt, who don’t pay it down very deliberately and aggressively, build up so much technical debt, especially design debt, that they drown in it. There has almost always been a buyer for these technical debt-laden products/companies, often a buyer that can squeeze a little more return on their bargain price investment and/or one with the capability of rejuvenating the product itself. But even a little such debt can turn a very successful vendor into a vendor of legacy products right before the eyes of their unsuspecting customers.

For customers, the amount of technical debt lurking under the covers of your seemingly shiny new software has a major impact on whether or not you achieve the very benefits for which you’ve committed resources to this vendor and to the implementation of this software. The more debt, the less likely you are to get those benefits now and into the future, and the less likely your vendor partner is to maintain what may be at this point a very successful track record. The accumulation of technical debt is one reason why being a late adopter isn’t always the wisest move because you get all the burden of this debt without having enjoyed the period of innovation before that burden became so great.

Even more important from a customer perspective is the drag on your vendor’s ability to continue to innovate, to deliver promised and much-needed functionality, and to continue to do so at an acceptable price. Technical debt raises vendor costs, reduces quality, and extends time to market to do even simple enhancements. And we all know that today’s business environment requires us to change our HRM practices quickly and with confidence that our HRM software won’t buckle under the load or cause us to spend money we don’t have on those awful workarounds, add-ons, and side systems.

One amazing (at least to me) culprit (but by no means the only one) in the creation of all this HRM software technical design debt is the extent to which that oh so successful PeopleSoft HRMS has influenced a generation (two generations?) of industry architects and business analysts. PeopleSoft was designed for a different era of HRM, for an era in which the contingent workforce wasn’t central to workforce planning and productivity, in which KSAOCs were only marginally understood and KSAOC-centric HRM was in its infancy, in which far fewer organizations were truly global, and the list goes on. PeopleSoft didn’t require the granularity of positions and many to most PeopleSoft implementations relied on an everything but the kitchen sink job code table to drive its business rules. Worse yet, the early design of PeopleSoft drew upon the team’s knowledge of a still earlier era’s mainframe HRMSs, and there was no foundational domain modeling done to rethink HRM in the early days of PeopleSoft. I could add that PeopleCode wasn’t meta-data driven, that it wasn’t effective-dated at its core, and that the North American payroll wasn’t a payroll engine but a very traditional (COBOL?) zero-to-gross and gross-to-net application. And don’t even get me started on external trees to compensate for the lack of a generalized treatment of recursion, e.g. in organizational structures. Shall I go on?

When PeopleSoft came to market, it made its competitors look dated and frumpy, it gave configuration power to HR folks that they’d never had before, and its marketing and sales were superb. But when I see key design principles from PeopleSoft, which should have long since been put out to pasture, perpetuated in shiny new 2011 software, I AM NOT IMPRESSED. So you can imagine my reaction when looking under the covers of various talent management applications this year only to discover that the everything but but the kitchen sink job code structure has been reincarnated more than once without a proper treatment of the essential and entirely separate concept of position, that many of these new applications are not systemically effective-dated (their data may be but the applications themselves are not), that there still isn’t proper handling of the contingent workforce, and that they haven’t really addressed the long understood problem of handling the many recursive objects in our domain with a suitably generalized approach. Arghhhhhhhhhhhhhhhh.

PeopleSoft was in fact a major and important technology upgrade of much older functional thinking, and it was a wild success in an era when everything around it was still tied to the mainframe. That success has continued, and there have been lots of improvements to its design and its code base over the years. But there remain many business analysts in our industry who couldn’t explain the role that job versus position play in the HRM object model and HRM processes to save their lives, and some of this ignorance can be traced to the long influence tail of PeopleSoft. I could go on, but I think you get the picture. And if you’re an HR leader considering the acquisition of new software, the last thing you want is yesteryear’s thinking and design in a new package.

So, no matter how slick a specific vendor’s mobile/social/global/gamified/etc. demo looks, you’d better start poking under the covers to see how much and what kind of technical debt, especially design debt but that code debt matters too, your prospective vendor is dragging around. To detect the presence of potentially harmful technical debt in HRM software, and here I’m speaking of design rather than the coding debt, which is much harder to detect, here are some important and easily observed/ferreted out clues:

Is their so-called modern software built upon a contemporary object model? You should be very afraid if your vendor wouldn’t know an object model if they tripped over one. Just ask them for a high level walk-through of their major HRM object classes and how they are related, making sure that you have someone in the room on your side who really knows object models and, in particular, the HRM object model. If all they can come up with are entity-relationship diagrams and the physical design of their relational database tables, then you may well be looking at very old think software design in a shiny new package. And if they do come up with a great-looking object model, use some of my “killer” scenarios (just search my blog on the phrase “killer” scenarios to find them) to test it.
Is their so-called modern software systemically effective-dated? This is really easy to detect using a good chunk of my “killer” scenarios on this subject.
Are all the business rules that drive their so-called modern software abstracted to effective-dated meta-data (or to effective-dated object attributes and methods which can be manipulated on the fly?)? Can their meta-data be configured non-destructively (so without impacting the push of future releases)? Are there any business rules expressed as application code — a horrible No No in modern software?

Since all vendors who’ve been in business for more than a few years will certainly have some technical debt, not only should you assess the extent of same but you should also pay attention to when/how/at what pace/with what resources/with what executive commitment your vendor is working to retire that debt. Software ages, it really does, and it takes ongoing investment to slow the aging process.

But eventually, no matter how much good work is done to pay down that technical debt, the pace of technology and business change really does force us to stop, take out that “blank sheet of paper,” and make a leap. Some established HRM software vendors may get that done, but most won’t. It’s VERY hard to convince senior management of the necessity and then to sustain their support during the tough years when there’s little to show for that next gen effort. But those established vendors who can take their customers forward, who are willing to bet it all on that next gen and not bury their (and their customer’s) futures in technical design debt (even if the code is new) to maintain “backward compatibility,” are vendors deserving of our collective respect.

For more information on technical debt and related topics, here are two very useful blogs. The wonderful graphic above is from the first of these. http://observationsonerp.blogspot.com/2009/03/hidden-architecture-syndrome-definition.html http://www.andrejkoelewijn.com/wp/2010/11/25/lac2010-technical-debt/

InFullBloom’s 2nd Anniversary — 11/08/2011

InFullBloom Celebrates 2nd Birthday

Who could have guessed, not only that I would have a blog, but also that I would be celebrating its 2nd anniversary and scoping out the topics for year 3? It’s been a wonderful two years, and I can’t thank my readers enough for investing their time with me.

If only blogging (and much of social tech) had been available to me — to all of us — as I migrated from being a physics major to English lit in the early 60’s. Imagine how much easier it would have been to organize those anti-Vietnam protests that really did bring an end to that misguided “police action (did you know that it was never called a war?)? Imagine what I could have tweeted from my jail cell when so many of us were arrested (just overnight, and no record that I know of) for what we thought were entirely legal, non-violent expressions of civil disobedience but which bollixed up traffic, class schedules, and local merchants? Imagine the pictures of me in my hippy prime that would still be circulating on YouTube?

So much has happened in my increasingly intertwined (which is a major byproduct of living your life online) professional and personal lives over the last two years, and I’ve derived great satisfaction from writing about at least some of it here. As I look forward to many more years of blogging (not to mention tweeting, LinkedIning, and living large both IRL as well as online), I thought I’d start my 3rd blog year by reviewing what I wrote at the very beginning — and haven’t changed since: About Naomi Bloom, in which I tell my (probably only of interest to me) life story; and About In Full Bloom, which explains why I’m doing this.

And while it may not seem to be the case for most blogs, I really did lay out a story told in chapters for these first two years. I hope that those of you who are new to my blog will go back to some of those early posts when you have time. To get you started, here’s where it all began:

Drum Roll Please! Da Da Da DAH!

Welcome to InFullBloom. I’ve been agonizing over this initial post for weeks, and I’m still no closer to knowing what to write than when I started. I so wanted to grab everyone’s interest and immediate respect by saying something really profound about improving the practice of HRM, the use of HR technology, achieving organizational outcomes, life, the universe and everything. Perhaps I used up my best opening lines in About In Full Bloom and About Naomi Bloom. In any case, it’s not happening here, so I think I’ll just move on — to my 2nd post.

November 8th, 2009 | Category: Ruminations |

What And Why Are Human Resource Management?

If I’m going to use this blog for its intended purpose, then I’d better get right to work on a core, perhaps the core, issue that lurks, quietly but dangerously, waiting to sabotage our best efforts to achieve improved organizational outcomes through improved workforce performance. The villain of this piece is the sloppy, inconsistent, ill-defined and rampant misuse of terminology.

The English major/natural science minor within me screams every time I hear/read someone who fails to use the subjunctive properly. But my psyche screams even louder when colleagues who should know better use talent management or SaaS to describe whatever ill-conceived idea or product they’ve got on offer this week.

But where to start? The colloquial vocabulary for many to most of the important concepts at the intersection of human resource management (HRM) and information technology (IT) is so imprecise that I could make myself and you totally crazy trying to unravel that muddle. No entirely sane person is going to read the 3,000+ pages it has taken me to do so in my magnum opus, although some of you — and you know who you are — have already done/are doing this.

Perhaps the best place to start, as always, is with the results we’re trying to achieve, working backwards from there to figure what must get done, how, when and by whom, in order to achieve those results. In my professional life, the results we’re trying to achieve are specific organizational outcomes through improved human resource management (HRM). But what is HRM?

HRM is a business domain, a collection of processes and business rules whose purpose is to help ensure long-term business and organizational success. HRM is about planning for, organizing, acquiring, deploying, assessing, rewarding, leading, coaching, supporting, informing, equipping, retaining, and developing a high performance, cost-effective workforce. It is also about nurturing the growth, usage and value of the organization’s intellectual capital and personal networks.

What a mouth full, and there’s more. HRM isn’t just the work of a central/local/3rd party HR department. While an HR department and HR professionals may still control the strategy and design of HRM, HRM execution is increasingly in the hands of managers and leaders at every level and the increasingly technology-enabled, self-sufficient workforce.

The bottom line? The purpose — the expected organizational results — of HRM are to maximize the performance of the organization’s workforce and the leverage from its intellectual capital and personal networks toward achieving the organization’s stated business outcomes. If we could get all of the organization’s work done and results achieved without any workforce, we wouldn’t need HRM. But we can’t, so we do.

November 8th, 2009 | Category: HRM, Vocabulary Shapes Our Thinking

In Full Bloom

About

Post Chronology

InFullBloom Archives

Categories

Selected Publications

Speaking Engagements

Adventures of Bloom & Wallace

Admin

Blogroll