“Best of Breed”… or “total solution”

This is an old discussion, but seems to have resonance recently.

There is a school of thought, espoused largely by ERP vendors, suggesting that organizations should have a single all-encompassing solution for everything that ails them.  Other words used to describe this approach are:  Sole source; single system; enterprise; extended ERP; comprehensive; one stop shop.

Contrary to what they would have you believe, ERP is NOT the panacea – in fact it can be a black hole as the US Air Force has discovered, cancelling an ERP rollout that started 10 years and over $1,000,000,000 ago, with an estimate of another billion before any return was expected:


ERP vendors seem to think that the inventory, billing and accounting is the hard part.  All the operational, supply chain, engineering, performance monitoring, and compliance stuff is simple.     I beg to differ – accounting has rules that are understood worldwide, whereas operational systems tend to have no right answer, are innovative, and differ from organization to organization. Operational system users are not usually as computer-savy as ERP users tend to be.  ERP vendors foster the belief that if one can provide “software for manufacturers”, that means every conceivable aspect of software for manufacturers – ERP, MES, MOM, LIMS, PLM, CAD, CAM, SCADA, EDI, Warehouse Management, CRM….  As if each is not an island of expertise!

There is a competing school that suggests that an organization should obtain the best solution for a particular problem, and, if necessary, integrate any solutions that might result in duplication of data.  This is called “Best-of-Breed”, and until recent marketing pushes by the ERP community, was the acknowledged preferred approach.

Incidentally, many of the same vendors who trash the best-of-breed approach are often selling solutions that are actually a mishmash of apps bought/acquired from multiple companies and cobbled together into an “total solution”.  Except for the vendor’s name on the box, this is no different than a best-of-breed solution (except that perhaps each module does not represent the “best”, just an “also ran”).  The vendor is the integrator – you just don’t know it…. until later.

So which approach is right?

As usual, the answer is “it depends”.  Marketing is so very prevalent in software solutions today, that I do not envy you the decision.  Typically I find an inverse relationship between best marketer and best system.  [Every dollar spent on marketing is not spent on development and support]  I have seen solutions purporting to be “SPC” that are comprehensive systems, overkill in fact… I have also seen “SPC” systems that are nothing more than a single run chart! (Surprisingly the single run chart was the most expensive – because it was part of a very expensive ERP system)  I have seen incredibly intuitive plant scheduling systems that automatically optimize schedules in near real-time based on sophisticated algorithms… or cumbersome scheduling systems that are really nothing more than a “to do list”.   (Again, the latter being far more expensive!)

If you need a formal sedan to escort clients, and a 20 foot cube van to deliver products, do you get:

  1. A basic SUV (the comprehensive solution) that may not have quite enough room to handle the deliveries optimally and be much less luxurious for the clients; (jack of all trades) or
  2. A luxury SUV that will provide luxury for clients but have the same cargo constraints at a premium price (not to mention the leather will be destroyed by packing product in); (expensive jack-of-all-trades) or
  3. A luxury sedan with towing package and a cube trailer (the integrated best-of-breed approach which answers both requirements completely); or
  4. A luxury sedan AND a cube van with a communication system (the ultimate best-of-breed:  integration as necessary; twice the transportation capability; lower price than the luxury SUV)

All are viable solutions!  In this scenario, I would probably go with option 4, or 3 if cost was a major constraint, all other things being equal.

Surprisingly, the approach is often more a function of who is making the decision.  If the actual end-user decides, best-of-breed will almost always be the result.  If someone removed from the actual need makes the decision, often the “comprehensive solution” will be chosen.

Why?  Simple.  As Marc Cuban says “it is always the little decisions that have the biggest impact”.  The end user knows the subtleties of what is needed.  In a recipe management system there are many capabilities that can make one system orders of magnitude better – little things obvious to R&D, but that the “big picture person” cannot comprehend: to her, simply having a Bill of Materials is sufficient, isn’t it?  That is, after all, the recipe. Even though as a “recipe management solution” this has no ROI to the R&D user, it does provide a single user interface.  Like buying a sports car with a trailer hitch to make deliveries… a vehicle with no towing capacity that would be destroyed by towing anything substantial.  But hey, it has a trailer hitch so it meets the need.

