by Ray Bernard

Most decisions and interpretations in the world of contracting are based upon the "letter of the law". When a provided system can be shown to meet the written specifications, the contractor must be paid and the system must be considered to have been installed "per contract". 

This sometimes happens even though the customer may not feel the system is what was originally intended or what is actually needed.

One method to avoid this situation and to achieve end-user satisfaction is to ensure that the "letter of the law", that is the specification or in a design document referenced by it, must be all of the items which ( if provided in any reasonable fashion) will result in the customer's requirements being met operationally as well as on paper. 

Customer Satisfaction
Most specifiers and system providers will agree that a general description of the objective of their activities is to "provide customer satisfaction at a profit." 

As consultants we are often called upon to review installed systems because the customer is not satisfied with what he has received. We have encountered these types of scenarios in those situations:

• The installed system meets the letter of the contract and must be accepted as it is. In many cases the customer is too small to be able to brow-beat the providers into upgrading the system at their expense. Either the customer unhappily accepts the unwanted system, or pays for it to be replaced or upgraded.

• The installed system meets the letter of the contract but the customer is big enough to be able to brow-beat the providers into upgrading the system at the expense of the providers. In this case the system providers unwillingly bear the cost. In this situation you can expect the additional work provided to be of minimal acceptable standard.

• The installed system does not meet the letter of the contract and must be improved to do so at the expense of the providers. If the customer can easily point out the omissions against the specific contract language, this situation can usually be resolved on an informal basis, with a few meetings and a letter or to clarifying the details where needed.

• There was a misunderstanding about items in the specification, resulting in the customer's system expectations exceeding the system expectations of the providers. One method of resolution is to call for a clarification by the specifying person or firm. Another means of resolution is to have those parties involved in the specification and purchasing process meet to determine or vote upon the interpretation to be considered the correct one. Generally the minority interpretation loses out to that of the majority. In this case the loser usually foots the bill for bringing the system up to meet the majority interpretation.

• The installed system meets the letter of the contract but not the customer's expectations, and the system provider has sold or promised 100% customer satisfaction in the process of obtaining the project. In such a case the provider may elect to improve the system at the provider's own expense in order to meet the customer satisfaction standard. The provider thus obtains a showplace installation and a loyal customer, sacrificing the job's profit or even taking a loss to do so.

Integration Design Issues
Many design issues require close examination when defining the scope and functionality of the front-end system. They must be addressed up front, in order to prevent any of the above scenarios.

At some level, a design document must exist that completely defines the work to be performed by the front-end system. Where such a document does not exist, it should be produced prior to obtaining bids on the integration project. That way, the parties providing and accepting the bids have a crystal clear idea of what should be produced.

A complete list of design issues that should be examined in defining the front-end system is beyond the scope of this article. However, to help illustrate the importance of examining these issues, we will touch upon a few of them now.
 
I will refer to the graphical user interface as either the "front-end" or the "front-end system". I will refer to the stand alone systems that are being integrated into this front-end as "subsystems", even though each of the subsystems can be operated as an independent system.

Subsystem Configuration. When integrating off-the-shelf systems which themselves are configurable, the integration plan must take into account how the subsystems will be configured. 

Will the front-end system be required to handle all of the optional capabilities of the subsystems being integrated? Or will it include only those capabilities which are envisioned as customer needs?

Monitoring vs. Control. Will control functions of the subsystems be integrated into the front-end, or just the monitoring functions? It is much easier and less costly to integrate monitoring only. 

Customers usually prefer to have all the key control functions implemented in the front-end system. Key control functions are functions required for daily operation, not restricted or infrequently used functions such as operator password assignments.

Monitoring functionality requires only a one-way interface: from the subsystems to the front-end system. 

Control functionality requires a two-way interface: from the subsystems to the front-end for status information, and from the front-end back to the subsystems for control.

Example: Acknowledged Monitoring
Let's look at alarm acknowledgement as an example issue with regard to system integration. There are four approaches:

• Front-End system alarm management -- subsystem events are not classified as alarms. All alarms, alarm instructions and alarm acknowledgement is performed in the front-end system.

• subsystem alarm management. Alarms and alarm instructions are set up in the subsystems. When subsystem alarms occur the front-end system directs the operator to the appropriate place in the subsystem, where the operator performs alarm acknowledgement and obtains alarm instructions.

• No alarm management. Alarm acknowledgement does not have to be addressed because alarm instructions and alarm acknowledgements are not used in daily operations.

