When most Metals and Mining Technology companies are presented with the need for a new software solution - whether it is to replace a legacy application or to fulfill a new need - they seem to go through the selection process with only two alternatives in mind. “Do we choose a shrink wrapped solution?” or “Do we design and develop the software ourselves?” My previous employer was a high volume, low margin automotive industry supplier. Design engineering was something rarely done. Our customers knew what they wanted and how they wanted it made. They usually supplied us the material, the casting, or at least knew which metal and grade they wanted us to use. Software selection at this company was not very complicated; our processes were not complex nor were our development of product.
When I changed jobs eight years ago, however, I joined a metals manufacturing company that could not be more different. Unlike my earlier experience with the automotive supplier, MetalTek International is a low volume manufacturer of highly engineered parts. We often are asked to supply parts that need to perform in very high temperature or harsh corrosive environments for many diverse markets and applications. Very often we produce a single part for a customer every three to five years. This is quite different from the high volume manufacturing from which I came and with which I was so familiar.
" Our client applications pull data from our ERP system and push data into our ERP system. This negates the need for duplicate entry and improves our data integrity and consistency"
I quickly earned that not only were the products and manufacturing processes different between the two companies, the software needs were vastly different as well. I was always leery of using in-house developed software, because it defied the standard which guided me when choosing solutions. That is that the solution had to be supportable, scalable, and repeatable. At smaller to medium size IT departments, software development seemed to be very agile; each developer created applications within their own style and comfort zone. When IT departments would experience employee attrition causing a change on their software development team, inefficiencies arose. The new software developer would have to spend time familiarizing him or herself with the way the application was written and the code that was developed.