One of the factories in my company works with wood: the first step in any process is to cut the planks into pieces of the correct size as needed for production. The planks normally are sized 2.44 X 1.22 metres, so several parts can be cut from one plank. Laying out the parts on the plank is a specialised job: someone who does this well can save a great deal of raw material. Naturally, this is a job for a computer - this kind of program is called an optimiser.
The optimiser too has its raw materials: the dimensions and quantities of parts which have to be cut. This information comes from our ERP program and is manually entered into the optimiser. Someone wondered whether it would be possible to create a file in the ERP program and then input the file into the optimiser, thus optimising the operative's time and reducing the number of mistakes. This is where I came into the picture.
"Is the optimiser capable of reading an external file?" was my first question, and when it was answered in the affirmative, my next question was "What is the structure of this external file?". The answer to this question was a long time coming. I started by analysing the structure of existing files; whilst I could see that there was a definite structure, its details weren't clear to me. The next step then was to contact the manufacturer of the optimiser program (in Italy) and obtain the necessary technical data.
Unfortunately, it seemed that the defined structure was not equivalent to the structure that I was observing in files which had been created by the program itself after the data had been entered manually. There were hundreds of attempts made to create a file in the correct structure but I could never find the correct format.
At one stage, I seemed to be making progress, only to receive a letter from my Italian contact which ended with the words "oh by the way, today is my last day at work with .... From now on, please contact X". Ouch.
To make a long story only slightly shorter, we eventually received a new mapping of data, and suddenly my files were being accepted by the optimiser. The values weren't particularly correct but at least I could see what needed to be replaced. After a few more attempts (I should point out that I am about 150km from where the optimiser is), I eventually found the magic format!
So we've now saved a great deal of work - the user can run a report in ERP, run my program on that report and create a file which can the optimiser can read. Can this be improved? I was idly thinking about this last night when it occurred to me that I can minimise the overhead even more: have the ERP program create its file then call my program to read this temporary file and then output an optimiser file. From my point of view, it's five minutes work, but from the user's point of view, it minimises the overhead.
As it happens, today I have been involved in implementing something else which promises to reduce overhead: our delivery notes will now bear a barcode (the delivery note's number). When we receive the delivery note signed by the customer, we scan the note in a scanner which is connected to special software; this software then assigns the scan to the delivery note in the database. If we had wanted to do this in the past, I would take the signed delivery note and scan it with a multi-function printer which sends me the scan as a pdf file via email. I would then save the pdf file in a directory and manually tell the erp program where the scan is. This would take about five minutes per document; this overhead has now been cut to around ten seconds (although of course we have to pay for the privilege).
It occurs to me that before starting work on the barcodes, I helped someone else minimise their overhead (maybe I should change my job description!). It began with an innocent question of how to get a inventory list for a given warehouse where the status is 'Goods'. It might be that the user was using the wrong report for this, but that's not the point; I showed her how she could get the list directly from the warehouse. Then I was told that she wanted to make a list of old work orders for these parts. My immediate reaction was to ask why; who needs a work order when the parts (chairs) already exist. "X needs the work orders so that he can print labels for them" was the reply. For every chair which is made, we print a label (which is stuck on the underside of the chair's seat) and it's easiest to source these labels from the work order.
Once I had got that straight, I pointed out that one could simply print labels for a given list of parts without having to find a work order. People are so used to a rigid set of rules that they don't see what lies behind those rules and procedures. It turns out that they had been dancing this dance every few weeks; hopefully now I will have minimised the overhead for them and saved a few minutes which can be spent on more useful pursuits.
No comments:
Post a Comment