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.