Early Enterprise Resource Planning (ERP) systems often started life as in-house development projects for large manufacturing organisations. Other products were developed for specific industries and only later, broadened to capture a wider market. Most of these pioneering systems were written for mainframe computers and then various flavours of Unix, almost exclusively with a crude ‘character’ interface. The connection of PC’s through local area networks (LAN’s) eventually led to DOS based systems with similar interfaces and functionality. Most of this software was coded before object-oriented development tools were available and hence do not benefit from the structured approach offered by this technology. This makes for cumbersome code that can be unreliable and costly to develop and maintain. Vendors however, cannot just discard this huge investment in legacy software.
To extend product lifecycles, Windows-based front-ends were later “bolted on” to some systems without improving the underlying code. It was the mid to late 1990’s before some of these legacy products were eventually re-written or replaced to take full advantage of the latest operating system (OS) architectures and object-oriented programming techniques but many are still on the market now.
In addition, there has been a tendency for larger businesses to demand custom functionality from which many vendors derived healthy revenues. This customisation typically ends up in the standard software leading to “bloatware” (overblown software containing an excess of little-used functionality). Such ERP software is going to demand substantial resources to operate, maintain, upgrade and develop. This can be exacerbated by high training and operational costs due to poorly designed user interfaces, and a bewildering array of superfluous functionality typified by “window clutter” and “menu sprawl”.
It is clear that, whilst larger manufacturing organisations can survive the high Total Cost of Ownership (TCO) of legacy ERP software, the Small to Medium sized Enterprise (SME) needs to look elsewhere. So what elements are going to characterise a development approach more in tune with the needs of the manufacturing SME? High on the wish list should be development focus – on manufacturing, on generic rather than industry-specific functionality, on features actually requested and used by clients and on relevance to the size of the organisation. This may be demonstrated by the software having a broad but cohesive feature set and a user base spreading across many industries and a development policy characterised by openness.
Another important area is the approach to customisation. If a vendor claims that even standard windows can be modified, this could point to long-term maintenance issues and expensive upgrades where modifications have to be re-coded to accommodate new versions. A much safer approach is to limit major customisation to additional windows and plug-ins and/or code that runs within a controlled customisation framework. A manageable methodology like this enables full vendor support to be maintained while allowing users to get the special functionality they need, even when they themselves manage and maintain the customisation.
This should all be supported by automated change management tools where simple point and click techniques are all that is required to re-install custom features into a new version and maintenance updates are delivered automatically over the internet, with minimal disruption to normal operations.