The overall objective of ICS' product support program is to support user and distribution efforts to keep a system mission capable, up to date, and current with the evolving needs of its owner. Achieving this goal involves several participants, typically the owner, supplying dealer or distributor, and the manufacturers of the system components. A good plan fosters a partnership between the participants.

System Support Plan

Our Definition: A System Support Plan is a detailed strategy to keep a system fully mission capable, up to date, and current with its owner's evolving needs. It defines the roles of the plan participants, the detailed services they provide, and establishes a standard of performance for each service provider.

The System Support Plan defines the roles and responsibilities of the parties who must work together to provide excellent product support. The owner, users, installers, service providers, parts suppliers, system dealers, and product manufacturers, and developers all have roles in this plan based on the user's decisions about how the System Support Plan is to be implemented.

Quality Support

Quality support may be defined in different ways by different users. To one, it may be the on-site presence of qualified technicians along with all necessary repair resources. To another, it may be the availability of qualified technicians who can repair any problem from resources in their individual service vehicle. To still others, it may be access to all information and resources to fix the problem, and access to qualified service technicians with know-how and parts. Finally, others might define quality support as access to all information, training, and resources needed to be fully self-sufficient, with backup access to advanced technical support.

The differences between these definitions are differences in the location repair resources, the location of the qualified technician, and differences in the rules of access to the needed information for product support. Fundamentally, a System Support Plan articulates the owner's decisions about where these support components are going to be located, who is responsible to provide them, and about how success will be measured.

Measuring Success

A product requiring little support is described as robust. Robustness has three major components:

Availability is the probability that a given system will be fully operational at any point in time. In other words, the product has high availability and when service is required, it is fixed quickly and easily.

A system that is 99.999% available is out of service no more than 5 ¼ minutes a year. A system that is 99% available is out of service no more than 87.6 hours per year. Engineers further detail computations of system availability by adjusting for what percentage of a system is broken at any one time. A system with several doors is still essentially functional even if one door is not operational. These calculations of availability can become very complex.

However, availability cannot be used alone to measure robustness. Suppose a particular problem causes a system reboot once or twice a day, and that the time to reboot is 10 minutes. Although two reboots each day probably creates anguish in an owner's mind, that system's developers can claim that their product has a system availability greater than 99.998%, only .001% less available than 99.999%! Such a system is not robust in the minds of most.

Mean Time Between Failure (MTBF) is the average amount of uninterrupted operation between failures. Truly robust systems exhibit long MTBF's. It is important to note that scheduled maintenance downtime affects availability but not MTBF.
Mean Time To Repair (MTTR). This describes the average amount of time required to repair a system when it fails. A robust system has a short MTTR. It is the MTTR characteristic that, when applied to security systems, determines whether the system is robust or not.

Mean Time To Repair characteristics

MTTR depends on a number of factors:

Time Spent on Problem Diagnosis. This time interval is dependent on the expertise, or know-how of the technicians who service it.

Know-how means knowing how to examine problem situations using the proper resources. The principle resource is a knowledge-base about the system that relates system behavior to behavior expectations, and the means to alter the behavior if not correct. Availability of high quality know-how is essential to a first class System Support Program.

Other resources include computer programs that allow technicians to inspect the real activity of the various programs and devices that make up the system, specialized monitoring devices such as datascopes, etc.

Replacement Part Acquisition. No matter how good the product, no matter how great the know-how, no matter how fast parts can be installed, without the necessary replacement parts the system cannot be fixed! Highly proprietary systems are more likely to experience delayed parts because of their single source of supply. They therefore may experience longer repair intervals.
Replacement Part Installation. Systems designed for fast repair are superior to others. For reasonably designed systems today, snap-out-snap-in component replacement is routine.
Time to Place the Repaired System into Full Operation. The time to reload data to replaced intelligent devices, to re-synchronize databases, and to upload history might delay normal operation for some systems. The extent of the system's ability to return to full mission capable status as soon as new parts are in place is a matter of system design and should be considered as a part of the acquisition decision process. Similarly, the ability of a system to provide essentially complete services while the synchronization process occurs is a positive factor for selecting a system.

Mean Time To Repair is an important component of a system's robustness. When all factors are considered, a system that runs well, rarely fails, but:

