“Software is a list of instructions that tell a computer what to do” (Wikipedia). Instructions, by their nature, can produce the same result, time and time again and can be performed by many users. Once written, tested, and accepted by a user community, collections of instructions become known as “software”. As software matures and updated versions are released, the instructions become common between each of the major programs. Instructions or commands like “open file”, “print”, or “save” are ubiquitous across applications. Even ERP programs have common commands that create a master data record, record a sale, or post a customer payment to an invoice. All the user needs to be shown is where the commands are in the menu structure, what set of business conditions must exist to use each command, and what results successful and unsuccessful transactions produce. Once a user learns how to perform a command rarely does it change. So why do employers place such a high value on potential employees using a set of repeatable instructions with a known result, over and over again?

One would think an employer lists their job requirements from most important to least important in a job ad. Specific software packages are usually called out at or near the top, along with other skills specific to the employers’ work environment. I see many job postings with requirements of “Must have x years’ experience with [fill in your software tool here]” listed first or near the top of their ad. Why is it skills with a specific software package get top billing? Software is nothing more than a canned set of steps in a specific order yet employers place a premium value for prospective employees to have extensive experience with them. Why is that? Packaged software can be easily learned yet employers insist prospective employees have years of experience with their particular software.

Learning business processes, how they work, how they consume and produce data, and where they receive their input is much more valuable than the ability to execute a canned process in a software package. Understanding, and being able to explain in simple terms, what a stored set of instructions actually does and what it produces are much more valuable skills than remembering the code for a certain transaction. Anyone can push a button, type a transaction, or execute a stored command. The value a potential employee brings is what happens after that button is pushed or the command is executed. What is going on in the background while the computer is churning away, busy completing the task you requested? What happens when you post a customer payment to an invoice? What is the business process effect of executing a command that returns goods to a vendor? And where will the transaction end up in the General Ledger? The Financial Statements? Which business processes will be effected by the command you just ran? Far more importance should be placed on the effects of executing a stored command than remembering the code for a command or where it is in a menu structure.