travel portal and eexpense - project proposal 1 · pmlc project proposal travel & expense...

PMLC Project Proposal Travel & Expense v1.82

Confidential

Not for release outside of The George Washington University without written permission

PMLC Project Management Life Cycle

The George Washington University Travel Portal and Electronic Expense Submission

Project Proposal

Prepared By: J. Seile / A.Donaldson

Version: 1.82

Date: October 19, 2011

Owner: Donna Ginter, Procurement

Deb Dickenson, Comptroller

Process Initiator: Jennifer Seile, BMAG

STATUS: Draft

Routing for Document Approval

Approved

Unapproved

PMLC Project Proposal Travel & Expense Proposal v1.82

Confidential Not for release outside of The George Washington University without written permission

Table of Contents Revision History ......................................................................................................................................................... 3

1 Business Needs & Objectives ............................................................................................................................ 4

1.1 Travel ......................................................................................................................................................... 4

1.2 Expense ...................................................................................................................................................... 4

2 Business Requirements ..................................................................................................................................... 4

2.1 Travel ......................................................................................................................................................... 4

2.2 Paperless Expense Reimbursements ......................................................................................................... 5

2.3 Paperless Approval Process ....................................................................................................................... 6

2.4 Paperless or Automated Journaling and PCard ......................................................................................... 6

2.5 Reporting and Notification ........................................................................................................................ 7

2.5.1 Tracking and Auditing ........................................................................................................................ 7

2.5.2 Exception Reporting .......................................................................................................................... 7

2.6 System Requirements ................................................................................................................................ 7

2.6.1 Software Requirements ..................................................................................................................... 7

2.6.2 Security & Access ............................................................................................................................... 8

3 Process Flows .................................................................................................................................................... 8

3.1 Existing Process Flow ................................................................................................................................. 8

3.1.1 Travel Booking ................................................................................................................................... 8

3.1.2 PCard ................................................................................................................................................. 8

3.1.3 Expense Reporting ........................................................................................................................... 10

3.2 Planned Process Flow .............................................................................................................................. 12

3.2.1 Travel ............................................................................................................................................... 12

3.2.2 PCard and Expense Reporting ......................................................................................................... 12

4 Proposed Solution Overview ........................................................................................................................... 15

4.1 Description of Proposed Solution ............................................................................................................ 15

4.1.1 Travel ............................................................................................................................................... 15

4.1.2 Expense ............................................................................................................................................ 16

4.2 Hardware, Software and Process Additions or Modifications ................................................................ 17

4.2.1 Hardware ......................................................................................................................................... 17

4.2.2 Software .......................................................................................................................................... 18

4.2.3 Process ............................................................................................................................................. 18

4.3 Proposed Milestones & Major Activities ................................................................................................. 19

4.4 Organizational Resource Requirements .................................................................................................. 21

4.5 Assumptions, Risks & Exclusions ............................................................................................................. 23

4.5.1 Assumptions .................................................................................................................................... 23

4.5.2 Risks ................................................................................................................................................. 23



4.5.3 Exclusions ........................................................................................................................................ 24

5 Funding ............................................................................................................................................................ 24

5.1 eExpense Funding Requirements & Source of Funding .......................................................................... 24

5.2 Travel Portal Funding Requirements, Source of Funding and Savings .................................................... 25

6 Business Case ................................................................................................................................................... 25

6.1 Cost Benefit Analysis ............................................................................................................................... 25

6.1.1 Travel Portal Savings Potential ........................................................................................................ 25

6.1.2 Total Net Present Value (NPV) of eExpense & Travel Portal Implementation ................................ 26

6.2 Qualitative Benefits ................................................................................................................................. 26

6.3 Quantitative Benefits ............................................................................................................................... 26

6.4 Comparative Analysis .............................................................................................................................. 27

7 Approval .......................................................................................................................................................... 28

Appendix A – Related Documents ........................................................................................................................... 29

Appendix B – Glossary ............................................................................................................................................. 30

Revision History

Version Number

Date Author Notes

1.7 9/30/11 J.Seile Reviewed at Proposal Gate Review

1.8 10/7/11 A.Donaldson Updated for approval routing:‐ Milestone Table modified w/ updated dates ‐ Timeline graphics updated to account for projected 10/19/11 project kickoff ‐ Funding (5.1 & 5.2) updated by J.Seile

1.81 10/10/11 A.Donaldson Section 5‐ Updated NPV table to reflect pCard Rebate Offset Section 2 ‐ Removed “*” located at the end of several requirements after consulting with D.Ginter. Could not locate in previous documents any explanation of these.

1.82 10/14/11 A.Donaldson Section 4‐ Updated eExpense timeline per Executive Sponsor D.Lawlor request to reflect 57 weeks from contract execution with Concur in support October 2012 user availability of eExpense as committed to EVPT L.Katz. Section 5 ‐ Edited and revamped to include financials as approved by EVPT L.Katz, separating out eExpense & Travel Portal. Section 6 ‐ Moved business case portion of Section 5 to Section 6, as this section is more appropriate for this information.



1 Business Needs & Objectives

1.1 Travel GW’s current travel process is decentralized and doesn’t take full advantage of possible cost savings opportunities based on the volume of travel spend. As one of the building blocks to strategic sourcing, this project seeks to implement a streamlined travel arrangement process which leverages current annual spend of between $6 and $10 million annually on faculty and staff domestic and international travel, based on 2010 non‐research charges to travel‐related accounts.

A GW travel portal seeks to:

Lower travel costs.

Provide an enhanced end‐user experience

Take advantage of state‐of‐the‐art technology in the field of travel services.

Improve information management.

Monitor and control spend.

Allow ability to audit and monitor compliance with University travel policies.

1.2 Expense The objective of Electronic Expense is to implement a third party software as a service expense management solution which will automate and simplify expense report submissions, approval workflows, and tracking. The Expense solution seeks to:

Achieve paperless expense reimbursements, approvals and journaling.

Reduce expense processing time and transaction costs.

Reduce the amount of time and effort required to submit, approve, process and pay expense reports.

Integrate PCard processing with automated pre‐population of expense reports with PCard transactions to eliminate manual processes and “yellow envelopes”

Accommodate and automate enforcement of existing and future University‐wide expense policies and rules allowing support staff to focus on value‐added activities including auditing and monitoring of compliance with policies.

2 Business Requirements

2.1 Travel 2.1.1 The system shall be usable for booking of domestic and international flights and rail or

other transportation, hotels and car rental services individually or through a consolidator.

2.1.2 The system shall offer 24‐hour emergency service.

2.1.3 The ability to contact a live travel agent to assist travelers without online booking availability is required.

2.1.4 GW’s existing and future travel rules shall be able to be accommodated by the system.

2.1.5 The vendor shall offer travel rebates or other incentives to demonstrate cost savings as part of GW’s strategic sourcing project.

2.1.6 While the system shall be primarily for faculty and staff traveling on University business, it should include options for students and for personal travel wherein GW would also benefit from rebates in subsequent phases.



2.1.7 Travelers or travel arrangers shall have the ability to easily create profiles and make simple or complex reservations.

2.1.8 Travel manager (or designated system administrator) shall be able to create or modify the tool to support GW’s travel policy as it exists and as it may change in the future.

2.2 Paperless Expense Reimbursements

2.2.1 The system shall include a user‐friendly, easily accessible and intuitive input screen for GW users to enter and manage expense data for travel and non‐travel related expenses.

2.2.2 The system shall accommodate searchable, individual expense report transaction number.

2.2.3 The system shall accommodate the following methods of data to populate the expense report without duplication:

2.2.3.1 System shall allow for manual data entry, excel upload or similar interfaces.

2.2.3.2 The ability to import and export electronic receipts to and from the travel portal.

2.2.3.3 The ability to import PCard data to populate the expense report.

2.2.3.4 The ability for users to attach receipts or other supporting documentation to their expense report.

2.2.3.5 The ability for users to manually enter data into their report to include:

User text fields

GW‐defined pick‐lists

2.2.4 System shall support the capability of allowing delegates to enter data and upload documents.

2.2.4.1 Delegates may not serve as approvers for the expense report they enter.

2.2.5 The system shall allow for reporting P‐Card and non‐P‐Card expenses on the same report.

2.2.6 GW shall continue to provide a process for submitting manual expense report reimbursements for process exceptions.

2.2.7 The system shall allow for notification to users, approvers and A/P when a transaction is suspected of violating University policies.

2.2.8 The system shall allow end users the ability to select appropriate G/L account codes, organization, fund and award from a drop‐down menu.

2.2.9 The system shall allow the ability to default GL account codes for defined expense categories.

2.2.10 The system shall provide the ability to limit the GL account codes to only those allowed on specific organizations/awards.

2.2.11 The system shall determine “appropriate” account codes based on the organization / award that the user is allowed to in EAS.

2.2.12 The system shall allow for minimum thresholds for requiring attachments.

2.2.13 The system shall not allow an expense report to be submitted without appropriate attachments.



2.2.14 The system shall have the ability for users to request and receive travel advances and for those advances to be applied to the individual’s expense report.

2.2.15 System shall accommodate interfaces from mobile applications.

2.2.16 System shall allow ability to capture expenses offline.

2.3 Paperless Approval Process

2.3.1 The system shall allow for pre‐ and post‐ expense approvals.

2.3.2 The system shall identify, based on GW’s policy and grants rules, the allowability of an expense.

2.3.3 The system shall identify, based on GW’s policy and grants rules, when pre‐approval is required and route appropriately.

2.3.4 The system shall have the ability to include customizable required and informational messages and disclaimers.

2.3.5 Initially, the system shall allow for user manual entry of “next in line” approver e‐mail address and support a variety of messaging options for various approvers or adopt existing procurement workflow approval matrix.

2.3.6 The system shall demonstrate flexibility to accommodate the future automation of GW’s current and/or future unique approval workflow structure to include divisions, departments, schools and research workflows.

2.3.6.1 The system shall demonstrate flexibility for different workflows with multiple levels (minimum 3) of approvers based on expense category and type of transaction or expenditure type and/or cost center.

2.4 Paperless or Automated Journaling and PCard

2.4.1 The system shall accommodate allocation of expenses based on GW’s general ledger and grants via Accounts Payable processes to include integration of account code and budget checking. The users will perform the necessary allocation to the appropriate account/org/fund/award from within the application, not once the activity has been interfaced into AP.

2.4.2 The system shall interface into Oracle AP via a standard AP interface.

2.4.3 The system shall allow for posting a payment voucher without intervention by mapping transactions types to predefined accounting strings to eliminate additional keystrokes.

2.4.4 The system shall accommodate the ability to support GW‐established audit rules.

2.4.5 The system shall provide accounts payable personnel with the ability to enter and track comments on individual expense reports in order to document an audit trail.

2.4.6 The system shall be manageable by existing A/P, PCard, FSS and IT staff and not require additional staff resources.

2.4.7 The system shall have the ability to identify individual vendors associated with PCard transactions and compare against GW’s policy engine.

2.4.8 The system shall associate data transmitted from the credit card company with individuals’ expenses.



2.5 Reporting and Notification

2.5.1 Tracking and Auditing

2.5.1.1 Ability to track usage.

2.5.1.2 Ability to support appropriate internal and external audits.

2.5.1.3 Ability for user to search past expense records.

2.5.1.4 Ability for procurement staff to perform PCard reconciliation.

2.5.1.5 Flexibility to select expense reports by categories and/or individuals for audit purposes.

2.5.1.6 Ability of individuals in the approval stream to see details about the expenses they are approving.

2.5.1.7 Ability for department managers, whether or not in approval stream, to run reports on expenditures within account streams for which they are responsible.

2.5.1.8 Ability of system to allow for individual audits based on means of payment (i.e. support PCard audits).

2.5.2 Exception Reporting

2.5.2.1 Ability to identify users who submit expenses outside of GW policy.

2.5.2.2 Ability of the system to determine policy validation based on established audit policies.

2.5.2.3 Ability to support 990 reporting and future government‐required reporting.

2.6 System Requirements

2.6.1 Software Requirements

2.6.1.1 The system shall store the following data on behalf of the user:

The user’s LDAP

The user’s GWID from Banner

The user’s Oracle Supplier ID

The user’s PCard information.

2.6.1.2 The system shall tightly integrate with GW’s Oracle financial system (version 12.1.2), specifically with the AP, GA and GL modules.

2.6.1.3 Shall include integration with supplier tables.

2.6.1.4 Shall include integration via APIs.

2.6.1.5 The system shall accommodate common data/flat files from the credit card company associated with PCard.

2.6.1.6 The system shall allow for availability of a test/development environment.

2.6.1.7 The system shall include a defined process to deliver and test new releases.

2.6.1.8 The system shall support real‐time funds checking.



2.6.1.9 The system shall support batch uploads of data in conjunction with real‐time data transfer between the system and GW’s chart of accounts.

2.6.1.10 The system shall allow for distribution of individual expenses to multiple cost centers.

2.6.1.11 The system shall support creation of all uses as suppliers via one integration point.

2.6.2 Security & Access

2.6.2.1 The system shall allow access initially to GW employees (staff and faculty). The ability to allow access to students, contractors and other vendors is necessary as a subsequent phase of this project.

2.6.2.2 The system shall meet GW’s security coding standards as outlined in the GW Division of IT Security Coding Standards document.

2.6.2.3 The system shall allow GW staff and faculty to securely access expense reporting system from on‐ and off‐campus locations as well as via mobile technology.

3 Process Flows

3.1 Existing Process Flow

3.1.1 Travel Booking As per current policy, “GW recommends use of its preferred travel agencies to assist with air, rail, hotel, and car rental arrangements,” but relatively few GW travelers make use of the preferred agency. The travel process is currently decentralized and largely individually managed.

3.1.2 PCard It is important to note that the PCard business processes involve 4 individual business processes; the JP Morgan/Chase (JPM) invoice, the bi‐weekly reallocation process, the billing cycle process and the zero dollar check process.

PCard user is responsible for: 1. Ensuring that the purchase is not restricted by any GW policy 2. Ensuring necessary approvals have been obtained. 3. Gathering and retaining all required supporting documentation for each transaction. 4. Within the next ten days, logging on to Pathway to allocate charges to the proper Oracle

account and alias immediately following the end of each billing cycle, reviewing PCard statement for accuracy, attaching all supporting documentation, and forward to the Procurement PCard team in yellow envelope.

In the JPM banking system:

1. A PCard holder makes a purchase and the charge is defaulted to a natural account 54154

and the Cardholder’s “home” organization alias.

2. On a 2 week schedule the cardholder enters the banking system interface (Pathway) to “re‐

allocate” the charges from 54154 and the cardholder “home” alias or organization to a more

appropriate natural account and alias for the transaction.

3. Weekly a JPM invoice is processed for payment.

a. This invoice includes all charges on GW PCards regardless of whether the cardholder

has “re‐allocated” the charges or not.



i. The expenditure account debited to post this invoice is 54154 and alias,

while the credit is posted to the AP account.

b. A payment is issued to JPM that debits the AP account and credits the cash account.

4. Every 2 weeks a file is pulled in from the JPM banking system by the PCard team.

a. All transactions with approved coding (defined by GW as a valid natural account and

alias combination authorized in EAS Oracle) are posted to the AP module, debiting

the expense codes (natural accounts and alias) and crediting the AP account.

b. These transactions have a transaction number assigned to them by the banking

system.

c. A unique invoice number (sequential order) is assigned to these transactions by the

EAS Oracle interface.

d. The information posted for each transaction is as follows:

i. Creation date

ii. Payee – JP Morgan

iii. Invoice Number – created by interface

iv. Invoice description – supplier / cardholder/traveler’s name

v. Amount

e. Any transactions without a valid coding are held in the EAS Oracle interface table

until “cleared” by the PCard team. The PCard team will review the transaction and

the coding, make necessary adjustments and order an EAS update process to post

these newly cleared transactions.

f. Once all of the “held” transactions per (e) above are “cleared”, a “$ Zero” payment

request is created (also referred to as a negative invoice or credit memo) by the

PCard team that debits the AP account for all of the detail transactions and credits

