1. Financial Management System Agency Requirements Outreach Briefing November 14 and 17, 2006

2. 2 Agenda  Welcome and Introductions  Background / Purpose of Study  Project Governance  Preliminary Findings  Requirements Functional Scope  System Requirements Validation  Questions

3. 3 FMS Needs Assessment Update Background  FMS Needs Assessment performed in 2001 by Accenture.  Overseen by steering committee made up of state agency representatives, including Judicial, Legislative branches  Recommended centralized system with two agency copies. Project costs estimated between $24.5M – $36.5M  Decision made not to move forward due to lack of funding related to economic downturn.  Began effort in April 2006 to revisit FMS needs in light of changes in administrative philosophy, business practices, changes in technology, and improved economic outlook  RFP opened in July 2006 for consulting services to assist in update. Awarded in late August to Salvaggio, Teal and Associates who have performed similar work in six states.

4. 4 FMS Needs Assessment Update Purpose of Study  Update the system requirements for a new integrated FMS  Update the business case analysis associated with implementing a new FMS  Determine whether there is a compelling business case for procuring/implementing an integrated statewide FMS  Submit recommendations regarding: Organizational best practices Implementation best practices

5. 5 Financial Management System (FMS) – A comprehensive suite of integrated modules delivered by a single software vendor that provides end-to-end support for statewide administrative business functions (e.g., financial accounting, procurement, asset management). FMS is a proposed solution that provides functionality similar to STARS, SOKI, Central Setoff System, and other agency administrative systems, but in a fully integrated manner. FMS Needs Assessment Update What is FMS?

6. 6 Business Case Analysis Report Sept Oct Nov Dec Project Start-Up Validate the Business Case Key Deliverables FMS Needs Assessment Update Key Activities and Timeline Validate Functional / Technical Requirements Updated Needs Assessment Organization / Implementation Best Practices

7. 7 Project Governance Organizational Structure

8. 8 Project Governance Project Sponsors  Duane Goossen Secretary of Administration  Carol Foreman Deputy Secretary of Administration  Denise Moore Executive Branch Chief Information Technology Officer

9. 9 Project Governance Steering Committee  Chair - Carol Foreman, Deputy Secretary of Administration  Mary Blubaugh, Board of Nursing  Alan Conroy, Legislative Research Department  Gary Daniels, Department of Social & Rehabilitation Services  Elaine Frisbie, Department of Administration; Division of Budget  Kathy Greenlee, Department on Aging  Mike Hayden, Department of Wildlife and Parks  Lynn Jenkins, State Treasurer  Deb Miller, Department of Transportation  Reginald Robinson, Board of Regents  Howard Schwartz, Judicial Administrator  Joan Wagnon, Department of Revenue  Roger Werholz, Department of Corrections

10. 10 Project Governance Stakeholder Agencies  Adjutant General  Department on Aging  Department of Agriculture  Department of Administration  Department of Health and Environment  Department of Transportation  Highway Patrol  Department of Labor  Department of Commerce  Juvenile Justice Authority  Department of Corrections  Department of Revenue  Social and Rehabilitation Services  Kansas Health Policy Authority  Judicial Branch  Department of Wildlife and Parks  State Treasurer

11. 11 Preliminary Findings Lack of Integration  Financial Accounting (STARS, SOKI)  Purchasing (Procurement Manager Plus)  Asset Management (various agency systems)  Budget Development (BMS, various agency systems)  Accounts Receivable (various agency systems)

12. 12 Preliminary Findings Functional Challenges  Procurement  Grant and Project Accounting  Fleet Management  Inventory Management  Time and effort reporting in SH A RP  Agency operating budget vs. appropriation budget  Real-time budget checking

13. 13 Preliminary Findings Functional Challenges  Agencies need ability to establish lower level of detail in chart of accounts  Robust ad hoc reporting  More efficient processing of employee travel authorizations and payment  Comprehensive accounts receivable functionality including Set-Off capabilities  Lack of enterprise Asset Management system for assets and controllable items

14. 14 Preliminary Findings Other  A number of agencies are either ready to seek replacement financial management systems or acquire a new system  Evaluation of Chart of Accounts Needed Financial Accounting Coding Structure Budget Coding Structure Procurement Commodity Code Structure  Difficult to obtain “true” data on statewide spend

15. 15 CORE FINANCIAL General Ledger / Budgetary Control Accounts Payable Accounts Receivable & Cash Receipting Cash Management Cost Allocation Grant Accounting Project Accounting Asset Management PROCUREMENT/LOGISTICS Purchasing Inventory Management Fleet Management HR / PAYROLL Automated Interfaces to/from SHARP BUDGET DEVELOPMENT INTEGRATION Appropriation Budget Agency Operating Budget Common Database FMS Needs Assessment Update Functional Requirements Scope

16. 16 Accounts Payable  The Accounts Payable module will be used to process payments to vendors for goods and services. Major business functions included in this module are: Vendor maintenance 3-way matching process Payment processing 1099 processing Payment cancellation Vendor self-service Employee travel authorization and payment processing

