Product Support Planning and Development

As part of developing any new longer life product or system, the organization needs to plan how the product will be supported and put the processes and supporting materials in place. Major elements of product support include customer training, product maintenance, spare parts planning, maintenance training (either internal or external), maintenance and operation instructions/manuals, product configuration, technical support, and customer service.

Product Support Planning
Given the nature of the product, the starting point is to prepare a plan that addresses what support is needed and how the support will be provided. Not all elements of this plan necessarily need to be in place by the time the first units are provided to customers, but the plan needs to describe what those product support elements are and how these product support elements need to be developed or put in place over time.

The plan should describe the general requirements and the approach for supporting the product(s). What capabilities will be required to support the product, e.g., installation service, field training, professional services, third-party support, telephone technical support, general customer support, etc.? What are the maintenance requirements of the hardware and/or software and what are the levels of repair (e.g., customer, field service, factory, etc.)? How will the company provide this maintenance (e.g., internal staff, third-party)? What is the expected availability and mean time to repair (MTTR) from notification until completion of the repair? How will this be achieved?

The plan should describe the customer documentation requirements, i.e., installation guides, user manuals, tutorials, quick start guides, warranty documents, service center lists, etc. Given who will maintain the product, what are the maintenance documentation requirements, i.e., maintenance manuals, diagnostic tools, troubleshooting guides, knowledge bases, etc? What is the approximate estimated size and the development effort associated with each item. When (e.g., prior to product release, in conjunction with beta customers, etc.) and how will this documentation be developed?

This planning should be done before any units are deployed to the field.

Product Maintenance
Consideration of product service and maintenance needs to start early in the development process with understanding the customer’s environment, product requirements (e.g., uptime or availability, mean time between failures [MTBF], mean time to repair), geographic locations, and expertise to potentially support the product. These needs would drive the product design. Principles of design for reliability (DFR), design for diagnosability, and design for serviceability (DFS) should be applied during the design (or redesign) of the product.

To the extent that a product is made more reliable, it will fail less often and require less maintenance over its life. However, additional reliability may require additional development effort (and its non-recurring cost) and/or additional product cost (e.g., more reliable and expensive components or modules, redundancy, etc.). What is the appropriate trade-off in reliability enhancement and related cost vs. the positive impact on maintainability and cost?

Design for reliability principles include:

  • Design based on expected range of operating environments (e.g., temperature, humidity, salt air, vibration, etc.)
  • Design to minimize / balance stresses & thermal loads
  • Provide cooling to hot components
  • Avoid stresses on boards & component leads due to flexing & bending
  • De-rate components for added margin
  • Provide critical subsystem redundancy (RAID storage, fail-over to extra computer)
  • Use more reliable / robust parts & materials (e.g., gold-plated connectors)
  • Reduce part count & interconnections

Maintenance activities include:

  • Response to a fault that requires repair or replacement of service items;
  • Inspection
  • Preventative maintenance (cleaning, filling, lubrication, part/module replacement, etc.);
  • Upgrades

The typical maintenance process involves the following steps.

If a fault occurs, it is necessary to determine the problem before any maintenance action can be taken. The ease of determining where the fault occurs will be based on the extent that diagnosability has been designed into the system. Diagnostic capabilities will depend on the extent of features such as sensors, indicators, and built-in self test (BIST) capabilities are present in the system to identify to not only identify the faults, but also the source of the faults.

To the extent that the diagnosis can be done remotely, this greatly simplifies the logistics in fixing the problems. This remote diagnosis can be done in the following ways:

  • A troubleshooting guide provided to the user or onsite maintainer to determine the source of the problem;
  • A technical support person talking the user or onsite maintainer through a series of steps by phone to determine the problem;
  • Using web-based tools to remotely access the system or equipment to diagnose the problem; and
  • Designing in a continuous remote monitoring capability to automatically capture faults and identify the source of the problem.

Without remote diagnosis, service technician would potentially need to visit the customer’s site to determine the problem. If the service technician did not bring the right parts with him or her or the customer did not have spare parts stocked, then a second visit would need to be made after the service parts were acquired or ordered.

Once the problem is diagnosed, the system or equipment will need to be repaired. In addition to repairs, there are also inspection, cleaning and preventative maintenance requirements. Key principles of designing to serviceability or design for maintainability are:

  • Design for ease of access to serviceable items; place serviceable items near perimeter of the product and provide access panels as required.
  • Minimize interconnections to facilitate access to serviceable items and be able to disconnect and remove serviceable items; use quick connect and disconnect connectors.
  • Minimize number of fasteners to get access to serviceable items or to remove the serviceable item; use integral attachment or fasteners which facilitate quick removal and re-attachment.
  • Make part and module size and weight easy to handle
  • Use robust parts and interconnections to avoid maintenance-induced failures resulting from disassembly and re-assembly.
  • Design to minimize the need for service tools or use a minimum number of standard tools.
  • Mistake-proof re-assembly:
    • Design part or module features which only allow assembly in the correct way
    • Mark and color code parts and interconnections to facilitate correct re-assembly
    • Make part or module orientation obvious

