State of KansasState of Kansas

Financial Management SystemFinancial Management SystemNeeds Assessment ValidationNeeds Assessment Validation

Focus Group Kick-Off MeetingOctober 9, 2006

2

Meeting AgendaMeeting Agenda

Introductions Project Governance Project Overview Key Activities

• Requirements Validation• Business Case Analysis

Upcoming Activities Questions

3

STA Company ProfileSTA Company ProfileStatewide ERP/eProcurement SystemsStatewide ERP/eProcurement Systems

State of ArkansasState of Nebraska

State of TexasState of Nevada

State of Texas

State of Tennessee

State of Wisconsin

Commonwealth of Kentucky State of Minnesota

4

Project Governance Project Governance Organizational StructureOrganizational Structure

EXECUTIVE SPONSORS

STEERING COMMITTEE

PROJECT DIRECTORDuncan Friend

PROCUREMENT TEAMChris Howe/Angela Hoobler, Manager

TECHNOLOGY TEAMCathy Jones/Jay

Coverdale, Manager

PROCUREMENT FOCUS GROUP

TECHNOLOGY FOCUS GROUP

PROJECT CONSULTANTSSalvaggio, Teal & Assoc.

ACCOUNTING TEAMBob Mackey/Martin Eckhardt, Manager

ACCOUNTING FOCUS GROUP

ELECTED OFFICIALS

AGENCY SUBJECT MATTER EXPERTS

AGENCY CFOsAGENCY CIOs

5

Project SponsorsProject SponsorsMembershipMembership

Duane Goossen• Secretary of Administration

Carol Foreman• Deputy Secretary of Administration

Denise Moore• Executive Branch Chief Information Technology

Officer

6

Project SponsorsProject SponsorsRoles & ResponsibilitiesRoles & Responsibilities

Actively champion the project Establish and cultivate legislative sponsors

Provide executive level support Steering Committee and Project Team guidance Monitor project progress

Provide clear direction Ensure that the FMS initiative is aligned with the State’s strategic goals

and objectives Empower the team

Steering Committee and the Project Team Assist with issue resolution

Resolve issues in a timely manner per the project issue escalation policy

Assist in removing obstacles Secure required resources

Ensure funding/staff necessary to achieve project objectives

7

Steering CommitteeSteering CommitteeMembershipMembership

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

8

Steering CommitteeSteering CommitteeRoles & ResponsibilitiesRoles & Responsibilities

Actively participate in Steering Committee meetings Remove obstacles to project success Actively champion the project Communicate project status within respective

agencies Review and provide input to final report

December 11 – December 14

9

Requirements Focus GroupRequirements Focus GroupMembership – 25 State AgenciesMembership – 25 State Agencies

Department on Aging Department of Agriculture Corporation Commission Kansas Health Policy Authority Department of Administration Department of Health and

Environment Department of Transportation Kansas Highway Patrol Department of Labor Department of Commerce Juvenile Justice Authority Kansas Public Employees

Retirement System Kansas State University

Legislative Research Department Kansas Lottery Board of Nursing Department of Corrections Department of Corrections –

Correctional Industries Department of Revenue Department of Social and

Rehabilitation Services Department of Education State Treasurer Judicial Branch University of Kansas Medical

Center Kansas Department of Wildlife and

Parks

10

Requirements Focus GroupRequirements Focus GroupRoles & ResponsibilitiesRoles & Responsibilities

Review draft baseline system requirements prior to

work sessions and come prepared to participate Participate in all assigned requirements validation

work sessions and provide quality feedback to ensure requirements properly reflect State of Kansas business needs

Serve as an “ambassador” for state agencies not in attendance.

Participate in final review of requirements during Agency Outreach sessions

11

Enterprise Resource Planning (ERP) – A comprehensive suite of integrated modules delivered by a single software vendor that provides end-to-end support for statewide administrative services

For purposes of this study, we will use the term ‘Financial Management System’ (FMS) rather than ERP since the scope of the project includes financials and procurement only – due to current / future investment in the SHARP system

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

Project OverviewProject OverviewWhat is ERP? FMS?What is ERP? FMS?

12

Project Overview Project Overview Why FMS?Why FMS?

Satisfy the needs of the agencies• Eliminate the proliferation of stand-alone agency systems• Avoid the cost associated with new agency administrative

systems • Avoid the cost associated with maintenance/upgrades of

current systems

Significantly improve the quality, quantity, and timeliness of information • Effective decision-making• Efficient and accurate research capabilities • Enhanced ad hoc reporting and inquiry functionality

Streamline processing and control of electronic “documents” through workflow management• Facilitates document routing, review and approval

13

Project Overview Project Overview Why FMS?Why FMS?

Streamline and simplify State’s business processes • Financial• Budgeting• Procurement• Other administrative operations

Improve operational efficiency • Commercially-available FMS systems include many features

representing best management practices

Support Web-enabled self-service• State employees• Vendors conducting business with the State

14

Project Overview Project Overview Why FMS?Why FMS?

Replace existing disparate systems• Costly to maintain• Difficult to administer

Automate and integrate• State’s financial accounting, procurement, asset management,

and other administrative business processes within a single database

Provide single point of entry• Eliminate duplicate points of data entry• Eliminate duplicate databases• Simplify reconciliation

