Management of In-House Developments
It's time for spring-cleaning, especially as far as release upgrades are concerned. Integrating in-house developments that are no longer used into a new release is a considerable cost factor.
But expenditure on in-house developments is not to be underestimated in day-to-day operations, either. After all, these are not just reports but often also transactional extensions which must be dealt with and tested repeatedly within the framework of smaller process customizing.
Here's the VMS approach:
By measuring the systems, VMS firstly determines which in-house developments are used at all, by whom and how frequently. On the basis of this hard data, it can make the right decisions on which components need to be integrated at all. The automated pathway to cleaning systems before the release-change considerably minimizes the expense?/effort? of adapting and testing it.
It is important that the VMS measurement covers not only simple items such as unused programs; it also looks at other components such as includes, screens, CUA components etc.
What's particularly important is that implicit use of such components is also examined, as too many deletions also cause annoyance. This formation of cross references is a/n expensive/complex? process that has been developed by VMS itself.
