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.