Show TOC

Define Project Standards and Procedures

Task notes

Project planning
Project planning (that is, time scheduling) for each Customizing project is based on the R/3 Procedure Model.
Carry out preliminary planning by entering planned start dates and planned completion dates at the work package level. Adjust this preliminary planning before the beginning of each phase for the individual project activities in the work packages of this phase.
The project manager is responsible for the planning.
In special cases (for example, in the case of cross-component system settings), and in consultation with the project manager, more detailed planning is also recommended for each individual system activity in the Project IMG.
You can carry out more extensive planning activities (such as expense projection, capacity requirements planning) in MS-Project or in another project management tool. If this tool can read data in MPX format, it can share planning information with the R/3 System. To do this, you can generate a data file in the Project IMG that contains the work packages along with their project activities and the Project IMG structure with the system activities in MPX format. Transfer back into the R/3 System is also possible using the MPX format.
In exceptional cases, you can also add additional work packages and project activities to the R/3 Procedure Model and also additional system activities to the Reference IMG for planning and monitoring purposes (see "Additional information").
Since these system enhancements can affect the time schedule of the project, they should fall within the the project manager's area of responsibility.
Project monitoring
In addition to the actual start and actual completion date, you also maintain status information, the selection fields and the resource fields for each project and IMG activity.
Each member of the project team to work on an activity is responsible for maintaining this data.
The following statuses are provided:
that is, the activity has been started.
Setting this status also documents the actual start date.
that is, the activity has been completed from the point of view of the person working on it.
The requirement for this status is that the results of the activity have been documented in accordance with the project standards. Setting this status also documents the actual completion date.
that is, the activity exists in the Project IMG, but is not relevant to the project and should not, therefore be carried out.
The reasons for this should be documented in the note to this activity; setting this status also documents an actual start and actual completion date.
that is, the results of this activity have been checked by quality assurance. This check should be carried out for critical (see IMG attribute) IMG activities in particular. Setting this status also updates the documented actual completion date.
that is, after the quality check some points still remain open.
These should be documented in the note to the activity. Setting this status also cancels the documented actual completion date.
that is, the configuration has been transported successfully into the prototype or production system.
This status updates the documented actual completion date.
To establish a link between the various project and IMG activities and the project team members, everyone who works on an activity enters his/her name in the resource field for that activity.
Bear in mind the distinction between:
Document the system settings in the form of a note (for example, in the standard global SAP note 'Z0') to the IMG activity concerned. Do this in the Project IMG only. The following information should be recorded every time a change is made to the settings:
Use the appropriate MS Word file (S_E.DOC - or T3250E.DOC on the BEW CD) to document the system settings.
Document project work in SAPoffice in the form of documents that are stored in the shared folders.
The folder structures are generated automatically if the following requirements have been met:
When the client is defined, the client role parameter is set to Customizing.
For the "Shared" folder structure, "Project Documentation" must also be activiated in the Customizing project definition.
For the "Components" folder structure, the folders have to be generated when the Enterprise IMG is created.
1. "Shared" folder structure
In this structure, folders are set up for each Project IMG. Each folder contains all the documents of the following classes:
Using the models in the R/3 Reference Model and the text descriptions in the Components folders as your basis, document your enterprise's structures and procedures. Use the following diagram types:
Record additional texts on individual processes/functions in the MS Word document "Process/function description", under the heading "Additional process/function description".
2. "Component" folder structure
In this structure, a folder is set up for each application component.
Your hierarchy should reflect the structure of the Component view in the Business Navigator and the selections you made to create your Enterprise IMG. At the lowest level of the hierarchy in each folder, create the following documents for a process/function:
3. "Deleted" folder structure
This structure is for the documentation that went with application components that have been deselected.
See the
Client management and transport system set-up activity in the "Set Up System Environment" work package.
See the User master set-up for team members activity in the "Set Up System Environment" work package.
System problems/errors can arise either when system or program errors are actually present in the system or as a result of handling difficulties that arise because a member of the project team is not familiar with the R/3 System.
It is recommended that a central technical support team should process system or program errors.
This will mean that the actual project work is not interrupted unnecessarily, and also that a solution can be found more quickly since the technical support team is familiar with the ABAP/4 Development Workbench and knows how to contact the SAP Hotline (via OSS).
You use the appropriate folder in SAP Office, that will contain in one single document all the system or program errors that arose during the project, each entered with a key term (process/function, IMG activity, transaction, etc.) and a short description.
The document is then sent by MLP to the appropriate person in technical support (set up a distribution list) to be processed and solved.
The technical support person contacts the project team member as quickly as possible or attempts to resolve the problem (possibly with the help of the R/3 consultant or the First Level Customer Suport).
When the system error or program error has been successfully processed, the technical support person sends a reply to that effect to the author of the original problem message.
If the standard functionality offered by the R/3 System does not represent a process/function satisfactorily, you can use the ABAP/4 Developement Workbench to develop/adapt the additional functionality you require.
As used by SAP, "modification" means:
The following system enhancements are noncritical:
The accessing of customer modules or the enhancement of menus, screens or text elements from the standard SAP software
User exits record your own program logic without changing the standard SAP program.
The creation of customer-specific objects such as reports, tables, module pools, screens, etc. (The conventions for customer name ranges should be observed.)
Use of the ABAP/4 Development Workbench for program, screen and menu maintenance.
The following system enhancements are critical:
Altering the R/3 System by making changes to programs, screens, menus and the like.
Advance corrections to the R/3 System that anticipate a forthcoming upgrade.
You should always import advance corrections from SAP automatically using the Online Correction Service.

