Fitting Standard Software to Non-Standard Organisations

The paper is interesting to me personally for several reasons, including the fact that the case study took place in a university. That some of the prospective users claimed the system was too simplistic and that it did not capture the complexity of the student-university relationship. My own background is teaching in a post-leaving certificate college in Ireland, and I can imagine certain people in my own staffroom with similar opinions, or at least a similar need to voice them.

Also interesting was the fact that despite the numerous interviews, observations and questionnaires carried out there still was difficulty in identifying process, structures and requirements. The authors explain this by claiming that the notion of a university is not easily translatable – that much of the interaction was ‘locally negotiated’ or ad hoc, not structured. Is it the case that these negotiations ‘cannot’ be mapped, or ‘have not yet’ been mapped, or that there is no imperative on the part of either researchers or business or do this?

The candid disclosure of the competition between the universities for their own slice of the ERP pie was also interesting. The paper seemed to be written quite honestly and for me personally had resonance and a certain authenticity.

It was mentioned that early on there was indications that the system was going to be incompatible. The question then arises - why follow on with it? What was the driving force to change? This is not clear from the paper.

Passing requirements along a chain probably involves them being subtly shaped by that process, however this is not mentioned by the authors. Each ‘node’ on the chain would have their own agendas, where requirements may be moulded to fit more easily with their own desired outcomes. This may be something that should be addressed by future researchers – to what extent does ‘Chinese Whispering’ take place where the final requirements received at the end of the chain are different from those that started out at the beginning of it. If it turns out that the chain does shape the requirements, then it may need to be a priority that a direct route be established for requirement passing.

The particular problems associated with the different universities conflicting requirements made me wonder whether it was not possible to make a ‘modular’ system, that can be attached together (like Lego) to make a reasonably compatible system. So for example, with the Post Graduate registration software issue, that different ‘flavours’ could be chosen from a selection, including both those compatible with a UCAS-type system or a competitive marketplace system. Universities would then be able to select the particular modules they require, and they would all be compatible, and they would all be happy (in theory at least).

The paper highlights how the fit of the system to the organisation, often depends on the fit of the organisation to the sector of industry it belongs to, as ERP systems are designed to fit a generic organisational sector.

A particular aspect which stood out for me in the paper was the notion that the availability of practices within the system may be a factor which shaped future decisions. This seems to me to be highly likely. Management should be aware of this tendency and should ensure that decisions which may have been affected by easy availability of facilitating technology are practically and morally justifiable in their own right.

The ‘paradox of the standard system’. In order to make a system ‘fit’ more that one organisation, it must be generic in the first place. Generic products are created to fit a sector of the market. Within any sector, there will be a range of organisations. Generic products will have different levels of ‘fit’ to different organisations depending on how well the organisation itself fits the sector. It appears that ERP products generally cannot be tested in advance due to the enormous amount of time and money needed to do this, however, buying a generic product may fit an organisation as well as a ‘generic’ pair of jeans – badly! Subsequently tailoring the system to the organisation will involve extra cost and effort, making it non-standard in the process and thus make upgrading more difficult.

Development companies are not interested in making a system for an organisation, they want to make it for a sector in order to maximise profitability. Organisations need to understand this and make their own decisions accordingly. I thought it was naïve of the university to expect to be able to influence the developers to the extent that they would get what they wanted, especially when larger American universities were involved.

At the same time, organisations that are not well structured to begin with, need to understand that they are unlikely to be happy with even a bespoke system, because no ‘system’ at present can adequately capture multiple ad-hoc locally negotiated practises.