Docstoc

Functional Design Template - DOC - DOC

Document Sample
Functional Design Template - DOC - DOC Powered By Docstoc
					Functional Design                                                                                                Printed: 11/14/10



Grants Workflow
FUNCTIONAL DESIGN DOCUMENT
Release:        8.9

Product:        PeopleSoft Grants



Document Information
Document Participants

        Author:            Yan Wu

        Contributors:      Barry Hickson, Elise Koo

        Reviewers:         Barry Hickson, Julie Gustafson, Elise Koo, Fei Lin, John Fitasimmons, Ashraf Morcos

        Approvers:         Barry Hickson, Julie Gustafson, Ashraf Morcos


Revision History

 Version Date         Change Summary
 24-Jan-2004          Initial Creation of FDD
 17-FEB-2004          Incorporate Barry Hickson‟s comment
 19-FEB-2004          Incorporate Barry Hickson‟s comment
 25-FEB-2004          Incorporate Barry Hickson‟s comment
 27-FEB-2004          Incorporate comments from review section
 05-MAR-2004          Incorporate comments from Ashraf Morcos. Changes in section 1.5, 2.1.12, 2.2.2.1
 19-MAR-2004          Add sample data
 08-ARP-2004          Incorporate comments from TDD review section
 28-Jun-2004          Incorporate new requirements/Changes from Sales; Creating a configurable/flexible workflow
                      rules for Grants Component approval process.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc           PeopleSoft Proprietary and Confidential                                     1
Functional Design                                                                                                                                                         Printed: 11/14/10


                                                                                Table of Contents

1. FEATURE OVERVIEW ....................................................................................................................................................... 4
   1.1     PROBLEM/NEED STATEMENT........................................................................................................................................ 4
   1.2     HIGH LEVEL FEATURE DESCRIPTION ............................................................................................................................ 4
   1.3 ASSUMPTIONS ..................................................................................................................................................................... 4
      1.3.1      Applications Installed ......................................................................................................................................... 4
      1.3.2     Design Assumptions ............................................................................................................................................. 4
   1.4 FEATURE DEPENDENCIES .................................................................................................................................................... 5
   1.5 SCOPE ................................................................................................................................................................................. 5
      Features in scope ................................................................................................................................................................. 5
      Features out of scope ........................................................................................................................................................... 5
   1.6 FEATURES FOR FUTURE RELEASES ..................................................................................................................................... 5
   1.7 DESIGN VALIDATION APPROACH ........................................................................................................................................ 5
   1.8 RELATED DOCUMENTS ....................................................................................................................................................... 5
      Requirement Source ............................................................................................................................................................. 5
      Other Documents ................................................................................................................................................................. 6
   1.9 GLOSSARY .......................................................................................................................................................................... 6
2. FEATURE DETAIL .............................................................................................................................................................. 7
   2.1 CURRENT FUNCTIONALITY ................................................................................................................................................. 7
   2.2 PROPOSED NEW FUNCTIONALITY ....................................................................................................................................... 7
      2.2.1 Common Workflow approval/notification setup component ....................................................................................... 7
        2.2.1.1 Approval/Notification Process definition/ Routing Roles ................................................................................ 7
        2.2.1.2 Approval Rules/Detail.................................................................................................................................... 10
        2.2.1.3 Approval Criteria ........................................................................................................................................... 11
      2.2.2 Milestone due Notification ........................................................................................................................................ 14
        2.2.2.1 Milestone Notification detail processes ......................................................................................................... 15
      2.2.3     Proposal Status Notification .............................................................................................................................. 18
        2.2.3.1 Proposal Status Notification detail processes ................................................................................................. 18
      2.2.4     Proposal (Component) approval process .......................................................................................................... 18
        2.2.4.1 Proposal (Component) Approval Detail Processes .......................................................................................... 18
   2.3 ROLES, USE CASES AND TASK ANALYSIS ......................................................................................................................... 26
   2.4 WORKFLOW ...................................................................................................................................................................... 26
   2.5 REPORTING ....................................................................................................................................................................... 26
   2.6 ANALYTICS ....................................................................................................................................................................... 26
   2.7 BATCH PROCESSING ......................................................................................................................................................... 26
   2.8 GLOBAL/REGULATORY ..................................................................................................................................................... 27
   2.9 MULTINATIONAL/INDEPENDENT BUSINESS UNIT.............................................................................................................. 27
   2.10 INDUSTRY ....................................................................................................................................................................... 27
3. ADDITIONAL SPECIFICATIONS................................................................................................................................... 27
   3.1 PEOPLESOFT PRODUCTS IMPACTED AND INTEGRATIONS REQUIRED ................................................................................. 27
   3.2 THIRD PARTY INTEGRATION ............................................................................................................................................. 27
   3.3 PERFORMANCE ................................................................................................................................................................. 27
      Online performance ........................................................................................................................................................... 27
      Online usability metrics ..................................................................................................................................................... 27
      Batch performance............................................................................................................................................................. 27
   3.4 SECURITY SPECIFICATIONS ............................................................................................................................................... 27
   3.5 OTHER SPECIFICATIONS .................................................................................................................................................... 27
