What are the benefits of ERP enhancement?

Continuing this series of blogs about what I intend to propose as a new topic for my doctorate, today I want to leave the taxonomy of enhancements and think about what results I am supposed to achieve from the research. The title states that "benefits" - whatever they are - are to be examined. As one reviewer overlooking my work wrote at one stage (I don't remember exactly where) - let us not forget that this is a doctorate in Business Administration; there should be some effect on the bottom line.

My current thinking is that in an interview, I would ask "Can you give examples of enhancements which have been created for your system?" (after explaining what enhancements are). The interviewee would ideally give an example, which I would classify according to my taxonomy. I would then ask how the company functioned in this area before the enhancement and how it functioned afterwards. Finally I would ask what benefits the company has obtained from the enhancement; the obvious benefits are time saving and improvement in the ability to manage processes. Hopefully there will be more, which I haven't thought of. The interviewee would ideally give several examples.

Time saving can also be equated to money: the development of the enhancement cost money (consultant's fees) which hopefully is a one-off cost, whereas the time saved (which possibly translates to employee salary) is a constantly recurring saving. I doubt that any jobs have been lost due to ERP enhancements, but maybe enough savings can be combined, thus allowing overheads to be reduced.

One benefit arising from "the ability to manage processes" would be a reduction in inventory (this was certainly the original aim of my work with WaterCo), which translates directly into money. Every company which has inventory wishes to maintain the smallest amount of inventory possible whilst at the same time maintaining sufficient inventory to fulfill customer orders as soon as required. This balancing act requires knowledge about the needs - the amount of inventory required - and the resources - how much there is. 

Another area having great effect on the bottom line is debt collection, or 'accounts receivable'. Here, the standard reports in Priority should be sufficient, but there is always room for improvement and/or personalisation. More efficient debt collection improves a company's working capital, which is always a good thing (companies can be very profitable but can run out of cash at the same time, if their customers don't pay).

More thoughts about my new doctoral topic

Whilst walking the dog yesterday evening, I thought some more about my intended subject. I didn't emphasize enough the topic of interfaces previously: these are programs which take data (either from external files or internal sources) and create new documents (customer orders, warehouse transfers, work orders) from those data. These are complicated programs but they don't require any change in the database schema, which led me to the conclusion that my taxonomy of enhancements should initially begin with two classes, those that don't require additions to the database schema, and those that do.

Under the 'no additions to the schema' class, there are (in increasing level of complication)

1. Innovative usages of existing fields
2. More complicated reports (the status log reports example fits in here)
3. Interfaces reading data from external sources
4. Interfaces reading data from internal sources

Under the 'additions to the schema' class, there are

1. Additions of standard fields to tables/screens (it's a bit difficult to recall examples of this type, but after a bit of head scratching, I remember that I added a second agent to customers - a customer can 'belong' to two divisions, and each division has its own default agent for the customer). There is a built-in program for doing this, but most people aren't aware of it. I prefer to do this manually.
2. Additions of single, unbounded, fields to tables/screens  (unbounded means that the field is not connected to any table); example: text fields in customer orders.
3. Additions of bound, non-standard, fields to tables - this is the case of the degenerate table which I wrote about earlier. A table has to be created, a screen has to be defined in order to input data into this table; all this in order to add a field to the target table (and screen). An example would be a private 'status' field which was initially added to customer orders and later to purchase orders; using a bound field enables records with the same value to be retrieved with little effort.
4. Private modules, which record data not covered by any other module. These modules can use standard fields along with private fields. One example is a module which I developed for tracking slow and dead inventory; obviously the table contains a field which joins with the 'parts' table. A more extreme example is the 'expenses' table, but this too contains a field which joins with the 'users' table. A table which has no foreign keys (as they are known in relational database-speak) is of limited use.

I think that the word 'user' should be dropped from the title, making it now 'Benefits of extending ERP programs in the post-implementation phase'. Maybe the words 'a case study approach' should be appended; I want to look at the titles of the various DBA theses which I have downloaded to see whether they include their research method.

Visiting a plant nursery

We have added a new balcony to our house, this time at the back. Naturally we have to have plants on the balcony in order to add some colour, so we had to go to a nursery. I don't know which is the worst option: accompanying my wife when she is buying clothes, accompanying her to the supermarket or accompanying her to the plant nursery.

New direction for doctorate?

I wasn't able to do much thinking about a new direction for my doctorate over the past week for two reasons:

1. Although my supervisor wrote that he would be discussing my situation with the research committee chairman on Tuesday, it would seem that no decision was made. The chairman has traveled abroad for a week, thus delaying any further discussion.
2. I was far too busy at work, ironically because I instituted a major change in the way that customer orders are managed in one division. In a sense, the change is minor (one mark is substituted for another), but about 120 orders had to be converted to this new system (done by yours truly) and several key reports had to be changed. The new system required major changes to the reports, so this took much longer than I had expected. 

Last Saturday, I performed a small literature search on what might be my new direction, and came across a very interesting paper, which is also very recent (October 2016): "ERP and Organizational Misfits: An ERP Customization Journey"; two of the paper's authors appear in my bibliography. Whilst much of the discussion in the paper is very pertinent, I feel that some of the subject matter could be looked at in a different way; proposing a different taxonomy is definitely a basis for my new direction. 

A possible title would be "Benefits of user extensions to post-implementation ERP systems", where the word 'extensions' is comparable to what has been called 'customising' in my thesis. There are different levels of extensions:

1. Using the standard ERP system in a creative and intelligent manner, allowing access to data organised in ways which were not immediately apparent. This level requires no changes to the standard database schema. One example is the one I implemented this week, in which tasks are used to replace statuses (read on for an explanation of statuses). Another example, which would apply to many installations, would be the writing of reports which are based on the customer orders' status log. Each customer order has a defined status - for example, draft, waiting for approval, approval, in production, supplied, cancelled - which shows at which stage the order is currently to be found, and implies who is currently responsible for the order. Priority records in a log table every change of status: when, who and which new status (although there is no 'why', which is sometimes necessary!). This log is of great interest to my company, and probably to others, for several reasons, which I won't explain. To the best of my knowledge, there are no standard reports which use this log, so it was one of the first tasks which I faced as a developer to write such reports. This was a great benefit to my company and did not require any changes in the system. Another example would be writing programs to import data from external sources (e.g. company payroll); this requires an advanced technique, but no changes to the schema.
2. Adding fields to standard tables: this is a fairly frequent event, in which a company requires to store extra information about a datum (e.g. customer order, purchase order), but there is not a suitable field in which to store this information. For example, companies often store engineering details about parts in the 'parts' table. 
3. Adding tables to the database: this can be done on two levels. I frequently am asked to add degenerate tables, consisting of a primary key, a code and a description; such tables are needed for adding constant values to existing tables. A deeper version of this is adding a completely new module to Priority in order to record data for which no standard table exists; a simple example is a table containing people's expenses.

All of these extensions naturally bring benefits to the company implementing them - otherwise, they wouldn't be needed. The research will have to find examples of such extensions, then ask how the companies managed before the extensions were added. It is clear to me that prior to adding a module, companies store the data (if at all) in spreadsheets (boo, hiss!).

My research is effectively dead

On the same day that I received the letter from the journal editor asking me to referee a paper, I also received a letter from my doctoral supervisor. He informed me that he and the research committee chairman were very concerned about the small number of completed questionnaires which I have obtained from companies, and asked how I intended to increase the number substantially.

My interpretation is: you will be permitted to continue with your research if somehow you increase the number of questionnaires to 150. As there is no chance of this happening, my research is effectively dead.

I haven't been happy - both figuratively and literally - for some time about the number of questionnaires, so in a sense I am relieved that someone else has made the decision for me and 'pulled the plug' on something which is going nowhere fast.

I considered a few options, of which the best seemed to be to start from scratch with a new, albeit related, topic. Obviously, I will have to write a new research proposal which will have to be accepted by the research committee, then write a new intermediate submission which again has to be approved. 

I have told my supervisor of my decision and I await his response (which may take a week). In my letter, I explained approximately what I intend to research and stated that I didn't have a formal title. After thinking about it some more, I think that the new title will be something like "Examining the benefits of consultants in the post-implementation stages of ERP installations". 

As opposed to my original research, which is based on questionnaires, this will be 'case study' research, carried out with two companies both of which have cooperated fully with my research until now and with whom I work as a consultant. The methodology will be interviews with five to ten people in each company, discussing how their usage of ERP has changed from before I started consulting with them to how it is now and how the company has benefited as a result. The already collected questionnaires may have some value. 

One of the foundations of the research will be a simple question of economics: is it better to employ a developer for a one time, but moderately expensive, cost, or allow employees to use any solution (mainly spreadsheets) at a constant cost of time, at the risk of bad data? This became very clear to me yesterday evening when I was shown a spreadsheet containing  invoices which the customers have yet to pay, which is created daily by a secretary at one of the companies. It seems that my job in this coming week will be to write a program which will output this data in a minimum of time and of course, more accurately. There is also a striking example from my own company: the financial comptroller used to take four days a month to compile a report; after speaking to me, I managed to reduce the required time to four hours a month - an eightfold saving of very expensive time.

I reckon that I can use about 50% of the material which I have already written. All the psychological material can be discarded, and the rest will have to be re-targeted. Fortunately, in the introduction and literary survey, I discussed the subjects 'customisation' and 'misfits', which are very much connected to the new, more refined, topic, so I already have this material in hand.

Reviewing someone else's academic work

I wrote last time that I had been invited to review a paper about an ERP implementation. I was sent this paper but discovered that the document was empty - for a while, I wondered whether I had been the victim of a scam or a virus attack - but after contacting the journal editor, the documents were sent again and this time were readable.

The paper discusses an ERP implementation for a national electricity company in Africa. The paper shows that so far, the implementation has failed, which does not come as much as a surprise to me. There isn't a particularly good fit between such a company and ERP to start with. It seems that the vendor, contractor and company didn't do their homework very well and that the users were not prepared in advance. Unfortunately, this happens frequently.

Also unfortunately, I couldn't recommend the paper for publication. There were many mistakes in English and strange adjectives used (e.g. "unappealing commitment"). But even ignoring such issues, the paper wasn't very good. There were very few references, which is odd considering the number of papers about ERP implementation (I don't remember the exact figure, but my literature survey states that about 80% of ERP research is about implementation). The methodology is ok, but data is presented in a haphazard way and the conclusions aren't stated in terms of the original objectives.

I can understand how the writer(s) will feel when they receive the feedback - I have been in the same position three times. At least I totally understand the subject matter, which is more than can be said for those who reviewed my work. I have tried to point out where the work can be improved. I was sorely tempted to send back a copy edited version of the manuscript, but that's not my job.

It will be interesting to see whether there is any follow-up to this review.

A certain kind of academic recognition

I received an interesting email today, asking me to review a paper for a professional journal. Not surprisingly, the paper is about an ERP installation. As reviewing is supposed to be anonymous, I can't publish here the name of the journal nor of the paper. I don't think that this journal is very well known (I certainly have never heard of it), but it does have a presence on the Internet and one can read papers published within. 

So, this is a certain kind of academic recognition, although not necessarily the kind that I crave for. 

[SO: 4422; 5,21,43

MPP: 802; 1,4,6

ELL: 926; 0,2,7]

The City Boy

It happened twice during the years 1969-70 that I found abandoned library books on benches in my school rooms. One time, the book was "Tiger, tiger!" (aka "The stars my destination") by Alfred Bester, which was a stupendous find; this was one of the strongest and most colourful science fiction stories that I would ever read. I suspect that I had difficulty understanding the story at first, but later understood its intricacies.

The other book was "The city boy", by Herman Wouk (certain editions seem to have lost the definite article). Whilst obviously I was not living in 1922 (or thereabouts) in the Bronx, with a father owning a factory which made ice, I was aware on first reading of several similarities between the story's protagonist and myself: we were both plump Jewish boys who preferred intellectual pursuits than sports and we both went to summer camp - although mine lasted two weeks as opposed to Herbie's two months. It is no wonder, then, that this book spoke to me.

I haven't read it for at least twenty years (if not more), but recently found an ebook version which I loaded onto my Kindle. I read the book in its entirety yesterday and was once again charmed by this story which apparently was a failure when first published (although this may have been a backlash to the success of Wouk's previous novel, which was his first). Now, I find it amazing how Wouk understands and writes about the behaviour and motivations of an eleven year old.

The serendipity of finding these books abandoned in classrooms helped fuel my eclectic and scattered approach to reading in the formative years of my adolescence. It's a shame that I found only two books - who knows what a third might have been? By 1970, though, I was off and reading books which I found through books which I had already read.

Grand-daughter is nine months old

Shaked is now nine months old and has a wide variety of behaviours and responses. Here she is, sitting on the sofa between me and her mother, trying to collect scraps of apple pie with her finger so that she can eat them. I'm trying to distract her with a samba rhythm on the shaker.

[SO: 4412; 5,21,43

MPP: 802; 1,4,6

ELL: 881; 0,2,7]

John Wetton, RIP

"Spinal Tap" notwithstanding (five drummers mysteriously die), it seems that being a bassist in a prog-rock group is a work hazard: I was sad to hear this morning that John Wetton, bassist in the 1972-4 configuration of King Crimson, died after a long battle with cancer. Wetton joins recently departed Greg Lake and long departed Boz Burrell in the King Crimson bassist casualty list (there are also two Van der Graaf Generator bassists to keep them company).

Wetton had been in a variety of groups before King Crimson, most notably Family; he sings second vocal to Roger Chapman on one my favourite Family songs, "My friend, the sun". In KC, he played bass, sang, wrote songs and played uncredited instruments, his apotheosis being "Starless".

After KC, he went on to play with Bill Bruford in UK, then hit the big time with Asia (I have no acquaintance with them). Apparently, he was an active musician until the last few years, when the cancer came.

Tonight, as a tribute, once more I will float down the river of music that is entitled "Starless" and enjoy his bass and voice.

Edit from the same evening: listening to the radio today, I heard the announcer mention the death of JW, and in tribute played a live version of 'Book of Saturday'. I didn't recognise this version - it may not have been by KC.

Fripp writes:
John was a pal over almost forty-two years, beginning at Bournemouth College in 1965, two teenage students and local gigsters. We continued in touch during our early professional lives in London, speaking from time to time, before John joined King Crimson in 1972-74 with David Cross, Jamie Muir and Billy B. JW was, for me, the leading bass player of his generation, a player of international class, before John moved increasingly to the front as singer and songwriter: Asia’s debut album was the world’s biggest seller in 1982. We continued as chums, working together when John lived in LA in 1992; and increasingly met for coffee and cakes after John moved back to Bournemouth in the Noughties.

Edit from a month later: I found this article (it's more like a book chapter!) about John, mainly before he became famous.