Automation products improve with customer feedback
Improved product automation is a result of customer feedback. As customers give suppliers valuable product feedback, suppliers will consider many factors that may result in a new feature being added to an existing product or launch a new product to provide a solution.
If you use automation products, then you've most likely had instances where you wanted a supplier to add new features or fix a problem with the product. Customer feedback can help customers feel as if issues are heard, can be resolved, and requests are fulfilled.
Below are best practices for gathering information from customers by field sales engineers, distributors, and product managers. Input can be taken from sales calls or from product engineers when they get similar change requests in a short period of time. More requests increase the likelihood the feature should be incorporated.
Software versus hardware issues
Feedback can be divided into two areas—hardware and software. Requests for improvements can be related to either area, although issues to software-related issues are more prevalent. Software issues are the quickest and easiest to address. The severity of the bug will determine how it is handled. If the bug is minor, it will be corrected as part of the next scheduled upgrade of the programming software. If the bug is more serious and inhibits a customer's use of the product, a beta release of the corrected software is provided to the customer so the customer can test the fix.
Software feature requests are regularly reviewed, prioritized, and sent to a product development team. The complexity of the request and its overall priority determine how long it will take to be implemented. High priority requests may have a turnaround time of just a few weeks.
Software improvement solutions use cases
Consider an original equipment manufacturer (OEM) that uses programmable logic controllers (PLCs). The OEM wanted a network protocol for communicating with loop controllers.
At that time, the cost of adding a protocol converter to allow this PLC model to communicate with the new protocol was out of the question for the customer, and writing ASCII strings for communication with each loop controller wasn't acceptable. The PLC manufacturer's development team investigated the possibility of adding the new network to the PLC as an optional communication protocol in the programming software and determined that it was feasible.
Once the development team created this solution, the OEM ordered PLCs with a custom part number which included this network communication capabilities. In the next generation of PLCs, that network became a standard protocol built in to all PLCs offered (see Figure 1).
As another example, an OEM customer worked with the data logging function on a human-machine interface (HMI), the company realized that it needed more precision in its data saves than what the software allowed. The HMI manufacturer discussed the customer's request with the development team and decided to address the customer's needs in the next version of the software.
In regards to next-generation product improvements, here are two examples. Many PLCs have Web server capability built in. Customers use specific strings to create Web pages with numerical displays, bar graphs, trend charts, buttons, and other graphics. These Web pages are then available for viewing by utilizing any Web browser.
However, many customers requested an easier alternative to create custom Web pages. Based on feedback, PLC programming software is available that has a built-in Web page editor that enables users to create elaborate Web pages using a drag-and-drop method as shown in Figure 2.
In prior years, only a few micro PLCs supported email functions using third-party email servers. However, over the years, e-mail servers were upgraded with more encryption, which no longer allowed micro PLCs to support third-party email servers. PLC manufacturers now have built-in support for third-party e-mail servers, an upgrade requiring a combination of hardware and software changes (see Figure 3). Software bugs are addressed quickly, however adding software features takes a little longer. Hardware improvements are more difficult, as they cost more and must therefore be considered very carefully. [subhead]
Complex hardware issues
Most hardware issues are requests for new features and other improvements, however all requests can't be fulfilled. In order to determine which improvements are implemented in the next generation of a product, the number of customers requesting the same change is taken into consideration. If more than a few customers are requesting the same change, the issue will be considered through research and its feasibility.
First, it must be determined if there are enough requests to move forward with a product's development. This requires visiting customers to collect more detailed information including why new features need to be added to the product or why a new product is needed at all. Since hardware product development is costly, suppliers must not only know what the customer needs now, but what will be needed in the future.
This customer feedback helps determine if the request should be an improvement to an existing product or a requirement for a new product. It also helps suppliers determine if they are making the right improvement or building the right product. Building a product based just on one customer's request isn't always the right path, as it might be very specific for a particular application without widespread applicability to other customers.
After gathering feedback from multiple customers requesting the same hardware improvements, automation suppliers must determine if the improvement:
- Is technically viable
- Applies to a significant portion of the core customer base
- Will result in enough volume
- Will achieve sufficient return on investment (ROI).
ROI calculations are complex and involve multiple factors including:
- Projected sales
- Length of the product lifecycle
- Engineering development costs
- Investment in the new production line
- Product testing.
In many cases, suppliers make prototypes and ask key customers to test them and give feedback. Based on the prototype testing, the supplier may modify the design. This process allows the supplier to fix designs in the prototype stage and not during the full production phase, which saves time and money.
For simple products such as interface relays, the prototype testing process occurs constantly. Examples are fulfillment of customer requests for higher contact ratings, hazardous location ratings, and additional socket requirements.
Customers and system integrators should speak with automation suppliers early and often. If the request is very specific to a unique application, it might be better addressed internally with workarounds or additional components. However, if the request is something that would have more widespread applicability, then there's a very good chance it will be fulfilled.
Don Pham is a product manager at IDEC. Edited by Emily Guenther, associate content manager, CFE Media, Control Engineering, email@example.com.
- Give product feedback to suppliers
- Changes to products are considered based on certain criteria
- Giving feedback results in improved products.
What percentage of product development is a result of customer feedback?
See additional articles from Idec and stories on smart manufacturing linked below.