Minimize your Customization & Accelerate your Realization - Part I
Part I of this 3 part series discusses about why Customer opt for customization in even in a matured package applications and how it can impact your cost of ownership.
When package applications were introduced, they brought about a revolution in the way Information Technology was consumed. Packaged applications redefined how applications were implemented by offering Industry best practices and hence focusing on process rather than on technology. These solutions had reduced the cycle time for implementation and hence the cost associated with it. The risk of going wrong with a packaged solution was very low when compared to the then prevalent custom-built-from-scratch applications. Theoretically, a package could be used by just configuring it.
As we see now, many customers are going for extensive customization during package implementations and hence enormous development requirements. The defined processes in the package do not seem to meet the requirements and there are gaps that have to be addressed. Users imposed a lot of legacy burden and the management backing wasn't enough to strictly adopt out-of-box processes.
Key reasons for extensive customization are:
- Mandatory requirements due to regulatory or compliance reasons, where not supported by the package
- Not able to adopting the best practices as provided by the package vendor
- Must have processes specific to the customer/industry/geography
Product companies have been playing i-will-catch-you with its customers by bringing out more and more functionality in the standard package but are continue to have significant gaps. Few packaged vendors went ahead and published best practices localized for a industry and region in an effort to bridge the gap and minimize custom development. This has met with limited success.
Custom development to address the gaps is the most prevalent practice in package implementations. Often gaps continue to evolve over a long period of time and developments fail to address the gaps fully. All this again leads to a longer realization phase, higher implementation costs and a risk of the unknown: will this development actually address the gap? Sometimes testing and documentation effort is compromised on developments to meet the go-live timelines. We also need to understand the fact that a development requiring x amount of effort to create one, will take 25x time to maintain during its lifecycle before embarking on customization.
So what is the solution to this? How can a customer adopt a package that requires least amount of customization in terms of development and accelerate realization?
Let us try to discuss the above in the next part of this series.