Reduce/eliminate paper documents• Reduce paper and handling costs (e.g., vouchers) • Simplify record retention and audit compliance

15

Project Overview Project Overview Why FMS?Why FMS?

Take advantage of technology enablers• Web-enablement• Graphical user interface• Single integrated relational database • Real-time processing• Increased functionality based on best business practices• Modular integration• Integration with desktop “office suite” software• Sophisticated reporting and query capabilities • Audit trail / “drill-down” capabilities• Workflow management and electronic approvals• Flexible chart of accounts

16

Key Activities Key Activities FMS Needs AssessmentFMS Needs Assessment

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

17

Business Case Analysis Report

Sept

Oct Nov Dec

Project Start-

UpValidate the

Business Case

FMS Needs Assessment Update

Key Deliverables

Key Activities Key Activities TimelineTimeline

Validate Functional / Technical

Requirements

Updated Needs Assessment

Organization / Implementation Best Practices

18

CORE FINANCIAL

• General Ledger / Budgetary Control

• Accounts Payable• Accounts Receivable

& Cash Receipting• Cash Management• Cost Allocation• Grant Accounting• Project Accounting• Asset Management

PROCUREMENT

• Solicitations (RFx)• Catalog Procurement• Reverse Auctions• Inventory Management• Commodity Management• Vendor ManagementHR / PAYROLL

• Automated Interfaces to/from SHARP

BUDGET DEVELOPMENT INTEGRATION

• Appropriation Budget

Common Database

Project OverviewProject OverviewProposed FMS Functional ScopeProposed FMS Functional Scope

19

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

Project ScopeProject ScopeUpdate / Validate FMS RequirementsUpdate / Validate FMS Requirements

20

System Requirements Validation – System Requirements Validation – GuidelinesGuidelines

Focus on what the system must do – not how. The system design will be completed after product selection.

Emphasize process change in lieu of software modifications to protect software warranties and facilitate future system upgrades.

Develop the system requirements at a level of detail required to differentiate among available products

Provide one requirement, not multiple requirements, per line item

Document each requirement in such a way as to support proper validation

21

System Requirements Validation – System Requirements Validation – ObjectivesObjectives

Included in Request for Proposal and used as a checklist against which to evaluate vendor offerings

Made 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

22

System Requirements Validation – System Requirements Validation – OrganizationOrganization

Functional Requirements • General Ledger and Budgetary Control• Asset Management• Accounts Payable• Accounts Receivable and Cash Receipting• Cash Management• Cost Accounting / Allocation / Activity Based Costing• Grant Accounting• Project Accounting• Purchasing• Inventory Management• Budget Development

23

System Requirements Validation – System Requirements Validation – OrganizationOrganization

General and Technical Requirements • Technical & Architectural Requirements• System Performance• Security• System Navigation and User Friendliness• System Management• Automated Workflow & Electronic Approvals

Reporting and Data Warehouse Data Conversion Requirements

• More data converted, greater expense and risk to State• Determine data conversion vs. data archive needs

24

System Requirements Validation – System Requirements Validation – OrganizationOrganization

Interfacing Systems• Target Systems• Interface Description• Direction of Transmission• Data Transmitted• Triggering Event• Frequency of Interface• Type of Interface• Level of complexity

25

System Requirements Validation – System Requirements Validation – Sample RequirementsSample Requirements

Business RequirementsVendor

Response Comments

Vendor Files

PU 19.00

System provides the ability to track and to report/inquire on vendor performance including delivery, complaints (including complaints about discrimination allegations) and resolution.

PU 20.00

System provides the ability to search for a vendor by commodity code/number/description and by vendor number/name. (Attach vendor to commodity).

PU 21.00System can infer default vendor information from the vendor master file when creating requisitions and purchase orders.

PU 22.00

System provides the ability to automatically carry forward a vendor number to the next transaction (i.e., requisition to PO and PO to invoice), optional on requisition.

PU 23.00

System provides the ability to assign status codes to vendors (i.e., inactive) and this status can vary by agency or facility (i.e., a vendor can be blocked from use by certain agencys/facilities but not blocked for other agencys/facilities).

PU 24.00System maintains pricing information, quantity breaks, freight terms and shipping information for each vendor.

PU 25.00System tracks vendor by performance / history, date added / deleted or inactivated and reason.

PU 26.00System provides the ability to classify one-time vendors and to check whether already on file based on multiple criteria (e.g., FEIN, SSN, etc.).

PU 27.00System can delete or deactivate vendor from vendor listing by date with reason. Historical data would be retained.

PU 28.00

System rates vendor at each event point based on user-defined criteria and these ratings are displayed at each point in the procurement process.

PU 29.00Vendor numbers (numeric and alphanumeric) can be system generated or assigned manually.

Reference Number

26

System Requirements Validation – System Requirements Validation – Vendor Response CodesVendor 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

27

Upcoming ActivitiesUpcoming Activities

Validate Functional &Technical Requirements• October 2 – November 21

Obtain Stakeholder Input and Approval• November 30 – December 7

Conduct Agency Outreach Sessions• December 7 – December 14

Updated Needs Assessment• December 11

28

Ongoing Project InformationOngoing Project Information

http://da.ks.gov/ar/fms/

29

Questions?Questions?