Perpetual MRP – Turning on a Sixpence


In the summer of 1987 I was sent to Hungary by my employer, as a programmer/consultant, to implement the first full MRP-II package behind the Iron Curtain. Hungary’s economy was then the most advanced in the Soviet Bloc and the Government was eager to improve the efficiency of its manufacturing (the Communist Party still believed that its socialist utopia could yet outdo the capitalist world). My task was to adapt the British software package that I’d been working on in London so that it could run on such hardware and operating system software as the Hungarians had access to.

MRP-II was then a standard for the planning of manufacturing and the resources it requires. An MRP-II system is used to specify the constituents of a final product, the constituents of those constituents, and so on, until there’s a complete ‘bill of materials’ defined for each product The system also ‘knows’ how much time each semi-finished item takes to make, the proportion of components and finished items that will be discarded (scrap and yield), and the man and machine hours involved in the process.

It’s a model of the manufacturing process, and once you’ve fed in how many of each final product should be made, and by when (and of course, by whom), the system can then calculate how much of each constituent must be ordered (either for internal manufacture, or from suppliers), precisely when they are required, and when each step of the manufacturing process should begin.


The Videoton factory in Szekesfehervar, 70 km from Budapest, where I was sent to work, was making televisions under license, if I remember correctly, from Samsung. They were modern enough for the time and for the Hungarian market. But what wasn’t modern enough was the computer hardware we had to make the system run on. I doubt the entire mainframe computer had as much memory and processing power as the PC I’m writing this on. CoCom regulations at that time severely restricted the flow of fast computer technology and sophisticated software into the Soviet sphere, and Videoton, a sprawling socialist conglomerate, was known also to be involved in the electronics of weaponry.


MRP-II needs serious computing power. When MRP-II packages are doing their calculations they start at the top of a bill of materials and work down, level by level, calculating at each level the components required, taking account of all orders on which work has already begun, and current inventory levels. The in-memory databases of today would probably do the whole thing in a minute or two, but back then, on an out-of-date smuggled IBM machine the process took hours. And when these calculations were running, all other interactions with the system had to stop.

So we were hugely disappointed when we first ran the process for the assortment of televisions Videoton was producing to find it took 22 hours to complete, leaving, in theory, just two hours for the factory to follow the system’s instructions. Not enough time.

Of course, that assumes that the process would be run each day but that’s best practice. MRP-II ‘idealises’ the manufacturing process, but in reality, customer orders, bills of material, scrap factors, yields and manufacturing times vary, so constant (at least daily) tweaks to quantities and timings are needed.

What to do?

Well, programming wise, this was the proudest moment of my career. I invented ‘perpetual MRP’. It was clear that there would never be enough time for MRP to run from top to bottom, so I suggested that the MRP calculations need never end, that the system should simply cycle for as long as possible, stopping and resuming according to the time available. Once it got to the bottom of the bill of materials it should start again at the top, picking up changes in order quantities and stock levels at each level as they are found.

So I changed the MRP program so that it could be ‘told’ when to stop (usually 6.00 am in the morning, so that the system would be ready for the first manufacturing shift). When restarted late in the evening, at the end of the second shift, it would simply pick up where it left off. This way it would usually manage three or four complete cycles each week.

Not perfect, but good enough. As you might expect, the system was always out of date, always trying to catch up, but then MRP systems are always, of necessity, out of date. They are a simulation, a model, not a precise prediction or description of the actual production process. We had only a sixpence of a computer to turn our algorithms on and yet we made it work.

After 1989 and the end of Socialism in Central and Eastern Europe Hungarian companies obtained better-performing hardware, and I imagine they could then run a complete MRP cycle every night.

But sadly, the relaxing of barriers to import also meant that the population could buy ‘Western’-brand televisions of better quality and at lower prices, and within a year or so the company was out of business.

It was great fun whilst it lasted.

Rare and Precious Creatures


I had lunch today with a former colleague. She was, when she worked for LLP Group, one of the best business IT consultants in the world, at least in the world I knew and know, which wasn’t small then, and isn’t small now.

She was, and is, meticulous, imaginative, extremely clever, pragmatic, and determined. She knows what can be done and how to get people to do it. When she worked for me, and on some projects with me, she travelled to Asia, to the Middle East, to Latin America and elsewhere, and learned about cultural sensitivity too. Of course, she wasn’t perfect, but I’ve long since forgotten the imperfections.

In the end, she was too good for us, and we were too small for her, and she left us to work for a large bank in the Czech Republic. There she manages enormous development and implementation projects.

Not my former colleague, I can assure you….but equally rare and precious.

rare and precious

