Ten or so years ago, IT departments were enthusiastically adopting best of breed software policies. Different software applications had areas of particular strength, so it made some sense for a company to cherry pick its way through the market offerings, choosing only those applications that best fit the company needs.

Companies purchased ERP [enterprise resource planning] software, warehousing systems, financials software, customer resource management systems, supply chain management systems, asset management systems, transport systems and more. Rather than requiring one big deployment project, the best of breed policy allowed IT departments to focus on discrete needs and to purchase and implement applications over a period of years. Because each solution typically involved a limited number of people or departments, the impact of the deployments was contained. There seemed to be less “bad press” or disruption to the overall business compared to a major integrated systems deployment.

Fast forward to today, however, and things have changed. Software vendors have realised that there is far more money to be made by offering stronger, more comprehensive, tightly integrated ERP suites. Over the past few years vendors have been actively acquiring technologies and developing their systems, so that today, the market offers a wide range of integrated solutions for every need.



The passage of time has also helped to highlight an underlying problem with the best of breed policy: best of breed is a tunnel vision policy that ignores the need for a holistic view of the business. Disparate systems may work well on their own, but they can’t always talk together easily or effectively. This has a major affect on management’s ability to view the business and negatively impacts business agility.

It can be a nightmare trying to integrate best of breed applications to create a cohesive whole that is capable of sharing data, supporting workflows and facilitating automation and process efficiencies.

The problem with integration starts with deployment. A business must be able to import existing finance, distribution and data, customer contact information from sources such as spreadsheets or an accounting package.

The second and more critical integration issue is the need for the ERP system to work seamlessly with other systems such as manufacturing and distribution systems, or with the systems used by suppliers and customers. For example, if a business deals with any of Australia’s major supermarket chains, it is likely to receive orders online via an Electronic Data Interchange [EDI] system. A collection of best of breed applications will have difficulty dealing efficiently with an EDI order. In these circumstances, staff often find themselves double entering data into different systems, dealing with different databases that between them, hold multiple versions of the truth. Trying to ascertain the exact status of an order – from production, sales and distribution systems – can be all but impossible.

Compare this to an integrated ERP suite that receives and processes the order, automatically forwarding information from one department to the next so that the order is accepted and documented, picked, dispatched and invoiced as quickly and effortlessly as possible. The transaction is reflected in production plans and inventory. Right across the business, the flow on effect is noted and actioned.

To get around the problem of isolated applications, companies may try to integrate their disparate systems but there’s always a lingering concern over whether modifications or future application upgrades will affect the integration and whether further development will be required with each change to the system.

Moreover, it takes time and money to establish integration between applications that were never designed to talk to one another. Although a fully integrated ERP solution may initially appear to cost more than a selection of disparate applications, once the cost of integration is factored in, the best of breed solution is quite likely to emerge as the more expensive approach.


Individuality is an interesting and engaging trait in a person but when it comes to software, consistency in appearance, operation and performance is important. Within an integrated solution, every module is designed to work the same ways as all the others. Once staff learn one module, they pretty much know how the others are going to operate.

When using best of breed software however, every application has its own unique characteristics. Screens, short cuts, command keys will all differ. This makes it harder for staff to learn the systems. It takes longer for new staff to become productive and, because each application works differently, there is a higher potential for error.


There’s one more major differentiating factor between best of breed and integrated ERP solutions. The former approach involves dealing with multiple suppliers for deployment, support, maintenance and training. There are many relationships to be established and managed. The latter involves just one supplier. When things need to be modified or customised, or if the business wants to provide input on the future direction of the software, there’s just one relationship to deal with, and one organisation to contact.

The changes in the market over the past decade have turned the tables on the best of breed versus integrated ERP solution debate. Due to the problems of integration, lack of uniformity and the sheer number of vendors involved, best of breed solutions have become more complex, more costly and more time consuming to deploy and manage when compared to integrated software suites. When you look at the lifespan of business software, the changes and upgrades that will occur over that time, the costs to maintain the system and the business benefits that accrue from free flowing data, it’s clear why organisations are choosing to ditch their best of breed policies in favour of integrated ERP suites.


Why You Should Care About The Database Behind Your Erp

