Chain Operators Should Take the Initiative with NAFEM Data Protocol

Author:  Leon McNutt, Watlow Controls
Member of the NAFEM Data Protocol Steering Committee

For years, chain operators and foodservice equipment manufacturers have advocated the need for a standardized online kitchen system. More specifically, the need for a single data language or protocol that would enable kitchen equipment, regardless of the manufacturer, to communicate with each other and with the restaurant's back office. Two years ago, representatives from throughout the industry came together to begin developing such a solution. In May, the North American Association of Food Equipment Manufacturers (NAFEM) announced that the initiative was complete, and the NAFEM data protocol was available for adoption. Last month, at the NAFEM tradeshow, Watlow demonstrated the first implementation of the protocol with its introduction of a network gateway product. For operators eager to get started, the completion of the protocol is welcome news. For those with more of a wait-and-see attitude, it is important they educate themselves about this technology. For both groups, it is critical to understand how to move this development forward, and it is definitely in their best interests to lead the process. Why they should lead and how to do it is a matter of sound business planning.

The protocol will be to restaurant managers what e-business is to the rest of the world. It will provide uniform data from every aspect of a kitchen - from operating temperatures to energy consumption to maintenance needs to sales information. Acting as a data pipeline, the protocol can greatly benefit an operation's inventory, asset and labor management, improve food safety and streamline maintenance functions.

Most operators appreciate the protocol's potential benefits and are eager to see how it can impact their organization. Yet although the protocol represents an unprecedented advancement in kitchen management, implementation is not as easy as purchasing a new software package or retrofitting equipment with compatible hardware.

Who Starts the Process: Chain Operators or OEMs?

A lack of start-up kits shouldn't deter chain operators from starting the process of adopting and implementing the protocol. As the most influential group in the industry, only chain operators have the clout required to move the process forward - at least in the manner that will be most beneficial to them in the long run. There's enough information available for chains to become the driving force in furthering the protocol's use. And if chains aren't the drivers, they put its future in the hands of individual equipment manufacturers or others in the industry. Considering that the purpose of the protocol is to ensure the use of a standardized language and to provide a customized tool for restaurants and chains, allowing OEMs to advance the protocol will probably not produce the results restaurants are seeking. Rather, it is more likely that OEMs will develop the protocol centered more on the equipment they manufacture (this is only natural). For the protocol to provide maximum benefits, operators must use it in ways that make the most sense for their own establishments. The alternative is to adapt a multiple systems delivered to them by multiple equipment manufacturers - an alternative that defeats the main purpose of having an industry wide protocol.

Enterprise Viewpoint vs. Equipment Viewpoint

The first essential step is for operators to adopt a store-centric viewpoint. Currently, the industry revolves around an equipment-centric viewpoint - equipment provides operators with data such as temperature, pressure and operating times. Managers take this data and adapt their processes and supporting equipment accordingly. The equipment, and the equipment manufacturers, are basically telling operators what data is important, and how that data affects their kitchens. This equipment-centric (and most times proprietary) viewpoint is one of the main reasons operators have felt a need for a single protocol. Most kitchens have struggled with new equipment that is incompatible with other equipment, or with data that does not provide relevant or timely information.

Therefore, for chains to reap the benefits they seek, they must adopt an enterprise viewpoint, or take a store-centric approach. This requires chains to define their own needs and then determine how equipment should meet those needs with data conveyed through the new protocol. The challenge is to design their systems and kitchens to best suit their operations and then communicate their plans to OEMs. The protocol gives operators the starting point and common method to do this.

To most restaurant managers this is not a new idea. Different chains have different needs and most have an unfulfilled wish list. By driving an enterprise view, a chain with a desire to streamline maintenance and diagnostics can dictate this as its first priority to supplying OEMs. Instead of accepting refrigeration equipment that emphasizes temperature measurement, the operator can request a model that prioritizes maintenance predictions, in addition to temperature monitoring. Likewise, a store that wants better performance from its exhaust filters can specify a system that focuses on measuring air pressure across the filters to help determine when they need to be changed. The operator can say to OEMs, "I have five exhaust hoods and seven filter systems. First, I need monitoring points and then I need to network the information back to a centralized place so I can take action." Throughout the industry, chain leaders should be evaluating their operations in similar fashion and beginning the process of creating a structured data model of their stores.

Education: The First Step Toward Implementation

Chains can initiate the process of using the protocol with education - determining how they want their kitchen to work and what the protocol has to offer. Specifically, operators should pull together development teams charged with aligning resources, learning the protocol and understanding its various components. NAFEM is taking steps to provide information and educational opportunities to the industry. The recently completed and released data protocol manual and the NAFEM web site (www.nafem.org) are also good starting points. Eventually, demand may encourage private companies to begin offering consulting and educational services.

Step Two: Determining Where to Start

Once familiar with the protocol, development teams should undertake a review of the operation from their enterprise viewpoint. The review will include a survey of all the equipment, look at maintenance issues, determine how the equipment affects food quality and safety and how it relates to other equipment or processes within the store. This will help the team establish what they are trying to target and what they want to access - the operation's priorities and areas that would make good candidates for the protocol. For example, if controlling or predicting utility expenses is a priority, it may be a natural place to begin the implementation process. In general, the monitoring aspects of the protocol are probably the simplest and easiest to integrate. This involves establishing a multitude of sensing points that collect information about a kitchen's processes. Simply understanding what's going on in a kitchen may be the first step an operator should take. The second round of implementation can then focus on employing the collected data to further improve ROI.