I have seen organizations acquire document management systems in order to do recipe management.  True, one can build a formula system in a document control / workflow system; one can build a cube on the back of a sports car too – but why not just buy a cube van?

Unfortunately the comprehensive alternative is usually extremely expensive, especially in terms of opportunity cost.  It often takes 2-5 years to find out that the dream being sold by the ERP vendor is not reality.  I have clients who bought SAP almost 2 years ago and are still waiting to run their first invoice that was supposed to be a year ago… yet they still believe that SAP can meet all of their MES needs (or will in the “Next Release”).   Are not the Emperor’s clothes magnificent?  Conversely, many of our SPC, MES, and scheduling users are SAP (and other ERP) users who tried and failed.

Proponents of “sole source” cite the following advantages: (borrowed from various web sites)

  • A single development vision for all ERP, manufacturing, MES, and Supply Chain requirements
  • Single point of contact for all technical support
  • One set of tables in a database with transactions updated instantly throughout the entire system, in real-time.
  • Single maintenance agreement, one development team, consistent user interface
  • Lower overall cost of investment, lower maintenance costs, Quicker ROI

And to restate as negatives to best of breed:   

Eliminate Hidden Costs of Third Party (“best of breed”) MES and ERP Integration

  • Higher implementation costs associated with the “integration” of the disparate systems
  • Time delay when transferring data between applications and databases
  • Finger pointing when it comes to identifying a system problem
  • Multiple maintenance agreements, multiple points of software support
  • Higher maintenance fees, Incompatible upgrades
  • Multiple databases that create a complex, problematic system architecture
  • Problems and inconsistencies when creating reports across multiple databases
  • Multiple vendors with different business strategies and visions

A pretty compelling argument.  But the reality is that the addition of modules to the vendor’s arsenal is a way to solidify your reliance on that vendor, and to increase his revenue.  Just because one knows about accounting and inventory doesn’t mean he knows quality management and process monitoring.  No one can be a master of all trades – best case would be jack of all trades.

Best-of-breed may be less expensive (from both a licensing and support perspective) and almost certainly will be more robust.  If properly integrated, there should be no problems with upgrades to either system – any system that regularly restructures the database tables is not a system you want anyway.  While it may be true that here is a possibility of finger-pointing by the respective vendor support people, a good support person wants to solve the problem, regardless of whether it is her system that actually caused it.  Besides, your support comes from the integrator who supplied all of the modules – to you this is a single application.   A large portion of system problems are with the underlying Microsoft or other vendor code anyway.

From a “common user interface” perspective, about 90% of the rules surrounding user interface design are dictated by Microsoft.  Is it difficult to navigate web pages on different sites?  Navigating different applications is no more difficult.

Last but not least, one of the biggest risks is to bite off more than you can chew.  Separate teams implementing best-of-breed solutions each have a good probability of success; but one team trying to balance ten or more modules of a single solution is easily overwhelmed…  rather than 3 of 10 applications running profitably in a year, the result is nothing running for a number of years.

Finally, having multiple developers with different visions is probably desirable.  Oversimplified, the vision of an ERP vendor is to have a financially sound and controlled system.  Is that the same vision you want for a recall, compliance or quality system?  Certainly cost is a consideration, but perhaps public safety and/or compliance to regulations would be a more important priority for these systems?

This is not to say that one cannot go overboard on Best-of-Breed.  We have clients that have multiple Document Management systems, where one is more than sufficient.  Or have separate LIMS and SPC systems, even though they overlap by about 95%.

So, in summary, if (and only if) your internal specialists find that the applicable module meets or exceeds their needs, consider a single vendor solution.  Your needs may not be that complicated.  But don’t be afraid to get the best solution for each need you have – integrating them is not near as difficult as the sole source vendors threaten.  If you have a good systems integrator, it should not be evident that there are multiple applications involved.  

