|
LL MM MM SSSSSS
LL MMM MMM SS
LL M MM M SSSSSS
LL M M M SS
LLLLLL M M M SSSSSS
RELEASE MANAGEMENT PROCESS
Version 3.0
LMS Release Management Process
LMS Legacy Implications...............................2
Introduction ........................................ 2
Revision History......................................2
Need Identified.......................................3
Request for Analysis Submitted........................3
Request for Analysis Refined..........................3
Request Distributed to all Sites......................3
Request Submitted to Vendor...........................4
Work Prioritized......................................4
Release/Implementation Schedule Determined............4
Proposed Release/Implementation Schedule Distributed..5
Saveset Availability..................................5
Final Acceptance Testing..............................6
Release Installed into Production.....................6
Request for Analysis Form.............................7
Release/Implementation Schedule.......................8
User Acceptance Notification..........................9
Page 2
LMS Legacy Implications
-----------------------
As a result of Corporate efforts to condense and dramatically reduce
applications in support of the Year 2000 system implications and
SAP R/3 standardization, LMS has been earmarked as a Legacy
Application, and must be retired. This will occur either by the
Y2000 efforts as a result of SAP R/3 implementations. These efforts
are planned to reduce and streamline the cost of the corporate
infrastucture. Since retiring LMS is planned, All enhancements are
frozen unless they are regulatory in nature, and are mandates. The
Emphasis of the document has not significantly been altered, with
exception for this mandated consideration. As such, all requests
should be accompanied with cost center management approval, and
are consistently applied to all user sites.
INTRODUCTION
------------
The purpose of this document is to describe the expectations placed
upon the user sites as well as PSG (Production Systems Group)
in support of requests for modifications of the (LMS) functionality.
The process identified will provide for effective communication,
consistent testing and implementation strategies for multiple
sites, identify roles and responsibilities, and ensure milestones
are completed in a timely manner.
For each milestone in the enhancement process, participants,
input, output and ownership are defined.
Needs identified as more critical (system unavailable, bug fixes,
etc.) will be processed using the LMS Hotline Support Document
which can be obtained thru the LMSCU::LMS notes file
Comments, questions and suggestions may be submitted to:
Linda Vaughan TIS::LVAUGHAN 297-6139
or MSexchange @ [email protected]
REVISION HISTORY
----------------
Version 3.0, May 1, 1997
SCU change to PSG
Update Contact list
LMS Legacy Implications
Saveset Availability Process Change
Version 2.6, October 18, 1994
Initial publication.
Page 3
1. A NEED IS IDENTIFIED.
-------------------------
Participants: Business or PSG
Input: Analysis
Output: Request for Analysis (attached)
Ownership: Whoever has identified the need
The Request for Analysis requires at a minimum:
Minimum requirements for analysis include:
Problem Statement
Non-systems Alternative
Benefits statement
Request Type
Priority
How handled today
2. REQUEST FOR ANALYSIS submitted to PSG
-------------------------------------------
Participants: Business and/or PSG
Input: Request for Analysis
Output: Request for Analysis
Ownership: Whoever has identified the need.
3. REQUEST FOR ANALYSIS REFINED.
---------------------------------
Participants: Business and/or PSG
Input: Request for Analysis
Output: Request for Analysis, PSG ID#
Ownership: PSG
4. REQUEST DISTRIBUTED TO ALL SITES
------------------------------------
Participants: PSG and all sites
Input: Request for Analysis
Output: Feedback by sites
Ownership: PSG
PSG distributes request to other site(s), providing a formal
opportunity to review and provide feedback by an PSG-designated
date.
Page 4
5. REQUEST SUBMITTED TO VENDOR
-------------------------------
Participants: PSG, vendor
Input: Finalized Request for Analysis
Output: Quote
Ownership: PSG
6. WORK PRIORITIZED
--------------------
Participants: PSG, sites
Input: All existing requests for which there is a vendor quote
Output: Sites-approved, prioritized schedule of enhancements
and release dates; notification of closed request,
if applicable
Ownership: Prioritized list: sites
Notification of closed enhancement: PSG
If for some reason a request is closed, PSG will provide formal
communication to all sites.
7. RELEASE/IMPLEMENTATION SCHEDULE DETERMINED
----------------------------------------------
Participants: PSG, sites
Input: Prioritized listing of identified enhancements
Output: Proposed release/implementation schedule
Ownership: PSG
Page 5
8) PROPOSED RELEASE/IMPLEMENTATION SCHEDULE DISTRIBUTED
--------------------------------------------------------
Participants: PSG, sites, vendor
Input: Proposed release/implementation schedule
Output: Finalized release/implementation schedule
Ownership: PSG, sites
PSG submits a proposed implementation schedule which includes
dates for release of preliminary saveset, acceptance testing (including
ownership) and worldwide implementation.
Template included at bottom of document.
Sites to approve schedule or suggest modifications by date determined
by PSG.
Upon agreement, PSG submits finalized plan to vendor and sites.
9) SAVESET AVAILABILITY
------------------------
Participants: PSG, vendor
Input: Acceptable test results of enhancement
Output: SAVmmdd*.BCK, LMS Release Notice
Ownership: PSG, vendor
Step One:
Sponsor Site is notified of saveset availability, who will provide an
LMS Release Notice. It is the sponsor site responsibility to test the
Solution and provide acceptance, at which time a general release will
occur.
StepTwo:
Sites are notified of saveset availability via PSG, who will provide an
'LMS Release Notice' (renamed from READMEFIRST.MMDD) specifying the
following:
The '*' appearing in the saveset name represents a letter which will
be incremented if there are more than one savesets distributed on a given
day. For example, the first saveset might be SAV1012.BCK, the second
saveset for that day SAV1012A.BCK, the third saveset for that day
SAV1012B.BCK, etc.
For a release, for each request being distributed:
1. Brief description
2. Request for Analysis PSG ID#
3. List of files affected.
4. Clear, concise instructions for IM&T and superusers.
5. New logicals documented.
6. If record layout has been changed, new layout is
included for user acceptance testing.
7. Documentation: what has been revised and how revisions
are being distributed.
8. Implementation plan attached.
9. User Acceptance Notification attached.
Page 6
10) FINAL ACCEPTANCE TESTING
-----------------------------
Participants: Site(s), PSG, vendor
Input: SAVmmdd*.BCK, LMS Release Notice
Output: Successful: User Acceptance Notification
Unsuccessful: mail communication to PSG, sites
Ownership: Site(s)
The '*' appearing in the saveset name represents a letter which will
be incremented if there are more than one savesets distributed on a given
day. For example, the first saveset might be SAV1012.BCK, the second
saveset for that day SAV1012A.BCK, the third saveset for that day
SAV1012B.BCK, etc.
Upon successful completion of user testing, site responsible for testing
enhancement submits User Acceptance Notification to LMSCU::ACCEPTANCE,
which will notify all sites and PSG.
Template included at bottom of document.
If problems found during testing, site responsible for testing
should inform PSG and other sites in writing. PSG to work
with vendor for resolution and return to step 8).
11. RELEASE INSTALLED INTO PRODUCTION
--------------------------------------
Participants: Site(s)
Input:
Output: Written communication back to PSG indicating
that implementation has completed.
Ownership: Site(s)
Each site must submit notification that release has been moved into
production environment.
NOTE: If for some reason a release cannot be implemented as
scheduled, future releases will be placed on hold until all sites
are at same rev of LMS.
Page 7
REQUEST FOR ANALYSIS
--------------------
(Submit to PSG)
REQUEST TITLE:
DESIGNATED BUSINESS REPRESENTATIVE: SITE:
PHONE #: E-MAIL: CC:
MANAGER: DATE:
PSG ID #:
(To be supplied by PSG)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
REQUEST TYPE:
Please check one of the following:
New Development [ ]
Enhancement (additional functionality) [ ]
Modification (change to existing functionality) [ ]
Other: ______________________________________ [ ]
______________________________________
PRIORITY
Reason: Please check one of the following:
1. Audit point [ ]
2. Compliance and/or Internal Control Issue [ ]
3. Time Critical [ ]
4. Productivity Improvement and/or Cost Savings [ ]
5. Disfunctional [ ]
Other: ______________________________________ [ ]
______________________________________
PROBLEM STATEMENT:
HOW DO YOU HANDLE THIS PROBLEM TODAY:
NON-SYSTEMS ALTERNATIVE:
BENEFITS STATEMENT:
OTHER IMPORTANT FACTORS:
Page 8
RELEASE/IMPLEMENTATION SCHEDULE
-------------------------------
(Distributed by PSG)
PSG ID #:
REQUEST TITLE:
SAVESET:
SCHEDULED DATE OF USER ACCEPTANCE TESTING:
SITE PERFORMING PRIMARY TESTING:
SCHEDULED DATE OF IMPLEMENTATION:
Page 9
USER ACCEPTANCE NOTIFICATION
----------------------------
(MAIL TO LMSCU::ACCEPTANCE)
The following modification to LMS functionality has been successfully
tested and approved for implementation.
PSG ID #:
REQUEST TITLE:
SAVESET:
SCHEDULED DATE OF IMPLEMENTATION:
DESIGNATED BUSINESS REPRESENTATIVE: SITE:
PHONE #: E-MAIL: CC:
MANAGER: DATE:
|