One of the questions that CIOs frequently face is termed "build or buy." Should we build this system or function ourselves, or should we just buy something even though it may not meet our needs exactly? For example, often the business side will argue for building something because the systems that can be bought don't quite align with how the business runs. Other times, the techies will want to build something and the reason comes down to having fun. So, what criteria should you use to decide whether to build or by your next system?
I think there's one simple measure that can be applied to answer the build vs. buy question: Does the system or function add competitive advantage? If so, then build it. If not, buy it. A few examples:
Company IT departments don't build general ledger packages anymore for a good reason: your accounting software won't add to your competitive advantage. We do, however, see organizations trying to significantly modify ERP systems to change how paydays are handled, etc. In Utah for example, we modified SAP's payroll system to handle a special way the Highway Patrol had of paying troopers because they couldn't be convinced to follow a standard business convention. The end result will be a system that's more prone to problems now and more expensive to upgrade later.
Of course, Utah isn't a business, but if it were, they'd be deriving no special competitive advantage from the way troopers receive their paycheck. These kinds of system should be bought and business processes should be changed to ensure that the system requires as few modifications as possible.
On the other end of the spectrum, I'd cite my experience at iMALL. We built a subscription-based eCommerce system. It wasn't one of a kind--at several points we could have bought something that did something similar. In the end, however, we believed we could build a better system and that was the basis of our competitive position. Worked too. We sold the company for $450 million (in 1999 dollars) based largely upon the business model and the technology. We eventually had over 50,000 merchants using the system and did partnerships with companies like First Data Corp. that we would have never been able to pull off without our own system.
The cloud in that silver lining is this: we built too much of the system. For example, we should have bought a transaction monitor (application servers were too new) early on instead of trying to handle them ourselves. We spent a lot of precious capital building components that we should have bought. The rule works here too: many of the components offered no special competitive advantage and we had no business building them.
