Configuration and Customisation |
||||
|
Identify the changes that need to be made to customise the software. | |||||||||
|
|||||||||
|
|||||||||
|
|||||||||
The goal of this step is to scope the work that needs to be undertaken in terms of customisation. This excludes the work that might need to be done to configure the system. To differentiate:
At this stage, there are probably many ideas for customisation that could easily double the time to implement. The exercise is to decide which are really important and which are "nice to have". There are also likely to be decisions around: "Do we change the business process to suit the system or the system to suit the business process" There is no blanket answer to these questions unless it has been decided that unless the system will not function, the change is deferred. This can be a valid approach where:
A key point to remember is that every change will need to be reinstalled in future releases. A customisation will need to be retrofitted to any new release. This adds additional cost and time to upgrades. To evaluate each change you may need to do some analysis as to what the requirement is, and how it might be implemented. This will typically involve the Vendor or Implementation Partner. They will have experience on the likely effort to implement changes and can provide an estimate of time and cost. The final calculation should also include the time involved for testing and delivery of additional training. There should be constant interaction between the team working on Customisation and the team working on Business Processes. If the decision is to change process rather than customise, the Business Process team need to know in order to develop new processes. |
|||||||||
|
|||||||||
|
|||||||||