|
HomePe |
Contact Us | Contribute | Forums
| TechWiki
- 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 SME’s assigned to the project should be fulltime and not parttime.
Before the actual implementation management 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 or
other systems through the a 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.
|