Do you have organization codes (org codes) where you work? Have you dealt with clients who have org codes? If so, this article is for you. If not, this article probably won't be too relevant, although you might find certain parts useful.
Internal software (both systems and applications) can help a business run like a brand new Mercedes-Benz S Class or make it run like a Ford Pinto with square wheels. Make no mistake, this analogy is meant to parallel both the incredible pleasure of a well thought out, smooth ride and the impending doom of the Ford Pinto fuel tank while thudding along a terrible ride.
A well-planned internal software landscape can make the daily workings of employees frictionless. Ideally, employees shouldn't even really consciously notice the software they use to get their jobs done because they're "just a part of the day". Like a comfortable pair of shoes, you forget you're wearing them throughout the day. An invisible toolset that just does what it does. Compare this to uncomfortable shoes or shoes that have a rock in them. These shoes are an incredibly distracting and noticeable toolset that a person would work to avoid, or constantly (and rightfully) complain about.
So what do org codes have to do with all of this? We've recognized a trend in internal software that is negatively impacting both the developers who build and maintain them and the users who are forced to use them. Both in the overall naming and functionality of software, org codes are statically built-in!
Notice we said statically built-in. The reason for this is that certain functionality needed in internal software should contain dynamic org code data ideally synced from a "source of truth" in which that data is its primary function. But that's not what we're talking about here.
We're talking about not naming that shared drive/managed folder/SharePoint document library after your spaghetti lettered org code or even what that org code acronym stands for. We're talking about not naming that new internal tool you built "Industrial Infrastructure Group Sales Navigator".
 This is an organization from Mitsubishi Corporation (which we have no affiliation or relationship with). Mitsubishi Corporation publishes their top level organizational structure on their site. https://www.mitsubishicorp.com/jp/en/about/profile/
Running an effective project requires the need for forward thinking without sacrificing too much development time and budget. Naming your internal software in a way that will withstand future changes is free to plan and very expensive if you do it wrong.
- New employees, contractors, and customers will be misled by legacy naming conventions
- When org codes change, executives and managers will request rebranding and renaming (which will require no less than 3 months of meetings and design changes)
- The need to rebrand sprouts new challenges that cost time and money to overcome and usually detract from actual development of the internal software
- Even if you're not too deep in the organizational structure, saying the org code every time the system, site, or application is mentioned is a boring mouthful
Why Do Org Codes Change?
There are also many reasons why org codes change. These changes happen much more often than expected. Our team members have worked at companies where they experienced org codes being changed every 3 years.
- Your company could buy another company and merge divisions, business units, and team (while changing their name and org codes)
- Your company could be bought out by the company above and you would be impacted the same way
- A new executive comes in and wants to make an immediate impact via "restructuring"
- Rebranding of functions and services (especially if your org codes are externally available to customers)
Some Other Considerations
In this blog post we've mostly been focusing on not using org codes in the names of systems, sites, applications, shared folders, etc. This can and usually should be expanded to the full names of the organizations those org codes represent. Our belief and experience is that no matter how long-running a government organization, private company, or industry has used certain branding and vocabulary, it will eventually change. It is our opinion that it is therefore better to create naming conventions that pertain to the general function of the tool or are completely unrelated as these will be more immune to organizational name changes, overall reducing the future headache of renaming misleading titles.
Do you agree or disagree?
We're experts in business automation. If you'd like to reduce the hours of monotonous work you do every day so you can get on to more important projects and learn new skills, reach out to us here.