Research proposal accepted!

The research committee of my university met today, and amongst other subjects discussed my research proposal. Following is an extract from a letter sent to me by the DBA Operations Manager:

The Doctoral Review Committee considered your proposal at their meeting this morning and I am delighted to inform you that they believe you are now ready to proceed to the supervised stage of the programme. There are still some issues with your proposal but these can be addressed under guidance from a supervisor.

A supervisor has been appointed, although apparently the committee has to obtain university approval for his appointment. At least it's not the same person who 'mentored' me.

[Edit]
Looking back over the blogs, I see that there was no mention that I intended to submit my research proposal, so there is no background to it being accepted. What happened was that I worked on my proposal and sent it to my mentor; he wrote back suggesting a few things. I responded to what he wrote, and then he wrote back saying that there was no point continuing the mentoring if I don't adopt his suggestions; he told me to submit what I have written in order to obtain some objective criticism. That letter really annoyed me; there have been suggestions which I adopted. I felt quite misunderstood and asked for a new mentor, to which the mentor (who is the departmental head) replied that there is no mechanism for changing mentors. As I still had a few days before the submission deadline (once every seven weeks), I worked even more on my proposal, checking to see what I had done in my original proposal. I added a few bits and pieces then submitted. 

My mentor was gracious enough to congratulate me on having the proposal accepted; I hate to think how we could have carried on. The entire mentor stage had been very difficult. Since the acceptance, I have yet to hear from my new supervisor. Something tells me that he is sympathetic to IT (I think that my original supervisor mentioned him) which means that the supervised stage should be more fruitful than the mentoring stage.

Two more people have passed away

