Rotary Encoder for the Quality Inspection Machines

In my current job, we use several inspection machines that utilize some old fashioned but certainly accurate mechanical counters.  The operators, load the machines with jumbo rolls of finished fabric and inpect them meter by meter, by unrolling the roll and creating several smaller ones.
After finishing inspection, they type the meters for each roll inspected in a small self adhesive label and stick it on the fabric and also write down the number of deffects that were found on each roll. Although this procedure is not very time consuming, it happend many times, to write down the wrong data on the label. The result led to dissapointed customers that received the wrong amount of meters or deffects. Some years ago, I decided to write down my own code to automate this procedure. I actually rewrote from scratch some routines of a ready made software writen for a similar application and altered its code in order to automaticaly capture the meters of each roll and classify it according to the number the deffects that the operator found. For each deffect found, the operator had just to press an approriate deffect button and the rest of the job was done by the software.

The actual problem was the way to capture the data of the mechanical counter and automatically do the calculations for classifying the fabric. The solution was to create a small data aquisition system, that counted the pulses generated from a rotary encoder (instead of a mechanical one), translate them into linear meters and send them through RS232 to a PC. Although I used a ready made solution at that time, later I tried to make a small aquisition system of my own and install it into other machinery.

I used a 16F628A microcontroller and a small HD44780 LCD screen to print the data. Although this is something I made a couple of years ago, a friend of mine found it really interesting and I decided to demonstrate it here.

 

 

A New approach to the Service Level

