In today’s competitive business setting, where low prices combined with the highest number of features possible packed in every end user product has reached an unprecedented high, organizations are forced to always perform a thorough ROI, Return on Investment, analysis before any investment. A bad expenditure decision can impact the final price and quality of the company’s product to the end user.
Companies that are in need of a test and measurements system are faced with a formidable challenge; calculate the ROI for a piece of capital equipment. ROI, in its purest concept, is the cross referencing on how the investment gain compares with the cost to implement that investment. In test and measurements, this has many tangible and also intangible components.
Based on the high level definition above, there are two main components that affect the final ROI; investment gain and investment cost. Calculating the investment gain is an involved process that heavily depends on specific aspects of the company looking into building the test system. What this article will focus on is the second component that impacts ROI; the investment cost.
There are two main paths companies that need to implement a test and measurements system take in order to accomplish that: having the internal staff tackling the system or involving a third party company that builds test systems as its main business, a System Integrator company, doing it. There are several reasons why test and measurements fail and also some challenges related to the involvement of System Integration companies as presented and detailed in two of TSXperts’ white papers. Unless the organization has been exposed to those in the past, it will end up finding out about them in the worst possible moment.
Let’s talk a little about the first path above; having the internal staff implementing the system. One very common way managers go about this is by sending engineers to training, so the technology involved in the implementation of the system is learned. Usually, training happens when a problem to be solved is already waiting for the engineer to come back from the training to solve it. Let’s take an example to illustrate this point. Take a case where the organization is in need of a data acquisition system to be implemented. The engineer mentions that National Instruments has the best tools for that type of application. The engineer’s manager then sends the engineer for training in LabVIEW, the software environment that will implement such data acquisition system.
NI’s LabVIEW training is certainly great. It provides a broad spectrum of topics that are involved into learning LabVIEW. However, LabVIEW is a programming language, and as in the case of learning a language, it takes time in practicing the language for one to master it and become truly proficient in it. Sending an engineer to LabVIEW training and expecting this engineer to come back from the training and implement the data acquisition system would be the equivalent of having a person taking a two-week crash course in Mandarin and sending the person to China to close a business deal in the native language.
Common sense says that the best solution for the above would be the hiring of a Mandarin translator. In this case, the two-people team, translator + business man, would have each one aligned with their core expertise. The translator would provide a complete and accurate account of what is being argued back in Mandarin, and the business man would focus on the business deal itself, without the distraction of having to deal with his broken Mandarin.
In the case of the data acquisition system, even though I do believe that training the engineer is the right thing to do, what I am advocating here is that the timeline to when the problem has been defined to the time when it is solved can be shortened if an expert in the field is hired to consult in the early stages of the project.
What usually happens is that the engineer will come back from the training to face the problem with a broad, but yet superficial, knowledge in the technology. Regardless of how bright that individual may be the framework, or architecture, that will serve as the basis for the solution of the problem will probably not be as solid as it would be if an experienced professional in the technology had done it. This will send the engineer on a path where the final product will not be maintainable or expandable. Usually, what ends up happening at that point is that either everything will have to be redone from scratch, or the organization will blame the technology chosen as not the right one for the job. If the latter, the cycle will restart by sending the engineer to another training section for a different technology.
What this article proposes is that, even if the desire is to have internal staff to implement the system, the involvement of a consultant to set up the initial framework shortcuts the implementation timeline; therefore reducing the implementation costs and ultimately, increases the test and measurements ROI.