Customize, Configure or Out of the box. What’s the impact for solution delivery?
Our challenge, as the transformation partner, is to help strike the right balance between supporting business needs, cost, timelines and maintainability. This is never an easy task given the number of options available.
Billing systems have evolved into very complex system offering support for many business models and providing myriad ways of achieving their core function of producing invoices. We have moved from billing simple, single services to convergence with quad play (and beyond) offerings across multiple industries.
The options become even more complicated when you consider the ability of application frameworks (such as AIA ) to allow the transformation of almost any interaction between applications without making changes to the base product
.
In my opinion, configuration forms part of any out of the box implementation, whereas customization involves major changes to underlying code or the development of new modules, neither of which will be supported by the vendor. I view the use of “out of the box” options as paramount for architectural imperatives such as account and product structure.
I’m happy to consider customization where the solution offers business benefits that can be clearly identified. There are the obvious caveats about managing future support and appropriate testing,
however I feel these can be managed without undue risk and cost.
Overall my view is that businesses need to focus on their signature processes and products and look to leverage their billing package’s functions to achieve this. Market advantage is not achieved by having a “me too” implementation of software.
I would be interested to hear other people’s perspectives and experiences.
Comments
Ian,
A very thought provoking post!
Across all the package implementations that I have seen (CRM/ERP etc), challenge is always to strike the right balance between benefits of customization to business vs the ROI on delta investments.
Again, these packages come with lot of "out of the box" best practices in business processes and what intrigues me is the extent of over customization that each client still goes through to achieve the right fit.
Every company feels that its business processes are the most complex and unique (having evolved from years of siloed implementations) and resistance to change is natural.
I would have to disagree with one of your points where you have mentioned that customizations are not supported by vendors. In my opinion, heavy customizations have a cost associated down the line, but they are pretty much supported by vendors, its extra revenue for them in form of expert services/professional services etc.
The irony is that when the vendor evaluations are done by companies, business process mapping is one of the points that is always considered. But moment that project hits the ground, the "actual users" are never happy with the OOB processes and that starts the journey of tweaks and pain!
There is no holy grail for the right mix. The SI partner would have to bring strong business focus, product knowledge, governance and buy in from right stake holders to keep this process in control.
Cheers,
Nitin
Posted by: Nitin Gupta | October 13, 2009 3:30 PM
Ian,
I agree with you. Though COTS packages support most of the standardized business processes, however, customizations may still be required to support other business processes specific to the customer. These scenarios mostly arise in situations where a customer migrates from a homegrown billing solution to using a COTS package. More often than not, these customizations tend to be very expensive and increase the operational and maintenance costs. It all boils down to the business justification for implementing these requirements. Customer needs to compare the business benefits vis-à-vis the development and support costs for implementing these. In my experience on a few billing implementations, most of these requirements/functionalities are good-to-have requirements, simply because these have been supported earlier, not because these provide a great deal of business benefit. These might have been easier and cheaper to implement earlier on the homegrown billing solution but may not be on the COTS billing package. I think it is important for the customers to understand that the implementation of a new COTS billing package is not a one way process. The customer also needs to re-look at each of their Business processes to remove the ones which are not relevant any more, or, implement them in a different (or better) way which the package might be able to support OOB.
Posted by: Kanwar Virender Singh Narania | January 6, 2010 8:50 AM