Create a free account to continue

Your System Is Not the Boss Of You

Your systems are in place to serve you and your business, not the other way around.

Your systems are in place to serve you and your business, not the other way around.

Imagine that you have just hired a very experienced and skilled expert. You introduce him to your team and set the expectation that this new expert will help you improve your entire team’s performance.

Shortly after you hire the expert, you encounter your first few opportunities to explain how you want him to do certain things in order to facilitate how your team and your business operates. His reply is, “I don’t want to do it that way.”

Your expert continuously makes things difficult and repeatedly does things his own way, which makes life harder, instead of better, for you and your team. What would you do?

  1. Would you make the ultimatum to do things your way or be fired?
  2. Would you make your entire team adapt to doing things the expert’s way even though it’s not the best way?

I hope that most everyone would choose option 1. Even though it can be a little embarrassing to admit that we made a hiring selection mistake, we wouldn’t accept a human employee that resists adapting to our business’s or team’s needs and way of work. We also don’t let curmudgeons stop progress toward business and process improvement as we drive change, just because they don’t want to change. We make them adapt or go away.

Why then do we so readily accept that a system, either a piece of capital equipment, or a software program, or a bygone policy, prevent us from designing our processes the way we know we want or need them to be? Take a look at your own organization. Chances are, somewhere in your environment is a process that is less than optimal because the pain of accepting it is perceived to be less than the pain of changing the hardware or software. It happens everywhere.

From the cold perspective of considering resources, the only difference between people and equipment or software systems is that we don’t have to pay benefits, including unemployment benefits, for our equipment. Therefore, it should be easier, not harder to fire equipment and software for not doing what we need. But we typically don’t.

I ran into two examples just this week. One friend explained to me a conversation in which her organization proposed that Certification and Conformance (an important function at this business to ensure user safety) approval of engineering changes to designs should be awarded before the drawing and design changes were finalized. Apparently, it is too hard to make their software system adapt to the approval occurring afterward.

Fortunately, she vehemently refused the proposal. What guarantee is there that the changes proposed are incorporated precisely and correctly, without error or an innocent, but dangerous alteration to a component call-out or drawing note?

As objective readers, we can see the obvious absurdity of the proposal, but at the time, peering into the face of changing the software system set-up, the team thought the idea was a good one. Watch for this in your own organization. Do like my friend did, and point out when we are allowing our “expert” systems, implemented at great expense for the sole purpose of serving us and making our lives better, dictate to us how things are going to be.

Another friend of mine was lamenting that personnel in his organization were, for a time, recording their work hours in five different locations; not five different categories in five different records, five separate recordings of the exact same time sheet. His organization has successfully eliminated two of them, but has not managed to get the various systems communicating well enough to eliminate two more.

He went on to observe that only minute portions of “hundred-thousand dollar” software packages were utilized because it was too much trouble to make them do what was desired. Most of what they were used to do could be done more effectively with a clipboard and paper, in his opinion. The only reason the software was used at all was because it was so expensive they had to do something with it. Sound familiar?

The above examples both involve expensive enterprise software. It happens with capital equipment on the production line just as often. Sometimes we convince ourselves that a highly versatile, and therefore expensive, piece of capital equipment is our best investment because that one piece of equipment can serve multiple product lines or otherwise perform multiple operations.

Unfortunately, when we buy one piece to do much, because we spend so much for it, we end up using it for many of our production streams and it becomes a bottleneck. We use it because we invested all of our cash on the one expensive machine, and therefore we must. Otherwise, we use it because we spent so much and feel like we need to recoup our investment.

Either way, we are forcing ourselves to use it, even though it may not actually make our production more efficient. Bottlenecks are often a root cause for inefficiency, especially if we need to make set-up changes on the bottlenecks in order to run different products. It can be the root cause for push systems, batch processing, inventory buffers, and many other things that are distinctly not Lean.

What’s worse, because we force ourselves to use these expensive bottleneck machines, we alter our product designs to accommodate the machine. Now, not only are we accepting sub-optimal process design to accommodate our equipment, we are altering our product designs from what might be best, to what we can do with our equipment. We heap sin upon sin and spiral downward to you-know-where.

Remember this. Your systems are in place to serve you and your business, not the other way around. Software can be configured. Machines can be bought, sold, modified, or traded. Policies can be changed. You built your business to serve customers and to make profit for doing so. Such should be the focus of every employee and every system. Your systems work for you!

Be careful with your large investments in systems. Before investing, be sure that you truly know and understand how that investment is going to make life better, and how you will be able to fire that investment if it doesn’t. Don’t make the mistake of thinking that more powerful or versatile is necessarily what you need.

While you consider that, before making further investments, take a look at the processes and systems you have right now. Aggressively attack the nonsense around you of system-convenience dictated processes. Make those systems fit your needs instead. Make it a quest. Let that quest become a cultural behavior. If it does, your organization will be well defended against making the mistake ever again.

Stay wise, friends.

What’s your take? Please feel free to comment below! For more information, please visit Nicol via

More in Software