natural account 54154 with alias (offsetting # 3b).

Figure 1 – Current P‐Card Transaction Flowchart



Figure 2 – Current T‐Accounts P Card Accounting

3.1.3 Expense Reporting The University currently utilizes two forms of travel and entertainment expense reporting: a manual process involving strictly paper filings and a GW developed EAS on line reporting portal for travel related expenses. The latter is a feed to AP for review and posting, but also involves printing the expense report for departmental approval and submitting the forms to AP for review versus the system fed information.

If the expenses are not travel or entertainment related, a payment request form is completed:

1. The employee attaches supporting documentation for the expenses included on this payment request.

2. The employee signs the payment request. 3. The employee forwards all documents to his or her department head or finance

representative responsible for approving the payment request. 4. Approved payment requests are forwarded to the AP department for entry into the Oracle AP

module and remittance to the employee. 5. The AP staff will validate the employee’s supplier record is correct in the system or submit

necessary changes to the Supplier Maintenance team for correction. 6. The AP staff will review the accounting information provided and contact the department to

resolve any missing or inconsistent information. 7. The transactions are manually keyed into the Oracle AP module. 8. The Oracle system validates the accounting information. 9. Three times each week AP prepares and mails checks for expense reimbursement payments

OR electronic payments are transmitted to PNC daily for distribution to the employees /payees.

If the expenses are travel and entertainment related, the current online expense reporting portal is used:



1. The employee logs onto the GWU EAS website by entering their GWU Username and their password.

2. The employee chooses EAS Forms and then Accounts Payable. Finally the employee chooses Online Travel and Expense Reimbursement.

3. The employee is prompted to: a. Add an itinerary – describe the expenses. b. Enter expenses. c. Charge the expenses.

4. Once the employee has completed the above they are prompted to print the report and submit it for departmental approval.

5. The employee submits the printed report and all supporting documentation for approval. 6. Once the approval is received the employee will forward all documents to the Accounts

Payable for posting and remittance to the employee. 7. When doing so the employee must return to the EAS website and submit the expense

itinerary electronically to AP in addition to the manual paper submission. 8. The AP staff will validate the employee’s supplier record is correct in the system or submit

necessary changes to the Supplier Maintenance team for correction. 9. The AP staff will validate that the employee has “submitted” the itinerary and expense report

from the EAS portal. AP will contact the employee if they have failed to do so. Failure to do so makes AP unable to load the expense report into the AP module for remittance.

10. Once the AP staff has validated the manual paper submission and the corresponding electronic submission, the T&E interface is run in EAS. This process posts the expense report to the AP module and GL.

Note – for Tax reporting purposes a full audit of the expenses is performed and is required for expense reimbursement that:

Are greater than $5,000.

Are submitted by a disqualified individual as defined by the tax code.

Figure 3 – Current Expense Reporting Flowchart



Payment of Expense Reports

Three times each week AP prepares and mails checks for expense reimbursement payments OR electronic payments are transmitted to PNC daily for distribution to the employees /payees.

3.2 Planned Process Flow

3.2.1 Travel Users will log into the Travel Portal via Single Sign On through the GW Portal page.

The Travel Portal will be branded “iBuy Travel” and users will access information about GW’s travel program through a revamped iBuy Central page.

The online booking tool is meant to be the primary and preferred source for employee plane and rail tickets, rental cars and hotel booking

Group booking, meeting planning and athletic travel support will also be provided however, this will be a telephone service transaction and require a higher fee.

Travel transaction entered into or ordered via the travel portal would be settled at the time of booking using the travelers PCard or a personal credit card to secure the travel arrangements.

3.2.2 PCard and Expense Reporting The implementation of an E‐expense reporting system affords GW the opportunity to consolidate its business processes from 6 (4 PCard and 2 Expense reporting) to 2 (The JPM payment process and the expense reporting process). A third process of manual payment requests would remain to accommodate GW staff that do not adopt the tool as the standard practice, and students and other non‐employees.

Transactions will be accepted from:

The travel portal,

The JPM system

Manually entered directly into the expense reporting tool.

The system will store E‐Receipts from suppliers that provide such documents, as well as accept receipts scanned and submitted, or faxed or emailed by the employee. These receipts are automatically loaded into the employee’s expense reporting module for subsequent attachment to the expense report.

PCard and non‐PCard transactions will now be reconciled on a single expense report with JPM transactions populated via an interface.

All transaction not settled by PCard (mileage for business use, cash purchases or business purchases settled with a personal credit card) are manually entered into the system.

Periodically, the employee will enter the expense reporting system and create an expense report. Our initial training plan includes establishing a biweekly or monthly expense reporting process. There is no automated control however, to restrict the employee from submitting an expense report each day or each week.

The employee selects the expenses they wish to submit from those in their queue. The system will provide suggested GL coding based on the employee’s home department and the type of expense incurred. The employee will:



Verify the coding is appropriate for the expense item

Change the coding if necessary

Attach electronic or imaged receipts

Submit the expense report for approval

An interface will be developed between the expense system and Oracle to allow GW to verify the natural account code and organization selected by the employee are a valid combination in Oracle and that sufficient funding exists for the purchase.

A workflow may be developed to move the submitted expense report to the appropriate approving personnel, or employees will be asked to identify their next‐in‐line approver. Once approved the expense report is ready to be selected for interface into Oracle.

It is currently planned that AP staff will create the interface selection in audit mode on a daily basis.

The AP staff can:

Select all for interfacing

Select certain reports for audit purposes. This must be done and the audit must be complete before the report is selected for interface purposes.

Select only those reports it wishes to interface.

Having the approval and auditing process in the workflow prior to expense posting and payment will provide a significant advantage over the current processes. Audit selections will be based on policy violations or other criteria established by GW. Expense reports fitting the criteria would be flagged for the AP staff to eliminate auditing 100% of the expense reports.

Interfaced information will mirror current requirements including:

Employee Name

Unique report identifier – invoice number

Date

Amount to be reimbursed – for the AP module

Description for line item – We may consider adding JPM if the line item was settled via the P‐Card.

Natural Account and Oracle Alias and amount for each transaction (detail) including PTA if applicable.

Once the expense reports are selected or audited and selected, an interface developed between the expense system and Oracle will post the transactions to the AP module.

The current schedule of reimbursing employee expense reports (3 days per week) can remain the same.



Figure 4 – Planned Expense Reimbursement Process

Below is a proposed accounting from transactions from the concur expense reporting system. The benefit is that the current Zero dollar check transaction can be eliminated. All JPM subtotals will be coded to account 54154 as a credit. There is no reason to post the credit side of these transactions to the AP trial balance, as a payment for these transactions will never be made. This process is dependent on upgrading to Payment Net 4 PCard interface, expected to happen in November/December 2011. The current weekly process of invoicing/payment to JPM will continue unchanged.

Figure 5 – Planned T‐Accounts P‐Card Accounting



There are several areas that require additional time to develop the business processes:

Advances – Employees that do not use the full advance currently return the unused portion with their PCard yellow envelope or with their paper expense report. The team proposes to explore the use of PCards only for advances. Athletics will be particularly impacted by any change to advance payment policy or process.

Un‐reported PCard transactions – Currently the PCard team posts all PCard transactions to the GL once the natural account and organization combination is verified. Unreported or un‐reallocated PCard transactions are posted to 54154. Subsequent reallocation must be done via a manual DCF form. The new process envisions PCard transactions will not be posted to the GL unless submitted via an expense report. Periodically (at least quarterly) we would like to be able to post unreported PCard transactions and remove them from the employee’s queue. Concur does not provide for this situation. To a lesser extent this same issue applies to non‐PCard expenses as well.

Personal use of the travel portal – Employees will be able to book online personal travel via the travel portal and settle these with personal credit cards. This provides GW with a rebate for non‐business travel. However, these expenses would remain in the employee queue until submitted on an expense report. This possibility will be explored as a subsequent phase of this project.

The above process provides the following benefits:

Consolidates multiple segregated processes into 2 automated integrated processes.

Places the audit and approval function on‐line and in line prior to the GL posting and reimbursement process.

Consolidates the audit function into 1 team. Currently the audit function for PCard transactions and expense reports are segregated between Procurement and AP.

Finally, a unique identification number will be assigned to each expense report making it searchable for approvers, AP, and school finance representatives when needed.

4 Proposed Solution Overview

4.1 Description of Proposed Solution

4.1.1 Travel In an effort to develop or enhance cost savings, compliance and convenience, the Procurement department is charged with implementing a central, easy to use University‐specific gateway for travel, accommodations, and ground transportation reservations. It proposes to do so by contracting with American Express Business Travel using Concur/Cliqbook technology as the online booking tool (OBT). By partnering with American Express Business Travel, GW will be assured of lower rates and volume discounts as well as consistent booking fees. Traveler support will be provided 24/7 by American Express Business Travel.

Travel booked through Concur/Cliqbook, or directly with American Express Business Travel (complex travel arrangements) will be fed directly into Concur Expense for electronic processing of expense and PCard reports.

GW travelers will utilize PCards to purchase travel through this system. This project should serve as a basis for, and building block toward a realignment of travel management at GW. The solution should align with the goals of GW’s strategic sourcing initiative. This scope of this project includes:



4.1.1.1 FrontEnd User Improvements: End‐user functionality is a key driver in selection of Concur Travel & Expense.

The project assumes implementation of a GW‐branded, Procurement created, online travel portal/webpage containing travel information. Coupled with American Express Business Travel, this will allow our travelers to obtain travel policy and procedure information and manage their own travel online. In doing so, they should be able to capture the lowest price available or receive a rebate on tickets purchased. Specifically, the solution will:

o Be usable for booking of domestic and international flights and rail or other transportation, hotels and car rental services individually or through a consolidator.

o Offer a lowest price guarantee which is measurable and easy to administer o Offer 24‐hour emergency service o Feature the ability to contact a live travel agent to assist travelers without online

booking availability o Offer the ability to build in existing travel rules o Offer travel rebates or other incentives to demonstrate cost savings as part of GW’s

strategic sourcing project o Be primarily for faculty and staff traveling on University business, but should include

options for students and for personal travel wherein GW would also benefit from rebates etc.

o Offer options for inbound travelers (visitors to GW)

4.1.1.2 Reporting: The solution allows for significant personalization based on GW’s policy and audit rules and

allows for future adjustment of these rules by a GW staff member or members to be trained on administration of the system. The project team will be required to spend significant time prior to implementation determining the manner in which policies and procedures will be applied within the system.

Cliqbook/Concur through American Express Business Travel provides GW with a better tracking/reporting mechanism for identifying and analyzing travel patterns and user expenditures. This can be used to implement further cost‐savings measures in the future.

4.1.2 Expense Concur Expense allows for a seamless integration with the proposed Travel Portal solution with data collected at the time of travel booking and through the travels of the user pre‐populating expense reports. Non‐travelers who are required to submit expense reports are also able to easily navigate the system. Concur Expense allows for closer‐to‐paperless end‐to‐end processing, offering a fax‐ or email‐to‐report option for those users without access to electronic versions of receipts. This scope of this project includes:

4.1.2.1 FrontEnd User Improvements: End‐user functionality and ease‐of‐use is the primary driver in selection of Concur Travel &

Expense.

User log‐in will be through the travel portal, and leverage the access path with validation for eligible GW community members, “Initial Load” database, and ongoing recurring feeds that validate eligibility to use the Concur system already developed for the travel portal.

The Concur Expense interface is intuitive and user‐friendly whether or not the expense is travel related and has been recognized as an industry leader in providing easy‐to‐use travel and expense solutions. Personalized messaging and pop‐up reminder screens are available in key locations.



4.1.2.2 PCard: The solution provides a mechanism for users to access expense data from PCard and travel as

well as enter data for other expenses along with the ability to upload supporting documentation. This will require integration of a PCard flat file feed from JP Morgan to capture line‐item expenses charged by PCard users (directly to Concur). The E‐Expense solution will eliminate the need for separate PCard reporting on behalf of users via the yellow envelopes and, accompanied by an evaluation of auditing procedures, allow PCard staff to move toward a paperless model of operations.

Proposal is to default to home orgs/alias and to natural account, not to 54154.

4.1.2.3 Allocation & Validation: Users will perform the necessary allocation to the appropriate account/org/fund/award from

within the application, before the activity has been interfaced into AP.

4.1.2.4 Reporting & Auditing: The Concur Expense solution allows for significant personalization based on GW’s policy and

audit rules and allows for future adjustment of these rules by a GW staff member or members to be trained on administration of the system. The project team will be required to spend significant time prior to implementation determining the manner in which policies and procedures will be applied within the system.

Accounts payable personnel will have the ability to select, review or audit any expense submitted and approved without manual intervention or paper, prior to expense report posting to the AP module or GL. Concur Expense includes a robust reporting and auditing capability that meets the stated system requirements and is sufficient to maintain appropriate A/P and PCard controls without the use of a secondary PCMS system.

4.1.2.5 Workflow: The Concur system’s workflow is configurable based on GW authorizations, but these

integrations need to be developed and maintained by GW.

Complex expense approval workflows are configurable based on GW needs at launch or as a future enhancement.

Workflow “lite” has been authorized by executive sponsors. In this scenario, the user manually enters the next‐in‐line approver. Workflow “lite”:

o Relies on user to know approver o Controls are no better or worse than today’s paper system o Fewer integrations

4.2 Hardware, Software and Process Additions or Modifications

In order to achieve stated objectives, multiple integrations to GW systems will be necessary to ensure data flow between Concur and EAS and Banner. A web service is available and will likely be necessary to accommodate the volume of GW’s expense accounts and for real‐time budgeted funds checking.

An authentication process will be necessary to ensure users are affiliated with GW (employees only at launch). Payment card information will be housed on the application and populated by the end‐user into their travel profiles, or uploaded directly from JP Morgan, not transmitted by GW.

4.2.1 Hardware Concur is a Software as a Service. No added hardware is necessary.



4.2.2 Software The current Concur technical requirements for use of their system are:

A combination of standard HTTP (80/tcp) and HTTPS (443/tcp) for communication between client Web Browsers and the Concur server farm. Pages containing sensitive data will be routed to the encrypted protocol by the application

No downloads of any kind (i.e. Java, Activex) are required.

Uses JavaScript browser script language for all browser‐side logic. Firewalls, proxies, browsers and other content‐inspection devices must allow all JavaScript from the Concur Travel & Expense and Concur Cliqbook Travel service host, concursolutions.com, without filters applied.

In certain cases, Proxy Servers and other content‐inspection devices can have a severe impact on the performance of Concur Travel & Expense and Concur Cliqbook Travel. If this is the case, it may be necessary to bypass the Proxy completely for all traffic to the Concur Travel & Expense and Concur Cliqbook Travel service host

The Concur Cliqbook application will require recurring feeds of changes to the list of eligible customers (add, deletes) from GW.

The definition of eligible customers for Phase I is not fully defined at this time.

4.2.3 Process

4.2.3.1 Changes in business processes managed by Procurement are: Rebrand travel services as iBuy travel and maintain resources to support that effort.

Redirect GW travelers to utilize the AmEx/Cliqbook booking tool for all trips.

Hire a travel manager to actively monitor GW travel activity and identify and implement policy and procedure changes to maximize travel cost savings.

Develop and manage a process to identify and redirect savings from travel to ITF.

Update Concur system configurations based on travel policy changes and audit rules.

Respond to end‐user questions about how to use the system (contribute to and publicize training materials and other communications).

In partnership with Procurement, respond to end‐user questions about how to use the .system (customer support functions, contribute to and publicize training materials and other communications).

PCard and A/P to consolidate audit functions.

PCard no longer reliant on 100% audit of paper forms.

No more yellow envelopes.

4.2.3.2 Changes in business processes to be managed by A/P are: Review and audit Concur expense reports.

Manually process non‐employee expense reports.

Update Concur system configurations based on expense policy changes and audit rules.

In partnership with Procurement, respond to end‐user questions about how to use the system (customer support functions, contribute to and publicize training materials and other communications).

PCard and A/P to consolidate audit functions.

4.2.3.3 Changes in business processes to be managed by FSS are: Support recurring EAS and Banner interfaces.

Serve as tier two helpdesk for administration of EAS integrations/interfaces.

Serve as tier two support for EAS‐related business processes and reporting.

Support maintenance of recurring updates including testing and user testing management.



4.2.3.4 Changes to system processes to be managed by Division of IT are: Support FTP file‐sharing to be used for all data imports and exports with naming conventions to

be provided by Concur.

Support inbound and outbound integrations between Concur and EAS/Banner.

Support SAML Single Sign‐On authentication between MyGW Portal and Concur.

Provide integration modification and testing through Concur, EAS and Banner upgrades.

Provide authentication modifications and testing through Concur and MyGW Portal upgrades.

Conform to Concur’s technical requirements for access, initial load and recurring updates.

Adhere to the Division of Information Technology’s security policies.

Provide ongoing support similar to SciQuest.

4.3 Proposed Milestones & Major Activities Implementation of Expense and Travel may happen separately or concurrently to one another.

Timeline is in agreement with experiences of other higher education implementations.

Phase Milestone & Major Activities Timing

E*Expense critical path tasksT*Travel critical path tasks

Expense Travel

Proposal Proposal Approved by Gate Review Board 9/26/11 9/26/11

Project Chartered 10/21/11 10/21/11

Identify project start date 9/26/11 9/26/11

Planning

TE*Sign vendor contracts 9/26/11 9/26/11

Engage team and stakeholder participants 10/19/11 10/19/11

Approval to make A/P, PCard, Travel process changes Project start + 4 weeks Project start + 2 weeks

Identify policy changes necessary Project start + 4 weeks Project start + 4 weeks

Stakeholder meetings/buy‐in Project start + 8 weeks Project start + 4 weeks

TE*Coordinate implementation schedules with vendors Project start + 4 weeks Project start + 4 weeks

E*Finalize IT Requirements & Functional Designincluding access protocol, requirements for integrations and validate security requirements

Project start + 4 weeks Project start + 4 weeks

Hire new staff (Travel Manager, application manager – if necessary) Project start + 8 weeks Project start + 4 weeks

Planning Gate Review Project Start + 8 weeks Project Start + 4 weeks

Analysis, Design &

Development

Engage vendors Plan Approval Plan Approval

Establish configuration Plan Approval + 4 weeks Plan Approval + 4 weeks

Knowledge transfer on system configuration and maintenance tools

Initial configuration + 2 weeks

Initial Configuration + 2 weeks

T *Develop employee (user) initial load and user interface Plan Approval +3 weeks

Develop SSO functionality Plan Approval + 2 weeks

Develop test plan Plan Approval + 8 weeks Plan Approval + 2 weeks



Phase Milestone & Major Activities Timing

E*Expense critical path tasksT*Travel critical path tasks

Expense Travel

Develop communication & training plans Plan Approval + 8 weeks Plan Approval + 2 weeks

Develop Expense Interfaces Plan Approval + 18 weeks

E*IT Analyst Testing Completed Plan Approval + 31 weeks Test employee initial load and user interface + 1 week

E*Initial FSS Testing Completed IT Analyst testing complete + 2 weeks

IT Analyst testing complete + 1 week

Code Freeze IT Analyst testing complete + 2 weeks

E*EndtoEnd FSS Analyst Testing Completed IT & FSS Initial testing complete + 4 weeks

AD&D Gate Review Plan Approval + 39 weeks Plan Approval + 7 weeks

Testing and

Readiness

TE*UAT AD&D+4 weeks AD&D+2 weeks

Rework UAT +2 weeks UAT +1 week

TE*Regression Testing UAT + 4 weeks UAT + 2 weeks

T&R Gate Review AD&D+8 weeks AD&D+4 weeks

Deploym

ent/

Cutover Implementation

Testing & readiness + 1 week

Testing readiness +1 week

Production Validation Implementation +1 week Implementation +1 week

Post GoLive Gate T&R + 2 weeks T&R + 2 weeks

Total Duration 57 weeks** 17 weeks**

** The total duration gets the project through implementation of for system availability. A pilot will then occur in the weeks following system

implementation and prior to announcement of general availability. Also, an initial communications / adoption campaign will also occur in the weeks

following pilot.

Table 1 ‐ Proposed Milestones & Major Activities

Figure 6 – Proposed Travel Portal Implementation Project Timeline



Figure 7 – Proposed eExpense (Concur) Implementation Project Timeline

4.4 Organizational Resource Requirements Phase Resources Required Role FTE & Duration

Expense Travel

Planning

A/P Process owner/SME .5 FTE through phase Stakeholder

Procurement Process owner/SME .5 FTE through phase 1FTE through phase

FSS Process owner/SME .5 FTE through phase .25 through phase

Stakeholders Provide input in plan 1/40 FTE each for duration of each Planning phase (2 hours/biweekly)

IT

Technology Development/SME

IT Development: 2.1 FTE through phase

SSO .25 FTE through phase

IT analysis1.5 FTE through phase

Initial Load.25FTE through phase

Risk SME/SOS linkage .1 FTE

OGC, Compliance, Internal Audit Informed

BMAG/Finance Project Management .5 FTE .5 FTE

Analysis, Design &

Development

A/P Process owner/SME .5 FTE through phase Stakeholder

Procurement Process owner/SME 1FTE through phase .1 FTE through phase

FSS Process owner/SME 1.5 FTE through phase .25 through phase

IT SME, Development, Analysis

IT Development: 2.1 FTE 18 weeks

.5 FTE through phase



Phase Resources Required Role FTE & Duration

Expense Travel

IT analysis1.5 FTE 17 weeks

Initial Load.25FTE through phase

Stakeholder groups (FDs, OVPR, Med Center, identified heavy travel user groups)

Involvement in system planning

1/40 FTE each for duration of each AD&D phase (2 hours/biweekly)

American Express Implementation Lead

Concur Implementation Lead

BMAG/Finance Project Management .5FTE .5 FTE

Testing & Readiness

A/P Process owner .5 FTE through phase Stakeholder

Procurement Process owner 1 FTE through phase 1 FTE through phase

FSS

Financial System Security Financial Applications

Support

Workflow and Security Role Validation & Modification IT Development & Analyst Testing Support End‐to‐End and UAT Testing Solution Cutover Support

1 FTE through phase 1 FTE through phase

IT UAT 1.5 FTE .5FTE

Stakeholder Groups Involvement in system testing

1/20 FTE each for duration of each testing phase (2 hours/week)

American Express Implementation Lead

Concur Implementation Lead

BMAG/Finance Project Management .5FTE .5 FTE

Deploym

ent

Cutover IT, FSS Validation .5FTE as necessary

A/P, PCard, Procurement Transition to operations

Stakeholders Informed

Table 2 ‐ Organizational Resource Requirements

The assignment of a Division of IT PMO Project Manager in the role of configuration manager is suggested in order to facilitate coordination of activities between the different Division of IT teams listed above and with the Division of Finance.

Ongoing collaboration with GW customer departments and with American Express and Concur will be necessary.



4.5 Assumptions, Risks & Exclusions

4.5.1 Assumptions PCard policies and procedures will be changed based on opportunities of new system.

A/P policies and procedures will be changed based on opportunities of the new system.

Travel Manager will be hired and supported by Procurement prior to Travel Portal implementation.

Technical support will be hired and supported by FSS prior to AD&D phase of Concur Expense.

Technical support will be hired by Division of IT prior to implementation of Concur Expense.

Recurring interfaces to be developed, implemented and maintained either in flat‐file exchange in the Concur‐defined format or as a web service:

o Authentication to portal as SAML Single Sign‐On. o Employee import from Banner. o Approvers list (depth based on workflow implemented). o List import for cost centers. o List import for expenditure items. o Standard Accounting Extract (invoice). o Payment Confirmation and Funds Checking.

GW can develop an access path that conforms to our security requirements and will meet the specifications of Concur.

Workflow lite will be evaluated and approved by internal audit.

The identification of eligible members into profile groups does not need to be managed by data from GW initial load or recurring interfaces.

Data exists in Banner that will meet the data requirements of the Cliqbook system.

Resources are available to meet the timing requirements of the Division of Finance.

Types of expenses that are currently submitted on T&Es at GW will be available to submit electronically, including: travel, supplies, meals, and training.

Paperless (both on user and administrator end) transactions to be included in this project plan: o Expense reimbursements. o Approval (pre/post expense). o Automated processing.

GW’s complex approval workflow must be supported; system shall be launched with “lite” workflow capability.

Solution must align with existing travel policies and procedures.

All travelers must use a PCard or personal credit card to pay for travel booked through the system.

The eligible members of the GW community are to be faculty and staff only. No alumni or non‐working students are to be eligible to use the service in the original implementation unless they also have another role at GW that makes them eligible.

4.5.2 Risks Limited existing travel policies may limit full realization of cost savings.

In order to support the paperless and financial goals, a high user adoption rate is necessary; requiring significant resources devoted to communication and training.

In order for the system to function as efficiently as expected, an organized pre‐implementation process (i.e. supporting policies and procedure changes) should be undertaken.

Workflow “lite” scenario is not recommended by the vendor due to lack of system controls.

Lack of defined supervisor workflow for all employees in the University will impact system effectiveness and reputation.



Changes during planning phase, including decision to develop workflows or addition of other similar integrations may have significant impact on estimated timeline.

Concur does not provide a test environment, rather a test user group is recommended. This may make testing more complex, particularly when changes are made to integrations.

Exclusion of students, contractors and vendors from expense solution will require manual processing of these populations.

A mechanism to ensure staff and PCard terminations are fed in a timely manner to avoid unauthorized expense report submission and/or reimbursement is required.

Full PCard functionality is dependent upon upgrading to PaymentNet 4 prior to implementation of the Concur Expense system.

Owners of departmental budgets may be resistant to travel budget reductions necessary to subsidize the Expense program.

4.5.3 Exclusions Students, contractors and vendors will not be included in the expense solution or travel portal at

this time.

Identified as Out‐of‐Scope for this project: o Streamlined GW‐wide workflow o Consolidation/reduction of number of GL accounts o Per Diems

While PCard reconciliation, reporting and auditing are in‐scope; determination of eligibility, changes to limits and other management of users is not.

5 Funding

5.1 eExpense Funding Requirements & Source of Funding

Table 3 – eExpense Funding Required & Funding Source

One time set up costs: $ DIT and Finance to co‐fund

Recurring Costs:

Transaction Costs: $ Assumes a 3,500 expense reports per months

DIT Support Costs: $

FSS Support Costs: $ FSS Integration support

Total Recurring Costs: $

Source of Funding:

pCard Rebate Offset $ Improved contract with JPM. Rebate % increased.

FTE Savings $ 2 FTE reduction from Finance (AP and PCARD)

Increased Strategic Sourcing Goal1

$ I will add to the Strategic Sourcing Goal another $135K.

Paper Savings (Yellow Envelopes) $

Net Funding Required: $

1 This wil l occur through attri tion and paid with Lapse sa laries unti l attri tution occurs in AP and PCARD



5.2 Travel Portal Funding Requirements, Source of Funding and Savings

Table 4 – Travel Portal Funding Required, Funding Source and Savings

6 Business Case

6.1 Cost Benefit Analysis

6.1.1 Travel Portal Savings Potential

Table 5 – Travel Portal Savings Potential



6.1.2 Total Net Present Value (NPV) of eExpense & Travel Portal Implementation

Table 6 – 3 year NPV of eExpense & Travel Portal Implementation

6.2 Qualitative Benefits Electronic expense reporting should allow for faster and more accurate expense reporting and reimbursements due to automated workflow, comparison against policy engine and audit functions. Additionally, thoughtful planning of the solution will allow for staff to focus more on exceptions, analysis and adherence to policy rather than day‐to‐day paper processing and auditing.

Implementing a Travel Portal will provide a uniform manageable service to the GW community. The provider will be able to develop histories that will facilitate the unique repetitive special situations needed by a university, such as handling athletic team travel, coordination with development activities and international travel. Research travel, accounting for approximately 20% of GW’s total travel spend, is not included in overall savings because savings cannot be redirected. However, the additional travel spend contributes to giving GW more leverage when it comes to negotiating rates with vendors.

6.3 Quantitative Benefits Reporting: The project should result in reportable savings to the University and a better tracking/reporting mechanism for identifying travel patterns and user expenditures.

Savings: The expectation in implementing a travel portal is to realize an annual cost savings of . This can be achieved only with very high adoption rates.

Travel savings will primarily be to traveling departments. A mechanism for capturing these savings and redirecting to fund the cost of the Concur system, and excess funds into ITF must be identified.

Additional travel savings may be captured by implementing American Express Business Travel’s Meeting Manager module (possibly in‐scope for this project)

Additional travel savings may be captured by implementing a per diem structure within GW and implementation of stronger travel policies (out‐of‐scope for this project).



An increase in the amount of PCard rebates received by GW will be seen if PCards are mandated to cover travel expenses.

6.4 Comparative Analysis As part of ITF Strategic Sourcing initiative, Travel Portal implementation is meant to lead to long‐term significant travel cost savings to GW and forms the cornerstone for future Procurement improvements in the area of travel services. American Express estimates a savings to GW of around in year one based on departmental adoption. A savings of at least 10% of travel spend is likely with full adoption of American Express Business Travel as GW’s sole agent for travel and meeting planning.

The main driver for selection of Concur Travel and Expense solution is the user‐friendly nature of the solution and the configurability of the system to reflect, and provide visual reminders of GW’s travel and expense policies as well as eliminate the need to complete separate PCard reconciliation processes and hard‐copy submission.

The solution allows for near paperless expense reimbursements and journaling, allowing A/P and PCard staffs to focus on audit, compliance, and reporting efforts reducing reliance on manual administrative processes.



Appendix A – Related Documents File Name

Document Owner

Document Location or Link

GW Concur Agreement ‐ 25 Sep 11.pdf D.Ginter https://eroom.gwu.edu/eRoom/EVPT/eExpense/0_1e969

GW AEBTS Agreement – 1 Oct 11.pdf D.Ginter https://eroom.gwu.edu/eRoom/EVPT/TravelPortal/0_1e972



Appendix B – Glossary Term / Acronym Definition

AEBTS American Express Business Travel Services

AR Accounts Receivable

BMAG Office of Finance ‐ Business Management & Analysis Group

CO Office of Finance ‐ Comptroller's Office

CSV Comma Separated Values

EAS Enterprise Accounting System

EIS Division of IT – Enterprise Information Services group

ETS Endowment Tracking System

FSS Office of Finance ‐ Financial Systems Support

G/L General Ledger

GM Grants Module

GW The George Washington University

GWU The George Washington University

HR Human Resources

IT Division of Information Technology

PMLC Project Management Lifecycle

SAML Security Assertion Markup Language

UAT User Acceptance Testing

XML Extensible Markup Language