depends on special order parts not locally available, or
parts are locally available, but require major disassembly and reassembly to install them, or
system complexity is such that it is difficult to diagnose a problem, or
there are limited resources to assist in the diagnostic process, or
reactivation is a lengthy process because long downloads of data to repaired components are required,
then by no means can the system be considered robust.

Characteristics of a robust system

A robust system will:

have a very high availability, generally not requiring down times of more than 24 hours for all reasons during a one year period;
be built from components that have a very long MTBF;
be installed such that it is resistant to accidental and intentional damage;
have MTBFs should be measured in years (based on the type of device);
Have a very short MTTR because:
the know-how to diagnose problems and effect repairs is easily available,
the time required to obtain replacement parts is short,
the time required to install replacement parts is short,
the time required to reactivate the system is short, and
the system is capable of full operation during all or most of the reactivation process.

Compare the robust system characteristics to the characteristics of personal computers. One reason why our dependence on PC's has grown is due to the wide availability to components, which also have very long MTBFs. With high quality replacement parts widely available, businesses can accept the risk of depending on PC's for critical functions because they can be repaired so quickly.

The explosive growth of personal computing also depends on its open architecture. With few proprietary constraints, people have become capable of independently configuring, fixing and adapting these systems. As PC's become even more self-diagnostic and self-installing, even less know-how will be required. Thus, more and more people will be able to extend their use of PCs in the workplace and home.

With this growth, there has been an explosion of resources (books, videos, etc.), constituting a knowledge-base, that empowers those who would become know-how providers. The current evolution for these knowledge-bases is to Internet accessibility, allowing users to solve their own problems, saving both them and the system provider money and time. Thus, users become their own know-how providers in the resolution of routine problems. This permits the PC market to continue its growth.

These same principles should apply to security systems. Unfortunately, this is not the case. The security market poses risks to system owners due to the highly proprietary nature of systems that dominate it. In this market, products are frequently available from only one protected supplier, limiting access to the knowledge-bases necessary to service products. Thus, know-how is based on personal experience, leading to a scarcity of sources of that know-how. This often manifests itself with on-site technicians spending long periods of time on the phone, trying to find the headquarters technical expert who has experienced an unusual problem. Worse yet, the vendor may fly technical experts from other locales to work the problem, a proposition that ultimately increases the cost of the vendor's goods and services.

System Support Plan Development

Depending on internal standards for system availability, MTBF, and MTTR, users must decide how to position its suppliers in its System Support Plan. Clearly, the more interchangeable your system's components, the greater their availability and because of competition, the lower their costs. The most demanding requirements may be satisfied by stocking snap-out-snap-in replacement parts and on-site know-how providers. Others may choose to wait for the well supplied service technician (know-how provider) while others may satisfied with overnight part shipments.

Just as the system user must prescribe sources of parts in the System Support Plan, the access route to the required know-how must be specified. Know-how includes knowing how to quickly diagnose the cause of a problem. Ultimately, the basis of know-how is documentation or, more generally, a knowledge-base. The problem with printed documentation is its lack of portability. And, the more comprehensive the documentation, the longer it takes to search for the solution to a given problem.

The Knowledge Base

System managers need better options. Should the know-how be on site or should it be on call? What form should the knowledge-base take and who should supply it? Where is the knowledge-base?

Our Definition: Know-how is experienced, trained access to a knowledge-base.

Our Definition: Know-how Providers are the people with know-how, available from a Dealer, Distributor, or other supplier.

Where is the knowledge-base and how good is it are the questions that are important to answer. Is the knowledge base:

easily accessible, at any time, and from any location?
complete with answers in a form that are useable?
searchable without restrictions?

If these characteristics are met, then the number of know-how providers can grow over time, simply because they need less experience to become effective. Only basic training should be required if the knowledge-base is really good. What does a knowledge-base have to contain to be really good? How can the success of the PC market be brought to security management?

Preventive Maintenance

Preventive maintenance includes all work done to prevent system failures. If preventive maintenance tasks interrupt system operation, they reduce system availability. On the other hand, the work may prevent a failure and subsequent repair interval. The ability of a system to remain fully functional during maintenance, although not the most important buying criteria, is an essential characteristic that should be considered during system acquisition.

Preventive maintenance includes replacing worn parts before they fail, cleaning and repairing surfaces, recalibration of components, and measuring and analyzing the operational effectiveness of the system. Performance degradation due to increased usage or shortage of system resources can be detected early and corrected before a real problem occurs.

