There is a reasonable expectation from any off-the-shelf product. It seems faster, easier to approve and less costly than a custom solution. For a trivial task, it can be the case. However, the challenges start coming in once an out-of-the-box solution confronts an organisation with several divisions, legacy systems, stringent control, peculiar process and information scattered among them.
The plain truth is that off-the-shelf solution falls short because it assumes a streamlined process while the organisation does not function this way. The solution may have all its merits. The vendor can be reliable as well. The point is fitness.
The guide is written for UK directors, operations directors, CTOs, IT managers, procurement teams and transformation teams. It reveals the origin of the risk, cases where off-the-shelf solution will do and how to make a more informed decision about the build vs buy software problem.
What Is Off-the-Shelf Software?
Off-the-shelf software is a finished product designed for wide distribution rather than for use by a particular company. Examples of off-the-shelf software include CRM, ERP, HR, financial, project management and service management software applications. Commercial off the shelf software, or COTS, is offered for sale or licensing and leasing as a pre-existing product rather than a software product that is specifically tailored to the needs of a customer.
Three important levels of the hierarchy should be considered. The standard product is used basically as it is delivered. Configured products have pre-set configurations, fields, workflows and permissions. Custom products can go much further than that and include codes and scripts as well as custom integrations.
Difficult projects usually start from a simple solution in the form of standard software and gradually evolve into complex customisation within a software package.
Why It Looks Like the Safer Choice at First
It is easier to justify packaged software, as there is no risk involved. You know the company, you know the interface, and there are probably some case studies, support personnel, documentation, training videos and implementation partners. It is easier for the purchasing team to compare licence options to a customised approach, and the finance department knows what the cost will be on a monthly or yearly basis.
This can all make perfect sense. A standard, proven process may not require customisation at all. Many basic HR, ticketing, collaboration and finance processes can easily be satisfied by existing solutions.
The problem is that a long list of features can be assumed to prove that the software matches your daily needs. What a demo proves is simply that the software works under the circumstances of the demo.
The Main Reason It Fails: A Standard Product Meets a Non-Standard Organisation
This is mainly due to the misalignment. The organisation is forced to bend the well-established processes to fit the product, or the product itself is so customised that the initial benefit in terms of speed and cost is lost altogether.
Large and complex organisations do not function in the same way as an average customer would in a vendor demonstration. A housing society, a logistics company, an NHS supplier, an insurance company, a manufacturing company, a charity or any other organisation which provides multi-site services might have established processes in place for many years now.
A new system will not necessarily make things simpler. It may help reveal them, bury them in spreadsheets, or move them into manual workarounds. In case this mismatch is discovered late, the new system itself becomes yet another source of friction.
If the gap between requirements is quite significant, then a well-defined discovery process and, in certain cases, bespoke software development is preferable.
9 Reasons Ready-Made Software Fails Complex Organisations
It Forces Teams to Change Proven Processes Too Quickly
Standards-based processes are ideal if the processes are truly standardized. They are dangerous if employees are asked to abandon their working processes simply because there is no support from the product.
For instance, a company operating multiple sites can develop one set of approval workflow for all branches. The headquarters will achieve uniformity. However, the local branches will notice a gap in the handing-over process, changes in stock levels or customer checks which do not apply. Employees will do their job outside the system; the platform is used to document the processes.
Poor process fit cannot be resolved by training alone. Where there is resistance from the system, employees will develop software solutions.
It Struggles to Integrate with Legacy Systems
Most sophisticated organisations will have a mixed environment with some of their legacy and new systems. There will be different systems for finance, operations, sales, reporting and other departments. Some of these legacy systems would have limited API access, while others depend on exports from old systems and manual rekeying.
The new system may be very good in itself but may not have any capabilities to interact smoothly with surrounding systems. This could mean duplication of effort if you have a CRM not capable of exporting information to the finance system, or a service platform unable to read asset information, or an HR system not connected with access management.
Software integration issues may go unnoticed up to the moment because they are not visible at sales demonstrations. But the good integration of enterprise systems requires certain answers. Who is responsible for the record? What data will be exchanged? How often? What should be done in case of a failed exchange? Who will support integration?
A focused design and implementation phase will help to provide such answers before the full-scale implementation starts.
It Creates Data Silos Instead of a Single Source of Truth
Leaders require reliable information from various departments. If various departments maintain the same information in various software, then this information sharing will become slow and disputed. The sales department will rely on the CRM, finance will rely on the invoice, operations will rely on spreadsheets, and management may not entirely rely on any of the dashboards.
The data migration process will make it even more difficult. The historical data might end up being duplicated, incomplete, and poorly formatted and might be using fields which are not available in the new product. Pouring such data into a new system without doing data cleansing and data ownership will not help the organisation.
A single source of truth cannot be achieved just by purchasing a reporting tool.
Tailoring Becomes Expensive and Hard to Maintain
Minor customisation looks harmless at the beginning: one additional field, one new authorisation process, one special report, one exception for a certain department. But in the end, those minor customizations can transform a common product into something that no one is able to understand anymore.
Too much customisation makes updates challenging. An update from the vendor can render a custom-developed script obsolete. An upgrade or introduction of new features may conflict with the customised business process. The knowledge of how the product works internally can belong to one administrator or an outside consultant. In case of their departure, support can be more difficult.
Here the hidden costs of commercial-off-the-shelf software become apparent. The buyer pays for licences, installation, customisation, integration problems, support and internal administration costs. The product is no longer cheap; it’s just paid in a different way.
The Vendor Roadmap Controls Your Business Options
The vendor must serve its broader community. While your feature request might make sense, it will face competition from other customers as well as the business needs of the vendor. The modifications made by the vendor to its product might fit its vision better than yours.
Costing and licensing could vary too. The feature could get moved up to a higher plan, there could be API constraints for integration, and the terms of the contract would make moving out tough. This is the vendor lock-in that comes with the product. You might be able to access your data in theory, but moving out could be difficult in reality.
Vendor lock-in should not be a ground for refusing the product outright, but it is definitely something that needs to be taken into consideration before using it. Find out how easy it is to extract your data from the product.
Security, Compliance and Audit Needs Are More Complex Than Expected
Regulated entities require more than just general assertions of security. They could need fine grained permissions, audit trails, approvals, retention requirements, supplier guarantees, secure collaboration and accountability for third party software risks.
UK organisations processing personal information need to think about data protection by design and by default. This means that privacy, necessity, access and safeguards need to be addressed from the beginning of a process or system and not just added on afterwards. UK public sector organisations and their suppliers also need to take accessibility seriously.
Packaged solutions often contain very good controls. The danger is the assumption that a vendor stamp absolves you of any responsibility. Poor configuration, poor permissioning and poor governance will turn a good piece of technology into a compliance issue. In high risk environments, software selection needs to go hand in hand with an understanding of cybersecurity services.
The Product Does Not Scale with Operational Complexity
Not only does scaling involve the addition of users. A process that will work fine with 30 people will not go down fine with 300 people with more departments, locations, approvals, reports, and permission levels.
The decision to select a scalable business software needs to be made on how complex the daily operations will become. How many roles will require different permission levels? How many approval processes are required? How frequent are changes in the process? What will happen if the case, customer, or order moves from one team to another?
There are certain solutions which work very fine in scaling as long as the processes are standardised. However, they fail to scale up if the growth leads to variation beyond what was present in the initial process.
User Adoption Drops When the Software Feels Imposed
Tools which make the job more difficult are not readily adopted, especially if those on the receiving end had no input into the choice process. Those who work the front line know about things which do not appear on the purchasing spreadsheet – the awkward handoff, the weekly exception, the customer comment that needs to be taken account of, the report which needs to be verified before signing off.
Low rates of adoption indicate a poor fit. When users enter information in order to comply with managerial insistence, then the integrity of the data is poor. Where the software does not decrease effort but increases clicks, people revert to using emails, spreadsheets, and messages.
Software adoption change management should begin well before deployment. It should include user research, piloting, clear communications and success criteria.
The Total Cost Becomes Higher Than the Original Business Case
The software licence fee makes up only one component of the total cost of ownership that software users need to consider when making a purchase decision. The cost of software deployment failure will not only reflect in the invoice; it may also amount to hours of fixing errors in the data, revising reports, obtaining approval outside of the new system and giving explanations as to why the expected change has not been made.
A more realistic approach is comparing costs for the next three to five years, not just the cost of the initial subscription year. In addition, it should also account for the cost of not doing anything, since maintaining the wrong system is costly as well.
Warning Signs That Your Software Is No Longer Fit for Purpose
Consider this checklist to perform an operational risk assessment. One or two problems may be manageable, while several problems at once indicate that the system needs an actual assessment.
- Teams depend on Excel spreadsheets external to the platform.
- Employees duplicate the same data multiple times.
- Reporting requires cleaning up before becoming useful to management.
- Users do not use the system unless compelled to do so.
- Integrations fail frequently or require manual exporting.
- Minor updates cost money through the vendor or business partners.
- The compliance team requests features the system lacks.
- Various departments conflict over usage of the product.
- Front-line employees claim that the system fails to represent the true process.
- Managers lack a unified and comprehensive overview of operations.
Unfit software tends to show itself through behaviour rather than board meetings. Workarounds get invented in order to get work done.
When a Standard Product Can Still Work Well
The pre-packaged solution makes most sense where the process is common, the data model is simple, integrations are limited, and the organisation can adopt the workflow of the product. The danger lies in cases where the software has to cater for uncommon processes, complicated approvals, old systems, and stringent reporting requirements.
Such a solution may make a lot of sense when the process does not represent a competitive advantage, when the supplier can take care of the necessary compliance issues, there is good local support available, and when deep customisations are not needed. In case the process is simple, don’t complicate it. In case it is complex, don’t oversimplify it.
Bespoke Software vs Standard Software: The Real Decision
Custom and package solutions do not have to be the best option either. The answer varies depending on the uniqueness of the process, importance of the system, number of integrations required and if the software gives an edge or an everyday boost.
| Decision factor | Packaged product | Bespoke software | Hybrid/configured platform |
|---|---|---|---|
| Upfront speed | Usually fastest to launch | Slower because discovery and build are needed | Medium, depending on settings depth |
| Initial cost | Often lower at the start | Usually higher at the start | Often between the two |
| Long-term flexibility | Limited by vendor features and settings | High if designed and maintained well | Good where the platform supports extension |
| Integration control | Depends on APIs and licence tier | Can be designed around existing systems | Strong if integration is planned early |
| User experience | Standardised for a broad audience | Can match specific roles and workflows | Tailored within platform limits |
| Compliance fit | Strong only if required controls are supported | Can be designed around the compliance model | Good if controls are configurable |
| Vendor dependence | Higher | Lower, though supplier risk still exists | Medium |
| Maintenance responsibility | Vendor manages the core product | Organisation or development partner maintains it | Shared between vendor and partner |
| Scalability | Good for standard growth | Good if architecture is planned properly | Good when platform limits are understood |
| Best use case | Common, low-risk processes | Unique, core or highly regulated workflows | Medium complexity where configuration is enough |
It is not about whether a system will be custom or off-the-shelf. It is about its ability to facilitate workflow, data, user interaction, controls and changes without adding extra friction to the process.
Some businesses will have their ideal system built according to the specific needs. Others might require integration of different platforms. The safest way forward would be the one depending on what the system should be used for.
A Practical Decision Framework for Complex Organisations
Score each question on a scale of 1 to 5, 1 being low complexity, and 5 being high complexity.
- How unique are our processes?
- How many systems does the software have to interface with?
- How sensitive or regulated is the data?
- How accurate do our leaders want reporting to be?
- How many teams/sites/user groups are involved?
- How often do our processes change?
- How expensive is failure/low adoption of the software?
- Do we need a competitive edge with this software?
- Could we work with the vendor’s standard process without affecting service levels?
- What is the total cost over 3 to 5 years?
If the score is low, a standard product will do just fine. A middle score will indicate that a configuration of a platform, hybrid development, or some discovery phase should take place prior to purchase. A high score will indicate that bespoke software development or a staged modernisation/integration approach might be more suitable.
Do not treat the score as a fact. It only helps you to see the complexity upfront.
What to Do Before Replacing or Buying Software
Start with discovery. Outline the existing process, the new future process, data models, integration points, audiences, reporting and compliance risks. Documentation of the users involved in the process, not just those who allocate the budget.
Good requirements identification differentiates between must-haves, should-haves and nice-to-haves. Good requirements documentation also documents reasons behind each requirement. A feature requirement without a justification is prone to causing unnecessary customisation. A business requirement with some proof behind it may influence the selection criteria.
Before going all in on the implementation, validate the riskiest assumptions in a proof-of-concept or pilot project. Will the platform be able to accommodate the approval process? Is the data migration possible without any issues? Can the system integrate with financial and reporting systems? Is the system understandable by the users? Are the security, accessibility and auditing requirements realistic for the selected technology stack?
Phased rollouts tend to be safer than a one-off release. This allows the company to make changes to the data, train its staff, streamline its processes and even learn from the initial users.
This is also the point where software decisions must tie into digital transformation initiatives. The introduction of the system will not digitally transform the business alone. Only when all other elements come into play can it help.
UK Considerations for Complex Organisations
The UK buyer needs to go beyond functionality and pricing. Data security, supplier assurance, accessibility, auditability, level of service and maintainability are all factors which need to be considered.
If there is any use of personal data in such projects, one needs to think about what data is being collected, why it is being collected, who has access to the data, how it will be stored and managed and what kind of risks are being managed by the project. If SaaS or cloud technology is being used, then the buyer must conduct the cybersecurity assessment taking into consideration the controls of the supplier and settings of the buyer.
For organisations in the public sector, accessibility is not optional. There are special requirements for digital services, except if an organisation is exempt from such requirements.
Common Mistakes to Avoid
The first error is making the purchase without mapping the requirements. The slick demo can be masking an unsuitable solution. The second is purchasing based on the longest list of features. Features are useless unless they work to achieve the correct process.
Other errors include forgetting about integration costs, considering training to be the whole adoption strategy, underestimating data migration, calculating licence cost instead of total cost of ownership, and customisation of packaged software that makes it act as a fragile custom solution.
Purchasing must never be done in a vacuum. Operations, IT, finance, compliance, security, and users all have to have their say. Otherwise, the company may end up with a solution that is satisfactory for the tender but not for work.
Example Scenarios
Multi-site operations: The product serves the central office but doesn’t serve the branches due to different approval processes, inventory management practices or client handover procedures at each site. The company tends to over-standardise and annoy the local teams or let the local teams use their methods, which negatively affect the reporting.
Regulated service provider: The team requires a very restrictive access control, approvals, and audit trail. The selected product offers basic role-based controls, but it cannot cover the requirements of the compliance-orientated model without additional fees. Therefore, we get a solution that looks good during the selection process, but causes problems with auditing later on.
Organisation with growth potential: A straightforward cloud-based solution serves well for 30 employees. For 300 employees, the solution will face the reporting and permission challenges since the data structure wasn’t intended to support several departments and managerial levels.
Organisation with legacy systems: The new system is implemented; however, the existing finance, CRM and reporting systems stay in place. Integration becomes an afterthought. Workers have to repeat themselves because the new system doesn’t receive and doesn’t send the necessary information.
Organization with case focus: An off-the-shelf CRM can handle contacts perfectly but fails to deal with issues of ownership, transfer of cases, evidence, notes and level of service. For this type of organisation, a custom-developed CRM case management system is more appropriate.
Conclusion: Do Not Buy Software Before You Understand the Organisation
But off-the-shelf software is not necessarily bad. Badness results from lack of consideration of complexity. The same product could be popular, secure, and highly supported but the wrong solution for a certain company.
For a complex company, the issue here is not “Which product offers the most capabilities?” But “Which solution meets our needs for our operation, security of data, our users, and flexibility to change as we change?” Solve that one first, and the software choice will become a lot easier.
Whatever the right choice may be, whether an out-of-the-box solution, a customized system, an in-house development or a phased transformation, it is important to choose the solution after discovery, cost analysis, and understanding of data, integration, regulatory requirements and adoption.
Frequently Asked Questions
This is software which is off-the-shelf, designed to suit a wide market base as opposed to being designed for one particular organisation. Examples include typical CRM, ERP, HR, finance and project management solutions. This type of solution may be purchased quickly and be useful for standard processes but could be too limited for some special cases.
It is unlikely that this will work since the organisation tends to have many complexities which are more than what is available in the standard workflow offered by the product. This will be seen in such things as legacy systems, unusual approval processes, stringent reporting requirements, multi-site operations, data management and user requirements.
This is not always true. Customised software is more appropriate for unique processes which are critical for an organisation or those that cannot easily be handled by standard software solutions. The packaged solution is more suited for common and low-risk processes. Many organisations require a balanced solution.
The hidden costs include setup, integration, migration of data, customisation, training, support, administration within the business, downtime, management of change and reduced productivity due to low adoption rates. The cost comparison should be based on total cost for three to five years, not just the licence cost.
While SaaS will work for many businesses, it might not always be sufficient if the organisation has complicated business processes, stringent compliance requirements, strange data management policies, high integration needs or multiple user groups requiring varied levels of permission.
Begin with discovery, not procurement. Analyse your processes, collect your requirements, analyse your data, understand your integrations, engage your users, determine compliance, do a pilot, and then roll out the system. Proper change management and phased implementation can prevent a theoretical success from becoming an actual failure.
Your discovery process should encompass all of your stakeholders, your workflow, your data, your integrations, your users’ requirements, compliance, reporting, risks, costs, and deliverables. There should be enough information generated to determine which path to take – a standard product, a configured platform, a bespoke system or a combination of the above.
