It's not luck ... and much more on business problems

As I have previously written, my lecturer in Organisational Behaviour suggested that we read a business novel called "The Goal" by Eli Goldratt. Eventually the penny dropped and I ordered the book. After reading it, I came to the conclusion that every MBA student should read it, even though at times the book seems antiquated. I have also recommended to people in one of the companies that I support that they too read it. It transpires that there was a plant manager who worked there only for a short while who also recommended the book and even read extracts to his managers.

After rereading the book a few times, I decided that it was time to read its sequel,  "It's not luck". Despite USA Amazon promising a delivery date somewhere in June, the book actually arrived about five days after having been ordered (rule #1 in business: always outperform one's promises). As usual, I read it far too fast to absorb too much, so I'm going to read it again in the next few days, taking it slower and trying to think about what is written.

As a novel, it's far less successful than "The Goal", although there is a clearly defined protagonist (Alex Rogo) and a problem to be solved. Although this is touted as a sequel, there are several tools used by Rogo whose source is never explained. These are clearly tools derived from the Theory Of Constraints, Goldratt's contribution to management studies, but their derivation is not described in the same way as in "The Goal", which made the early chapters somewhat frustrating. Maybe there is another book which is a true sequel to "The Goal", or at least a true predecessor of "It's not luck".

One of the more charming aspects of "The Goal" was how Rogo's private life provided several examples which eventually became paradigms for his industrial success. In "It's not luck", Rogo uses the new business tools for solving problems in his personal life; whilst this might be more realistic, it is less engrossing as a novel. Writing management books as novels is definitely a good way of enabling the brain to absorb what are sometimes complex issues. I shall be on the lookout for more such books.

After finishing the book and reflecting on how I can use the ideas presented within, it becomes clear to me that I am too low on the corporate level - or at least, not in a chain of command post - to do very much. Even though I work for what is essentially a holding company which is running three or four different companies, our scale is much much smaller than the companies discussed in the books. Actually, this smaller size should be to my advantage as there are fewer levels of beaurocracy and I have a direct line to the company's president.

My problem is more that I think on too low a scale: I think mainly about computer problems and how I can solve them, not on the corporate strategic level. In order to solve this problem, I am studying for an MBA; the final course - strategic planning - is supposed to give me the necessary tools and vision.

At the moment I am engrossed with three different problems at work, two of which are championed by the president. One is an attempt to improve the throughput of one factory - or rather, reduce waiting time for orders before beginning production. I have done the necessary development work to enable this system to be implemented in our ERP program; that's actually a joke, as the ERP program can easily handle what needs to be done, and in fact was designed to work in this "new" way. This factory had implemented change after change in order to force the program to work in the way that they wanted it to work. My job was to maintain their way of looking at things whilst making the program more flexible. After a few false starts, I realised about six weeks ago that the solution was actually simpler than I had originally thought, and the implementation was done quickly. My problem has been convincing the factory managers to use the new system. The president has given his political clout to the change, but I am convinced that the managers are only paying lip service to the ideas and are not using the new system to its full potential.

The other problem is using an external program to perform design work. An ERP system whilst being flexible in certain respects is also very rigid: there is no such thing as a parametric bill of materials - yet this is exactly what is needed if one is building wooden tables, whose length and width can be tailored to the customer's needs. This external program is designed from the ground up to be parametric - but of course only replaces one module of the ERP program. Thus it is my job to 'glue' the two together.

This program does export several files, but it turns out that all of them bar one are useless. The only useful file - and it contains all the information that I need - is in HTML format, which is not the most conducive to parse. Suffering a lack of time, it was only on Tuesday that I managed to give serious time to the problem. It became obvious to me that I could read the HTML file with Excel and then save it as a CSV file, which made parsing much simpler. After about an hour, I had written a Delphi program which could parse the file and output a text file holding the bill of materials which could serve as input to the ERP program.

As it happens, on Wednesday was held a divisional meeting, and the subject of integrating this external program was raised. I was able to report on my progress, and pointed out that we had received a price quotation of 5,500 euros to do what I had done in one hour. On the basis of this, I suggested (somewhat tongue in cheek) that my salary should be "only" 4,000 euros per hour, but that I was willing to settle for 4,000 euros a month.

On Thursday, the implementation team had another meeting in which we attacked the problem of how the factory was going to integrate this external program. It soon became clear to me that there was a major problem that we had not considered, the problem of producing a delivery note from the ERP program. I don't want to go into details, because most of the problems derive from the way that this factory produces delivery notes. If I were Alex Rogo, I would change this system immediately, but on the other hand, it won't make any difference to our bottom line and so the change is not needed.

The needed insight was that writing a program that simply interpreted a csv file and exported the information contained in a suitable format was not enough. The program has to receive a certain amount of extra information and impart much more information to the export file. Writing the program won't be too difficult; what was necessary was the insight. The other members of the team seemed somewhat lost at what I was suggesting (although one caught on fairly quickly) and it took a great deal of persuasion and explanation before they understood the problem and how I proposed to solve it.

After the meeting I wrote a proposal which explains the problem and how to solve it without going into specifics. Then I went into very specific detail and explained - mainly to myself - how to implement my idea. I will have to put my money (or rather, my brain) where my mouth is.