Dr Ashley Braganza, lecturer from Cranfield School of Management, attempts to answer the question: What should an organisation do in order to decide whether to change the process or bespoke the software?

Companies ought to be divided into two categories: those who define processes and then purchase software, and those who purchase software and then consider processes. It would appear that most fit into the latter category and very few into the former.

First, many organisations make the mistake of referring to functions as processes. Such organisations talk about ‘HR processes’, ‘manufacturing processes’, ‘logistics processes’ and so on. Even worse, these organisations refer to departments within these functions as processes, so in the logistics function there might be a ‘delivery process’ or a ‘warehouse’ process.

If an organisation has defined its processes in this way, it is unlikely to achieve the full benefits of a major software package. This is because changes that are intended to align the ‘function-as-process’ with the software package will result with that process being aligned to the software, but misaligned with the remaining functions that constitute the business process. So initially the system will deliver the information required by that function, but over time, the information being collected and the data being generated will become increasing less relevant to users.

On the other hand, if the software is customised to fit the function or process, leaving it unchanged, the organisation is, in effect, automating years of historical and possibly outdated practices, procedures and routines. Research and experience shows that organisations that automate manual and historical activities rarely, if ever, gain benefits from software packages. The customisations can only ever approximate the ‘actual’ activities and information flows and hence never really meet the users’ needs.

Process identification

The second problem is that, in order to build processes, organisations map what people do and how information flows between tasks and activities. They use a variety of means to develop these maps: mapping-specific software packages, brown paper and Post-Its, presentation software, or occasionally paper and pencil. These maps, once complete, often look a mess, with lines and boxes criss-crossing and overlapping, even though strenuous efforts are made to keep the lines ordered.

Once the map is complete, an arbitrary boundary is drawn around a number of activities that are then deemed to be a process. So when it comes to customising software to fit this arbitrary grouping of activities, there is always the possibility that a vital activity has been left out – thus rendering the process, and the supporting software, ineffective from the outset.

Where a process is of strategic importance, I would suggest that the software is customised to fit the process. Likewise, where a process is of vital importance to the organisation’s future strategic direction, the software should be adapted to the process. The danger with changing these types of processes to fit with the software is that the competitive elements of these processes get reduced to ‘lowest common denominator’ levels, and hence the organisation loses it present and future strategic edge.

Furthermore, every organisation has processes it has to perform that are either for internal ‘housekeeping’ or because it is a regulatory or industry requirement. I would suggest that these processes could be aligned to the software package, as there might well be efficiency gains to be made, without loss of strategic advantage.