|
|
PeopleTools Support
 |
|
|
|
PeopleSoft will support PeopleTools enterprise releases as long as there is at least one supported PeopleSoft application that uses that version of PeopleTools. For example, People Soft will support PeopleTools 6.x until support expires for the last PeopleSoft application based on PeopleTools 6.
|
|
|
|
PeopleTools enterprise releases correspond directly to similarly numbered application releases. For example, PeopleTools 7 is used with PeopleSoft 7 applications. When Brandeis University upgrades to a new PeopleSoft enterprise application release, we also need to upgrade to the corresponding enterprise PeopleTools release. For example, when we upgrade to a PeopleSoft 8 application, we also need to upgrade to PeopleTools 8.
|
|
|
|
|
|
|
|
|
A supported release includes:
|
|
|
|
 |
tax updates and other regulatory changes,
|
|
|
|
|
updates and fixes to products,
|
|
|
|
|
Global Support Center management of cases (this assumes Brandeis University is current on all updates),
|
|
|
|
|
training from Education Services, and
|
|
|
|
|
support for third-party products bundled with the software.
|
|
|
|
|
|
|
|
|
When a PeopleSoft release officially moves from a supported to a non-supported state, it is called a retired release. A retired release includes only:
|
|
|
|
|
account management,
|
|
|
|
|
access to PeopleSoft Customer Connection,
|
|
|
|
|
access to PeopleSoft Professional Services consulting,
|
|
|
|
|
access to other available billed specialized consulting programs, such as:
|
|
|
|
|
 |
