Purchasing off-the-shelf software and customising it can be significantly cheaper than building an entire solution from the ground up. In particular it is easy to get some quick runs on the board because you often have the scaffolding in place which defines how your overall solution will work. Platforms such as SharePoint and Dynamics fit into this category within the Microsoft space, but also other tools such as SAP are also targets for customisation.
In general I am a fan of customisation with a little bit of development around the fringes to get the job done, but a recent experience reminded me of a critical lesson that you need to learn when doing so. Don’t wire the ejector seat to the handbrake!
The big trap with system customisation is not knowing exactly how the target of the customisation is truly designed to work. If you don’t have this overall understanding your customisations might break standard usages of the system. This may not be important to you at the time of implementation and you may not even pick it up, but it breaks things like standard reports and upgrade paths.
Student/School Management Example
One example might be building a Student Management System out of Microsoft CRM. You might decide it makes sense to re-use the Contact entity to represent a student in your first pass of the solution and go ahead and re-name that entity. However – down the track when you start to integrate representations of teachers within that system you are going to hit problems. It would have been a better design to create a Student entity and a Teacher entity, but point them both to Contact entities, so the new entities really just become a definition of the role rather than the person.
Service Activity Example
Another example might be using the CRM Service Activity entity as a way to represent a timesheet in a professional services organisation. In a world where you create one service activity per day per consultant that makes sense. However, what you may not have realised is that a single service activity can actually have multiple resources serviced against it, and so the concept of the Service Activity being the container for time recording doesn’t make sense. You would actually be better off introducing a new Timesheet entity which relates the Service Activity, and the consultant/resource.
I’m reading this too late!
If you are reading this too late, don’t despair. There are really two strategies for dealing with this situation:
- Start from scratch and salvage what data/relationships you can.
- Peel back the customisations one at a time whilst maintaining system function.
We are currently working on strategy #2 because the value in our data is too high and the level of customisation is relatively small (just painful in a few key areas). Perhaps the big push for the work is that we are expanding usage into other areas of the product that we didn’t need before but now that we are we are hitting up against some of the consequences of our decisions.