After our Marketing department approached me with the question of whether I’d like to write an article on the topic of "standard software versus individual software", I was initially a little perplexed and gnawed a bit on my imaginary pencil. Sure, we come across this question more often in IT. But at the same time, it has the distinct disadvantage that a simple answer isn’t possible, so it’s not very suitable for an article that you can just lean back and relax after you’ve read it.
Of course there are cases where the answer is easy. If you’re looking for an office programme then you probably wouldn’t consider programming it yourself. There are already excellent products on the market. The situation is similar with, for example, Content Management Systems for technical editing. Here, too, there are great products and, apart from a quest for adventure, there’s hardly any justification for developing one yourself. The only exciting question here is which of the available products is most appropriate for your own requirements.
So in these cases, the answer is obvious, but it becomes more complicated when it comes to software that addresses less standardised requirements and/or software that has complex connections with business processes. In this case, inappropriate software leads in the worst case scenario, for example, to production downtime and, as a consequence, to considerable financial losses.
The Advantages and Disadvantages
If we look at the basic advantages and disadvantages of the two options, the following picture emerges:
(in order to simplify matters, we’ve placed an evaluation at the beginning of each point: "S+" indicates a Standard solution, and a "I+" indicates an Individual solution)
- S+ A standard solution has proven that it works and is equal to the requirements. The investment need can be determined quite reliably (which of course doesn’t mean that it is necessarily low). The implementation period should also be relatively easy to calculate. The planning reliability is comparatively high, and the risk of a fundamental failure of the project is comparatively low. However, numerous unsuccessful attempts to introduce an ERP system frustration-free, for example, demonstrate that a considerable residual risk remains with complex software.
- I+ On the other hand, a standard solution by its very nature cannot be perfectly tailored to a company; after all, it targets a set of requirements from across various companies, industries, etc. As a compensation, however, almost all products offer the possibility of adapting the requirements (e.g. by means of workflow editors or script programming); which simultaneously increases the implementation effort – possibly to the point of virtual non-implementability (however, you’ll not usually find this information in the marketing brochures of the various providers).
- S+ An individual solution can be optimised by adapting it to the specific processes, products, employee requirements, technological specifications, etc. Disadvantages here are the (usually) much higher financial, time-related and emotional expenditure and, as a result, contribute to a much higher risk of technical or financial failure of the project.
So there is a need for both good reasoning and a certain willingness for decision-makers to take risks – opportunities and risks are usually found uncomfortably close to each other.
In addition to these basic aspects, the following points seem relevant to me:
- S+ If an individual development is planned, the question is exciting as to whether the current company processes are really so much better than a standard process that they should be preserved with the aid of an individual development. Or, are they rather the product of coincidence? Is this already existing advantage of the current processes so great that it can be assumed that the processes should not be changed – even over the long-term (an individual development is rarely as flexibly adaptable as standard software)?
- S+ Is it even possible to sensibly map these processes in individual software? When formalising lived (i.e. real-life) processes, it often turns out that they aren’t quite as clear as had been assumed ("Actually, we always do this... Except in the case of X, we ask Y, sometimes Z or someone else. It depends."). It should also always be considered that the attempt to formalise informal processes can lead to considerable conflicts between the parties involved in the process, with resulting emotional, chronological and financial aftershocks. A reference to the necessities of a standard solution can be the easier way.
- I+ Conversely, individual software can provide a competitive advantage over competitors. One could argue, for example, that it makes sense to focus more on individual software when it comes to software that is directly customer-facing (e.g. mobile apps).
- I+ In addition, the theoretical advantage of standard software can’t even be realised in some cases (e.g. if the effort for adaptation of the software and process adjustments within the company ultimately significantly exceeds the effort for individual programming). The question must also be clarified, as to how a company or department can simultaneously introduce new software and processes adapted to the new software without negatively impacting production.
- I+ Finally, the universality of a standard solution can lead to considerable complexity for the overall system. A software programme that claims to meet "all" requirements usually covers far too many requirements with regard to the individual case. Configuration, training, administration, updates and use are correspondingly awkward.
- S+ Speaking against an individual solution is that considerable cooperation on the customer-side is usually necessary – for the specification of requirements, the evaluation of prototypes, and the testing of the application. A significant number of errors must also be expected initially.
Conclusion
What comes out of all this? Firstly: It's complex. Secondly (up until now unspoken and obvious): There is no strict alternative "individual software" versus "standard software". Rather, as with complex systems the question arises for which aspect of the solution standard or individual components are appropriate in each case.
So what does all this mean for our industry? Suppose we’re faced with the task of wishing to largely automate the creation of variant-specific documentation (this scenario is always good as an example). Our basic idea is to create information products for various target systems, based on information that is available in different leading systems (SAP, Confluence, Jira, CAD, file systems, etc.), as well as content modules that can be found within a CMS. Some of the information is to be made available to customers in the form of mobile apps.
One possible solution within our current projects is to rely on standard software for the Content Management System, metadata management, and the publication server. For the interfaces and data transformation, on the other hand, we develop an individual solution. In the case of the interfaces, this is obvious anyway due to their very specific character. In the case of mobile apps, we opt for a modified standard solution. In this manner, we ensure that the app meets the customer-specific requirements, but is still faster to implement and easier to maintain than a completely new development. Our solution implies a manageable effort, and at the same time the probability of success is very high. This solution is therefore far from simple.
Do you have ideas or suggestions on this topic? We’d be very happy to receive your feedback.