CAUTION

If you carry out critical system enhancements, you should expect the following disadvantages:

Avoid critical system enhancements.
Create an organizational procedure so that system enhancements have to be authorized:
Within any project, project team members will have questions (review requirement) that cannot be resolved/answered without the help of another employee (in the project team or in the company).
Since outstanding issues often cannot be dealt with immediately, it is recommended that you keep a central folder in SAPoffice for this purpose.
Enter any outstanding issues in a document with a key term (process/function, organization unit, IMG activity, etc.) and an appropriate short description.
The document is then sent by MLP to the appropriate person (business process manager, component manager, employee in user department XY, etc.) who then addresses the issue.
For employees not in the project team, use the standard communication paths in your company.
Once the issue has been successfully resolved, the person responsible for resolving it sends a reply to this effect to the author. The author then deletes the outstanding issue from the shared folder if he/she considers the issue resolved.
A process/function or an activity may only be given the status "completed" when all the outstanding issues relating to it have been resolved.
Set up regular committee meetings
All committees should meet regularly to discuss project status, ensure that decisions are made, report on the progress of outstanding action points and to assign new actions. Meetings can also be called ad hoc, if required. In addition to these meetings, other meetings are also held (for example, approval meetings with the user departments). These are held in parallel to the project work whenever this is necessary. Apply the recommendations listed in the section "The Organization of Meetings" below.
Frequency of meetings
The number of committee meetings held will depend on the phase of the project. In early phases, meetings will normally be held more regularly, since more coordination is required at this point. The frequency of project meetings also depends on the number of organizational change requirements and the need for committee approval.
The project team should meet about once a week. The management body should meet once a month. This meeting should be arranged so that it falls before the monthly steering committee meeting. This means that any preliminary results can be discussed in the management body and any remaining questions and decisions then dealt with by the steering committee.
The Organization of Meetings
You should define standards for the structure of meetings. This will ensure that your project can proceed purposefully. Written invitations should be sent for planned monthly and any ad hoc meetings.
The invitations should contain the following information:
a) date and location
b) who is taking part and who else has been informed
c) phase/work package of the project
d) topics to be discussed (each with person responsible and duration)
e) when the meeting is expected to end

Suggestion for a standardized meeting structure (agenda):

a) Appoint a minutes secretary
b) Approve the minutes of the previous meeting
c) Deal with any outstanding issues since the last meeting
d) Discuss the project status
e) Discuss the (preliminary) results of any tasks
f) Present pending tasks
g) Assign pending tasks
h) Approve the results for the minutes
Also use the MS Word lists of open questions that you assigned to the processes/functions.
The topics on the agenda for the management body meeting and the steering committee meeting should be prepared by the project manager (or by someone the project manager has delegated) in such a way that a decision can be reached at the meeting.
The agenda sequence for the steering committee can also be structured to reflect the contents of the project status report.
Project status report
The project status report should be drawn up by the project manager and presented to the steering committee.
It should contain information on at least the following:
i) phase of the project
j) general events
k) positive events
l) negative events and measures taken
m) percentage degree of completion of the work packages
n) planned/actual date situation and consequences of this
o) planned/actual costs and consequences of this
p) remaining work
You should allocate separate rooms for work in the R/3 System and for project meetings.
Members of the project team should be equipped with high-performance, multimedia, MS Windows-based PCs, at least one good laser printer, and a plotter.

Using ARIS-Toolset for this work

Using Visio Business Modeler for this work

Using LiveModel: SAP R/3 Edition for this work

Additional Information

Enhancements to the R/3 Procedure Model affect the whole project. However, they are only visible in the hierarchy display and can only be maintained there. You should set up any new work packages using document class 'CHAP'.
IMG enhancements can be made only in the Reference IMG. This means that, after an enhancement, the Enterprise IMG and all existing Project IMGs have to be regenerated. In the Reference IMG, you must set up any new node using document class 'CHAP' and any activity using document class 'SIMG'. For activities, you must also maintain the application component number and work package number attributes.
To make sure that the enhancements can be transported into other systems, you must enter a development class for each enhancement (you cannot transport a "local object"). To make sure that the description texts of the enhancements can also be transported, you must save them with the "final version" status.
Using ScreenCams
Using ScreenCams to record processes/functions/process flows has several advantages and is generally recommended. In some cases, a ScreenCam of a business process or a special workstation procedure may also be useful.
You can use ScreenCams
That way you can show, and discuss, how the process is organized (using the process chain) and how it is supported in the R/3 System (with the ScreenCam material).
Carrying out a modification
Refer to the Workbench Organizer documentation for programming techniques and the principles of program creation. When you design a modification, take into account that you do not just pay for a modification when it is developed, but that further costs are entailed for modification adjustment during or after a release upgrade. The costs of modification adjustment are lower if you separate your modifications using encapsulation.
Modification adjustment (maintenance upgrade/release upgrade)
If modifications were carried out in the system, then the problem arises that the modified objects might be overwritten by the new standard R/3 System during the next upgrade. In extreme cases, this can lead to the loss of data if the modification rules are not observed.
If you did observe these rules, adjustment transactions are presented to you that will help you to copy your modifications into the new standard R/3 System during an upgrade and thus avoid the possible loss of data.
The transactions for modification adjustment are:
A modification always means that the upgrade process has to be interrupted so that these transactions can be accessed.
It is in your own interest to avoid critical system enhancements by