4. OTHER CONSIDERATIONS ............................................................................................................................................ 27
   4.1 SYSTEM TEST CONSIDERATIONS ....................................................................................................................................... 27
   4.2 SYSTEM DATA CONSIDERATIONS ..................................................................................................................................... 28
   4.3 SAMPLE DATA CONSIDERATIONS ..................................................................................................................................... 29
   4.4 SALES DEMO CONSIDERATIONS ........................................................................................................................................ 30
   4.5 INFORMATION DEVELOPMENT CONSIDERATIONS ............................................................................................................. 30
   4.6 UPGRADE/CONVERSION CONSIDERATIONS ....................................................................................................................... 30
   4.7 INSTALL CONSIDERATIONS ............................................................................................................................................... 30
5. MISCELLANEOUS ............................................................................................................................................................ 30
0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc                                 PeopleSoft Proprietary and Confidential                                                                          2
Functional Design                                                                                                                                                  Printed: 11/14/10

   5.1 GAPS IN PEOPLETOOLS FUNCTIONALITY .......................................................................................................................... 30
   5.2 OTHER NOTES................................................................................................................................................................... 30
6. OPEN ISSUES ..................................................................................................................................................................... 30




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc                              PeopleSoft Proprietary and Confidential                                                                     3
Functional Design                                                                                                   Printed: 11/14/10




1. Feature Overview
      1.1 Problem/Need Statement
               There is a need to provide a workflow solution that can support the business process of submitting, reviewing and
               approving Proposal components with Grants. This workflow solution is intended to help in managing the Grants
               Proposal approval process through its life cycle. In addition, we are looking to provide users the ability to
               determine more efficiently when milestones are due and to send out notification to the appropriate person(s) as
               needed.

      1.2 High Level Feature Description
              Grants Workflow Feature will comprise of the following:
                   I. Provide efficient communications between the different project roles (PI, SPO, administrator,
                      stakeholder, etc.) through all aspects of the proposal‟s life cycle. This is achieved via the creation of a
                      workflow process using worklists and email notifications.
                  II. Provide the ability to select (query) milestone(s), which will be due in the near future and to send out an
                      email notification as needed. Users can also set up a process scheduler to run this process periodically.
                 III. Customer configuration options which allow them to control properties/routing of the proposal approval
                      process
                 IV. Common Approval configuration setup within a Grants Application

      1.3 Assumptions

               1.3.1 Applications Installed
                       This FDD assumes that a customer has purchased and installed the PeopleSoft Grants application.


               1.3.2 Design Assumptions
                       Using Peopletool delivered standard workflow solutions.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc           PeopleSoft Proprietary and Confidential                                        4
Functional Design                                                                                                Printed: 11/14/10




      1.4 Feature Dependencies
                    1.4.1     Construction of Grants Proposal
                              Enhancements to Grants Application in order to support/develop/implement Grants workflow
                                      Ability to establish Grants proposal level component(s) must be implemented in order
                                          to develop/implement Grants workflow.
                                      Ability to associate an Institution, Major Subdivision, SPO office, Department Admin,
                                          Department Chairman, Department Represent to a department and automatically
                                          populate this information during Proposal Creation process.
                                      Ability to identify a personal Workflow Eligibility
                                      Ability to calculate and display total amount for each Proposal and Project in Maintain
                                          Proposal component.
                                      Ability to associate default stakeholder(s) to each component; user also will be able to
                                          input multiple stakeholders for each component.

                    1.4.2    Proposal Status
                             Current Proposal Status needs to work in tandem with the new workflow process. In order to
                             implement workflow, a clearly defined proposal cycle/status is needed.



      1.5 Scope
               Features in scope

                PT-100         Milestone Email Notification
                PT-200         Milestone Email Notification Process Scheduler
                PT-300         Proposal Status updates Email notifications
                PT-400         Proposal (Component) Approval Process
                PT-500         Approval Process at Proposal/Primary Project
                               Components and Project Components
                PT-600         Flexable/Common Workflow Rules setup at BU level


                Features out of scope

                PT-700         No external notification



    1.6 Features for Future Releases

    1.7 Design Validation Approach
            The design will be validated by internal reviews with ESA Strategists, Product Development Managers, Product
            Architects, and Developers. The intent is to have ESA Sales Support review the design as well. Design prototypes
            will be built and reviewed by the Usability group.

    1.8 Related Documents
      Requirement Source
        Location        Document ID           BRD #              Description                                  Owner