PeopleSoft Ask Professional Services - a billed consulting service that provides access to a consultant for small scale consulting activities that do not require onsite presence, and |
|
The PeopleSoft Technology Lab program - a billed consulting service that provides the ability to outsource the process of upgrading the PeopleSoft application database to a currently supported release.
|
|
|
|
|
|
|
|
|
|
PeopleSoft Releases |
|
|
The following definitions explain PeopleSoft release types and other release processes:
|
|
|
|
Enterprise Releases - An enterprise release is a major release that delivers significant new functionality for all enterprise solutions. Sets of updates and fixes are also included in enterprise releases. An enterprise release is 7.x to 8.x.
|
|
|
|
Application Updates - This is the maintenance approach for the Commercial PeopleSoft HRMS. This is a delivery mechanism whereby critical and urgent fixes posted to the Updates and Fixes site on PeopleSoft Customer Connection are combined with standard fixes. These combined fixes are system and platform tested before release. This is done once a year for a limited number of releases—usually the current shipping release, and one release prior. When an application update has been released, Brandeis University needs to apply the application update to the appropriate environments within 3 months. After the 3-month grace period, all fixes and support will assume the application update has been applied.
|
|
|
|
|
|
|
|
|
Product Updates - is a new maintenance approach used for the Commercial PeopleSoft Financials, Distribution, and Manufacturing product lines. This is a delivery mechanism whereby critical and urgent fixes posted to the Updates and Fixes site on PeopleSoft Customer Connection are combined with standard fixes. These combined fixes are system tested before release to customers. These updates will be done three times a year (120 day cycle) for a limited number of releases - the current shipping release, and one release prior. When a product update becomes available, Brandeis University needs to apply the product update to the appropriate environments within 3 months. After the 3-month grace period, all fixes and support will assume the product update has been applied.
|
|
|
|
Regulatory Updates - Legislative changes are researched on an ongoing basis. Based on the effective date of the change, the requirement is scheduled for an upcoming regulatory update. The resulting changes are delivered for supported releases. Today this applies mainly to the PeopleSoft Student Administration and PeopleSoft HRMS product lines.
|
|
|
|
|
|
|
|
|
PeopleTools Minor Releases - This is a new strategy for PeopleTools maintenance delivery. These minor releases contain fixes to critical, urgent, and standard priority incidents and may also contain some new functionality. New PeopleTools minor releases are cumulative, so they include all updates from previously published PeopleTools minor releases, patches, and maintenance rollups.
|
|
|
|
PeopleTools Patch Process - PeopleTools will continue to provide patches for critical issues that cannot wait until the next scheduled PeopleTools minor release.
|
|
|
|
Posting to PeopleSoft Customer Connection - As critical and urgent incidents are reported and resolved, PeopleSoft will post them to PeopleSoft Customer Connection.
|
|
|
|
|
|
|
|
|
PeopleSoft Release Support Strategy
|
|
|
Introduction
|
|
|
|
Brandeis University PeopleSoft support strategy will focus on three main areas.
|
|
|
|
|
PeopleTools releases,
|
|
|
|
|
Financials releases, and
|
|
|
|
|
HRMS releases.
|
|
|
|
Typically, these releases will contain critical, urgent, and standard fixes, which occur throughout the year. PeopleTools releases are planned for delivery every 90 days. Financial releases are planned for delivery in bundles on a 270-day cycle (two times per 1½ years) and HRMS releases in 1999 were bundled as releases every 120 days. These minor releases are cumulative and will contain all updates and fixes from the last minor release.
|
|
|
|
In addition to the scheduled releases, PeopleSoft posts critical and urgent fixes (patches) to the Updates and Fixes site in Customer Connection as they become available. These usually cannot wait until the next minor release.
|
|
|
|
|
|
|
|
|
To ensure that the PeopleSoft applications are at their most current release, Brandeis University must retrieve all applicable updates and fixes from Customer Connection. Applying updates/fixes requires business decisions. At times, these updates/fixes must be justified in order to be applied. In some cases, we might not apply the fix because Brandeis does not use the functionality that is changing or because the change may have a negative impact on how Brandeis University does business. we need to address each change upon the release of the software. If we do not apply a fix, however, we risk the possibility that a future fix will have this fix as a pre-requisite or that we need to have applied this fix to receive assistance through the Global Support Center (GSC). Continued support through the GSC and future upgrades will be predicated on maintaining current software.
|
|
|
|
|
|
|
|
|
|
The Strategy
|
|
|
|
Taking these facts into consideration the Brandeis University PeopleSoft release maintenance strategy mandates:
|
|
|
|
|
Weekly or bi-weekly, a PeopleSoft administrator reviews Customer Connection for critical and urgent fixes for the appropriate platform or release of PeopleTools, HRMS, and Financials installed at Brandeis University. Review the fix with the user community and determine its impact on Brandeis University installed software. Before deciding to apply an update/fix, we will make sure to investigate the depth of the specified update/fix. That is, if the fix requires a pre-requisite fix, then the pre-requisite fixes must be investigated as well. Before applying any fixes, we will make sure to understand the overall level of impact. Coordinate application of fixes (apply in DEMO >DEVL > TEST > TRN > QA > PROD) and maintain a fix log.
|
|
|
|
|
|
|
|
|
|
No critical/urgent fixes/hot fixes will be applied unless they impact Brandeis University functionality and business processes. Only those fixes, which are of a critical nature and cannot, wait for the next service pack or update will be implemented.
|
|
|
|
|
Quarterly, we will apply the newest version of PeopleTools, unless there are no problems needing fixing, in which case we will wait for the next maintenance release of PeopleTools.
|
|
|
|
|
Every time PeopleSoft releases a new service pack (or as required by the application release) we will apply the newest release of the application software (HRMS and Financials). There is a 90-day grace period that assumes the product updates have been applied to continue receiving GSC support.
|
|
|
|
|
|
|
|
|
|
Periodically we will apply Tax updates as they become available.
We will build an annual IS workplan that includes all PeopleSoft releases and updates.
|
|
|
|
|
We will follow the Brandeis University Software Configuration Management Plan for applying hot fixes, Patch Releases, and General Releases.
|
|
|
|
|
We will develop a Release Support Plan (project plan).
|
|
|
|
|
Track patches, fixes and upgrades and databases installed, i.e. DEMO >DEVL > TEST > TRN > QA > PROD etc. (using spreadsheet or MS Access database).
|
|
|
|
|
We will document and maintain updates/fixes. In PeoplSoft 7.5, customizations are recorded by operator ID (opid) and date/time stamp. To take advantage of this feature, We will use a unique operator ID to apply updates/fixes. In addition, we will maintain physical documentation in order to ensure the contents of the database containing the updates/fixes. This will simplify tracking updates/fixes as well as future upgrade efforts.
|
|
|
|
|
|
|
|
|
|
We will segregate updates/fixes and customizations into separate projects. This will simplify the migration process of updates/fixes and customizations from one database to another. In addition, documenting each project in a common facility (fix log) will ease organization of the overall project.
|
|
|
|
|
After testing updates/fixes on the DEMO database, we will test them in a customized environment. We will migrate the project to the next environment (DEVL > TEST) and test the updates and fixes against the customized database. This will ensure that the updates/fixes will not conflict with customizations made by Brandeis University. Test, test, test. Make sure to test update/fixes at all stages of the development process.
|
|
|
|
|
We will plan for and integrate into the IS annual workplan, major releases of PeopleSoft (PeopleTools and applications). These should be timed to coincide with PassPort upgrades. Brandeis University should strongly consider using the capabilities of the Upgrade Lab to assist in performing upgrades.
|
|
|
|
|
Note - Before updates/fixes can be applied, AUD, DEMO, DEVL databases must be installed and available, for ongoing changes. Brandeis University will use DEMO database to apply updates/fixes, however, we may want to retain a vanilla copy of the original install. In this event a database instance can be created that is identical to the DEMO database.
|
|
|
|
|
|
|
|
|
|
Roles and Responsibilities
|
|
|
|
The application of updates and fixes requires the involvement of many people. Each has an important role in the successful application of these updates.
|
|
|
|
|
The PeopleSoft Application Administrator is responsible for co-coordinating and applying the updates and fixes, testing the updates and fixes, creating the SQL scripts to be run by the DBA, and migration of the projects from one database instance to another following the database migration path.
|
|
|
|
|
The PeopleSoft Database Administrator is responsible for running the SQL scripts that are created by the application administrator. Each script is to be reviewed by the DBA and applied across database instances as requested by the application administrator.
|
|
|
|
|
The Systems Administrator - Unix is responsible for all Unix based files that are affected by the Update and Fixes.
|
|
|
|
|
Functional Users are the people from GL, AP, Budgets, Grants, Purchasing who will actually test the updates and fixes to ensure that the system continues to function properly after applying any updates and fixes.
|
|
|
|
|
|
|
|