It appears that the expectations of the market agree with me.  In its review of trends going into 2013, Panorama Consulting suggests: “Best-of-breed solutions will continue to chip away at single-system ERP software. With more companies moving away from big, single-system ERP deployments, there will be a continuing opportunity for niche and best-of-breed ERP systems to capture market share in 2013. Vendors… with their best-of-breed solution focus, will be better positioned to respond to customer demand of this type.  http://panorama-consulting.com/top-ten-predictions-for-the-global-erp-industry-in-2013/

It is so gratifying when other experts agree with you, isn’t it!

Getting new software – Make or Buy?

This is a huge question facing every buyer of software today.  Why does Joe, the owner of Joes Baked Goods LLC, a $100 million bakery thinks he can hire his brother-in-law’s son “the geek” for a summer and have the same Manufacturing Execution Tools that others have paid hundreds of thousands for?   If it was that easy, as they say, everyone would be doing it.

There is no question that with the tools and technical expertise available today, many solutions can be built in-house [and some should].  But, these should be very specific, very contained, very well defined, very organization-specific, and/or very confidential solutions.  They should be single-user or at worst, workgroup solutions.

To even consider building an integrated enterprise solution today should be met with a great deal of skepticism by management.

In most cases today, there is a well-written, well-supported, fully-featured parametric package out there that will do what needs doing, and much better than anything you can build – even given unlimited time and money.  Do you want ABC Biscuit Company to make the best biscuits; or to become the ABC Biscuit, Software & Computer Company?

Conversely though, your software often gives you a competitive advantage.  If the software supplier that is telling you how you need to run your process (because that is the way their software works) could run your business as well as you can, perhaps they should be in your business rather than software!  However, there is still probably another package that is adaptable to the way you do things.

So there are some unique circumstances when building your own, is a viable option – but that is usually where proprietary processes are involved, or you come up with a need that no one has ever automated before – unlikely but feasible.  The trick is to know the difference.

Remember the inevitable laws of software development, all of which are unfortunately true:

90-90 law :  “The first 90% of the software takes 90% of the time to build, and the last 10% of the software takes the other 90% of the time.”

Cheops’ Law:  “Nothing ever gets built on schedule or within budget.”

Brook’s law:  “Adding manpower to a late software project makes it later.”

Starting down the “we can build it, they will come” road is costly.  I have seen clients delay implementing a solution because they are going to write it.  Years later, they are still going to write it.  If they had implemented the package solution in the meantime, just as an interim solution while they were writing the panacea, they would have paid for the package several times over from savings.

Sure, $100,000 or more may be a lot of money to invest in a solution, even if it saves $500,000.  Perhaps putting a couple of junior programmers in a room for 6 months to a year will give you at least the basics you need in your business – you don’t need all the bells and whistles that the $100K package has.  So pay each of these guys just $60,000 a year ($120K), plus benefits ($30K), give them an office ($5K), development software ($10K), and computer horsepower ($5K), and give them unlimited access to the user community that they will need to develop a responsive package ($$$).  And get someone to write decent user documentation (about 30% of the cost of any system).

What most people don’t realize is that it is not the writing of the code that is difficult – exceptional coders are available – it is the ability to understand user requirements and translate them into workable system definitions that work in the culture and are supportable on current and future platforms – that is the key to success.  This is why sending the code offshore to be “developed” in India often fails.  In order for the Indian coders (who are very good) to write it correctly, you have to take the time to define it in infinitesimal detail – so now you need to add your time to the expense calculation.


At the end of the year I guarantee you will have a half-written, very basic single-user partial solution, and be out about $300,000 in salaries and expenses – not to mention the opportunity cost of not having a solution in the meantime. Even if the junior programmers produce exactly what you need in the time promised (you would be the first), you will still have spent $300,000 and lost a year getting part of a $100,000 solution.

So, to avoid this, you will decide to hire a “professional” consultant, or software developer.  You still need the detailed definition.  All you have accomplished is a restart, and a cost base of $100+ per hour, instead of $30.

