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!).