Question:
Guys,
Now its my turn to get some info from you...
I am trying to put together a list of high-level project considerations for implementing any PM/CS project.
These consideration may affect the project timing, cost, resourcing etc.
I have started this process (see below) but would appreciate your feeback.
REMEMBER - HIGH LEVEL CONSIDERATIONS
-------------------------------------------------------------------------
Right people for the job:
A combination of engineering, management and workforce personnel will result in a more robust solution. For CS this may include the service department and maybe even customers. Also the number of project personnel is important. A single client representative is not advisable – if they leave what happens!!!
Data conversion:
Data conversion is a crucial element of any project. However, experience shows that this is usually left too late in the project cycle.
The number of legacy-systems and data extraction also impacts on project duration.
Asset registers:
Many projects do not have an adequate asset register. This data needs to be collected before the SAP data loads and testing can occur.
It is also common that the client does have a list of assets, however, the master records do not have all the data required. This data can be collected prior/during the project, alternatively it can be collected as part of the ongoing maintenance and entered into SAP at a later date.
Historical data:
The client may want to include historical data from legacy systems as part of the data conversion.
Equipment Quantity:
The number of equipment can have a direct impact on project duration.
Bills of Materials (BOM):
The data collection/conversion of BOM can be quite considerable. Due to time/budget constraints this is often left until after the initial PM rollout.
Maintenance implementation strategy:
Is the PM/CS project a direct replacement of a legacy system/s, or does the client want to rationalise/re-engineer maintenance as part of the project.
Number of locations:
The number of roll-out locations
Global/local project:
Global projects tend to take longer especially if a standardised maintenance system is to be adopted across all locations
Project group and end-user training:
Can prolong the implementation if the project group have no formal SAP training. This is also true if end-user training is the responsibility of the project group.
Reporting:
PM/CS reporting is often left too late or ignored completely. You WILL need some bespoke ABAP reports.
Think about workshop, supervisor and management reporting. Also about data inconsistency reports e.g. equipment without costs centre assignment.
Reporting can be from R/3 and/or Business Warehouse (BW).
Other SAP Modules:
Project scheduling can be affected by other modules, especially FI/CO, MM, SD etc. These modules may or may not be implemented before work on the PM module commences
Existing Client experience:
The client may already be familiar with SAP (and indeed PM/CS)
Developments:
Most PM/CS implementations involve some form of development in the form of ABAP reports, batch programs and user-exits. However, more major developments such as front-end programs and workflow can involve considerable man-hour levels.
If possible, do NOT modify the SAP standard system.
Skills transfer:
Ensure someone at the client is learning from you especially in the following areas: IMG, document processing, problem resolution etc
_________________
Sponsored partner: www.arch.co.uk
PM/CS FAQ
Search SAPFans
Answer:
PJA
3 considerations that you might want to include are:
1. Training Requirements and how, CD rom , train the trainer etc, translations if global. There is no point having a highly skilled support team if the end user cannot use the system
2. Organisation and Roles, often left late in a project.
3. Data Cleansing - cannot start early enough
Answer:
PJA,
I think that one of the primary considerations must be the ramp up in usage post go-live. It is vital that the expectations are realistic and are agreed. Too many people are lead to believe that on day-one they will enter a maintenance utopia - obviously not true.
Reports: Ensure that there is a sound process for establishing reporting requirements. This can burn up a lot of time during the implementation. Consider a strategy where the reports are specified post go-live, when the users have a feel for the systems capabilities and the information that is important to them.
_________________
Answer:
LMW, ATC
Thanks for the input, I will add them to the list
Any more guys???
_________________
Sponsored partner: www.arch.co.uk
PM/CS FAQ
Search SAPFans
Answer:
Hi PJA,
You need yo identify and vet any grey systems in the organisation
Small systems that exist in the organisation that were probably put in as stop gap measures but have over time become process critical.
Typically these have a lot of data in them that are not in any corporate system (measurements, task list, BOM data etc.) and they have their own reporting which may be specific to the architecture (eg some MS Access system).
I have seen these systems have a fundamental impact on system/proces design and reporting requirement. And you're right most of them popped up as surprises well into the design or realisation phases.
_________________
Damo
The Dark Lord of Data Conversion
Answer:
hello PJA,
- The maturity of the maintenance department, in which works planning and preparation is an important part. In my experience, I still find companies that work basely in a firefighting context : urgent repair when something breaks down ; only a small fraction is planned maintenance
- a tradition for preventive maintenance.
If these 2 points are absent, then a serious effort must foreseen for change management within the maintenance department.
regards. Didier