0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc            PeopleSoft Proprietary and Confidential                                    5
Functional Design                                                                                         Printed: 11/14/10




               Other Documents
        Location                                           Document ID                      Description



    1.9 Glossary

        Term                               Definition




               -




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc          PeopleSoft Proprietary and Confidential                               6
Functional Design                                                                                                      Printed: 11/14/10




      2. Feature Detail
       2.1 Current Functionality
               Workflow is not present within existing Grants releases.


      2.2 Proposed New Functionality
        The Proposed new functionality will establish an approval/notification structure, which allows the customer to manage
        their approval process more efficiently. The detail of this design document will support the capabilities outlined below:

        Functions/Processes                   Workflow            Description
        Common component to set up                                Define a common workflow setup component which provides a
        Workflow                                                  single user interface for configuring / structuring all Grant‟s
        Approval/Notification Process                             workflow processes and Rules.
        for all Grants Workflow
        solutions
        Milestone due Notification            Email               Sending reminder email notifications to group of roles (people)
                                              Notification        prior to milestone due date
                                              Only
        Proposal status Notification          Email               Sending informational email notification to group of roles
                                              Notification        (people) when Proposal status is changed.
                                              Only
        Proposal (Component)                  Worklist/Email      Generates worklist/notification requesting for approval/review
        approval process                      Notification        of a proposal/project.


               2.2.1 Common Workflow approval/notification setup component
                    Grants will be providing 5 workflow solutions in the 8.9 release. A common workflow approval/Notification
                    setup component will provide with a single user interface for configuring/structuring all Grants workflow
                    solutions. Users will define their Approval/Notification Processes at the Business unit level. This setup
                    component contains following sections:
                        Approval/Notification Process definition
                        Routing Roles
                        Approval Rules/Detail
                        Approval Criteria

                2.2.1.1 Approval/Notification Process definition/ Routing Roles




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                         7
Functional Design                                                                                                   Printed: 11/14/10




                           Business Unit – Contact /Award Business unit
                           Transaction Type – Grants provides 5 workflow solutions. We define a transaction type for each
                            workflow solution.
                                 o Proposal Component Approval
                                 o Milestone Notification
                                 o Proposal Notification
                                 o Protocol Approval Process (See detail in FDD for Protocol Management)
                                 o Protocol Committees meeting Notification (See detail in FDD for Protocol Management)
                           Workflow Type – Type of workflow function provide by the workflow transaction
                                 o Proposal Component Approval – Worklist/Email notification
                                 o Milestone Notification – Email Notifications only
                                 o Proposal Notification – Email Notification only
                           Elements – Indicate what is the key element for the workflow.
                                 o Proposal Component Approval – Component
                                 o Milestone Notification – Milestone
                                 o Proposal Notification – Proposal Status
                           Detail – A secondary page where user defines the detail information related to the current element
                            (see detail in later section)
                           Criteria – A secondary page where user defines the Criteria for the approval process. In this
                            secondary page users specify the conditions for requiring current element as part of approval process.
                            (See detail in later section)
                            Routing Rules – Indicating who will be involved and what kind of action they can perform.
                                 o Role – list of available roles. These are user-defined roles. Requires one or more roles. List
                                      of roles involve in each Transaction type maybe little different. Following are list of roles
                                      involve in Proposal (Component) approval and Proposal Status Notification.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc            PeopleSoft Proprietary and Confidential                                       8
Functional Design                                                                                                         Printed: 11/14/10




                                       Roles involving Milestone notifications are Award PI and Milestone Contact(s)
                                  o    Required – User will be required to perform actions on the task and feedback from them
                                       will affect the approval status. If a role is set as required, worklist must be generated for this
                                       role. Required at least one “Required” approval role. This field is applied to workflow type
                                       Worklist/Email only.
                                  o    Perform Action – Type of action that will be performed by the role of user. This field is
                                       applied to workflow type Worklist/Email only.
                                             Approve
                                             Review
                                  o    Workflow Action – Type of workflow that will be generated/Type of workflow user will be
                                       receiving. This field applies to workflow type Worklist/Email only.
                                             Worklist/Email
                                             Worklist only
                                             Email Notification Only
                                  o    Sequence – Order receiving the workflow. It can be setup where all roles will receive the
                                       workflow simultaneously or sequentially or a combination of both. This field applies to
                                       workflow type Worklist/Email only. For example:




                                       In this case, Role Administrator and Co-PI will receive the workflow simultaneously.
                                       Department head will receive the workflow after Administrator approves the workitem,
                                       which is sequentially. This field applies to workflow type Worklist/Email only.