For operators skeptical about committing resources toward reengineering their kitchens, it's important to understand that the protocol can be implemented gradually. Using recommendations from a development team, decision-makers can select one or two areas as pilot programs. The protocol's flexibility and structure actually encourage users to implement it in a piecemeal fashion. Broken into groups such as maintenance, utility, monitoring and inventory, it allows users to apply it to where it is most needed, and not force them to implement unwanted or costly changes to their kitchen.

Again, large chains have the necessary history to streamline the process of deciding where to begin implementation. Because the protocol is broken into groups, chains can immediately select areas that address their individual problems. For some chains, maintenance is the first priority, for others, it may be food preparation processes or labor scheduling. Regardless, the protocol groups can be quickly adapted to react to an organization's most painful areas.

Step Three: Conduct a Thorough Inventory of the Data Available

Selecting where to begin is a good start, but before involving equipment manufacturers, development teams must take the important step of focusing on critical control parameters. If the goal is to control and monitor utility usage, teams should understand and document all processes that impact this area. It's essential to determine what data can be generated and captured to enable better business decisions and improve processes. Even limiting the example to utility management, the amount of available data, and the potential positive impact it can have, is very encouraging, if not immediately obvious. A system designed to optimize energy usage might go well beyond better control of heating and cooling systems. Users can control cooking equipment in response to data from POS systems, or measure the amount of heat spilling over into environmental areas that requires additional work from the cooling system. Monitoring the performance of equipment, such as whether a fryer heater is providing the correct thermal transfer, is also data that may help improve energy efficiency. It's simply important for development teams to realize the scope of valuable information available to their operation.

Step Four: Designing Your Intelligent Kitchen

At this point, a development team has educated itself about the protocol, decided where it can best be implemented and has gathered and defined the process data it wants to network. The next step is to design, or lay out, the actual system. The team should consider the data it plans to capture and how to link it with the responses needed to transfer the information into actions. Simply stated, construct a model that connects equipment data to back office software, allowing management to understand what's happening throughout the kitchen and take any necessary actions. Of course, many processes can be easily automated, such as instantly ramping up a warming cabinet or notifying service personnel of equipment failure.

How the information is to be presented should also be decided at this point. A store with 40 monitored temperatures should decide how these temperatures should be consistently displayed for action response. From an enterprise standpoint, consistency in how the information is organized is key. Establishing that the temperature of fryer #1, for example, is going to be the top instance displayed at every franchise will ensure a presentation of information that is valuable to the chain through reduced training and education costs. Again, the alternative is to allow others in the industry, such as software providers or OEMs, to determine what information is important.

Step Five: Implementation

Finally, with model in hand, chains are ready to approach OEMs and request the equipment or components needed to implement the system they envision. Suppliers must then determine how best to handle the internal mapping needed within its devices. Two options are available - an embedded firmware approach, in which the equipment is designed and pre-programmed to successfully communicate the desired data within the chain's existing system. Or OEMs can simply rely on a gateway device to serve as a translator and a bridge - making their equipment compatible, both in language used and physical connectivity.

Watlow believes a gateway device is an attractive solution since it eliminates the need for OEMs to modify every machine to every customer. It also can impose a restaurant's enterprise map onto a device and translate its non-enterprise view. Whether a gateway device will work depends on the design of the equipment to which it will be connected. The equipment must already have some kind of communication mechanism, as well as a physical way of connecting. It must also produce the store-centric data the chain wants for its system.

NAFEM data protocol uses Internet connectivity rules so the actual process of physically connecting equipment and/or a gateway is fairly standard. Basically, a chain's IT personnel or a manager with general computer skills can connect the system. The process should be as simple as plugging in cables and turning on application buttons. Undoubtedly, equipment suppliers will also be more-than-willing to help link their machines.

One Final Step: Measuring Deliverables

After a system has been in place and operating for a significant period of time, the development team should measure its success, comparing it to original expectations. If the goal was to reduce energy consumption by 10%, but the reduction has not occurred, refining of the system may be needed. For an online kitchen to generate substantial ROI, operators must be capturing the right information and using it correctly. To achieve this goal, some adjusting and reevaluating of assumptions may be necessary. On the other hand, once success has been verified, it can be used to justify moving forward with more programs within the organization.

What Next?

As with any tool, regardless of how advanced or powerful, the NAFEM date protocol is useless if it is not used, or not used effectively. The challenge of the protocol is it requires a proactive approach in a field dominated by reactive practices and decisions based on current needs. Unless chain operators move forward to use the protocol, and more importantly, to take the lead in its implementation, it will fail to become the tool they've requested. For those companies committed to improving their bottom line, NAFEM has created the tool. To use it, operators simply need to focus on their needs, or viewpoint, and then follow the instructions on initiating its implementation. The possibilities are very exciting - dramatic improvements in controlling costs, operations and, of course, ROI.

About the author

Leon McNutt is a steering committee member for the NAFEM protocol development. He has 17 years experience in the field of electronics, primarily in communications technologies. McNutt serves as Watlow's Research and Development Manager for Controllers Technology. Watlow is the largest custom designer and manufacturer of industrial heaters, sensors, controllers and software with offices and manufacturing facilities around the world.