Priority, our ERP program, prides itself on having a very strong MRP module. This is a program which scans all the open customer orders then issues work orders according to when the goods' delivery dates; it can combine work orders if the same part is needed for several orders and can also issue purchase recommendations. In a sense, it is the basis of any manufacturing ERP system and ours is very good.
In the chair division, there is a clear separation between parts which can be produced in bulk and parts which can be produced individually. If there is an order for 100 chairs with a metal frame, 10 chairs per colour, then the metalworkers can produce 100 frames at one go, but the upholsterers have to produce ten sets of different upholstery. Thus it makes sense for the metalworkers to produce items in bulk and store them in inventory, whereas the upholsterers and the final assemblers work only on ordered items. For a bulk part, we define a minimum quantity and a bulk quantity: when the quantity of the part falls beneath the minimum amount, the MRP program is clever enough to issue one work order for the bulk quantity (if not more). Obviously such work orders are issued maybe once a week. In order to do so, the MRP program has to check inventory and outstanding purchase orders, which takes time.
But in the furniture division where everything seems to be bespoke, there is no concept of producing bulk items for inventory. When a customer order comes in, work orders have to be issued for every single part which has to be manufactured. So here one doesn't need a very clever MRP program.
Unfortunately, for reasons which I have never understood completely, the man who runs the production facility in the furniture division (let's call him Vladimir - ruler of the world in Russian - but not his real name) was running MRP maybe ten times a day. This requires a large amount of computer processing, but more importantly prevents anyone else from running MRP at the same time. There is a third division which uses the same database as the furniture division; until recently, they have been "ERP free", but finally they seem to be moving into the computer age. These multiple runs of MRP are causing them havoc.
At the moment, the furniture and chair divisions work on separate databases but there are moves afoot to combine them into one humongous database. When this was first mooted two years ago, I did a feasibility study and saw that there was only one real problem which could prevent the integration - MRP.
Talking this over with my consultant, he suggested writing a work order generator which would function outside of MRP; it would issue work orders but not check inventory levels or anything clever. Several times I have tried to get this suggestion adopted but have never succeeded. I felt that the major reason for my failure was that the word 'change' does not exist in Vladimir's vocabulary. He seems to be content to run things 'the way that they have always been run', whether or not that is correct. Systems and goals change, but Vladimir keeps on in his groove. God forbid we should change how work orders are created - we might not output the correct work orders! [I should note that I suspect that some parts are produced without work orders, so this apparently strict adherence to the need for work orders seems strange at times. There are also plenty of furniture parts which don't have a bill of materials and so don't have work orders at all.]
I had written a simple work order generator for the third division which was sufficient for their needs but not enough for the furniture division.
The company's CEO heard rumours of problems running MRP and so called a meeting; Vladimir and his manager tried to cancel it. I don't know whether this was done innocently, believing that there was no problem, or deliberately in order to maintain the status quo. Whatever, the CEO ruled that the meeting be held and held it was. First, Vladimir explained how he works at the moment, after which I said, "Yes, this is how they work. It doesn't mean that they work correctly". I explained how the proposed work order generator would function, and the representative of the third division said that his simple generator works well.
I must have been persuasive enough for the CEO to decide that we would try to work with the work order generator! To be fair, Vladimir and his manager took the decision well and didn't try any stalling tactics which might be understood to imply that they had ulterior motives - or in other words, maybe the word 'change' does exist in Vladimir's vocabulary after all.
After the meeting I looked at the simple generator which I had already written and saw that I would have to extend it to handle multiple orders. This took a few hours of false starts and problems but this morning I had a program which I could test. I tried it out on a few simple examples, finding a few problems and fixing them. Then I tried it out on a more complex example and the generator passed with flying colours. At this stage, I passed it on to Vladimir for further testing. He found some problems, most of which were due to bad data (parts which had some wrong definitions); I fixed each problem and returned the generator for further scrutiny.
During the test process, I saw how I could simplify matters in the future; this requires a new field in one of the tables, so tonight I'll add the field (I can't do this when people are working) and tomorrow I'll update the generator to use this new field.
During the day, the CEO mailed us asking Vladimir when he would put the generator into production use (the CEO has little patience at times, but he also might have thought that the generator was ready for use instead of being debugged). About an hour ago, Vladimir wrote in reply: after a number of tests in our test database, I have begun to use the generator in our production database. If I find any strange behaviour [ie bugs - NN], I will pass them on to No'am for checking and correction. Generally speaking, it works very well indeed and I haven't come across any serious problems.
Who would have thought it? Vladimir actually going on record about a change (and a fairly radical one at that) working very well and almost instantly embracing it! Maybe I misread the person after all. But it all goes to show that change will be embraced when the user realises that the change is designed to make his job easier as well as everyone else's.
As far as I am concerned, this is one of the most radical changes which I have ever made in the way that we use Priority, and I'm pleased that the political side was so easy. Of course, it does help that Priority is so flexible....
No comments:
Post a Comment