When choosing an ERP [enterprise resource planning system], companies typically look at the range of applications, the features and functionality of the software. They want to know that it will support all the different areas of the business, from the supply chain and logistics to transport. They look for functionality to support advanced planning and material demand control, forecasting, sales, cost control, quality assurance, traceability and more. Only occasionally does anyone stop to think about the underlying database. And this is a pity because in an ERP, the database lies at the very heart of the solution.

The job of the database is to support all the applications. It provides the common repository of data that is crucial when trying to share information between applications, people, departments and partners. The speed of the database, its flexibility and scalability has a profound affect on the performance of the ERP.

Unfortunately, discussions about databases can easily veer into technical territory. Talk about spatial, text, binary and other types of data, transaction loads, platforms, terabytes and petabytes can quickly leave non-technical participants out in the cold. The temptation then is to simply ignore the database and focus instead on the far easier topics of features and functionality. But it doesn’t have to be so.

Following are some very simple suggestions that will help you to understand and evaluate the suitability of a database the next time you go looking for an ERP.



There are many different kinds of databases but two of the most commonly found – among legacy and modern ERP offerings, from small-to-medium up to large solutions – are SQL Server and Oracle. These robust technologies are well-proven, capable of underpinning numerous applications and able to cope with the tens of thousands of daily transactions involved in large-scale manufacturing, distribution and logistics businesses.

Within the sector, there is also a large number of organisations relying on commercial or bespoke ERP systems based on legacy database infrastructure. In other words, the applications have been developed on older databases that may not be able to deliver the reliability, scalability, flexibility and availability expected in business today.

Two examples of legacy databases that periodically turn up in small-to-medium legacy solutions are FoxPro and Access. Never designed for the kinds of demands of an ERP and limited in their size and capabilities, it doesn’t take long for companies to find they are pushing the limits of these systems. More importantly in the case of FoxPro, the database is now at the end of its life, no longer supported by Microsoft. This raises the very real likelihood that one day soon, a new security patch for Microsoft Windows may inadvertently “break” the database permanently.

Even when the applications themselves are relatively modern, if the underlying database is from a past generation, there are many complications that can arise. The older the database, the harder it becomes to find the programming skills necessary to maintain and update the system. And, the rarer the skills, the more expensive they are to acquire.

Moreover, when dealing with databases developed a decade or more ago it can be difficult, if not impossible, to establish connections to the standard tools of today such as tablets, warehouse scanners or other third party peripherals.


The typical lifespan of an ERP system within the logistics sector is around ten years. So when you enter into a partnership with a software vendor, you’ll typically look for assurance that they are going to be there for the long haul. But what about the database – this incredibly important part of the software infrastructure?

Is your database current-generation or, like the FoxPro example above, is it at the end of its lifecycle? Will your choice be supported for the ten or so years you plan to use your ERP system?


The most logical place to start is with standards. Look for an ERP that adheres to industry standards, or even better, one that because of its popularity, has become an industry standard. This will give you the security of a path forwards in future years and will make it easier to integrate and add to your solution with new software or peripherals over time.

For security of mind and certainty of longevity, look for software powered by a proven, market-leading database. The more popular the database, the longer it is likely to be supported by the vendor.

Other essentials include scalability to cope with business growth and reliability of performance. You do want to know the system is likely to keep on operating. Also think about the availability of skills for your chosen database, not just across the overall employment market, but within the logistics sector and your geography.


For reasons of cost, performance and longevity, it’s obvious the database plays an important role when choosing an ERP system. For an enduring return on your ERP investment, look for a database that has the proven power and performance to support the complexity of an ERP. It should be affordable and scalable. Even better, choose a database that has already established itself as the leading industry standard, such as Microsoft SQL Server.

That said, it’s also important to keep in mind the database is just one of the factors that will influence your ERP purchase. A system that doesn’t have the functionality your business requires will be a poor investment, regardless of the quality of its database. Just as a great solution sitting on top of an outdated database will never provide the performance a modern business needs.

Perhaps it’s best to consider the database as a critical item in the check-list, right next to the list of functional areas you need to address and the must-have features that will help improve processes and performance. When you find an ERP solution that offers a fit across all three areas, you’ll know you’ve found the right solution for your needs.