I personally wrote my own Client Database several years ago.  Took about 6 months and did exactly what I thought we needed.  Single user.  Then we bought a commercially available CRM.  Cost about the same as the underlying database and supporting software for my custom system.  Had everything mine had, and hundreds of other features we could use, but I had not even thought of.  And it was designed for enterprise use.  No brainer!  We still use it.

At QIC we have developers on staff to perform integration for clients.  They are beyond programmers – for the most part they can define the details and understand the business processes behind the software.  If anyone is positioned to write our own, we are.  And yet, every system we use internally is an application package.  There is a reason for that.

Is our Food safe?

The recent outbreak of Escherichia coli in meat shipped by XL Foods has raised food safety to new heights in the public eye.  Despite the significance of this mammoth recall, my experience in food plants over the past 20 years tells me that overall our food is getting safer, and food safety is achieving a higher priority in many food companies.  The problem is that big box stores, and food industry amalgamation means that when a problem occurs, it is no longer a local manufacturer and local stores – it is a continent, or more, with millions of people potentially affected.   The XL Foods recall represents over 2,948,00 pounds of product… perhaps not as much as the 25,000,000 pounds  in 1997 (Hudson Foods) or 21,700,000 pounds (Topps in 2007), but pretty big nevertheless.

According to the Centers for Disease Control in Atlanta, [Rangel JM, Sparling PH, Crowe C, Griffin PM, Swerdlow DL. Epidemiology of Escherichia coli O157:H7 (the most common strain of E.coli) outbreaks, United States, 1982–2002. Emerg Infect Dis [serial on the Internet]. 2004 Apr. Available from   http://wwwnc.cdc.gov/eid/article/11/4/04-0739.htm] e.coli 0157:H7 causes 73,000 illnesses in the US each year resulting in 61 deaths annually.  From 1982 – 2002, 49 states reported 350 outbreaks of which 52% were foodborne – 41% of which were from ground beef and 21% from produce.

It is important to note that “foodborne” does not necessarily refer the manufacturing channel – it includes restaurants (which may be manufacturer, handling, or restaurant caused).  A small number of ground beef related outbreaks were restaurant “associated”, while a majority of the produce related outbreaks were restaurant “associated”.  NO fast-food related hamburger outbreaks have been reported since 1995, which shows the impact of food safety awareness.  According to most sources, E.coli O157:H7 is killed by “properly” cooking meat, so the industry could say that preparation is everything; nevertheless the U.S.D.A. banned the sale of ground beef contaminated with the O157:H7 strain in 1994.

The number of e.coli outbreaks (or perhaps the reporting of outbreaks) rose from 1993 to 2000, and then started to recede.  The other good news is that the median outbreak size has declined over the entire time.  It would be interesting to know whether that decline is a result of faster reaction time, better containment, or better food safety. The authors of the study attribute the decreased outbreak size to increased reporting of less “clinically severe outbreaks”.  In layman’s language, more reporting of smaller outbreaks is essentially watering down the numbers.

I couldn’t find any empirical studies with statistics after 2002, but a review of media reports seems to indicate that incidence is on the rise again after 2007, but that may just be because of the huge size, or media exposure of recent recalls.

As the food industry goes through a similar transformation in quality as the automotive industry underwent in the eighties, we can hope that food safety continues to improve.  By showing HACCP points, GFSI data, Process Profiles, Test results and other information to operators in real time, reaction time is improved:  actions can be taken that can respond to potential food safety concerns before they materialize.

Nevertheless, I never ceased to be amazed at how many very large food companies are still using paper, or worse.  There is nothing wrong with paper systems, per se, but they certainly do not elevate alarms as quickly or as accurately as automated systems, properly deployed.

Food Safety is as much an attitude as it is a quality system.  Even if systems exist to drive sanitation, traceability, and testing, if concern for food safety is not ingrained into staff, then we can expect to see more outbreaks.  Having said that, the existence of, and investment in, food safety monitoring systems does send a message to employees that food safety is a priority for management.  I remain hopeful that our entire supply chain is getting safer every day.