0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc               PeopleSoft Proprietary and Confidential                                          9
Functional Design                                                                                                       Printed: 11/14/10

                                  o     Pool List – If this option is set then only one person from this role needs to perform an
                                        action and the workitem will be dropped from others. This field applies to workflow type
                                        Worklist/Email only. Example: if 3 people are assigned as Co-PI, 3 workitem will be
                                        generated and inserted to their worklist. As long as one Co-PI approves the component, the
                                        workitem will be dropped from the other‟s worklist.
                                  o     Reassign – check if workitem can be reassigned. This field is applied to workflow type
                                        Worklist/Email only
               2.2.1.2 Approval Rules/Detail
                       For each workflow solution, we will provide a detail section, which only includes the information that
             specific to its workflow process. User comes to this detail page by clicking on the “Detail” hyperlink.

        Functions/Processes           Workflow         Approval Rules/Detail
        Milestone due                 Email
        Notification                  Notification
                                      Only




                                                            o      Days Prior to Due Date – Number of days that user will need to
                                                                   be notified prior to milestone due day.
                                                            o      Notification Text – Comments that user would like to see on the
                                                                   email notification.
        Proposal status               Email
        Notification                  Notification
                                      Only




                                                            o      Notification Text – Comments that user would like to see on the
                                                                   email notification.
        Proposal                      Worklist/Email
        (Component)                   Notification
        approval process




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc               PeopleSoft Proprietary and Confidential                                        10
Functional Design                                                                                                   Printed: 11/14/10

                                                  .
                                                       o      Required Approval Process – Check this option if this component
                                                              is required for all proposals within current BU.
                                                       o      Notify When Status Changed – Check this options if user wants
                                                              to receive an email notification when component status is
                                                              changed.
                                                       o      Self Approval – if this option is checked then workitem will
                                                              consider as “approved” immediately if workitem generator and
                                                              receiver is the same person.
                                                       o      Approval Initiator Role – Group of people that manage/monitor
                                                              the approval process. This group of people will be responsible for
                                                              resubmitting the component in case of “send back”(component
                                                              sent back for modification by approver). Note: It is very
                                                              important to identify this role; they are the people who can edit
                                                              project/budget in case of “Send Back”. Project/Budget will be
                                                              displayed only for others during the approval process.
                                                       o      Exception Approver ID – He/she acts as exception Approver in
                                                              case we could not find the approver.

               2.2.1.3 Approval Criteria
                 This section only applies to Proposal (Component) approval workflow process. User defines the criteria that
             are required for requiring a component approval. Component will be inserted into the proposal automatically if all
             criteria are satisfied.




                      Condition ID – This is a system-generated value. User can set up one or more conditions for each
                       criterion.
                            o A criterion is considered as true if any condition is met. Current component will be inserted to
                                 the Proposal and be part of required approval path.
                            o Component will be removed from proposal if user updates the proposal and Condition is no
                                 longer met.
                            o All values within a condition must be satisfied in order to consider the condition met.
                      Component Name – Criteria editing process will be triggered in 3 peopletool components:
                       GM_PROPOSAL, GM_BUD_HEADER and GM_BUD_LINE_SUM.
                      Monetary Criteria – User can select an amount field and identify the amount limit in a specific
                       currency code and exchange rate as part of the condition.
0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc          PeopleSoft Proprietary and Confidential                                         11
Functional Design                                                                                                  Printed: 11/14/10

                                o    Amount Record – Depending on the peopletool component, user will prompt/select a record
                                     that is available within the current peopletool component. We deliver this information as
                                     system data.




                                     Note. Please Use following instruction to define system data. Set Up Financials/Supply Chain
                                      Product Related  Grants  Workflow Component
                                     Component name = GM_PROPOSAL, GM_BUD_HEADER and GM_BUD_LINES_SUM




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                     12
Functional Design                                                                                                  Printed: 11/14/10




                                o    Amount Field – Select a field that is in number/Amount format within the amount record
                                o    Currency Field – A field that contains the currency code. For example
                                     GM_PROPOSAL.CURRENCY_CD


                                o    Criteria Operation --
                                o    Amount: -- Identify the amount limit
                                o    Currency Code – The currency code for “Amount”. Example: USD
                                o    Exchange Rate type – Currency conversion will be performed if amount filed is in different
                                     Currency Code.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                     13
Functional Design                                                                                                     Printed: 11/14/10




                        Other Criteria – User can also define other non-amount criteria.
                             o Record Name – Identify the record name
                             o Field Name – Identify the filed name




                                o    Operator –
                                o    Value – Value of the filed




               2.2.2 Milestone due Notification

                    Summary of 8.9 Milestone notifications Functionality:
                       1. Users will be able to use run control searching of the milestones periodically to determine those that
                          satisfy the search conditions. The result will be a list of award milestone(s) being returned. Users will
                          then be able to trigger email notifications from the list. Email notification can be sent out for all or
                          only select award milestone(s).
                       2. Users also can set up a process scheduler to search milestones that are due on the current date and
                          send out email notifications automatically

                             The existing award milestone page will be modified to incorporate this new functionality. We will
                             keep track of the entire notification history. Users will be able to find all history from the Grants
                             Award --> page Milestone.



