"Software Packages vs. Custom Software"
You'll Usually Start Out with a Package, But Beware of "Best Practices"...
I can think of few situations where you would not want to at least start out with "a package". Accept in rare circumstances you don't need to write a custom G/L, A/R A/P module, etc. So you obviously shop for a package that gives you the "best fit" for your overall business. I argue that this is your starting point. Here's why...
Usually you will find that no package will do exactly what you do now... at least I've never found one that does. The "packages" tout that they use "best practices" and ideally list several customers successfully using the package. The argument coming from the vendor and often from top management is that if you're currently doing something different you must be wrong and you should change your ways to conform with the package.
This is a valid argument at least for some modules. But step back from it. "Best practices" says who? Are any of the differences between what you do and the best practices implemented in the package positively differentiated yourself from your competition and one of the reasons your company has been successful and grown in the first place?
Cost of Licensing Additional Users
Determine the success rate for implementing the package.
Ask the software salesman to tell you the success rate for the successful implementation of packages sold. Expect the same response Rodney Dangerfield responded to his English teacher in the movie Back to School when asked to comment on the book The Great Gatesby saying "It was.... Great!". But seriously this is a tough one. And there is the issue of defining "successfully implemented" because having installed one or two modules out of 20 is not implemented.
The best source of this information is through users groups by attending their meetings or by visiting the users group's web site. Doing an Internet search for "problems XYZ package" and similar searches may be helpful.
Determine the Percentage of the Vendor's Revenue Derived from Consulting and Support vs Software Sales
Software vendor's revenue resulting from consulting and support often exceeds the revenue from software sales. It is not uncommon for companies to permanently assign offices to their software consultants.
If the software company is publicly traded this information is usually available. Things get more complicated when the software vendor is privately held. The best approach in the case of privately owned vendors is to talk to their customers. And this does not necessarily mean talking to the customers that they suggest. Sometimes asking the customers that the vendor does suggest about other companies using the package is helpful. Try to find users groups for the software where you might attend their meetings or review information posted on the Internet. Query the Internet directly for problems regarding the software package or the vendor.
You simply cannot be too careful when selecting a package. It is an expensive, long term commitment that will directly impact the future of your company.
Complexity as a result of trying to be all things for all people
Large packages are designed to fulfill the needs of a wide variety of industries. As such their database can be complex and consist of hundreds and often thousands of tables. Setups are complex and if mistakes are made the consequences may not appear for weeks or sometimes even months.
Trying to untangle the mess can be complicated and costly and some errors are never fully resolved. There are some major packages where the documentation providing the road map through the database maze is not only poor but is not even written in English.
A Disastrous Example of Choosing a Package for the Wrong Reasons
I've personally witnessed a service company who replaced software that was functioning perfectly and supporting remarkable growth so that marketing could boast the company now uses a very big name software package. But the problem was that the old software package functioned very much like a helicopter performing a myriad of diverse functions demanded by very different customers. The "big name" package functioned like a Boeing 777 and could perform one function... the best practice for that function... extremely well. Sadly that "best practice" did not conform to the majority of the customers' needs. The company then proceeded to spend close to $20MM dollars trying to make the "big name" software function like a helicopter. Obviously a Boeing 777 can never be made to function like a helicopter... they failed... and they lost over half their customers. But they still have the "big name" software because it's too expensive to write off the loss.
Modifications & Custom Software
Modifications to Software Packages
Establish completion dates... agreed to in writing with non-delivery penalties... for all modifications.
Many times the excessive costs of attempting to implement the software are so great that it is financially impossible to abandon the project and endure the write-off. Establish implementation benchmarks in terms of time and implementation costs.
If you don't you'll soon find out that your primary goal of your business is no longer manufacturing your product or providing your service. Instead your goal will be to install the software and somehow make it work to avoid going out of business.
Important Things to Consider When Modifying a Package
Will the Modification be Built Into the Generic Software Package or in Your Copy Only
If the modification is built into the stock package it will be available to everyone in the next release. If the modification represents something you do that's unique giving you a strategic advantage over the competition you just lost that strategic advantage.
Avoid Modifying the Stock Code or Data Structures
Avoid unnecessary problems with new releases by creating ancillary and parallel tables.
|Copyright 2014 NJN Consulting All Rights Reserved - Software Package Evaluation, Package Modifications & Customer Software|