TechHairBall.com Tech All…

Based on my experience 

• The theoretical phase of information gathering should be kept as brief as possible. Try to go into early prototyping of business processes so that business users can see and come up with change request much earlier in the project than later on. The sooner changes can be handled the cheaper it is. The cost of handling change requests increases exponentially as we go closer to Go-live and any change request after Go-live it is definitely much costlier than before Go-live.
• Prototype should be created in a way that the production code or configuration is built on top of it and not separately. No work should be throw away work. Be it code, data, configuration or test plans.
• Data migration should be handled as early as possible. It is recommended that even during the prototyping stage, do not stub the test data, and use the actual migrated sample test data from existing systems. This way business user will be looking at the actual data during demo. The most prevalent risk to conducting an SAP test whether it is integration, functional, string, volume, smoke, or security test is obtaining valid SAP test data. Where will the test data come from? How will one produce new data for transactions that require unique data? How will the data be loaded into a new SAP client and instance? What happens when an interface or conversion needs to send data into core SAP R/3 from a legacy system and the interface or conversion is not executing properly or has yet to be developed? What happens when the transactional data has not been created? All these are very important aspects and should be handled at a much earlier stage.
• An effective archiving strategy for data should be developed as part of the implementation. I have seen cases where many Terrabytes of un-used data just stays in production later on.
• Extensive replenishment simulation should be tested for normal store replenishment, seasonal variations, special events like promotions, markdowns, clearances and any other major event.
• Integration testing should be done multiple times, after every major change across the modules.
• Business Readiness Testing should be performed at least 2-3 times with all the trained business users. This should be done with all the production loads running with volume of data as it will be running in the actual production environment.
• System should be performance tested with the real migrated data since volume of data impact’s performance drastically. If the migrated data is going to be huge, Data Partitioning is recommended for some major tables.
• It is recommended to use the latest stable release during final implementation, whatever is available.
• Proper communication strategy should be finalized during the project preparation phase with all the stakeholders involved. It is better to over communicate. There are instances when big changes are highlighted during the later stages of project just because some SME was not involved or communicated from the beginning.
• Change Management process should be formalized during the blueprinting stage including what, when, why, who, where and how of changes. All the stakeholders should be communicated.
• Change requests should be kept to minimum during the later stages of implementation stage.
• The resources (SME’s) assigned to the project should be fulltime and not parttime. Before the actual implementation must do some knowledge transfer from the SME’s to other persons so that business continues as normal during the SAP implementation other wise the SME’s cannot dedicate sufficient time to the implementation.
• Performance of the system should be tested for some big events for the company. From wine retailing perspective I believe the biggest event should be New Year and thanks giving or any other vacations. Forecasted load should be tested from the perspective of Master data updates – Article listings, Price changes (promotions, markdowns etc) and the volume of data flowing down to POS systems through the WebSphere message broker. Both the POS outbound and the POS inbound process should be tested for huge volumes of data.
• Change pointers creation should be kept to minimum. Create only those change pointers which are required, especially the Article and Pricing change pointers. During the special events the volume becomes really big and causes lot of system performance issues.
• Year end, Quarter end, Month end and any other special financial cycle or event should be tested for all the systems in an integrated way.
• The scalability of the system should be tested for a predetermined percentage growth.
• Knowledge transfer team should be identified much earlier, else consultants leave with all the knowledge and it becomes difficult for the client to handle the different business changes after Go-Live.
• Usually existing internal processes in a company are not integrated that causes lot of delay in decision making.
• NEVER allow testing of a new program in production server since the actual data is out in production only. Get the data to the QA environment.
• Integration approach to all the systems with which SAP has to integrated should be finalized during blueprinting. An approach should be taken so that integrating software and data can be re-used across systems, if possible. This will reduce the processing time and the creating of data in the SAP system.
• Decentralized testing should be done for only unit testing QA should be doing the actual standardized testing
• Peer reviews help refine work-products and deliverables. Peer reviews also provide independent verification and give the end customers or SMEs an opportunity to provide feedback during the early stages of the SAP implementation.
• The format/interface of the data to be exchanged between SAP and non-SAP systems should be finalized during blueprinting.
•  A very important aspect of SAP implementations is end user training. If they do not feed the right data to the SAP system then SAP alone will not be able to provide any good information. They need to be trained by a professional SAP trainer and NOT the functional guys. I know the SAP trainers are costly but ranging in hourly rate from 140-200/ per hour but do you really want not to hire them and risk your business.

Posted under World News