0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc              PeopleSoft Proprietary and Confidential                                        14
Functional Design                                                                                                      Printed: 11/14/10

                    2.2.2.1 Milestone Notification detail processes
                                 A new milestone run control page will be created. Users can use this run control page to find out
                                 a specific milestone(s) that satisfies certain conditions and decide if they would like to send out
                                 an email notification to the appropriate person(s).

                                   They can also use this page to view completed milestones but no action will be performed for
                                   these completed milestones. Notify check box will be displayed only for completed milestones

                                       1.   Run control parameter(s)
                                                 Business Unit
                                                 Milestone type
                                                 Milestone Code
                                                 Priority (New field added to Proposal Milestone record)
                                                 Milestone Due Date From
                                                 Milestone Due Date To
                                                 Notification Due in days – Milestone notification that is due within specific
                                                    days. Notification Due Date = Milestone due date – Days prior to due date
                                                 Last Notification Date From
                                                 Last Notification Date to
                                                 Milestone Completed From
                                                 Milestone Completed To


                                       2.   Return a list (Grid) of milestones that satisfies the search parameter. The list includes
                                            the following fields
                                                  Notify – Check box
                                                  Award ID -- hyperlink
                                                  Milestone type -- Display only
                                                  Milestone Code – Display only
                                                  Priority – Display only
                                                  Milestone Due date – Display only
                                                  Last Notification Date – Display only
                                                  Comments – Long text (Populated with default value in field Comment from
                                                      Milestone setup page)
                                                     Note: Users can select to send an individual milestone notification or can select
                                                     “Notify all uncompleted Milestones” to send out multiple milestone
                                                     notifications

                                3. Milestone Run Control Page
        New Milestone Run Control page:




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc               PeopleSoft Proprietary and Confidential                                       15
Functional Design                                                                                                     Printed: 11/14/10




                                       4.   Milestone Notification Activity – A business event will be trigger sending out the email
                                            notification to people who are listed as receiver in the BU workflow set for Milestone
                                            Due notification.
                                       5.   Milestone Notification Message
                                                  Subject – Milestone (value) is due on (Due date)
                                                  Note text -- Milestone (value) is due on (Due date). Please take appropriate
                                                      actions to complete this task. Click on the following Link for Detail
                                                      information (URL Link)

                                       6.   Running milestone notification from Process scheduler
                                            Users can set up a process scheduler and run milestone notifications automatically. A
                                            program is run searching for the milestones that are due on the current date and sends
                                            out email notification automatically. The parameters for running this program comes
                                            from the Millstone setup page:
                                                   Business Unit
                                                   Milestone Type




                                       7.   Milestone Notification history
                                            Maintains Milestone Notification History – Users will be able to access this
                                            information in the Award Milestone page, which includes the following information:
                                                      Notify On
                                                      From
                                                      To
                                                      Comment




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc              PeopleSoft Proprietary and Confidential                                       16
Functional Design                                                                         Printed: 11/14/10

         Milestone Notification History page:




        Modified Award Milestone Page:




                                                                                            )

0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc        PeopleSoft Proprietary and Confidential                 17
Functional Design                                                                                                     Printed: 11/14/10


           2.2.3 Proposal Status Notification
                    Summary of Proposal Status Notification Functionalities:

                    Provide a flexible email notification system that will be triggered when the proposal status is changed.
                    2.2.3.1 Proposal Status Notification detail processes
                          If the proposal status is changed and status is listed in the common workflow setup page, then an email
                          notification will be generated to the roles/person(s) listed in the workflow setup page.
                                  o Proposal Status Notification Activity – A business event will be trigger sending out the email
                                      notification to people who are listed as receiver in the Common workflow set for Proposal
                                      Status notification.
                                  o Notification Message
                                            Subject – Proposal (value) Status is Updated from (value) to (value)
                                            Note text -- Proposal (value) Status is updated from (value) to (value). Click on the
                                                following Link for Detail information (URL Link)
                                  o Notification History
                                            No History will be maintained for this transaction
           2.2.4 Proposal (Component) approval process
                    Summary of Proposal (Component) Approval Functionalities:

                    Provide an efficient workflow solution that supports the business process of submitting, reviewing and
                    approving Grants Proposal at the proposal/Primary Project component or project component level (mutually
                    exclusive). We will achieve this functionality by creating workitems and Email notifications.

                     2.2.4.1 Proposal (Component) Approval Detail Processes
                              1. Adding new page (identify Setup Level) to existing Grants Contract BU setup Component.
                                 User will use the setup page to identify the approval level. Proposal (Component) approval can
                                 be set at:
                                      Proposal/Primary Project Level – Only workflow the components that are listed in
                                            Primary Project
                                      Project Level
                                     If user selects Primary Project, then only workflow the components that are listed in the
                                     primary project, otherwise workflow all components that listed in all projects. This option
                                     can be overwritten in Grants Proposal.
                                     If user selects Primary Project but still enters components in non-primary project, user will
                                     receive a warning message, which clearly explains that the component in the non-primary
                                     project will not be part of the workflow approval process. If they want to have an
                                     approval process for non-primary project component, they need to change the proposal
                                     component level option in current proposal.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc              PeopleSoft Proprietary and Confidential                                       18
