Are you guilty of any of these data flow blockades?

A modern ERP system is an amazing thing to behold. A materials manager can look at a screen and know what to buy, and when. This can be achieved with confidence, without a spreadsheet and without a meeting. Someone in order entry can check on a realistic promise date for a product that hasn’t begun to be built yet. Again, there’s no spreadsheet and no meeting needed to accomplish this.

These things (and many others) can be achieved because the integrated ERP system is designed to be a real-time system. What this means is that as transactions take place in the ERP, you see their effect immediately. For example, once a purchase order receipt is entered, the corresponding inventory is immediately adjusted—otherwise known as real time.

Before the development of real-time ERP systems, transactions were collected one by one, then a routine was initiated at a specific time to process all the transactions. This is called a batch system. In a batch system, you are always looking at aged data. But, hey, at least you have data. The development of batch systems was a big step forward. Real-time systems were the next big step.

Just because an ERP system has the capability to provide you with real-time information, doesn’t mean that you’re getting it. You may have processes or procedures that delay the introduction of data into your ERP system. In effect, this turns your real-time system into a batch system. I’ll describe two of the biggest mistakes companies make which result in this technological back pedal.

Paper labor reporting

I’m a big believer in labor reporting for SMB manufacturers. I have managed departments, divisions, and entire plants with and without labor data. It’s much, much more difficult to perform those roles without labor data. It’s not exactly driving blind, but you are impaired. So, let me start by saying if you are doing labor reporting on paper, I applaud you for understanding the importance of that information and doing something proactive to get it. Bravo!

Here is the problem, though. There is a delay between someone filling out the form, and entering that information into the ERP system. The delay is usually about one business day. If you’re only using the information for costing, and the only people looking at the information are those who are preparing financials or analyzing closed orders, that delay is no big deal. The data doesn’t need to be real time because it’s only being used to look in the past at things that already happened.

But what if you are responsible for managing production? You live in the here and now. You need to know the amount of work that still needs to be done and where a job stands. You need to manage capacity and schedule the shop. The data you have is at least a business day old. Can you work with that data? Sure, but it just makes everything harder.

It's also the most expensive way to collect and enter labor data. What’s a better method? Barcode labor reporting is the way to go. In the time it takes someone to fill out a form, you can scan labor transactions right into the ERP system – it’s real time! And there’s no data entry the next day.

Related: 6 Shop Floor Management Techniques Learned From 30 Years of Experience

Related: 3 Manufacturing Efficiency Metrics & KPIs

Purchase order receipts

When a truck pulls up to your dock to deliver goods that were requested via a purchase order, those goods need to be received into inventory. In some organizations, the dock worker opens the packing list that comes with the delivery to confirm the quantity received. This is usually done by writing the received quantity next to the shipped quantity on the packing list. Then, at some point during the day, all those packing slips are delivered to accounting. At some further point, the receipt of goods is entered into the ERP.

By now you can probably see this delay turns your ERP from a real-time system into a batch system. From an accounting standpoint, this works fine. They only need this information when they receive the vendor’s invoice.

But on the production and inventory control side of the business, this delay is a problem. Perhaps production has been waiting for the material and they want to issue it to a job. The ERP says there is no inventory to issue, even though production is staring at it. Another issue is this: Maybe purchasing canceled the P.O., but the vendor shipped the goods anyway. Accounting will realize the goods never should have been shipped to you when they enter the receipt into the ERP, but now you are in possession of it.

All this can be solved by receiving the goods at the dock. If the P.O. has been canceled, the dock worker will know right away. If the PO is valid and they do receive it, they can turn around and issue the goods to a work order or ship it against a customer order. Ultimately, the data is flowing like it should.

One barrier accounting usually brings up about performing these transactions at the dock is that the dock workers will do it wrong. Sure, that could be true. The solution is training. Accounting is already entering the data that the dock workers provide. Let’s cut out the delay.

Timing is everything

Here is the takeaway: Tell your ERP what you are doing, when you do it. Anything short of that creates a delay and turns that part of your ERP into a batch system. It’s a pretty simple concept, but you may have trouble creating the new process. No problem, we can help. Just let us know.