Building a "Trusted Source"

Data synchronization issues are no small potatoes for McCain Foods, which produces nearly one-third of the world's French fries, so the company is moving to implement a "trusted source" for product information in its Canadian division as a way of improving customer service and gaining competitive advantage.

For Don Luby, product data synchronization is all about one thing: customer service. "It'll make us more agile in response to changing demands from our customers," says Luby, who is director of information technology (IT) planning and e-business at Canadian-based McCain Foods Limited.

Of course, when the McCain family founded the company in Florenceville, New Brunswick, in 1957, data synchronization probably was not much of an issue. That year, the company's 30 employees produced about 1,500 pounds of product an hour and earned sales of $152,678. Now, however, McCain's 18,000 full-time employees around the globe put out not only more than 1 million pounds of potato products every hour, but also green vegetables, desserts, pizzas, beverages, oven meals and other food products, racking up worldwide sales of $4.8 billion for the fiscal year ending last June 30.

All those products — including several dozen different French fry varieties — add up to a big serving of product attributes, everything from packaging and shipping information to nutritional, recipe and cooking information. As a global enterprise, McCain regularly receives requests for product information from other companies, its customers and regulatory agencies in countries around the world, in addition to requests to provide information to third parties, such as online trading exchanges. More recently, customers have also requested that McCain provide product data to industry-supported data repositories like ECCnet, the Electronic Commerce Council of Canada, a not-for-profit group dedicated to promoting and maintaining product data standards.

Each customer or other requesting entity typically has its own format requirements, which has made the task of responding to queries in a consistent manner all the more complicated. For instance, McCain sells those small juice boxes that parents pack in their children's lunchboxes. The juice boxes are bundled in packs of three, then four packs of three go into a store pack of 12. Six store packs make up a carton, for a total of 72. One customer might want McCain to use "one carton of grape juice" for the quantity field in the product description, while another might view the juice as 72 individual cartons, still another might see 12 cartons of six or six cartons of 12, and so on, multiplied times the couple of hundred different products that McCain offers.

The dispersion of product information throughout the company has further complicated efforts to meet customers' requests. Much of McCain's product data resides in the company's enterprise resource planning system, but a good deal of the product attribute information sits in disparate systems in the company's research and development or marketing departments in Excel spreadsheets or Access databases elsewhere in the enterprise. And that, according to Luby, is where the trouble starts. Because the data are dispersed among different systems, fulfilling an information request requires tracking down the correct set of data from the appropriate system, then ordering and formatting the information as required by the requester. That is, each request essentially requires a customized response.

At the same time, similar requests coming into sales or marketing people in different locations within the company would trigger similar efforts. "Basically, one salesman in one office might be doing it for one customer, and a hundred miles away somebody's doing basically the same thing for another customer," explains Luby. "So not only is it just manual effort, there's potential duplicate effort." And because much of the effort to meet the requests is semi-manual, the data provided are subject to errors and transposition, with incorrect data holding the potential for raising issues with customers, exchanges or industry repositories.

These one-off requests were challenging enough, but McCain also had to contend with continuous requests. The issue here was that often the initial request would be for a limited set of product attribute data, but over time the company would be asked to provide additional pieces of information. "You don't know the full extent when you start," says Luby, "until all of a sudden you figure out that you're spending a lot of time and effort on this and it's becoming mission-critical."

Finally, the frequency of requests for product data has been increasing. Customers and other entities are starting to want more frequent updates, according to Luby. "We are finding that these are not one-offs," he says. "They are starting to get more frequent, and so what you thought you were only doing once, now you have to do regularly." Retail customers, in particular, had an interest in having access to up-to-date information through organizations such as ECCnet, since the industry is moving to use these types of groups as centralized product data repositories — although McCain still had to deal with ad hoc requests for product data, too.

McCain divisions around the world did make moves to automate the process of collecting the information to some extent, using data extracts, Excels spreadsheets and other semi-mechanized tools. But the ad hoc systems and processes put in place were not consistent across the company, and moreover they frequently had to be patched and re-patched together to comply with new or changing requests over time. "It got to be rather 'kludgey,'" Luby says. "And people were doing this all around the world."