A maintenance and level of repair strategy needs to be developed. Potential levels of repair are:

  • No repair; product discarded and replaced upon failure
  • User/maintainer repair in the field
  • Service technician in the field
  • Service centers or repair depots in regional areas
  • Factory service

A maintenance strategy will consider the maintenance requirements and the potential levels of repair to come up with a low-cost approach to maintaining the product. To the extent that maintenance will be done externally in the field or a service center, the existing skill levels of the users and maintainers will need to be considered and appropriate training developed to bring those skill and knowledge levels to the desired level. The frequency of maintenance will also need to be considered. If a third party service organization will be used, the maintenance frequency could be low enough that that there will be significant erosion in learning over time. In this case, there should be more emphasis placed on maintenance documentation and guidance that can be readily used for the less frequently performed activities and less on the initial training.

Maintenance documentation can be in the form of text descriptions, step-by-step; text with pictures to illustrate each step, or video of the steps. The form of this documentation should take into consideration the workspace when servicing the equipment, availability of a device to play video or access electronic versions of the documentation, or the logistics of carrying around paper manuals. In addition to documentation which describes how to perform a maintenance activity, there is a need for trouble-shooting guides, parts lists, and drawings or diagrams of the equipment.

Finally, what is the business model for service? Is a warranty provided that will require the organization to provide service during the warranty period? If not, other potential business approaches for a maintenance business model include:

  • Provide training and maintenance documentation to the customer; the customer is responsible for all maintenance.
  • Provide all maintenance free for a fixed period as part of the purchase price.
  • Provide maintenance on a paid basis with company personnel or a third party (time and materials per occurrence or a fixed price maintenance schedule).
  • Establish third parties to address maintenance; provide them with training and product data; the company is not directly involved with maintenance.
  • Sign customers to a maintenance contract based on a period of time or operating hours; the company or a third party would provide all maintenance defined under this contract.

Economic analysis often needs to be performed to determine the best approaches to take and consider the trade-offs.

Spare Parts
Another aspect of maintenance is spare parts planning. The mean time to repair (MTTR) and availability requirements of the product will dictate the spare parts strategy. If customers can tolerate longer periods of downtime, the company can buy and build the spare parts to order. If customers cannot tolerate longer MTTR and lower availability, the company and/or third party service providers need to maintain a stock of spare parts. If there are a large number of units in customer sites around the world and customers want a low MTTR, it is generally advantageous to maintain a stock of spare parts in regional service centers. With fewer units and customers that are willing to tolerate several days before they may receive spare parts, it makes more sense to maintain a central spare parts stock.

Before a product is first released, it is useful to identify the needed spare parts for service and, based on the spare’s strategy, establish the needed spare parts inventory in conjunction with product release. While this may seem unnecessary so early in the product’s lifecycle, the concept of infant mortality suggests that there will be early product failures. If the company is unprepared to provide the needed parts and service, it will lead to early customer dissatisfaction.

Spare parts requirements can be minimized with use of standard parts or modules and a modular architecture approach. Part standardization should particularly focus on those parts more likely to require replacement (e.g., a hard disk drive vs. a metal chassis). Even where technology will cause rapid evolution of parts or modules (e.g., disk drives, CPU boards, etc.), try of focus on using products from a manufacturer that will maintain a common form factor or common attachment points. This strategy also allows systems to be maintained when older technology parts or modules are discontinued and allows for product upgrades.

With a modular architecture approach, customized system can be built and sold using these modular hardware building blocks and relying on configurable software to the extent possible. This minimizes the number of unique items that need to be stocked as spares.

Product Operation
An important question to consider is how the customer is going to learn to properly operate the product or equipment. With beta units, companies frequently provide ad-hoc training and minimal product documentation. However, as more units are shipped, this may not be a sustainable model. Considering projected shipments, what is the appropriate way to educate or guide users in the operation of a product given the type of user and their likely skill level?

Training requirements or operation instructions can be minimized or simplified with a product design that is intuitive, easy to use, and reflects good human factors principles. But there is still a need to provide training, instructions or guidance in one form or another. With a more complex system or product, there may be a need for the user to attend a training class or to provide onsite training. With most products, operation instructions can be provided in one or more of the following formats:

  • Operator or instruction manual
  • Quick start page or guide
  • Help functions or a step-by-step operation guide built into computerized systems
  • CD/DVD instruction manuals and/or operation videos

Customer Service and Technical Support
In addition to operation and maintenance documentation and training, there is generally a need to provide customer service or technical support. Despite all efforts to document the operation and maintenance of the system, customers will need someone to help because they don’t look hard enough for the answers in the information provided or the information provided doesn’t cover their needs or issue.