We were informed two days ago about the death of another kibbutz member (that's four in less than two months); I think that I've had only one conversation with this man, ironically when we both visited a bereaved member a few years ago. It turns out that my wife had no small amount of contact with him via gardening, so she very much wanted to go to the funeral yesterday (I was in the north of Israel at the time).

I discovered a few hours later that Jerry Pournelle, science fiction writer who also wrote about computers, had died - albeit a few months ago. I think that I came across Pournelle first as a novelist - "Lucifer's Hammer" was a book that we passed around at the beginning of the 80s. But it was in Byte magazine (from about 85-95) that I really became acquainted with Pournelle with his "Computing at Chaos Manor" column, where he used to write about all the equipment that he received for review. The columns were entertaining, albeit fairly useless practically speaking, as the general Israeli computer nerd was several years behind with respect to equipment.

I did occasionally read Pournelle's blog but this turned more and more to internal American politics which don't interest me very much (especially when Pournelle described himself as being "to the right of Genghis Khan"). There were a couple of good books - "The mote in God's eye" and its sequel, as well as "Footfall" - but I also remember some which seem to have been knocked off in order to pay the bills ("King David's spaceship").

So, two more people who were peripheral to my life have passed away.

One more instrument in the developer's toolkit (using a trigger in a report)

The other day, I was asked to write a report about "Catalogue of parts with serial numbers"; the use of this screen is very important to companies which track where each individual product is found. The report had to include the status of each product. Normally, most tables (e.g. customer orders, purchase orders, customers, etc) have a corresponding status table; the ubiquitous documents and inventory line tables have their own status table which is very complicated. But for some unknown reason, the serial number products table does not have a corresponding table but rather uses the customers table! It would seem that the use of this table is shared with other tables.

The statuses stored in the customers table all have the 'statusflag' set; predefined statuses have their ID (cust) bearing a negative value, but user-added statuses have regular, positive, values for their ID.

In the first version of the report, I had defined the customers.custname field as a parameter and tried to limit the number of values displayed by requiring customers.statusflag to be 'Y'. This did not work; every time I tried to find a status, the report would present the entire list of customers.

There is a little known way around this problem which I intend to explain. One can define a choose-field trigger for a field in a report in the same way that one defines a trigger for a field in a screen. Each field has a sub-form called 'field triggers' which most developers are probably unaware of. Once I remembered the existence of this sub-form, writing the trigger was very easy:

SELECT CUSTDES, CUSTNAME
FROM CUSTOMERS
WHERE CUSTNAME <> ''
AND STATUSFLAG = 'Y'
ORDER BY 2

Once this code was in place, only the status 'customers' would be presented as possible values. It isn't often that one needs this technique, but like all esoteric techniques, it is the perfect solution to a specific problem. One more instrument in the developer's toolkit.

[Edit from much later] The reason why inventory statuses are stored in the customers table is because inventory can also be 'packed'/reserved for a customer, whereupon its status becomes the customer number (this is what happens after using the DOCUMENTS_A screen). In order to maintain a status that can be either a customer number or some general form of status (like 'goods', 'reject', etc), the general inventory statuses are stored in the customers table, but flagged. Thus 'real' customers can be displayed as can be 'real' statuses without the two intersecting.

Joe Cool

We haven't had a grandfather - granddaughter picture for some time. This is primarily because most of her pictures now are videos. 

INTQUANT and REALQUANT

Almost every programming language has at least two kinds of numbers: integers and reals. In the old 16 bit days, an unsigned integer could have a value between 0 and 65535 (that's 2 to the power of 16, less 1), whereas a signed integer could have a value between -32768 and 32767 (2¹⁵ − 1). In these days of 32 bits, an integer can have a value between −2,147,483,648 (−2³¹) and 2,147,483,647 (2³¹ − 1). An integer does not have a fractional part; for this, one uses real numbers, which have a range of −2³⁸ to 2³⁸. Whilst real numbers have a much larger range than integers, they are also less accurate: there are certain fractions which are very difficult to store in binary. This lack of accuracy causes problems when real numbers are multiplied, and so some languages store real numbers as 'decimal shifted' integers (i.e. 3.333 is stored as 3333). This is very important for applications which deal with money as no accuracy is sacrificed.

As Priority deals with both monies and stock quantities, it provides integers, reals and decimal shifted integers. As usual, the documentation is not too clear how to use the different types, so this blog is intended to clarify matters, especially with regard to decimal shifted integers. The TRANSORDER (inventory movement) table - as well has other tables - contains a few fields whose name is like QUANT (quant, tquant, cquant); in the table directory screen, these fields are defined as integers with a width of 17.3. This means that they are stored as integers but their values should be shifted three columns to the left in order to obtain their real value; as written above, a quantity of 3.333 would be stored as 3333.

The screen manager knows automatically how to display such fields (3000 would be displayed as 3.00) so the beginning programmer doesn't have to convert anything. The problems begin when one wants to calculate something based on such a field: for example, the value of inventory is calculated by multiplying the amount in inventory by the part's cost. The unaware programmer will write this statement without change: if the amount is 3, then it will be stored as 3000, and multiplying by the cost (let's say 20 shekels/unit) would result in the value of the inventory being 60,000 shekels! Obviously the quantity has to be converted to a real number before multiplying, so one would actually write REALQUANT (TRANSORDER.QUANT) * PART.COST. This will give the desired result, 60 shekels.

The result of such a calculation should be stored in a variable which has been defined as a real. The easiest way to do this in a procedure is to initialise the variable in the following manner:

:VALUE = 0.0;  /* this tells the parser that 'value' is a real */
SELECT REALQUANT (TRANSORDER.QUANT) * PART.COST INTO :VALUE
FROM TRANSORDER, PART
WHERE TRANSORDER.PART = PART.PART
AND ...

Sometimes it is necessary to store the result of such a calculation back into a decimal shifted integer: for this one uses the INTQUANT function, which as its name suggests, turns a quant into an int. I've had to use this function recently as I was writing code which creates bills of materials; a quantity field in the interface requires a decimal shifted number which is calculated on the basis of a real number and another decimal shifted number. INTQUANT requires its operand to be a real number, so the easiest way of ensuring this is to include 0.0+ in the expression, as follows:

:NEWQUANT = INTQUANT (0.0 + :COEF * REALQUANT (:QUANT));

The variable :COEF has already been defined as a real (for example, this would hold the value of PARTARC.COEF, which defines the number of 'son parts' to its 'father part') whereas :QUANT would be a decimal shifted integer, such as ORDERITEMS.QUANT.

The parser in Priority procedures can be a bit stupid, so one should give it all the help one can by predefining variables. Otherwise one is liable to receive the error message that :VARIABLE has been defined having two different types.

I tend to use REALQUANT when I am writing cursors, so that I know that I am working with a real number; I find this makes life a bit easier. For example,

DECLARE CUR CURSOR FOR
SELECT REALQUANT (TRANSORDER.QUANT), PART.COST 
FROM TRANSORDER, PART
WHERE TRANSORDER.PART = PART.PART
AND ...

Basic rule: never write an arithmetical expression using decimal shifted numbers without REALQUANT! That's about all there is to say about INTQUANT and REALQUANT.

ERP enhancement management

I spent about three hours on Friday, brainstorming with regard to my research proposal. The results of that thinking appeared in my previous blog entry. On Saturday I spent about the same amount of time looking for introductory papers in three disciplines - organisational change management, engineering change management (ECM) and product management. On Sunday I printed the papers and glanced at them but didn't have much time to concentrate on them.

Yesterday evening, I sat down with the printed papers and my mobile computer, and started reading the papers, extracting the salient points and adding them to the research proposal. I was very pleased to note that one of the papers on ECM contained a five stage model which was very similar to mine. I was able to contrast ECM with my proposed change management discipline and in doing so, I was able to present my model naturally, without feeling that I was pulling a rabbit out of a hat.

After I completed writing up the papers and introducing my model, I looked again at my mentor's post from last week which started this flurry of activity. He suggested looking at stakeholder literature, which is a topic which I hadn't considered. After entering that term into Google Scholar, I was presented with a list of papers from which I chose one, entitled "A roadmap for IT project implementation". This was exactly what I needed, as it provided some choice quotes. There was also room for critical evaluation: this paper deals with project implementation, e.g. implementing Priority, whereas my research is concerned with implementing enhancements, which of course are on a much smaller scale in all respects. Fewer people are involved, the costs are very low and the time span is negligible.

Once I had added a paragraph or two, I realised that I had a complete document which I could send back to my mentor. I was quite surprised that I had managed to implement the changes in such a short time. Now I can focus my time on other activities.

40 years ago

Day	Month	Year	Artist
6	Nov	1970	Heron
12	Nov	1971	Al Stewart
16	Nov	1975	Richard and Linda Thompson
17	Nov	1976	National Health
6	Nov	1977	Sandy Denny

Above are extracts from the concert log which I used to maintain in the old days, when I went to concerts. The first and last entries are the most interesting, coincidentally on the same date. 

I've written about Heron and this concert before: it was a promotional tour, selling tickets for one old penny! I very much enjoyed their set, which persuaded me to buy their eponymous album (I listen to it to this day and still enjoy it very much). It was this concert which weaned me off rock acts such as Ten Years After; I was much more content to listen to this 'wooden music'.

The last concert on the list is the last time I had the pleasure of seeing Sandy Denny in her brief life. I know that there are plenty of fans who never saw her appear at all, so I should be thankful that I saw her three times - once with Fotheringay, once with Fairport and once on her own (well, with a supporting band of five musicians). To be honest, I remember almost nothing of the music, but fortunately some of the concerts on this tour were recorded; many many years later, we were treated to a cd of one of them. My name appears in the credits of this disc, which was very kind of the producers. My contribution was to send them a copy of my ticket (which was not for the date which was recorded) and an advert for an earlier Sandy record - none of which found their way into the final booklet. I admit that this is not a disc that I listen to - Sandy's voice had almost completely gone by this time.

This concert is also memorable for a more personal reason: I invited a girl to go out with me to this concert and she accepted. I don't remember whether this girl has ever crossed the pages of this blog so I had better introduce her; we had met about a month earlier at the inaugural meeting of the Jewish Society at my university. It turned out that she was in the new intake of my degree course whereas I was a final year student, so we had more than a few things in common. She also didn't live too far from me, in Swiss Cottage, which was a brisk 40 minute walk for me.

The memory which stands out about this girl (for whom I wrote the song 'M') was when I invited her about a month later to the communal house for our Chanuka party. The next morning I phoned her, asking whether she enjoyed herself; we proceeded to have a half-hour chat which left me slightly bemused. I remember saying to someone that her tone was far more friendly than it should have been. A minute later, M phoned and apologised: she thought she had been talking to someone else! Our relationship lasted only about another month, mainly because we had less in common that it might have seemed at first.

More thinking on the page (DBA)

This post is a continuation of a previous post from three weeks ago, so it's best first to read that post before continuing with this one. As the title alludes, I am going to be 'thinking on the page', so I can't guarantee that there will be an ending or any conclusions from what I write, although I certainly hope that there will be.

My mentor was not particularly impressed by my new version of my research proposal, which featured the seven stage model for developing enhancements. I too had certain doubts about this as I had asked him about where the model should be introduced; at the moment, it had a deus ex machina quality about it as it doesn't flow from the limited literature review. The mentor suggested that I not use the model in the proposal, which returns me to the stage I was in a few weeks ago: what is my research question? What are the aims and objectives?

After further cogitation, I am naming the concept which is to be researched as 'ERP enhancement management' (EEM), a term which I don't think exists in the literature. The definition is based on the seven stage model, but I'm going to ignore that for the moment; instead I will define it in terms of what it is not. EEM has similarities to organisational change management (OCM, a well researched topic) in that it affects the organisation and should achieve strategic or tactical objectives; it is also connected with several groups of stakeholders (which is defined as "members of the groups without whose support the organization would cease to exist"). But EEM is concerned with incremental and fairly minor changes, whereas OCM generally is concerned with major changes, often in critical situations. Also, the success rate of OCM is much lower than that of EEM.

There is also similarity to engineering change management (ECM) but differs in several aspects: ECM is generally concerned with the life cycle of a product, and not incremental changes to software. ECM also is much more technical that EEM - I am purposely leaving out all the technical aspects of EEM, leaving only the managerial aspects.

There is also similarity to software product management (SPM), but as its name hints, SPM is concerned with the life cycle of a complete software product and not with incremental change. That said, there may well be lessons to be learnt from a description of how (for example) Microsoft manages changes in Word or Excel (I doubt that I'll be able to find academic papers on this topic). But then again, these are changes to a product which completely ignore the effects of the software upon the organisation and stakeholders.

So it would seem that EEM is a distinct topic about which there appears to be no prior research. So this is a good example of a research gap.

I found a Doctor of Engineering thesis which examines the engineering change management process (William Rowell: 2013, University of Strathclyde); there is no research question, but the aim and objectives are illuminating. The aim: To characterise the variations in the engineering change management process within the product life cycle and explore the relationship between this process and artefact knowledge. Based on the findings from this study, recommendations for improving existing engineering change management practice shall be offered.

The objectives are (briefly):

1. Synthesise and discuss relevant literature in the field of engineering change management
2. Present empirical evidence of the activities that are enacted during the engineering change management process
3. Present the impact of the research in terms of how the results should influence future engineering change management practice
4. Discuss the benefits and limitations of the research findings and approach used to obtain these findings, offering conclusions and avenues for further research

These objectives can easily be reworded for my purposes. But what is the research question? At the moment, there are two:

1. By what methods do organisations develop enhancements?
2. How closely do those methods match the proposed process model?

Clearly, the second question has to be dropped as there is no proposed process model. The first question is in the right direction but needs to be developed a bit more. Going back to Rowell's thesis, his second research question is What types of artefact knowledge are used and created during the engineering change management process and what can be taken from this to improve the engineering change management process? So ...

1. What are the steps taken by organisations in the ERP enhancement management process?
2. How can these steps be generalised in order to create a model to improve the process?

That's not a bad beginning. This will require discarding (once again) a fair amount of material which is included in the current version of the proposal. Hopefully, the next version will tighter as well as being refocused; its title will now be Examining the ERP enhancement management process in Israeli SMEs.