Eventually, McCain conceived of the idea of moving toward establishing a centralized repository for the company's product information and decided to start off in the company's Canadian division — which employs about 3,300 people, has 11 processing facilities and represents a considerable percentage of the total frozen food dollar in Canada. The idea was to set up a storehouse of product attribute data that would also incorporate transformational capabilities so that users could set up customized but reusable templates with the proper information and formatting required by individual customers, industry registries like ECCnet and other requesters. This "trusted source" of product attribute data would be fed from other systems within the company.

Luby and his team evaluated a variety of product information management solutions for use within McCain Foods before settling on an application called I-Accel from solution provider FullTilt. I-Accel is a Web-based product information management solution that offers a shared enterprise-wide repository, configurable workflow and role-based security. The solution was designed to help companies to aggregate and create product data from disparate sources and to standardize it using product domain expertise and industry standards.

McCain and the solution provider announced the selection of I-Accel in September 2003, and the deployment was set to go live in January 2004. The solution will not replace the company's enterprise resource planning (ERP) system as the master record for certain data, such as part number, but for information such as a product's official recipe, the "trusted source" will be the I-Accel database. "You might have six versions of the recipe somewhere else in the company, but if anyone in the company were to get a phone call from someone who needed the 'publishable' recipe or list of ingredients, then [I-Accel] is where you go," Luby explains.

Getting the database established and the necessary "hooks" connecting the repository to other systems has been relatively straightforward, according to Luby. "This is not rocket science," he quips, noting, however, that in order to feed external requestors the company has had to go through a largely manual task of "cleansing" the data, whether for the individual requests or for feeding the database — not an overly onerous task, given that a McCain division may have a couple hundred products, but nevertheless very important, particularly when competing data exists within the company. Currently McCain intends to populate the database with about from just under one hundred different attributes for some products to several hundred attributes for others. Luby did not expect to have all the hooks automating data feeds to the repository in place by the January launch date, but the project team planned to work in a follow-up phase to ensure that all the loading and data transfers become more fully automated than in the initial phase.

Altogether about a half-dozen people within McCain's Canadian division will be responsible for the "care and feeding" of the Canadian data repository, but the system will be open to whomever within the division needs to access it to provide product information to a customer or other entity. The system allows users to configure "views" of the data to be sent out, and average users will have the ability to set up new views to a certain extent. But McCain will also have a number of "power users" who will have the ability — and the administrative permissions necessary — to generate completely new views. "If it's fundamentally different, then IT will have to do the first one of that ilk," explains Luby.

McCain's implementation team has worked to ensure acceptance of the new repository by bringing in the different functions affected by the project — R&D, marketing, sales — from the very beginning. "One of our keys to success will be that they've been part of this right from the start," says Luby. "They've seen us. We've documented things, passed it back after them, kept them in the loop. They knew what we were doing, and we've had them involved in project meetings and product meetings."

Luby did not discuss the total cost of the data synchronization project, but he did say that putting in this new process basically came down to a cost of doing business, at least initially. "This first project is to cost effectively meet external requirements," he says. That said, Luby believes the solution will lend a certain competitive edge to McCain, at least in the near term. "When someone wants to know this or that, we can quickly respond to them, versus someone else who has to dig through their systems and has to tell the customer, 'We'll get back to you in a week or month.'" In today's business environment, he notes, delays in providing information can result in missed sales opportunities and lost revenues.

Such projects, of course, hold the potential for ancillary benefits, as well, such as increased efficiency through the elimination of manual and duplicated effort, in addition to higher quality data. A.T. Kearney, for example, has reported that some $25 billion to $50 billion is lost each year due to supply chain information inefficiencies born of poor vendor-retailer data synchronization, and the consulting firm has estimated that 30 percent of item data in retail catalogs is in error, at a cost of $60 to $80 per error. Clearly data synchronization holds significant potential for new efficiencies and savings.

As for McCain Foods, once the company gets the solution fully rolled out in Canada, additional divisions may be tapped for implementations, too. This type of "trusted source" could be quite useful, for instance, in Europe, where companies like McCain must contend with customers and entities in multiple countries, and in the United States, where data synchronization is gaining momentum. Even within the Canadian division, Luby says the company sees opportunities for additional uses of the solution, although he declined to go into any details.

Regarding the experience working with FullTilt, Luby had this to say: "I've got a lot of respect for them for doing what they say they're going to do. They're meat-and-potatoes kinds of guys." Which is high praise coming from the world's largest processor of French fried potatoes.

Loading