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.
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:
Maintenance activities include:
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:
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:
A maintenance and level of repair strategy needs to be developed. Potential levels of repair are:
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:
Economic analysis often needs to be performed to determine the best approaches to take and consider the trade-offs.
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.
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:
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:
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.
Once the business approach is decided, the mechanism for the software updates needs to be established. Options include:
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:
These design approaches will minimize the number of truly unique systems and only require that support personnel know the unique aspects of the system.
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.