Introduction and general background

Oracle's PeopleSoft applications are the basis for a great number of the University's mission-critical functions. Other enterprise applications - supported by OIT or by other distributed IT units - integrate with PeopleSoft to provide specific functionality to targeted user populations. The OIT PeopleSoft Application Development team publishes the information on this page for the University of Minnesota business analysts and technology staff who represent business process owners in the support of the group of PeopleSoft applications.

Page Audience

Business analysts responsible for direct support of one or more modules of a PeopleSoft application

Page Purpose

Provide guidance for the reporting of unplanned/unexpected functionality issues associated with a PeopleSoft application at the production level. One goal is to provide a written reference for steps and actions that may be infrequent for some individuals/teams.

  • This page documents (at a high level) a few operational norms which have been in place for several years
  • The guidance on this page relies heavily on the professional judgment of the reporting business analyst(s).

Errors Encountered in the Production Environment

When first contacting the On Call Team via one of the methods below, please classify your topic with one of the following Severity values:

  • Critical: Total failure of the system, or module functionality, or the corruption or loss of data. There is no workaround identified. It prevents the use of the system: "We cannot do business."
  • Major: Significant failure of the system, or module functionality. There may be a workaround identified, however; the workaround is difficult, high risk, and/or unsustainable until the next monthly change window: "We're in trouble."
  • Moderate: Some loss of the system, or module functionality. The business processes can be completed, but the system may display data incorrectly/incompletely/inconsistently. A workaround exists and is sustainable on a near term basis: "This is difficult." (Note: these items should be managed as Planned Work, only items that would become Major or Critical at a soon-to-be-reached business milestone should be reported via the on-call channel.)
  • Non-production: An issue with a non-production system.

Report a System Issue

If There Is an Existing TeamDynamix Incident

  • Assign the Incident to one of the following Responsibility Groups:
    • T3 EFS PeopleSoft Developers
    • T3 OIT HCM Tech Support
    • T3 OIT Portal Developers
    • T3 OIT Student Admin Services
  • State the Severity of the issue
  • Add any additional information or context (usually needed since the Incident was typically opened by someone outside of a business analyst group)

If There is No Existing TeamDynamix Incident

  • Write to [email protected] with one of the following tags included at the bottom of the email (place the tag before any signature; this tag will cause TDX to auto-route the resulting Incident to the On Call Team):
    • assgn_grp:T3 EFS PeopleSoft Developers
    • assgn_grp:T3 OIT HCM Tech Support
    • assgn_grp:T3 OIT Portal Developers
    • assgn_grp:T3 OIT Student Admin Services
  • State the Severity of the issue
  • Describe the issue, provide any screen shots or attachments

The default timeline for the On Call Team's initial response is to acknowledge the incident within 15-30 minutes.

Expectations of Reporting Analyst by the On Call Team During Research / Resolution Phase

  • Clarify the Severity of the issue as requested by the On Call Team.
  • Respond to any requests for additional information, etc.
  • If the solution to the issue will require a code migration:
    • Create a PFM in ITG if requested by the On Call Team member.
    • Consult with your team lead or manager to discuss the business criticality, evaluate the available workarounds, and propose the production migration date (Note: whenever possible, the standard monthly Sunday Release Dates are preferred for all types of code changes).
  • If an emergency migration is requested (i.e. a migration on a date that is not the standard monthly Sunday Release Date):
    • work with your team lead or manager to write the business justification. Your team lead or manager should provide the business justification to the ERP Support Product Owner/Manager.
  • Close the TDX Incident at the completion of the agreed upon action(s).

Expectations of On Call Team by the Reporting Analyst During Research / Resolution Phase

  • In general, On Call items are worked on a first-in-first-out basis; the described Severity and/or negotiation between reporting team’s management and ERP Support Product management may influence the actual sequence when multiple items are open at the same time.
  • The Primary On Call team member may refer the issue to another team or may recruit assistance from team members, as needed.
  • For code changes and SQL updates, standard SDLC phases will be exercised, including build review, etc.
  • Forward progress on planned work may be affected by the volume or nature of On Call items

Request a Data Update via SQL

Oftentimes, a business analyst team has enough familiarity with an issue and/or the underlying data to know that a direct manipulation of the data in the database is necessary via SQL. The following outlines the high-level steps for initiating this "SQL Update" procedure.

  1. Create the request describing what needs to be updated in the pertinent tracking system [ITG (CS, HR, IH) or QC (FS)].
  2. Notify the On Call Team when the request is ready for their review [email (CS, HR, IH), QC (FS)].
  3. Formally approve the data update (once it reaches the appropriate stage).
  4. Verify the results.

The default timeline for the On Call Team's activities for "moderate" items is within one business day (actual complexity of each specific request will drive the actual timeline).

Note: The ITG PFM/SDLC (CS, HR, IH) or QC Defect (FS) along with the specific steps carried out by the On Call Team are collectively a requirement to satisfy controls recommended by Internal and External Audit; the team performing the update action needs to have a record of the request, the approach to meet the request, a review of the approach, the approval to carry out the approach, and its completion.

Errors Encountered in Any of the Non-Production Systems

  • Follow the same general procedure for production as outlined above, however, clearly state that the topic pertains to non-production; resolution of these items will be best effort as any open issue associated with production will have priority over any non-production issue.
  • This is general guidance for general issues discovered during day-to-day use.
  • Issues discovered in non-production during the course of a testing project (e.g. a PeopleTools Upgrade, Image) should be reported via Quality Center per the guidance provided by that project.
  • Issues discovered in non-production during the course of testing an SDLC should be reported via Quality Center and routed to the Developer associated with the SDLC.