The world of the engineered system always tend to get stuck on the procedure side. The best engineers are known because they develop a superior process; it is no surprise that they come to believe that the process is what people want. This leads to long sales cycles, and uncommunicative systems in sterile silos. The result is rent-seeking industries that cannot perceive the true value they might offer their customers, and thus have trouble convincing their customers of the new value they might add.
In the last post, I claimed that Dell suffered by outsourced its tech support process rather than its tech support service. End-user tech support is notoriously difficult to develop metrics for. If you track agent calls per hour, customers will be rushed through their calls without regard for their understanding or satisfaction. If you reward the first agent for solving the problem without calling for help, then there will be many mysterious disconnects during phone transfers. Under some metrics, it is better not to answer the phone at 4:30 than risk having an uncompleted call at 5:00. I know one site in which the agents routinely recorded all notes on paper, allowing them to enter and complete service calls in seconds. Be careful what you measure, because you will get what you measure.
The best out-sourcing (or in-sourcing) of any business function is when people know exactly what service they want, or what service they can provide.
Kevin Sample has told me that the HVAC systems for chain drug stores provide three services, and might be provided as three systems. The open floor’s service is the economic provision of a healthy and comfortable environment. The service provided in the pharmacy area is keeping the drugs stable; this might require colder temperatures, lower humidity, and less variance, whether the store is open or closed, than the first service. The service provided by the store’s warehouse area, as relayed to me by more than one experienced hand, is “Don’t melt the chocolate!”
What is most interesting about these three missions is that not one of them mentions any component of the system, or demand limiting, or load control, or even temperature. Each of those metrics or processes might be interesting, but only as subordinated to the primary service. When I am speaking, my shorthand for this is “Each system has a mission, and its primary job is to defend that mission no matter what it is asked to do.
Load control is, then subordinate to the mission, that is to say the service. Within the mission, each of these systems is able to respond to demand limiting or demand response requests. The more intelligent system will understand how to anticipate time-based load control by making adjustments in advance. A simple way to do this might be by over-cooling space early in the day when power is cheap.
Recently Dr. Bob Smith described to me a failure caused by exposing process rather than service. Bob lives in Huntington Beach, and California had some very hot days in early September. A hospital responded by turning off the air conditioning in the clinical areas, with a scheduled resumption at 8:00 Monday morning. It took more than half the day to get the spaces properly conditioned. During those 6 hours, doctors and nurses worked at greatly reduced efficiency. The mission costs to the hospital were probably greater than the energy costs saved. As an added detriment, the cooling was performed during the day, at day-time costs, under day-time heat load.
If the hospital systems had been better defined as a service, the same request would have been “prepare clinical spaces to be in operation at 8:00 AM”, rather than “Turn on at 8:00 AM.” The system itself, with domain knowledge greater than any possessed by the hospital administration, would have decided when to turn on. Using extant outside air temperature sensors, internal temperature sensors, humidity sensors, and even the live electricity pricing, the system would have decided when and how to return the clinical areas to optimum conditions.
Next: How Service Architectures change what the programmer needs to know.