Service Level is a very important performance indicator. According to Wikipedia (http://en.wikipedia.org/wiki/Service_level), when it is reffered as a quantity-oriented Service Level, it measures the proportion of total demand, within a reference period, which is delivered without delay, from stock on hand and it is expressed as a percentage.

In most cases, service level is predetermined and it is used as a basic parameter for calculating the Safety Stock.  In real practise, it is a MUST to assure that the goal is achieved and maintained, by measuring it  at a regular basis.

There are not many info you can find about it in the internet. You might get some fancy algorithms that won't help you much in your daily work. Most of the info that I have traced refer to the S.L. as the Expected BackOrders over the Expected Demand. That is very true but...you don't  actually measure what is happening but you rather express your enthousiasm on how well you are going to work. It is a predetermind goal and not an achievement.
 

After giving it some thought I realised that it is better to measure how things have gone in the real life. The key to do that is to find the actual backlog for a specific period. All the ERP's I've seeing do not offer such a report and the ERP that I use does not either. So how to measure it?

The key is to use your SQL knowledge and some VBA to do the trick in Excel. What I've done was to track every Order that the Sales Department had placed and then store in a spreadsheet the date that the order was issued and the initial delivery date that the order was given. These two fields are found in every ERP, large or small, and it is just a matter of few SQL querries to retrieve it. The next step was to perform an other querry to retrieve the Invoice that corresponded to that Order. Again all ERPs offer this kind of binding between Sales Orders and Invoices. And bingo! You can get the Supposed Delivery Date and the Actual Delivery Date. Subtract the two dates and what you get, is a backlog in days for that given period.

From now on you have several options. The first and easiest one, is to add the all the orders that were backloged (I prefer to use Units instead of Money), disregarding the number of the days and divide it with your total sales for the same period. Subract it from 1 and you'll get a robust percentage of your actual Service Level. So, say you had

$5.000 backloged and you total Sales were $100.000. Thus 1- ($5k / $100k) =95%.

While this is quite an orthodox approach, it is not enough.

What I prefer to do is to find the average number of days that the sales orders where backloged for every month and report it as a plain number. This is a very important indicator because it also shows how many days your customers waited more, than what you had commited, for receiving their goods. Since every customer complains even for a single day of delay, it is important to know if you had a Service Level of 95% over a given month and a backlog of 5 days than a 95% Service Level and 15 days of Backlog. The difference is huge!

The third thing and most tricky one, is to calculate the weighted average of your backlog in days. Since many different orders might be in backlog, it is important to weigh your numbers based on the order's value. So 10 orders worthing $10 each should weigh less than a $10k order.  To get this, just multiply every order's value with the number of days the order had been backloged and sum the results. Then divide this number with the total value of orders in backlog. The result is expressed in days and it is the TRUEST approach of your real backlog.

If you have reached this point than you can create many other interesting reports such as Service Level per Customer. You 'll find it very usefull when you have to decide (if there is no other alternative) which order to postpone.

P.A.

Introduction to MRP (published in Orosimo Software official site) - GR

http://www.orosimosoftware.gr/mrp-intro

Prioritizing Production Orders

If the capacity Planning and the Master Schedule expressed the reality, then prioritizing the production orders would be meanless, since everything would be done in time.

In real life thing things are different. There will be many cases where several production orders must be executed in a period that the capacity is not enough. MRP will not catch this problem, as it always assumes infinite capacity.

I’ve heard of many approaches basically applied on large ERPs such as SAP or SAGE but in my case, there was no way of prioritizing.

After giving the issue some thought, I decided that all that was really needed was a priority FLAG. The user could just see the flag and manually give priority to some orders against some others. The idea came back from my days in the army. We had four priority levels on every military document that signified the level of urgency. Check on Wikipedia to see what I mean (http://en.wikipedia.org/wiki/Message_precedence).

In my case, three priority levels were only necessary and this is what I’ve done:

·         Immediate (I) :  High-Priority

When Stock-Reserved <0

·         Urgent (U):  Medium-Priority

If not “I” and Stock-Safety Stock-Reserved  <= 0

·         Routine (R): Low Priority

When it is not either “I” nor “U”

The “I” flag signifies that a SKU has a stock level which is lower than the pending orders, that will due in the current time bucket. If you don’t react immediately then you will just increase your backlog and receive complaints.

The “U” flag signifies that your current stock is enough for fulfilling the pending orders but after fulfilling them, it will be dropped below the safety stock levels. This is a sign of alertness. Safety stock is supposed to be carried from period to period in order to absorb any failure of the system, to fulfill the demand. It is a wise idea to release a production order while the SKU is still on a “U” state.

Finally, the “R” flag signifies no special alertness. Your pending orders can be fulfilled by your stock and even after fulfilling them your safety stock will be enough to absorb any other shocks. There is no hurry on producing this SKU but it should be produced as the MRP is committed to the MPS.

What you see above is an IF…Clauses statement, that can be very easily calculated even “on the fly” from an SQL query. A sorted report can be generated and the user can easily choose to release first, the production orders with the highest priority level.  

 

Top KPI to check your Production Planning Efficiency

 

Top 5 Key Perfromance Indexes, for the Production Planning Manager:

1. Inventory Turnover
2. Average days to sell inventory
3. 
   
4. Weighted average of backlog in days
5. Average Actual Lead Time Over Standard Lead Time

Use Quantities instead of Money for Inventory KPIs

The accounting formula of Inventory Turnover is Cost of Goods Sold / Average Inventory. To find the COGS you have to use the following equation: Cost of Goods Sold = Beginning Inventory + Inventory Purchases – End Inventory

While this makes perfect sense, in real word the calculation of COGS is little more complex and
several inventory valuation methods are used, such as FIFO, LIFO and Average Cost. In FIFO we assume that the oldest units of inventory are always used first. In LIFO we assume that the newest inventory is always used first. In the Average cost method, the beginning inventory balance is used and the purchases all over the year in order to determine an average cost per inventory unit.

This might still sound easy but remember that in most cases, the repeated purchases of a material, take place with different prices all over the year. So you cannot just divide the inventory balance with the last price because you’ll get a wrong result. In addition, if you don’t purchase but produce a material, estimating its cost is a far more complex procedure and many things should be taken into account such as the Cost of the Raw Materials, the Cost of Labor, the Manufacturing Overhead and the Depreciation Cost.

Most ERP systems do not provide these values “on the fly” but only at the end of the year, when the Balance Sheet is created and the Costing Process is executed.

If you are a Manager who needs to track the Inventory’s KPI, the easy way out is to use Quantities instead of Money.

• Inventory Turnover= Sales in Quantities / Average Inventory in Quantities
• Average Days to Sell Inventory= 365 / Inventory Turnover

Direct Material Costing through BOM explosion

There is often a case when your supplier suddenly changes the price of a material you purchase. The question that arises is how much this change is going to affect your direct material cost. Some ERPs might offer the capability of “What if” analysis while some others don’t. If the second is your case, the easy (or not so easy) way out, is to perform a BOM explosion in an Excel spreadsheet for the SKU you want to check and try to re estimate the total Direct Material Cost.

To do this you have to be an advanced SQL user and have an understanding of Database management and of course Excel and VBA. The trick is to make a connection with your Database Server and perform a recursive query in order to extract every component of your BOM tree diagram. After doing this, you can then change the price of the material which interests you and find out how much it affects the total material cost.
When I faced the same problem I decided to write some routines of my own. I made an "Excel Add In" that presents a form with the tree diagram. There I can easily insert the new price and re estimate the cost without even sweating.