My blog has moved to http://blog.derekbobo.com

I moved my blog. Visit http://blog.derekbobo.com for the new one!

Packaged Software vs Custom Develop

Posted by derekbobo on January 23, 2009

In all of the organizations I’ve worked for or with I seem to always end up analyzing this long standing question. Should the client buy packaged software or build their own? Most people think that they need to buy the software. They say that they get higher quality and support. They also say things like they’re better off because they can easily find people who work in these environments.

I’m just not sure I agree. The are absolutely situations that it makes sense to use packaged software, but I think people need to realize that many of the reasons they say they are buying software are based on false assumptions. At the company I work for we are in a situation right now where we are having trouble getting our ERP software vendor to show up. The system needs a lot of love, and were almost 2 months past when the consultants were supposed to be on site. How’s that for support? Unfortunately since it is canned software the internal development team cannot touch it and we’re held ransom until they feel like showing up. I won’t even begin to try and figure out the cost associated with initial purchase, implementation, custom features, and ongoing support, but I’d wager it is significant to say the least.

The other thing I seem to see every single time is a piece of packaged software that has been bastardized beyond the point of return. When you buy one of these big software packages you buy a way of doing business. Unless you are willing to make that commitment and stick to the tools way of doing things; I must say you are in for heart ache. The “fixes” or “workarounds” that you come up with to make things work end up causing you a lot of pain downstream. Upgrades or migrations to new systems become next to impossible. Tasks that should otherwise be easy to implement seem to become more and more complicated and users (or customers) start to get frustrated. When this happens you quickly move towards a system that will have trouble scaling and adapting with your business.

The other thing I find amusing is that you pay hundreds of thousands (or millions) of dollars for these bloated systems. The thing is they are trying to be everything to everybody. As a result you pay for all of the available “features” but you only use a small portion of them. Aside from the fact that you’re wasting system resources, you’re also creating a larger environment than you really need. This makes it harder for you to track down issues that pop up. That doesn’t even begin to touch on the fact that you are working with a magic box. You throw some data into the black box and some data comes out the back. If what comes out isn’t what you expected you’re at the mercy of your vendor to help. That’s right they’re saying cha-ching cha-ching cha-ching as they stare at you with $$$ in their eyes.

My final rant is one of integration. Despite what the sales folks tell you, there is not a silver bullet/one tool that solves all your problems. You will undoubtedly try to bolt new systems onto whatever drives the core of your business. Once again the ability to pull this off creates a big dependency on the vendor (cha-ching, cha-ching….). You end up jumping through all sorts of hoops to pull off integration which exposes your system to more complexity and makes change very difficult.

On the custom development side of things folks become afraid. They don’t like the risk associated with putting a dependency on internal resources, they believe that the tool is harder to maintain, won’t support future enhancements, etc. These are absolutely things to be concerned with, but most of them also exist with packaged software.

Ultimately, I guess my thought is packaged software makes perfect sense for commonly used tools, such as email, word processing, file sharing, etc. Items which have become standard in most of today’s businesses. If you can commit to the software’s way of doing business, then go for it. You’ll probably have a quicker time to market, otherwise save yourself the headache because your setting yourself up for potential disaster.

If you see the light you simply need to manage custom builds appropriately. Have multiple people engaged in the development. For big projects this may mean multiple consulting firms, and/or the use of internal personnel. Then you just need to share knowledge and document. If you do this your software will be every bit as good as the packaged software you could by and most likely at a lower cost of ownership. You will have a leaner system that does business the way you want, and you will have direct access to modify it as you see fit. Because of these things I would argue that in many cases you’re going to have a more scalable and flexible system than you would with packaged software. If you do this you’re not committed to any particular vendor and you’ll be able to fit the tool to your business rather than your business to the tool.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: