1 / 28

Effort Certification System Implementation

Effort Certification System Implementation. Andres Chan Senior Manager, University of Southern California & Jason Jacobs Senior Manager, Attain. Agenda. Overview of Effort Reporting System Implementation Life-cycle Business Requirement/Proposed Solution

rufina
Download Presentation

Effort Certification System Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Effort CertificationSystem Implementation Andres Chan Senior Manager, University of Southern California & Jason Jacobs Senior Manager, Attain

  2. Agenda • Overview of Effort Reporting • System Implementation Life-cycle • Business Requirement/Proposed Solution • High Level Design (Functional Specifications) • Detailed Design (Detail Specifications) • System Configuration, Customization, Development and Testing • System Implementation • System Support and Maintenance • Future Enhancements

  3. Why do Effort Reporting? • Sponsored Research • OMB A-21 • NIH Salary Cap Requirements • Cost Sharing • Flexibility for additional regulatory requirements • Institutional Policy/Procedure Rules • Controls on Uncommitted/voluntary Cost Sharing • “Knowledgeable Person” policy based on employee being certified (exempt vs. non-exempt certifiers) • Funding source coverage for cost sharingOTC cost sharing

  4. Challenges of Effort Reporting • Cumbersome to faculty • Timeliness • Accuracy • Tracking and enforcing commitments • Enforcement of Federal requirements outlined in OMB A-21 circular • Enforcement of other institutional and state requirements • Documenting and reporting cost sharing • Amended effort reports

  5. PRE-AWARD POST-AWARD Faculty Appointments and Hiring Staff Preparing the Proposal Budget Charging Salary Certifying Effort • Employment terms are established, including # months (contract period), % full time, salary base • Effort is proposed, a commitment is made to the sponsor • Effort is charged, in a real time manner consistent with activity • Effort is monitored • Effort is attested to, after activity has occurred LEADERSHIP, POLICIES, TRAINING, SYSTEMS Business Process Integration “Effort Reporting is more than just a certification statement…” NCURA FRA-IX – New Orleans, LA – February 26, 2008

  6. Problem Areas for Research Compliance in ERP Systems • Chart of Accounts and Cost Sharing • Determining IBS across multiple jobs • Inconsistent Rate of Pay across multiple jobs • Inconsistent Rate of Pay on additional pay / overloads • Additional Pay / Overload not distinguishable as IBS • Defining FTE % accurately • Allocation of leave accruals upon termination

  7. People Review Skills, Knowledge, Support Review Workload Balancing Review Organizational Skills Full-Life Cycle Stakeholder Analysis Process Review Current Business Processes Integration of Connected Processes Review Workflow and Separation of Duties Evaluate Business Process Alternatives Technology Configuration Settings Control Settings System Integration Evaluate Technology Alternatives Holistic Approach to Projects:People, Process and Technology

  8. Implementation Phases & Activities

  9. Business Requirements and Proposed Solution • Phase where your business requirements are finalized, the software package is learned, and a solution using the package is defined to meet the business requirements.

  10. Business Requirements and Proposed Solution University Implementation Partner Defining Governance: Stakeholders, Strategic Alignment, Decisions Ensure requirements define true business need, not current solution approach Designing for full life-cycle Address requirements and issues at source Business process change in upstream and downstream systems • Identified vulnerability in current system • Advantage of systems implementation to Kuali • Pitched idea to decision makers

  11. Full Life-cycle Design:

  12. High-level Process Requirements

  13. High-level Process Requirements

  14. High Level Design – Functional Specifications • The planned solution is further clarified by functionally specifying how the system will operate.

  15. High Level Design – Functional Specifications University Implementation Partner Involvement (and buy-in) from Full life-cycle stakeholders Apply criteria based on true business need, not “how it used to be done” Consider Business Process Change (full life-cycle) when evaluating solutions Understanding limitations of system comparisons and demos • Involvement from: • Office of Financial Analysis • Office of Compliance • Systems Implementation Team • Campus Community Representatives • Team provided wish-list items • Positive/Negative functionalization items • Team compared wish-list items to Workday EC & Kuali EC (alternative was to also go with vendors)

  16. Detail Design – Detail Specifications • Detailed design specifications are developed (e.g., table values are defined, specifications as to exactly how reports will look and work are developed, etc.)

  17. Detail Design – Detail Specifications University Implementation Partner Challenges of business process and system changes in up-stream and down-stream systems Designing for future state while within the current state Considering all real-world business scenarios (devil is in the details) • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Other system owners • Identified various modules needed for implementation • Modules: Integration from payroll, Salary Expense Transfer, Cost Sharing, User Interphase, etc.

  18. System Configuration, Customization, Development and Testing • The system is “programmed” by setting up its parameters and tables with the values defined in the previous phases. Interfaces, data conversion and customized programming are also done in this phase. Quality assurance (systems and user testing) is done here

  19. System Configuration, Customization, Development and Testing University Implementation Partner Scripting full life-cycle scenarios (inputs, direct processes, and outputs) Avoiding pitfalls of staged data and invalid variation on scenarios The right skills, tools and participants – they are different from the design phase • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Other system owners • Very tedious work • Develop very intimate/in-depth knowledge of new system/payroll inter-workings • Challenging due to moving target

  20. System Configuration, Customization, Development and Testing (cont.) University Implementation Partner Calling on Governance model and effective decisions documentation from earlier phases Re-designing when things don’t work out Having a contingency plan • Development and testing • Will our wish-list items make the cut? • Are we talking the same language? • Are promises being broken? • Keep notes, notes, and more notes on what is promised by development team. • Expect to get push back on some items

  21. System Implementation • The system is implemented and operations are converted to the new system.

  22. System Implementation University Implementation Partner Clearly define and tested cut-over strategy, plan and schedule Having a contingency plan Understanding Change Management – it’s not just training and communication • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Other system owners • Very tedious work • Develop very intimate/in-depth knowledge of new system/payroll inter-workings • Challenging due to moving target

  23. Integration of project management and change management Solution is designed, developed and delivered effectively(Technical side) + Solution is embraced, adopted and utilized effectively(People side) = SUCCESS Complimentary disciplines with a common objective

  24. Who “does” change management? Each ‘gear’ plays a specific role based on how they are related to organizational change

  25. Common Problems Possible Tactics Change Management with ER System Projects Poorly aligned Stakeholder Groups Multiple business process changes at once – Appointment and Payroll Management, Commitment Enforcement, on-line certification System enforces rule that were never system enforced Payroll / Effort is not right; “I’m getting errors!” Properly Defined, Managed and Executed Governance Well designed and clearly communicated business processes; advance communication; coordination of training topics; cut-over approach Training on institutional and regulatory guidelines and audit risks Evaluate upstream business processes to correct data before this stage

  26. System Support and Maintenance • The post implementation phase where the system is turned over to the normal support and maintenance process.

  27. System Support and Maintenance University Implementation Partner Production Support Strategy It shouldn’t begin here! Knowledge Transfer Plan Realistic Support Cut-over Strategy Celebrate! Roadmap and Plan for the Enhancements – Make sure Phase 2 Arrives • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Payroll Office • Different team members due to changing from in-house payroll to cloud system in Workday

  28. Where Others have Gone: Turning a Negative into a PositiveFull Life-Cycle Faculty Workload Management

More Related