The Future Of HRM Software: Naomi’s Preferred Behaviors

Who Can Forget This Teaching Moment? Susan Boyle Sings Out

Having done the first post in this series, on interrogatory configuration, without even realizing that I wanted to do an entire series, I then did a setup post to launch what I hope will be considerable discussion of the desired architectural characteristics (a.k.a. Naomi’s preferred HRMDS platform behaviors) of great HRM software.  No one HRM software package, or even custom application, may need all of these behaviors or need them to the high standard that I’m setting in these posts.  But “if we shoot for the stars, we’ll at least reach the moon,” one of my Mom’s favorite motivational aphorisms.

Preferred Behaviors

Preferred behaviors are the systemic, object model and/or architecturally-produced application software (i.e. platform) capabilities that:

• improve materially the HRMDS cost/quality of service delivery for both the end-user and vendor/provider;
• improve materially the ease/cost/elapsed time of the sales cycle and initial/ongoing implementations, again for both the end-user and the vendor/provider;
• provide substantial agility in the face of new business requirements;
• enhance customer acceptance and usability;
• enable the cost-effective and customer-pleasing use of the software in a variety of deployment business models, from licensing and in-house implementation to SaaS through comprehensive HRM BPO — although I freely admit that my emphasis over the last several years — and some might say my bias — has been on true SaaS and SaaS-based BPO;
• make SaaS and BPO economically viable — I believe that we have passed the tipping point on HRM SaaS for new development (the vendor perspective) and new implementations (the customer perspective), but the very large installed base of older licensed/on-premise (or even hosted “in the cloud”) ERPs/HRMSs will dominate HR/IT spend with maintenance fees for many years;
• can be accomplished via different designs and technology choices, which is why they are presented here with minimal design detail (although I may have an opinion) and no technology preferences;
• are, in many if not most cases, highly interrelated such that they must be addressed in groups;  and
• represent a combination of best practices in software engineering and the software development life cycle, insight gained via modeling the HRM domain and seeing its systemic patterns of complexity that could be addressed architecturally, and lessons learned through my own experiences and those of valued colleagues.

When I’m asked by end-users and vendors/providers what I look for when I’m exploring software, it’s always that combination of a correct object model (for the relevant domain scope that’s being addressed) and these preferred behaviors along with the relevant features/functions.  Just as human beauty is a shallow thing that whithers with age, application software features/functions are the surface beauty that can show up very well in a demo but which don’t necessarily sustain you as your business needs change, markets mature, etc.  Character, on the other hand, is a much deeper quality that ages very well — and such are great architecture and object models. 

In my Preferred Behaviors “Starter Kit,” I include a lot of behavioral scenarios (where Use Cases are much more formally structured and rigorously presented but address the same topics) to provide examples, further clarifications, relevant business situations, etc. that:

• enhance understanding of the preferred behavior;
• begin the discussion of the business value, and therefore the business case, for the preferred behavior;
• link the preferred behavior to the underlying HRM domain model to show where this behavior is needed to IT-enable specific aspects of the domain model;
• link the preferred behavior to more colloquial expressions or understanding of the current state of HRM practice or automation; and/or
• add my personal opinion/point of view/comments to the discussion.

As I write about these preferred behaviors, I’m going to do some companion “killer” scenario posts that provide scenarios you can use to determine how deeply a specific vendor’s architecture addresses the desired behavior as well as, for the vendor community, to provide a basis for determining how deeply you need to do so in order to be competitive.  If you thought I was opinionated before, this series clinches the deal.