Functional Design                                                                                                     Printed: 11/14/10

        New page to identify Setup Level:




                               2.   Active/inactive Proposal (Component) workflow process at BU level.
                                    User can active/inactive Proposal (component) approval process by enter or delete the value in
                                    field Proposal status in the Grant‟s Award setup Definition page. When the proposal‟s status
                                    changes to the status that is listed in Grant‟s Award setup Definition page, an approval process
                                    will be triggered, sending workitem/email notification for multi-layer(s) approval.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc              PeopleSoft Proprietary and Confidential                                       19
Functional Design                                                                                                      Printed: 11/14/10




                               3.   Proposal Component can be added to Proposal pragmatically or manually
                                          Proposal Component will be added/deleted to each Project programmatically
                                             depending on the criterion that was set up in the “Common Workflow
                                             approval/notification Setup” section. Component will be added to the
                                             Proposal/Project if the criteria is true or deleted if proposal/project/budget is updated
                                             and criteria is no longer true.
                                          User can not delete any Proposal component that is added programmatically
                                          Can not delete any “None- Draft” Proposal Component
                                          User can also add Proposal Component(s) manually if they wish to have additional
                                             approval process. This Proposal Component(s) can be deleted as long as it is in
                                             “Draft” status.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc              PeopleSoft Proprietary and Confidential                                        20
Functional Design                                                                                            Printed: 11/14/10




                                                         Proposal Status -- “Display” only if Proposal (Component)
                                                          approval process is active
                                                         Proposal Status Date -- “Display” only field
                                                         Required Flag – Proposal will consider “Approved” if all
                                                          Required Components are “Approved”. This is a display only
                                                          field and value come from Component setup.
                                                         Stakeholders – User can enter multiple stakeholders for each
                                                          Proposal Component




                                                         Approval Hierarchy -- User can view all the roles that involve in
                                                          approval process by clicking on this hyperlink. All information in
                                                          this page is display only (cannot be modified). Information
                                                          shown in this page is viewed from “Common Workflow
                                                          approval/notification Setup” Page.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc   PeopleSoft Proprietary and Confidential                                         21
Functional Design                                                                                                  Printed: 11/14/10




                                                           Approval History – User can view the current approval process and its
                                                            history by clicking on this hyperlink.




                                                           Submit/Resubmit – This button will be active when:
                                                          1. Component Status = “Send back” and the current user has role of
                                                               Approver Initiator.
                                                          2. Ccomponents that is added after the approval workflow started.
                               4.   Associate Approval (Routing) Roles with Approver/Reviewer
                                            User will define the Routing Role(s) for Proposal (Component) Approval process
                                               routing roles in the BU level and can be viewed the in the
                                               Proposal/Component/Approval Hierarchy page.
                                            User will associate Approval Roles to a individual emplid in Proposal/Project
                                               Resource page:




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc            PeopleSoft Proprietary and Confidential                                      22
Functional Design                                                                                                 Printed: 11/14/10




                                                             An emplid must be workflow eligible to receive a workitem. If you
                                                              do not wish to be part of approval process, user can uncheck
                                                              “Workflow Eligible”. This option can be set at Professional Data
                                                              page and defaults to the Proposal/Project Professional Grid.
                                                           User can pre-define contact(s) for each department in “Department”
                                                              Set up page and will be brought into Proposal Project Professional
                                                              grid automatically. User will also be able to associate Department
                                                              with Major Subdivision, Institution, SPO office and Location in
                                                              “Department” setup page
                               5.   Approval Rules/Processes:
                                     Proposal (Component) Approval process will be triggered when the proposal‟s status
                                       changes to a status that is listed in Grant‟s Award setup Definition page. All people
                                       involved in the approval process will receive workitem, email notification or both
                                       depending on the setup options (see detail in section: Common Workflow
                                       approval/notification setup component). Note: Following Peopletool Component/pages
                                       will be un-editable during approval process: Maintain Proposal, Overall Budget and
                                       Budget Detail.
                                     Approval process can be simultaneous or sequential depending on setup. If approval
                                       process is set to sequential, workitem will be generated for next layer of approver after
                                       receiving approval from all “Required” approver(s)/Review(s). Feedback from non-
                                       required approver(s) will not affect the approval process/status. E.g.: If all required
                                       approver(s) approved the component but not the non-required approver, Component status
                                       will still be updated to “Approved” or workitem will be generated for next layer of
                                       approver.
                                     All “Required” Approval Roles must be defined in the Proposal/Project/Professional
                                       resource grid and set to workflow eligible. User can find our which role is “required” by
                                       clicking on the hyperlink “Approval Hierarchy” in Component page.
                                     Only the “Workflow Eligible” emplid will receive a workitem.
                                     Approver/Reviewer will receive Workitem, email notification or both during approval
                                       process. Here is the list of action can be taken depending on the workflow setup.
                                            o Approve
                                            o Send Back
                                            o Review
                                            o Reassign (new approver/reviewer will have same authorities as original
                                                  approver/reviewer)
                                     Component Status:
                                            o Draft
