Aug 2, 2010
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.