ERP in food processing companies

Different companies in different industries have different problems, although most 'full-function' ERP systems can cope with the majority of them. It certainly helps that many components of ERP systems are used in much the same way, regardless of industry. Finance department requirements are pretty much the same in any industry (and will stay that way unless someone invents triple-entry book-keeping!), whilst Customer Relationship Management (CRM) systems don't care who the customers are and what they are buying. Additionally, most products are bought and sold as discrete items, be they items of furniture or items of clothing; electronics or car parts. Some items are liquids or powders but, if not sold in bulk, are generally sold by individual pack size (e.g. soft drinks, soap powder, jars of coffee etc). Others, such as fresh foods, may be sold by weight and the consumer is not generally concerned with how many peas, tomatoes or whatever they get for a given weight.

Challenges of ERP in food processing

Many meat products present a different challenge because they are sold in one unit of measure and priced in another. This happens with other types of product such as steel bar, reels of cable and divisible packs but, with these, there is a recognized and constant unit of measure conversion that can be applied, because a given radius of a particular steel bar will always weigh the same for a given length, a particular reel of cable will always have the same length, and a pack of 50 items will always contain 50.

The problem with meat is that, when Mother Nature gave us, for example, chickens, she neglected to ensure that they were all of a standard size. So when a consumer goes to purchase a whole chicken, they can't ask for a given weight of chicken: the best that they can do is to aim for one of the approximate size that they are looking for and then pay for its weight.

Check out our food ERP comparison tool to find the best food and beverage ERP

From an inventory control point of view, the supermarket needs to know how many chickens it has in the warehouse but, from an inventory value point of view, it needs to know what weight of chicken it has in there (the actual numeric quantity is actually irrelevant). This means that every transaction must be recorded in two units of measure; representing quantity and weight, and that means that the ERP system must offer functionality known in the industry as 'catch weight'.

There is another challenge for ERP systems that meat processors have to overcome, and it is one that MRP (Materials Requirements Planning) systems have to stand on their heads to deliver. Most manufacturers take a number of items or ingredients and bring them together to create a finished product. But supermarkets also sell chicken thighs, chicken wings, chicken breasts, chicken soup and much more. Meat processors actually create product by 'disassembling' one item (i.e. the chicken) to make many more, and they will boast that the only part of the chicken that doesn't get used is its 'cluck': even things like the head and feet get processed and find their way into pet food to ensure that nothing is wasted.

These are not problems that are restricted to meat processors and several other industries have to overcome them too. Take dairies that receive raw milk which they then process to produce full fat, semi-skimmed and skimmed milk; along with butter and yogurt. And dairies have two extra problems: one is that the fat content of milk can vary from batch to batch (so the quantity of milk required to produce a given weight of butter varies continually) and the second is that they are contracted to accept all that the farmer delivers, and that quantity varies day by day and from herd to herd.

Product and ingredient expiry date control is, as in other industries, key. Obviously, the system should not allow allocation or dispatch of items beyond their expiry date, and all full-function ERP systems will offer that facility. But it can sometimes be overlooked that foodstuffs usually have two significant dates: a sell-by date and a use-by date. Not all systems support both of these. A further complication is that many customers demand a minimum shelf life remaining when they take delivery of products; so companies are likely to get short shrift if they deliver product with a sell-by date of 'tomorrow' or anything like it, and the minimum shelf life remaining can vary from customer to customer.

One last but very important consideration: like many industries, such as aerospace, pharmaceuticals etc, foodstuffs have to have rock-solid batch control for traceability purposes. If an end product is found to be faulty, the first thing that is necessary is to establish where the rest of that batch of product went so that it can be recalled; and that could mean a number of different shops or stores. 

But traceability needs to go further than that. For processed products, it has to be able to identify which batches of ingredients went into those products and then which other products, and which batches, those ingredients were used in; and it potentially has to do that at several levels of the recipe or bill of material. For example, some ingredients may have been used to make a batch of sauce that was then used in several products. All of those batches will be suspect and must be pulled from store shelves and recalled as quickly as is humanly possible: the industry views the health of its customers as paramount and speed of reaction is vital.

So perhaps, in comparison, manufacturing widgets aren't quite so difficult after all!