gen_000186
TRANSCRIPT
SAP R/3 Implementation
KRL
Phase –Conceptual Design and Planning
ASAP Methodology September 2002
Table of contents
1 EXECUTIVE SUMMARY..................................................................................
2 PROJECT CHARTER.......................................................................................2.1 OBJECTIVE OF PROJECT CHARTER2.2 VISION OF KRL2.3 MISSION OF KRL2.4 BUSINESS DRIVERS2.5 BUSINESS MEASURES2.6 PROJECT GOALS
3 ENTERPRISE SCOPE DOCUMENT (ESD).....................................................
4 IMPLEMENTATION STRATEGY.....................................................................4.1 METHODOLOGY4.2 GEOGRAPHICAL SCOPE4.3 IMPLEMENTATION SCOPE
5 PROJECT ORGANISATION............................................................................
6 PROJECT TRAINING.....................................................................................................................6.1 PROJECT TEAM TRAINING6.2 END USER TRAINING
7 PROJECT INFRASTRUCTRE..........................................................................7.1 TECHNICAL REQUIREMENT PLANNING
7.1.1 Development Environment..........................................................................7.2 OTHER INFRASTRUCTURE
8 PROJECT PLAN...............................................................................................
9 PROJECT MANAGEMENT STANDARDS AND PROCEDURES....................9.1 PROJECT COMMUNICATION PLAN
9.1.1 Project Status Meetings.....................................................................................9.1.2 Status Reporting and Work Planning...........................................................
9.2 PROJECT DOCUMENTATION PLAN9.2.1 Standards for Business Processes....................................................................9.2.2 Standards for Project work papers9.2.3 Standards for Deliverables.................................................................................
9.3 Issue Management Plan................................................................................................................9.4 SCOPE MANAGEMENT PLAN9.5 PROJECT PLANNING AND MONITORING STANDARDS9.6 QUALITY ASSURANCE STANDARDS
10 IMPLEMENTATION STANDARDS AND PROCEDURES..............................10.1 SYSTEM AUTHORIZATION STANDARDS FOR PROJECT TEAM10.2 SYSTEM PROBLEMS AND ERROR HANDLING PROCESS 10.3 SYSTEM STRATEGY FOR DEVELOPMENT ENVIRONMENT 10.3.1System Landscape
10.3.2Three System Landscape
1
10.3.3Client Strategy for Development Environment10.3.4Authorization Strategy for Development Environment
10.4BACKUP STRATEGY10.4.1 STANDARDS FOR OSS CODE CORRECTIONS AND HOT PACKAGES
Annexure A : Issue Form TemplateAnnexure B : Change Request TemplateAnnexure C : Answer to CI TemplatesAnnexure D : Meeting MinutesAnnexure E : Agenda for MeetingAnnexure F : Weekly Module level Status ReportAnnexure G : Project Status Report
2
1 EXECUTIVE SUMMARY
Kochi Refineries Ltd (KRL) has initiated the Project Integrated Refinery information system (MANTRA) with a view to implement enterprise applications covering the various business and operation processes of KRL. The initiative is named project MANTRA that means Managing Transformation and Man Transformation. This will enable KRL to streamline its business processes and assist KRL in developing capabilities to be competitive and gain strategic advantage in the emerging petroleum processing and distribution market both in India and abroad.
Kochi Refineries Ltd. as the first phase of Project has embarked on implementing SAP R/3 and is now starting the work on the Conceptual Design and planning phase of SAP R/3 solution.
ASAP (AcceleratedSAP), the latest and proven methodology of SAP, has been chosen as the implementation approach for this project. ASAP offers the following advantages:
minimizes the length of time between installation and production start up maximizes the utilization of SAP and customer resources results in a quicker Return on Investment incorporates a process oriented approach to training involves the user community results in a “model” that can be used with other implementations of R/3
ASAP incorporates a step-by-step approach and avoids NO non-value-added tasks.
There are four major milestones or phases in this project implementation namely,
1. AS IS workshop2. Project Preparation3. Business Blueprint4. Quality audit
Enterprise Scope Document and the Business Blueprint are the deliverables during the conceptual design and planning. The detailed project plan including the tasks, sub-tasks, time frame and roles are given in the project plan which is given in annexure A.
One of the key inputs for an implementation using ASAP approach is Project Charter, i.e. the business framework that guides the SAP implementation. The project charter presents:
The project mission - the reasons as to why SAP is implemented for the company or part of it
The business drivers - company’s or a SBU's business goals for the R/3 implementation.
The business measures - the implementation goals to measure the success of the project, specifically the business-related goals
The business drivers and the business measures are presented in the project charter section of this report.
3
The detailed scope of the project in terms of business processes that are to be implemented will be finalized during AS IS and an Enterprise Scope Document will be generated. This is a deliverable document. This will form part of the Project charter once this is generated.
A large part of success in any implementation project is comprehensive planning and the project preparedness. This includes areas such as:
1. Project organization and training 2. Technical requirement including infrastructure3. Project management standards4. Project implementation standards and procedures.
The details on each of the above areas are given in the subsequent chapters.
The project management standards and the project implementation standards are templates that can be used for any such project. It is suggested that KRL can convert these into institutional standards for other project implementations in the company.
Even as the project team is empowered to implement the project, the Steering Committee and the Project Sponsor play a key role in monitoring and guiding the project and supporting the Project Manager to accomplish the project goals.
4
2 PROJECT CHARTER
OBJECTIVE OF PROJECT CHARTER
Project charter is a document that presents the mission statement for the project, spells out the business drivers and indicates the business / project measurements. The project charter is a framework that guides the SAP implementation using Accelerated SAP Implementation Methodology.
VISION OF KRL
KRL’s vision is to be a globally competitive integrated energy and petrochemical company focused towards achieving excellence in national priority areas with a strong conscience towards protection of environment and progress of society.
MISSION OF KRL
To strengthen the presence of petroleum refining and marketing of petroleum products and to grow into the energy and petrochemicals sector
To realign orientation of thinking and philosophies to become a market driven and customer friendly organisation with focus on total quality management
To enhance shareholder’s value and maximise returns through best use of resources
To recognise employee as the most valuable asset of the organization and foster a culture of participation and innovation for employee growth and contribution
To achieve global standards of excellence through R&D efforts technology upgradation, safety management and environment protection
BUSINESS DRIVERS
Business drivers are company’s or a SBU's business goals for the R/3 implementation. The management team identifies those specific company objectives and business drivers for initiating the R/3 implementation and why the process is important to the corporation. These include tangible and quantifiable measures.
It is important to identify these drivers at the start of the project. They are the reason for the implementation, and they establish the standards by which the success of the project is measured.
KRL involved the entity leadership and management teams in identifying the business benefits that would accrue by implementing an integrated information system across KRL. The primary drivers for the quantitative benefits were as follows:
Business process simplification resulting from integrated information availability
Eliminating duplication of activities by utilizing the same information across the business processes
5
Reducing reconciliation efforts
Quantitative and qualitative benefits identified through this exercise are from:
Financial Accounting including GL, AP, AR and Asset Management Investment Management Cost Center Accounting, Product Costing, Profitability Analysis and Profit center
accounting (To be explored) Materials Management –Purchasing, Inventory Management including
Hydrocarbon Materials Sales and Distribution including IS OIL solutions Project Systems Personnel Administration & Organization Management, training and event
management. Payroll and Time management and Benefit Administration will be evaluated to understand the scope and timing of the implementation.
Plant Maintenance & Service at Refinery/Marketing plants Production Planning for discrete/batch processes (LPG/Bitumen) India Version for Excise, MODVAT, TDS, SALESTAX, OCTROI etc., Quality Management (To be explored) Integration Requirements between MES and SAP
The implementation team needs to keep focus on these business drivers and look at the current implementation as an opportunity to support these business drivers.
BUSINESS MEASURES
Business measures are the implementation goals to measure the success of the project, specifically the business-related goals. These measurements serve as the basis for measuring the success of the R/3 implementation project.
This will be a deliverable of CDP phase PROJECT GOALS
The project related goals form the target for the implementation team to achieve during project execution. The following project goals are to be defined for this project:
Completion of CDP by December 02 2002
Go live by 25 07 2003
Acquire skills to enable the team extend the implementation to newer areas
Follow ASAP methodology and maximize the methodology / tools usage
6
3 ENTERPRISE SCOPE DOCUMENT (ESD)
The Enterprise Scope Document, popularly known as ESD, presents the scope that is being taken up for this implementation. Using ASAP methodology, the team members generate this document by simply choosing the business processes that are to be taken up for SAP R/3 implementation in KRL.
The scope document defining the enterprise area, business scenario and the business process groups that are valid for KRL will be finalized after completion of AS IS and will form part of the Project Charter. This will be a deliverable of AS IS workshop.
AS IS process mapping is completed and the ESD is finalized and is available in the ASAP tool.
7
4 IMPLEMENTATION STRATEGY
METHODOLOGY
The implementation methodology followed for this project is AcceleratedSAP. In addition to providing the approach to successful implementation, AcceleratedSAP provides numerous tools and templates that help the project team to plan and execute the implementation more effectively and efficiently. AcceleratedSAP provides the following benefits:
minimises the length of time between installation and production start up maximises the utilisation of SAP and customer resources results in a quicker Return on Investment incorporates a process oriented approach to training involves the user community results in a “model” that can be used with other implementations of R/3
ASAP incorporates a step-by-step approach and avoids NO non-value added tasks. It utilizes the Business Engineer and is based on R/3’s best business practices. ASAP provides a baseline for Business Process Requirements, Configuration /Testing, and End User Procedures/Training,
Standards have been derived to suit the requirements of KRL for this project. Please refer to Project and Implementation standards section given later for details.
The Customer Input questionnaire helps the client to give their expectations/Requirements about a particular process. It provides a list of 15 generic questions, which should be answered by KRL so that this helps when generating the Business Blueprint.
GEOGRAPHICAL SCOPE
Refinery at Ambalamugal, Kochi, Kerala, IndiaCorporate Office, Maradu (Located 8Km away from manufacturing facilities at Ambalamugal)Jetty facilities at Ernakulam (Located 15Km away from manufacturing facilities at Ambalamugal)Water Pumping station at Alwaye(Located 20Km away from manufacturing facilities at Ambalamugal)Offices at New Delhi ,Chennai & Mumbai.Single Point Mooring Facility (Proposed)
IMPLEMENTATION SCOPE
The implementation scope would cover the following process areas:
R/3 Module Process areasFI/AM Financial accounting including GL, AP, AR, and Asset
ManagementTR-CM Cash managementIM Investment management CO / PA / PCA Cost centre accounting, Product costing and Profitability
8
analysis, Profit center accountingPS Project systemsMM Materials management - Purchasing, Inventory
management including Hydrocarbon materialsPM Plant maintenance and service at Refinery/marketing
Plants SD/IS Oil Sales and Distribution including IS Oil solutions PP Production planning for discrete/batch processes (LPG,
Bitumen ) HR Personnel administration, Organization Management,
Payroll & Benefit Administration*CIN India version for Excise, MODVAT, TDS, Sales Tax,
Octroi etc.QM Quality managementIntegration Integration requirements between MES and BMS
* Pay roll and benefit administration will be evaluated to understand the scope and timing of implementation.
5 PROJECT ORGANISATION
The project organization is the people structure that supports the implementation. The different components of the project organization are:
1. Project Director -- Mr. Koshy Varghese2. Steering Committee Comprising of
Mr N Nandakumaran, GM (PM) : ConvenorMr.N.Sivakumar – ED (HR)Mr.M.A.Mohammed Ali –ED(T&D),Mr.Cherian N Punnose-GM(F&A),Mr.K.N.Ravindran-GM(P),Mr.E.Nandakumar –GM(O),Mr.N.Viswakumar- Company Secretary
3. Project Leader – Mr.N.Nandakumaran – GM (PM)
4. Project Manager (KRL) – Mr.Joseph Martin C F
5. Project Manager (SAP) – Mr.Suresh Ramamurthy
6. Program Manager (SAP) – Mr.Vijay Motwani
7. Functional Teams (SD, MM, QM, PP, FI, CO, PM, PS, HR) SD Mr R JayakrishnanMM Mr V GopakumarQM Mr Jacob ThomasPP Mr A UnnikrishnanFI Mr N R S Ganesh BabuCO Mr Thomas MurickanPM Mr K RaviPS Mr Kurian AlapatHR Mr T A MuralidharanTechnical Mr L L Ramachandran
9
ASAP methodology provides the detailed roles and responsibilities for the project organization. The responsibilities of the Steering Committee and the Project Sponsor are highlighted here.
Role of the Steering Committee:
Empowering the core team to make decisions Generating timely decisions; supporting the Project Leader to accomplish the
project goals Provide direction for the overall SAP project in terms of overall timeline, mission,
goals and scope. Monitor top level plan and progress. Provide organizational resources and sustained sponsorship. Provide top level directional and knowledge inputs. Resolve issues that get escalated to this level. Provide guidance on direction of SAP project in relation to other initiatives which
may impact the SAP Project. Assist in executive stakeholder management of the newly designed processes to
ensure buy-in, effective rollout of new processes and systems, and effective communications strategy internal to the HPL business.
Conduct regular meetings (fortnightly) with the Project Management to ensure that project milestones are met and key issues are resolved.
Ensure that all business issues which impact KRL / SAP Project design and timeline are resolved in a timely, effective manner (i.e. issues which can not be resolved by core team)
Role of the Project Leader:
Is the owner of the project and has decision-making power in the fulfillment of the primary responsibilities, as outlined for the Steering Committee members
Maintains the final authority to set priorities, approve scope, and settle company wide issues
Promotes the SAP project throughout the organization; Where conflicts exist in the completion of these responsibilities the sponsor is empowered to negotiate and promote a solution
Member of the project and Apex Steering Committee. Defining and controlling Scope. Advise Steering Committee on project progress and problems. Monitoring project deadlines Assigning all KRL project personnel (including Project Manager, Core Team
Members, Key users) and monitoring their involvement. Monitoring of risk management aspects and project delays. Ensure availability of all necessary infrastructure required for the project. Participate in review meetings Accept deliverables and give sign-offs
The responsibilities of the SAP project manager include:
Providing methodology for SAP’s accelerated implementation approach Assisting project management and project team in internalizing the
AcceleratedSAP Implementation Roadmap Aiding in the definition of project deliverables and critical target dates to be
reflected in the project plan
10
Assisting in the definition of project scope and objectives Aiding in the resolution of issues when necessary Assisting project managers, consultants, and individual teams when necessary in
the completion of any tasks.
The responsibilities of the KRL project manager include: Definition of the implementation strategy; preparation and maintenance of the
project plan, project budget, and work plan Acquisition, assignment and ongoing management of project resources Communication of project status to the steering committee, project sponsor, and
the project team Streamlining the issue resolution process
The Application Consultant's (SAP) responsibility: SAP R/3 application knowledge in the assigned business process area The ability to solve a company’s business requirement through an R/3 solution The ability to work effectively in a diversified team; guiding and supporting project
team members Strong analytical skills Independence as a team member, with strong time management skills and multi-
tasking capabilities A working understanding of the AcceleratedSAP methodology and tools
Responsibility of Functional team members (KRL) : Develop the R/3 design Configure the system and validate the design Test and document the R/3 implementation Obtain buy-in from both the business process owners and end users Identify mission critical business process scenarios Identifying transactions and data to be tested; managing expected results versus
actual results, and reasons for differences Assigning follow up tasks to reconfigure and retest Tracking of error resolution.
Roles & Responsibility of Technical team : System administrator Database administrator Network administrator Operating system administrator Authorization administrator ABAP developer. Layout developer
The project organisation structure followed for this implementation is given below.
11
In addition to the above project team, the following Business Process Owners are nominated.
MM Mr Thomas K GeorgeSD Mr Anto Varkey
Mr P S RamachanranFI Mr P K SureshCO Mr R Gopinathan HR Mr Prasad M GeorgePM Mr M N NeelakantonQM Mr C K Soman PS Mr Tomy MathwesPP Mr Technical Mr Titus Eapen
12
6 PROJECT TRAINING
PROJECT TEAM TRAINING
Knowledge about the features and functionalities available in SAP is a very critical input for the user team. It is desirable that SAP’s partner academy shall certify the team members, who carry the responsibility of implementation. These team members will also receive on the job training and exposure while performing various project tasks under each phase of implementation. This will ensure that they can carry out the role of internal consultants successfully.
END USER TRAINING
The project team will do end user training during and after Realization phase, which is not covered in the present scope. However KRL is in the process of preparing a comprehensive plan will be released in due course.
13
7 PROJECT INFRASTRUCTRE
TECHNICAL REQUIREMENT PLANNING
7.1.1 Development Environment
The development environment for CDP phase is already in place.The server is IBM make ,Windows 2000 server Intel Foster Xeon MP 1.4 GHZ,2 GB RAM,18.2 GB * 2 in RAID 1,36.4 GB*4 in RAID 5
OTHER INFRASTRUCTURE
Other infrastructure including front ends and printers, sitting space, conference room facilities etc. have already been provided and are in place.
14
8 PROJECT PLAN
The project is to be executed in phases. As there are many intermittent milestones, it helps the steering committee to monitor the progress of the project. The following phases are planned for this AcceleratedSAP implementation:
1. AS IS identification2. Project Preparation3. Business Blueprint4. Quality Audit
Please refer to the project plan KRLProjectplan.mpp for the comprehensive project plan details including tasks, sub-tasks, responsibilities and time line. This is available in the ASAP tool for reference.
15
9 PROJECT MANAGEMENT STANDARDS AND PROCEDURES
PROJECT COMMUNICATION PLAN
9.1.1 Project Status Meetings
Regular project status meetings will be conducted as per the following plan.
Table 1 Project Status Meeting Schedule
S No Title Participants Frequency
1. Steering Committee Meeting
Steering Committee Members
Fortnightly
2. Project Status Meeting
KRL Project LeaderKRL Project ManagerSAP Project ManagerKRL Team LeadersSAP Lead Consultants
Need basis
3. Integration Meeting KRL Project LeaderKRL Project ManagerKRL Module LeadersSAP Project Manager and Consultants
Need basis
4. Module Status Meeting (Separately for each module)
KRL Project LeaderKRL Project ManagerSAP Project ManagerKRL Team Leader KRL Team MembersSAP Consultants
Weekly – Every Thursday of the weekSD 10:00 AM – 11:00 AMMM / QM11:00 AM – 12:00 AMPP 12:AM - 01:00 PMFI/CO 2:00 PM – 3:00 PMPM 3:00 PM - 3:30 PMPS 3.30 PM - 4.00 PMHR 4.00 PM - 4.30 PM
The objectives of Steering Committee Meeting are to
Appraise the committee of the project status Discuss the coming milestones Discuss specific open issues affecting the project schedules Resolve pending issues and ensure that pending decisions are taken Discuss functional and technical support required and ensure availability Discuss resource requirements and ensure availability
16
The objectives of Integration Meeting are to
Discuss the decisions impacting multiple modules Discuss the integration points to ensure that all modules move in the same direction.
The objectives of Project Status Meeting and Module Status Meeting are to
Discuss the project status Ensure that the held up decisions are taken Discuss any outstanding integration issues Report on the action taken on the outstanding action points Assign new action and follow-up items
The minutes of the meeting must be documented using the ASAP templates. These are available as “Meeting Minutes Template” in the Annexure D.
If there is a requirement of any other meeting, a meeting agenda as per Annexure E to be provided.
9.1.2 Status Reporting and Work Planning
The following status reporting mechanism will be used to communicate status and work plan.
Table 2 Status Reporting and Work Planning
S No. From To Title Frequency
1. Project Managers Project Leader Project Work Plan Project Status Report
Fortnightly
2. Module Leaders Project Managers Module Work Plan Module Status Report
Weekly
Project management team will prepare project level plan for each phase detailing overall time frame for achieving each milestone, based on the overall project plan. This plan will be detailed up to weekly tasks, for each module, by module leader and lead consultant. Project management team will suitably modify the overall plan for the phase, if needed, based on the detailed module level plan for the phase.
Module leaders & Lead consultants will prepare weekly plans detailing up to daily tasks and submit this to project managers every Friday. This will be used for project execution and monitoring. The weekly plan will also indicate resources for each task.
Project management team will consolidate the module level status reports into overall project level status report and will be shared with the Project Leader
The formats for project status reports are available as “Weekly Plan/Status Report” & ‘Project Status Report Template “ in the annexure F & G respectively.
PROJECT DOCUMENTATION PLAN
17
9.1.3 Standards for Business Processes
For all the functionality being taken up in KRL ASAP Implementation, the Accelerated SAP - QAdb will be used to document the business processes. The user teams along with consultants need to complete the following:
a. Entreprise scope document (ESD)b. Business Process master list (BPML)c. Based on the CDP review, wherever necessary to capture further details and clarity,
complete both Customer Input (CI) templates and Business Process Questions.d. Concept documents (where relevant)e. A plan that can be triggered if merger happens with BPCL.f. Benefit documentation based on the business process changes evolved during blue
printing.
9.1.4 Standards for Project Work Papers
MANTRA project work would be documented and maintained in shared folders on the mail-server where ASAP is loaded. The name of the directory is MANTRA-DOC.
The following folders would be set up under MANTRA-DOC:
Plans Project (for all the project plans) SD (for all SD plans including weekly plans) MM (for all MM plans including weekly plans) PP (for all PP plans including weekly plans) FI /CO (for all FI/CO plan including weekly plans) PM (for all PM plans including weekly plans) PS (for all PS plans including weekly plans) HR (for all HR plans including weekly plans) QM (for all QM plans including weekly plans) Technical (for all technical plans)
Status Project (for all Project status reports) SD (for all SD status reports) MM (for all MM status reports) PP (for all PP status reports) FI/CO (for all FI status reports) PM (for all PM status reports) PS (for all PS status reports) HR (for all HR status reports) QM (for all QM status reports)
Minutes (for storing all minutes of the meeting)
Project SD MM PP FI/CO
18
PM PS HR QM Integration
Deliverable Enterprise Scope Document Business Blueprint
Knowledge sharing
Issues (will be maintained in the issue database of QAdb)
The following guidelines are to be followed for documentation:
The documents in above-mentioned folders will follow the templates provided in the project standards document.
All the project communication is to be done using SAPOffice/Microsoft outlook.. Backup_sharedprojects_<date> contain the folder to store the QADB work
carried out to complete the Phase 1 and Phase 2 Milestones. All the above directories are centrally available and Project managers, Module
leaders will regularly update the folders as per the requirement and individual module respectively.
The following naming convention is to be followed:
In case of weekly plans for modules it will be year/month/date/doc-type/module. For example, the SD weekly plan for the week starting 16th September 2002 is to be named as 020916-WkPlan-SD. Likewise a detailed SD plan for the blueprint phase can be named as 021125-BPPlan-SD.
In case of weekly status report the same naming structure holds good. For example, the SD weekly status report for the week starting 23rd September is to be named as 020923-WkStat-SD. The status report for a phase is to be named as 020923-BPStat-SD.
In case of meeting minutes, the subject area is to be given as name of the file. All the integration-meeting minutes are to be stored in “Integration” directory.
9.1.5 Standards for Deliverable
The following deliverables would be generated during different phases of the project and will be stored in the Q&A DB of ASAP.
Table 3 – List of Deliverables
Milestone Deliverables
Phase 1:Project Preparation Detailed project plan for CDP phase, Project Standards, Team training , Enterprise Scope Document
Phase 2 : Business Blueprint Business Blueprint document, Benefit statement
19
ISSUE MANAGEMENT PLAN
Given below are the steps involved in the issue resolution process:
Submitting: An Issue form must be submitted by the person who identifies the issue
Logging: The project manager records every issue in the log and updates the status of issues.
Screening*: The project manager must review the submitted issue forms and determine if the issue is relevant to the scope of the project.
Accepting*: The project manager accepts the issue if it may impede the progress or success of the project
Deferring*: The project manager defers the issue if it is contingent on another issue that has not been resolved.
Rejecting*: The project manager rejects the issue if it is not relevant to the project.
Prioritizing: The project manager prioritizes the issue based on its impact on other tasks or phases.
Investigating and resolution determination: The project manager assigns the accepted issue to an Issue Owner for resolution determination. The Issue Owner with other team members would identify the appropriate resolution for the issue.
Deferring resolution: The project manager defers issue resolution if it is contingent on another issue that has not been resolved. If necessary, the manager may consider expediting the issue.
Monitoring or tracking: The project manager monitors the progress and the status of each issue. In addition, the manager follows up on all open issues and identifies their anticipated resolutions.
*In some cases, the team leader or other person will be qualified to take on this responsibility.
The issue log will be reviewed on a weekly basis and the project managers will take appropriate action.
Issue Escalation Process
Expediting: If an issue is not resolved by the forecasted date, and the lack of resolution will affect other project steps, then the issue must be expedited. The project manager evaluates the reason the issue is not resolved and defines what must be done for the issue to be resolved. Also, the project manager identifies who is responsible for resolution, attempts to put more people on the issue team (if this would help resolve the issue), and ascertains whether or not the issue will be resolved in a timely manner. If need be, the project manager raises the priority and rearranges the project schedule to accommodate issue resolution, keeping in mind the business and project goals.
20
Escalating: If the issue is not resolved according to the project plan and this will significantly affect the project time line, then the manager may opt to escalate it to the steering committee.
Crisis mode: If there is a crisis, for example, the system is down or a significant member leaves the team, the project manager should immediately review the project, its status, and the impact of the crisis. Additionally, the project manager should devise a workaround to accommodate the change to the project plan. In all cases, the project manager involves the lowest-level personnel in the decision-making process. The project manager will report any revisions of the time line in an emergency steering committee meeting.
Issue database in QAdb will be used to track the issues. The following Issue Statuses would be used to monitor the status:
Logged and unassigned Rejected Deferred Under Investigation Under Implementation Resolved Expedited Escalated Crisis Mode
The following classification is to be used to categorize issues in QAdb:
Business process Documentation Resource Project management Application configuration OSS/Software bug Conversion Interface SapScript /Forms Authorization System administration Training
The issues will be logged in the issues database of Q&A DB .The issue form is given in Annexure A.
SCOPE MANAGEMENT PLAN
The actual scope with related business processes, R/3 functionality, interfaces, data conversions, R/3 enhancements and reporting requirements get finalized in Business Blueprint document. Subsequent to Business Blueprint approval, any requested changes in scope must follow the process mentioned below:
21
Step 1 - Submit the requested change in the format specified in accelerator section of ASAP to the Project ManagerStep 2 - The Project Manager would assess the impact of incorporating the change on the project schedules and cost.Step 3 - A recommendation would be made to accept or reject the change.
A log of all change requests would be maintained in the Scope Management folder in the mail server.
The scope change request form is provided in Annexure B.
PROJECT PLANNING AND MONITORING STANDARDS
MS Project would be used as the tool to track the status of various tasks in the Project Plan. Any task, which will take two or more days, must be mentioned at least at the module level. In addition to the Plan/Actual Start and Plan/Actual End dates, additionally the following statuses can be maintained for tracking purposes:
Task on Hold: The task has been put on hold due to non-availability of Information / resources or linkages to an unresolved issue Task Completed: The task has been completed from the point of view of the responsible person. The task is considered complete only when all related documentation has also been completed.
QUALITY ASSURANCE STANDARDS
A Quality Audit would be performed at the end of following stages in the project:
Business Blueprint
The QA is not a review of the project for conformance to the ASAP tools and templates. The QA review assists the customer executive management and project manger in providing a second opinion of the implementation progress towards achieving the project goals. The scope of the review is to investigate the application, technical and project management areas of the implementation. The review looks for good implementation practices while following a prescribed methodology. Each review is one or two days in length.
Procedure
QA is automatically included in the ASAP Roadmap.
1. QA Agenda Meeting
This meeting starts the day with a review of the one or two day agenda with the project manager and executive sponsor. Any input to the QA process from senior management is noted for consideration.
22
2. Key Interviews The discussions are conducted with various key project team members and end user management.
3. Key Document Study Various documents are reviewed.
4. Present Preliminary Findings A meeting is held with the project manager and executive sponsor to verbally discuss the finding from the QA process. This ensures that there is clear understanding of the project information and that the right people and documents have been reviewed.
5. Prepare QA Findings Report The consultant assembles the information collected and prepares a report for management.
6. Present Report A final meeting is held with the project manager and executive sponsor to present the findings in writing.
ResultsAn oral presentation and a written report of the review results are given at the end of the review.
23
10 IMPLEMENTATION STANDARDS AND PROCEDURES
SYSTEM AUTHORIZATION STANDARDS FOR PROJECT TEAM
Development Server will serve the following purposes Development System [Playground / Sandbox] Customizing System Training System
System Checks
1. Initial state
Most users in a newly installed R/3 System begin with the authorization in their user master record. This profile allows a user to perform all tasks in an R/3 system. As the R/3 project progresses, the need to limit user access increases. In general, users in the DEV system have more access than users in the Test (QAS) or Production (PRD) system.
2. First stepsAt this time, the Security Administrator should be learning the R/3 Authorization Concept. Initially, it is recommended you create a new profile <KRL_ALL, modeled on the profile SAP_ALL, but removing the poweruser authorizations. Refer to The SAP R/3 Authorization Made Easy - Guidebook Special Cases Setting Up Authorization Profile KRL_ALL. Assign the activity group KRL_ALL to all non-superusers in the DEV system and update their user master records as described in Assigning Activity Groups and Authorization Profiles to Users.
3. Limiting the number of power users There should be a very limited number of power users in each system. Treat power user accounts similar to root in UNIX. The KRLALL profile limits risk on the DEV system. You now control who can create and maintain users, profiles, and authorizations. You also eliminate attempts to lock transactions, delete user sessions, stop work processes, and any other basic administration functions. This control maintains the integrity of the system, and keeps it as stable as possible. You do not want any system malfunctions due to excessive access. Such malfunctions can cause delays in project development.
4. Using the profile generator
Using the profile generator the Security Administrator develops user profiles and authorizations in the DEV system. User profiles and authorizations are transported to the QAS system for final testing before going to PRD. The user master records can be created in PRD closer to the go-live date. The activity groups, together with the authorization data transported from DEV to QAS to PRD, are assigned to the users, as required. In both QAS and PRD, all authorization profiles need to be regenerated after the activity groups are imported. As generated profiles are not included in the transport, you must regenerate the profiles once the data has been imported into the target system. To do this, choose R/3 transaction PFCG Authorizations for an activity group, then choose Generate. Repeat this for each imported activity group.
5. Documentation of authorization designDocumentation is especially important from the beginning. It helps future roll outs of the project go smoothly. Documentation is essential to pass on security administrative functions to other project members, and is required by auditors.
6. Cooperation with client copy activitiesThe Security Administrator should work closely with the administrators responsible for client copies. Users, authorization profiles, and authorizations are all client-dependent. When new clients are created generated profiles and authorizations are not automatically copied. The client copy administrator also needs to know which user master records need to be copied.
7. Cooperation with Change ManagementThe Security Administrator should work closely with your company’s Change Management administrators. Both administrators are important control points for the project. The system landscape, client landscape, and client roles should be clearly defined and presented to the project team. Development classes and authorization groups should be established for all new development. All administrators should attend SAP training course BC325 – Workbench Organizer, Transport System, and Upgrade. Next, they should conduct a project-specific workshop both to review the system and client landscape, and to discuss the control points – when development requests move, what clients they move to, what signatures are required along the way, and so on.
8. Cooperation with ABAP/4 Development Workbench usersThe Security Administrator should work closely with the developers to enforce security standards for new ABAP/4 programs and transactions. All new customer-written code should be assigned to an authorization group through the ABAP/4 Editor attributes screen (transaction). These standards can be enforced through Change Management. Unprotected customer-written programs and transactions in PRD always present problems.
9. Cooperation with corporate auditors
The Security Administrator should now consider involving the corporate auditors. It is recommended BPCL involve the corporate auditors up-front so their requirements are incorporated in the development efforts. It can be unpleasant when projects that did not include corporate auditors are eventually audited post-live. In the worse case scenario, projects are halted until auditor requirements are met. At a minimum, all of the original development work has to be revisited.
SYSTEM PROBLEMS AND ERROR HANDLING PROCESS
Steps
1. Determine the Service Level Agreements internally, based on the future internal R/3 Help Desk organization. These Service Level Agreements should be agreed with the other project teams. Set an appropriate date for availability of the R/3 Help Desk organization.
Result
25
Each Service Level Agreement should cover the following:
Desktop Level Application area description (particularly remote log-in procedure)
Procedures Desktop Level Support
organizational plan Standard processing time Reporting and response procedures Escalation procedure
Server Level (application and database server)
Application area description Server Level Support organizational
plan Procedures Standard processing time Guaranteed recovery window Procedures for R/3 transports Standard processing times for R/3
transports Reporting and response procedures Escalation procedure Disaster recovery decision paths
Network Level Application area description Network Level Support
organizational plan Procedures Standard processing time Reporting and response procedures Escalation procedure
Partner Support Organizations Access to further support organizations What support partners are
available? (SAP, hardware partners, implementation partners, development partners, others)
Procedures for processing problems – Recording problems Passing problems to partners Communication with partners Implementation of solutions Closing problems
Procedures for accessing support partners, with particular regard to security aspects, as appropriate
STRATEGY FOR DEVELOPMENT ENVIRONMENT.
26
The development environment of KRL requires to have the following software in the same server.
R/3 4.6CCIN 4.0AIS-Oil 4.6C
The Development Server will be installed as follows.
R/3 will be installed first.IS-Oil will be installed as the next add-on installation.CIN will be installed as the last add-on.
10.1.1 System LandscapeThe landscape consists of all R/3 Systems (Instances) involved in the implementation project and client architectures that access (or share) a common transport directory.
Development (DEV)All customizing and development work is performed in this system. After all the changes have been unit tested, these changes can be transferred to the quality assurance system (QAS) for further system testing.The customizing and development changes are transported using transport requests.The development system also contains a sandbox (SAND) client that allows new users to become familiar with the R/3 System and lets experienced users test customizing changes without affecting the main customizing client.
Quality Assurance (QAS)After unit testing the customizing and development changes in the development system (DEV), the changes are transported to the quality assurance system (QAS). Here, the configuration undergoes further tests and checks to ensure that it does not adversely affect other modules.When the configuration has been thoroughly tested in this system and signed off by the quality assurance team, it can be copied to other system clients and to the production system (PRD).
Production (PRD)A Company uses the production system (PRD) for its production work. This system—containing the company's live data—is where the real business processes are performed.The other systems in the landscape must guarantee that defective programs or incorrect customizing configurations do not adversely affect the production environment
10.1.2 Three-System LandscapeAdvantagesSubsequent installation of additional applications can be prepared for without affecting production workThe general sandbox client (SAND) in the development system (DEV) makes it easier to become familiar with the new application functions and conduct suitability testing
27
The customizing configuration for production is carried out in the customizing/development client (CUST) in the development system (DEV) and is then transported to the quality assurance-testing client (QTST) of the quality assurance system (QAS) for validationThe transport of the customizing settings can be verified before being taken over into the production system (PRD)The ability to conduct isolated testing of new customizing configurations and program developments before releasing them to the production environmentThe ability to integrate development efforts and to check the validity and consistency of transported objects before moving the objects into productionClient-independent customizing testing can occur without conflicts
DisadvantagesNeeds additional hardwareRequires increased system administration and change management activities
10.1.3 Client Strategy for Development Environment
Standard ClientsOverviewEvery R/3 System is initially installed with three standard SAP clients. The role of these clients is described below:Standard ClientsClient Name Description
000 SAPR SAP Reference001 SAPS SAP Sample066 SAPE SAP EarlyWatch Service
The contents of clients 000 and 001 are identical when a R/3 System is first installed. Both clients contain organization-specific and non-organization-specific settings that can serve as a foundation for working in the R/3 System.
Client 000: SAP Reference Client (SAPR)This client is shipped as an industry-neutral model company.To create a new client, as recommended in this documentation, the SAP reference client (SAPR) should be used as the source client in the client copy procedure. The new client will then contain an executable system that can serve as the basis for further customizing, development, training, and testing.During an upgrade to the R/3 software, client-dependent changes will be automatically updated in the SAPR. To reflect these changes in the other clients, the settings will need to be copied from the SAPR to the other clients.The Implementation Guide (IMG) contains delta projects that highlight the changes between different R/3 releases. These projects can be used for distributing the new functionality to other clients and other systems in the landscape.The delivered SAP reference client (SAPR) should never be changed or deleted from the system.
28
Client 001: SAP Sample Client (SAPS)As stated previously, when the R/3 system is installed, the SAP reference client (SAPR) and the SAP sample client (SAPS) are identical. After the system has been upgraded, or additional languages have been imported, it is likely that the SAPR will contain customizing table entries and language-dependent text entries relevant to the new release.The SAPS, like all other clients in the R/3 System, will not contain the new entries after the update. If this information is required in the SAPS, it will need to be transported with customizing transactions and the change management system.
Client 066: SAP EarlyWatch Service Client (SAPE)SAP provides a proactive support service for checking the performance of a customer’s system. This EarlyWatch Service (EWS) involves a survey of the customer system to check various performance criteria.A report is then compiled and forwarded to the customer with recommendations. These recommendations are aimed at improving system performance. The report should also alert the customer to potential problems, so that immediate, corrective action can be taken.The SAP EarlyWatch service client (SAPE) enables SAP to remotely access the customer system. The client contains a user record that the SAP EWS personnel use to log onto the customer system and gather the necessary information. The user record only has the minimal R/3 authorizations necessary to allow the
The following clients will be available in the system with the mentioned settings.
Client No Client Name System Change Option
100 Development Client All changes allowed
200 Test Client Only client dependent settings
300 Golden Master Client No Changes allowed
10.1.4 Authorization Strategy for development environment
Enable the Profile generator as defined in the Authorization Made Easy Guide book on your development server.
The users in the system may be categorized as
R/3 System Administrators
Project Manager
Team Leaders / Members
29
During the development phase of the system, it is required that the team members be given adequate rights to ensure a smooth operation. Unlike in a production server environment, the roles are defined at a more broad level.
The following will be the profiles assignment for the mentioned user category.
1. R/3 System Administrators: SAP_ALL + CIN + IS-Oil2. Project Manager: SAP_ALL + CIN + IS-Oil3. Team Leaders/ Members : Function_ALL + CIN + IS-Oil + CTS_ALL +
Develop_ALL
Any further authorizations required will have to be submitted to the technical team after approval from the project manager.
Profile Function_ALL ( will substitute the team with their function. E.g.: MM_ALL, FI_ALL, SD_ALL …)
BACKUP STRATEGY
SAP recommends a backup cycle of 4 weeks. A pool of tapes for database and offline redo log file backups is required. Ensure
that enough tapes are provided in each tape pool to span the entire backup cycle. We recommend having 30% more tapes than required. to cover database growth and additional backups, for example after a database extension. Backup tapes can be reused at the end of a backup cycle (after 28 days).
30
Perform a full online backup each workday. Perform a full offline backup at least once in the backup cycle.
You must back up the offline redo log files each workday, as well as after every online and offline backup. Ensure that you back up the offline redo log files twice, on separate tapes, before they are deleted.
To verify a backup, check the database for logical errors and the database backups for physical errors. You must perform backup verification at least once in the backup cycle, however, you should try to perform it once a week.
Remove the last verified full offline backup of each cycle from the tape pool, and keep this backup in long-term storage. Replace the tapes, and initialize new ones.
Perform additional backups after each database structure modification or a system upgrade. Place these additional backups in long-term storage.
10.1.5 Standards for OSS code corrections and Hot Packages
A central register will be maintained to document application of R/3 code fixes from either the OSS system, or through SAP Hot Packages. The register would be maintained in the System Problem and Errors folder as an MS Excel file with the following columns
Patch No Brief Description (as specified in the patch) Date of application Correction performed by Reference Problem no (as provided by SAP Help-desk)
31
Annexure A : Issue Form Template
ISSUE IDENTIFICATIONDate Submitted Submitted By Project Name Issue ID Issue Name Category
Issue Description:
ISSUE INVESTIGATION AND RESOLUTIONResponsible Party Status Date Assigned
Issue Resolution(s)
Resolution Authorization Date Issue Status Due Date
Resolution Date
ISSUE ACTION OPEN CLOSED DEFERRED CHANGE REQUEST #
32
Annexure B: Change Request TemplateSubmitted by: Date: Req.
Nbr:Requested by: Project:Area Affected
SAP Module: SD FI MMPriority: Critical Important DesirableBusiness Area:Description of Proposed Change
Benefits/Reason for Change
Approvals for InvestigationProject Manager: Date:Comments:
Senior Management: Date:Comments:
InvestigatedAssigned to: Date:Comments:
Impact AnalysisOn: budget, resources, project days, other modules, etc.Comments:
Disposition: Closed Deferred Rejected On Hold Date:Approval for ImplementationManagement: Date:
Comments:
33
Annexure C: Answer to CI Templates
Once the detailed process scope has been agreed, and business process questions have been answered, it is time to analyze the detailed requirements for each business process. The Customer Input template is a series of 15 generic questions that are asked about every process, they form the "detailed design" requirements and the body of the business blueprint document.
The 15 CI template questions are:
1. Requirements/ExpectationsA brief definition of the process and its requirements.
2. General ExplanationsAny general explanations on the process that relate to the customers business process. This typically does not include any SAP specific terms, it should relate purely to the business rules.
3. Explanations of Functions and EventsIf there are any special functions or events. This may include process triggers etc.
4. Special Organizational ConsiderationsIf there are any special organizational considerations. Where in the organization a particular process exists or if it is unique to a business division.
5. Business ModelIf a business-modeling tool is used, reference to it is applicable here.
6. Changes to Existing OrganizationChange management issues as appropriate.
7. Description of ImprovementsIt is important to outline where the business will realize benefits of implementation. Both in its use of software, and streamlined business processes.
8. Description of Functional DeficitsWhere appropriate, identify any gaps. This section is important when assessing risk, as well as estimating the need for ABAP (or similar) resources.
9. Approaches to Covering Functional DeficitsDocumentation of any work-around or assumptions that have been made when outlining functional deficits.
10. Notes on Further ImprovementsThis is very useful to document any planned improvements, or a ‘wish list’ for the future. It can be the basis for a phase 2 or steering committee scope meeting.
11. System Configuration ConsiderationsDocument any special considerations that may need to be taken into account when configuration occurs.
34
12. File Conversion ConsiderationsDocument file conversion procedures. Where the information is to come from, what data is to be converted manually/automatically and at what point in time. This is critical information that is used later.
13. Interface ConsiderationsIf any exist, document where and how they will be realized/used.
14. Reporting ConsiderationsOften forgotten, always necessary. It is always necessary to document what reporting requirements exist. It also will enable more accurate planning of resources during the realization phase.
15. Authorization ConsiderationsDocument what types of user use the business process (e.g. Account Clerks, Cost Centre Mangers etc.) and what their user access privileges should be. A deliverable in the project charter is a list of users and where they fit into the business, this document is very useful when completing this step.
The CI template questions will form the heart of the business blueprint document, thus it is very important to provide as much information as possible when answering these questions. In some cases the information needed is not known at the Blueprint stage, if this occurs, it should be noted in the CI template answers. For example, when entering the Authorization Considerations during the Business Blueprint phase only high level information is available. As this changes, the QADB should be updated with detailed authorization requirements.It is up to the Customer and SAP Project Manager (and project standards paper) to specify what detail is required at what point for the CI template answers.
35
Annexure D:
MEETING MINUTESSubject: ...Meeting
Meeting Date:
Time: 9:00…
Attendees: Copies:
Minutes Taken By:
Off-agenda Items:Following is a summary of the meeting:
1.
2. Summary of Issues
Open Items:
1.
Attachments:1.
36
Annexure E - Agenda for Meeting
Subject: ...MeetingPurpose:
Meeting Date:Time: 9:00…
Attendees:
Minutes Taken By:
37
Annexure F: Weekly Status Report
Weekly status Report : 4th October 1999 to 9th October, 1999Module :
A. Weekly Status Report
Plan Tasks Plan Dates Responsibility Status Proposed Action
B : Issues Needing Attention
C: Weekly Plan
Plan Task Plan dates Responsibility Comments
38
Annexure G: Project Status Report
Month of: _________
Project Name:_________________________ Date: _______
1. SummaryAs of Sep 2002, we have completed Phase 1 (Project Preparation) and Phase 2 (Business Blueprint).
2. Gantt Chart — Work Package/Phase LevelProduce from Project Management Planning Tool, for example MS Project. Attach graphic here.
3. Issues StatementMake a high-priority list of open issues and provide a brief summary description.
4. Scope ChangesIdentify the scope changes, if any.
5. Change Control Mechanism List new changes to the project which will materially affect budget, timeline or resources.
6. ResourcesProvide a brief statement about resource issues (capacity, utilization, training). Utilize the Resource Variance Report Template.
7. Major Activities Next MonthAttach the Project Work Plan to describe next month’s activities. Also provide a brief description of the most important activities.
39