Develop in house or configure off the shelf?

[original PM]

Then you have very poor management of contractors.

every company ( contractor) is out there to make money - no problems with that

however human beings are not pieces of software and for them to work effectively requires more than just a desire to earn money

I manage anyone who works with me very well - however people who only think of the bottom line and nothing else are too narrow minded to be of use to anyone....

[cojak]

Over to you doomage...

[eek]

Some good points, thanks.

The requirement exists because the ERP system cannot easily handle the complexity of the manufacturing process. The process is such that there are far too many variables (environmental, physical resource availability, product destination, plant connectivity) that the ERP system (glares at OS to keep quiet) cannot handle the detailed scheduling of the factory. But this isn't really my point.

I'm interested really in the support aspects of the two potential options. Eg Vendor OTS means access to cheaper 24/7 support, upgrade plan, certified api's for the ERP, OS patches approved etc With in house you get flexibility to do exactly what you want without compromise but are more limited in longer term support options?

Looking at the quotes I saw for some recent oracle ERP upgrades don't bet on OTS being cheaper. It is up to the point you start looking at the cost of keeping your customisations working after the upgrade.

OTS is fine if you don't plan to do many customisations or can change your process to match the expected process. Otherwise both are custom developments however the OTC system will have a core people outside your company can understand and support.

[Scoobos]

I'm interested really in the support aspects of the two potential options. Eg Vendor OTS means access to cheaper 24/7 support, upgrade plan, certified api's for the ERP, OS patches approved etc With in house you get flexibility to do exactly what you want without compromise but are more limited in longer term support options?

I'd be careful about that assumption and what Cojak says, despite how "managery" it sounds is spot on.

[oscarose]

Apologies for being so generic but it's more of a things to consider type question. Assume that the existing source code has been modified so many times that it is of little value and it would be a start from scratch, define new requirements type project. Assume the vendor based solution will give +90% as vanilla but would need to be enhanced for the additional 10%. Hardware reqmt's would be equivalents.

I'm interested in peoples experiences of support costs of in house vs store bought, flexibility to business change. etc.

If COTS gives 90%, it seems clear cut to me that it's the way forward, however that's based on limited information. Consider the man years development it would have taken to get that 90% out of the box functionality. I would then tackle the remaining 10% using the MoSCoW approach.

[oscarose]

I don't know why I'm posting this in the bearpit but here we go...

A (purely hypothetical) client has a locally developed app that sits between its ERP system and its process control systems. It's a manufacturing site that produces different varieties of similar products, although the manufacturing process can be quite complex.

The application was developed approx 20 years ago and was at the time ideal for their requirements but as the business has developed over the last two decades and the systems the app interfaces to have changed, it's now no longer as flexible as it once was.

So today's discussion is - What are the pros and cons of developing a replacement in house vs buying an off the shelf vendor solution and configuring to meet requirements.

On a contract with a manufacturing client last year they had a similar problem and bit the bullet and went for a ERP COTS solution. Approx 1 year to implement, 6 months to bed in. Good support from Vendor. Approx cost = £1M.

HTH

[doomage]

every company ( contractor) is out there to make money - no problems with that

however human beings are not pieces of software and for them to work effectively requires more than just a desire to earn money

I manage anyone who works with me very well - however people who only think of the bottom line and nothing else are too narrow minded to be of use to anyone....

Maybe you are too narrow minded to see the obvious solution is the simplest one. Choose the most expensive option, it creates lock in, that sorts your support problem.

[cojak]

I'd be careful about that assumption and what Cojak says, despite how "managery" it sounds is spot on.

Hey, people can take or leave it - I'm not invoicding for it...

(PS - re. 'managery' Small words and bullet points, that's the trick - )

[Gentile]

FWIW, my tuppence worth on the COTS vs bespoke debate is that if you know what you want in sufficient detail, you'll be in a position yourself to easily know whether there's a COTS solution that matches your needs or whether you'll need to get someone to build your dream home for you. If you don't know what you want in sufficient detail to be able to make that decision easily, then get a COTS package that most closely matches your needs, because then at least you'll have piece of software that has been built to some coherent vision, even if as Cojak observed such solutions are usually only an 80% match for your real needs at best and will provide far more features that you probably don't need or want (but will have to work with).

If you start building a bespoke solution with only a vague idea of what you want, don't be surprised if what you end up with is only a vague reflection of your actual needs. If you don't know where you want to go, then any road will take you there.

[Durbs]

So today's discussion is - What are the pros and cons of developing a replacement in house vs buying an off the shelf vendor solution and configuring to meet requirements.

I'd always go bespoke.

Recently worked on a contract integrating an off-the-shelf that provided 75% of what we needed with a vendor who initially seemed very accomodating in developing mods to fill in the gaps - it turned out a nightmare.

The vendor was so slow at providing the promised updates and each change appeared to be completely untested with endless problems meaning we had to chuck a load of test resource into the mix. Several 'critical' changes originally agreed with the vendor were eventually refused as 'it would require too many changes to the core product and we would be unable to support it'.

So it was basically no fun having to tell the business why changes they had marked as 'must-have' were simply not going to happen. The frustrating thing is that these were not complex changes and had we had access to the code, we could have implemented them pretty easily.

So depends on how open to a change in their process the business is, in our case - not very, so that meant that implementing COTS was like pulling teeth.