How should we assess "Build vs. Buy" for an ERP System?

Question

Background

We are about to make a huge decision and change of ERP. The current solution is outdated and failing on us. The burning question is: Do we buy a solution like SAP, PeopleSoft, Oracle or do we extend our already existing sales software with ERP functionallity ?

As I just said, we already have a custom software solution which is being used in almost the whole company. We also have 3 developers working on this. We are only interested in the financial/accounting part of an ERP system, so I am not talking about a complete ERP.

The other option is to buy an ERP system and come up with some kind of interface between our sales software and the ERP system. According to SAP this is possible.

I came up with some pros and cons:

Custom Solution:

• 100% fits business needs
• Cheap customization
• 1 solution for the entire company
• Flexibility in future changes
• Low initial investment
• We can make it so that the people using it don't have to change the way they are used to work.

Vendor Solution:

• Faster implementation
• Less risk

Build vs. Buy Analysis

I already have some pros and cons listed, but don't have a formal risk assessment. What is a workable process for comparing a build vs. buy decision for this type of project?

Answer 1

Developing a Pro v. Con list is a start; however, for a decision of this magnitude, you need a bit more rigor. In other words, your analysis needs to be along the lines of benefit v. cost v. risk and you need to quantify these three categories to the degree possible. You can decompose each as you desire and score at the lower levels and you can apply weights if you desire.

Here are the steps I would use:

Generate the criteria under each category of benefit, cost, and risk; Conduct workshops with the appropriate technical and business SMEs; Iterate scores; Conduct workshops to validate which came out the highest.

It is an iterative process and the scoring is more subjective than we would like; however, you have to start somewhere and if you use enough SMEs in the scoring, the extremes will level out. Watch out for bias and hidden agendas and control for those things as best you can.

Answer 2

Chancho, welcome to PMSE! Recommend you look at the Guide to the Project Management Body of Knowledge, 5th Edition, section 12 which is entitled "Project Procurement Management" and specifically section 12.1.2.1 entitled "Make-or-buy analysis."

Answer 3

You have multiple solutions to consider, not just Build vs Buy.

Regarding Buy you will need to consider a number of different purchasing choices;

1. Gap Analysis of your proceses and business goals against on a number of ERP products (they are all different, with natural fit to different verticals)
2. Delivery models (iterative or big-bang)
3. Combinations of smaller best-of-breed products rather than just a single ERP
4. Hidden costs such as cost of implementation, customisation, change management and ongoing maintenance and support contracts

Regarding Build you will need to consider a number of different solution choices;

1. Platform/Technology/UX choices (cloud vs local vs thick-client vs web vs mobile or a combination)
2. Release Plan (short iterative vs. big-bang), and the different speed of ROI that provides

The good/bad news is you shouldn't even start this investigation until you have listed and analysed all your processes, to a sufficient extent that you can do 1) detailed Gap Analysis against at least 2 two ERP products and also Gap Analysis against an integration-based solution ("A Combination of smaller best-of-breed products") (which is often better than an ERP, with faster ROI and better fit-to-need)

You will end up with a gap analysis summary of Product or Dev choices mapped against processes (picture a great big spreadsheet). You will then need to assess the size and cost of closing the gaps, which usually requires Vendors and Development companies to engage closely with you. If any solution is less than 70% fit out-of-the-box then it probably should be discarded immediately.

Bottom line, I believe no ERP solution will fit your needs out of the box. I have been doing this for 25 years and this is ALWAYS the case.

So... Gap Analysis is the key, and expect a lot of options to choose between.

Good Luck!

Answer 4

I recently walked my team through a similar question. Here's a hybrid approach I used that considers typical build or buy logic and cases with a team-based problem solving method: .

Of course the usual cost/ROI and speed/accuracy questions are important. But you may want to do a bit more pro-active risk planning. For this I employ what HBR likes to call the "pre-mortem".

Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight—imagining that an event has already occurred—increases the ability to correctly identify reasons for future outcomes by 30%.

Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t. Indeed, the premortem doesn’t just help teams to identify potential problems early on. It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project. Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them. The exercise also sensitizes the team to pick up early signs of trouble once the project gets under way. In the end, a premortem may be the best way to circumvent any need for a painful postmortem.

You can read more on it here: http://hbr.org/2007/09/performing-a-project-premortem

Answer 5

It depends on the budget you want to allow, the scope you want to cover and the number of user. If you want only to cover finance/accounting it will be difficult to have the quality of existing software. It may be also difficult to be in line with accounting rules from your country. If you choose an existing software, you can still develop the interface with your sales tool.

Pros for vendor solution:

• Tax and accounting rules covered
• Support and continuity of the solution
• Opportunity to review your process and improve

I don't see a good reason to develop a software from scratch for a process that is repeated in most of companies.

Answer 6

If you're only interested in the financial/accounting part of the system, I'd certainly look at a program that does just that and nothing else, like Exact Online. ERP systems are specifically developed for a production environment, and from what I've seen, the more options a program has, the more complex it is and the harder it is to implement, even if you don't use other modules of the system.

Almost all self-respecting ERP (and other business administration) systems have possibilities to link with other programs. This is almost always the result of collaboration between the companies: inquire with your present software company which systems are compatible, and used by their other users. This also illustrates a disadvantage with building your own system: you'll have to work around certain parts of the existing software if you want your new system to work together with your existing package. (I've worked around it earlier with f.e. data dumps but I wouldn't recommend it to anyone!)

I'd only recommend an entire ERP system if you are planning on implementing throughout an entire (production) company. I'd look for a tailor made system if you need something very simple, otherwise the benefits of having support from the software company could outweigh the disadvantages.