One-Stop Shop or Integrated Best of Breed?

14 February 2022

Trying to navigate the decision-making process for procuring new digital tools and solutions for the organization can be fraught with difficulty and complexity.  There are so many features and functions, integrations, platforms, and companies all seemingly offering the best solutions on the market, it can be tricky to whittle down the list of options to those solutions that fit with your environment and meet your operational needs.

A fundamental question that comes up repeatedly as part of this process is;

“Do we look at a single specialized supplier or do we try to combine systems for a best-of-breed solution?” 

As a basic principle, the solutions should be researched based on solving the organization’s problems at the right price.

The consideration of going for a ‘One-Stop Shop’ (OSS) versus an ‘Integrated Best of Breed’ (IBoB) is something likely to come up as the company searches for the right solution.  Typically, the IT strategy will dictate that keeping the number of individual vendors down corporately will reduce the complexity and risk of combining separate vendor solutions. 

Similarly the risk of creating a monopoly for one particular supplier, and the thought of one company having such influence over your operations which can lead to having solutions or technology ‘forced’ on the organization, which can pose a risk to project success. 

This article aims to highlight some areas for discussion based on the experience of supplying software into this environment. 

One-Stop Shop

“OSS” providers are traditionally large global multinationals with a large staff base, with strength and depth in support in delivery globally.  Often there are multiple 3^rd party system integrators (SI) representing the OSS locally, with project elements from implementation to training and support being provided by the SI.  With multiple products, multiple locations, and regional strategies, this can lead to inconsistency in the focus on particular solutions and varying quality of support across different regions.

Lack of specialist functionality in some cases and too much functionality in others is a result of a company catering for a wide audience and set of functional solutions without a specific focus or expertise area.  Retaining staff dedicated to particular functional areas, who are likely moving between several functional units and solutions can raise an objection to this approach.  Although, having a company with multiple layers, and a huge range of technical solutions can often mean that larger companies choose to work with a vendor providing expertise, strength, and depth.

A large user community however can lead to a large knowledge base and that can pose a significant advantage to the company.  More reference material, more case studies, more user experiences feed into a community to improve the knowledge of individual companies, with the OSS a conduit for information.

 In many cases, these OSS companies find user communities setting up outside the ‘control’ of the organization as an unofficial body discussing experiences, suggesting improvements, and creating a cross-pollination of ideas.

When it comes to implementation, OSS companies tend to have cross-functional and large project teams which while valuable can sometimes come at a significant cost.  Project teams in this vein are often aligned to one corporate set of costs and project management methodologies that can appear expensive and inflexible for some customer environments and solution teams.  Once committed to a company of this nature it does become more and more difficult to consider moving away from the selected vendor because of time and capital already invested in the project. 

Companies that choose to opt for an IBoB approach do so because it offers them the opportunity to select from a variety of solutions that will work together to form a targeted set of functionality that better suits the environment.  Although integration overheads may be more prominent, as specific interfaces are needed to get systems to align together, the perception is that best of breed can offer benefits that need to be considered by the organization.

Integrated Best of Breed

When using the “IBoB” approach you do get more niche and targeted functionality that may better suit your environment but may have the extra work and risk of managing integration between the different systems onsite.  Specifically, IT departments taking on separate but integrated solutions in IBoB approach, find that they may have to support different environments, real-time interfaces, and extra infrastructure to support the solution.  Troubleshooting problems, especially within integration can be time-consuming and add extra workload for the IT support of the business.

Another major benefit is the dedication and focus of teams associated with IBoB style of implementation.  Functional areas can be focussed on point solutions that are run as independent projects, to a point, before bringing together the solutions in an integrated manner overall. 

From a user perspective there is the fact that if using multiple systems, the interfaces and UX will be different so more training may be required. Although this is often offset by the simplicity and ease of the UI in best of breed, which in the case of NiSoft’s eclipse Suite, it is designed to mimic the layouts and processes you currently use on paper or in another computerized system. 

When looking at the development and functionality of systems, the best of breed systems are so-called, because the focus is on the specific functionality of their product and the sector(s) they work in.

Another major advantage of the iBoB is also being able to upgrade or change components of a corporate software setup without the need to disrupt the entire company.

Factors to Consider

Some major factors to consider when choosing which approach to take (iBoB vs OSS):

• Price – Look for hidden or future cost implications, both initial price and price to change and maintain.
• Functionality – Does the system provide exactly what you need or do they need to have custom variants created or compromises made to achieve overall goal. Always ensure configuration is used rather than custom components (Development) that is hard to support and upgrade.
• Integration – when selecting multiple systems, ensure that integration is possible between systems and understand what is needed to a low level of detail.  Look at other specialist modules from the providers to minimise the interfaces whilst still getting specialist functionality.
• Management of Change – What impact will the implementation have on the organisation, the staff that will need to be involved and can this be phased or compartmentalised to allow them to still maintain focus on their main job area.
• Support – What level of support do you need and are the correct experts available in your area/time zone?
• Future – How easy is it to change the system if new processes and technology are introduced. Does the provider offer an upgrade path and are they focussed on the industry to adapt to new requirements?

These are just some of the points that have come up over the years when discussing these topics and having had the experience of implementing both “one-stop shop” corporate solutions as well as “integrated best of breed” solutions.  Each company will have its own approach and preference and it would be good to hear from you in terms of how your organization approaches this and the pros and cons that you see.

Contact us for more information on what solutions might best fit at your organization, sales@nisoft.com