17. 17 Accounts Receivable  Accounts Receivable provides proper recording of revenue against all segments in the Chart of Accounts to enable the State to report and monitor actual revenue against budgeted revenue. This area addresses the following functions: Customer maintenance Accounts receivable processing Billing Cash receipting Dunning notices Interest / penalty calculation

18. 18 General Ledger & Budgetary Control  The General Ledger & Budgetary Control Module provides an integrated central repository of statewide financial data. All subsidiary functions (e.g., Accounts Payable) update the General Ledger with financial data. Budgetary Control is used to control spending to ensure that spending is in accordance with the Appropriations Bill. Major functions of this module include: Chart of Accounts Structure Basic Fund Accounting Corrective or Adjusting Journal Entries Interfund/Interagency Transactions

19. 19 General Ledger & Budgetary Control Month-End and Year-End Closing State and Federal Reporting Real-time Budgetary Control Budget Maintenance and Monitoring Budget Adjustments

20. 20 Cash Management  Cash Management provides an integrated central repository of deposit transactions for reconciliation of the various state bank accounts. In addition, payments issued are tracked to validate against the redemption of these items: Issuance and redemption of payments Bank reconciliation

21. 21 Cost Allocation  Cost Allocation aids management in making cost- effective and informed decisions about projects and programs by assessing the entire monetary cost of resources used or committed to projects and programs. By providing financial allocation and distribution functionality, the FMS offers the ability to accumulate and measure the true cost of organizational activities. Cost Allocation Labor Distribution Billing

22. 22 Project Management  Project management addresses the recording, tracking, and reporting of financial data for a variety of State projects and contracts. This module addresses the following: Key processes for operating and capital projects, including project development, execution, and the project close process. Tracking of project progress using work plans, tasks, resource assignment, controlled critical path, and deliverables.

23. 23 Grants Management  Grant accounting enables the recording and monitoring of all grant activity. Grant accounting functionality includes: Grant award Grant billing and draw processing Grant reporting Sub-grantee accounting

24. 24 Asset Management  Asset Management addresses the need for the State to track and account for all capitalized assets. Additionally, Asset Management performs the following: The ability to produce reports in accordance with GASB 34 for inclusion with the CAFR. Allows the agencies to track other items as needed, including sensitive items and other controlled assets (e.g., guns, PDAs, digital cameras). Processing of surplus assets Processing of lost and stolen assets

25. 25 Procurement Procurement  Procurement includes the traditional solicitation process used for purchasing goods and services, as well as new eProcurement functionality: Catalog procurement Reverse Auctions Vendor registration and other self-service Commodity maintenance Vendor performance management

26. 26 Procurement Best Practices - Traditional Procurement Process  Requisitioner initiates purchase requisition  Approvals provided via automated workflow  Solicitation initiated based on pre-defined business rules: Posted to State Procurement Web Site Automatically “pushed” to vendors registered to service specific commodity(s)  Solicitation responses received from vendors  Responses tabulated, evaluated and awarded

27. 27 Procurement Best Practices - Traditional Procurement Process  All vendors submitting bids receive email notification of award  Purchase order created and issued  Goods receipt entered  Invoice receipt entered  Automated three-way match performed If no exceptions, payment request generated If exceptions exist, they must be resolved

28. 28 Procurement Best Practices - Catalog Procurement  Requisitioners procure goods and/or services from vendor catalogs at the State’s pre-negotiated prices via the Internet  Types of catalogs available may include: Catalogs that reside inside the State’s firewall (e.g. statewide or agency contracts) Catalogs that reside at the vendor’s site – requisitioners “punch-out” to vendor web sites to configure and price items; this information is then retrieved and used in building a requisition Catalogs for goods or services purchased from other organizations within State government

29. 29 Procurement Best Practices - Catalog Procurement  Purchase order created and issued  Approvals provided via automated workflow within agency or across agencies  Goods receipt entered  Invoice receipt entered  Automated three-way match performed If no exceptions, payment request generated If exceptions exist, they must be resolved

30. 30 Procurement Best Practices - Reverse Auctions  Typically performed for certain types of purchases (e.g., bulk commodity purchases, big-ticket items)  State notifies prospective vendors of upcoming auction, including auction start and end dates / times Vendors registered with the State to provide specified commodity(s) are invited to participate in the auction Notice of auction posted to Division of Purchasing Web site  Vendors log in, view and accept terms and conditions, target bid price, specifications, and enter their respective bids in online, real-time mode  Vendors can view other bids and submit lower bids to stay competitive

31. 31 Procurement Best Practices Procurement Best Practices Market Place Examples Catalog procurement = Reverse auctions =

32. 32 Procurement Best Practices - Vendor Self-Service  Vendor registration  Special certifications can be captured (e.g., Small Business, Woman Owned, Minority Owned)  Maintenance of basic vendor information (e.g., contact information)  Maintenance of commodities serviced  Automatic “pushing” of bid opportunities to vendors that service specific commodities  Inquiry into status of transactions with State

33. 33 Procurement Best Practices - Vendor Performance Management  Track contacts with problem vendors (phone calls, written contacts regarding problem orders/delivery of goods and services)  Automatically track and report/inquire on vendor performance, including: Orders Delivery Returns Bid history Payment history Complaints and resolution

