Systems can be designed in many number of ways depending on the priority and importance we give to the various aspects of solutioning. In most cases the raw business requirements drives the solution approach. ‘The customer is always right’ philosophy is often religiously followed resulting in an over customised solution. This often results in a complicated solution which is difficult to maintain.
It is suggested that a layer of Business Consulting is involved between the Business and Technology Consulting team. The Business Consulting team needs to understand and validate the business requirements. On analysis it could be found out whether the requirements can be implemented though simple and standard solutions. There could be requirements for which the solutioning could only be achieved through complicated and highly customised design. In such cases, it needs to be ascertained that such complex requirements when implemented provide high value to Business. The complexities needs to be weighed against the business values and the finding are to be highlighted to the Business leadership team. The Business team can then decide whether it needs such a complex customised design or some other alternative solution which is simpler and standard with a slight compromise on the original business requirement. It is recommended that the Business Leadership team chooses the complex and customised design only when there is a high value proposition associated with it. This would go a long way in helping creating a system which is lot simple to build and maintain.
Should the complex and customised designs be chosen and implemented due to their value proposition, then adequate validations are considered. High importance needs to be given to the validations as otherwise any missing validations would result in data corruption. Before the issue is found out sufficient damage would have been done. Corrupt data is not good for the system as it would diminish the confidence in the System in the eyes of the Business. The data fix work which would follow will involve additional resource and time in addition to the business impacts. Many a time it is better that the solution does not work instead of the solution working partially. The front loaded validations are better than the intermittent validations which results in partially processed data which are difficult to resolve.
The value of project and system documentation increases with time. However, unfortunately in many cases decreasing importance is given to the system documentation with incremental changes that occur in the system with time. This results in the system and its documentation going out of sync with time. This could be reduced to a great extend be reduced with insistence that changes and fixes will go through only when the corresponding documentation is updated. This would to a great extend reduce the risk of dependence on a select few people who only know the system. This would also enable smooth transition between the project teams and subsequent maintenance teams.
The above points have been brought out of experience in working with SAP IS Utilities projects in new developments and maintenance activities. So they have more relevance in SAP IS Utilities projects which are highly data intensive.
