Standardization—what does it really mean? (Guest Commentary)

Editor's note: This article is part 2 in a series on Engineering
a Competitive Test Strategy. See part 1, "Do
you know your true cost of test?" Part 3, "How do you treat test
like a product?" will follow next month.

Standardization is an interesting term in the test and
measurement industry and other related high-tech fields involving major
hardware and software investments. Standardization by definition refers to
bringing something into conformity with a standard. Standards are loved and
cursed by engineers who by the nature of their profession seek innovative
solutions using the latest technology, which may or may not fall within the
realm of conformity. Without standards, however, we would have a very difficult
time communicating our findings with other engineers in measures and terms that
are globally understood. Standards also help ensure the ideal end-user
experience of interoperability and quality that consumers of our engineering
breakthroughs come to expect. In the simplest of terms, standardization of
test-and-measurement systems often brings about a mixed reaction and varied
support by management and engineers because of its potential impact on the
business and engineering projects. The focus of this article is to dissect the
polarizing topic of standardization and how to determine whether elements of
standardization may be a benefit to your organization. It will also discuss
best practices for determining the right standard components for your
organization.

Standardization done properly can have a significant impact
on the efficiency and cost of test. Some organizations, such as Hella KGaA
Hueck & Co (www.hella.com), an
automotive electronics supplier, view their test-system standardization as a
competitive advantage across all elements of their business, including
development, deployment, and operations. Approaching the topic of
standardization should be done carefully since it is as much, if not more,
about the business, people, and process elements of achieving it as it is about
the technical solution. Thus, ensuring you address each of these elements as a
part of your plan is critical.

The first step to standardization is determining whether it
will benefit your organization. Standardization is most often used to control
growing costs or time to market related to having numerous sites, product
lines, or programs, for which organizations typically develop independent test
solutions for each. These independent efforts often result in compounding
development, deployment, and operations and maintenance budgets and resources
in the validation and manufacturing test areas of a business. In cases such as
these, standardization is a highly effective tool for increasing development
reuse, streamlining test system deployment, and reducing operating costs and
downtime.

Once it has been determined that standardization could
benefit your organization, it is important to scope out the focus of the
standardization effort on the specific areas of greatest benefit. Some
companies in the past have repeatedly struggled in their standardization
efforts because they tried to standardize everything down to the coversheets on
the TPS reports. This is what most engineers despiseâ€”standardization for the sake of standardization. Instead, identify
which of the three vectors of standardization would be most valuable for your
organization: validation to manufacturing, local to global deployment, or
product-to-product lines. In some instances your organization may benefit from
a combination of these focus areas; however, be careful to avoid taking on too
much complexity by trying to solve everything at once.

Embarking on a standardization effort to achieve the
aforementioned gains requires a significant investment of time and resources.
Be sure you take the time to get proper buy-in from all of the necessary groups
that will need to support your efforts. This includes your manager and
representatives from other groups, sites and divisions, as well as business
management who will ultimately provide the budget and dedicate resources for
the standardization effort. While it is tempting to dive right into the details
of finding a technical solution that will satisfy the needs of each group, the
step of ensuring proper alignment across all elements of the business cannot be
understated in terms of importance. Many engineering teams have spent hundreds
of man-hours hashing out technical specs for a standardization only to forfeit
their time and efforts due to misalignment on the standardization at the business
level. A great way to help ensure business alignment is to find a sponsor at a
director or officer level within your organization. Such sponsors can help
champion the effort amongst their peers and also help reinforce measurable
outcomes, deadlines, and ultimately consensus amongst the different groups.

When you are ready to take the first steps towards
identifying a standard test software and hardware platform for your
organization you should look to identify a project manager with strong
cross-group leadership skills. You will also want to identify working groups
for the key software, hardware, and services elements of your common core test
standardization. The working groups should consist of a reasonable number of
representatives from each key stakeholder in the standardization, whether it is
across product lines, sites, or teams in the design flow. Remember to devote
time in selecting members of the working groups since they will be taking on
the lion's share of the work in identifying the right architecture and
technologies for your standardization. Be sure you also set clear expectations
on the amount of time that will be required from them (typically, up to 50%
percent for a six- to 12-month period).

Once the core working groups begin their work, it is
important to keep in mind the personal attachment each of the engineering
owners throughout your organization has for its solutions and tools to solve
its existing test application problems. Important consideration should be given
to thoroughly understand and compare best practices for solving common test
challenges by reviewing internal and external best practices and tools. One
technique used successfully for identifying a common hardware I/O platform is
to ask each of the groups to specify its measurement needs instead of its
instrumentation needs. This helps constructively analyze the measurement needs
across your organization instead of surveying everyone's list of preferred
instruments in which it is typically impossible to find a common denominator.
Another lesson learned in the standardization process is taken from old words
of wisdom in which you are reminded to pick your battles carefully. Know which
elements of your standardization effort are critical to its success and which
ones you can concede if needed to maintain alignment and buy-in towards the
overall process. This advice can be especially helpful when discussing the
programming software for your standardization, which can tend to be a religious
debate among most engineers. Many of the successful standardization efforts
look for objective side-by-side comparisons, or perform their own trade studies
on internal and external tools to encourage the objective, non-biased
consideration of the right tools for the standard.

As mentioned, developing a common standardized test
architecture and tool chain is not a trivial task. However, it can yield a high
ROI, if done properly, and ultimately lead to a significant competitive
advantage in terms of cost savings and time to market. It also benefits the
engineers using the standard by allowing them to focus on new problems to solve
instead of repeatedly solving problems that others in their organization have
proven solutions for. The process of choosing a standard test platform is
complex, and there are proven best practices that can save you countless hours
and significantly improve your success. The points highlighted in this article
will take you a long way towards this success. The rest is up to you to use
your engineering and business knowledge to successfully navigate the people,
process, and technology elements that can often only be taught as you are going
through the journey.