This customer service and technical support function can be done via email, chat or telephone. Does this function exist within the organization? If not, given the potential volume of support requirements, should a dedicated function be set up? If not, who should calls or emails be directed to? Can and should this function be outsourced? What are the hours of operation? How can products be supported globally if hours of operation are limited?

To enhance the productivity of this function, supporting tools need to be established to help the customer service and technical support function. These include:

  • Product and support training materials;
  • Product documentation (user manuals, instruction manuals, maintenance manuals);
  • Trouble-shooting or diagnostic guides;
  • Knowledge-bases to capture learning over time related to support;
  • Frequently asked questions (FAQ) and answers; and
  • Web-based tools to access the customers system, observe their use, demonstrate the use of the product or diagnose a problem.

There is an investment required to develop this information and these tools. But without them, the effectiveness of the customer service and technical support function is greatly reduced and the timeliness to respond to customer issues is diminished. If this function is ever outsourced, the criticality of putting together this documentation is increased. The challenge to supporting products is increased as the number of products increases, their configuration changes over time, and the extent of product customization increases. Minimizing configuration changes and the extent of product configuration will reduce support requirements. Further, providing customer service and technical support personnel access to a customer’s specific configuration will greatly improve their effectiveness.

Software and Hardware Updates/Upgrades
Most products that include software will need to have a process in place to update the software. These updates can be in response to software bugs, to plug security holes, changes in the software environment such as new versions of the operating system or database, or additional functionality. Consideration needs to be given to how these updates are going to be handled both logistically and business-wise.

From the business perspective, these are potential approaches.

  • No updates or bug fixes provided – the customer maintains the software on their own or buys a new system to take advantage of software improvements.
  • No formal program to provide new versions of the software – the company responds on an ad-hoc basis to any customer issues.
  • Software upgrades and security/bug fixes provided on a time and materials basis.
  • Software upgrades and security/bug fixes provided free of charge on customer request. Any customer-requested enhancements would be done on a paid basis.
  • The customer is sold a maintenance contract that would include software upgrades and security/bug fixes free of additional charge while under contract. Any customer-requested enhancements would be done on a paid basis.

Once the business approach is decided, the mechanism for the software updates needs to be established. Options include:

  • User downloads and updates their system either in response to a notification or an ad-hoc basis when they have a specific need.
  • Updates of customer systems done on a periodic basis established by the company.
  • Automatic update capability built into the software with user configuration of how the updates would be made.

When updates are made to a system, it is important to be able to identify what version of the software a customer has in order to provide technical support and troubleshoot. This can be done by maintaining the version on an internal company system and/or by enabling the user to determine their version of the software.

Product Customization and Configuration
Often customers will want a customized system. If this is done in an unplanned way, the result can be many unique products/systems which become very difficult to support. The process of managing product customization and configuration is to define the potential configuration options early in the development process. While this may not cover all potential customization options that customers may ultimately require, it will allow a more rationale approach to designing the product to enable customization.

There are several design approaches that can mitigate the effects on support while allowing tailoring of the system to a customer’s needs and situation. These design approaches include:

  • Design modular hardware and software. This will allow different hardware and software modules to be put together to meet a customer’s unique needs while the underlying modules are relatively standardized. For example, different modules for a radar system simulator may be created with a standardized interface to the rest of the software system. The particular radar software module would be selected and configured as part of the total system. Standard interfaces for hardware can be designed in the same manner. For simulator displays, a standard interface could be developed that would allow the customer to select the number of simulator displays and the size or resolution of simulator displays.
  • Build configurability into hardware and software. So instead of unique hardware and interconnections, standard hardware can be provided that may have multiple types of connectors on a printed circuit board for interconnections or DIP switch which can configure hardware. Provide configurability with software where all needed configurations of the software are built into a common code base. The customer will select software settings to configure the software to their unique needs. For example, simulators for different radar system would be built into a common code base and the customer would select the radar type to use for their operation in a software menu.
  • Provide plug and play hardware capabilities where different models of hardware could be plugged into the system and the system would recognize the type of hardware and configure itself to operate that hardware. For example, a different model of a display could be plugged into a simulator (it might even be a different size or resolution) and the software would recognize the model and configure itself automatically.

These design approaches will minimize the number of truly unique systems and only require that support personnel know the unique aspects of the system.

Configuration Management
With higher volumes of the product in the field, it will be much easier to support them when there are good configuration management practices in place. At a minimum, the company should be able to clearly define the as-shipped configuration of the product for a major product or system to each customer. If the organization is heavily involved in supporting the product (vs. a third party or the customer taking responsibility for support), it is also advantageous to know the current configuration of the product or system as maintenance is performed or upgrades made to hardware and software. This will allow technical support personnel to more readily access this information and provide the needed support.

Related Links