Consider this, you have an Enterprise Software Solution running and have found that every new hire in the sales department makes the same mistake on one of your key on-boarding processes.
Perhaps in recent years, it wasn’t as noticeable but you are currently going through a rapid expansion and the problem has become more acute. After some investigation you find that a particular input form which allows the sales person to proceed without entering a customer’s email address is the culprit. The flow on effect of this omission is that the automatic marketing your organisation relies on is now not able to notify the customer of your sales promotions.
while you wait your business continues to haemorrhage money”
Your software vendor, while happy to help, comes back with a quote for $10,000 and informs you that they will not be able to implement the change for three months. An expensive fix, for a small change that is nevertheless critical to your business. But since it’s critical you agree, and while you wait your business continues to haemorrhage money.
Sound familiar? You can at least console yourself that it’s a one off …
Well, that is until a year later when new tax legislation requires more “minor” changes. Suddenly you are up for another $10,000 and the cycle starts again.
Figure 1: The original form with email optional and at the bottom
Figure 2: The improved form guaranteeing emails are entered
So what happened? What went wrong and can it be avoided or alleviated in some way?
It might be a hypothetical, but this situation, or something similar, is more typical than not. Firstly, why did the software vendor quote $10,000 when you wanted the email address field change done? It might seem like a lot for such a small change, however if we look more closely the software vendor may indeed have needed to quote for numerous days’ worth of work by their development team. In this instance, the team that built the original system three years ago has now been disbanded and even had key staff move on. As a result they may need to factor in bringing a developer up to speed for your solution, or at least to become familiar with the old version you happen to be running on. So while the change itself may only take a couple of hours, even including environment set up, code changes and unit testing by the developer, this is not the only consideration. Even after that, there is still a need to factor in a tester coming up to speed on your solution and to retest the entire on-boarding process. While the change may itself appear superficial it is still important to test the process itself from end to end. Finally, yet more time is then required to release and deploy the updated solution.
As for that delay, the vendor may simply have had scheduling issues for key staff as they were otherwise already engaged on a critical project deliverable for another customer.
the team that built the original system three years ago has now been disbanded and even had key staff move on
The point here is to highlight how even small changes can lead to potentially large costs and long implementation time when having to make a direct change to an existing Enterprise Software Solution. Particularly when outside the main development schedule. Costs would likely be much less if it could simply be included as a feature in the next release for example, however that would likely have resulted in an even longer delay in deployment of the feature.
Is there a better way?
One way to have more rapid control over your Enterprise Software Solution is to develop it in house with your own software development team. However, while this might be a viable solution for larger companies and even cost effective for them, building and maintaining such a team can be inefficient, cost prohibitive, and difficult when software development is not part of your core business focus.
Another approach is to have your Enterprise Software Solution built in such a way that in-house staff can make some changes such as the field positioning on forms and some business process logic via meta tools such as builders and wizards. In effect allowing them to customise the solution without changing the software code itself. By doing so and avoiding the need to engage the vendor, important business process change can be more rapidly implemented. This is the direction that we at Xelleron have decided to pursue and seems the most promising to us.