Rapid obsolescence

A new phenomena, the rapid obsolescence of specific versions of PC components threatens the success of System Support Plans. As computers age, or their operating systems evolve, a specific computer tends to become unfixable for certain kinds of outages. If the network card of a given computer ceases to be available, and the computer operating system was not compatible with replacements, the system is not easily fixable. Just as parts need recalibration to match their environments, software must be upgraded to meet its changing environment.

Application software refers to the computer programs that do work for us as users, like access control and alarm monitoring. A user who wants to maintain the operational effectiveness, i.e., the availability, of his or her system must make the commitment to keep their applications software current with PC computing technology, even if the computer hardware is not changed. This practice protects against incurring major repair time. As we have observed, short MTTRs are characteristics of robust systems.

Keeping Current With Evolving Needs

No matter the choice of system, at some point the installed system will not meet the evolving needs of its owner. How is this problem to be resolved? Wholesale replacement is not acceptable. Therefore, the system's scalability, and available options for user-driven customization, help extend the useful life of a system.

Vendors who provide a single version of software from small and simple to large and integrated without structural changes is the best assurance that the investment in the system will be able to meet the future needs of its owners. If combined with an aggressive upgrade program and the ability of the owner to influence development efforts, the system will almost certainly be able to support its continuing requirements.

If the owner has access to genuine customization services or source code to perform its own customization, then the potential is there for a perfect System Support Plan.

Building a System Support Plan

Having carefully evaluated all of these options, a system manager can begin to decide how to structure the System Support Plan for his or her system. Fundamentally, there are three types of participants in the System Support Plan. There are the owner and users, the parts and service providers (dealers, distributors, parts stores), and the manufacturers and developers of the core products. These different types of participants have different strengths and weaknesses that define their roles in any System Support Plan.

A Successful System Support Plan is a Partnership

A successful System Support Plan builds a partnership between its participants. A strong plan results in all participants being satisfied; a weak plan usually results in the system owner developing a different plan. Experience shows that good partnerships include open disclosure of all pertinent information and hard work by all involved parties. In fact, the key to a good support partnership is the effective distribution of know-how. When each partner has the requisite level of know-how, the partnership is strong. Where the underlying knowledge-base is guarded, the availability of people with useable know-how will be restricted, resulting in a weakened partnership. A properly designed knowledge-base fosters the development of many know-how providers and successful partnerships.

It is important to note that granting access to one's knowledge-base is not the same a publishing one's library of technical information on the Internet. Such a strategy could be more confusing than valuable. The proper publication of a useful knowledge-base requires openness, creativity, and perseverance by the publisher in order to be successful.

ICS' Standard Support Program

ICS' standard Product Support Program is available to all at no charge. It can be accessed over the ICS website without restriction. The standard program includes open access to our knowledge-base, containing problem solutions, and our open problems inventory, all searchable by search engine, and includes free access to software patches. Our E-Support-Center provides users a means to get fast access to the known solutions, open problems, and technical information necessary to effectively implement their System Support Plan.

ICS avoids the problems inherent in traditional, "expert-based" technical support. Specifically, traditional technical support relies on knowledgeable individuals for support delivery. As the vendor grows, more, less experienced support engineers are added, decreasing the chance that, for a given problem, the system user will reach the "expert". The time between opening and closing a problem then increases, and customer satisfaction decreases.

ICS further improves the traditional support model by providing technical support the automated tools to access the user's entire problem history. Since systems rarely fail all at once, good records of your system's problem history may provide the clues needed to solve the next problem you encounter. Keeping good records is difficult, especially in a traditional technical support environment where so much information is exchanged verbally.

The solution, provided free to all EnterpriseSMS users, is ICS' E-Support-Center.

Free Software Patches are Standard at ICS

Patches usually fix specific, important problems. They are narrow in scope, and are infrequently released because of the risks inherent in upgrading only a certain portion of a software product where all portions are designed to work together.

However, patches address all critical problems of a release of the software. But, due to their limitations, patches are uncommon. As a rule, a patch is released only when no effective means exists to circumvent the problem and when the problem is judged to be of serious impact.

Patches are provided at no charge and are available to all users of the software release for which the patch is provided.

Download for Print...

On This Page....

On Other Pages....

Information contained on this page is correct at the time of its publication and may change without notice. Integrated Command Software and its agents assume no responsibility for its accuracy.