0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                    23
Functional Design                                                                                                    Printed: 11/14/10

                                               o In Progress
                                               o Approved/Reviewed
                                               o Send Back
                                          Component Status will update to “In Progress” when Workitem is sent out to the approver
                                           and waiting for action to be taken by the approver.
                                          Component Status will be “Approved” if all required approver(s)/reviewer(s)
                                           approve/review the component
                                          Component Status will be “Send Back” if any of required approver “Send Back” the
                                           Component for modification and workitem will be generated for Approver Initiator.
                                               o Project/Budget will be editable by approver initiator only when Component
                                                    status = “Send Back”
                                               o If Component Approval level is set at Project then only the Project that is
                                                    associate with the “Send back” component can be editable.
                                               o If component Approval level is set at Proposal then all Project(s) are editable by
                                                    the approver initiator.
                                               o Proposal Remains un-editable during approval cycle.
                                               o During the process of modification (By Approver Initiator), New Proposal
                                                    Component can be added/Deleted in the Project if meet some criteria or if the
                                                    criteria no longer met
                                          Proposal can be “Canceled” during the approval process. All workitem will be removed
                                           from approver worklist.
                                          Proposal is “Approved” if all Component(s) are approved.
                                          Approved/Canceled Proposals are not editable. It is the end of Proposal process.
                                          Workflow Process Flow:




                                       Proposal Component Approval Activities:
                                         1. Workitem will be generated for Approver/Review when Proposal Component is
                                             submitted for Approval.
                                         2. Workitem will be generated for Approver Initiator when Proposal Component is sent
                                             back by Approver
                                         3. Workitem will be generated for new Approver/Reviewer when Proposal Component is
                                             reassigned by Approver/Reviewer
                                         4. Email notification to all people who are involved with approval process when Proposal
                                             Component status is changed
                                       Proposal Component Approval/Review/Submit Page:
                                             Clicking on the Workitem from the worklist will bring user to an
                                             approval/Review/Submit page. In the approval page, user can approve all the
                                             component(s) that are currently assigned to him/her within a Proposal/Version. User
                                             can also come to this page though the left navigation (Proposal Proposal Component
                                             Approval)



0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc                PeopleSoft Proprietary and Confidential                                    24
Functional Design                                                                                                     Printed: 11/14/10




                                        Note: Depending on user‟s authority/role, different check box(s) will be editable in this
                                        page. E.g.: If the user is assigned to perform “Approve” action, he/she will see
                                        Approve/Send Back check box active. All others will be display only. User can also use
                                        this page to resubmit component for approval in case of “Send Back”
                                      Proposal Component Notification Message:
                                              An email notification will be generated and sent to everyone that is involved in the
                                              approval/review process (see detail in section Common Workflow
                                              approval/notification setup component).
                                                  Subject – Proposal Component (value) is ready for Approval
                                                  Note text – Proposal l Component (Value) is ready for approval by
                                                       Stakeholder (value). Click on the following Link for Detail information
                                                       (URL Link)

                                               Grants Proposal Statuses – When workflow is enabled, the proposal statuses will
                                                have to follow the deplicted flow. See diagram below.




                                           From Draft, user will manually change to Pending Approval which will then trigger the
                                           workflow process. Denied by Institution can be changed by the user, however,
                                           Institution Approved must be changed by system in the workflow approval process.
                                           Once approved, user can change the status to Submitted. Only Submitted proposals
                                           will be allowed to be generated, at which time the system will change the status to
                                           Awarded.
                                           All other statuses can be selected prior to submission. If workflow is disabled, status
                                           functionality is unchanged from 8.8. User can select any/all statuses at any time prior to
                                           submission.
                                           The superuser has authorization to change a Submitted (but ungenerated) proposal back
                                           to Not Submitted. If workflow was enabled, the proposal status will go back to
                                           Institution Approved. If workflow was disabled, the proposal status will go back to
                                           Draft, as is current functionality in 8.8.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc              PeopleSoft Proprietary and Confidential                                       25
Functional Design                                                                                              Printed: 11/14/10


