Removing Artifacts

Over time as you go about using and configuring your CRM solution it is likely that you will replace an older design with a newer design to facilitate some business process. This may come about for a variety of reasons:

·        New features in a newer version CRM that allow you to go about solving the problem in a more efficient, direct way

·        Budget constraints that restricted the original design – perhaps there is now budget to purchase a 3rd party solution to replace an interim solution that was put in place

·        Lessons learned – both in terms of technology, experience gained from other implementations, or feedback from end users who decide that the solution needs tweaking

Whatever the reason, it's important to keep the solution clean. By this I mean removing the "artifacts" that may build up as part of this natural evolution of configuring CRM within an organization. Leaving in attributes that are no longer in use is not good practice for a number of reasons, some of which are:

·        Over time it can lead to confusion when trying to understand how a particular part of the application works. Keeping the system nice and clean is good in and of itself but also saves time in the long run by not having to spend time trying to separate between the wheat and the chaff

·        Although you may have cutover to the newer functionality it's possible that there are old reports or the like that still reference the old artifacts. If you remove these attributes the reports will fail the next time they run, however it is better to have a report fail noisily (of course expectations should be set) so it can be addressed, than continue to function and return wrong and/or misleading information

·        Performance – This one is fairly obvious. To keep the system running at optimum levels it is always advisable to keep them as lean and mean as possible.

       

Of course, removing artifacts doesn't have to be performed as part of the cutover to the new functionality. In many circumstances it may be prudent to wait a day or two, or even a week or two after a cutover event. For example, it may be possible that data was converted as part of the cutover event, but perhaps certain data got missed or skipped over (of course, this never happens when working with Sentri!) – having the artifact data available can allow you to correct the data quickly. Alternatively, it might be possible that for whatever reason you need to rollback to the previous functionality and of course having the old attributes along with the accompanying old data makes this that much easier to do. In short, it is recommended to create a follow up task pending a cutover event to remove artifacts from the system at a not too distant time in the future.