Implementing Smart Codes

So you’re going to implement new job codes, or department codes, or whatever.  Someone in the organization has a great idea:  “let’s make the codes smart!”  I mean, what better idea to manage the information within the code than to implant attributes within the code itself.  So you go down the road:  Job category will be digit 1, job family will be digit 2, EEO code will be digit 3, grade will be digit 4.  If you’re on PeopleSoft, I think you only have 6 digits to work with, so 4 is probably a sensible place to stop.

Wait… Perhaps digit 1 was actually the sensible place to stop.

You see, a long time ago, when we were running off of mainframe computers, and we didn’t have a robust job table to work with, it was important to capture all the attributes of the job in the code.  I mean, if you didn’t capture all that information in the code, how were you ever going to get a report on all people performing a finance function?  The only place to store a job attribute would have been the job code.  Think Dewey Decimal System.  Brilliant at the time, but would we really catalog a library that way if we could reconstruct every library in the world simultaneously?  Lucky for us, we don’t have mainframe computers anymore.

You see, today we have what are called relational databases.  They have actually been around for a very long time.  Relational databases allow us to store attributes in tables which have many fields on them.  This lets us actually use these additional fields to select and report on, rather than trying to force a report to sort on Digit 3.

Does it even make sense to include attributes in the code from a definition perspective?  Do all those attributes end up helping us manage the information?  I’m going to argue almost not at all.  There is some benefit to being able to visually recognize that a code is an HR job, but I’m not sure there is much use outside of that.  We need to utilize the table structure for what it was meant to do.

Published by


systematicHR is a daily news and commentary site about HR strategy and technology.

5 thoughts on “Implementing Smart Codes”

  1. Dubs – I would advocate for absolutely NO logic in the codes at all. In my experience, as soon as you think you have the logic figured out, a reorganization happens which defies your logical structure. For example, you start with finance and accounting jobs together all starting with a 3, yet 6 months later the finance department breaks into a finance department and a separate department for accounting. Or, accounting-type jobs get filled in departments other than finance. Needless to say there are countless ways this can backfire.

    By keeping to codes “dumb” you can leverage the meta data associated with each job code to group, sort, classify, etc all you need.

  2. I’m going to go with you on this one as well. Bryon summed it up well – just when you thought you had it all figured out and there is no way that anything could derail your smart codes, you hear the Jaws theme music in the background as the VP of ‘Who’s bright idea was that’ comes along and tells you that they are going to reorganize the company using the height of the executives as the basis for the new structure.

    Pick a number, start there and count up.

  3. Quote: “We need to utilize the table structure for what it was meant to do”
    Only if it adds value to the business. I remember the old job codes and the “position management” from PS, but to be honest, everytime we tried to use it for some kind of business logic, we found that the data quality was not good enough. We ended up using the “product-line” roll-up from PeopleSoft Financials, as it was more reliable. People don’t care much if they are in the wrong job category, but they will be on the horn to you immediately if they are in the wrong cost centre.

  4. @Jacob : If your JobCode associated Grade, Category, or “manager level” drives your incentive, merit, equity, or promotional increase then I bet the data quality of this information will be a lot better.

Comments are closed.