You need to open up a new market, cut costs, or automate a process. New software can help solve this problem, but which software meets your needs?
There are three main categories of software: 1) packaged software, 2) software as a service (SaaS), and 3) custom software. This article covers the pros and cons of each type of software and can help you make the right purchase decision for your business.
When is packaged software or SaaS the right choice?
If you want a word processor, email client, or accounting package, it's been done. The products are numerous, mature, and range from free to very reasonably-priced.
More and more business software is falling into this commodity space, such as enterprise content management solutions, document management programs, and customer relationship management (CRM) software. These tools have a single purpose and usually very good at what they do.
Cost wise, buying software is usually cheaper than building custom software. As we'll see later on, there are some caveats to this, but this conventional wisdom is often correct.
This is where most software evaluations end. It meets your requirements and it's cheaper. Make the purchase and move on, right? Well hold on a sec.
There are some risks to packaged software and SaaS that are often overlooked:
- They often include modules you don't want and may not be an exact fit for your business. Adding the modules you do want is extra. So is implementing the software and customizing it to fit your business.
- They work in functional silos and are usually from multiple vendors. You've got to be sure it will integrate with your other systems.
- They may not let you get the data out the way you want it.
- Your users may not be as excited about your choice as you are.
Let's take a closer look at these problems and when they may ultimately push your decision to the custom software side.
Get just what you want, no more, no less
Buying software "off the rack" is the way to go if the package meets all your business requirements. But most of the time, you're buying functionality you don't need and missing functionality you do need. You shouldn't have to change your business to match the software you've just purchased.
The common answer is to have consultants implement a solution and customize it to your business. If the packaged software is a good fit with your requirements, this can be a good choice, too. You just want the consultants to come in and round out the corners, though. They shouldn't need to rewrite anything; just configure it for your organization and maybe integrate your new software with some of your existing systems.
But at some point (and it should be pretty soon after the install), the consultants should finish and go home. If they need to stick around for lots of customizations or integrations, you may have lost the justification for buying instead of building it. And don't forget that all those customizations can't just be thrown out when the vendor rolls out the next version of the product you've bought. Too many companies make this mistake and fall into a cycle of perpetually customizing packaged software.
With custom software, the program meets all the requirements of the business and doesn't include any modules you don't want. It usually costs more initially, but because you buy only what you need, nothing more, you won't need to perpetually customize.
Get deep integration with your existing systems
With packaged software, integration with your other systems ranges from simple to a painful implementation project. For example, if you purchase CRM software and want to load all your existing customers into it, the tool should provide this. Most consultants can do this work quickly. Painful integrations are when you can't get the data out, or you can get it out, but you have to use the vendor's very strange API to pull just one record at a time.
If the new system is one piece of a larger process, or if it will be the system of record for your enterprise data, you will have many integration points for data coming into and out of the new system.
With custom software applications, those integration points are built in because they are part of the original requirements. The software integrates deeply with your current enterprise systems. If done right, the new integration APIs are written in standard ways that are discoverable by any new applications that may come online in the future.
How stable is that vendor? What is your exit plan?
The main value proposition of packaged software is the functionality you get for the price you pay. But that value can go out the window if the vendor goes out of business or is purchased and no longer supports your software. And what happens if you get their software deeply embedded in your business and the vendor goes up on price next time you're negotiating their contract. Vendor lock-in is a real business risk.
In a struggling economy, it's not unusual to see smaller software vendors bought out by larger ones. It's also common to see start-up SaaS companies offering low introductory prices to get customers on board, then gouging them once the cost of leaving that vendor gets high enough. When purchasing software, consider the long term costs and how you would get your data out.
And don't just make a plan. You need to test that your plan really works and you can get the data out when you need it and in a format that is useful to you. This is like a building evacuation plan. Usually no one reads the plan until the emergency happens, and then it's too late. You have to actually test pulling your data out in a non-emergency situation to see if the plan will really work.
With custom software, your business owns all the code and all the data from the start. Most systems are turned over to IT departments after the construction phase, so there is no risk of your data being held hostage.
Although unlikely, it's certainly possible to have your custom software development vendor go out of business or be purchased by a competitor during the development phase. However, if the system is written using your IT department's standards and your application development vendor is releasing working versions of code every few weeks, you minimize vendor lock-in or vendor going-out-of-business risk.
Where is the data stored?
With packaged software, the data is often stored in a proprietary database. Even if it's in a more common database format, many vendors will not support direct queries or reports against the data store.
If you're using SaaS and the data is in the cloud, you can't be sure where it is. That works great for some organizations that really want the redundancy and availability, but for sensitive data or for businesses that are heavily regulated, data security will be a deciding factor in your purchase.
Custom software puts the data where the organization wants it because access to and location of the data are part of the requirements. It's as secure, redundant, and available to queries and reports as the requirements dictate.
Get user buy in
The typical IT buying process is to identify the requirements and find the packaged software that best fits. This evaluation is often handed over to a technical person to be sure the software is a fit for the organization from an IT perspective.
The problem comes when a package is selected and the users are told that starting next Monday, they will be in training, and starting the Monday after that, they will be using the new system. If the users haven't helped choose the software, they may reject it or sabotage the implementation.
With custom software and custom integration projects, users are involved in the requirements early on, and the new system should be tailored to their specifications. They are the most critical stake holders and can set the tone for a successful adoption throughout your organization.
Software purchase decisions can be as complex as the problems they attempt to solve. Decision makers need to consider short and long term costs and risks of buying packaged or SaaS software as is, buying it and customizing it to integrate into the business, or going with custom application software the whole way. The easy answer is not always the best answer when all the risks are considered.