Why Avoid Third Party Add-Ons to QAD
Joe Drouillard 
Principal/Consultant
Avenue Systems LLC
http://www.avenue-systems.com/

Many third party software solutions are written in another programming language, then altered to update the QAD database.  Most come at a high price, with high annual maintenance and licensing costs which must be paid for each database instance.  And for the high price, you often get very poor interfaces to QAD and very poor support.  Most come without source code, so you cannot make any changes ore even look under the hood.   Many are bloated, with features your company will not need.  Most will STILL have their own missing 5%.  You are forced to "do without" or pay the high third party consultant rates to get a good fit.  And then you are left with a non-standard custom version which is difficult to upgrade.  

Most third party solutions duplicate data and functionality already found in QAD.  This leads to dual maintenance of data and multiple systems with the same functionality, leading to confusion among users.  Multiple "silos" of data, functionality, understanding/knowledge, come with a security nightmare.  Repeated licensing and maintenance fees kick-in when Mfg/Pro is implemented at a new subsidiary or location.  When the SALE of a subsidiary or plant is ever attempted, the cost to the purchaser of establishing and maintaining this complex infrastructure must surely be considered. 

When a Progress solution is crafted with the same "look and feel" of QAD, a company gets exactly what they need, typically maximizing the use of  "vanilla" functionality and data stored in QAD.  New data tables are placed in the same database structure as QAD, eliminating the multiple data silos problem.  No new maintenance or license fees are required.  When crafted using QAD best practices, supplemental modules will never compromise the implementation of a QAD upgrade, and will fully utilize its security tables.

Some examples based on my experiences:  

  • I designed a barcode labeling/scanning/shipping and EDI interface module for a client that was developed for 90K.  It was then implemented globally on dozens of databases, saving my client millions as compared to the third party alternative they were considering.  Internal IT staff then expanded it to include scanning functionality throughout many additional departments, utilizing examples developed in the first instance to greatly automate data collection throughout the organization.. 
  • I came to a recent client when they were already committed to using all third-party alternatives (a total of six!), ostensibly to avoid adding permanent Progress programming staff in IT.  They now employ easily double the IT programming staff supporting multiple programming languages and hardware infrastructure (many more PC servers in what was otherwise a totally UNIX Mfg/Pro implementation) to support these applications.  As a result, 6 otherwise unnecessary IT staff have been added to avoid hiring two Progress programmers, resulting in a much more complex and fragile environment, subject to many more potential points of failure.

My suggestion is to obtain an estimate from a consultant or employee who has already developed (perhaps several times) the equivalent to the third party solution under consideration.  Double or triple the estimate, then have Finance do a cost analysis.  Make sure that 100% of source code is included if developed by a consultant, and that it corresponds with QAD's best practices for the development of custom code that should never hinder the upgrade to a new release of Mfg/Pro.  And, make sure it utilizes QAD security, or you will have a nightmare at your next SOX audit. 

Please feel free to contact me if you would like assistance. 

 

J o s e p h  D r o u i l l a r d
Principal/Consultant
Avenue Systems
Detroit Contract Progress/QAD
40928 Kingsley Ln
Novi Michigan 48377
joe "at" avenue-systems "dot" com
http://www.avenue-systems.com/

 

 

 



© 2011 Avenue Systems LLC
Valid HTML 4.01 Transitional     Valid CSS 2.01