Data synchronization issues are no small potatoes for McCain Foods, especially when it comes to improving customer service and gaining competitive advantage.
[From Supply & Demand Chain Executive, April/May 2004 ] 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 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. 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.
What's the Hold Up?
The dispersion of product information throughout the company has complicated efforts to meet customers' requests. Much of McCain's product data resides in the company's enterprise resource planning (ERP) system, but a good deal of the product attribute information sits in disparate systems in Excel spreadsheets or Access databases. 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.
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. 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.
Eventually, McCain decided to move toward establishing a centralized repository for the company's product information, starting 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 incorporate transformational capabilities so that users could set up customized, 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 finally settled on an application called I-Accel from solution provider FullTilt, which 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 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 went live in February for retail products, feeding weekly updates to ECCnet for 300 attributes, as well as the company's Canadian Web site, mccain.ca. The solution will not replace the company's 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.
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. Currently McCain intends to populate the database with just under 100 different attributes for some products to several hundred attributes for others.
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 to generate completely new views.
McCain's implementation team has worked to ensure acceptance of the new repository by bringing in the different functions affected by the project — research and development, 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.
Luby believes the solution will also 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. 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.