2.3 Roles, Use Cases and Task Analysis
        The following is a listing of Roles that will interact with Grants Workflow to some capacity.

        Proposal PI –
             Creates, maintains and approve Grants Proposal

        SPO Contact --
            SPO office Contact

        Milestone Contact
             Milestone Contact personnel

        Stakeholder
             Responsible for Approving/Denying a Proposal/Project component


        Task Analysis:

        The following section will expand the Use Cases that were introduced in the Business Requirements document (Grants
        Workflow – document ID XXXXX) into „system specific‟ details based on the design described in Section 2.2.3

     1. Update Proposal Status (no corresponding BRD Use Case)
       Actors                 Proposal PI
       Summary                A user wants to know when proposal status is updated
       Path                       1. An authorized user navigates to Grants  Maintain Proposal,
                                  2. Select a specific page.
                                  3. User updates some information in the proposal and updates the status
       System Rules               1. Proposal PI would like to know when the proposal they maintain is changed to
                                       ensure Proposal is setup the way they envision
                                   1. When a Proposal status is changed, People who are involved in this proposal will
                                       receive an email notification so they have a chance to go into the system and review
                                       the recent changes

     2.     Component Approval Process (BRD Use Cases 1, 2, & 3)

        Actors                       Proposal PI, Proposal Sponsor and Stakeholder
        Summary                      A Proposal is ready for approval by component Stakeholder
        Path                             1. User navigates Grants  Maintain Proposal  Search
                                         2. PI updates the proposal status from “Draft” to “Pending Approval”
                                         3. Workflow process kicks off when PI saves the Proposal
                                         4. Component Stakeholder(s) receive Workitem/Email notification request for approval
                                         5. All Components(s) are approved by stakeholder(s).
        System Rules                     1. All components must be approved in order to update the proposal to “Approved.”
                                         2. Once a component is approved, it remains approved during the whole Proposal
                                             cycle.
                                         3. A “Send back” component can be submitted again for approval


2.4 Workflow
        See detail in this FDD documents.

2.5 Reporting
          No requirements identified at this time.

2.6 Analytics
          No requirements identified at this time.

2.7 Batch Processing
          No requirements identified at this time.
0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                 26
Functional Design                                                                                                          Printed: 11/14/10


2.8 Global/Regulatory
        No requirements identified at this time.

2.9 Multinational/Independent Business Unit
        No requirements identified at this time.

2.10 Industry
        No requirements identified at this time.


3. Additional Specifications
3.1 PeopleSoft Products Impacted and Integrations Required
        No requirements identified at this time.


3.2 Third Party Integration
        No requirements identified at this time

3.3 Performance
               Online performance
        Meet Peoplesoft performance standard



               Online usability metrics
        No requirements identified at this time.
               Batch performance
        No requirements identified at this time.

3.4 Security Specifications
                   No security for Workflow
                   Peoplesoft standard page security
                   Grants Security


3.5 Other Specifications
        No requirements identified at this time.


4. Other Considerations
4.1 System Test Considerations
        This section highlights some areas that should be focused on for Grants Workflow.
        Feature                              Test Emphasis
        2.1.1.2 Milestone Notification       Grants > Interactive Report > Milestone Notification > Run Control

                                                  Fill update run control parameters – Business unit, Milestone Type, Milestone Code, Days
                                                   Prior to Due date
                                                  Click on “Search” button
                                                  A list of milestones will be returned in the grid
                                                  Click “Notify All”
                                                  Put some comments to the comment box
                                                  Click “Save”
                                                  Send email notification to award PI, sponsor and milestone contact


0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                             27
Functional Design                                                                                                      Printed: 11/14/10

        Feature                            Test Emphasis

        2.2.1.2 Proposal Workflow          Grants Maintain Proposal > Select an existing Proposal

                                               Update the Proposal Status from “Draft” to “Pending Approval”
                                               Click “Save”
                                               Notify Proposal PI, Sponsor that proposal status is updated (email notification)
                                               Component Stakeholder receives Workitem/email notification requesting for approval
                                               Stakeholder accesses the approval page from his/her worklist
                                               Stakeholder approves the component
                                               All components are approved
                                               Proposal status updated to “Approved”
                                           



4.2 System Data Considerations
        No special requirements at this time.




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc          PeopleSoft Proprietary and Confidential                                            28
Functional Design                                                                                             Printed: 11/14/10



4.3 Sample Data Considerations
        See above sections for more details.

        Milestone Priority




        Component Approval Roles
                                                                   PI, Admin, SPO, stakeholder, Authorized, CO-Mentor, CO-
                                                                   PI, Dept.Head, Key Personal, Mentor, Other




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc       PeopleSoft Proprietary and Confidential                                      29
Functional Design                                                                                                     Printed: 11/14/10



4.4 Sales Demo Considerations
                   Create at least two Proposals with at least two component(s). Create at least two milestone(s) that are due in
                    the near future
                   Scenario:
                         o Update Proposal status to trigger email notification and workitem
                         o Run milestone report, send milestone email notification


4.5 Information Development Considerations
        Clearly defined Proposal Status and rules on who can update status.


4.6 Upgrade/Conversion Considerations
        No special requirements at this time.


4.7 Install Considerations
        No special requirements at this time.


5. Miscellaneous
5.1 Gaps in PeopleTools Functionality

5.2 Other Notes

6. Open Issues




0c2cb86d-5b0d-40ab-b513-e10f1c4d13c4.doc             PeopleSoft Proprietary and Confidential                                        30

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:337
posted:11/14/2010
language:English
pages:30
Description: Functional Design Template document sample