From time to time we meet for lunch to catch up on family things, world affairs and, because they still interest us both, professional matters too. Amongst other things we talked about how hard it still is to find those rare and precious creatures in our profession who are really good at designing good business software systems.

The problem is in bridging the gap between those who have the business ideas and the business vision, and those who understand the precise world of IT systems and know how hard it is to go from idea to system. The job of the systems analyst lies between these two worlds, but finding good people who understand both sides of the chasm is really hard and I see no sign that it’s got any easier in the last twenty years.

A good analyst must grasp the essentials of what the ‘business’ wants, and what a system must be like to be usable by people who are not IT nerds. Such people are most easily found in the ranks of business tacticians or those who work in business operations.

A good analyst must grasp the essentials of what IT systems can do, how rigorously the rules must be defined, how information can be stored and transmitted from one place to another, and how difficult it is to program software. Such people are most easily found in the ranks of IT specialists.

Rarely can you find someone who isn’t very much more one type of good analyst than the other.

To mitigate this problem practitioners have adopted more flexible methods of development and design, such as the ‘agile’ method, whereby ‘users’ and ‘developers’ are more frequently brought together so that what one side thinks it’s understood, and what the other side thinks it’s asked for, are more frequently compared. The old ‘cascade’ method of finding out what’s wanted, building it in a remote laboratory and then bringing it back, finished, just doesn’t work. Probably even less successfully nowadays because business systems have become ever more complicated, and must be ever more easily usable by ordinary people.

But although ‘agile’ methods are better, they don’t eliminate waste. With iterative design and development procedures you move ten steps forward and then three steps back, so there are plenty of costly steps that you wish you hadn’t taken. A good analyst will save you perhaps two of these wasted steps.

I don’t see a better solution than finding the best possible people for the job, and neither does my former colleague. Method only gets you so far.

So where can we find business analysts who understand how to design good business systems? The skill can’t be taught. You can’t itemise it on a CV. Some recruits can’t even learn these skills from experience. It seems to me that it’s a matter of talent, of art. You might as well try to identify a good pianist from some words on a page.

Such people are rare and precious creatures. Hold on to them tightly..

The Necessity of Agility


I’m a nuisance when it comes to system design because I can’t get things right first time. I feel guilty, of course, because asking that things should be done again, or done differently, costs us time and money, and I really ought to be able to get it right at the start, if only I thought about it more carefully.

But, better that I should raise issues now rather than later when it’s too late.


Last Friday I was reviewing the new browser-capable version of invoicing that we’re developing for Version 4.9 of time@work, due out in September (or so). Our invoicing module is complex (I should say ‘sophisticated’ really – it’s the right salesman’s euphemism) since our system is multi-company, and invoicing allows recalculation, discounting, exclusion, addition, rounding and all sorts of other features. Producing a .Net browser version has taken months, but we’re nearly done.

It all began some months ago when I sat down with our systems analyst and looked at the mock-up he’d produced. This followed some hours of discussion over the previous days. The mock-up allowed us to click through the invoicing process, from one dummy screen to another, ‘trying out’ how invoicing might look. Our invoicing process can involve about six different pages, and we’d thought very carefully about what fields should be where, and how to reduce the end-user’s clicks and make the whole process as intuitive as possible..

But, despite that, a mock-up isn’t real, so, to our developers’ dismay, when I looked at the system on Friday, with real data and real programming logic behind the screens, it didn’t seem so easy to use as we’d thought it might be, and it was obvious to me that we’d made a few mistakes.

Years ago, when I worked for Coopers & Lybrand Consulting Services in Budapest I went on a ‘Summit D’ course which was all about systems analysis, specification and development. I was taught the typical ‘cascade’ method. Each phase must be completed before the next phase is begun. Once systems analysis is complete, a requirements document must be produced that the end-users will sign off as correct, then a system specification, and then you build the actual system. Not much room for revision. When the system is complete, it’s take it or leave it, and ‘this is what you signed off on!

But we’re human and our imagination is limited. We need to touch and feel things before we know they are right. So, nowadays, I much prefer the ‘agile’ method of system development or system implementation. You engage in repeated demonstrations and mock-ups and at every stage you allow for revision and successive approximation to what is really needed. The end-user sees what he’s getting long before the system comes out of the laboratory. Of course he’s never HAPPY but he’s less UNHAPPY this way!

True, without careful control this can be an expensive method, but it’s certainly cheaper than delivering a big, expensive, system to users who find it totally unusable.

So, though I feel guilty from time to time at contradicting myself and asking for change, I know that it’s inevitable, and it’s the best way I know. So, forgive me, designers and programmers. And, after all, it’s not as if you don’t occasionally make a few tiny mistakes yourselves.

Here’s a happy user:

agility 2