
Maybe so ...
That may be the case, and if so, it is a good result for all.
5 publicly visible posts • joined 18 Mar 2010
I was behind one of the bids that was not selected and my company is an OSS specialist SME.
However, it does not matter simply if the solution is OSS or not, it matters if the solution will be a good fit, meet the requirements and be delivered within the expected budget and time. And most importantly that the business need is properly understood in the first instance. Within a few months, we should all be able to look back at the solution and judge for ourselves if our money was well spent.
For this and most other ongoing projects, it is the exit cost that can be the hardest to quantify and can restrict the option of exit in many cases meaning that other costs can be introduced later. The Government are aware of this but have not woven it in to the procurement process. As an assessment criteria, it could alter the scoring and provide a better understanding of the overall costs.
Amongst other benefits, OSS does reduce the exit risks and can open up the solution to competition instead of a single supply situation for the life of the contract. As buyers learn this, the use of OSS will increase.
What was a large IT project 10 or 20 years ago may now be a free piece of Open Source software which can be set up by an SME so the large costs and consultancy element of yesteryear is not always needed. The government has realised this and is trying to take advantage of it by investigating SME and Open Source solutions. However, the existing incumbent suppliers are resistant due to the appeal of keeping these projects on a large scale and the associated scale of fees.
It is possible that this reform could open the doors to SME's but the SME's need to be organised and present a good case to the government. Sadly, this all takes time and money which many SME's do not have just now.
In my experience, the primary cause for system implementation failure is lack of understanding (and investment) relating to the problem that needs to be solved.
Companies like to think they are buying a solution to their problem and ERP sales people are keen to take the money. The "problem" may not be lack of an ERP system but lack of process.
This is a classic example of automating something that is not understood. In any company, the process should be well understood and tested before it is automated with an ERP system.
My company ensure that a customer commits to up-front consultancy to enable all parties to be clear about the project and systems. We loose opportunities this way but at least we do not end up with unsuccessful projects. It is a hard sell to many customers as they do not expect to pay for what they may consider as pre-sales. We also have learned to be very tough on customers who will try to persuade us that they know their own systems, if they cannot write it down, they are not ready for an ERP system.
Regarding the point about never ending projects, a good relationship between supplier and customer should go on in to perpetuity. This is not failing to finish but working on refinements and updates. The fundamental rule is that if the requirement does not change, the system should not have to. In practice, most businesses will change and adapt elements of their processes in line with new suppliers, new products or projects, even legislation and regulatory changes.