• Mixed Alarm Management. Alarms and alarm instructions are implemented independently (sometimes at different levels) in the front-end system and subsystems. Although sometimes implemented, this is never recommended because it is a large potential source of errors, oversights and confusion.

Documentation and Project Success
The less detailed the integration specification, the greater the chance for the end result to comply with the written requirements without meeting the end-user's needs.

How can the specification and design work be done to help ensure that the end result will match the end-user's needs? 

There are a number of successful approaches. As you might expect, all of them involve dialog with the end-user.

Design Methods
When the end-user is thoroughly familiar with the setup and operation of the subsystems involved in the integration, it is a simple matter to have the customer describe the facility's needs in detail for the design document. This requires a fairly short time frame for design, often days or weeks. It can also provide the lowest design cost and most accurate design. 

When the end-user is not familiar with the setup and operation of the subsystems, the customer can be introduced to them by "show-and-tell."

Choose a variety of installed sights, sufficiently diverse as to provide a selection of features from which the end-user can choose the design feature-by-feature. The design document can include descriptions that reference the installed sights. This requires a longer time period, usually weeks or months depending upon how intensively the process is performed.

An experienced system designer can eliminate the necessity for customer familiarity by designing a proposed system based upon a familiarity with similar end-users and systems. 

Phased Integration
An approach that is both practical and economical is called phased integration. This approach allows the "shopping around" method to be used with regard to subsystem selection, and provides the opportunity to combine the "experienced customer" and "shopping around" methods for the integration design. There are the two phases involved:

Phase One -- Install and configure the subsystems, fine-tuning their setup and operation until the customer is maximally satisfied with their operation and performance.

Phase Two -- When phase one is complete and the system has been in operation by the end-user, design and develop the front-end integration based upon the end-user's preferences. 

This process involves some back-and-forth between designers and end-user (including hands-on users), balancing any features vs. cost issues until the design achieves the best feature-cost mix from the end-user's point of view. 

Develop and install the front-end system based upon the customer-accepted design. This approach holds the least chance for misunderstanding by any of parties involved, and the greatest chance for complete customer satisfaction.

Here are some additional advantages of the phased approach:

Educated end-users -- Use of the subsystems in their own facility produces end-users who are educated not only on the operation of the systems, but on their own facility's needs with regard to the functions those systems perform. Sometimes this reveals new requirements that neither the designers nor the customer could have foreseen. These can now be included in the integration design.

Subsystem "kinks" are worked out early on -- When the subsystems are installed and any kinks or "wrinkles" worked out prior to integration, a major source of confusion is eliminated. Integration installation and troubleshooting times are reduced markedly.

The full role of integration can be identified -- With the subsystems operating, the actual role that the integration must perform can be clearly identified. 

Is it the job of the integration to simplify operations, so as to lower training and personnel requirements? 

How about to speed operations, by combining several subsystem operator actions into one? 

These and many other questions can now be answered accurately based upon performance and functionality of the installed systems the customer's real-world experience with them.

It provides the fastest track to functional operations -- When the subsystems are installed and fine-tuned as phase one, the customer receives an operational system in the fastest possible time.

If front-end integration is required to provide functions that are not performed in the subsystems, then you are really not talking about simple system integration. You are instead dealing with added functionality or system enhancement. 

In most cases you are still better off using the phased approach for the installation. Without the phased approach, the fact that added functionality is needed in the front-end system may not be discovered until after installation.

It allows for last-minute design changes -- Design and development of the front-end integration should include allowances for last-minute design changes. (They always happen, so why not plan for them in advance?)

After phase one installation, and before finalizing the front-end design, consulting with the customer's hands-on personnel can assure that the last minute changes only have to be done once.

Measure twice, develop once -- This is the software development version of the carpenter's "Measure Twice, Cut Once." The same principle applies to custom system design, whether the system is large or small. In this case the best "measurement" to take is a review of the set of installed subsystems, after they have been fine-tuned to the customer's requirements. 

The most-accurate design "measurements" can be taken from observation of the installed sub-systems in action, and from the list of requirements that are provided by a now-knowledgeable customer operating the sub-systems in the customer's own facility.

See the related sidebar: An Integration Project Checklist.

Also see the author's August 1999 follow-up comments to this article, after reviewing the above guidelines against recent projects: What Do Projects Prove?

From Engineered Systems Magazine, 1995.