34. 34 Inventory  Inventory Management addresses the need for selected agencies to purchase, store and distribute, and replenish goods within a warehouse or “ central stores ” operation. Additionally, this module provides the following functions: Ability to provide inventory data for inclusion with the CAFR Allows the agencies to effectively manage inventory cost and quantities Provides a mechanism to allocate inventory costs to programs and organizations Provides “ reordering process ” or replenishing inventory when specific reorder points are met Provides for full integration with Procurement module Supports the use of bar coding technology

35. 35 Fleet Management  Fleet Management addresses the need for the State to manage and efficiently maintain its investment in vehicles and other motorized equipment. Additionally, Fleet Management performs the following: Reduces vehicle downtime to the State through the use of effective preventive maintenance Provides the ability to manage vehicle assignments and the proper allocation of the cost within the organization Provides the ability to track and manage fuel cost

36. 36 System Requirements Validation – Objectives  It is essential that a comprehensive set of detailed requirements be developed as they will: Identify the system requirements necessary to support the State’s business processes Be included in Request for Proposal and used as a checklist against which to evaluate vendor offerings Become part of the contract entered into with the selected vendor(s) Monitored during implementation to ensure all requirements were met, and that work was not performed to develop functionality that did not support the documented requirements

37. 37 Requirements from 2001 Needs Assessment Study STA Requirements Toolkit Baseline Requirements Draft Requirements Final Requirements Focus Group End User Community Functional and Technical Requirements Development Process Project Team System Requirements Validation – Process Used

38. 38 System Requirements Validation – Accomplishments  Focus Group Kick-Off Meeting on 10/09/06 with 75 agency participants  Over 130 participants representing 25+ agencies in various Focus Groups to-date  Requirements cover 14 functional areas  Final draft requirements are almost complete. Will be posted to the web for review by all state agencies by late next week (Nov. 17).

39. 39 Requirements from 2001 Needs Assessment Study STA Requirements Toolkit Baseline Requirements Draft Requirements Final Requirements Focus Group End User Community Project Team System Requirements Validation – Where We Are? Conduct statewide stakeholder meetings – Early October (Human Resources, Payroll, Financial, Budget Development) and 9-28/10-6 (Purchasing) Stakeholders download requirements and response templates Stakeholders email the response template back to us by 10/14 Conduct statewide stakeholder meetings – Early October (Human Resources, Payroll, Financial, Budget Development) and 9-28/10-6 (Purchasing) Stakeholders download requirements and response templates Stakeholders email the response template back to us by 10/14 Attend Agency Requirements Outreach Briefing (November 14 or 17) Download and review requirements applicable to your agency’s business functions Email completed Feedback Response Template by 12/04/06

40. 40 System Requirements Validation – Process for Obtaining Agency Feed back  Download the following files from the FMS Web site (the URL is http://da.ks.gov/ar/fms/): Functional requirements Requirements Feedback Template (Excel file)  Enter your recommended additions, changes, and deletions to the requirements in the Requirements Feedback Template  Save the template using the following naming convention: Abbreviated Agency Name + Your Last Name Example: KDHE Smith  Email the completed template as an attachment to: Noelle Jones at noelle.jones@da.state.ks.us

41. 41 System Requirements Validation – FMS Web Site http://da.ks.gov/ar/fms/

42. 42 System Requirements Validation – Sample Functional Requirements

43. 43 System Requirements Validation – Vendor Response Codes  SF = Standard functionality  NR = Provided in Next Release  MI = Minor Modification  MA = Major Modification to Source Code Required  RQ = Provided through Reporting or Query Tool  CD = Custom Development  TP = Third Party Software Required  NA = Cannot Meet Requirement

44. 44 System Requirements Validation – Requirements Feedback Template

45. 45 System Requirements Validation – Adding a Requirement To add a requirement: Enter the reference number of the requirement you would like the new requirement to follow Enter the requirement Enter an “A” in the Add/Change/Delete column Provide additional explanation in “Comments” column if needed

46. 46 System Requirements Validation – Changing a Requirement To change a requirement: Enter the reference number of the requirement you would like to change Enter the requirement as changed Enter a “C” in the Add/Change/Delete column Provide additional explanation in “Comments” column if needed

47. 47 System Requirements Validation – Deleting a Requirement To delete a requirement: Enter the reference number of the requirement you would like to delete Enter the requirement to be deleted Enter a “D” in the Add/Change/Delete column Provide additional explanation in “Comments” column justifying why the deletion is required

48. 48 System Requirements Validation – Guidelines for Reviewing Requirements  Do not attempt to document your existing systems/ processes – describe your future requirements  Focus on what the system must do – not how. System design will be completed after product selection  Ensure that the requirements are documented in clear and concise statements (single requirement -- don’t blend multiple requirements together)  Focus on requirement content, not “wordsmithing”  Remember that considerable work has already been put into validating the requirements by the Focus Groups  We need all Requirements Feedback Templates returned to Noelle Jones by December 4 th

49. 49 Questions?