ERP Business Case Study v11

September 17, 2008 Revised September 30, 2008
September 30, 2008
Ms. Susan Combs Texas Comptroller of Public Accounts 111 East 17th Street Austin, Texas 78774 Dear Ms. Combs and members of the ERP Advisory Council: Salvaggio, Teal & Associates is pleased to submit our revised final report documenting the results of the Business Case Analysis for a Statewide ERP System. We are providing our report in hard-copy and electronic format. It has been our pleasure to work with the States ERP Project Team, and we are grateful for all the hard work that the Comptroller staff and other State agency personnel have put into this effort. We greatly appreciate having had the opportunity to assist the Comptroller with this important study and look forward to being of further assistance to the State of Texas in the future. Should you have any questions or comments regarding our report, please do not hesitate to contact me by phone at (512) 797-7338 or by e-mail at mitt.salvaggio@staconsulting.net. Sincerely,
Mitt A. Salvaggio President
Report on Business Case Analysis for Statewide ERP Planning
TABLE OF CONTENTS
1. Executive Summary ..................................................................... 1 2. Introduction................................................................................. 12 3. High-Level Assessment of Existing Systems.......................... 25 4. Why ERP? ................................................................................... 58 5. Business Case Analysis ............................................................ 68 6. Recommendations .................................................................... 133 7. Funding Plan...............................................................................141 8. High-Level Implementation Plan for Recommended Alternative .........................................................................................................154 Appendix A: Detailed Alternative 2 Estimating Schedules for the Implementation and Operation of New ERP system ...................175 Appendix B: Detailed Alternative 3 Estimating Schedules for the Implementation and Operation of New ERP system ...................185
Salvaggio, Teal & Associates
Page i
September 30, 2008
SECTION 1 EXECUTIVE SUMMARY

Background and Purpose of Study
In May of 2007, the 80th Texas Legislature passed House Bill 3106 (HB 3106), which addressed the concept of Enterprise Resource Planning (ERP) for the State of Texas (State). From a practical standpoint, the term ERP for the State refers to an integrated software package that provides functionality similar to that offered in the existing statewide administrative systems (e.g., USAS, SPA, USPS, SPRS), as well as critical functionality currently provided by agency administrative systems. The Legislation defined the organizational scope to include all State agencies and institutions of higher education, and the functional scope to include the following application areas: General Ledger; Accounts Payable; Accounts Receivable; Budgeting; Inventory; Asset Management; Billing; Payroll; Projects; Grants; and Human Resources, including administration of performance measures, time spent on tasks and other personnel and labor issues. Though not included in the Legislation, the following functional areas were added to the Plan scope: Procurement. While not specified in HB 3106, the functionality is an integral component of an ERP system and procurement falls within the Comptrollers authority. Procurement is the functional area that typically obtains the greatest process efficiencies and potential cost savings in the transition to an integrated ERP system. Fleet Management. While not specified in HB 3106, the functionality is required in order to address Rider 16 which requires that the Texas Comptroller of Public Accounts (Comptroller or Comptrollers Office) implement and maintain a State fleet data management system for agencies to report fleet operating expenses and uses, as required by Chapter 2171.101, Government Code. The system must be accessible through a web-based interface, provide forms for efficient
Page 1
September 30, 2008
entry of data required by the State Vehicle Fleet Management Plan, allow agencies to batch load relevant data from internal legacy systems, provide fiscal and managerial reports for both direct asset management and oversight needs, and be flexible enough to accommodate future agency or legislative needs. Data Warehousing. While not specified in HB 3106, it is assumed that a statewide data warehouse is required in order to provide functionality necessary to meet the States present and future analysis and reporting requirements, and to address the Comptrollers new standards for transparency and accountability in State spending. In November 2007, the Comptrollers Office developed a survey that was sent to all State agencies and institutions of higher education to capture high-level information regarding their administrative systems and expenditures related to the application scope listed in HB 3106. The purpose of the survey was to determine which systems were in place in the various State agencies and institutions of higher education, and what funding was being spent to deploy, operate and maintain these systems. Additionally, the Comptrollers Office wanted to identify the amount of expenditures that were planned over a five-year time horizon to replace, upgrade or maintain these systems. The survey identified the total estimated cost for annual operation and maintenance of the systems across State government at over $88 million, including: Annual software maintenance at $17 million; Annual hardware maintenance at $9 million; and Staffing and labor performing system or application maintenance totaling $62 million and representing approximately 950 FTEs. Anticipated system upgrades, enhancements and replacements totaled over $144 million over the six-year period, according to the survey results. This amount included the following elements: Planned system or application upgrades totaling $27 million; and Planned system replacement or implementation costs totaling $117 million. Based upon a six-year time horizon, the November 2007 survey yielded total system and application costs for the applications included within the scope of HB 3106 to be $672 million or roughly $112 million on an annualized basis. In late June 2008, the Texas Comptroller of Public Accounts (Comptroller or Comptrollers Office) initiated a study to develop a comprehensive business case analysis (BCA) and related strategic planning associated with ERP. The purpose of the Study was to perform a series of tasks that will provide the ERP Advisory Council and the State Comptroller with the data and other information necessary for determining whether implementing a statewide ERP system is economically feasible for the State of Texas through the analysis of the following three (3) alternative scenarios: Business Case Alternative 1: Status Quo (BCA 1) -- The State continues on its current path whereby each agency and institution of higher education continues operating their existing administrative systems as currently planned.
Page 2
September 30, 2008
Business Case Alternative 2: Statewide ERP Platform Deployment (BCA 2) - Replace the existing statewide legacy administrative systems (USAS, USPS, SPA, SPRS, HRIS, TINS) with a new, fully integrated, commercially-available ERP system that would provide all functionality identified in HB 3106. One (1) statewide ERP system for all agencies and all institutions of higher education (HE) would be established and operated by the Comptroller. Business Case Alternative 3: Hub Model (BCA 3) -- Replace the existing statewide legacy administrative systems (USAS, USPS, SPA, SPRS, HRIS, TINS) with a new, fully integrated, commercially-available ERP system that the Comptrollers Office would operate as an Application Service Provider (ASP) for all State agencies with the exception of the Health and Human Services (HHS) agencies. The HHS agencies and institutions of higher education would operate under a decentralized processing model as data reporting Hubs and would be interfaced into the Statewide Data Warehouse platform and their transactional data would be interfaced into the new ERP system.
Approach and Deliverables

Four groups were identified to provide data and information to support the BCA analysis: A subset of 182 State agencies surveyed in November 2007. This group was composed of twenty-four (24) of the States largest and most complex agencies as selected by the Comptrollers Office and represents at least 97% of the States total FY 2007 expenditures. System stakeholders that represent the existing statewide administrative systems, including: Uniform Statewide Accounting System (USAS); State Property Accounting (SPA); Texas Identification Number System (TINS); Uniform Statewide Payroll/Personnel System (USPS); Standardized Payroll/Personnel Reporting System (SPRS); and Human Resource Information System (HRIS).
Higher Education System Offices that represent all institutions of higher education except for Stephen F. Austin University, Texas Southern University, Texas Womans University, Midwestern State University, and Texas State Technical College. Members of the Information Technology Council for Higher Education (ITCHE) that is composed of representatives of: The Texas A&M University System; The Texas State University System; The Texas Tech University System; The University of Houston System;
Page 3
September 30, 2008
The University of North Texas System; The University of Texas System; and Texas Womans University.
The deliverables associated with the Study include the following: Documentation of the alternative scenarios to be analyzed; High-level assessment of existing administrative systems; Development of Cost Estimates for the Status Quo, and the alternatives to be evaluated; Development of Avoided Costs (costs that would no longer be incurred if a statewide ERP system was implemented) for the alternatives to be evaluated; Development of Process-improvement Savings (process efficiency savings that would be achieved if a statewide ERP system was implemented) for the alternatives to be evaluated; Development and documentation of the business case to support each alternative to be evaluated; Recommendation of a specific alternative to be pursued to address the States statewide administrative system needs; High-level implementation plan documenting a recommended approach for deploying the recommended solution across State government (and higher education as applicable); and Funding plan to support the recommended alternative to be pursued.
Key Findings
As a result of our analysis of survey responses and interviews with key stakeholders within the Comptrollers Office and across State government, we identified the following key findings: A total of 1,220 administrative system functional modules (General Ledger, Accounts Payable, etc.) are currently utilized to address the functional areas addressed in HB 3106. More than twenty (20) human resources/payroll systems are in operation across the State and three (3) statewide payroll and personnel reporting systems are in existence for validation and reporting (USPS, SPRS, HRIS). There are significant redundancies in functionality and capabilities of the three systems that could be consolidated to reduce the complexity of the reporting function and significantly reduce the cost of operating and maintaining the platforms. Of the total number of functional systems in operation across the State, roughly one-third (1/3) are custom developed solutions and roughly one-quarter (1/4) are statewide systems. The remaining systems are a mixture of various commercial off-the-shelf systems (COTS) and somewhat evenly spread across PeopleSoft, SunGard and MIP with the Other leading all categories at 13%.
Page 4
September 30, 2008
Each agency and institution (except those utilizing the USAS and USPS platforms as their processing system) must interface their systems into the existing Statewide systems resulting in more than 250 interfaces in operation that must be managed, maintained, and reconciled across the State at both the statewide and agency/institutional levels. Data is fragmented across a wide array of systems and platforms, which makes it difficult to generate management information on a timely and accurate basis due to differences in formats, cycle times, and controls across all systems, which leads to complications in preparing enterprise (statewide) reports. This results in a lack of confidence by the States citizens and their elected leaders. Each of these systems has its own ongoing operating and maintenance costs for hardware, software and infrastructure which, in the aggregate, could represent significant savings through consolidation and standardization. In order to roll-up the fragmented data to a statewide level, manual, labor intensive processes must be performed to reconcile, update and adjust the data across the various systems and interfaces. This effort represents a significant cost to the State and dramatically reduces the efficiency and effectiveness of the States business processes. Because the current statewide administrative systems do not meet many of the States business needs, the States administrative business processes are less efficient and effective than they could be. As an example, the State is unable to track method of finance for all transactions, resulting in a significant information gap regarding what money was used and in what ways, which is especially critical in times of budget constraints. To address critical unmet needs, agencies have expended significant amounts of money on their own ERP and/or best-ofbreed systems. Instead, these funds could be spent toward the implementation of a single, statewide ERP system that would benefit all agencies. The State does not utilize a statewide procurement system at this time, which causes the following deficiencies: Other than the agencies that already use ERP systems, the majority of other agencies follow manually-intensive business processes or maintain standalone systems or spreadsheets to address their procurement needs. Manually-intensive processes and redundant data entry tend to be slow, error-prone, and costly; Lack of integration of procurement function with financial accounting and other administrative systems; Most purchasing organizations lack the transaction data (at the proper commodity code level) required to effectively negotiate with suppliers; and Most procurement managers spend much of their time chasing paperwork rather than managing their supplier base or negotiating better prices.
The existing statewide administrative systems were developed and implemented

based on user and State business requirements that are now more than fifteen (15) years old. As new requirements have emerged, the State continues to patch
Page 5
September 30, 2008
or rewrite the systems to meet or comply with the new, point-in-time requirements. The cost of maintaining these systems continues to escalate due to the difficulty of locating skilled personnel to make the changes as well as the overall limitations of the original system architecture (e.g., often changes must be made to the actual computer code instead of simply changing data table entries to make the changes). The State Property Accounting System is 15 years old. It does not support accounting standards enacted in recent years. Therefore, inefficient manual reconciliation and rework is required. Insufficient internal system controls necessary to maintain the integrity of transaction data have caused State audit concerns. TINS lacks the ability to ensure that funds are not paid to individuals indebted to the State. Instead of netting all payments against amounts owed, the State pays some individuals in full and, therefore, misses an opportunity to recoup funds owed. The existing statewide systems are not providing adequate protection for confidential state employee information and are not in compliance with the information security, data privacy and accessibility regulations, exposing the State to possible lawsuits and public relations risks.
Business Case Analysis Results

The State spends approximately $9 million per year to maintain and operate the existing statewide administrative systems such as USAS, TINS, SPA, etc. Additionally, the Comptroller and the State agencies/institutions need to spend approximately $121 million combined to rewrite the statewide administrative systems and deploy these new systems across Texas government over the next few years. These rewrites are intended to address major system deficiencies, eliminate the need for HRIS, address risks associated with the current use of Social Security Number, and lack of compliance with Section 508 of the Americans with Disabilities Act regarding accessibility. From a financial-analytical perspective, Alternative 3 is by far the best of the three (3) alternatives evaluated in this BCA. Under Alternative 3, all but approximately $35.4 million of the estimated $335.2 million 11-year cost to implement and operate a new statewide ERP system would be offset by systems costs that would likely be spent by the State on systems that provide functionality relatively comparable to that provided by a new ERP system (i.e., Avoided System Costs), but without achieving the processimprovement benefits that could potentially be realized by implementing an integrated statewide system (i.e., Value Pocket benefits). The estimated $128.3 million in processimprovement benefits would exceed this $35.4 million shortfall by $92.9 million during the 11-year planning timeframe, and at a discount rate of 5% per annum, that $92.9 million would provide a Net Present Value (NPV) for Alternative 3 of $60.5 million and reach breakeven/payback in Year 8 of the initiative (see table below).
Page 6
September 30, 2008
Schedule of Estimated Net Costs and Benefits/Savings from Implementing ERP Alternative 3
($ millions)
Acquire Fin / Proc / HR / Pay Yr 0 Yr 1 Yr 2 Cost and Benefits/Savings Categories FY 2009 FY 2010 FY 2011
Yr 3
Yr 4
Yr 5
Yr 6 FY 2015
Yr 7 FY 2016
Yr 8
Yr 9
Yr 10 FY 2019
FY 2012 FY 2013 FY 2014
FY 2017 FY 2018
T otal (335.2) 299.9 (35.4)
ERP Costs (implementation & operation) Avoided System Costs N et before Process-Improvement B enefits C umulative Net before ProcessImprovement Benefits Process-Improvement Benefits -Agencies (Value Pockets) Process-Improvement Benefits -Higher Ed (Value Pockets) N et after Process-Improvement B enefits C umulative Net after ProcessImprovement Benefits PV of Net after Process-Improvement B enefits C umulative PV of Net after ProcessImprovement Benefits N PV (Yr 0 through Yr 10) @ 5% per annum N PV (Yr 0 through Yr 10) @ 8% per annum
(1.8) (1.8) (1.8) (1.8)
(44.7) 122.0 77.3 75.5 77.3
(45.4) 0.9 (44.4) 31.1 1.9 (42.5)
(37.4) 1.9 (35.5) (4.4) 2.0 (33.5)
(44.9) 10.6 (34.3) (38.7) 2.1 (32.2)
(28.6) 16.4 (12.3) (51.0) 13.5 1.2
(45.6) 23.2 (22.4) (73.3) 17.3 (5.1)
(20.8) 29.1 8.3 (65.0) 23.0 31.3
(21.3) 30.6 9.3 (55.7) 22.1 31.5
(21.9) 32.0 10.1 (45.6) 22.8 32.9
(22.7) 33.0 10.2 (35.4) 23.5 33.7
128.3 92.9
(1.8) (1.8) (1.8) 60.5
75.5 73.6 71.8
33.0 (38.5) 33.3
(0.5) (28.9) 4.3
(32.7) (26.5) (22.1)
(31.5) 1.0 (21.2)
(36.5) (3.8) (25.0)
(5.2) 22.2 (2.7)
26.2 21.3 18.6
59.1 21.2 39.8
92.9 20.7 60.5 60.5
48.1
Note that of the estimated $335.2 million 11-year cost to implement and operate a new statewide ERP system, approximately $248.5 million would be spent over a 7-year implementation period (Yr 0 through Yr 6) on the ERP implementation, and the remaining $86.7 million would be spent on operating and maintaining the new ERP system. The $248 million would be spent as described below:
FY09 Planning; Statewide ERP Requirements Development; Procurement of ERP Integration Services FY10/11 Develop ERP Blueprint; 32 Agency Deployments FY12/13 92 Agency Deployments; Replace Statewide System FY14/15 11 Agency Deployments; Replace Remaining Statewide Systems Total ERP Project Cost $1,805,000 90,101,000 82,336,000 74,216,000
$248,458,000
Alternative 2 is much less attractive than Alternative 3 from a financial-analytical perspective. We estimated that it would cost $930.3 million to implement and operate a new ERP system under Alternative 2 over the 11-year planning timeframe of this BCA. As illustrated below, the Net Present Value (NPV) for Alternative 2 is -$295.9 million,
Page 7
September 30, 2008
assuming a discount rate of 5% per annum, or -$266.4 million, assuming a discount rate of 8% per annum. The investment would be far from breaking even during the 11-year analysis period of the BCA (-$352.8 million see the Cumulative Net after ProcessImprovement Benefits row in the table below). Schedule of Estimated Net Costs and Benefits/Savings from Implementing ERP Alternative 2
($ millions)
Acquire Yr 0 FALSE (2.6 ) (2.6 ) (2.6 ) (2.6 ) (2.6 ) (2.6 ) (2.6 ) (2 95.9 ) (2 66.4 ) Fin / Pr oc / H R / Pa y Yr 1 Yr 2 FYE 2010 FYE 2 011 ( 4.0 ) 12 2.0 11 8.0 11 5.5 11 8.0 11 5.5 11 2.4 10 9.8 (1 62 .9) 0 .9 (1 61 .9) (46 .5) (1 61 .9) (46 .5) (1 46 .9) (37 .0) Yr 3 FYE 2 012 ( 163 .3) 1 .0 ( 162 .3) ( 208 .8) 2 .0 ( 160 .3) ( 206 .8) ( 138 .5) ( 175 .5) Yr 4 Yr 5 Yr 6 Yr 7 Yr 8 Yr 9 Yr 10 FYE 2 0 13 FYE 201 4 FYE 2015 FYE 2 016 FYE 201 7 FYE 2018 FYE 2 019 (1 00 .4) 30 .1 ( 70 .4) (2 79 .1) 2 .1 ( 68 .3) (2 75 .1) ( 56 .2) (2 31 .7) (7 7.6 ) 2 4.3 4.4 (4 8.9 ) ( 32 8.0 ) 3.7 (4 5.1 ) ( 32 0.2 ) (3 5.4 ) ( 26 7.1 ) (7 0.9) 2 8.7 8.5 (3 3.6) (3 6 1.6) 1 5.4 (1 8.3) (3 3 8.5) (1 3.6) (2 8 0.7) (15 0 .9 ) 4 0 .4 1 1 .7 (9 8 .7 ) (46 0 .3 ) 2 2 .1 (7 6 .6 ) (41 5 .0 ) (5 4 .4 ) (33 5 .1 ) (6 0.8 ) 4 3.0 1 3.8 (4.1 ) (4 6 4.4 ) 2 3.4 1 9.4 (3 9 5.7 ) 1 3.1 (3 2 2.0 ) (96 .6 ) 44 .7 19 .6 (32 .3 ) (4 96 .7 ) 24 .4 (7 .9 ) (4 03 .6 ) (5 .1 ) (3 27 .1 ) ( 40. 4) 46. 0 20. 1 25. 8 (4 71. 0) 25. 1 50. 9 (3 52. 8) 31. 2 (2 95. 9) ( 29 5.9 ) 11 8.2 ( 35 2.8 )
C ost a nd Be nefits/Sa vings Categories ERP C os ts (i mp le me nta tio n & op e ra tio n ) Av oide d Sys te m C osts -- Age nc ie s Av oide d Sys te m C osts -- HE N et be fore Pr oces s -I mpr ovem e nt B ene fits C um ula tive Ne t be for e P roce s sIm prove m ent B ene fits Proc es s -I mprov em e nt Be nefits -Age ncie s (Va lue Po cke ts ) Proc es s -I mprov em e nt Be nefits -Higher Ed (Va lu e Po ck ets) N et a fte r Proc e ss- Im pr ove me nt B ene fits C um ula tive Ne t a fte r Pr oc ess Im prove m ent B ene fits PV of N et a fte r Pr oce ss Im prove m ent B ene fits C um ula tive PV of Ne t a fte r Pr oc ess -Impr ove m ent B ene fits N PV (Yr 0 thr ough Yr 10 ) @ 5 % pe r a nnum N PV (Yr 0 thr ough Yr 10 ) @ 8 % pe r a nnum
Tot al ( 93 0.3 ) 38 1.2 7 8.2 ( 47 1.0 )
Please note that the totals in the schedule above may reflect variances due to rounding.
Summary Recommendations
The following are the key recommendations for the Comptroller and the ERP Advisory Council to consider when evaluating future ERP plans for Texas State government and higher education. Recommended Business Case Alternative STA recommends that the Comptroller implement the BCA 3: Hub Model scenario as its solution for addressing statewide ERP system needs. Under BCA 3: State agencies (with the exception of the Health and Human Services agencies) would migrate to a new Statewide ERP platform operated by the Comptrollers ASP service; Health and Human Services agencies and the Higher Education Systems would operate as reporting Hubs and interface directly into the Statewide Data Warehouse; Existing statewide legacy administrative systems (USAS, USPS, SPA, HRIS, SPRS, TINS) would be replaced by the Statewide ERP system that would provide all functionality identified in HB 3106;
Page 8
September 30, 2008
Each Hub would be able to operate its own platform with the only restriction being that the Hub reporting capability conforms to the statewide data standards and standard business processes required for statewide reporting; and The Statewide ERP baseline code would be made available to every Hub and would be patched and maintained according to the ERP vendors recommended schedule. Our BCA 3 recommendation is based upon the following reasons: The State achieves business process standardization based on best practices, economies of scale and efficiency gains through the implementation of a single, unified platform for almost all State agencies Provides for a statewide procurement system that will be fully-integrated with the financial accounting, asset management, and inventory management modules, as well as the Comptrollers Online Ordering System currently in development. A statewide procurement function would provide numerous benefits to the State, including increased competition for the States business, lower inventory carrying costs, reduced printing and mailing costs, reduced procurement cycle times, reduced maverick spending, and a level playing field for small/disadvantaged businesses. Additionally, the State should obtain the spend intelligence necessary to make effective strategic sourcing decisions at the statewide level. Addresses HB 3106 requirements and the Comptrollers Rider 16 regarding fleet management. Complies with the ERP Advisory Councils guiding principle of not throwing out what works by leveraging the considerable work done to date by Higher Education and the Health and Human Services agencies in implementing their own ERP systems. Allows the State to significantly upgrade the functionality and reporting capabilities of its statewide administrative systems and resolves the fragmentation associated with the States existing administrative systems environment. BCA 3 total project implementation costs are considerably less than the costs associated with BCA2 and are only $35.4 million more than BCA1 over the 11year planning timeframe of this BCA. For an additional $35.4 million, the State could address numerous deficiencies with their existing systems the State will need to spend approximately $121 million in rewrites of the existing administrative systems, which will do nothing more than pave the cow path. In addition, BCA 3 is a proven model that is most often utilized by other states and would result in lower overall project risk. Establishes a common language for reporting expenditures and provides for significantly enhanced statewide reporting which will facilitate a single source of the truth and taxpayer transparency. Allows the State to comply with recent data privacy, accessibility and information security mandates.
Page 9
September 30, 2008
Provides for better tracking of the States $104 billion in assets, thus helping agencies and the Legislature in budget planning by identifying replacement costs and schedules. Allows for the Hubs to address ERP consolidations through an evolutionary process as their existing systems reach the end of their useful lives. Recommended Deployment Approach Only the State agencies (excluding the Health and Human Services agencies and higher education) would be deployed under this model. The participating agencies would be logically organized into deployment groups or waves. All functional modules would be deployed for all agencies within a specific group or wave. The first deployment phase would include the development of a prototype deployment model that would become the blueprint for deploying all functionality among the remaining agency deployment waves upon the successful deployment for the initial agency wave. Each deployment phase would be executed sequentially until all agencies have been deployed on the statewide ERP system. For cost estimating purposes, STA and the Comptroller Project Team developed a detailed deployment schedule for State agencies under BCA 3. This planning schedule will be made available to the Comptroller as part of project close-out activities. The schedule was used solely for the purposes of developing our estimates and the Comptroller has not made any decisions or plans regarding the deployment schedule should an actual ERP project be funded by the Legislature. Additionally, ITCHE members and HHSC representatives assisted us in determining the years in which the Hub data warehouses would be placed into production. PeopleSoft as the Statewide ERP Baseline Should the State acquire funding to pursue the acquisition of a new ERP system and associated implementation services, several procurement strategy decisions will be required, including a decision as to whether to acquire ERP software through a competitive bid process or seek to continue its investment already made in Oracles PeopleSoft Enterprise Financial Management, Enterprise Supplier Relationship Management, and Human Capital Management software. STA recognizes that unique benefits exist should the State continue to utilize the PeopleSoft ERP software suite as the baseline software for the new Statewide ERP System. In fact, STAs recommendation of BCA 3 and the associated estimated costs for BCA 3 are based on the Comptroller continuing the relationship with PeopleSoft. STA estimates that there is up to a 30% reduction in total implementation costs as a direct result of reuse value of PeopleSoft. These reuse benefits include (but are not limited to): The PeopleSoft software has already been implemented by some of the large and most complex agencies and institutions of higher education in the State of Texas. This experience provides considerable documentation and lessons learned from these implementation experiences that cannot be replaced. Additionally, this experience considerably reduces overall project risk. The Health and Human Services, University of North Texas System and University of Houston Systems use PeopleSoft to address their administrative system needs within their component organizations. Additionally, the University
Page 10
September 30, 2008
of Texas System has made a significant investment in PeopleSoft software as well. This should streamline the statewide interfacing and reporting effort required of these Hub organizations. The Comptrollers technical resources have considerable experience with the PeopleTools proprietary toolset to support software configuration, customization, establishing security, and ongoing administration of the system, therefore, reducing the burden of training and retaining these resources. The Comptrollers functional resources have considerable experience with the PeopleSoft product to support the set-up and configuration as well as comprehensive training documentation and experience, which will help facilitate the training effort. Some of the States requirements that were gaps have been incorporated into the statewide baseline, which will reduce the amount of time spent modifying the product for State of Texas needs. Some standard reports and queries have been created that can be leveraged for all State agencies, which will reduce the amount of time and dollars spent during the implementation. The following states have implemented or are in the process of implementing the PeopleSoft financial management and human resources/payroll applications in a statewide environment: Connecticut, Delaware, Georgia, Indiana, Montana, New Mexico, New York, North Dakota, Ohio, Oklahoma, Tennessee, and Vermont. Additionally, the following states have implemented or are in the process of implementing the PeopleSoft human resources/payroll applications only in a statewide environment: Hawaii, Kansas, Massachusetts, and Minnesota. In consideration of expanding the use of the PeopleSoft ERP platform, STA also recommends that the State renegotiate the following issues with Oracle: The State should seek to obtain reduced rates for annual maintenance and future increases in maintenance fees should be based on reasonable parameters (e.g., lower of 3% of the previous year's maintenance fees or the increase in the Consumer Price Index). The State should only pay for software licenses based upon the agency deployment schedule and that annual maintenance should be calculated based upon only those agencies that have been deployed and for modules in use during the period. New functionality that arrives in the form of repackaging the PeopleSoft application suite (e.g., e-applications including eSettlement and eBill Payment) should be included in the negotiated licensing agreements with the State for the Statewide ERP platform.
Page 11
September 30, 2008
SECTION 2 INTRODUCTION
In late June 2008, the State of Texas (State) Comptroller of Public Accounts (Comptroller) initiated a study to develop a comprehensive business case analysis and related strategic planning associated with enterprise resource planning (ERP), as directed by House Bill 3106 (HB 3106) of the 80th Texas Legislature. The Comptroller engaged the consulting firm of Salvaggio, Teal & Associates (STA) to assist in the study. STA has provided or is currently providing statewide ERP advisory services for the following states: Arkansas, Kansas, Kentucky, Louisiana, Minnesota, Mississippi, Nebraska, Nevada, Tennessee, Virginia, and Wisconsin. This report documents their work effort and the results of the study.
Background and Purpose of Study

In May of 2007, the 80th Texas Legislature passed HB 3106, which addressed the concept of ERP for the State of Texas. From a practical standpoint, the term ERP for the State of Texas refers to an integrated software package that provides functionality similar to that offered in the existing statewide administrative systems (e.g., USAS, SPA, USPS, SPRS) as well as critical functionality currently provided by agency administrative systems. HB 3106 requires the Comptroller to set clear standards for the implementation of ERP software for the State. The Legislation also required the Comptroller to establish an Enterprise Resource Planning Advisory Council to develop a plan that contains key requirements, constraints, and alternative approaches for the Comptrollers implementation of ERP standards, including related core functionality and business process reengineering requirements. The Council is comprised of representatives from the Department of Information Resources (DIR), Health and Human Services Commission (HHSC), ITCHE, Texas Comptroller of Public Accounts, and two State agencies selected by the Comptroller with fewer than 100 employees (Texas Commission on the Arts and Texas Soil and Water Conservation Board). The guiding principles established by the ERP Advisory Council are as follows: Through workgroups and committees, we will engage statewide agencies and institutions of higher education in the project; We will establish and implement standardized business processes where possible; We will establish and implement common data standards where possible; We must ensure future ERP system projects are compatible with statewide standards; We will not throw out what works; and We will adapt our processes to the software rather than the software to our processes.
Page 12
September 30, 2008
The project to develop the Statewide ERP Plan (Plan) is led by the Comptroller of Public Accounts. The purpose of the Plan is to explore ways to integrate data and processes into more cohesive and standardized systems for the highest levels of efficiency. The deadline for completing the Plan is December 2008. The Legislation requires the Comptroller to report to the Legislature on progress made toward implementing the Plan prior to each legislative session. This report must include any planned modifications and/or upgrades to existing statewide and agency-specific administrative systems and the associated financial impact of said modifications and upgrades. The Legislation defined the organizational scope to include all State agencies and institutions of higher education, and the functional scope to include the following application areas: General Ledger; Accounts Payable; Accounts Receivable; Budgeting; Inventory; Asset Management; Billing; Payroll; Projects; Grants; and Human Resources, including administration of performance measures, time spent on tasks and other personnel and labor issues. Though not included in the Legislation, the following functional areas were added to the Plan scope: Procurement. While not specified in HB 3106, the functionality is an integral component of an ERP system and procurement falls within the Comptrollers authority. Procurement is the functional area that typically obtains the greatest process efficiencies and potential cost savings in the transition to an integrated ERP system. Fleet Management. While not specified in HB 3106, the functionality is required in order to address Rider 16 which requires that the Comptroller implement and maintain a State fleet data management system for agencies to report fleet operating expenses and uses, as required by Chapter 2171.101, Government Code. The system must be accessible through a web-based interface, provide forms for efficient entry of data required by the State Vehicle Fleet Management Plan, allow agencies to batch load relevant data from internal legacy systems, provide fiscal and managerial reports for both direct asset management and oversight needs, and be flexible enough to accommodate future agency or legislative needs.
Page 13
September 30, 2008
Data Warehousing. While not specified in HB 3106, it is assumed that a statewide data warehouse is required in order to provide functionality necessary to meet the States present and future analysis and reporting requirements, and to address the Comptrollers new standards for transparency and accountability in State spending. Additionally, the functional scope must specifically address the States existing statewide administrative systems: Uniform Statewide Accounting System (USAS); State Property Accounting (SPA); Texas Identification Number System (TINS); Uniform Statewide Payroll/Personnel System (USPS); Standardized Payroll/Personnel Reporting System (SPRS); and Human Resource Information System (HRIS).
Major Assumptions / Qualifications

Any time a project of this nature is undertaken within a highly aggressive timeline, assumptions must be made that span the entire scope of the study. This study is supported by the following major assumptions: Due to the aggressive timeline associated with this project, all activities associated with this business case were focused on twenty-four (24) agencies as selected by the Comptrollers Office and the institutions of higher education that fall under the six (6) System offices. It should be noted the 24 agencies included in the study compose more than 97% of the States budget. As required in HB 3106, the Comptrollers Office mandated that higher education be included in the project scope. Only the functionality identified above was addressed for higher education; student information functionality that is the backbone of higher education operations was excluded from the scope of this study. Per the Comptrollers directive, any savings associated with strategic sourcing were excluded from the scope of this study. Per the Comptrollers request, STA was asked to utilize existing data collected from the State agencies and institutions of higher education in their survey undertaken in November 2007 to the maximum extent possible in order to reduce the data gathering effort required of the agencies and institutions. Business case development relied heavily on the ERP Advisory Councils guiding principals of standardized business processes, common data standards where possible, adaption to the processes inherent in the ERP software rather than modifying the software to meet existing processes, and not throwing out what works today.
Page 14
September 30, 2008
Benefits Administration functionality was excluded from the scope of this study as this functionality is provided by systems currently maintained by the Employees Retirement System and Teachers Retirement System. The statewide ERP system would utilize an automated interface to communicate with these systems as it does today. The Comptroller has initiated various ERP-related initiatives that may complement the findings and recommendations associated with our study, such as statewide work groups for accounts payable, asset management/inventory, fleet management, global data standardization, and statewide considerations, as well as internal workgroups to develop business process and data standards. Additionally, the Comptroller is considering how to address the immediate administrative system needs of some agencies, such as those currently on DIRs GFAS accounting system. Modifications to the assumptions listed above and elsewhere in this report may result in material changes to the results of the study.
Project Scope and Approach

This Business Case Analysis Study (Study) was initiated in June 2008. The purpose of the Study was to perform a series of tasks that will provide the ERP Advisory Council and the State Comptroller with the data and other information necessary for determining whether implementing a statewide ERP system is viable for the State of Texas at this time. The deliverables that were produced during the Study include the following: Documentation of the solutions to be analyzed based on concurrence with the Comptrollers Project Team; High-level assessment of existing administrative systems; Development of Cost Estimates for the Status Quo, and the alternatives to be evaluated; Development of Avoided Costs (costs that would no longer be incurred if a statewide ERP system was implemented) for the alternatives to be evaluated; Development of Process-improvement Savings (process efficiency savings that would be achieved if a statewide ERP system was implemented) for the alternatives to be evaluated; Development and documentation of the business case to support each alternative to be evaluated; Recommendation of a specific alternative to be pursued to address the States statewide administrative system needs; High-level implementation plan documenting a recommended approach for deploying the recommended solution across State government (and higher education as applicable); and Funding plan to support the recommended alternative to be pursued.
Page 15
September 30, 2008
Participants
Though the Study was completed under an aggressive timeline, care was taken to obtain State agency and higher education participation to the extent possible. Such participation included the following: Orientation meetings were held with agency Chief Financial Officers (CFOs), Chief Information Officers (CIOs), and other subject matter experts in preparation of data gathering efforts that support STAs high-level assessment of existing systems and business case development. Additional meetings and web conferences were conducted with those agencies that failed to attend these meetings. A total of 78 CFOs, CIOs, and subject matter experts attended these meetings. Representatives of STA and the Comptrollers Project Team visited each Higher Education System Office. These meetings included representatives of the System Office and some of their component institutions. A total of 24 higher education professionals attended these meetings. Representatives of STA and the Comptrollers Project Team attended two meetings with the Information Technology Council for Higher Education. Representatives of STA and the Comptrollers Project Team participated in two (2) meetings with the State agency and higher education CFOs and CIOs. Representatives of STA and the Comptrollers Project Team participated in one (1) monthly meeting with the ERP Advisory Council.
Definition of an ERP System

An ERP system is a suite of fully integrated software applications that are used to perform administrative business functions such as financial accounting, procurement, and personnel administration. What distinguishes ERP systems from stand-alone best-of-breed administrative software solutions is the integration that allows for more efficient processing and eliminates redundant data entry and reconciliation tasks. The functionality provided by ERP systems is usually provided in major groupings or modules. These modules typically address the major administrative functions within State government: financial accounting and management, human resources and payroll administration, procurement and logistics, and budget development. Additionally, certain features such as automated workflow and electronic approvals, security, reporting/data warehousing, and the development toolset cross all functional modules.
ERP FUNCTIONALITY COMPONENTS

Acounts Payable Accounts Receivable Budget Dev. Asset Mgmt Inventory Mgmt Billing Projects Grants Procurement Personnel Admin Payroll Time Reporting Fleet General Ledger (includes Budgetary Control and Chart of accounts) Security Workflow and Electronic Approvals Reporting Data Warehousing Development Toolset
Page 16
September 30, 2008
The functional modules of an ERP system that the State would need to implement were included in the scope of this study, including:
Financial Management
General Ledger The General Ledger is an integrated central repository of statewide financial data. Numerous types of financial transactions are recorded in the General Ledger, both directly and through data received from other ERP modules and from interfacing external systems. The General Ledger is the key module used in financial reporting. The chart of accounts is established and maintained in the General Ledger. Additionally, budgetary control is established and enforced through this module. Traditionally, this module is implemented first as most other modules require some interaction with the General Ledger. Additionally, the General Ledger provides: Basic fund accounting; Corrective and/or adjusting journal entries; Interfund/interagency transaction processing; Month-end and year-end closing; State and federal reporting; Real-time budget checking; Budget maintenance and monitoring; Budget adjustments; Governmental Accounting Standards Board (GASB) compliance; Cost allocation; and Labor distribution. A General Ledger module should be integrated with other functional modules to allow for efficient and effective sharing of data. Accounts Payable The Accounts Payable module addresses the various means by which the State pays for goods and services. The module is used to record liabilities and payments. The automated matching process takes place in this module. Before a payment is processed, a successful match must be completed and sufficient budget must exist to cover the payment. The Accounts Payable module shares the vendor file with the Purchasing module. Additional functionality provided by this module includes: Invoice processing; Automated matching process (purchase order (PO), receiving report, invoice); Payment and remittance processing (discounts, holds, warrant/check printing, direct deposit, and handling);
Page 17
September 30, 2008
Budget checking prior to payment processing; Automatic liquidation of encumbrances when payments are made; Automated bank reconciliation; Electronic funds transfer; Form 1099 processing; and Employee reimbursement. Accounts Receivable and Billing (includes Cash Receipting) The Accounts Receivable module is used to record receivables and payments received against specific customer accounts. Billing functionality supports the processing of billings and generation of new receivables. Most systems also provide functionality to support the collection process (e.g., dunning notices). This module will also support cash drawer and lockbox processing, though some customization may be required, and should be compatible with industry-standard third party cash register products. This module would only be used by organizations that maintain accounts receivable, have a need for an automated billing function, and/or handle cash. Budget Development The Budget Development module enables the development of the States budget at the agency (operating) and the statewide (appropriation) levels. Budget Development integrates with both Human Resources to facilitate salary projections and General Ledger to upload budgetary data for budgetary control. This module is intended to support the analysis of historical expenditure and budgetary data, allow what if analyses, salary and position budgeting, salary projections, and other types of forecasting. Budget development functionality required by sophisticated governments has been the weak link in ERP systems to this point, so many governments address their budget preparation needs through electronic spreadsheets or third party budget development applications. That said, there have been significant functional enhancements to the budget development modules recently in order to make ERP systems a viable solution for potentially meeting statewide and agency-specific budget development needs. Grant Accounting / Management Basic Grant Accounting modules support the establishment of a grant budget and the recording of expenditure activity against the grant budget and pre-defined grant budget categories. These modules also allow for the reporting of grant activity by period or over the life of the grant award. More sophisticated Grants Management modules allow for the recording of detailed information about each grant, grant application activity, as well as grant drawdown activity.
Page 18
September 30, 2008
Project Accounting / Management Project Accounting modules address the recording, tracking, and reporting of financial data for projects and contracts. These modules typically address the key processes for operating and capital projects, including budget development, project development, execution, and the project close process. Project Accounting modules typically support the establishment of a project budget (which is typically linked to a funding source), and the recording of expenditure activity against the project budget (by pre-defined project task or activity). These modules also allow for the reporting of project activity by period or over the life of the project.
Procurement and Logistics

Procurement The Procurement module provides traditional procurement functions such as requisitioning, solicitations, purchase order processing, contract management, and goods and/or services receipt. Vendor and commodity maintenance is also addressed in this module. Recent eProcurement initiatives support web-based vendor registration, online catalog procurements, pushing of procurement opportunities to vendors based on the commodities serviced, and web-based solicitations. The Purchasing module will automate and integrate the entire purchasing process, from purchase requisition to the receipt of goods and services, eliminate a significant amount of duplicate data entry, and shuffling of hard copies of documents. It will also provide for full accounting integration (e.g., automatic creation of a pre-encumbrance when a purchase requisition is approved, automatic creation of an encumbrance and liquidation of the associated pre-encumbrance when a purchase order is approved). Vendor self-service functionality allows vendors to complete the following functions through the Internet: Register as a vendor to the State; Maintain authorized data elements (e.g., goods/services they provide by commodity, contact information); and View the status of transactions (e.g., PO issued, goods received, invoice received, payment requested). Asset Management The Asset Management module is used to capture and maintain information associated with the organizations leased, capitalized, and non-capitalized assets. Information maintained in this module includes acquisition cost, asset type, location, asset description, model number, serial number, insurance information, and replacement cost. The Asset Management module provides the ability to track assets for internal control purposes versus financial reporting purposes. The module provides for the automatic flagging of an item as an asset when it is processed in the Purchasing module and automatic recognition of the asset at the time of receipt or payment in the Accounts
Page 19
September 30, 2008
Payable module. The module also provides the ability to define what assets will need to be depreciated, as well as the method of depreciation appropriate for each asset. Specific areas of functionality include: Asset creation, Asset maintenance (including transfers), Asset depreciation, Asset disposal, and Asset retirement. The software will support maintenance of the following types of assets: Capitalized asset -- asset that has a value equal to or greater than the capitalization threshold established for that asset type. Capitalized assets are reported in an agencys annual financial report (AFR). Comptroller-controlled asset -- asset that has a value less than the capitalization threshold established for that asset type, however due to its highrisk nature, is required to be reported to the Comptroller. Controlled assets are not reported in an agencys AFR. Locally controlled asset -- asset that is not capitalized or on the Comptrollerscontrolled asset list, but is tracked and accounted for as mandated by agency management. Inventory Management The Inventory Management module supports the establishment, storage, tracking, and disposal of Inventory items, automated Inventory replenishment at pre-defined reorder points, and recording of all Inventory activity. The Inventory module is typically integrated with the Purchasing and Accounts Payable modules, and checks the General Ledger for funds availability when replenishing goods in Inventory. This module would only be used by organizations that maintain warehouse inventories. Fleet Management Fleet management functionality has recently become an offering of ERP vendors. Traditionally, this functionality has been provided by specialized best-of-breed software applications. Fleet Management functionality includes asset identification, parts Inventory maintenance and processing, work order processing for maintenance and repairs, and vehicle history tracking. More advanced applications also provide fuel supply management, mileage tracking, warranty management, accident tracking, risk management, and performance analysis and reporting. This module would only be used by organizations that maintain large vehicle fleet operations.
Page 20
September 30, 2008
Human Resources
Personnel Administration The Personnel Administration module provides for the maintenance of personnel information pertaining to each employee from application through retirement. This information includes the following: Basic demographic and address information, Emergency contact data, Organizational and funding source data, Employment history, and Personnel actions (demotion, promotion, salary increase, leave without pay). Position Control The Position Control module supports the maintenance of all budgeted and authorized positions. More specifically, position control allows users to perform the following tasks: Provides edits to ensure that no personnel action can take place without an available qualified and active position, Tracks and reports budgeted, filled, frozen and vacant positions, Links positions to a funding source, and Links positions to required skills, certifications, etc. Compensation The Compensation module enforces the administration of the State's rules for calculating pay. In addition, this module includes specific functions as follows: Maintains effective salary dates, Calculates future pay increases, Calculates additional pay based on flexible, user defined criteria, Calculates step, increment, and percentage pay increases for all or a group of employees, Projects costs for future fiscal years, and Provides analysis of compensation by Chart of Account element. Payroll The Payroll Module provides for the calculation, production, and distribution of payroll warrants and the processing of direct deposits. In addition, this module provides the following additional functionality: Maintains salary, deduction, and pay history and totals by employee and fund,
Page 21
September 30, 2008
Complies with State and Federal payroll tax withholding and reporting requirements, Supports retroactive and manual payments, and various pay cycle frequencies, Calculates benefit deductions based on rules specified in Benefit Administration module, and Calculates pay based on user-defined criteria (e.g., pay status, overtime rules). Payroll modules in some ERP systems now provide employee travel reimbursement processing as well. Time Reporting and Employee Leave Accounting Time Reporting addresses the administration of the State's rules for capturing and calculating time. This module includes functions to: Support positive and negative (exception) time entry, Provide online time entry and the charging of time to pre-defined Chart of Accounts elements, Calculate overtime hours and eligibility, Support flexible definition of shift and work schedules, and Provide flexible workflow for review and approval of automated timesheets. Leave Accounting addresses the administration of the State's rules for granting and using the various types of employee leave. In addition, this module provides the following features to: Calculate leave eligibility and leave availability, Allow employees to request leave online with automatic routing for approval, Notify employees of leave that will be lost or automatically paid, Integrate leave types with Benefits Administration and Payroll, and Track leave taken, leave lost, and leave payments by leave type and reason. Benefits Administration The Benefit Administration module supports the comprehensive administration of multiple employee benefit, retirement and insurance plans. In addition, this module addresses the ability to: Maintain multiple eligibility rules, Maintain eligibility dates for different plans based on different rules, Track eligibility and enrollment of dependents, Maintain beneficiary information, Calculate employer and employee costs, Provide online (Web based or kiosks) and telephone benefit enrollment,
Page 22
September 30, 2008
Interface with benefit providers and third party administrators, Provide functionality to ensure compliance with Consolidated Omnibus Budget Reconciliation Act (COBRA) requirements, and Track information related to Health Insurance Portability and Accountability Act (HIPAA) requirements. It is expected that this module will not be required as the functionality identified above is provided by systems currently maintained by the Employees Retirement System and Teachers Retirement System. The statewide ERP system would utilize an automated interface to communicate with these systems as it does today. Applicant Services This module provides functionality to support the application process associated with a new job posting. Additionally, this module includes the capability to: Manage recruiting of both internal and external candidates, Manage testing requirements and results, and Support the submittal of applications and resumes through the web. Training and Employee Development Training and Employee Development addresses the management of employee training and skills. Additionally, this module includes the capability to: Provide standard career development curriculum based on position, skill category, and other criteria; Allow employees to request training online and route request for appropriate approvals; Record training session attendance, grades, costs, certifications, etc.; Track classes and courses needed for career / job progression planning; and Track training class prerequisites. Employee Self Service Employee self-service allows State employees to perform common functions previously performed by human resources and payroll administration staff through a web browser or kiosk after entering their authorized user ID number and password. Some functions typically accessed through the web by State employees include: Viewing pay stub and withholding information; Changing basic employee information (e.g. address change); Changing benefit options; Checking leave balances and requesting time off; Initiating travel authorization requests and travel reimbursement requests; Checking the status of the travel reimbursements; and
Page 23
September 30, 2008
Registering to attend a training course. This module will reduce the amount of time spent processing transactions relating to reimbursement and advances for employee travel.
System-Wide
Security Security is used to regulate who has access to what information. ERP systems typically offer a comprehensive security function that provides for: User log-in; Row level (record) security; Data field level security; Restricted access to specific screens or processes; Object security; and User group security. Workflow Workflow allows for the establishment of business rules, roles, and routings that are used to route electronic documents (e.g., purchase requisition, timesheet) to proper supervisors and management for approval. Governments most often use workflow in conjunction with procurement and personnel administration processes. Workflow facilitates an organizations transition to a paperless environment. To work properly, Workflow typically requires configuration and a degree of standardization of approval processes across the enterprise. For this reason, it is best to limit the number of workflows to be implemented. Reporting ERP systems typically provide a suite of reporting tools that are used to develop ad hoc reports and online queries. Data Warehouse More and more governments are utilizing data warehouses to address their enterprise reporting requirements. These data repositories collect data from the ERP system and other external data sources after being normalized. Various financial reports can then be generated from the Data Warehouse. Additionally, the Data Warehouse is typically a key component in addressing taxpayer transparency initiatives. Development Toolset Each ERP vendor provides a suite of tools that are used to configure, customize, troubleshoot, and maintain the application software. The toolset is usually proprietary to each specific vendor.
Page 24
September 30, 2008
SECTION 3 HIGH-LEVEL ASSESSMENT OF EXISTING SYSTEMS

Background and Purpose
The purpose of this assessment is to obtain a high-level understanding of the States administrative systems, their strengths and weaknesses, functionality being provided by each system, functionality not being provided, potential process-improvement opportunities, as well as the degree of interfacing/integration across the various systems. Our assessment was completed based upon our review of the following elements: The following statewide administrative systems were included in our assessment: USAS; SPA; TINS; USPS; SPRS; HRIS; and Integrated Statewide Administrative System (ISAS not a true statewide system that is mandated for use, but is an ERP system that is maintained by Comptrollers Office and has a large user base).
Surveys of existing administrative systems were completed by twenty-four (24) of the States largest and most complex agencies as selected by the Comptrollers Office. Interviews and other data gathering efforts were completed for the following system offices that support the States institutions of higher education: University of Texas System; Texas A&M University System; Texas Tech University System; Texas State University System; University of Houston System; and University of North Texas System.
Additional meetings were held with the ITCHE to validate the results of our assessment.
Page 25
September 30, 2008
Data Gathering Approach

In November 2007, the Comptrollers Office developed a survey that was sent to all State agencies and institutions of higher education to capture high-level information regarding their administrative systems and expenditures related to the application scope listed in HB 3106. The purpose of the survey was to determine which systems were in place in the various State agencies and institutions of higher education, and what funding was being spent to deploy, operate and maintain these systems. Additionally, the Comptrollers Office wanted to identify the amount of expenditures that were planned over a five-year time horizon to replace, upgrade or maintain these systems. The November 2007 survey methodology included 182 State agencies and institutions of higher education and asked each organization to capture data related to the following categories: Identify applicable FY08 encumbrances and projected annual expenditures for hardware/software maintenance costs related to business systems; Identify encumbrances and projected annual expenditures for contract staff; Identify payroll records and time accounting estimates for direct application support costs; Estimate costs based on projected expenditures for additional software, hardware, contractor and State human resources FTEs required to complete the upgrade or implementation; and Identify State and contractor FTE counts working on administrative systems from time accounting system records. The survey also asked each agency and institution to document their individual technical environments that support the systems and applications included under the scope of HB 3106, including the following: 1. System Information a. Software name/vendor or in-house system; b. Hardware platform; 2. Annual Maintenance Cost Information a. Software maintenance costs; b. Hardware maintenance costs; c. Human resource costs for hardware and software maintenance; 3. Planned System Information from FY 2008 through FY 2013 a. Date of next planned upgrade; b. Estimated cost of upgrade; c. Date of planned implementation; d. Estimated cost of implementation; 4. Personnel Requirements Full-Time Equivalent Resources
Page 26
September 30, 2008
a. Functional FTEs Personnel that are involved in supporting the functional side of the application(s); and b. Technical FTEs Personnel that are involved in providing technical support for the application(s). All 182 agencies and institutions of higher education responded to the survey and the results were tabulated. The total number of agencies and institutions that were operating the applications under the scope of ERP as defined by HB 3106 were compiled as follows:
Administrative System Functional Area
No. of Agencies or Institutions Utilizing
Overall % (Based on Total of 182)
General Ledger Payroll Accounts Payable Budgeting Asset Management Human Resources Purchasing/Procurement Accounts Receivable Grants Inventory Billing Projects
182 181 179 175 175 153 128 113 103 95 92 73
100% 99% 98% 96% 96% 84% 70% 62% 56% 52% 50% 40%
The survey identified the total estimated cost for annual operation and maintenance of the systems across State government at over $88 million, including: Annual software maintenance at $17 million; Annual hardware maintenance at $9 million; and
Page 27
September 30, 2008
Staffing and labor performing system or application maintenance totaling $62 million and representing approximately 950 FTEs. Anticipated system upgrades, enhancements and replacements totaled over $144 million over the six-year period, according to the survey results. This amount included the following elements: Planned system or application upgrades totaling $27 million; and Planned system replacement or implementation costs totaling $117 million. Based upon a six-year time horizon, the November 2007 survey yielded total system and application costs for the applications included within the scope of HB 3106 of $672 million or roughly $112 million on an annualized basis. This total may be somewhat understated given that well over 50% of the agencies and institutions did not have enough information to be able to project their future costs for system upgrades and implementations. In June 2008, the Comptroller of Public Accounts initiated the ERP Business Case Analysis (BCA) study as a component of the overall Statewide ERP Plan effort to help determine which of the following three (3) alternatives to pursue related to the ERP direction for the State: Business Case Alternative 1 (BCA 1) -- Continue on the States current path of operating existing systems for each agency/institution in accordance with the results of the Comptrollers November 2007 survey. Business Case Alternative 2 (BCA 2) -- Replace the existing statewide legacy administrative systems (e.g., USAS, USPS, SPA, SPRS, HRIS) with a new, fully integrated, commercially-available ERP system that would provide all functionality identified in HB 3106. One (1) statewide ERP system for all agencies and all institutions of higher education (HE) would be established and operated by the Comptroller. Business Case Alternative 3 (BCA 3) -- Replace the existing statewide legacy administrative systems (e.g., USAS, USPS, SPRS, SPA, HRIS) with a new, fully integrated, commercially-available ERP system that the Comptrollers Office would operate as an Application Service Provider (ASP) for all State agencies with the exception of the Health and Human Services (HHS) agencies. The HHS agencies and institutions of higher education would operate under a decentralized processing model as data reporting Hubs and would be interfaced into the Statewide Data Warehouse platform. Four (4) groups were identified to provide data and information to support the BCA analysis: 1. A subset of 182 State agencies surveyed in November 2007. This group was composed of twenty-four (24) of the States largest and most complex agencies as selected by the Comptrollers Office: Texas Education Agency Health and Human Services Commission
Page 28
September 30, 2008
Texas Department of Transportation Department of Aging and Disability Services Office of the Attorney General Department of State Health Services Texas Department of Criminal Justice Texas Workforce Commission Teacher Retirement System Department of Family and Protective Services Comptroller of Public Accounts General Land Office Department of Public Safety Texas Lottery Commission Texas Commission on Environmental Quality Department of Assistive and Rehabilitative Services Texas Higher Education Coordinating Board Texas Parks and Wildlife Department Governors Office Department of Housing and Community Affairs Texas Water Development Board Texas Railroad Commission Texas Public Finance Authority Employees Retirement System The total agency expenditures of this group of agencies represent at least 97% of the States total FY 2007 expenditures. 2. Higher Education System offices that represent all institutions of higher education except for Stephen F. Austin University, Texas Southern University, Texas Womans University, Midwestern State University, and Texas State Technical College. 3. Members of the Information Technology Council for Higher Education (ITCHE) that is composed of representatives of: The Texas A&M University System; The Texas State University System; The Texas Tech University System;
Page 29
September 30, 2008
The University of Houston System; The University of North Texas System; The University of Texas System; and Texas Womans University. 4. System stakeholders that support the following existing statewide administrative systems: USAS; SPA; TINS; USPS; SPRS; HRIS; ISAS; and HHSAS. The twenty-four (24) State agencies and statewide system stakeholders were asked to participate in a Business Case / Existing System survey in July 2008. The results of the survey were utilized in assessing existing systems and in developing the business case to support a new statewide ERP system. This survey was intended to build upon the data provided previously in the November 2007 survey, but also to expand the scope in order to obtain information that will be used to estimate: The cost to implement a new statewide ERP system; and The costs that would potentially be avoided if a new ERP system were implemented. The survey requested that each participating organization perform the following tasks: Confirm that the data submitted in the November 2007 survey response was still valid or make changes as necessary; Indicate whether the reported system would be retired if BCA 3 was implemented; Indicate whether the reported upgrade expenditures would be avoided if BCA 3 was implemented, along with the expected upgrade frequency if the upgrade expenditures would be avoided; Indicate whether the reported planned implementation expenditures would be avoided if BCA 3 was implemented; Provide the incremental dollar impact the avoided upgrade/implementation would have on the annual maintenance costs; Describe each application systems strengths and weaknesses, such as:
Page 30
September 30, 2008
Describe functionality not provided by each system, but needed, and explain why it is needed (e.g., would eliminate some amount of specific manual effort, etc.); Describe issues and risks associated with each system; and Describe any other weaknesses of each system;
Estimate the total systems costs over a ten-year horizon; Provide information on the interfaces currently in place between internal systems and any external systems, including existing statewide systems (e.g., USAS, SPA, USPS); and Provide an Application-Interface Diagram that depicts the organizations main applications within the scope of this analysis, along with the relevant interfaces. To capture information on the existing statewide systems, the Agency survey was modified slightly to address the data requirements of the statewide systems. Survey data was collected by the Comptroller Project team for the following statewide systems: USAS; SPA; TINS; USPS; SPRS; and HRIS. It should be noted that the focus of the Business Case/Existing System survey was BCA 3 only as the data needed for BCA 2 is a subset of the data submitted for BCA 3. To obtain information related to the institutions of higher education, members from the Comptroller Project Team conducted visits with each of the six (6) higher education System offices in order to gather data required for the existing systems assessment as well as for business case analysis purposes. The Comptroller Project Team also participated in work sessions with ITCHE in order to validate their data and obtain their feedback on selected project deliverables. The ERP Advisory Council convened an ERP workgroup to study and make recommendations concerning the format and use of a Texas unique business identifier (UBID) for individuals and entities receiving payments and/or doing business with Texas State agencies and institutions of higher education. Through this effort, the ERP workgroup: Examined mission-critical systems used across the State; Reviewed the data storage, security and usage of Social Security Numbers (SSN) in the identified systems; Determined which agencies and institutions currently use UBIDs that are not SSN-based and how they are assigned; and
Page 31
September 30, 2008
Reviewed existing policies and procedures in place at some agencies and institutions to provide SSN protection. The workgroup administered surveys to capture data regarding the use of SSN within the State, and the survey results revealed the following: More than 50 unique identifiers are in use by various agencies and institutions; Over 100 systems/processes utilize SSN data as a unique identifier and/or UBID; Several agencies use SSN as a primary key in their administrative systems/databases; and Multiple interfaces to statewide administrative systems and other systems exist that are dependent on SSNs. The goal of establishing a UBID was seen by the workgroup as having far-reaching effects. Depending on the ERP solution selected, the workgroup also concluded that the new ERP project should include the following requirements related to UBID: UBIDs should be unique, permanent, and never reused; The development of a UBID format should not contain SSNs; The UBID should be generated by the ERP system and used as the primary identifier; and SSN data should continue to be maintained in the system as required for reporting and interface activities. However, SSN data should not be displayed on screens and reports except for authorized users with specific business needs.
Description of Existing Statewide Administrative Systems

In 1987, the 70th Legislature enacted legislation that required the Comptroller's Office to make uniform the collection and reporting of statewide accounting, payroll and personnel data. Through this legislation, the Uniform Statewide Accounting System was established. Since 1987, the USAS effort has grown to include the following systems or planned projects: Statewide System or Project Human Resource Information System Texas Identification Number System TINS Rewrite (to update TINS) Uniform Statewide Accounting System State Property Accounting System Capital Asset System (to replace SPA) Uniform Statewide Payroll/Personnel System Implementation Date 1989 1989 Planned 2009 1993 1993 Planned 2012 1994
Page 32
September 30, 2008
Statewide System or Project Standardized Payroll/Personnel Reporting System Standardized Payroll/Personnel Reporting System for Higher Education
Implementation Date 2002 Planned 2008
Each of the systems listed above with a planned implementation date has been put on hold pending the outcome of the ERP Advisory planning effort. A description of each of these systems or new project initiatives follows. Human Resource Information System (HRIS) The Human Resource Information System (HRIS) is a custom developed, in-house application system that was programmed using the NATURAL programming and database access language. HRIS was implemented in 1989 as part of the first phase of the overall USAS implementation. HRIS operates on a mainframe platform and was designed to automate payroll and personnel reporting, and to act as a central repository for all personnel and payroll data for all State agencies and institutions of higher education. Agencies and institutions of higher education are responsible for processing and calculating their own payrolls and the resulting data was reported into HRIS to roll up payroll and personnel information at the statewide level. HRIS also maintains historical data such as information on former and current employees for inquiry, analysis and reporting purposes. HRIS supplies oversight agencies such as the Governor's Office, the State Auditor's Office, the Office of the Attorney General (OAG), Texas Workforce Commission Civil Rights Division, the Legislative Budget Board, and the Comptroller's Office with statistical information. Currently, HRIS is only used by institutions of higher education. The Comptrollers Office has identified several concerns related to the functionality and data controls of HRIS, including: Payroll reimbursements to institutions of higher education are paid without confirmation or control edits that the payments are appropriate. Additionally, limited data is reported after-the-fact rather than as part of a payroll reimbursement and validation process; HRIS deficiencies prohibit the Comptrollers Office from effectively monitoring and enforcing compliance with Accounting Policy Statements such as APS 5 and APS 11, related to funding sources and reimbursements for salaries and benefits; and Institutions of higher education do not currently report authorized salary information to HRIS nor do institutions report human resource information for all employees. Many employees in the student worker or casual worker population are not reported to HRIS. Texas Identification Number System (TINS) The Texas Identification Number System (TINS) is an in-house system that was implemented in 1989 and provides vendor/payee information to other critical statewide systems. Associated subsystems include warrant printing, ACH processing, held
Page 33
September 30, 2008
payments and payment inquiries. TINS captures information on individuals or entities that have received or may receive payments from the State of Texas, including state employees, state agencies, and other governmental entities. TINS maintains information such as the payees identifying information as well as the address and direct deposit account information that agencies use to remit payments. TINS also captures information on individuals or entities that are indebted to the State and facilitates the withholding of payments until their obligations to the State are met. TINS retains historical information to support inquiries on payments issued to specific entities over a period of time. In 2002, there was a large backlog of TINS application change requests that were waiting to be processed. The Comptrollers Office initiated a project to determine if the existing 15+ year old system should be modified to meet current and future business needs or if the system should instead be entirely rewritten. In August 2003, the TINS Feasibility Study was completed and based on the results, the Comptrollers Office decided to proceed with a rewrite of the system. The study revealed several major risks, including: Confidential information, including Social Security Numbers (SSNs), employee addresses and certain payment information is not being adequately protected; SSNs are embedded in payee numbers. Payee numbers are also exposed on widely available printed reports; TINS lacks the capability to store multiple identifying numbers such as SSN, ITIN, and FEIN, which are used to identify individuals indebted to the State. Additionally, debtors can assign their payments to others, thereby bypassing warrant hold. Payees are also being set up under more than one payee number allowing payees to bypass warrant hold; The Comptrollers Office estimated that it would take eleven (11) years with the use of eleven (11) full-time resources to develop and implement the entire backlog of application change requests for TINS; and Agencies can override payee information in the system and are circumventing payee direct deposit instructions by setting up new payment instructions for warrants. The TINS Rewrite project team completed the software requirements in 2005. Planned changes to the existing functionality included the following: The new system will replace Social Security numbers as the payee numbers with a randomly generated identification number to conform to privacy regulations and reduce the risk of identity theft; The new system will close gaps in the withholding payments process to reduce the number of payments made to debtors of the State; and The new system will automate several manual processes, improve process efficiency, and improve data consistency between TINS and State agencies payee information. The TINS Rewrite project encountered several delays over a three year period prior to the project being placed on hold, primarily due to resource constraints and contention for
Page 34
September 30, 2008
technical resources with other statewide systems such as USAS, USPS and SPRS. The cost to implement the TINS Rewrite project has been estimated at over $36 million with $9 million allocated for modifying the TINS source code and an additional $27 million to retrofit each of the 182 agency and institution interfaces. With the passage of HB 3106, the TINS Rewrite project has been put on hold pending the outcome of the ERP Advisory Councils plan for statewide ERP. Uniform Statewide Accounting System (USAS) In 1993, the State implemented KPMGs R*STARS mainframe financial accounting software to provide General Ledger, Accounts Payable and limited Accounts Receivable, Grant Accounting, Project Accounting and Contract Tracking functionality. The State licensed and modified the code to meet the States business process and statutory requirements. KPMG no longer supports or maintains the R*STARS product or code base. Of the 182 agencies and institutions of higher education surveyed in November 2007, eighty (80) State agencies use USAS as their internal accounting system. An additional 102 agencies and institutions function as reporting agencies that provide agency or institutional data through a standard reporting interface from their internal systems. USAS provides both GAAP (Generally Accepted Accounting Principles) and cash basis accounting, and satisfies statewide accounting requirements. Financial data in USAS is used by the Comptroller's Office to produce state payments, agency reports, legislative reports, and reports for appropriation management and statewide budgets. USAS also performs specialized functions, such as budgetary and encumbrance accounting, cost allocation, payment processing, and document tracking. Accounting data is entered into USAS either through online entry or via electronic (FTP) batch input files. According to the Comptrollers records, USAS processed over 39 million transactions during Fiscal Year 2007. Major USAS accounting events include: 1. Budget accounting, including: Appropriation control; and Agency budget control. 2. Revenue cycle functions, including: Revenue estimates; Accounts receivable; Invoicing; Revenue accounting; and Cash receipts. 3. Expenditure cycle functions, including: Pre-encumbrances; Encumbrances; Expenditures and disbursements; and
Page 35
September 30, 2008
Payment generation/cancellation. 4. General ledger functions, including: General ledger accounting; Journal entry processing; and Long-term liabilities recording. USAS also contains six subsystems: Project accounting; Grant accounting; Recurring transactions; Program and cost accounting (cost allocation); Document tracking; and Reporting. USAS financial report categories include the following: General Ledger Reports - monitor agency general ledger balances and assist in the preparation of periodic GAAP reports; Budgetary Reports - monitor appropriations and agency, grant, and project budgets. Budgetary reports contain budgetary information as well as revenue and expenditure information; Operating Reports - contain revenues, expenditures, transfers, and other nominal activities summarized by classification-level elements. Operating Reports allow financial activity to be monitored at all levels; Document Reports - provide information related to Pre-encumbrances, Encumbrances, Accounts Receivable, and Vouchers Payable. Document Reports monitor activity at the document level; Transaction Reports - contain information regarding posted transactions and assist agencies in researching and analyzing balances; and Subsystem Reports - provide transaction and audit trail activity specific to a subsystem. State Property Accounting System (SPA) The State Property Accounting (SPA) system, implemented in 1993, is an in-house developed system for tracking capital and controlled assets. There are 112 agencies that use SPA as their internal fixed asset system while 99 other agencies report their asset data to SPA. SPA contains the capital asset balances for the State of Texas and the data is utilized for the Comprehensive Annual Financial Report (CAFR) to prepare the Capital Asset Note to the Financial Systems. The total balance for Capital Assets for the State according to the 2006 CAFR is $97.8 billion, which is 54% of the States total assets. The SPA system is also used to enforce the provisions of Section 12.04 of the General Appropriations Act (GAA), which requires the Comptrollers Office to withhold
Page 36
September 30, 2008
from State agency and institution of higher education appropriations an amount equivalent to 50% of the value of lost property. SPA is also relied upon to comply with various open records requests. In 2004, a feasibility study was conducted related to SPA to determine risks and recommended actions. The following deficiencies were identified: 1. SPA does not adequately support asset Inventory under Generally Accepted Accounting Principles (GAAP) and more specifically Government Accounting Standards Board (GASB) Statements 34 and 35. 2. SPA does not currently support the ability to reduce the cycle time for producing the CAFR due to the manual reconciliation and rework required for SPA data and table maintenance. 3. SPA does not have sufficient internal system controls to systematically maintain the integrity of transaction data. The lack of controls requires the use of extensive manual, labor intensive control processes. In 2005, the Capital Asset System (CAS) project was initiated to replace SPA with a new system. After reviewing various alternatives, the decision was made to modify and update the original KPMG R*STARS fixed asset module (purchased as part of the original USAS project) to become the replacement system for SPA. The planned updates and modifications included the following: 1. Achieve the original USAS design of an integrated fixed asset subsystem; 2. Make the module compatible with all USAS modifications and enhancements since inception, including Year 2000 considerations; and 3. Upgrade the module to ensure compatibility with current GAAP/GASB standards (GASB 34). CAS was scheduled to go live in March 2011 and is estimated to cost approximately $20 million to implement. The system development and implementation cost is estimated at approximately $2.4 million and the interfaces changes for 90 agencies are estimated to be approximately $18 million. However, with the passage of HB 3106, the project is on hold pending the outcome of the ERP Advisory Councils plan for statewide ERP. Uniform Statewide Payroll/Personnel System (USPS) In 1994, the Uniform Statewide Payroll/Personnel System was implemented using a modified version of the GEAC Human Resources mainframe software product. USPS is the internal payroll/personnel system for 113 State agencies and 79,700 employees. Institutions of higher education were originally slated to be deployed on USPS in a later phase of the project, thereby allowing for the retirement of the mainframe HRIS platform at some point in the future. Unlike HRIS which was and is primarily focused on statewide reporting of payroll and personnel data, USPS was established to actually process payroll transactions for State agencies as well as to accomplish two additional objectives:
Page 37
September 30, 2008
Payroll Calculation Standardization -- to ensure that all State agency employees will have their pay calculated in a consistent manner and that all claims against the State are legitimate; and Easier Access -- to give the Legislature and other oversight agencies the ability to have online access to payroll and personnel information across all State agencies. A project to remediate the use of Social Security Numbers within USPS has been estimated at over $30 million total. The system changes have been estimated at $2.2 million. However, due to a network of interfaces across USPS, USAS, SPRS and HRIS, the interface costs are estimated at approximately $28 million. Standardized Payroll/Personnel Reporting System (SPRS) In 1997, with the advancement of client/server technology for human resource applications, the 75th Legislature modified the statute, Section 2101.035 (d), (e), (f) and (g) of Subtitle C., Texas Government Code, which had previously required that all State agencies use USPS as their internal payroll/personnel system, to allow the Comptroller to designate a standardized payroll calculation on one or more systems. This legislative change in direction gave State agencies and institutions of higher education an option to migrate off of the USPS platform to license and implement either a commercial off-theshelf software application or design their own internal payroll and personnel processing system. Each agency was allowed to pursue this approach for payroll/personnel if they independently determined that the USPS mainframe product was not consistent with that agencys desired technical architectural direction. As a result of the 1997 legislation, several State agencies moved forward to license and implement the PeopleSoft suite of Human Resources and Financial applications to do their internal payroll and personnel processing. However, it was still necessary for the new payroll/personnel systems to meet the States statutory obligations from earlier legislation, including: 1. Validation of claims processing; 2. A standardized, uniform payroll calculation; and 3. Statewide reporting requirements of payroll/personnel data. The Comptrollers Office began reviewing their options to determine the best method by which they could meet the statutory obligations. After evaluating several options, the Comptrollers Office ultimately decided to develop a new system to capture necessary data elements from the agencies' internal personnel/payroll systems, validate the information before payrolls are processed and post the validated personnel and payroll information. The resulting system became the Standardized Payroll/Personnel Reporting System (SPRS), an in-house developed, custom application system to answer the needs of State agencies that chose not to implement USPS. In 2002, SPRS was implemented and captured reporting data for seven (7) State agencies that are utilizing the PeopleSoft HR applications and one State agency that developed their own payroll system using the DB2 database platform. SPRS maintains payroll and personnel information for over 89,000 State employees. With the implementation of SPRS, all State agencies were moved off the HRIS platform.
Page 38
September 30, 2008
However, the 1997 legislation that allowed agencies and institutions to utilize other platforms had the result of allowing institutions of higher education to stay with HRIS for reporting personnel and payroll data instead of moving to USPS. The implementation of SPRS allowed the Comptroller to continue meeting its statutory obligations of processing valid claims, fulfilling statewide reporting requirements, and ensuring, via post-payment audit, a standardized payroll calculation. However, the primary objective of SPRS was basically to provide a system for capturing and validating uniform personnel and payroll information for agencies not on USPS, including all institutions of higher education, who were allowed to still report into the HRIS system. Currently, statewide reports are generated by extracting data from three payroll/personnel systems. The Comptrollers Office is required to produce or assist with producing reports on equal employment information (Texas Workforce Commission), new hire data (Attorney Generals Office), and Veterans data (Texas Legislature). Many State agencies, including the Legislative Budget Board, State Auditors Office, Governors Office and Legislature rely on the Comptrollers statewide systems for costing information, fiscal notes, statewide data, and new hire information for child support enforcement. After the implementation of SPRS, the Comptrollers Office determined that it was not cost effective for the State to operate, maintain and reconcile (3) separate payroll and personnel reporting systems (HRIS, USPS and SPRS) and their related interfaces. It was recognized that there were significant redundancies in functionality and capabilities that could be consolidated to reduce the complexity of the reporting function and significantly reduce the cost of operating and maintaining the platforms to the State. Standardized Payroll/Personnel Reporting System (SPRS) for Higher Education In order to reduce the number of mainframe platforms and statewide system interfaces for personnel/payroll data in operation by the State, the Comptrollers Office initiated a project in 2003 to modify SPRS to meet the current and future reporting needs for Texas institutions of higher education and ultimately retire the HRIS application and platform. This project was named SPRS for Higher Education. In addition to eliminating the need for HRIS, other objectives included: Reducing the number of statewide system payroll/personnel interfaces from three (HRIS, USAS, TINS) to one (SPRS); Ensuring statutory compliance with State and federal mandates for employee benefits and entitlements; Improving the accuracy, consistency and integrity of data reported by institutions to reduce the number of Comptroller audit findings and discrepancies between institutional and Comptroller data; and Including validated higher education personnel/payroll data in a database to be used by State agencies and institutions in the new hire/interagency transfer process. Data would include previous state employment history and length of service for determining longevity pay and other mandated entitlements. The SPRS for Higher Education project was put on hold in 2004 in order to redirect technical resources towards the HHSC consolidation effort. The project was resumed in
Page 39
September 30, 2008
2005 and continued through the requirements phase and the technical design and development phase in 2006. The Comptrollers Office estimates that the SPRS for Higher Education project will cost over $5.5 million to develop and implement and an additional $24 million to develop the required interfaces to each institution of higher education for a total project estimate of approximately $30 million. With the passage of HB 3106, the SPRS for Higher Education project has been put on hold pending the outcome of the ERP Advisory Councils plan for statewide ERP.
Inventory of Existing Agency/Higher Education Administrative Systems

The Business Case/Existing System survey (July 2008) and the November 2007 survey identified the total number of functional systems in place across 182 agencies and institutions of higher education. The table below shows the breakout of functional systems across State government. Column A shows the total number of application systems that are operated and maintained by individual agencies or institutions. For example, there are 120 Accounts Payable systems across the State that are operated and maintained by an agency or institution. Column B shows the number of agencies and institutions utilizing a statewide system for processing this function. For example, there are 89 agencies or institutions utilizing the Statewide State Property Accounting (SPA) system for the Asset Management function.
A Functional Modules in Operation at Agencies/Institutions Functional Area
B Agencies/Institutions Utilizing Statewide System Modules for Function
General Ledger Accounts Payable Accounts Receivable Budget Asset Management Inventory Billing Projects Grants Purchasing
116 120 113 141 86 90 92 71 81 128
66 59 0 34 89 5 0 2 22 0
Page 40
September 30, 2008
A Functional Modules in Operation at Agencies/Institutions Functional Area
B Agencies/Institutions Utilizing Statewide System Modules for Function
Payroll Human Resources Total Modules
76 106 1,220
105 47 429
The Total line shows that there are 1,220 administrative system functional modules in operation across the State that are operated and managed by individual agencies or institutions. In terms of the systems in operation at both the Statewide and the agency/institution level, the breakdown of type of system is depicted on the chart that follows:
SunGard 8% Other 4%
PeopleSoft 12% Oracle 2% SAP 1% MIP 4%
In-House 30%
Statewide System 26% Other COTS 13%
Of the total number of functional systems in operation across the State, roughly one-third (1/3) are custom developed solutions and roughly one-quarter (1/4) are statewide systems. The remaining systems are a mixture of various commercial off-the-shelf systems (COTS) and somewhat evenly spread across PeopleSoft, SunGard and MIP with the Other leading all categories at 13%.
Page 41
September 30, 2008
It should be noted that considerable effort has been made by the higher education System Offices to migrate their component institutions across a common ERP software solution and data warehouse: The Texas Tech University System is in the process of migrating its administrative business processes to the SunGard Banner ERP solution. The University of Houston System and University of North Texas System have migrated to Oracles PeopleSoft ERP software solution. All components of the Texas A&M University System utilize the Systems custom BPP System for human resources/payroll business processes, while sixteen (16) of the nineteen (19) component institutions use the Systems custom FAMIS application to address their financial management business processes. The components within the University of Texas (UT) System currently utilize a variety of software applications to address their administrative system needs; however, five (5) components have implemented the PeopleSoft ERP software and the UT System recently purchased a license from Oracle that allows all components of the UT System to utilize the software. The Texas State University System has standardized on the SunGard Banner product suite for ERP with two exceptions: Texas State University San Marcos utilizes SAP ERP software Sam Houston State University utilizes a custom-developed system to meet their administrative system needs.
All of the six Higher Education Systems above are in various stages of development of a data warehouse that supports reporting from their ERP systems. These efforts range from pre-implementation planning to near completion (e.g., Texas Tech University System). With the exception of those institutions not currently assigned to a university system, the functional systems in use by all Institutions of Higher Education are shown in the table below.
Page 42
September 30, 2008
Current Statewide Interfacing System Model

State law requires agencies to report their expenditures to USAS for reporting and controlling all expenditures of funds in the State Treasury. USAS operates as the financial system of record for the State of Texas. Eighty (80) agencies use USAS as their primary accounting system and no interfaces are required. One-hundred and two
Page 43
September 30, 2008
(102) agencies and institutions have been designated as reporting agencies and 102 interfaces have been developed from agency and institution-specific solutions to USAS. Agencies and institutions also must report personnel and payroll information into statewide reporting systems, including USPS, SPRS and HRIS. The diagram that follows documents the high-level integration points between State agency/higher education systems and the various statewide administrative systems.
High Level Statewide Systems Diagram
Uniform Statewide Accounting System (USAS) (General Ledger, Accounts Payable, Grants, Projects)
Reporting Agency Interfaces (46) ISAS USAS Internal AGY (80)
Courts (21) Regulatory (32) Legislative (4) Natural Resources (4) General (12) Public Safety (7)
TINS
HE Reporting Interfaces (56)
SPRS
USPS
TCEQ
Austin
UT System
UTSW-D Arlingtn UTB UTD UTEP UTHSC-H UTHSC-S UTHSC-T MDACC UTMB
HHSC (5)
Tyler
HRIS
UTSA UTPB UTPA
DFPS DSHS DARS DADS TDCJ TWC Other Reporting AGYs GOV Lottery THECB GLO TPFA TxDOT TEA OAG ERS TWDB TRS RRC TDHCA TPWD Univ. of N. Texas System
UNT UNT-HSC SR-Rio SHSU
TAMU System
TAMU CorpCh INTL King PView Texark Galv West Comm Tarl St TEES VetMed AgriLife TAExS Forest TTI TEExS
CPA
Legend Agency Group or HE System
Texas Tech System

Tx Tech Angelo TTUHSC
TAMUHSC
Texas St System
TxState
UH System
UH
NonSystem
TWU MWStU SFASU
Application System Agency or Institution Health-related Institution Logical System Interface or Data Flow System Usage
UH-CL SRSU UH-D UH-V Lamar
TSU TSTC
USAS, SPRS, HRIS, TINS and SPA accept batch input transactions from the agency systems. USPS also accepts timecard, reportable income and leave batch input. USAS, USPS, SPRS, HRIS, TINS and SPA also produce output files that include posted and unposted transactions and database table extracts to the agencies and institutions of higher education. TINS vendor set-up and maintenance is received from the USPS, SPRS and HRIS systems. USPS and SPRS send and receive files from USAS to validate payrolls and produce deduction payments. It should be noted that in completing this assessment, STA obtained ApplicationInterface Diagrams from each of the twenty-four (24) agencies included in the Business Case / Existing System Survey. These diagrams depict the organizations main applications within the scope of this analysis and the relevant integration/interface points for the various systems. The High-Level Statewide Systems Diagram presented above
Page 44
September 30, 2008
does not reflect the numerous additional administrative systems and associated integration/interface touch points that must be maintained to provide the complete range of functionality needed by State agencies and institutions of higher education.
Summary of Findings
As a result of the data collected from and discussions held with State agencies, institutions of higher education, and the major stakeholders of the statewide administrative systems, our findings can be summarized as follows: According to the results of November 2007 survey, the systems portfolio in the State includes the following: A total of 1,220 administrative system functional modules (General Ledger, Accounts Payable, etc.) are currently utilized to address the functional areas addressed in HB 3106. More than twenty (20) human resources/payroll systems in operation across the State and three (3) statewide payroll and personnel reporting systems in existence for validation and reporting. Each agency and institution not utilizing the USAS platform as their processing system must interface their systems into some number of Statewide systems (including USAS, USPS, SPA, SPRS and TINS) resulting in more than 250 interfaces in operation that must be managed, maintained, and reconciled across the State at both the statewide and agency/institutional levels. Having such a fragmented legacy systems environment creates the following drawbacks: Data is fragmented across a wide array of systems and platforms, which makes it difficult to generate management information on a timely and accurate basis due to differences in formats, cycle times, and controls across all systems. Each of these systems has its own ongoing operating and maintenance costs for hardware, software and infrastructure which, in the aggregate, represent significant savings through consolidation and standardization. In order to roll-up the fragmented data to a statewide level, manual, labor intensive processes must be performed to reconcile, update and adjust the data across the various systems and interfaces. This effort represents a significant cost to the State and dramatically reduces the efficiency and effectiveness of the States business processes. Functionality that would allow the State to meet its objectives related to detailed financial and expenditure reporting (such as transparency) is difficult to develop and implement due to the number of source systems that must be updated. Fragmented systems result in a lack of data standardization therefore we do not speak the same language or provide State leadership or the taxpayers with a single source of the truth.
Page 45
September 30, 2008
Systems are difficult to use from an end user perspective due to the differing platforms and user interfaces (Windows, mainframe, etc.), resulting in reduced employee productivity and efficiency. The existing statewide administrative systems were developed and implemented based on user and State business requirements that are now more than fifteen (15) years old. As new requirements have emerged, the State continues to patch or rewrite the systems to meet or comply with the new, point-in-time requirements. This patch and rewrite cycle has resulted in the following consequences: Because the underlying processing platforms are not replaced, the State is unable to utilize changes and enhancements in the information technology industry and new and innovative ideas have to be retrofitted back into the States system environment; The cost of maintaining these systems continues to escalate due the difficulty of locating skilled personnel to make the changes as well as the overall limitations of the original system architecture; (e.g., changes must be made to the actual computer code instead of simply changing data table entries to make the changes); The State is exposed to significant risk due to the fact that the systems are not providing adequate protection for confidential state and employee information and are not in compliance with the American with Disabilities Act (ADA). This problem is compounded by the fact that the resources required to implement the changes are often reallocated to other higher priority projects. The State is currently maintaining three (3) statewide payroll and personnel reporting systems (USPS, SPRS, HRIS). SPRS is an accommodation for not requiring agencies to adopt USPS. HRIS is maintained at this point for the sole purpose of collecting human resources and payroll reporting data from the institutions of higher education. Considerable manual effort is required at times to reconcile, update and maintain the data in these three systems. There are significant redundancies in functionality and capabilities of the three systems that could be consolidated to reduce the complexity of the reporting function and significantly reduce the cost of operating and maintaining the platforms. A significant omission with the States existing statewide administrative system environment is the fact that no statewide procurement system exists for the State. Additionally, many agencies have no internal procurement system, which requires them to rely on manual processes, spreadsheets, or other home-grown shadow systems to keep track of agency procurement activity. A statewide procurement system would reduce purchase cycle time, reduce maverick spending that circumvents sourcing rules, and provide critical spend intelligence required for effective strategic sourcing decision-making. The current statewide systems do not meet agency-specific business needs or are considered cumbersome to use by the user community (e.g., grants management and accounting, asset management, payroll administration, vendor self-service, and employee self-service). As a result of these unmet needs:
Page 46
September 30, 2008
The States business processes are less efficient and effective than they could be due to fragmentation and the use of agency shadow systems; and Agencies continue to spend significant funds on systems with functionality that is contained in ERP systems these funds could be better spent toward the implementation of a single, statewide ERP system.
One of the most compelling reasons for utilizing commercial off-the-shelf software packages is that the vendor is responsible for maintaining the software based upon the common needs of the customer population. The cost of this new development and maintenance is funded through annual maintenance fees paid by the customer base and the benefits are spread across the entire user community, thereby lowering the overall cost of maintenance for each customer. Due to the age and the heavily modified/customized nature of the existing statewide administrative systems, the State is responsible for all expenses associated with maintenance and update of the statewide systems and platforms in response to changes in regulatory and business requirements. There are over 250 automated interfaces to and from agencies, institutions and the statewide administrative systems that must be operated and maintained on an ongoing basis. Whenever business or regulatory requirements change, depending on the magnitude of the change, there is a ripple effect across these interfaces that results in significant cost and effort to comply. The large number of system interfaces at the statewide level has a significant impact on overall process efficiency and transaction processing cost.
Potential Process-Improvement Opportunities

Based on data collected and interviews conducted during this phase of this study, STA offers the following potential process-improvement opportunities for consideration as Value Pockets in the Business Case Analysis phase of the study. The process improvements are identified by functional area in the table that follows.
Functional Area Process Improvements
Accounts Payable Increase utilization of vendor discounts. Reduce the amount of time spent preparing and mailing vendor remittance advices to vendors on direct deposit. Also reduce postage. Reduce the amount of time required each year to generate ad hoc and standard Accounts Payable reports that require retrieving data from multiple sources (i.e., USAS, agency shadow systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling payment transactions across
Page 47
September 30, 2008
Functional Area
Process Improvements
Accounts Receivable/Billing
multiple systems (USAS, agency shadow systems, etc.). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time spent entering invoice data into agency payable systems. Reduce the amount of time spent entering recurring payments into agency payment systems (i.e., entering the recurring payments from scratch each time a payment is to be made and not being able to use system functionality to automatically generate recurring payments). Reduce the amount of time spent processing vendor inquiries regarding the status of payments. Reduce the amount of time spent performing the matching process. Reduce the amount of time spent performing vendor file maintenance, including registering vendors and updating vendor information (e.g., commodity codes serviced, address, phone number, etc.). Reduce the amount of time spent reconciling procurement card transaction detail to USAS and procurement transactions in agency shadow systems. Reduce the amount of time spent processing and obtaining approvals for authorized business travel. Reduce the amount of time spent processing transactions relating to reimbursement and advances for employee travel.
Automated application of late charges. Reduce Accounts Receivable (AR) balances and carrying costs through improved data accuracy, visibility, and related communication resulting in faster collection of good receivables and fewer write-offs. Reduce the amount of time required each year to generate ad hoc and standard Accounts Receivable reports that require retrieving data from multiple sources (i.e., USAS, agency AR systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time required to track AR transactions
Page 48
September 30, 2008
Functional Area
spread over multiple AR/Billing systems (e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent each year researching, troubleshooting, and reconciling payment transactions across multiple systems (USAS, agency AR system, etc.). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time spent on customer billing. Reduction of bad debts Reduce the amount of time required to post remittance information captured via lockbox to the appropriate AR accounts.
Asset Management
Reduce the amount of time required each year to generate ad hoc and standard Asset Management (AM) reports that require retrieving data from multiple sources (i.e., SPA, agency AM systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time required to track transactions spread over multiple AM systems (e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent calculating and maintaining asset depreciation, as well as manually entering the resulting accounting entries into accounting and tracking systems. Reduce the amount of time spent each year researching, troubleshooting, and reconciling payment transactions across multiple systems (SPA, agency AM system, etc.). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems
Budget Development
Making adjustments in the appropriate system(s)
Reduce the amount of time required to develop and maintain appropriation budgets. This is the amount of time spent developing and maintaining the agency's appropriation budget -- preparing and distributing historical data; collecting and compiling data; performing what-if analyses; entering data into
Page 49
September 30, 2008
Functional Area
ABEST and USAS and other systems; and managing the appropriation budget during the fiscal year. Reduce the amount of time required to develop and maintain agency operating budgets. This is the amount of time spent in developing and maintaining the agency's operating budget -preparing and distributing historical data; collecting and compiling data; performing what-if analyses; entering data into agency shadow systems; and managing the operating budget during the fiscal year. Reduce the amount of time required to develop and maintain agency capital budgets. This is the amount of time spent in developing and maintaining the agency's capital budget -preparing and distributing historical data; collecting and compiling data; performing what-if analyses; entering data into USAS and other systems; and managing the operating budget during the fiscal year. Cost Allocation Reduce the amount of time required each year to generate ad hoc and standard Cost Allocation reports that require retrieving data from multiple sources (i.e., USAS, agency shadow systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling payment transactions across multiple systems (USAS, agency Cost Allocation system, etc.). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time required to track transactions spread over multiple Cost Allocation systems (e.g., avoid having to keep track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent manually entering Cost Allocation data into multiple systems (i.e., USAS and agency Cost Allocation systems). Reduce the amount of time required to monitor actual vs. budget status of expenditures (real-time budget checking and integrated encumbrance accounting). Reduce the amount of time spent performing year-end close.
General Ledger and Budgetary Control
Page 50
September 30, 2008
Functional Area
This is the amount of time spent performing system-related tasks pertaining to performing the year-end close, such as distributing data, compiling data, etc. Reduce the amount of time spent preparing the CAFR report. This is the amount of time spent performing system-related tasks pertaining to the preparation of the CAFR report, such as distributing data, compiling data, etc.). Inventory Reduce Inventory levels and carrying costs. Reduce the amount of time required each year to generate ad hoc and standard Inventory reports that require retrieving data from multiple sources (i.e., USAS, agency Inventory systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time required to reconcile Inventory data between USAS and Inventory systems used by agencies (i.e., Accounting data in USAS and Inventory transaction data in Inventory systems used by agencies). Reduce the amount of time required to track transactions spread over multiple Inventory systems (e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent processing Inventory reorders. Reduce overall the cost of vehicle downtime as a result of having better management information (i.e., more accurate, timely, and useful/meaningful). Reduce overall maintenance & repair costs as a result of having better management information (i.e., more accurate, timely, and useful/meaningful). Reduce the amount of time required to identify and obtain the right replacement parts. Reduce the amount of time preparing maintenance Work Orders. Reduce the amount of time required each year to generate ad hoc and standard Fleet reports that require retrieving data from multiple sources (e.g., SPA, agency Fleet Management systems, agency Maintenance & Repair systems, etc.). These processing tasks include: Extracting data from multiple sources
Fleet Management
Page 51
September 30, 2008
Functional Area
Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time required to reconcile Fleet-related data among multiple systems (e.g., SPA, agency Fleet Management systems, agency Maintenance & Repair systems, etc.). Reduce the amount of time required to track Fleet Management transactions spread over multiple systems such as SPA, agency Fleet Management systems, agency Maintenance & Repair systems (e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Procurement Generate revenue from fees charged to vendors for using eProcurement, as well as generate revenue from fees charged to vendors for value-added services provided as part of registration. Reduce cost of goods and services due to reduction in maverick spend. Reduce the amount of time spent on creating POs manually. Reduce the amount of time required each year to generate ad hoc and standard Procurement reports that require retrieving data from multiple sources (i.e., USAS, agency Procurement systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time required to receive procured assets in agency Asset Management systems, as well as in agency Procurement systems. Reduce the amount of time required to receive procured consumables (i.e., non-asset and non-Inventory items) in agency Procurement systems. Reduce the amount of time required to receive procured Inventory items in agency Inventory systems, as well as in agency Procurement systems. Reduce the amount of time spent processing formal (i.e., published) solicitations through procurement life cycle (requisition through award). These processing tasks include: Identifying and notifying registered vendors of the solicitation
Page 52
September 30, 2008
Functional Area
Distributing the solicitation--posting on the Web, mailing, etc. Receiving and recording vendor responses Tabulating/scoring vendor responses Notifying vendors of award decision Documenting award information Reduce the amount of time spent each year processing informal solicitations (i.e., solicitations not published but performed via phone call, e-mail, etc.) through procurement life cycle (requisition through award). These processing tasks include: Identifying and notifying registered vendors of the solicitation Distributing the solicitation--posting on the Web, mailing, etc. Receiving and recording vendor responses Tabulating/scoring vendor responses Notifying vendors of award decision Documenting award information Reduce the amount of time spent printing, and then faxing and mailing Purchase Orders, as well as reduce the postage required to mail the POs. Project Accounting/ Management Reduce the amount of time required to track Project Accounting transactions spread over multiple systems (e.g., avoid having to track transactions using spreadsheets, paper logs). Reduce the amount of time required each year to generate ad hoc and standard Project Accounting reports that require retrieving data from multiple sources (i.e., USAS, agency Project Accounting systems). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling project accounting transactions across multiple systems (i.e., USAS, agency Project Accounting system). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems
Page 53
September 30, 2008
Functional Area
Making adjustments in the appropriate system(s) Reduce the amount of time spent manually entering Project data into multiple systems (e.g., USAS and agency Project Accounting systems). Grant Accounting/ Reduce the amount of time required to process Grant draws Management that currently are manually requested. Reduce the amount of time required each year to generate ad hoc and standard Grant Accounting reports that require retrieving data from multiple sources (i.e., USAS, agency Project Accounting systems). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling payment transactions across multiple systems (USAS, agency Grant Accounting system, etc.). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time required to track Grant Accounting transactions spread over multiple systems (e.g., avoid having to track transactions using spreadsheets, paper logs). Reduce the amount of time spent manually entering Grant data into multiple systems (e.g., USAS and agency Grant Accounting systems). Applicant Services Reduce the amount of time spent notifying applicants of interviews, results, etc. Reduce the amount of time spent processing applications and applicant inquiries. Reduce amount of time required to handle and mail remittance advices to employees. Reduce the amount of time spent entering/changing employee data, as well as researching and responding to employee inquiries. Reduce the amount of time spent processing other supplemental pay types (now calculated and entered manually). Reduce the amount of time required each year to generate ad
Payroll
Page 54
September 30, 2008
Functional Area
hoc and standard Payroll reports that require retrieving data from multiple sources (i.e., USAS, agency Payroll systems). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling payment transactions across multiple systems (USAS, agency Payroll system, etc.). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time required to track Payroll transactions spread over multiple systems (e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent manually entering Payroll data into multiple systems (e.g., statewide and agency Payroll systems). Personnel Administration Reduce amount of time spent maintaining employees' personnel information (employees maintain own information). Reduce the amount of time required each year to generate ad hoc and standard Personnel Administration reports that require retrieving data from multiple sources (i.e., statewide systems, agency Personnel Administration systems, etc.). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling Payroll transactions across multiple systems (e.g., USPS, SPRS, agency HR/Payroll system). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time required to track Personnel Administration transactions spread over multiple systems
Page 55
September 30, 2008
Functional Area
(e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent manually entering Personnel Administration data into multiple systems (e.g., statewide and agency HR/Payroll systems). Training Time Reporting Reduce the amount of time spent monitoring licenses and certifications. Reduce the amount of time spent on employee time entry (e.g., fewer data-entry errors, automatic prior-period adjustments, workflow routing for approvals). Reduce the amount of time spent processing requests for overtime. Reduce the amount of time required each year to generate ad hoc and standard Time and Labor reports that require retrieving data from multiple sources (e.g., agency Timekeeping systems, agency Grant and/or Project Management systems). These processing tasks include: Extracting data from multiple sources Compiling and reviewing data Formatting data into the reports Distributing the reports Reduce the amount of time spent each year researching, troubleshooting, and reconciling Time and Labor transactions across multiple systems (agency Timekeeping systems, agency Grant and/or Project Management systems). These processing tasks include: Investigating failed interface transactions Reconciling balance discrepancies between systems Making adjustments in the appropriate system(s) Reduce the amount of time required to track Time and Labor transactions spread over multiple systems (e.g., avoid having to track transactions using spreadsheets, paper logs, etc.). Reduce the amount of time spent manually entering Time and Labor data into multiple systems (e.g., agency Timekeeping systems, agency Grant and/or Project Management systems). Reduce the amount of time required to generate ad hoc and standard reports that require retrieving data from multiple sources (i.e., data across various HE components/ HHS agencies and System offices to address statewide reporting requirements). These processing tasks include: Extracting data from multiple sources
Reporting
Page 56
September 30, 2008
Functional Area
Compiling and reviewing data Formatting data into the reports Distributing the reports
Page 57
September 30, 2008
SECTION 4 WHY ERP?

There are numerous reasons why the State should consider implementing an ERP system. The major drivers that support the implementation of a statewide ERP system can be grouped into 3 categories: (1) legacy system deficiencies, (2) technology enablers, and (3) the results of the Business Case analysis. The results of the Business Case Analysis are discussed in Section IV of this report. Legacy system deficiencies and technology enablers are discussed below.
Legacy System Deficiencies

The greatest justifications for implementing a statewide ERP system are attributable to the shortcomings of the existing statewide administrative systems and the workarounds required by user agencies to address these deficiencies. Specific points that support this conclusion are provided below. Fragmented Legacy Administrative Systems Environment Numerous administrative systems are required to meet statewide and State agency administrative business needs. More than 1,220 administrative system functional modules are currently utilized to address the functional areas addressed in HB 3106. Agencies are running in excess of 100 information technology (IT) environments to support the existing administrative systems, resulting in redundant hardware, software, maintenance, and operational costs. More than twenty (20) human resource/payroll systems are in operation across the State and three (3) statewide payroll and personnel reporting systems exist for validation and reporting. The current statewide administrative systems do not meet the States business needs. Examples of critical functional needs that are not being addressed include procurement, asset management, project accounting, grant accounting, and employee self-service. Each agency and institution not utilizing the USAS platform as their accounting system must interface their administrative systems into the existing statewide administrative systems (e.g., USAS, USPS, SPA, SPRS and TINS), as appropriate. This requirement results in more than 250 interfaces in operation that must be managed, maintained, and reconciled across the State at both the statewide and agency/institutional levels. Having such a fragmented legacy systems environment has the following drawbacks: Much of the States financial, personnel and other administrative data originates and resides in various ERP and stand-alone systems that are not updated across systems in a real-time mode. Data maintained in independent databases or shadow systems can produce inconsistent information. This
Page 58
September 30, 2008
fragmented environment also results in a lack of data standardization and agencies and central authorities not speaking the same language. Because the data is fragmented, it is also difficult to generate management information in a timely and accurate manner. The existing administrative systems have insufficient reporting tools to facilitate ad hoc reporting. The end result is that report requests from State leadership and the Legislature often require a considerable amount of time to develop. Additionally, system users often need to access multiple statewide systems or make requests to the agencies and institutions to obtain the necessary data. Because of these multiple sources, reports typically require notes explaining the timing and accuracy of the data. The States administrative systems are costly to maintain and operate (e.g., data must be reconciled among the various systems and numerous interfaces must be maintained, etc.). Additionally, the Comptroller and the State agencies/institutions need to spend approximately $121,102,000 combined to rewrite TINS, SPA, SPRS for Higher Education, and USPS, and deploy these new systems across Texas government over the next few years. The purpose of these rewrites are intended to address major system deficiencies, eliminate the need for HRIS, address risks associated with the current use of Social Security Number and lack of compliance with Section 508 of the Americans with Disabilities Act regarding accessibility. The existing statewide administrative systems are difficult to use as they lack the modern, Windows-based, common user interfaces that system users are accustomed to using (e.g., e-mail, office applications, Internet browsing). Often State employees must work with several of these systems, and each system has its own unique look and feel. Because the current statewide administrative systems do not meet the States business needs, the States administrative business processes are less efficient and effective than they could be. As an example, the State is unable to track method of finance for all transactions, resulting in a significant information gap regarding what money was used and in what ways, which is especially critical in times of budget constraints. To address critical unmet needs, agencies have expended significant amounts of money on their own ERP and/or best-of-breed systems. Instead, these funds could be spent toward the implementation of a single, statewide ERP system that would benefit all agencies. The State Property Accounting System is 15 years old. It does not support accounting standards enacted in recent years. Therefore, inefficient manual reconciliation and rework is required. Insufficient internal system controls necessary to maintain the integrity of transaction data have caused State audit concerns. TINS lacks the ability to ensure that funds are not paid to all individuals indebted to the State. Instead of netting all payments against amounts owed, the State pays some individuals in full and, therefore, misses an opportunity to recoup funds owed. Additionally, TINS contains SSNs, Taxpayer ID numbers, and payment information that are not adequately protected.
Page 59
September 30, 2008
The systems are not compliant with Section 508 of the Americans with Disabilities Act regarding accessibility. Because of this, potential new end users who are physically impaired would require assistive devices for accessibility to the administrative systems. The States existing administrative systems do not provide for such accessibility, therefore, physically impaired workers cannot utilize these systems at this time. The State has considerable exposure to lawsuits initiated by physically impaired workers. Two states have already incurred such litigation: In 2003, three visually-impaired state employees from Pennsylvania and the National Federation of the Blind of Pennsylvania (NFBP) filed a lawsuit against the State and its governor. The suit asserted that the States multimillion-dollar computer system upgrade for use by all state employees was inaccessible to blind employees and, therefore, in violation of the Americans with Disabilities Act (ADA). In 2001, the Arkansas Administrative Statewide Information System (AASIS) had a similar accessibility problem as two visually-impaired state employees filed a lawsuit, to prevent further use of the information system without modification for accessibility. The judge issued an injunction on the States plan to roll out more components of the application that was deemed inaccessible. In turn, the State of Arkansas sued the software vendor contending the company did not fulfill its contract to develop the programs.
The State Does Not Have a Statewide Procurement System The State does not utilize a statewide procurement system at this time, which causes the following deficiencies: Other than the agencies that already use ERP systems, the majority of other agencies follow manually-intensive business processes or maintain stand-alone systems or spreadsheets to address their procurement needs. Manuallyintensive processes and redundant data entry tend to be slow, error-prone, and costly; Lack of integration of procurement function with financial accounting and other administrative systems; Most purchasing organizations lack the transaction data (at the proper commodity code level) required to effectively negotiate with suppliers; and Most procurement managers spend much of their time chasing paperwork rather than managing their supplier base or negotiating better prices. The Comptroller should be commended for the recent project initiated to develop an Online Ordering System (OOS). The OOS is intended to enhance the online ordering process by providing an online ordering portal that will provide a centralized procurement method for qualified purchasing entities. The resulting web-based application will be accessed through TexasOnline, where customers will be able to browse, search and pay for orders from pre-approved product vendors. Phase I will roll out with a limited list of product categories to be defined during the requirements phase of the project. Phase II
Page 60
September 30, 2008
will include more categories and will also include the roll-out of additional features and enhancements to improve the online browsing, searching and procurement experience. STA supports the work efforts associated with the Online Ordering System; however, we believe this function must be fully-integrated with other procurement functionality commonly found in ERP systems. To fully achieve the benefits of the OOS, it must be integrated with financial accounting, asset management and Inventory management (if applicable) functions to ensure standardized and efficient business processes, eliminate fragmentation, and to obtain the spend intelligence necessary to make effective strategic sourcing decisions at the statewide level. The State will realize significant value from two primary areas as a result of fully implementing procurement functionality as part of a statewide ERP system: (1) reduced cost of goods and services, and (2) process efficiencies. Each of these areas is addressed in detail below. Reduced Cost of Goods and Services Increased competition for the States business. The statewide ERP system will increase competition for the States business by notifying vendors of bid opportunities and by making the bid submission process easier and less costly. This increased competition will create a more efficient marketplace that will be characterized by lower prices. For example, the Commonwealth of Virginia has reported that bid counts received for some purchases have increased from 12-15 bids to 40-80 bids. Enable strategic sourcing benefits. With a centralized data warehouse and enhanced ad hoc reporting capabilities that would be part of the statewide ERP solution, the State can better document, analyze, and leverage procurement information for the purposes of negotiating contracts with more favorable rates. Lower Inventory costs for the State. The statewide ERP system will be able to expedite the procurement process from requisition to goods receipt to vendor payment much quicker than the current process. This has the potential to allow the State to reduce Inventory levels or eliminate some types of Inventory. Reduced printing and mailing costs. The statewide ERP system will enable the State to automatically notify vendors of bid opportunities electronically (via email), thus saving the State time and costs of printing and mailing. Process Efficiencies for the State Reduced procurement cycle times. The State should be able to reduce the total time required to procure goods and services. The procurement process entails many steps that include requisition, issuance of a purchase order, vendor fulfillment, delivery, receipt, and payment. As the time required to complete these steps is compressed, the State will be able to receive goods more quickly, and vendors will be able to receive payments earlier. The Aberdeen Group published a report indicating that eProcurement can compress purchase order processing time by 70-80 percent. Reduced time and effort required to complete purchasing activities. Reducing the time associated with procurement activities not only provides
Page 61
September 30, 2008
goods and services in a more timely manner, but it also frees valuable time of State employees, thus reducing the States procurement-related process costs. These processing costs are often measured by analyzing the cost per procurement transaction. Various studies have shown that costs per transaction can be reduced by up to $100 or more per transaction from $150-120 per transaction to $66-33 per transaction. These time and cost savings can be realized because an ERP system enables the State to: Take advantage of software workflow functionality that speeds up tasks; Automate approvals for certain orders; Reduce manual data entry and re-keying; and Reduce errors and the time associated with detection and corrections.
A common complaint of procurement professionals is they spend too much time pushing paper and resolving issues, and an inadequate amount of time analyzing the procurement process and making strategic decisions that will result in lower costs and more efficient processing. The new ERP System will automate many of the current processes through its role-based workflow and sourcing rule processes. The System will also provide a much greater level of information on the States purchases. The combination of these factors will enable procurement professionals to spend more time on the strategic aspects of purchasing and enable achievement of other cost savings. Improved monitoring of the procurement process. With better system controls, it is easier for the State to reduce off-contract or maverick purchasing. This maverick purchasing can result in price premiums of up to 27% according to the National Association of Purchasing Managers (NAPM). Leveling of the playing field for small/disadvantaged businesses. Procurement functionality in ERP systems allows for bid opportunities to be automatically pushed to any vendor that is registered to provide the commodities being procured. Thereby, small/disadvantaged businesses get access to opportunities they might not otherwise know of. A fully-integrated ERP system will address the deficiencies noted above by providing for the following: Replace the States existing statewide ERP systems over a 6-year period and eliminating many of the shadow systems currently maintained by agencies because the existing statewide systems do not meet their functional needs; This action would eliminate much of the fragmentation found under the current environment. Provide System-wide integration of the various ERP modules offers integration that has been built by, and will be maintained by, the software vendor. Offer individual agencies a viable alternative to purchasing a new accounting system or upgrading their existing system to meet internal accounting and reporting needs.
Page 62
September 30, 2008
Incorporate standardized business processes built on best practices that are inherent in ERP systems for the public sector. Provide data standardization to support a single source of the truth and taxpayer transparency. Establishes a common language for reporting expenditures through use of commodity codes for procurement spend analysis and Comptroller Object Codes for financial reporting (CAFR, GASB) purposes, which provides for consistent reporting and better analysis of how the States money is spent. Provide a statewide procurement system that will be fully-integrated with the financial accounting, asset management, and Inventory management modules, as well as the Online Ordering System currently in development by the Comptrollers Office. Allow for more efficient processing and control of documents through automated workflow, reviews, approvals, and inquiries on document status and possible bottlenecks in approval process. Eliminate duplicate data entry as pertinent data is entered once and then carried throughout the system. Reduce data integrity concerns and the effort required to reconcile duplicate data in multiple databases. Ensure consistent and complete statewide federal funds analysis and management for more effective draw down of federal dollars including the ability to estimate carry forward or lapsing federal funds; monitor, coordinate and establish the priorities for the use of federal funds statewide; and review agencies federal funds budgets, expenditures and transfers on an ongoing basis. Provide more efficient and accurate research capabilities through enhanced ad hoc reporting and inquiry functionality associated with new technologies. Eliminate the use of Social Security Number (SSN) as the primary identifier in the statewide administrative systems, thus helping to reduce identity theft opportunities and the related legal risks and costs associated with incident response, investigation, and public relations. Allow for compliance with Section 508 of the Americans with Disabilities Act regarding accessibility. Provide for better tracking of the States assets, thus helping agencies and the Legislature in budget planning by identifying replacement costs and schedules.
Technology Enablers
Besides correcting deficiencies associated with the States existing administrative systems, the most compelling reasons for implementing an ERP system lie within the technology enablers that support the system. Key technology enablers found in ERP software include:
Page 63
September 30, 2008
Integration with a Common Database The most distinguishing factor of an ERP system is its integration across all system modules. Alternatively, the current environment utilizes separate stand-alone statewide administrative systems and agency shadow systems to address business needs not being met by the existing statewide systems. Some legacy systems include automated interfaces to simulate a limited level of integration. Integration in an ERP system is supported by a single database across all functions (or at least a single database for human resource/payroll functions and another for financial management/procurement functions). In this way, data elements (e.g., account codes) are not duplicated when used for more than one purpose. With no duplication, every function has access to the most recent information, and once any change is made, it is immediately available to all functions. Real-Time Processing Many of the current administrative systems perform a majority of their transaction processing via batch jobs that process only a few times a day or during a nightly batch run. This limitation results in delays between the time an action is entered into the system and when the data is available for use by the end user. In contrast, ERP systems use real-time (or near real-time) processing, so transaction results are immediately available to all system modules. Reports are generated using a single, upto-date data source that helps to provide the States leadership with a single source of the truth. Increased Functionality / Best Business Practices Todays ERP systems provide a considerable amount of functionality to meet governmental financial management, procurement, asset management, human resources/payroll, and other administrative business needs. The application modules that often comprise ERP systems have been designed in accordance with industrystandard best business practices. While best practices have not been defined by any governing body or research firm for the private or public sector, such practices have evolved over time with each new software release and have been validated with each ERP implementation. Best practices, together with the flexibility provided by other technology enablers inherent in ERP software today, allow governments to conduct their administrative business processes in a more efficient and effective manner. Best practices promote standardization of business processes across government, and it is critical that the State embrace these practices in order to implement the ERP software with minimal customization. Some simple examples of best practices found in ERP systems include: Asset Management module sweeping the Accounts Payable module for potential capitalized and controllable assets based on specified parameters (selected object codes and threshold amounts) to reduce the possibility of capital assets going unrecorded; Electronic three-way match of invoice, purchase order, and receiving report reduces the use of paper documents and processing time, and allows staff to focus their efforts on exception resolution;
Page 64
September 30, 2008
Distribution of the automated requisitioning function eliminates the paper requisition document; sourcing rules and workflow ensure compliance with predefined procurement rules and approval paths to ensure the lowest cost for goods and services purchased and reduce maverick (off-contract) spending by the participating organizations. Web-based vendor self-service functionality allows vendors to select commodities they service as part of vendor registration and maintenance; opportunities are then automatically sent to all vendors that service commodity to be purchased. Additionally, small vendors get access to opportunities they might otherwise not know about. the bid the bid
Vendor access to self-service payment information reduces staffing required to answer vendor inquiries. Web-Based / Open Architecture Todays leading ERP solutions are designed to be accessed through the use of an industry-standard web browser. Vendor products are transitioning to a pure webbased architecture whereby no code resides on the client other than the web browser. Web-based ERP solutions result in easier deployment and lower costs of IT infrastructure, network administration, and information access. As ERP functionality matures, the need will arise to grant access to those individuals not traditionally considered users of ERP systems vendors, mobile managers, and all employees for self-service functions, to name a few. A web-based system facilitates providing this access at a lesser cost to the State. End users can gain access to the ERP system at anytime as long as he/she has access to a web browser and the proper security authorizations. The leading ERP systems also comply with open architecture standards. Open architecture provides a means whereby the ERP system can be linked to specific bestof-breed software if the need arises (e.g., possibly to meet fleet management requirements). Open architecture also provides the ability to interface the ERP system to common desktop office suite applications (see Desktop Software Integration below). Scalability Scalability allows the State to size its system components to meet its ever-changing business needs. Increased capacity can be added, upgraded or removed as computing needs change, without substantial changes to the application. Scalability considerations include increasing memory, adding additional processors, and installing additional disk storage. Portability Portability provides the flexibility for application software systems to run on multiple hardware platforms or provides built-in capabilities for switching between platforms without requiring reinstallation or additional customization, thus allowing the State to adapt the system to the States technical landscape as it changes over time.
Page 65
September 30, 2008
Graphical User Interface ERP systems utilize a graphical user interface (GUI) that provides user-friendly features similar to other office functions on the users desktop, such as intuitive icons, pull-down menus, point-and-click navigation, pop-up windows, scroll bars, radio buttons, the use of color for clarity and emphasis, and tool bars to assist in the users learning and ongoing use of the System. They also provide online help menus and online documentation, as well as screens that can be customizable to user roles, to enhance the end user experience. The same interface and commands are used for all functions, thereby facilitating training for users that access multiple functions and functional areas. Efficient Modification Where Necessary Assuming that an open (n-Tier) architecture is used (browser-based user interface, database, business rules, and web server), the business rules associated with the system are separated from the rest of the architecture, thus, it is easier to change the business rules (a common occurrence in government) than if they were included in the user interface or the database design. Extensive Development Toolset ERP systems provide for a single (often proprietary) toolset to support software configuration, customization, and ongoing administration of the system. Although use of the toolset requires specialized training and technical knowledge, the development toolset is typically integrated with the functional ERP software and is supported by the vendor. The development tools are also utilized in establishing workflow, managing security, and in implementing a software upgrade. Application Modularity An ERP system consists of a series of application modules (e.g., general ledger, accounts payable, purchasing, asset management, payroll). A breakdown of typical modules is described above. These application modules are designed to be standalone if necessary, though some modules require that others be in place to fully utilize the functionality provided. This modular approach allows governments to selectively implement ERP functionality based on functional need, priorities, funding availability, and staff availability to implement and support the system. The entire ERP solution may be built on a piece-meal basis. Additionally, the government can substitute a third party solution in lieu of the ERP module if necessary to meet a specific business need. Advanced Reporting Tools ERP systems typically provide a suite of ad hoc reporting /query tools to allow properly trained end users to develop their own custom reports. Electronic report routing capabilities are often provided with some of the systems. Security ERP systems provide a robust security function across all ERP modules, including rolebased security, screen and field level security. Automated Workflow and Approvals ERP systems provide automated workflow capabilities that support electronic document routing, review and approval, provide for inquiries on document status, and an efficient
Page 66
September 30, 2008
document filing and retrieval process. Automated workflow also facilitates the implementation of a paperless environment, eliminates paper document shuffling, and often reduces the layers of approval. Drill-Down Capability ERP drill-down capabilities allow an end user to drill down on a field on a screen or report through successively lower levels of detail all the way to the initial entry source document. Comprehensive Audit Trail ERP systems provide online access to a comprehensive history of all changes made to a record in the system. Flexible Chart of Accounts The flexibility provided by the chart of accounts is the greatest factor in determining the usefulness of a financial system. ERP systems provide for a flexible and customizable chart of accounts structure that is supported by relational database technology, sophisticated ad hoc reporting tools to improve financial and budgetary reporting, and minimizes the proliferation of shadow systems across State government. Desktop Software Integration ERP systems provide the ability to easily extract data from the ERP system into common desktop office suite applications such as the Microsoft Office suite for data manipulation and analysis. Most ERP software also supports the import and export of data to/from the ERP system, which can facilitate the uploading and downloading of information from different systems or sources.
Page 67
September 30, 2008
SECTION 5 BUSINESS CASE ANALYSIS

Background and Purpose of Business Case Analysis
The purpose of this section of the report is to document the alternative models that were considered to address future statewide administrative system needs, the approach used to conduct the financial analysis for each alternative, and the results of our financial analysis.
Overview of Approach
Salvaggio, Teal and Associates utilized its proven Business Case Analysis Methodology in performing this project. The diagram that follows depicts the phases of our methodology and how its phases fit into the other phases of this project. Overview of STAs Business Case Analysis Methodology
High-Level Review of Develop Existing Requirements Statewide Systems Business Case Analysis High-Level Implementation Plan Executive Briefings & Testimony Support
Project Project Start-Up Start-Up
Funding Plan
Project Management and Quality Assurance
Determine Alternative Solutions to Evaluate
Identify & Analyze Costs, Benefits & Risks
Perform Financial Analysis
Evaluate Alternatives
Prepare Business Case Analysis Report
The methodology involves evaluating the estimated cost of implementing and maintaining a new ERP system vs. the potential benefits/savings from such an implementation, including: (1) retiring current systems and avoiding the implementation and enhancement of planned/anticipated systems, and (2) realizing benefits/savings from process improvements. The diagram below depicts the primary components of our BCA Methodology.
Page 68
September 30, 2008
Primary Components of STAs Business Case Analysis Methodology
The term Value Pockets is used to refer to the most likely sources of significant value from process-improvements to be found in each process/functional area within the scope of an implementation).
Each of the three (3) components of this business case analysis depicted in the diagram above (represented by the three boxes: ERP Costs, Avoided Systems Costs, and Process-Improvement Benefits) is discussed below. 1. ERP Costs The costs in this category include the estimated costs to acquire, implement, and operate a new statewide ERP system. Additionally, the estimated cost of performing a software upgrade of the new system within the 11-year planning timeframe (Year 0 through Year 10) is included. Approach for This Methodology Component The cost estimates developed for this analysis were based on input from State personnel and on our experience in assisting public sector clients in evaluating, selecting, acquiring, and implementing integrated enterprise-wide systems. To develop these estimates, we utilized our proprietary estimating model, which incorporates estimating standards/metrics and provides an overall framework for developing estimates of this type. The approach taken to estimate the cost of acquiring and implementing a new ERP system was to: Estimate the number of hours required by a team composed of integration vendor and State personnel to implement the functional modules within scope. Estimate the average loaded consulting rate that would be used by the integration firm (the term loaded rate here refers to a rate that includes labor and travel-related costs), as well as the average loaded rate for State
Page 69
September 30, 2008
employees that would be members of the Project Team (the term loaded rate here refers to a rate that includes employee benefits paid for by the State). Multiply total estimated vendor and State employee project hours by the respective loaded rate to determine the total integration vendor cost and the cost of State employees on the Project Team. Estimate the costs of other items associated with acquiring and implementing the new ERP system, which included the following: Software license(s); Project team training; Hardware and system administration during the project; and Facilities and equipment.
The cost of these items was added to the total implementation cost to determine the total cost of acquiring and implementing the new ERP system. We also estimated the cost of software maintenance fees, production support provided by the vendor(s), as well as ongoing cost of operating and supporting the new ERP system after being put into production. These estimates were based on our experience with similar statewide system implementations. 2. Avoided Systems Costs The State could potentially avoid incurring certain system-related costs by (1) retiring existing systems as a result of a new ERP system being put into production, and (2) avoiding costs that would likely be incurred to procure, implement, maintain, and upgrade planned/anticipated systems if a new ERP system were not implemented. Approach for This Methodology Component In performing this aspect of the study, we conducted interviews with personnel from a number of State agencies in order to obtain information regarding current systems in use, plans for enhancing existing systems and implementing new systems, and administrative business needs currently not being met. We also worked with the States project leadership in order to (1) gain an understanding of business drivers for the statewide ERP initiative, (2) formulate assumptions regarding the implementation and operation of a new ERP system, (3) obtain information regarding existing statewide administrative systems and future plans for statewide systems, assuming a statewide ERP system is not implemented. Furthermore, we conducted a survey to collect costs from agencies, including the central administrative agencies, to obtain information necessary to quantify Avoided Systems Costs (i.e., system savings). We also drew from the responses to a survey conducted by the Comptroller in November 2007 to develop an initial estimate of the Avoided Systems Costs for the Higher Education entities within the scope of this BCA, which were then reviewed by the Higher Education entities and modified as necessary. Meetings and follow-up discussions were also conducted to collect system cost information. The results of the surveys are presented in the sections below that describe the Selected Alternatives in detail.
Page 70
September 30, 2008
3. Process-Improvement Benefits The State could potentially realize process improvements in a number of functional areas as a result of implementing a new statewide ERP system. Note that only process-improvement benefits that could potentially result from the new implementation are included. We have coined the term Value Pockets to refer to the most likely sources of significant value (i.e., cost savings and other benefits) to be found in each functional/process area within the scope of a possible new statewide ERP implementation. In applying our Business Case Analysis Methodology, dollar-quantifiable (tangible) and non-dollar-quantifiable (intangible) Value Pockets are composed of: Dollar-quantifiable process-improvement benefits/cost savings Improved process outcomes/results (i.e., improve process efficiency), for example: Lowering the cost of goods and services procured Decreasing inventory levels and associated carrying costs
Reduced cost of process execution (i.e., improved process effectiveness), for example, reassign/reduce headcount (FTEs) by: Reducing the number of FTEs required to enter data into systems Reducing the number of FTEs required to generate needed information by no longer being required to obtain and consolidate data from multiple sources (also results in faster and better decision making) Reducing the number of FTEs required to reconcile data among multiple systems Reducing the number of FTEs required to track transactions spread over multiple systems (e.g., avoid maintaining tracking data in spreadsheets, using paper logs, etc.)

Note: Savings from reducing the number of FTEs that perform certain activities can be obtained in ways such as repurposing personnel from redundant and/or unnecessarily labor-intensive activities to valued-added activities and by eliminating unfilled positions. Also, FTE-related savings can be achieved over the long run through retirements and attrition. Non-dollar-quantifiable process-improvement benefits/cost savings (intangible items), for example: Reduced cycle times Realignment of processes in support of strategic initiative(s) Increase data and reporting accuracy Improve usefulness of information
Page 71
September 30, 2008
Approach for This Methodology Component In performing this portion of the BCA, interviews were conducted with a number of Comptroller personnel in order to obtain information regarding the business processes currently in place, as well as to obtain their input on potential processimprovement opportunities. We also worked with the States Project Team to identify potential process-improvement opportunities, in particular, those that should be considered Value Pockets, both dollar-quantifiable and non-dollar-quantifiable. Dollar-quantifiable Value Pocket benefits were estimated from data collected from State personnel through interviews and a Value Pocket survey that was sent to twenty-four (24) agencies which collectively comprise more than 97% of the States operating budget. Meetings and follow-up discussions were also conducted to collect information used to estimate benefits/savings from process improvements. The results of the survey are presented in the sections below that describe the selected Alternatives 2 and 3 in detail. Our Business Case Analysis Methodology includes the use of proprietary formulas and calculations that are used to quantify Value Pocket benefits. Savings Factors are key variables in these formulas and the values that were used for these Factors for this study were derived from a variety of sources, including the experiences of other government organizations and estimates made by STA based on our analysis of the respective processes and our experience, in general, in these matters, as well as input from State personnel.
Selected Alternative Solutions

A key component of the State of Texas Statewide ERP Business Case Analysis project was to identify alternative approaches or scenarios that can best address the requirements of a statewide ERP system, and then to develop a resulting business case for each alternative so that the costs and benefits associated with each alternative can be determined and compared. This resulting comparison will provide the quantitative and qualitative data to support the recommended approach as a result of the Business Case Analysis project. Based on the work previously performed by the Comptroller, our understanding of the States existing administrative business processes and associated systems, our experience with statewide ERP/eProcurement initiatives in twelve (12) states, and our knowledge of the public sector ERP software marketplace, we have identified and selected the following three (3) alternative approaches to be analyzed for the Statewide ERP Business Case project: 1. Current Path (Status Quo) assumes that the State continues on its current path whereby each agency and institution of higher education continues operating their existing administrative systems as currently planned. 2. Statewide ERP Platform Deployment assumes that every State agency and higher education institution will replace their existing systems and applications covered under the scope listed in HB 3106 and will instead migrate to a single Statewide ERP platform that will be operated by the Comptroller.
Page 72
September 30, 2008
3. Hub Model -- assumes that only State agencies (with the exception of the Health and Human Services agencies) will migrate to a new Statewide ERP platform operated by the Comptrollers ASP service. The Health and Human Services agencies and the Higher Education Systems will operate as a reporting Hubs and interface directly into the Statewide Data Warehouse that will be operated by the Comptrollers ASP service. Specific agency/institution transactional systems would be interfaced to the Statewide ERP System for addressing major functional needs. Each of these three (3) alternatives is briefly described immediately below, and each is described in detail in its respective section of the report below.
General Assumptions
Following are the general assumptions that support this Business Case Analysis: 1. Our data gathering and resulting financial analysis was completed over a brief period of time when compared with similar studies we have completed for other state and local governments. Due to the aggressive timeline, we did not receive the final value pocket survey responses from the State agencies until September 12, 2008, and the data had to be compiled, analyzed and included in our final report by September 17, 2008. There are inherent risks associated with performing such hurried data compilation and analysis; nevertheless, we believe our resulting findings and analysis to be materially accurate. 2. Our estimate required STA to obtain data from State agencies and higher education institutions. Where possible, we reviewed the data for adequacy but ultimately had to rely on the information submitted. 3. In some instances, we received inadequate or no data for estimating purposes from agencies and institutions of higher education. In those instances, we had to extrapolate estimates for specific cost elements using comparable data from other similar agencies and institutions and STA's experience with studies of a similar nature. 4. We included no facilities costs for FY 2010 under BCA 2 and BCA 3 as consulting and project team costs for pre-implementation activities are assumed to be absorbed through existing Comptroller facilities and equipment. 5. No contingency/risk amounts have been applied to the estimates presented in the table above because we applied a highly conservative approach to (1) estimating the cost of the implementation effort; contingency amounts were built into the estimates of the effort required to perform project tasks, and (2) estimating the process-improvement and cost-avoidance benefits; therefore, we believe the resulting values for the financial metrics are conservative. 6. We were unable to analyze the specifics associated with the timing of temporary and permanent interfaces over the 11-year timeframe; however, we are confident there is sufficient funding in the total cost model to cover the cost of temporary and permanent interfaces. 7. The costs identified in this section of the report are total costs of implementing, deploying and supporting the software in accordance with each alternative (e.g.,
Page 73
September 30, 2008
facilities and equipment, Comptroller staff costs, contractor costs, state agency staff costs) for Business Case Analysis comparative purposes only and reflects the costs of the various alternatives over a standard 11-year horizon commonly used for such analyses (FY 2009 FY 2019). The costs presented in this section of the report are to be used for analysis only. The specific costs that would be funded as part of a statewide ERP project are presented in the Funding Options and Priorities section of the report. 8. The estimated costs of agencies/institutions in deploying the software under BCA 2 and BCA 3 are not reflected in the total cost estimates because it is assumed that the agencies would absorb the cost of these resources for the relatively short time period they would be used and would not be backfilled due to the short duration. It is assumed that the only agency/institution personnel that will be backfilled/funded are those that directly participate as Project Team members. We assumed that 60% of all State Project Team members would be backfilled/funded. Backfill resources are those staff hired to replace the State resources that leave their current positions to join the ERP Project Team.
Detailed Discussion of Business Case Alternative No. 1 (BCA 1): Current Path (Status Quo)
Description The Current Path scenario or Status Quo makes the assumption that that the State continues on its current path whereby each agency and institution of higher education continues operating their existing administrative systems in accordance with the results of the Comptrollers November 2007 survey. No major investments or enhancements will be made to the information systems that are currently in place for the next ten (10) years for any State agency or higher education institution other than what is currently planned as reflected in the November 2007 survey. This alternative also assumes that the existing statewide administrative systems (e.g., USAS, SPA, TINS, USPS, SPRS, HRIS) will remain operational, and will be supported and maintained according to the planned schedule.
Page 74
September 30, 2008
High Level Statewide Systems Diagram

Uniform Statewide Accounting System (USAS) (General Ledger, Accounts Payable, Grants, Projects)
Reporting Agency Interfaces (46) ISAS USAS Internal AGY (80)
Courts (21) Regulatory (32) Legislative (4) Natural Resources (4) General (12) Public Safety (7)
TINS
HE Reporting Interfaces (56)
SPRS
USPS
TCEQ
Austin
UT System
UTSW-D Arlingtn UTB UTD UTEP UTHSC-H UTHSC-S UTHSC-T MDACC UTMB
HHSC (5)
Tyler
HRIS
UTSA UTPB UTPA
DFPS DSHS DARS DADS TDCJ TWC Other Reporting AGYs GOV Lottery THECB GLO TPFA TxDOT TEA OAG ERS TWDB TRS RRC TDHCA TPWD Univ. of N. Texas System
UNT UNT-HSC SR-Rio
TAMU System
TAMU CorpCh INTL King PView Texark Galv West Comm Tarl St TEES VetMed AgriLife TAExS Forest TTI TEExS
CPA
Legend Agency Group or HE System
Texas Tech System

Tx Tech Angelo TTUHSC
TAMUHSC
Texas St System
TxState SHSU
UH System
UH UH-CL
NonSystem
TWU MWStU SFASU
Application System Agency or Institution Health-related Institution Logical System Interface or Data Flow System Usage
SRSU UH-D UH-V Lamar
TSU TSTC
This scenario is presented primarily as a baseline for comparison with Business Case Alternatives 2 and 3. Other elements of BCA 1 include the following: Platform Operation: Each agency and institution will continue to operate its existing platform and application set it has previously implemented according to its own business needs and requirements. Interfacing to Statewide ERP: Each agency and institution is responsible for maintaining its current individual interfaces to the statewide systems of record. As data requirements change in relation to the business environment, each of these individual interfaces must be modified and updated. Source Code Modifications: Each agency and institution will continue to modify and support its individual platforms and applications as it deems necessary. Patch and Release Management: Every agency and institution will continue to operate under whatever patch and release management cycle it has implemented. Other Assumptions: In November 2007, the Comptroller conducted a survey of every State agency and higher education institution. The purpose of the survey was to gather data related to the planned IT expenditures, including hardware, software, infrastructure and labor for each agency and institution for the next five (5) fiscal years. This data was extrapolated out to an 11-year time horizon and was used as the primary method of
Page 75
September 30, 2008
calculating the business case costs of this alternative. The survey asked the participants to estimate their anticipated costs and not to assume any major changes or enhancements at the statewide level. This scenario also makes the assumption that upgrades and enhancements that are known to be required in the future will be made and those costs will be included in the analysis of the Status Quo alternative. Strengths of the Current Path Alternative Relative strengths of this alternative primarily have to do with the fact that no major investments or changes would need to be made to the existing IT environments of each State agency and institution, including: No disruption of current business processes; Limits the inherent risks associated with changing or upgrading current systems (assumes ongoing maintenance will still occur where applicable); and Additional costs limited to new agency systems and annual maintenance and upgrades for existing systems. Weaknesses of the Current Path Alternative Current administrative systems require considerable technical resources and time to modify and maintain; Continued reliance on paper documents in most State agencies and institutions resulting in inefficient and time-consuming workflow and reporting; Lack of real-time integration within and among the financial, procurement, and human resources/payroll systems at the Statewide and agency/institutional levels; Fails to take advantage of best business practices inherent in ERP systems; Time-consuming reconciling tasks associated with maintaining duplicate data in multiple databases. Reconciling required: Between user agency/institution administrative systems, Between user agency/institution and statewide administrative systems, and Between statewide administrative systems;
Continues the practice of State agencies purchasing and implementing new administrative systems in order to meet agency administrative business needs not being met by existing statewide systems; Lack of adequate ad hoc reporting capabilities; Fails to address replacement of legacy statewide administrative systems and most likely agency-specific systems that have reached obsolescence; and Continued expense and complexity associated with supporting and maintaining the hundreds of interfaces to/from each and every State agency and higher education institution.
Page 76
September 30, 2008
Constraints and Risks The risk associated with the Status Quo solution is that it provides no additional functionality or technological improvements; therefore, current systems will, at some point, fail to meet statewide and user agency/institutional needs. Specifically, the existing systems lack real-time integration with one another, and do not include an adequate end user reporting facility. Additionally, the States legacy administrative systems and associated support are not positioned to respond rapidly to changes in business processes or technology. This alternative faces the risk of technical obsolescence. The State is exposed to significant risk as legacy system technologies are becoming obsolete and will eventually become difficult to replace. Furthermore, it will become increasingly difficult and costly to find technical staff to maintain these systems. Estimated Costs As noted previously in this report, we conducted a survey of twenty-four (24) agencies which collectively comprise more than 97% of the States operating budget to collect cost data for the Status Quo Alternative. The summarized results of that survey are presented in the table below.
Page 77
September 30, 2008
Agency Status Quo Costs

Yr 0 Yr 1 Yr 2 Yr 3 Yr 4 Yr 5
Agency Name & Number
FYE 2009
FYE 2010
FYE 2011
FYE 2012
FYE 2013
FYE 2014
Statewide Systems TDHCA--332 GLO--305 Lottery--361 Rail Road--455 TRS--323 OAG--302 TWDB--580 TEA--701 CPA--304 TxDOT--601 TCEQ--582 OOG--301 ERS--327 TPFA--347 DPS--405 TWC--320 TPW D--802 TDJC--696 HHSC--529 DFPS--530 DSHS--537 DARS--538 DADS--539 THECB--781 Total Costs Ongoing Costs Projects Costs
Total Costs, Inflation Factor = 3% Ongoing Costs, Inflation Factor = 3% Project Costs, Inflation Factor = 3%
8,885,044 440,000 170,000 161,654 37,858 535,906 655,799 53,450 1,596,500 1,000,000 3,709,249 2,197,892 10,000 713,163 10,527 651,000 1,570,000 2,649,158 2,203,613 10,058,000 214,150 37,522,964 33,236,627 4,286,337
126,405,590 480,000 80,000 161,654 37,859 562,702 526,719 53,450 2,421,500 890,000 3,545,620 677,013 10,000 494,379 10,948 661,000 1,570,000 2,696,484 2,203,613 17,229,000 215,711 160,933,241 33,047,238 127,886,003
8,830,590 480,000 70,000 161,654 37,860 590,837 513,599 53,450 2,108,500 890,000 3,687,445 677,013 10,000 755,114 11,386 671,000 1,570,000 707,135 2,203,613 15,855,000 217,351 40,101,547 37,024,547 3,077,000
8,830,590 410,000 80,000 161,654 37,861 620,379 665,999 53,450 2,121,500 890,000 3,585,831 677,013 10,000 713,163 17,747 683,000 1,570,000 724,506 2,203,613 11,988,000 219,070 36,263,375 33,993,375 2,270,000
8,830,590 410,000 70,000 161,654 37,862 651,398 343,399 53,450 1,621,500 890,000 3,729,265 677,013 10,000 494,379 14,423 693,000 4,170,000 740,440 2,203,613 22,088,000 220,878 48,110,864 37,110,864 11,000,000
8,830,590 410,000 80,000 161,654 37,863 683,967 345,799 53,450 1,621,500 890,000 3,878,436 677,013 10,000 755,114 12,808 713,000 1,570,000 765,613 2,203,613 11,088,000 222,774 35,011,194 34,791,194 220,000
37,522,964 33,236,627 4,286,337
165,761,239 34,038,656 131,722,583
42,543,731 39,279,342 3,264,389
39,625,970 37,145,479 2,480,491
54,149,201 41,768,604 12,380,597
40,587,570 40,332,529 255,040
Page 78
September 30, 2008
Agency Status Quo Costs (continued)

Yr 6 Yr 7 Yr 8 Yr 9 Yr 10 Total Years 0 - 10
FYE 2015
FYE 2016
FYE 2017
FYE 2018
FYE 2019
Statewide Systems TDHCA--332 GLO--305 Lottery--361 Rail Road--455 TRS--323 OAG--302 TWDB--580 TEA--701 CPA--304 TxDOT--601 TCEQ--582 OOG--301 ERS--327 TPFA--347 DPS--405 TWC--320 TPW D--802 TDJC--696 HHSC--529 DFPS--530 DSHS--537 DARS--538 DADS--539 THECB--781 Total Costs Ongoing Costs Projects Costs
8,830,590 410,000 70,000 161,654 37,864 718,166 498,199 53,450 1,621,500 890,000 4,033,575 677,013 10,000 713,163 13,321 725,000 1,110,000 791,589 2,203,613 10,588,000 224,766 34,381,463 34,011,462 370,000
8,830,590 410,000 80,000 161,654 37,865 754,074 350,599 53,450 1,621,500 890,000 4,194,918 677,013 10,000 494,379 13,853 745,000 1,110,000 465,575 2,203,613 10,588,000 226,857 33,918,940 33,918,940 -
8,830,590 410,000 70,000 161,654 37,866 791,778 352,999 53,450 1,621,500 890,000 4,362,716 677,013 10,000 755,114 21,844 755,000 1,110,000 482,045 2,203,613 10,588,000 229,054 34,414,236 34,194,236 220,000
8,830,590 410,000 80,000 161,654 37,867 831,367 505,399 53,450 1,621,500 890,000 4,537,226 677,013 10,000 713,163 14,984 765,000 1,110,000 499,060 2,203,613 10,588,000 231,361 34,771,247 34,401,246 370,000
8,830,590 410,000 80,000 161,654 37,867 831,367 505,399 53,450 1,621,500 890,000 4,537,226 677,013 10,000 713,163 14,984 765,000 1,110,000 499,060 2,203,613 10,588,000 231,361 34,771,247 34,401,246 370,000
214,765,944 4,680,000 930,000 1,778,194 416,492 7,571,940 5,263,914 587,947 19,598,500 9,900,000 43,801,507 8,968,021 110,000 7,314,294 156,823 7,827,000 17,570,000 11,020,665 24,239,744 141,246,000 2,453,333 530,200,318 380,130,977 150,069,342
41,053,265 40,611,465 441,800
41,716,018 41,716,018 -
43,594,924 43,316,235 278,689
45,368,590 44,885,824 482,767
46,729,648 46,232,398 497,250
598,653,119 442,563,177 156,089,943
We also drew from the responses to a survey conducted by the Comptroller in November 2007 to develop an initial estimate of the Avoided Systems Costs for the Higher Education entities within the scope of this BCA, which were then reviewed by the Higher Education entities and modified as necessary. Meetings and follow-up discussions were also conducted to collect system cost information. The results of the surveys are presented in the sections below that describe the Selected Alternatives in detail.
Page 79
September 30, 2008
Higher Education Status Quo Costs

University Systems Yr 0 FY2009 Yr 1 FY2010 Yr 2 FY2011 Yr 3 FY2012 Yr 4 FY2013 Yr 5 FY2014
Texas A&M System -- ongoing Texas A&M System -- projects Texas Tech System -- ongoing Texas Tech System -- projects Texas State System -- ongoing Texas State System -- projects University of North TX System -ongoing University of North TX System -projects University of TX System -- ongoing University of TX System -- projects University of Houston System -ongoing University of Houston System -projects Universities not System-affiliated -ongoing Universities not System-affiliated -project Inflation Factor Not Applied Total All Universities -- ongoing Total All Universities -- project Total All Universities Inflation Factor Applied Total All Universities -- ongoing -inflated 3% Total All Universities -- projects -inflated 3% Total All Universities -- inflated 3%
6,076,808 1,507,415 3,419,570 -
6,076,808 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
6,076,808 50,000 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
1,733,317 34,375,966 42,260,175
1,531,317 34,336,530 11,100,875
1,531,317 34,336,530 3,103,375
1,531,317 33,235,655 -
1,531,317 33,235,655 1,650,000
1,531,317 33,235,655 -
3,748,739 -
3,280,739 -
3,280,739 -
3,280,739 -
3,280,739 -
3,280,739 -
3,808,487 4,522,858
3,832,909 150,000
3,842,909 -
3,842,909 -
3,842,909 -
3,842,909 -
54,670,303 46,783,033 101,453,336
53,872,789 11,250,875 65,123,664
53,882,789 3,103,375 56,986,164
52,781,914 50,000 52,831,914
52,781,914 1,650,000 54,431,914
52,781,914 52,781,914
54,670,303 46,783,033
55,488,972 11,588,401
57,164,250 3,292,371
57,676,222 54,636
59,406,509 1,857,090
61,188,704 -
101,453,336
67,077,374
60,456,621
57,730,859
61,263,598
61,188,704
Page 80
September 30, 2008
Higher Education Status Quo Costs

University Systems Yr 6 FY2015 Yr 7 FY2016 Yr 8 FY2017 Yr 9 FY2018 Yr 10 FY2019 Total Years 0 - 10
Texas A&M System -- ongoing Texas A&M System -- projects Texas Tech System -- ongoing Texas Tech System -- projects Texas State System -- ongoing Texas State System -- projects University of North TX System -ongoing University of North TX System -projects University of TX System -- ongoing University of TX System -- projects University of Houston System -ongoing University of Houston System -projects Universities not System-affiliated -ongoing Universities not System-affiliated -project Inflation Factor Not Applied Total All Universities -- ongoing Total All Universities -- project Total All Universities Inflation Factor Applied Total All Universities -- ongoing -inflated 3% Total All Universities -- projects -inflated 3% Total All Universities -- inflated 3%
6,076,808 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
6,076,808 1,507,415 3,307,070 -
66,844,887 50,000 16,581,565 36,490,275 -
1,531,317 33,235,655 -
1,531,319 33,235,655 -
1,531,317 33,235,655 -
1,531,317 33,235,655 -
1,531,317 33,235,655 -
17,046,489 368,934,269 58,114,425
3,280,739 -
3,280,739 -
3,280,739 -
3,280,739 -
3,280,739 -
36,556,129 -
3,842,909 -
3,842,909 -
3,842,909 -
3,842,909 -
3,842,909 -
42,227,577 4,672,858
52,781,914 52,781,914
52,781,916 52,781,916
52,781,914 52,781,914
52,781,914 52,781,914
52,781,914 52,781,914
584,681,191 62,837,283 647,518,474
63,024,365 -
64,915,099 -
66,862,549 -
68,868,426 -
70,934,478 -
680,199,877 63,575,531 743,775,408
63,024,365
64,915,099
66,862,549
68,868,426
70,934,478
Page 81
September 30, 2008
Status Quo Costs for Agencies and Higher Education Combined

Status Quo Costs Agencies and Higher Ed Combined Inflation Factor N ot Applied Agency -- Ongoing Costs Agency -- Project Costs Agency -- Total Cost All Universities -- Ongoing Costs All Universities -- Project C osts All Universities -- Total Cost Grand Total Cost Inflation Factor Applied Agency -- Ongoing Costs -- inflated Agency -- Project Costs -- inflated Agency -- Total Cost -- inflated All Universities -- Ongoing Costs -- inflated All Universities -- Project C osts -- inflated All Universities -- Total Cost -- inflated Grand Total Cost Inflation Rate Yr 0 FY2009 Yr 1 FY2010 Yr 2 FY2011 Yr 3 FY2012 Yr 4 FY2013 Yr 5 FY2014
0% 0% 0% 0% 0% 0% 0%
33,236,627 4,286,337 37,522,964 54,670,303 46,783,033 101,453,336 138,976,300
33,047,238 127,886,003 160,933,241 53,872,789 11,250,875 65,123,664 226,056,905
37,024,547 3,077,000 40,101,547 53,882,789 3,103,375 56,986,164 97,087,711
33,993,375 2,270,000 36,263,375 52,781,914 50,000 52,831,914 89,095,289
37,110,864 11,000,000 48,110,864 52,781,914 1,650,000 54,431,914 102,542,778
34,791,194 220,000 35,011,194 52,781,914 52,781,914 87,793,108
3% 3% 3% 3% 3% 3% 3%
33,236,627 4,286,337 37,522,964 54,670,303 46,783,033 101,453,336 138,976,300
34,038,656 131,722,583 165,761,239 55,488,972 11,588,401 67,077,374 232,838,612
39,279,342 3,264,389 42,543,731 57,164,250 3,292,371 60,456,621 103,000,352
37,145,479 2,480,491 39,625,970 57,676,222 54,636 57,730,859 97,356,828
41,768,604 12,380,597 54,149,201 59,406,509 1,857,090 61,263,598 115,412,800
40,332,529 255,040 40,587,570 61,188,704 61,188,704 101,776,274
Status Quo Costs Agencies and Higher Ed Combined Inflation Factor Not Applied Agency -- Ongoing Costs Agency -- Project Costs Agency -- Total Cost All Universities -- Ongoing Costs All Universities -- Project Costs All Universities -- Total Cost Grand Total Cost Inflation Factor Applied Agency -- Ongoing Costs -- inflated Agency -- Project Costs -- inflated Agency -- Total Cost -- inflated All Universities -- Ongoing Costs -- inflated All Universities -- Project Costs -- inflated All Universities -- Total Cost -- inflated Grand Total Cost
Inflation Rate
Yr 6 FY2015
Yr 7 FY2016
Yr 8 FY2017
Yr 9 FY2018
Yr 10 FY2019
Total Years 0 - 10
0% 0% 0% 0% 0% 0% 0%
34,011,462 370,000 34,381,463 52,781,914 52,781,914 87,163,376
33,918,940 33,918,940 52,781,916 52,781,916 86,700,856
34,194,236 220,000 34,414,236 52,781,914 52,781,914 87,196,149
34,401,246 370,000 34,771,247 52,781,914 52,781,914 87,553,160
34,401,246 370,000 34,771,247 52,781,914 52,781,914 87,553,160
380,130,977 150,069,342 530,200,318 584,681,191 62,837,283 647,518,474 1,177,718,792
3% 3% 3% 3% 3% 3% 3%
40,611,465 441,800 41,053,265 63,024,365 63,024,365 104,077,630
41,716,018 41,716,018 64,915,099 64,915,099 106,631,117
43,316,235 278,689 43,594,924 66,862,549 66,862,549 110,457,473
44,885,824 482,767 45,368,590 68,868,426 68,868,426 114,237,016
46,232,398 497,250 46,729,648 70,934,478 70,934,478 117,664,126
442,563,177 156,089,943 598,653,119 680,199,877 63,575,531 743,775,408 1,342,428,527
Business Case Alternative No. 2 (BCA 2): Statewide ERP Platform Deployment
Description The Statewide ERP Platform Deployment scenario assumes that every State agency and higher education institution will replace their existing systems and applications covered under the scope listed in HB 3106 and will instead migrate to a single Statewide ERP platform that will be operated by the Comptroller. The Comptrollers Office will, in effect, be operating as an ASP and will provide all application and infrastructure services
Page 82
September 30, 2008
for every State agency and institution of higher education. The new Statewide ERP platform will also replace the existing statewide legacy administrative systems (e.g., USAS, USPS, SPA, HRIS, SPRS) with a new, fully integrated, commercially-available ERP system that would provide all functionality identified in HB 3106.
BCA 2 - Statewide ERP Platform
Statewide ASP operated by CPA

Statewide ERP (Master ERP Baseline Instance) Consolidation of: USAS/USPS/HRIS/SPRS/SPA/TINS/Paysubs/Warrants + ABEST (if possible)
Statewide Data Warehouse (Business Objects)
Higher Education ASP
All Higher Education Institutions

UT System TAMU System Texas Tech System Non-System Institutions TWU MWStU SFASU TSU TSTC
All State Agencies
UH System
Texas State System
North Texas System
Push Awarded Contracts from TPASS
Texas Online Shopping Cart, Vendor Performance, Contracts (RFO, ESBD, Open Market, Reverse Auctions)
As the diagram shows, all State agencies and higher education institutions will utilize the Comptrollers ASP managed service. Separate ASP instances (or copies) will be established for agencies and institutions of higher education, and both will feed data into a Statewide Data Warehouse. The Statewide Data Warehouse will provide the detail data needed for statewide and agency/institutional reporting. No statewide interfaces will be required under BCA 2 due to the fact that all agencies/institutions will be operating on the same platform. Other elements of BCA 2 include the following: Platform Operation: The Comptroller will operate and manage two (2) ASPs one (1) for all State agencies and one (1) for all institutions of higher education. Both ASPs will utilize a common unified ERP code baseline but can be configured differently to suit the needs of each customer base.
Page 83
September 30, 2008
Interfacing to Statewide ERP System: No interfaces will be required to the Statewide ERP platform since every agency and institution would be on a common platform. However, there would be a data feed from each ASP to the statewide Data Warehouse. Source Code Modifications: Source code modifications would be restricted to only those required to meet State or Federal mandates. Every attempt would be made to keep the statewide ERP Baseline as close as possible to the ERP software providers code baseline in order to streamline the maintenance and upgrade process. Patch and Release Management: The Comptroller ASPs will stay current with the ERP vendors patch and release cycles. Other Assumptions: The implementation costs associated with BCA 2 will be calculated under the assumption that a Tier 1 ERP platform will be selected and a clean install of the vendors application code will be utilized (i.e., no applications currently in use will be reused). Strengths of the Statewide ERP Alternative Relative strengths of this alternative primarily relate to the fact that all State agencies and institutions of higher education will be operating on a single, unified platform. The benefits of using one platform are as follows: Fully addresses HB 3106 requirements; Addresses Comptroller Rider 16 regarding fleet management; Provides greatest degree of integration across the Statewide enterprise (less interfacing system touch points); Most efficient model (greatest system avoidance costs and process-improvement savings) from Statewide perspective; Greatest economy of scale; Proven model for State agencies (excluding higher education) in other states; Eliminates proliferation of agency ERP and other administrative shadow systems; Complies with guiding principles to implement standardized business processes; Provides a plan that allows the Comptroller to replace its legacy statewide administrative systems; and Facilitates governmental transparency. Weaknesses of the Statewide ERP Alternative Significant one-time expense to deploy; Unproven for higher education (only North Dakota has included higher education within the Statewide ERP scope); Fails to comply with ERP Advisory Council guiding principle to not throw out what works; Highest risk of project failure and significant cost over-runs of all alternatives considered; and
Page 84
September 30, 2008
Potential indirect negative impact on higher education related to interfacing other core systems, including patient care, student information, learning management, and library systems. Constraints and Risks The risk associated with the Statewide ERP solution is risk of project failure simply due to the sheer size and scale of the initial deployment to move all State agencies and institutions of higher education onto one common platform. The inclusion of Higher Education within the scope of the Statewide ERP system introduces significant complexities many of which are unknown because no other State (other than North Dakota) has attempted to include Higher Education institutions within its statewide systems project. Deployment Strategy and Approach All State agencies and institutions of higher education would be logically organized into deployment groups or waves. All functional modules would be deployed for all agencies and institutions within a specific group or wave. The first deployment phase would include the development of a prototype deployment model that would become the blueprint for deploying all functionality among the remaining agency/institution deployment waves upon the successful deployment for the initial agency wave. Each deployment phase would be executed sequentially until all agencies and institutions have been deployed on the statewide ERP system. For cost estimating purposes, STA and the Comptroller Project Team developed a detailed deployment schedule for State agencies under BCA 2. ITCHE members assisted us in developing the deployment schedule for higher education. This planning schedule will be made available to the Comptroller as part of project close-out activities. The schedule was used solely for the purposes of developing our estimates and the Comptroller has not made any decisions or plans regarding the deployment schedule should an actual ERP project be funded by the Legislature. Estimated Costs The costs in this category include the estimated costs to acquire, implement, and operate the new ERP system. All State agencies and institutions of higher education are included in the scope of this alternative. Also, the estimated cost of performing a software upgrade of the ERP system is included in alternative 2. Approach The cost estimates developed for this analysis were based on input from state personnel and on our experience assisting public sector clients in evaluating, selecting, acquiring, and implementing integrated enterprise-wide systems. To develop these estimates, we utilized our proprietary estimating model, which incorporates estimating standards/metrics, and provides an overall framework for developing estimates of this type. The approach taken to estimate the cost of acquiring and implementing the ERP system was to: Estimate the number of hours to implement the functional modules within scope. The estimated number of hours addressed the following services:
Page 85
September 30, 2008
Project Management; Pre-Implementation Services / Project Oversight; Software Installation, Configuration & Process Reengineering; Custom Development, including: Automated Interfaces Software Modification / Enhancements Report Development Data Conversion / Loading Workflow Configuration Data Warehouse Implementation;
Organizational Change Management; and End-User Training and Documentation.
After estimating the total number of consulting hours, we estimated the average loaded consulting rate that would be used by the implementation firm. The term loaded rate refers to a rate that includes labor and travel-related costs. The loaded rate was then multiplied by the total estimated project hours to determine the total implementation vendor cost. Estimate the costs of other items associated with acquiring and implementing the ERP system, which included the following: Software License(s); Project Team Training; Facilities and Equipment; Infrastructure (Database, Server, and Network); and Compensation for State Project Team Members.
The cost of these items was added to the total implementation cost to determine the total cost of acquiring and implementing a new ERP system. We also estimated the cost of software maintenance fees, production support provided by the vendor(s), as well as ongoing cost of operating and supporting the system after being put into production. These estimates were based on our experience with similar statewide system implementations. The table below presents a summary of our estimated costs to implement, operate, and maintain the system over an 11-year period. Please refer to Appendix A for detailed information regarding our assumptions, as well as detailed cost-estimating schedules.
Page 86
September 30, 2008
Summary Schedule of Estimated Costs of Implementing and Operating Alternative 2
Page 87
September 30, 2008
As indicated in the Introduction section of this report, the estimating schedules, including the one above, contain an Acquire phase that spans FY 2009 and FY 2010 and that includes the work effort of consultants and state personnel to: Develop system requirements for a statewide ERP system; Develop a Request for Proposal (RFP) for the acquisition of ERP software; Develop detailed demonstration scripts that the vendor finalists must follow during their software demonstrations; Facilitate the acquisition process and contract negotiations for ERP software; Develop an RFP for the acquisition of ERP integration services; and Facilitate the acquisition process and contract negotiations for an ERP integration firm. General Supporting Assumptions The core of the new ERP system will be configured, tested and implemented for a subset of agencies during a 24-month implementation period, starting in September 2010. The agencies included in the initial implementation project would go live in FY 2012. After the initial agency deployment in 2012, the ERP system will be rolled out in multiple waves, over a six-year period. The roll-out will start in FY 2013 and end in FY 2018. An average hourly, expense-loaded rate of $200 is assumed for the integration contractors and $180 for the project oversight contractors. The cost of State of Texas resources is assumed to be $58.50 per hour. This dollar amount is based on the assumption that the average annual salary of State staff working on the project is approximately $90,000 and the average load is 30%. It is assumed that a full-time equivalent number of hours per year are 2,000 for both contractor resources and state resources. An average inflation factor of 3% was applied to non-state staff costs. average inflation factor of 2% was applied for state staff. A software upgrade will occur during Year 6 of the project. The implementation work effort will be conducted using a ratio of approximately 1.0 State resource for every 1.0 contractor resource. Project Team Composition The staffing model used for the cost estimates is based on our experience with ERP implementations and on input from the States project leadership. Not all of the team members will be utilized throughout every aspect of the initiative. Therefore, for information on the total assumed number of hours that resources will work on the project, please refer to the appropriate schedules in Appendix A. An
Page 88
September 30, 2008
Contractor Cost Assumptions Note that the items that follow correspond to the line items pertaining to Contractors in rows 1-189 of Schedule A3 of this report. Project Management We assume that 8.0 FTEs will be required for the duration of the 24-month implementation period and 4.0 FTEs will be required for the six month post go-live support period for a total of approximately 36,000 hours. Pre-Implementation Services/Project Oversight We estimate that 9.0 FTEs will be required to perform the pre-implementation planning and acquisition services, as well as oversight services for the duration of the implementation project and deployment effort. We assume that it will take approximately 30,000 hours over the course of twenty (20) months to develop the ERP system requirements, draft the RFP for ERP software, facilitate the evaluation process and contract negotiations associated with the software procurement, draft the RFP for software integration services, and facilitate the evaluation process and contract negotiations associated with the integration services procurement. We further assume that 36,000 hours spread over twenty-four (24) months will be required to provide project oversight services for the initial implementation project and 84,000 hours will be required to provide project oversight services for the remaining deployment effort across state government. Software Configuration and Process Reengineering This category includes the contractor effort involved in: Developing To-Be business processes; Configuring the software in accordance with the defined To-Be processes; and Performing configuration unit testing, and assisting in integration, system, and stress testing. We estimate that this activity will require approximately 549,500 hours based on the functional scope and the implementation duration. Workflow Configuration This category involves defining the States workflow business rules and configuring the Systems workflow functionality in accordance with those rules. Included are the hours necessary for analysis, design, construction, testing, and moving the workflows into the production environment. We assume that 14.0 to 15.0 FTEs will be required for 21 months of the 24-month implementation period (51,167 hours) in order to provide the baseline workflow functionality necessary to support key business processes.
Page 89
September 30, 2008
Development Technical Lead We assume that 2.0 to 3.0 technical leads will be in place for the entire 24-month implementation period and six month post go-live support period, for a total of 13,500 hours. Development Testing Lead We estimated 2.0 FTEs to be in place for the entire 18 months of the 24-month implementation period, for a total of 6,000 hours. Development Interfaces This category includes the entire effort required to create a number of standard inbound and outbound interface formats. This effort includes analysis, design, construction, testing, and moving the interfaces into the production environment. We assume that resources will start in month 4 and reach a peak in months 7 through 24 of the 24-month implementation period to perform the activities in this category, for a total of 43,167 hours of effort. Development Software Modifications This category includes all the effort necessary to develop modifications/ enhancements to the new ERP system in order for the system to meet the States business requirements (i.e., analysis, design, construction, testing, and moving the modifications/enhancements into the production environment). The estimate of 83,333 hours is based on the assumption that the State will attempt to limit the number of modifications and/or customizations as much as possible and will change business processes in lieu of modification when appropriate to do so; however, a significant amount of customization will be required to meet the needs for some agencies such as the Department of Transportation and the health-related institutions. Development Report Development This category includes the work effort required to develop the reports necessary for the new ERP system to meet the States reporting needs (i.e., analysis, design, construct, testing, and moving the reports into the production environment). It was assumed that approximately 46,667 hours would be used to develop more than 800 reports of varying complexity. The estimates we have developed for this effort are based on STAs proprietary estimating metrics for ERP report development. Development Data Conversion / Loading This category includes the effort necessary to analyze, design, construct the conversion/loading programs, test the programs, and load the necessary data into the production system. Manual data loading efforts are also included in this category. The estimate provides for 26.0 FTEs to support the conversion efforts. Our estimates are based on the assumption that the implementation vendor will provide standardized conversion programs to assist with automated conversion activities. State and institution personnel will be responsible for extracting the appropriate data
Page 90
September 30, 2008
from existing administrative systems. We estimate that it will require approximately 96,667 hours of effort to be performed by the integration contractors. Organizational Change Management This category includes the work effort required to mentor the States change management activities, focusing primarily on executive sponsorship and communication. We estimate that 10.0 FTEs will be required throughout the entire 24-month implementation period and 2.0 FTEs for the 6-month post go-live period for a total of 42,000 hours. Training and Documentation Project Team Training This category includes the expenditures necessary to train the State project team members. We assume that the State will be able to negotiate an agreement with the selected ERP software vendor to deliver the training for a set fee. Training and Documentation End User Training This category contains the effort for contractors to assist in (1) developing end-user training materials based on the To-Be process designs, (2) training the State trainers, and (3) delivering the training to the agencies included in the initial software implementation. We assume that up to 4.0 FTEs will be required for months 4 through 11, and that 28.0 FTEs will be required for months 12 through 24 of the 24-month implementation period, for a total of 66,500 hours of effort. Infrastructure Management & Project Support (including Data Warehouse) This category includes the cost of resources to: Install the software; Apply updates/patches to the software during the implementation period; Control the movement of software configuration changes through the development environment and into the production environment; Direct the system stress testing (i.e., volume testing); Tune the system for performance; Assist in developing procedures for ongoing system operations; Implement the data warehouse (DW) infrastructure (hardware and software); Assist in developing data cubes; and Analyze, design, and configure the extract/transfer/load (ETL) software to pull ERP transaction data into the DW, as well as data from non-ERP sources. We assume that 8.0 FTES will be required for months 1 to 5 and that 18.0 FTES will be required for months 6 through 24 of the 24-month implementation period to perform the activities in this category, for a total of 68,333 hours of effort.
Page 91
September 30, 2008
Production Support There is not a designated row on the staffing spreadsheet for production support. Based on our previous experiences in other states, we assume that the integration contractor will be retained to provide production support for six (6) months following the go-live. We have extended the staffing for each category above at a reduced level. State Employee Cost Assumptions Note that the items that follow correspond to the line items that pertain to the State Project Team members in rows 191-232 of Schedule A3 in this report. The State Project Team was built based upon the ratio of approximately 1.0 State FTE to 1.0 consultant FTE. The State staff to consultant ratio is 1.0 to 1.0 because at peak the Project Team size is estimated to be 546 total staff. We feel that with this project team size requirement, the State can only expect to acquire a limited number of staff from the Comptroller and State agencies/institutions. Therefore, a greater number of contractor staff is required. Project Management We assume that 4.0 FTEs will be required for the duration of the 24-month implementation period, for a total of 19,000 hours of effort. Functional Team This category includes the effort of the State Project Team members to work with the contractor functional team (see Software Configuration and Process Reengineering above) and assist in: Developing To-Be business processes; Configuring the software in accordance with the defined To-Be processes; and Performing configuration unit testing, and assisting in integration, system, and stress testing. We estimate that this activity would require approximately 714,500 hours based on the functional scope and the implementation duration. Deployment This category includes the following: Change management; and Training/agency support. We estimate that the Change Management activities will require 8.0 FTEs for the first 11 months of the 24-month implementation period. Months 12 to 24 will require 24.0 FTEs, for a total of 72,667 hours of effort. We estimate that the Training/Agency Support activities will require 4.0 FTEs for months 1 through 11 and 32.0 FTEs for months 12 through 24 of the 24-month implementation period, for a total of 79,667 hours of effort.
Page 92
September 30, 2008
Technical Team This category includes the effort on the part of the State Project Team members to work with the contractor team members on: Workflow; Report development; Interface development; Data conversion; Modifications and enhancements; System Administration / Support; and Data Warehousing. We estimate that this activity would require approximately 207,333 hours of effort based on the functional scope and the implementation duration. Deployment Costs Contractor and State This area includes the effort to implement the ERP system from FY 2013 through FY 2016. We classified the agencies into low, medium, and high complexity groups. Next, we estimated the number of hours to deploy the ERP system to each agency based on its complexity. The hours, associated with each deployment activity, are shown below.
Cost Assumptions That Are Not Hours-Based Note that the items that follow correspond to the line items in Schedule A1 in which the estimates are not hours-based (see rows 1, 5, 6, 15, 16, 18, and 19 for Schedule A1).
Page 93
September 30, 2008
Application Software License and Software Maintenance Fee It is estimated that the software license fee for the new ERP system will be approximately $34.0 million. This estimate is based on an informal estimate provided by a major ERP software provider and includes a confidence factor of +/20%. The estimate is intended to cover the functionality provided under HB 3106 and assumes the entire purchase would be made and paid for in a single transaction. The estimate should not be considered a formal quote. The cost estimate is allocated as follows: $22 million for State agencies and $12 for higher education. It is expected that the PeopleSoft software could be provided at a reduced cost since licenses for the PeopleSoft ERP software suite are already owned by the agencies that use HHSAS and ISAS as their core administrative system, as well as the Employees Retirement System, and numerous institutions of higher education. Annual software maintenance fees typically range between 17% and 20% of the original software license fees. Annual software maintenance fees of 20%, or $6,800,000 for the first year, were assumed for purposes of this analysis. Facilities and Equipment We estimate that the start-up costs will total approximately $4,000,000 and that the costs will average approximately $2,500,000 per year for the second and third year of the implementation/deployment period, and approximately $650,000 per year for the remainder of the project. We included no facilities costs for Year 0 under BCA 2 as consulting and project team costs for pre-implementation activities are assumed to be absorbed through existing Comptroller facilities and equipment. Infrastructure (Database, Server, and Network) This estimate is intended to provide a high-level approximation of data center and infrastructure costs. It is based on STAs experience with similar statewide projects and input provided by the ERP Project Team and technology experts in the Comptrollers Office. It is somewhat difficult at this stage of the study to estimate the cost for this category under BCA 2 as the ERP software has not been selected nor has the technical platform been fully architected for the Statewide ERP system. However, it is assumed that the platform that is currently operating the ISAS solution would be extended to accommodate the data center requirements of BCA 2. The Project Team estimated the costs for BCA 2, which includes all State agencies and institutions of higher education on the extended ISAS platform. The hardware costs included four IBM UNIX P6 595 servers that were fully-configured with all processor slots utilized. Two of the servers were assumed to be co-located for high availability, full redundancy and disaster recovery failover. These co-location costs were also included, taking connectivity into account. For BCA 2, the hardware and technical infrastructure total estimated cost includes the following cost elements: Processors Application / database server(s) processing hardware; Maintenance and server upgrades;
Page 94
September 30, 2008
New server operating system software and server operating system upgrades and maintenance Disk/Storage Area Network (SAN) capacity RDBMS Software Maintenance Transaction monitoring software Middleware such as gateways LAN/WAN upgrades Telecommunications costs Hardware costs Software costs
Data Storage and Management
Systems Management and Security software
Communications
Backup / Disaster Recovery
Ongoing Support/Operations and Upgrade Cost Assumptions Ongoing Support/Operations Management It is assumed that only State resources will fill the positions covered in this cost category. In developing estimates for this (and all of the Ongoing Support/ Operations sub-categories), we took into consideration the staffing levels of other states and STAs ERP experience. Also, the assumption was made that the best and brightest resources from the implementation Project Team would fill these Ongoing Support/Operations positions. The estimate for this cost category includes 6.0 management-level FTEs. Ongoing Support/Operations Functional Support It is assumed that 26.0 FTEs will support the HR/Payroll functional area and 27.0 FTEs will support the Financial/Procurement areas. It is assumed that all of these FTEs will be State resources. Ongoing Support / Operations Technical Operations and Support This category includes all activities to support the technical environment (e.g., software operation and maintenance, application of software patches/fixes, moving development items into the production environment). The category also includes resources necessary to support the system interfaces and modifications/enhancements. We are assuming that 45.0 State FTEs will be required to provide ongoing technical operations and support.
Page 95
September 30, 2008
Ongoing Support / Operations Ongoing Training/Help Desk We are assuming that 24.0 FTEs will be assigned to support ongoing training as well as the help desk. The training team will be supplemented at times by the ongoing functional and technical support personnel. Upgrade in Year 6 Based on our prior ERP experience, we assumed that it will require approximately 477,313 hours to perform a software upgrade of the new ERP system, with approximately 40% of the effort being performed by contractors and the remaining 60% being performed by State personnel. These estimates are also based on an upgrade of existing functional/technical capabilities. Avoided Systems Costs / System Savings System Surveys were sent to twenty-four (24) agencies which collectively comprise more than 97% of the States operating budget. We also drew from the responses to a survey conducted by the Comptroller in November 2007 to develop an initial estimate of the Avoided Systems Costs for the Higher Education entities within the scope of this BCA, which were then reviewed by the Higher Education entities and modified as necessary. Meetings and follow-up discussions were also conducted to collect system cost information. The results of the surveys are presented in the sections below that describe the Selected Alternatives in detail.
Page 96
September 30, 2008
Agency Avoided Systems Costs for Alternative 2

FYE 2009
FYE 2010
FYE 2011
FYE 2012
FYE 2013
FYE 2014
SW Systems TDHCA--332 GLO--305 Lottery--361 Rail Road--455 TRS--323 OAG--302 TWDB--580 TEA--701 CPA--304 TxDOT--601 TCEQ--582 OOG--301 ERS--327 TPFA--347 DPS--405 TWC--320 TPW D--802 TDJC--696 HHSC--529 DFPS--530 DSHS--537 DARS--538 DADS--539 THECB--781 Total Costs Ongoing Costs Projects Costs
117,575,000
4,438,928
890,000
890,000
890,000 -
890,000 3,729,265
890,000 3,878,436 677,013
22,088,000
11,088,000
118,465,000 890,000 117,575,000
890,000 890,000 -
890,000 890,000 -
26,707,265 26,707,265 -
20,972,377 20,972,377 -
122,018,950 916,700 121,102,250
944,201 944,201 -
972,527 972,527 -
30,059,262 30,059,262 -
24,312,733 24,312,733 -
Page 97
September 30, 2008
Agency Avoided Systems Costs for Alternative 2 (continued)

Yr 6 Yr 7 Yr 8 Yr 9 Yr 10 Total Years 0 - 10
FYE 2015
FYE 2016
FYE 2017
FYE 2018
FYE 2019
SW Systems TDHCA--332 GLO--305 Lottery--361 Rail Road--455 TRS--323 OAG--302 TWDB--580 TEA--701 CPA--304 TxDOT--601 TCEQ--582 OOG--301 ERS--327 TPFA--347 DPS--405 TWC--320 TPW D--802 TDJC--696 HHSC--529 DFPS--530 DSHS--537 DARS--538 DADS--539 THECB--781 Total Costs Ongoing Costs Projects Costs
4,506,034
8,324,712 410,000
8,324,712 410,000 70,000 161,654 37,866 791,777 352,999 53,450 1,621,500 890,000 4,362,716 677,013 10,000 755,114 21,844 755,000 1,110,000 482,045 2,203,613 10,588,000
8,324,712 410,000 80,000 161,654 37,867 831,366 505,399 53,450 1,621,500 890,000 4,537,226 677,013 10,000 713,163 14,984 765,000 1,110,000 499,060 2,203,613 10,588,000
8,324,712 410,000 80,000 161,654 37,867 831,366 505,399 53,450 1,621,500 890,000 4,537,226 677,013 10,000 713,163 14,984 765,000 1,110,000 499,060 2,203,613 10,588,000 231,361 34,265,368 33,895,368 370,000
159,818,810 1,640,000 230,000 808,270 189,329 3,208,582 1,714,398 213,799 6,486,000 8,900,000 29,273,362 4,062,077 50,000 2,675,819 78,985 3,755,000 4,440,000 1,480,165 11,018,066 86,116,000 1,143,399 327,302,061 208,767,061 118,535,000
161,654 37,864
890,000 4,033,575 677,013 10,000 13,321 725,000
161,654 37,865 754,073 350,599 53,450 1,621,500 890,000 4,194,918 677,013 10,000 494,379 13,853 745,000 1,110,000 2,203,613 10,588,000
2,203,613 10,588,000
224,766 24,070,840 24,070,840 -
226,857 32,867,487 32,867,487 -
229,054 33,908,357 33,688,357 220,000
231,361 34,265,368 33,895,368 370,000
28,741,841 28,741,841 -
40,422,863 40,422,863 -
42,954,092 42,675,403 278,689
44,708,533 44,225,767 482,766
46,049,789 45,552,540 497,249
381,184,792 258,823,837 122,360,955
Page 98
September 30, 2008
Higher Education Avoided Systems Costs for Alternative 2

Yr 0 University Systems FY2008 FY2009 Yr 1 FY2010 Yr 2 FY2011 Yr 3 FY2012 Yr 4 FY2013 Yr 5 FY2014
Texas A&M System -ongoing Texas A&M System -projects Texas Tech System -ongoing Texas Tech System -projects Texas State System -ongoing Texas State System -projects University of North TX System -- ongoing University of North TX System -- projects University of TX System -ongoing University of TX System -projects University of Houston System -- ongoing University of Houston System -- projects Universities not Systemaffiliated -- ongoing Universities not Systemaffiliated -- projects Total All Univ ersities -ongoing Total All Univ ersities -projects Total All Univ ersities Total All Univ ersities -ongoing -- inflated Total All Univ ersities -projects -- inflated Total All Univ ersities -inflated
2,305,060 -
1,531,317 -
3,836,377 3,836,377
3% 3% 3%
4,447,412 -
4,447,412
Page 99
September 30, 2008
Higher Education Avoided Systems Costs for Alternative 2 (continued)

Yr 6 University Systems FY2015 Yr 7 FY2016 Yr 8 FY2017 Yr 9 FY2018 Yr 10 FY2019 Total Years 0 - 10
Texas A&M System -ongoing Texas A&M System -projects Texas Tech System -ongoing Texas Tech System -projects Texas State System -ongoing Texas State System -projects University of North TX System -- ongoing University of North TX System -- projects University of TX System -ongoing University of TX System -projects University of Houston System -- ongoing University of Houston System -- projects Universities not Systemaffiliated -- ongoing Universities not Systemaffiliated -- projects Total All Univ ersities -ongoing Total All Univ ersities -projects Total All Univ ersities Total All Univ ersities -ongoing -- inflated Total All Univ ersities -projects -- inflated Total All Univ ersities -inflated
2,305,060 -
2,769,106 -
2,769,106 -
3,025,895 -
3,025,895 -
16,200,123 -
3,300,797 -
3,300,797 -
3,307,070 -
3,307,070 -
3,307,070 -
16,522,805 -
1,531,317 -
1,531,319 -
1,531,317 -
1,531,317 -
1,531,317 -
9,187,904 -
1,932,089 -
3,280,739 -
3,280,739 -
3,280,739 -
11,774,306 -
3,842,909 -
3,842,909 -
7,685,818 -
7,137,174 7,137,174
9,533,311 9,533,311
10,888,233 10,888,233
14,987,931 14,987,931
14,987,931 14,987,931
61,370,956 61,370,956
8,522,159 -
11,724,770 -
13,792,887 -
19,555,850 -
20,142,526 -
78,185,604 78,185,604
8,522,159
11,724,770
13,792,887
19,555,850
20,142,526
Page 100
September 30, 2008
The Avoided Systems Costs for Higher Education under Alternative 2 are less than might be expected over the 11-year planning horizon ($78.2 million); Technology leaders at the university systems provided the following rationale: In some cases, maintenance and support software contracts are built on the original modules purchased; those institutions cannot eliminate modules no longer needed and reduce their costs. Additionally, some modules not addressed by HB 3106 would still be required (e.g., student information system and other modules that share tables required for student information) Existing hardware and support costs cannot be eliminated due to reliance on the hardware and support staff for other administrative and programmatic systems Due to the fact that large university systems have a broader view of ERP systems than a conventional State agency, and the complexities associated with implementing ERP systems for health-related and research institutions, the model typically utilized for State government as described in Alternative 2 is not conducive to higher education ERP implementations. Institutions would not have the opportunity to make unique configurations required to meet their administrative business needs but instead would have to build customizations and sophisticated interfaces to legacy systems that will not be replaced After analyzing their current ongoing costs and the impact of Alternative 2 on their university system, the systems leadership concluded that Alternative 2 would not provide critical functionality required for higher education (e.g., student information system) and that they would have no Avoided Cost savings under Alternative 2. As an example of the complexities caused by Alternative 2, the System would have to continue to maintain components of its existing ERP system since student billing and receivables maintained in their current system are required to interact with their student information and financial aid systems Value Pocket Savings The State could potentially realize process improvements in a number of areas of the organization as a result of implementing a new statewide ERP system. Note that only process-improvement benefits that could potentially result from the new implementation are included. We have coined the term Value Pockets to refer to the most likely sources of significant value (i.e., cost savings and other benefits) to be found in each functional/process area within the scope of a possible new statewide ERP implementation. Dollar-quantifiable Value Pocket benefits were estimated from data collected from State personnel through interviews and a Value Pocket survey that was sent to twenty-four (24) agencies which collectively comprise more than 97% of the States operating budget. Meetings and follow-up discussions were also conducted to collect information used to estimate benefits/savings from process improvements. The Value Pocket survey requested two (2) types of data:
Page 101
September 30, 2008
1. Effort-Related Data The survey captured the approximate total number of hours (and associated compensation) State employees and contractors spend on an annual basis performing certain activities that are within the scope of this BCA. STA then applied a percentage savings factor to the results to estimate the amount of time and associated compensation that could be saved/redirected as a result of implementing a new, integrated, statewide ERP system. These savings factors were derived from a variety of sources, including the experiences of other government organizations, and estimates made by us based on our analysis of the respective processes and our experience, in general, in these matters, as well as input from the States project leadership 2. Metric Data This data was not directly effort-related (e.g., dollar balances, postage costs, etc.) A summary for the survey results is presented in the tables below. Summarized Value Pocket Survey Effort-Related Data Alternative 2 Annual Savings before 3% Inflation Factor Applied
Estimated Savings Estimated Savings Hours Dollars 131,009.1 $ 3,491,395 8,635.5 $ 206,184 7,182.5 $ 243,236 8,109.7 $ 200,920 72,713.5 $ 2,837,718 1,297.8 $ 58,140 28,057.6 $ 1,022,296 2,540.5 $ 60,796 29,423.5 $ 836,350 51,111.9 $ 1,533,453 1,049.0 $ 38,612 8,754.1 $ 245,644 24,025.4 $ 702,243 31,488.1 $ 768,604 23,806.0 $ 871,572 3,550.2 $ 114,565 158,148.4 $ 4,302,487 590,902.7 $ 17,534,214 37.3% 38.0%
Financial & Procurement
HR / Payroll
Functional Areas Accounts Payable Accts Payable/ Accts Receivable Accts Receivable / Billing Asset Management Budget Development Cost Allocation GL & Budgetary Control Inv entory Fleet Management Procurement Project Accounting Grant Accounting Applicant Services Payroll Personnel Admin Training Time and Labor Total Overall Savings Percentage
Total H ours All Agencies 316,673.2 28,785.0 12,930.0 13,525.6 242,378.5 1,854.0 42,333.2 5,031.0 94,690.3 134,412.6 2,061.0 15,588.0 60,063.5 54,331.1 45,517.0 11,834.0 500,715.7 1,582,723.7
Total Dollars All Agencies $ 8,375,186 $ 687,280 $ 435,393 $ 333,260 $ 9,459,060 $ 83,058 $ 1,534,566 $ 120,220 $ 2,718,633 $ 4,136,067 $ 75,871 $ 433,309 $ 1,755,607 $ 1,326,556 $ 1,646,531 $ 381,882 $ 12,615,995 $ 46,118,472
Page 102
September 30, 2008
Summarized Value Pocket Survey Metric Data Alternative 2 Annual Savings before 3% Inflation Factor Applied
Functional Area Value Pocket Question Totals All Agencies Annual Savings Ben efit Assumptions / Calculation
Accounts Payable
Accounts Receivable / Billing Accounts Receivable / Billing
Inventory
Approximate annual cost to mail Remittance Advices to vendors (Do not answer if your systems enables you to send RAs electronically and you only ma il RAs to a small percentage of total RA recipients) Average Accoun ts Receivable balance (Only answer this question if your agency do es not utilize a truly integrated, full-featured Accou nts Receivable syste m with modern ERP functionality that could h elp improve data accuracy, visibility, and related co mmunication, which in turn could help reduce the aggregate AR balance, thereby lowe ring the interest cost of carrying AR) Approximate dollar amount of charge-offs each year (Only answer this question if you r agency lacks a truly integrated AR system with workflow functionality found in modern ERP systems that is used to man age bad debts) Average Inventory b alance (This only applies to agencies that have inve ntory management requirements [e.g. warehouse] but d o not utilize a full-fea tured, inte grated Inventory Management system) Approximate annual cost of vehicle downtime (This only applies to agencies that have Fleet Management requirements but do not utilize a full-featured, integrated Fleet Management system) Approximate annual cost of vehicle maintena nce & repair (This only applies to agencies that have Fleet Management requirements but do not utilize a full-featured, integrated Fleet Management system) Approximate annual cost to mail Purchase Orders (Do not answer if your systems enables you to send POs electronically and you only ma il POs to a small percentage of total PO recipients) Approximate annual cost to mail Remittance Advices to employees each ye ar (Do not answer if your systems enables you to send RAs electronically and you only ma il RAs to a small percentage of total recipients) Totals
20,606
18,546
90% savings
10,766,337
80,748
Annual saving of 5% interest carry on 15% reduction in av erage balance
30,206
3,021
10% reduction\
$ 121,309,147
909,819
Fleet
Fleet
1,520,227
152,023
10% annual reductions
Procurement
40,920
36,828
90% reduction
Payroll
48,378 $
43,540 1,244,523
70% reduction
It is also assumed that most of the Effort-Related annual savings presented in the table above would be realized over time through attrition, employee retirement, reassignment to approved but unfilled positions, and the like. In keeping with this assumption, it is assumed that none of the effort-based Value Pocket benefits would be realized during the first year after an agency goes live as follows: 1st year following go-live 2nd and remaining years following go-live 0% 100%
We assumed the timing of the recognition of the benefits that are not Effort-Related (i.e., calculated from Metric Data) would be the same as for the Effort-Related benefits, as depicted in the table above. The timing of the recognition of the Value Pocket benefits during the timeframe of the BCA is depicted in the table below (note that a 3% inflation factor has been applied to the values in the table below).
Page 103
September 30, 2008
Recognition of Value Pocket Benefits Alternative 2

($ millions)
Acquire F in / Proc / H R / Pay
Yr 0
Value Po cket Benefits by Survey Type
Yr 1
Yr 2
Yr 3
Yr 4
Yr 5
Yr 6 FY 2015 1 2.7 0.2 1 5.1 0.2 1 5.4
Yr 7
Yr 8
Yr 9
Y r 10 FY 2 019 17. 5 1. 2 23. 6 1. 5 25. 1
FY 20 09 FY 20 10 FY 2 011 FY 2012 FY 2013 FY 2 014 1. 8 0. 0 2. 0 0. 0 2. 0 1.8 0.0 2.1 0.0 2.1 3.1 0.1 3.5 0.2 3.7
FY 2016 FY 20 17 FY 20 18 15.5 2.6 19.1 3.1 22.1 1 7.4 1.2 2 2.0 1.4 2 3.4 17 .5 1 .2 22 .9 1 .5 24 .4
Alt 2 V P B ene fits -- Age ncies -- Ef fo rt re la ted Alt 2 V P B ene fits -- Age ncies -- Me tric Alt 2 V P B ene fits -- Age ncies -- Ef fo rt re la ted -- inf lated Alt 2 V P B ene fits -- Age ncies -- Me tric -in flate d T ota l -- inflated only
Results of Financial Analysis The schedule below presents a summary of estimated ERP Costs applied against estimated Avoided Systems Costs/System Savings and Value Pocket benefits/savings, developed using our Business Case Analysis Methodology. Schedule of Estimated Net Costs and Benefits/Savings from Implementing ERP Alternative 2
($ millions)
Acquire Yr 0 FALSE Fin / Proc / HR / Pay Yr 1 Yr 2 FYE 2010 FYE 2011 Yr 3 FYE 2012 Yr 4 Yr 5 Yr 6 Yr 7 Yr 8 Yr 9 Yr 10 FYE 2013 FYE 2014 FYE 2015 FYE 2016 FYE 2017 FYE 2018 FYE 2019
Cost and Benefits/Savings Categories
T otal (930.3) 381.2 78.2 (471.0)
ERP Costs (implementation & operation) Avoided System Costs -- Agencies Avoided System Costs -- HE Net before Process-Improvement Benefits Cumulative Net before ProcessImprovement Benefits Process-Improvement Benefits -Agencies (Value Pockets) Process-Improvement Benefits -Higher Ed (Value Pockets) Net after Process-Improvement Benefits Cumulative Net after ProcessImprovement Benefits PV of Net after ProcessImprovement Benefits Cumulative PV of Net after Process-Improvement Benefits NPV (Yr 0 through Yr 10) @ 5% per annum NPV (Yr 0 through Yr 10) @ 8% per annum
(2.6) (2.6) (2.6) (2.6) (2.6) (2.6) (2.6) (295.9) (266.4)
(4.0) 122.0 118.0 115.5 118.0 115.5 112.4 109.8
(162.9) 0.9 (161.9) (46.5) (161.9) (46.5) (146.9) (37.0)
(163.3) 1.0 (162.3) (208.8) 2.0 (160.3) (206.8) (138.5) (175.5)
(100.4) 30.1 (70.4) (279.1) 2.1 (68.3) (275.1) (56.2) (231.7)
(77.6) 24.3 4.4 (48.9) (328.0) 3.7 (45.1) (320.2) (35.4) (267.1)
(70.9) 28.7 8.5 (33.6) (361.6) 15.4 (18.3) (338.5) (13.6) (280.7)
(150.9) 40.4 11.7 (98.7) (460.3) 22.1 (76.6) (415.0) (54.4) (335.1)
(60.8) 43.0 13.8 (4.1) (464.4) 23.4 19.4 (395.7) 13.1 (322.0)
(96.6) 44.7 19.6 (32.3) (496.7) 24.4 (7.9) (403.6) (5.1) (327.1)
(40.4) 46.0 20.1 25.8 (471.0) 25.1 50.9 (352.8) 31.2 (295.9)
118.2 (352.8)
(295.9)
As illustrated above, the Net Present Value (NPV) for Alternative 2 is -$295.9 million, assuming a discount rate of 5% per annum, or -$266.4 million, assuming a discount rate of 8% per annum. The investment would be far from breaking even during the 11-year
Page 104
September 30, 2008
analysis period of the BCA (-$352.8 million see the Cumulative Net after ProcessImprovement Benefits row in the table above).
Business Case Alternative No. 3 (BCA 3): Hub Model

Description The Hub Model scenario is a variation of BCA 2. It assumes that only State agencies (with the exception of the Health and Human Services agencies) will migrate to a new Statewide ERP platform operated by the Comptrollers ASP service. The Health and Human Services agencies and the Higher Education Systems will operate as reporting Hubs and interface with the Statewide Data Warehouse that will be operated by the Comptrollers ASP service. Under this model, specific agency/institution transactional systems would be interfaced to the Statewide ERP System for addressing major functional needs such as payment processing. As with BCA 2, the existing statewide legacy administrative systems (e.g., USAS, USPS, SPA, HRIS, SPRS, TINS) will be replaced by the Statewide ERP system that would provide all functionality identified in HB 3106.
BCA 3 Hub Model Diagram
Statewide ERP Platform

Consolidation of: USAS/USPS/HRIS/SPRS/SPA/TINS/Paysubs/Warrants + ABEST (if possible)
NOTE: Higher Ed transactional data (e.g. warrants) is submitted to the S/W ERP system at the institution level
CPA ASP
HHSC Data Warehouse
System Data Warehouse
Statewide Baseline ERP
HHSC Agencies
TAMU System
Texas Tech System
Tx State System
Ind. Institutions Data Warehouses TWU MWStU SFASU TSU TSTC
All non-hub AGYs including Treasury All Modules including HR/Payroll
UT System
UH System
North Texas System
S/W ERP Baseline for Distribution

Push SW ERP Baseline to Service Bureaus Push Awarded Contracts from TPASS
All agencies & co-ops access for Term, TXMAS & Open Market contracts
Page 105
September 30, 2008
The primary difference between BCA 2 and BCA 3 is the establishment of data reporting Hubs that will interface into the Statewide Data Warehouse. A separate Data Warehouse Hub will be established for each Higher Education System and the Health and Human Services agencies that currently utilize the HHSAS system. Each Hub will develop its own data warehouse capability and every Hub component (agency or institution) will be required to provide data to the Hub Data Warehouse. Component institutions in each Higher Education System and the Health and Human Services agencies will be able to operate and maintain whatever platform and application set they choose with the only restriction being that the System Data Warehouse conforms to the statewide data standards and standard business processes required for statewide reporting. The Statewide ERP baseline code will be made available to every Hub (beneficial to those that utilize Oracles PeopleSoft ERP software) and will be patched and maintained according to the ERP vendors recommended schedule. Other elements of BCA 3 include the following: Platform Operation: The Comptroller will operate and manage an ASP for all State agencies (except for the HHS agencies). The HHS agencies and all Higher Education Systems will operate their own enterprise-level data warehouse that will collect, compile, and normalize all agency and institutional data. Interfacing to Statewide ERP System: Hub Data Warehouses will be interfaced to the Statewide Data Warehouse. There will also be individual interfaces from component institutions and agencies for certain transactional data such as warrants and paystubs so that the Statewide ERP platform can produce payment vouchers and issue warrants or direct deposit payments. Hubs will not roll up payment transaction data. Source Code Modifications: Source code modifications will be restricted to only those required by State or Federal mandate for State Agencies on the Comptrollers ASP. To the extent possible, state or federal mandates of the HHS agencies will also be addressed in the statewide ERP solution, since the HHS Hub intends to use the same ERP software as the Comptroller ASP. Hubs can select and implement modifications and enhancements as they see fit provided they are able to meet the statewide data requirements. Patch and Release Management: The Comptroller ASP will stay current with the ERP vendors patch and release cycle. Each Hub can determine its own patch and release management cycle provided it continues to comply with the statewide data requirements. Hubs also have the option of utilizing the Statewide ERP baseline code, which will be maintained according to the ERP vendors recommended schedule. Strengths of the Hub Model Alternative Relative strengths of BCA 3 primarily have to do with the fact that it is a hybrid approach. The State will achieve economies of scale and efficiency gains through the implementation of a single, unified platform for almost all State agencies while still allowing for the differences in the functionality requirements of the Hubs. Other strengths of this hybrid approach are as follows: Addresses HB 3106 requirements; Addresses Comptroller Rider 16 regarding fleet management;
Page 106
September 30, 2008
Implementation costs can be more reasonably managed than under BCA 2; Proven model as this is the most common statewide deployment model resulting in lower overall project risk; Eliminates proliferation of agency ERP and other administrative shadow systems, while allowing higher education to maintain its own ERP solutions that are integrated with other ERP functions such as patient care, student information, learning management, and library systems; Complies with guiding principles of the ERP Advisory Council to implement standardized business processes and not throw out what works; Provides a plan that allows the State to significantly upgrade the functionality and reporting capabilities of the statewide administrative systems (e.g., USAS, SPRS, USPS, HRIS, SPRS, TINS); Allows the State to execute the implementation project plan in a strategic and controlled manner in accordance with the funding plan; Provides for significantly enhanced statewide reporting for both higher education and State agencies; Hubs will gain the benefit of centralized reporting at the System or Enterprise level through data warehouses that will be used to gather and normalize disparate institutional data to support effective statewide reporting goals; Allows for the Hubs to address ERP consolidations through an evolutionary process as their existing systems reach the end of their useful life; and Facilitates governmental transparency. Weaknesses of the Hub Model Alternative No significant savings for higher education from process improvements and avoided systems costs; and State agencies may seek to be a Hub in order to avoid changing their business processes. Constraints and Risks The risks associated with the implementation of the Hub Model are primarily due to the various multiple elements and activities that will need to be managed concurrently. Under BCA 3, institutions of higher education will be pursuing a different approach (data warehouse) than State agencies (full implementation on new ERP system) in order to achieve the desired benefits of a Statewide ERP System, and as such, these paths will need to be coordinated in order to achieve the expected benefits under BCA 3. Deployment Strategy and Approach Only the State agencies (excluding the Health and Human Services agencies and higher education) would be deployed under this model. The participating agencies would be logically organized into deployment groups or waves. All functional modules would be deployed for all agencies within a specific group or wave. The first deployment phase will include the development of a prototype deployment model that would become the
Page 107
September 30, 2008
blueprint for deploying all functionality among the remaining agency deployment waves upon the successful deployment for the initial agency wave. Each deployment phase would be executed sequentially until all agencies have been deployed on the statewide ERP system. For cost estimating purposes, STA and the Comptroller Project Team developed a detailed deployment schedule for State agencies under BCA 3. This planning schedule will be made available to the Comptroller as part of project close-out activities. The schedule was used solely for the purposes of developing our estimates and the Comptroller has not made any decisions or plans regarding the deployment schedule should an actual ERP project be funded by the Legislature. Additionally, ITCHE members and HHSC representatives assisted us in determining the assumptions regarding when the Hub data warehouses would go into production. Estimated Costs The costs in this alternative include the estimated costs to acquire, implement, and operate the new ERP system for all State agencies except for HHSC. Institutions of higher education are not included in the scope of this alternative. The estimated cost of performing a technical upgrade of the ERP system is included in this alternative. Approach The cost estimates developed for this analysis were based on input from State personnel and on our experience assisting public sector clients in evaluating, selecting, acquiring, and implementing integrated enterprise-wide systems. To develop these estimates, we utilized our proprietary estimating model, which incorporates estimating standards/metrics and provides an overall framework for developing estimates of this type. The approach taken to estimate the cost of acquiring and implementing the ERP system was to: Estimate the number of hours to implement the functional modules within scope. The estimated number of hours addressed the following services: Project Management; Pre-Implementation Services / Project Oversight ; Software Installation, Configuration & Process Reengineering; Custom Development, including: Automated Interfaces Software Modification / Enhancements Report Development Data Conversion / Loading Workflow Configuration Data Warehouse Implementation;
Organizational Change Management; and
Page 108
September 30, 2008
End-User Training and Documentation.
After estimating the total number of consulting hours, we estimated the average loaded consulting rate that would be used by the implementation firm. The term loaded rate refers to a rate that includes labor and travel-related costs. The loaded rate was then multiplied by the total estimated project hours to determine the total implementation vendor cost. Estimate the costs of other items associated with acquiring and implementing the ERP system, which included the following: Software License(s); Project Team Training; Facilities and Equipment; Infrastructure (Database, Server, and Network); and Compensation for State Project Team Members.
The cost of these items was added to the total implementation cost to determine the total cost of acquiring and implementing a new ERP system. We also estimated the cost of software maintenance fees, production support provided by the vendor(s), as well as ongoing cost of operating and supporting the system after being put into production. These estimates were based on our experience with similar statewide ERP system implementations.
Page 109
September 30, 2008
Summary Schedule of Estimated Costs of Implementing and Operating Alternative 3
Page 110
September 30, 2008
The table above presents a summary of our estimated costs to implement, operate, and maintain the system over an 11-year period. Please refer to Appendix B for detailed information regarding our assumptions, as well as detailed cost-estimating schedules. As indicated in the Introduction section of this report, the estimating schedules, including the one above, contain an Acquire phase that spans FY 2009 and the first two months of FY 2010 and that includes the work effort of consultants and State personnel to: Develop system requirements for a statewide ERP system; Develop an RFP for the acquisition of ERP integration services; and Facilitate the acquisition process and contract negotiations for an ERP integration firm. General Supporting Assumptions The core of the new ERP system will be configured, tested and implemented for a subset of agencies during a 22-month implementation period, starting in November 2009. After the initial agency deployment in 2011, the ERP system will be rolled out in multiple waves, over a six-year period. The roll-out will start in FY 2012 and end in FY 2015. An average hourly, expense-loaded rate of $180 is assumed for the implementation and project oversight contractors. The cost of State of Texas resources is assumed to be $58.50 per hour. This dollar amount is based on the assumption that the average annual salary of State staff working on the project is approximately $90,000 and the average load is 30%. It is assumed that a full-time equivalent number of hours per year are 2,000 for both contractor resources and State resources. An average inflation factor of 3% was applied to non-State staff costs. average inflation factor of 2% was applied for State staff. A software upgrade will occur during Year 6 of the project. The implementation work effort will be conducted using 1.30 State resources to every 1.0 contractor resources. The estimated costs associated with BCA 3 are based on continuing the relationship with Oracles PeopleSoft ERP software suite. Any change in ERP software provider would likely result in a considerably higher cost as the State would not be able to leverage the work performed to date on the various PeopleSoft projects in Texas State government and higher education. Project Team Composition The staffing model used for the cost estimates is based on our experience with similar implementations of this type and on input from the States project leadership. Not all of the Project Team members will be utilized throughout every aspect of the initiative. An
Page 111
September 30, 2008
Therefore, for information on the total assumed number of hours that resources will work on the project, please refer to the appropriate schedules in Appendix B. Contractor Cost Assumptions Note that the items that follow correspond to the line items pertaining to Contractors in rows 1-205 of Schedule B3 of this report. Project Management We assume that 2.0 FTEs will be required for the duration of the 22-month implementation period, plus a six month post go-live support period for a total of approximately 9,333 hours. Pre-Implementation Services/Project Oversight Work effort associated with software planning, acquisition, and project oversight services are summarized in the table that follows:
Activity Planned Start Date Planned End Date Duration No. of FTEs Hours
Define Requirements Create RFP Evaluate/Select Vendor Total
1/1/2009 1/1/2009 6/1/2009
5/31/2009 5/31/2009 10/31/2009
5 months 5 months 5 months
5 1 6
4,167 833 5,000 10,000
While most of activities take place during Year 0, the vendor selection continues into the first two months of Year 1. It should be noted that the estimates are based on the assumption that the State will start with a baseline set of public sector requirements. An additional assumption is that the CPA will provide one resource for each consultant and will also recruit five (5) to fifteen (15) subject matter experts for each module to participate in the requirements sessions. Responsibility for refining the baseline requirements and developing the new requirements would be divided among five (5) FTEs. This five (5) month period provides adequate time for each FTE to have two (2) to three (3) weeks of preparation time, ten (10) to fifteen (15) half-day meetings per module, and a week to finalize the requirements. At the same time that the requirements are being prepared, one (1) FTE will prepare the RFP. After the RFP is issued, six (6) FTEs will work to manage the procurement process, facilitate the proposal evaluation process, facilitate demonstrations, and negotiate the contract. After the implementation vendor is selected, five (5) FTEs will provide project oversight services. The team is expected to provide 18,333 hours of oversight during the twenty-two (22) month implementation phase and 36,000 hours of
Page 112
September 30, 2008
oversight through the deployment of the software. The total amount of preimplementation services and project oversight is 64,333 hours. Software Configuration and Process Reengineering This category includes the contractor effort involved in: Developing To Be business processes; Configuring the software in accordance with the defined To Be processes; and Performing configuration unit testing, and assisting in integration, system, and stress testing. We estimate that this activity would require approximately 116,833 hours based on the functional scope and the implementation duration. Workflow Configuration This category includes defining the States workflow business rules and configuring the systems workflow functionality in accordance with those rules. Included are the hours that are necessary for analysis, design, construction, testing, and moving the workflows into the production environment. We assume that 2.0 FTEs will be required for 20 months of the 22-month implementation period (7,667 hours) in order to provide the baseline workflow functionality necessary to support key business processes. Development Technical Lead We assume a Technical Lead will be in place for the entire 22-month implementation period and six-month post go-live support period, for a total of 4,667 hours. Development Interfaces This category includes the entire effort required to create a number of standard inbound and outbound interface formats. This effort includes analysis, design, construction, testing, and moving the interfaces into the production environment. We assume that resources will start in month 03 and reach a peak in months 07 through 22 of the 22-month implementation period to perform the activities in this category, for a total of 16,500 hours of effort. Development Software Modifications This category includes all the effort necessary to develop modifications/enhancements to the new ERP system in order for the system to meet the States business requirements (i.e., analysis, design, construction, testing, and moving the modifications/enhancements into the production environment). The estimate of 15,833 hours is based on the assumption that the State will attempt to limit the number of modifications and/or customizations as much as possible and will change business processes in lieu of modification when appropriate to do so; however, a significant amount of customization may be required to meet the needs for some agencies such as the Department of Transportation.
Page 113
September 30, 2008
Development Report Development This category includes all the effort required to develop the reports necessary for the new ERP system to meet the States reporting needs (i.e., analysis, design, construction, testing, and moving the reports into the production environment). It was assumed that approximately 10,500 hours would be used to develop more than 200 reports of varying complexity. The estimates we have developed for this effort are based on STAs proprietary estimating metrics for ERP report development. Development Data Conversion / Loading This category includes the effort necessary to analyze, design, construct the conversion/loading programs, test the programs, and load the necessary data into the production system. Manual data loading efforts are also included in this category. The estimate provides for 5.0 FTEs to support the conversion efforts. Our estimates are based on the assumption that the implementation vendor will provide standardized conversion programs to assist with automated conversion activities. State personnel will be responsible for extracting the appropriate data from existing administrative systems. We estimate that it will require the implementation contractors to perform approximately 16,833 hours of effort. Organizational Change Management This category includes the work effort required to mentor the States Change Management activities, focusing primarily on executive sponsorship and communication. We estimate that 2.0 FTEs will be required throughout the entire 22month implementation period and 1.0 FTE for the 6-month post go-live period for a total of 8,333 hours. Training and Documentation Project Team Training This category includes the expenditures necessary to train the State project team members. We assume that the State will be able to negotiate an agreement with the selected ERP software vendor to deliver the training for a set fee. Training and Documentation End User Training This category contains the effort for contractors to assist in (1) developing end-user training materials based on the To Be process designs, (2) training the State trainers, and (3) delivering the training to the agencies included in the initial software implementation. We assume that 1.0 FTE will be required for months 3 through 9, and that 10.0 FTEs will be required for months 10 through 22 of the 22-month implementation period, for a total of 23,667 hours of effort. Infrastructure Management & Project Support (including Data Warehouse) This category includes the cost of resources to: Install the software;
Page 114
September 30, 2008
Apply updates/patches to the software during the implementation period; Control the movement of software configuration changes through the development environment and into the production environment; Direct the system stress testing (i.e., volume testing); Tune the system for performance; Assist in developing procedures for ongoing system operations; Implement the data warehouse (DW) infrastructure (hardware and software); Assist in developing data cubes; and Analyze, design, and configure the extract/transfer/load (ETL) software to pull ERP transaction data into the DW, as well as data from non-ERP sources. We assume that 4.0 FTEs will be required for months 1 to 4 and that 6.0 FTEs will be required for months 5 through 22 of the 22-month implementation period to perform the activities in this category, for a total of 23,000 hours of effort. Production Support There is not a designated row on the staffing spreadsheet for production support. Based on our previous experiences in other states, we assume that the integration contractor will be retained to provide production support for six (6) months following the go-live. We have extended the staffing for each category above at a reduced level. State Employee Cost Assumptions Note that the items that follow correspond to the line items that pertain to the State Project Team members in rows 207-248 of Schedule B3 in this report. The State Project Team was built based upon the ratio of 1.3 State FTEs to 1.0 consultant FTE. The state staff to consultant ratio is 1.3 to 1.0 because at peak the Project Team size is 154. We feel that with a Project Team size requirement that is reasonable in comparison to BCA 2, the State can expect to acquire a higher ratio of staff from the Comptroller and State agencies/institutions. Project Management We assume that 2.6 FTEs will be required for the duration of the 22-month implementation period, for a total of 9,533 hours of effort. Functional Team This category includes the effort on the part of the State team members to work with the contractor functional team (see Software Configuration and Process Reengineering above) and assist in: Developing To Be business processes; Configuring the software in accordance with the defined To Be processes; and Performing configuration unit testing, and assisting in integration, system, and stress testing.
Page 115
September 30, 2008
We estimate that this activity would require approximately 123,933 hours based on the functional scope and the implementation duration. Deployment This category includes the following: Change management; and Training/agency support. We estimate that the Change Management activities would require 2.6 FTEs throughout the 22-month implementation period, for a total of 9,533 hours of effort. We estimate that the Training/Agency Support activities would require 1.3 FTEs for months 3 through 9 and 13.0 FTEs for months 10 through 22 of the 22-month implementation period, for a total of 29,683 hours of effort. Technical Team This category includes the effort on the part of the State Project Team members to work with the contractor team members on: Workflow; Report development; Interface development; Data conversion; Modifications and enhancements; System Administration / Support; and Data Warehousing. We estimate that this activity would require approximately 106,167 hours of effort based on the functional scope and the implementation duration. Deployment Costs Contractor and State This area includes the effort to deploy the ERP system from FY 2012 through FY 2015. We classified the agencies into low, medium, and high complexity groups. Next, we estimated the number of hours to deploy the ERP system at each agency based on its complexity. The hours associated with each deployment activity are shown below.
Page 116
September 30, 2008
Cost Assumptions That Are Not Hours-Based Note that the items that follow correspond to the line items in Schedule B1 whose estimates are not hours-based (see rows 1, 5, 6, 7, 17, 18, and 19 for Schedule B1). Application Software License and Software Maintenance Fee It is estimated that the software license fee for the new ERP system will be approximately $17 million. This estimate is based on an actual informal quote provided to STA by Oracle Corporation for the PeopleSoft ERP software suite. Since the PeopleSoft ERP software suite is currently utilized by the agencies that use HHSAS and ISAS as their core administrative system, as well as the Employees Retirement System, and numerous institutions of higher education, the estimate provided by Oracle is intended to cover license costs to allow the remaining agencies and institutions of higher education to have access to the new ERP system either as internal users of the new system or as reporting agencies that function as Hubs under BCA 3. It is anticipated that agencies and institutions that operate under one of the designated Hubs will require periodic access to the new ERP system in order to meet their financial accounting and statewide reporting needs. Annual software maintenance fees typically range between 17% and 20% of the original software license fees. Annual software maintenance fees of 20%, or $3,400,000 for the first year, were assumed for purposes of this analysis. Facilities and Equipment We estimate that the startup costs will total approximately $330,000 and that the costs will average approximately $55,000 per year for the 6-year implementation/deployment period, for a total of $668,910, based on our experience
Page 117
September 30, 2008
with similar statewide projects. This cost estimate was reduced considerably from the original estimate as Project leadership told us to assume that the Comptrollers Office can provide office space and office furnishings at no additional charge to the project due to the reduced size of the Project Team under BCA 3 (when compared to BCA 2). Should the Comptrollers office be unable to provide the office space and office furnishings at no additional charge to the project, we estimate that the startup costs will total approximately $1,453,695 and that the costs will average approximately $724,389 per year for the 6-year implementation/deployment period, for a total of $4,346,334. We included no facilities costs for Year 0 under BCA 3 as consulting and project team costs for pre-implementation activities are assumed to be absorbed through existing Comptroller facilities and equipment. Infrastructure (Database, Server, and Network) This estimate is intended to provide a high-level approximation of data center and infrastructure costs. It is based on STAs experience with similar statewide projects and input provided by technology experts in the Comptrollers Office. It is somewhat difficult at this stage of the study to estimate the cost for this category under BCA 3 as the technical platform for the Comptroller ASP has not been fully architected for the Statewide ERP system and decisions have not been made as to how the Hubs will be integrated into the overall solution. However, it is assumed that the platform that is currently operating the ISAS solution would be extended to accommodate the data center requirements of BCA 3. The hardware costs for BCA 2 included four IBM UNIX P6 595 servers that were fully configured with all processor slots utilized. Two of the servers were assumed to be co-located for high availability, full redundancy and disaster recovery failover. These co-location costs were also included taking into account for connectivity. The hardware and technical infrastructure total estimated cost includes the following elements: Processors Application / database server(s) processing hardware; Maintenance and server upgrades; New server operating system software and server operating system upgrades and maintenance Disk/Storage Area Network (SAN) capacity RDBMS Software Maintenance Transaction monitoring software
Data Storage and Management
Systems Management and Security software
Page 118
September 30, 2008
Middleware such as gateways LAN/WAN upgrades Telecommunications costs Hardware costs Software costs
Communications
Backup / Disaster Recovery
For BCA 3, given the fact that institutions of higher education and the five (5) Health and Human Services agencies would not be on the platform, costs were calculated under the assumption that the hardware and support costs for all State agencies and Higher Education institutions would be roughly equal (50/50 split). Of the State agencies, we attributed 1/4 of the overall costs to HHSC. In order to estimate costs for only the State agencies under BCA 3 (no higher education or HHS agencies), we multiplied the 3/8 factor times the BCA 2 costs. The 3/8 allocation was calculated as follows 3/8 (State) + 1/8 HHS Agencies + 1/2 Higher Education = Total Hardware and Support Costs. Hub Data Warehouse and Interfacing Systems Cost The Hub entities, the higher education systems as well as HHSC, were asked to estimate their individual cost to implement a data warehouse and interface transactions to a new statewide ERP system. Each entity reported the requested cost in three categories, 1) establishing the data warehouse, 2) ongoing support of the data warehouse, and 3) interfacing to the new ERP system. Ongoing Support/Operations and Upgrade Cost Assumptions Ongoing Support/Operations Management It is assumed that only State resources will fill the positions covered in this cost category. In developing estimates for this (and all of the Ongoing Support/ Operations sub-categories), we took into consideration the staffing levels of other states and STAs ERP experience. Also, the assumption was made that the best and brightest from the project implementation team would fill these Ongoing Support/ Operations positions. The estimate for this cost category includes 4.0 managementlevel FTEs. Ongoing Support/Operations Functional Support It is assumed that 17.0 FTEs will support the HR/Payroll functional area and 18.0 FTEs will support the Financial/Procurement areas. It is assumed that all of these FTEs will be State resources. Ongoing Support / Operations Technical Operations and Support This category includes all activities to support the technical environment (e.g., software operation and maintenance, the application of software patches/fixes, moving development items into the production environment). The category also
Page 119
September 30, 2008
includes resources necessary modifications/enhancements.
to
support
the
system
interfaces
and
We are assuming that 30.0 State FTEs will be required to provide ongoing technical operations and support. Ongoing Support / Operations Ongoing Training/Help Desk We are assuming that 16.0 FTEs will be assigned to support ongoing training as well as the help desk. The training team will be supplemented at times by the ongoing functional and technical support personnel. Upgrade in Year 6 Based on our prior ERP experience, we assumed that it would take 119,000 hours to perform a software upgrade of the new ERP approximately 40% of the effort being performed by contractors and 60% being performed by State personnel. These estimates are upgrade of existing functional/technical capabilities. Avoided Systems Costs / System Savings System Surveys were sent to twenty-four (24) agencies which collectively comprise more than 97% of the States operating budget. Meetings and follow-up discussions were also conducted to collect system cost information. The results of the surveys are presented in the sections below that describe the Selected Alternatives in detail. approximately system, with the remaining based on an
Page 120
September 30, 2008
Avoided Systems Costs for State Agencies Alternative 3

Agen cy Name & Nu mber
FYE 20 09
FYE 2010
F YE 2011
F YE 2012
FYE 2013
F YE 2014
Sta tewide Systems TDHCA--3 32 G LO- -3 05 L ottery--361 R ai l Road--4 55 TRS-- 323 O AG- -3 02 TW DB-- 580 TEA-- 701 C PA- -304 TxDO T--6 01 TCEQ-- 58 2 O OG --301 E RS- -327 TPFA --34 7 D PS- -405 TW C- -3 20 TPWD-- 802 TDJC--69 6 H HSC-- 529 D FPS--53 0 D SHS--53 7 D ARS--53 8 D ADS--53 9 THECB--781 Total Cos ts O ngoing Cos ts P roje cts Cost s Total Co sts, Inflatio n Factor = 3% O ngo ing Costs, In fla tion Fa ctor = 3% Pro ject Co sts, In fla tion Fa ctor = 3%
117 ,575 ,000 890 ,000 118 ,465 ,000 890 ,000 117 ,575 ,000 122 ,018 ,950 916 ,700 121 ,102 ,250
8 90,0 00 8 90,0 00 8 90,0 00 9 44,2 01 9 44,2 01 -
8 90,0 00 8 59,0 00 1,7 49,0 00 1,7 49,0 00 1,9 11,1 80 1,9 11,1 80 -
2,774,269 890,000 3,729,265 677,013 1,384,000 9,454,547 9,454,547 10,641,176 10,641,176 -
4,4 38,9 28 1 61,6 54 37,8 63 8 90,0 00 3,8 78,4 36 6 77,0 13 10,0 00 12,8 08 7 13,0 00 2,2 03,6 13 8 59,0 00 2 22,7 74 14,1 05,0 89 14,1 05,0 89 16,3 51,6 63 16,3 51,6 63 -
Page 121
September 30, 2008
Avoided Systems Costs for State Agencies Alternative 3 (continued)

Yr 6 A gen cy N ame & Nu mber FYE 2015 Yr 7 FYE 2016 Yr 8 F YE 2017 Yr 9 F YE 2018 Yr 10 FYE 2019 Total Years 0 - 10
Statewid e Systems TDHCA- -33 2 GLO--305 Lottery -- 361 Rai l Roa d--455 TRS--32 3 OAG--302 TW DB-- 580 TEA--701 CPA- -304 TxDOT-- 601 TCEQ--58 2 OOG -- 301 ERS- -327 TPFA- -3 47 DPS- -405 TW C--320 TPWD-- 802 TDJC- -6 96 HHSC--529 DFPS- -5 30 DSHS- -53 7 DARS- -53 8 DADS- -53 9 THECB--781 Total Cos ts Ongoing Costs Projec ts Cost s Total Costs, Inflation Factor = 3% Ongo ing Co sts, Inflation Fa cto r = 3 % Pr oject Costs, Inflation Fa cto r = 3 %
4,50 6,0 34 41 0,0 00 16 1,6 54 3 7,8 64 71 8,1 65 49 8,1 99 5 3,4 50 1,62 1,5 00 89 0,0 00 4,03 3,5 75 67 7,0 13 1 0,0 00 71 3,1 63 1 3,3 21 72 5,0 00 1,11 0,0 00 2,20 3,6 13 85 9,0 00 22 4,7 66 19,46 6,3 17 19,24 6,3 17 22 0,0 00 23,24 3,8 01 22,98 1,1 09 26 2,6 92
8,324,712 410,000 80,000 161,654 37,865 754,073 350,599 53,450 1,621,500 890,000 4,194,918 677,013 10,000 494,379 13,853 745,000 1,110,000 465,575 2,203,613 859,000 226,857 2 3,684,062 2 3,684,062 2 9,128,408 2 9,128,408 -
8,324,712 410,000 70,000 161,654 37,866 791,777 352,999 53,450 1,621,500 890,000 4,362,716 677,013 10,000 755,114 21,844 755,000 1,110,000 482,045 2,203,613 859,000 229,054 24,179,357 23,959,357 220,000 30,629,686 30,350,996 278,689
8,324 ,71 2 410 ,00 0 80 ,00 0 161 ,65 4 37 ,86 7 831 ,36 6 505 ,39 9 53 ,45 0 1,621 ,50 0 890 ,00 0 4,537 ,22 6 677 ,01 3 10 ,00 0 713 ,16 3 14 ,98 4 765 ,00 0 1,110 ,00 0 499 ,06 0 2,203 ,61 3 859 ,00 0 231 ,36 1 24,536 ,36 8 24,166 ,36 8 370 ,00 0 32,014 ,39 5 31,531 ,62 8 482 ,76 6
8,324 ,712 410 ,000 80 ,000 161 ,654 37 ,867 831 ,366 505 ,399 53 ,450 1,621 ,500 890 ,000 4,537 ,226 677 ,013 10 ,000 713 ,163 14 ,984 765 ,000 1,110 ,000 499 ,060 2,203 ,613 859 ,000 231 ,361 24,536 ,368 24,166 ,368 370 ,000 32,974 ,827 32,477 ,577 497 ,249
162,59 3,079 2,05 0,000 31 0,000 96 9,924 22 7,192 3,92 6,748 2,21 2,597 26 7,249 8,10 7,500 8,90 0,000 29,27 3,362 4,73 9,090 6 0,000 3,38 8,982 9 1,793 4,46 8,000 5,55 0,000 1,94 5,740 13,22 1,679 7,39 7,000 1,36 6,173 261,06 6,107 142,31 1,106 118,75 5,000 299,85 8,286 177,23 4,639 122,62 3,646
Value Pocket Savings The State could potentially realize process improvements in a number of areas of the organization as a result of implementing a new statewide ERP system. Note that only process-improvement benefits that could potentially result from the new implementation are included. We have coined the term Value Pockets to refer to the most likely sources of significant value (i.e., cost savings and other benefits) to be found in each functional/process area within the scope of a possible new statewide ERP implementation.
Page 122
September 30, 2008
Dollar-quantifiable Value Pocket benefits were estimated from data collected from State personnel through interviews and a Value Pocket survey that was sent to twenty-four (24) agencies which collectively comprise more than 97% of the States operating budget. Meetings and follow-up discussions were also conducted to collect information used to estimate benefits/savings from process improvements. The Value Pocket survey requested two (2) types of data: 1. Effort-Related Data The survey captured the approximate total number of hours (and associated compensation) State employees and contractors spend on an annual basis performing certain activities that are within the scope of this BCA. STA then applied a percentage savings factor to the results to estimate the amount of time and associated compensation that could be saved/redirected as a result of implementing a new, integrated, statewide ERP system. These savings factors were derived from a variety of sources, including the experiences of other government organizations, and estimates made by us based on our analysis of the respective processes and our experience, in general, in these matters, as well as input from the States project leadership 2. Metric Data This data was not directly effort-related (e.g., dollar balances, postage costs, etc.) A summary for the survey results is presented in the tables below.
Summarized Value Pocket Survey Effort-Related Data Annual Savings before 3% Inflation Factor Applied
Total Hours All Agencies 310,246.0 28,785.0 12,930.0 12,608.5 232,969.6 1,854.0 42,333.2 5,031.0 94,690.3 88,954.1 2,061.0 15,588.0 60,063.5 33,811.1 45,517.0 11,834.0 493,515.7 1,492,792.0 Total Dollars All Agencies $ 8,173,749 $ 687,280 $ 435,393 $ 308,794 $ 9,009,439 $ 83,058 $ 1,534,566 $ 120,220 $ 2,718,633 $ 2,712,207 $ 75,871 $ 433,309 $ 1,755,607 $ 832,218 $ 1,646,531 $ 381,882 $ 12,407,495 $ 43,316,251 Estimated Savings Estimated Savings Hours Dollars 127,637.3 $ 3,380,620 8,635.5 $ 206,184 7,182.5 $ 243,236 7,467.7 $ 183,793 69,890.9 $ 2,702,832 1,297.8 $ 58,140 28,057.6 $ 1,022,296 2,540.5 $ 60,796 29,423.5 $ 836,350 35,005.7 $ 1,031,105 1,049.0 $ 38,612 8,754.1 $ 245,644 24,025.4 $ 702,243 18,924.1 $ 474,568 23,806.0 $ 871,572 3,550.2 $ 114,565 153,468.4 $ 4,168,237 550,716.1 $ 16,340,793 36.9% 37.7%
Financial & Procurement
HR / Payroll
Functional Areas Accounts Payable Accts Payable/ Accts Receivable Accts Receivable / Billing Asset Management Budget Development Cost Allocation GL & Budgetary Control Inv entory Fleet Management Procurement Project Accounting Grant Accounting Applicant Services Payroll Personnel Admin Training Time and Labor Total Overall Savings Percentage
Page 123
September 30, 2008
Summarized Value Pocket Survey Metric Data Annual Savings before 3% Inflation Factor Applied
Functional Area Value Pocket Question Totals All Agencies Annual Savings Ben efit Assumptions / Calculation
Accounts Payable
Accounts Receivable / Billing Accounts Receivable / Billing
Inventory
Approximate annual cost to mail Remittance Advices to vendors (Do not answer if your systems enables you to send RAs electronically and you only ma il RAs to a small percentage of total RA recipients) Average Accoun ts Receivable balance (Only answer this question if your agency do es not utilize a truly integrated, full-featured Accou nts Receivable syste m with modern ERP functionality that could h elp improve data accuracy, visibility, and related co mmunication, which in turn could help reduce the aggregate AR balance, thereby lowe ring the interest cost of carrying AR) Approximate dollar amount of charge-offs each year (Only answer this question if you r agency lacks a truly integrated AR system with workflow functionality found in modern ERP systems that is used to man age bad debts) Average Inventory b alance (This only applies to agencies that have inve ntory management requirements [e.g. warehouse] but d o not utilize a full-fea tured, inte grated Inventory Management system) Approximate annual cost of vehicle downtime (This only applies to agencies that have Fleet Management requirements but do not utilize a full-featured, integrated Fleet Management system) Approximate annual cost of vehicle maintena nce & repair (This only applies to agencies that have Fleet Management requirements but do not utilize a full-featured, integrated Fleet Management system) Approximate annual cost to mail Purchase Orders (Do not answer if your systems enables you to send POs electronically and you only ma il POs to a small percentage of total PO recipients) Approximate annual cost to mail Remittance Advices to employees each ye ar (Do not answer if your systems enables you to send RAs electronically and you only ma il RAs to a small percentage of total recipients) Totals
15,678
14,110
90% savings
10,766,337
80,748
30,206
3,021
10% reduction\
$ 121,309,147
909,819
Fleet
Fleet
120,227
12,023
10% annual reductions
Procurement
40,920
36,828
90% reduction
Payroll
48,378 $
33,865 1,090,412
70% reduction
It is also assumed that most of the Effort-Related annual savings presented in the table above would be realized over time through attrition, employee retirement, reassignment to approved but unfilled positions, and the like. In keeping with this assumption, it is assumed that none of the effort-based Value Pocket benefits would be realized during the first year after an agency goes live as follows: 1st year following go-live 2nd and remaining years following go-live 0% 100%
We assumed the timing of the recognition of the benefits that are not Effort-Related (i.e., calculated from Metric Data) would be the same as for the Effort-Related benefits, as depicted in the table above. The timing of the recognition of the Value Pocket benefits during the timeframe of the BCA is depicted in the table below (note that a 3% inflation factor has been applied to the values in the table below).
Page 124
September 30, 2008
Recognition of Value Pocket Benefits

($ millions)
Acquire Fin / Proc / HR / Pay Yr 0 Value Pocket Benefits by Survey Type Yr 1 Yr 2 FY 2011 Yr 3 Yr 4 Yr 5 Yr 6 FY 2015 Yr 7 FY 2016 Yr 8 Yr 9 Yr 10 FY 2019 FY 2009 FY 2010 FY 2012 FY 2013 FY 2014 FY 2017 FY 2018
Alt 3 VP Benefits -- Agencies -- Effortrelated Alt 3 VP Benefits -- Agencies -- Metric Alt 3 VP Benefits -- Agencies -- Effortrelated -- inflated Alt 3 VP Benefits -- Agencies -- Metric -inflated T otal -- inflated only
1.8 0.0 1.9 1.9
1.8 0.0 2.0 0.0 2.0
1.9 0.0 2.1 0.0 2.1
11.5 0.0 13.3 0.2 13.5
14.3 2.5 17.1 0.2 17.3
16.2 1.1 19.9 3.1 23.0
16.3 1.1 20.7 1.4 22.1
16.3 1.1 21.3 1.5 22.8
16.3 1.1 22.0 1.5 23.5
Results of Financial Analysis The schedule below presents a summary of estimated ERP Costs applied against estimated Avoided System Costs/System Savings and Value Pocket benefits/savings, developed using our Business Case Analysis Methodology.
Acquire Fin / Proc / HR / Pay Yr 0 Yr 1 Yr 2 Cost and Benefits/Savings Categories FY 2009 FY 2010 FY 2011
Yr 3
Yr 4
Yr 5
Yr 6 FY 2015
Yr 7 FY 2016
Yr 8
Yr 9
Yr 10 FY 2019
FY 2012 FY 2013 FY 2014
FY 2017 FY 2018
T otal (335.2) 299.9 (35.4)
ERP Costs (implementation & operation) Avoided System Costs N et before Process-Improvement B enefits C umulative Net before ProcessImprovement Benefits Process-Improvement Benefits -Agencies (Value Pockets) Process-Improvement Benefits -Higher Ed (Value Pockets) N et after Process-Improvement B enefits C umulative Net after ProcessImprovement Benefits PV of Net after Process-Improvement B enefits C umulative PV of Net after ProcessImprovement Benefits N PV (Yr 0 through Yr 10) @ 5% per annum N PV (Yr 0 through Yr 10) @ 8% per annum
(1.8) (1.8) (1.8) (1.8)
(44.7) 122.0
77.3 75.5 77.3
(45.4) 0.9
(44.4) 31.1 1.9 (42.5)
(37.4) 1.9
(35.5) (4.4) 2.0 (33.5)
(44.9) 10.6
(34.3) (38.7) 2.1 (32.2)
(28.6) 16.4
(12.3) (51.0) 13.5 1.2
(45.6) 23.2
(22.4) (73.3) 17.3 (5.1)
(20.8) 29.1
8.3 (65.0) 23.0 31.3
(21.3) 30.6
9.3 (55.7) 22.1 31.5
(21.9) 32.0
10.1 (45.6) 22.8 32.9
(22.7) 33.0
10.2 (35.4) 23.5 33.7
128.3 92.9
(1.8) (1.8) (1.8) 60.5
75.5 73.6 71.8
33.0 (38.5) 33.3
(0.5) (28.9) 4.3
(32.7) (26.5) (22.1)
(31.5) 1.0 (21.2)
(36.5) (3.8) (25.0)
(5.2) 22.2 (2.7)
26.2 21.3 18.6
59.1 21.2 39.8
92.9 20.7 60.5 60.5
48.1
As illustrated in the table above, the Net Present Value (NPV) for Alternative 3 is $60.5 million, assuming a discount rate of 5% per annum, or $48.1 million, assuming a discount rate of 8% per annum. Breakeven/payback occurs in Yr 8 (in the 9th year of the initiative, taking into account Year 0) of the planning timeframe. Due to the estimated ongoing savings that will be realized, the NPV for the project increases over time (see Cumulative PV of Net after Process-Improvement Benefits row in table above).
Page 125
September 30, 2008
The following are notes that support our analysis. STA believes the Avoided Systems Costs estimates may be understated given the fact that only 27 out of the 182 agencies provided dollar estimates for new investments. Forty-one (41) agencies stated on their responses to the Comptrollers November 2007 survey that they were planning implementation projects but provided no costs for those projects. Of the twenty-four (24) agencies that were surveyed for Value Pocket data, only eighteen (18) were included in our Value Pocket analysis as responses from five (5) agencies (Texas Department of Housing and Community Affairs, Governors Office, Texas Higher Education Coordinating Board, General Land Office, Texas Lottery Commission) were received after the deadline for submission and we were unable to include these responses in our analysis in order to comply with our deadline for report submission. Additionally, the Department of Assistive and Rehabilitative Services response spreadsheet was corrupted, and we were unable to obtain a corrected version prior to our deadline for inclusion in our analysis. No Value Pocket benefits for strategic sourcing were estimated and included in our analysis, and based on our experience with similar projects for other states and given our understanding of the States environment, those benefits could potentially amount to several millions of dollars per year (refer to Why Should the State Implement an ERP System? section for additional information regarding this topic). There are potentially process improvements for Higher Education under Alternative 3 associated with efficiencies in reporting that were not estimated and included in our analysis
Additional Alternative Solutions Not Considered

The maturity of public sector functionality commonly found in ERP software, combined with deficiencies in the functionality provided by existing legacy administrative systems that are reaching or near obsolescence, are driving governments to evaluate the need to make changes. However, budgetary constraints in recent years have led elected officials and government executive leadership to closely scrutinize this decision and consider possible alternatives to implementing an ERP system. The following alternatives to an ERP system implementation for the State of Texas, have been considered by our public sector clients as well as other state and local governments; however, most organizations have chosen the ERP path where there was a viable business case to support it: Custom Development Best-of-Breed Solutions Enhancement of Existing Administrative Systems Outsourced Business Processes The remainder of this report provides a summary of each alternative solution, including:
Page 126
September 30, 2008
Description of the solution; Solution pros; Solution cons; Constraints and risks associated with implementation of the solution; and Feasibility of solution. These alternative solutions are presented for discussion purposes only and are not recommended for implementation at this time. Custom Development Description of Solution The Custom Development (Custom) option will provide for the in-house development of a new fully integrated, web-based ERP application that will meet the States functional and technical system requirements. System programs would be developed using state-of-the-art programming languages, development tools, and development environment. All data would be maintained in a single, uniform, database. By adapting to an open system architecture, modern tools and design techniques would assist the State in achieving a flexible, interoperable, and modular system, which can meet the future needs of the State. Pros Assumed to meet 100% of the States functional system requirements since the State controls all development efforts. System will be designed to provide full integration across the core areas of functionality. Will be built in compliance with the States strategic technology direction. State will own the software. In-house expertise will be developed. May not require re-engineering of the States business processes Pay as you go funding approach with no annual maintenance commitments. State has total control no involvement from software or implementation vendors. Cons Will take a minimum of three to four years (possibly longer) to design, develop, properly test, and prepare a custom-developed system for deployment to the agencies. Requires extensive training of existing personnel and/or outside support assistance in the latest software development tools and methodologies. The State solely funds all initial development costs and risks, as well as future ongoing software upgrades and maintenance costs (as opposed the costs being
Page 127
September 30, 2008
funded by all clients that pay annual maintenance costs for commerciallyavailable software). Technical expertise must be developed. Highest total cost of ownership over long period of time. Potentially long period of time to complete the Project and obtain benefits/ savings. Likely staff turnover during the Project. May not develop and utilize business processes based on industry-standard best practices as are available with commercially-available ERP software. Ongoing maintenance and functionality/technology enhancements must be completed in-house. High risk associated with developing a custom system from scratch. Constraints and Risks Based on our experience with custom development solutions, we believe that the extremely high risk of project failure associated with the Custom Development option renders this option unacceptable to the State due to its size, complexity, project duration, and funding requirements. Only organizations with considerable funding can support the high cost of ownership and complexity associated with developing and maintaining custom-developed applications. Even if funding is available, an ERP system is a very poor candidate for custom development due to the functional scope, complexities, integration requirements, and numerous other risk points that can lead to failure. Feasibility of Solution Due to the numerous risks associated with a project of this magnitude and the ongoing costs associated with maintaining and enhancing the System for future use, custom development of a new fully-integrated statewide system is not considered a feasible alternative and was given no further consideration. We know of no states that are currently or have recently built custom software applications to meet the requirements of a new statewide administrative system. Best-of-Breed Solutions Description of Solution Increasingly, organizations are looking at commercially-available software solutions ability to meet specific business requirements as the primary driver in determining the best solution. The Best-of-Breed option means that the State would choose the best software product available for each business function and then build the necessary interfacing points between such systems. Specifically, the State could focus its efforts on acquiring software and integration services to address its most compelling needs at this time procurement -- and implement other best-of-breed solutions to address general ledger, asset management, and other administrative systems needs as the need arises and funding is made available.
Page 128
September 30, 2008
Pros Ability to meet a high percentage of the States business requirements in specific functional areas; potentially greater depth of functionality in these areas. Less time required to implement or upgrade the System. Typically costs considerably less, initially, than ERP software solutions Provides many of the same features commonly found in ERP software (e.g., automated workflow, ad hoc reporting tools, self-service functionality). Cons Requires the State to maintain resources skilled in multiple development toolsets and programming languages. Lacks true integration provided by an ERP solution, though some best-ofbreed vendors now provide for integration points with common ERP systems that allow for real-time integration. Higher total cost of ownership than an ERP system over time because of the cost of integration, supporting multiple development environments, and managing multiple vendor relationships. Time-consuming reconciling tasks associated with maintaining duplicate data in multiple databases. Upgrade paths and support lack coordination and integration, resulting in less flexibility. Constraints and Risks Care should be taken in planning for the acquisition of best-of-breed software to ensure a proper breaking of the integration by this we mean that there are best practices for combining best-of-breed software applications to meet an organizations administrative business needs. A common option is to acquire a stand-alone procurement system, and interface it with the legacy financial management system. Feasibility of Solution Best-of-Breed solutions are viable alternatives for meeting the States administrative business needs as long as care is taken to select a high quality solution that is supported by a stable company. These solutions are especially attractive during difficult economic times when funding is limited. The State could implement a new procurement system and interface it with USAS in order to address several major procurement process and integration issues, but such a solution will not address grant/project accounting, asset management, budget development integration, and other functional deficiencies or the nearing obsolescence of the legacy administrative systems.
Page 129
September 30, 2008
Enhancement of Existing Administrative Systems Description of Solution This alternative would provide for enhancements to the existing statewide legacy systems. Potential enhancements include: Deployment of sophisticated ad hoc reporting tools to allow end users to create many of their own reports; Development of limited employee and vendor self-service functionality; Development of SPRS for Higher Education to facilitate the retirement of HRIS; Enhancements to facilitate compliance with Section 508 of the Americans with Disabilities Act regarding accessibility; and Elimination of the use of Social Security Number (SSN) as the primary identifier in the statewide administrative systems. This option has the potential to produce an improved reporting capability, but will provide only a marginal increase in productivity due to limited opportunities to improve integration and system functionality, and the lack of use of best business practices and automated workflow capabilities. In addition, enhanced reporting does not address the broad array of granular data required by State agencies to manage their operations that is not currently captured in USAS. Pros Does not disrupt normal business operations as much as a system replacement project. Does not require the replacement of application software. Not necessary to train users on an entirely new system -- only certain software features. Leverages the skills of existing technical resources. Cons High costs to pave the cow path estimated at $121 million to complete the TINS rewrite, SPRS for Higher Education, Capital Asset System (SPA replacement), and USPS SSN changes. Fails to provide the efficiencies and process improvements that other options will provide. Considered only a stop gap option. Constraints and Risks Any potential modifications to the existing statewide systems will include high risk due to the fact that these systems have been modified numerous times in the past and the systems (other than USPS) are no longer supported by their respective software vendors. Customization of any of the administrative systems includes inherent risks.
Page 130
September 30, 2008
Feasibility of Solution This option is considered feasible only as a stop gap until other more viable options can be implemented. Outsourced Business Processes Description of Solution Under this alternative, the State would contract with an outside vendor to provide all business processes within the scope of this project, or some subset thereof. Pros Provides shorter implementation time and faster realization of projected benefits/savings. Typically makes use of vendor and employee self-service and latest technology. All transactions are handled by the outside vendor, allowing State staff to focus on agency core competencies. Expected cost savings (brief history has shown varied actual results). Reduced need to hire and retain functional and technical resources. Improved levels of customer service (brief history has shown varied actual results). Reduced initial investment and pay-as-you-go financing. Predictability of cash flow. Operating expense versus capital expense. Cons Relies on outside vendor to provide system and services requires that vendor be economically viable. Relies on contractual relationship service may be compromised if contract is deficient. Requires a good partnership with outside vendor. Major change impact to the organization. Political risk as State jobs may be eliminated (though jobs may be offered to impacted employees by vendor). Some transactions may be inappropriate for processing by non-State employees (e.g., procurement awards). Negotiations typically involve multi-year lock-in contracts, which raise concerns of vendor stability and quality of service. On multi-year contracts, vendor profits are often backend loaded into the later years of the contract, so that attractive first year pricing may be misleading.
Page 131
September 30, 2008
Offer limited flexibility these solutions work well in a standardized environment but tend to break down when an entity has unique needs. Constraints and Risks An Outsourced Business Process arrangement is only as good as the contractual agreement that supports/enforces it. Where the outsourced business processes have failed to be cost-effective or do not yield satisfactory service delivery, the organizations involved have struggled to reinitiate in-house functions without impacting services. This model typically works well in performing routine business processes that have been standardized across the organization; however, the model typically struggles in performing exception type processes in which prior institutional knowledge is a benefit. Feasibility of Solution Outsourced Business Processes can be a viable option for consideration if there is a business case to support the change, and the new model will allow State resources to focus on agency core competencies. However, governments should proceed with caution as statewide projects to date have focused on human resources and payroll functionality only, have failed to realize all cost savings as planned, and have encountered difficulties in executing non-standardized, exception-based business process at a high level of customer service.
Page 132
September 30, 2008
SECTION 6 RECOMMENDATIONS
As the final task in completing the ERP Business Case Analysis Study, STA is providing a series of recommendations for the Comptroller and the ERP Advisory Council to consider when evaluating future ERP plans for Texas State government and higher education.
Recommended Alternative Solution

STA recommends that the Comptroller implement the BCA 3: Hub Model scenario as its solution for addressing statewide ERP system needs. Under BCA 3, State agencies (with the exception of the Health and Human Services agencies) will migrate to a new Statewide ERP platform operated by the Comptrollers ASP service. The Health and Human Services agencies and the Higher Education Systems will operate as reporting Hubs and interface directly into the Statewide Data Warehouse that will be operated by the Comptroller ASP service. Under this model, specific agency/institution transactional systems would be interfaced to the Statewide ERP System for addressing major functional needs such as payment processing. The existing statewide legacy administrative systems (e.g., USAS, USPS, SPA, HRIS, SPRS, TINS) will be replaced by the Statewide ERP system that will provide all functionality identified in HB 3106.
BCA 3 Hub Model Diagram
Statewide ERP Platform

Consolidation of: USAS/USPS/HRIS/SPRS/SPA/TINS/Paysubs/Warrants + ABEST (if possible)
NOTE: Higher Ed transactional data (e.g. warrants) is submitted to the S/W ERP system at the institution level
CPA ASP
HHSC Data Warehouse
Statewide Baseline ERP
HHSC Agencies
TAMU System
Texas Tech System
Tx State System
Ind. Institutions Data Warehouses TWU MWStU SFASU TSU TSTC
All non-hub AGYs including Treasury All Modules including HR/Payroll
UT System
UH System
North Texas System
S/W ERP Baseline for Distribution

Push SW ERP Baseline to Service Bureaus Push Awarded Contracts from TPASS
All agencies & co-ops access for Term, TXMAS & Open Market contracts
Page 133
September 30, 2008
A separate Data Warehouse Hub will be established for each Higher Education System and the Health and Human Services agencies that currently utilize the HHSAS system. Each Hub will develop its own data warehouse capability and every Hub component, agency or institution will be required to provide data to the Hub Data Warehouse. Component institutions in each Higher Education System and the Health and Human Services agencies will be able to operate and maintain whatever platform and application set they choose with the only restriction being that the System Data Warehouse conforms to the statewide data standards and standard business processes required for statewide reporting. The Statewide ERP baseline code will be made available to every Hub and will be patched and maintained according to the ERP vendors recommended schedule. We recommend this solution for the following reasons: The State will achieve business process standardization based on best practices, economies of scale and efficiency gains through the implementation of a single, unified platform for almost all State agencies while still allowing for the differences in the functional requirements of the Hubs. Complies with the ERP Advisory Councils guiding principle of not throwing out what is not broken by leveraging the considerable work done to date by Higher Education and the Health and Human Services agencies in implementing their own ERP systems. Addresses HB 3106 requirements. Addresses Rider 16 regarding fleet management. Fixes much of the fragmentation associated with the States existing administrative systems environment. Total project implementation costs are considerably less than the costs of implementing BCA 2. Total costs are only $35.4 million more than the BCA 1: Status Quo option that does not address the HB 3106 requirements. BCA 3 is a proven model, as this is the model most often utilized by other states to meet their statewide administrative system needs, resulting in lower overall project risk. Eliminates proliferation of agency ERP and other administrative shadow systems, while allowing higher education to maintain its own ERP solutions that are integrated with other ERP functions such as patient care, student information, learning management, and library systems. Provides a plan that allows the State to significantly upgrade the functionality and reporting capabilities of its statewide administrative systems and retire the legacy systems (USAS, SPRS, USPS, HRIS, SPA, TINS) over a period of six (6) years.
Page 134
September 30, 2008
Provides for significantly enhanced statewide reporting for both higher education and the State agencies, which will greatly facilitate a single source of the truth and taxpayer transparency. Establishes a common language for reporting expenditures through use of commodity codes (NIGP) and focuses the use of Comptroller Object Codes on financial reporting (CAFR, GASB), thereby allowing for consistent reporting and better analysis of how the States money is spent. Provides for a statewide procurement system that will be fully-integrated with the financial accounting, asset management, and Inventory management modules, as well as the Online Ordering System currently in development by the Comptrollers Office. Eliminates the use of SSN as the primary identifier in the statewide administrative systems, thus helping to reduce identity theft opportunities. Provides for compliance with Section 508 of the Americans with Disabilities Act regarding accessibility. Provides for better tracking of the States assets, thus helping agencies and the Legislature in budget planning by identifying replacement costs and schedules. Hubs will gain the benefit of centralized reporting at the System or Enterprise level through data warehouses that will be used to gather and normalize disparate institutional data to support effective statewide reporting goals. Allows for the Hubs to address ERP consolidations through an evolutionary process as their existing systems reach the end of their useful lives.
Recommended Deployment Phasing

As described in the High-Level Implementation Deployment Plan section of this report, we recommend that the Option #2: Phased Deployment by Agency Group approach is utilized for deployment of the ERP solution across State government. Using this approach, State agencies would be logically organized into deployment groups or waves. All functional modules would be deployed for all agencies with a specific group or wave. The first deployment phase would include the development of a prototype deployment model. Upon the successful deployment of the initial agency wave, that would become the blueprint for deploying all functionality among the remaining agency deployment waves. Each deployment wave would be executed sequentially until all agencies have been deployed on the statewide ERP system.
Benefits of Continuing the PeopleSoft Relationship

Should the State acquire funding to pursue the acquisition of a new ERP system and associated implementation services, several procurement strategy decisions will be required, including a decision as to whether to acquire ERP software through a competitive bid process or seek to continue its investment already made in Oracles PeopleSoft Enterprise Financial Management, Enterprise Supplier Relationship Management, and Human Capital Management software. STA recognizes that unique benefits exist should the State continue to utilize the PeopleSoft ERP software suite as
Page 135
September 30, 2008
the baseline software for the new Statewide ERP System. In fact, STAs recommendation of BCA 3 and the associated estimated costs for BCA 3 are based on the Comptroller continuing the relationship with PeopleSoft. STA estimates that there is up to a 30% reduction in total implementation costs as a direct result of reuse value of PeopleSoft. These reuse benefits include (but are not limited to): The PeopleSoft software has already been implemented by some of the large and most complex agencies and institutions of higher education in the State of Texas. This experience provides considerable documentation and lessons learned from these implementation experiences that cannot be replaced. Additionally, this experience considerably reduces overall project risk. The Health and Human Services, University of North Texas System and University of Houston Systems use PeopleSoft to address their administrative system needs within their component organizations. Additionally, the University of Texas System has made a significant investment in PeopleSoft software as well. This should streamline the statewide interfacing and reporting effort required of these Hub organizations. The Comptrollers technical resources have considerable experience with the PeopleTools proprietary toolset to support software configuration, customization, establishing security, and ongoing administration of the system, therefore, reducing the burden of training and retaining these resources. The Comptrollers functional resources have considerable experience with the PeopleSoft product to support the set-up and configuration as well as comprehensive training documentation and experience, which will help facilitate the training effort. Some of the States requirements that were gaps have been incorporated into the statewide baseline, which will reduce the amount of time spent modifying the product for State of Texas needs. Some standard reports and queries have been created that can be leveraged for all State agencies, which will reduce the amount of time and dollars spent during the implementation. The following states have implemented or are in the process of implementing the PeopleSoft financial management and human resources/payroll applications in a statewide environment: Connecticut Delaware Georgia Indiana Montana New Mexico New York
Page 136
September 30, 2008
North Dakota Ohio Oklahoma Tennessee Vermont Additionally, the following states have implemented or are in the process of implementing the PeopleSoft human resources/payroll applications only in a statewide environment: Hawaii Kansas Massachusetts Minnesota While there is considerable value to be gained from continuing the PeopleSoft relationship, we believe that Oracle needs to improve on its relationship with the State in several areas as follows: As one of PeopleSofts first and largest public sector customers, Oracle needs to negotiate reduced rates for annual maintenance, and future increases in maintenance fees should be based on reasonable parameters (e.g., lower of 3% of the previous year's maintenance fees or the increase in the Consumer Price Index). Since the various State agencies will be deployed over a period of five (5) years under BCA 3, it is critical that the State pay for software licenses only when the agencies are to be deployed on the software per the agreed-upon deployment schedule, and that annual maintenance be paid only for those agencies that have been deployed and for modules being used. A heavily-discounted annual maintenance fee may serve the same purpose with fewer complications. PeopleSoft often packages new functionality in the form of e-applications (e.g., eSettlement, eBill Payment) that require their existing customers to pay additional license fees and annual maintenance. It is STAs position that the State is already paying annual maintenance fees to fund these development costs and that the new functionality in these e-applications should actually be covered under their existing licensing agreements with the State.
Complexities Associated with Higher Education

HB 3106 required that higher education be included in the Statewide ERP Plan. The recommended alternative (BCA 3) requires that each Higher Education System operate as a reporting and interface directly into the Statewide Data Warehouse that will be operated by the Comptroller ASP service. Institution transactional systems will be interfaced to the Statewide ERP System for addressing major business processes at the statewide level.
Page 137
September 30, 2008
BCA 2 required that institutions of higher education replace their existing administrative systems by migrating to a single Statewide ERP platform that would be operated by the Comptroller. Though not recommended in this study, care should be taken regarding any future statewide ERP plans that require higher education to move to a common ERP solution for the following reasons: The focus of state government ERP implementations is typically on Financial Management and Human Resources/Payroll functionality; institutions of higher education typically implement these modules but also Student Information, Financial Aid, Library, and Learning Management modules in order to meet the administrative business process needs of their students, faculty, and staff. Selection of Student Information, Financial Aid, Library, and Learning .Management systems is often driven by institutional size, program scope and complexity. At times, a "best-of-breed" approach may be appropriate with functional integration of ERP modules being the requisite requirement. The vendor community for higher education and state government software are not the same. The leading software providers for statewide ERP projects are CGI, Oracle (PeopleSoft), and SAP. The leading software providers for higher education are Oracle (PeopleSoft) and SunGard (Banner). Requiring both types of organizations to utilize the same solution will most likely result in some functional needs not being addressed. While a one size fits all approach (with limited exceptions e.g., transportation departments) is feasible for State agencies participating in a statewide ERP project, such an approach will not work for higher education without providing for considerable unique configuration for health-related components and large flagship academic institutions. Additional complications arise because most institutions have student and other academic systems that share tables with their existing ERP systems (e.g., student billing and receivables maintained in current financial management systems are required to interact with student information and financial aid systems). These additional complexities would add considerable costs and risks to the statewide ERP Project. As documented in Systems section of expended to date by systems to address Student Information, needs. the High-Level Assessment of Existing Administrative this report, considerable effort and funding has been the States institutions of higher education to move to ERP their Financial Management, Human Resources/Payroll, Financial Aid, and other administrative business process
Research provided by the National Association of State Auditors, Comptrollers, and Treasurers (NASACT) validated that only the State of North Dakota utilizes a model whereby state government and higher education operate under the same ERP system. Following are recommendations provided by the Information Technology Council for Higher Education: 1. Higher Education maintains and supports a critical reporting role to the State and intends to remain proactive in accommodating the data reporting frameworks the State requires. Higher Education believes that effective data/reporting require consolidation around common data definitions for the data to maximize its
Page 138
September 30, 2008
value to the State. In this regard, higher education is particularly supportive of efforts to utilize modern Business Intelligence technologies to gather and normalize disparate institutional data to support effective statewide data reporting goals. 2. Higher Education supports BCA 3 of the ERP Business Case Study and intends to encourage and target ERP consolidations and efficiencies within each System. 3. At the same time, Higher Education realizes that ERP consolidations within Systems will be an evolutionary process as current ERP lifecycles reach their end. At that point, current ERP solutions would need to be researched. This approach conserves resources and money until the need arises and is not wasteful with current State resources. As systems continue to consolidate their ERP efforts, it will evolve in a way that will embrace ERP vendor solutions driven by both common and differential needs by each institution and System. It is imperative that Higher Education proceed down a road consistent with modern ERP software and their future direction.
Breaking the Integration

While STA supports the concept of full integration to the maximum extent possible, there are instances in which the need to break the integration arises as the State may best meet a specific business need through the use of a best-of-breed software product. A best-of-breed approach means that the State would choose the best software product available for a specific business function and then build the necessary interfacing points between that system and the statewide ERP system. STA suggests that the State may want to research alternative best-of-breed solutions for the following functional areas prior to committing to the PeopleSoft ERP product line for all functionality identified under HB 3106 and Rider 16: Fleet Management a specific business need that is typically addressed through the acquisition of a best-of-breed solution that is then interfaced with the statewide ERP system. Best-of-breed fleet management software is typically more robust and feature-rich than the solutions offered by the major ERP vendors; they are also more reasonably-priced. STA anticipates that a best-ofbreed solution will be required to meet the requirements of Rider 16 to provide a State fleet data management system for agencies to report fleet operating expenses and uses. Time and Labor There have been considerable issues with state and local government implementations of PeopleSofts Time and Labor software in recent years. Best-of-breed time reporting software may be more flexible than the solutions offered by the major ERP vendors; they may also be more reasonablypriced. The Comptroller needs to ensure that the PeopleSoft Time and Labor module will meet all time reporting requirements prior to committing to its use as the statewide ERP solution for state government time reporting. Budget Development At this time, most state and local governments utilize one of the following solutions for developing their enterprise budgets: Custom-developed software;
Page 139
September 30, 2008
Personal computer spreadsheets; Best-of-breed budget development software; or Budget development module within ERP software.
We have assisted numerous state and local governments with the selection of ERP software over the past eleven (11) years; yet none of our clients utilize the budget development module within their ERP software to build their budget requests. In fact, most of our clients have chosen not to purchase the budget development module after a thorough evaluation of the softwares capabilities. ERP systems were originally developed for the commercial sector, and started to evolve toward public sector use in recent years only after commercial markets reached saturation. Since budget development in the commercial and public sectors differ greatly, ERP software vendors have failed thus far to truly gain a thorough understanding of how government entities build their budgets. That said, the latest generation of budget development products offered by the major ERP vendors holds considerable promise for meeting state government budget development needs. It should be noted that there are exceptions to the general rule that ERP software cannot meet a public sector organizations budget development needs. As an example, a few years ago AMS acquired the Brass budget development software, which had been successfully implemented for numerous state and local governments as a stand-alone budget development system. AMS (now CGI) has since redesigned the software as a component of its Advantage 3 ERP solution. As with Time and Labor, the Comptroller needs to ensure that the PeopleSoft Budget Development module(s) will meet specific appropriation, operating, capital, and other budget development requirements prior to committing to its use as the statewide ERP solution for state government budget development.
Page 140
September 30, 2008
SECTION 7 FUNDING PLAN

Background and Purpose
Project funding requirements are often one of the first challenges encountered by states or other organizations considering implementation of an ERP system. Securing a viable funding source sufficient to meet the needs of the project typically requires significant forethought, coordination, and creativity on the part of the sponsoring organization. Although the costs associated with implementing ERP will be significant, this business case reveals that there is a compelling business case for the State to proceed with implementation of a new statewide ERP system. The purpose of this funding plan section is to provide information that may be helpful to decision-makers for the State of Texas as they consider the best approach for funding a new statewide ERP system. The remainder of this section of the report is organized as follows: Approach Used to Develop the Funding Plan; GASB Considerations; Federal Funding Considerations; Funding Options Considered; How Other States Fund ERP Projects; Recommended Funding Model; Cost Allocation Methodology; Business Case Analysis Recap; and Estimated Method of Finance.
Approach Used to Develop the Funding Plan

STA has taken a methodical approach to the development of the funding plan to support the recommended solution. We began by evaluating potentially viable funding sources and reviewing the funding approaches utilized by other states to fund their ERP systems. We then conducted focus meetings with the Comptrollers Fiscal Management leadership and reviewed federal regulations and authoritative guidance relating to statewide ERP systems. Additionally, GASB statements were reviewed for relevance.
GASB Considerations
GASB Statement 34, issued in June 1999, was a far-reaching pronouncement that required state and local governments to take a government-wide approach to financial reporting that requires accounting for all capital assets, including intangible assets.
Page 141
September 30, 2008
GASB Statement 51, issued in July 2007, provides further guidance on what should be considered an intangible asset. It also includes specific guidance on the proper accounting treatment for internally generated computer software, such as an ERP system to which more than a minimal incremental effort is applied to make it ready to use in the governments operations. GASB 51 also identifies three stages of activities involved in creating and installing software, and whether each stage should be expensed as incurred or capitalized and amortized over its estimated useful life. Basically it requires that costs incurred for the first stage, the preliminary project stage, and costs incurred for the third stage, the postimplementation/operation stage, be expensed as incurred. Costs incurred for the second stage, the application development stage in which design, configuration, interfacing, coding, installing the software and hardware and testing occur, should be capitalized and amortized over the estimated useful life of the software. These GASB statements provide guidance to state and local governments regarding the proper accounting and financial reporting for computer software, such as ERP systems, effective for fiscal years beginning after June 15, 2009. While the GASB statements themselves do not directly affect state funding models, the implications for federal financial participation do impact state funding model considerations.
Federal Funding Considerations

Under Office of Management and Budget (OMB) Circular A-87, statewide ERP system costs are allowable general government costs for a state and they may be included in the Statewide Cost Allocation Plan (SWCAP) either as a Section I allocated cost if paid by a central authority or as a Section II billed central service if the costs are allocated to individual agencies for payment. One manner in which federal financial participation is secured for statewide ERP costs paid by a central authority is to include these costs along with other allowable costs of general government as Section I costs under the SWCAP. The costs are allocated to individual state agencies for inclusion, along with internal agency costs, in the determination of agency indirect cost rates. Allocated ERP costs handled in this manner contribute to increasing the indirect cost rates and can result in higher reimbursements from some federal grant programs for overhead costs of the State and agency. However, the large federal entitlement programs typically do not allow agencies to recover indirect rates and many other capped federal programs limit the percentage of indirect or administrative costs that they will provide reimbursement for. Therefore, the allocation of ERP costs as a Section I SWCAP expense is a relatively inefficient vehicle for obtaining federal financial participation in the initiative. As a result, states typically experience greater federal financial participation in statewide ERP projects that are treated as a billed central service activity under Section II of the SWCAP. Because of the greater level of federal financial participation, states must also comply with much more restrictive federal requirements, including advance federal review and approval of the methodologies used to allocate the ERP costs to the benefiting agencies and programs. The cognizant federal entity for the review and approval of the SWCAP is the Division of Cost Allocation (DCA) of the United States Department of Health and Human Services
Page 142
September 30, 2008
(DHHS). On September 13, 2007, DCA issued a letter of guidance to states with two attachments. Attachment 1 related to State Data Center Consolidations and Outsourcings, while Attachment 2 provided Guidance for Software Products, specifically addressing new ERP systems and Human Resources Management Systems. Attachment 2 specifically referenced GASB Statement 51 and put the states on notice that the general principles contained in that statement should be complied with for charging federal programs. Attachment 2 stated that ERP projects should be amortized over their estimated useful lives. Federal programs only benefit and should only be charged for amortization of the capitalized costs once the software programs are implemented and in use by Federal programs. The states were also put on notice that States that have initiated or are planning software projects that will be allocated or billed to Federal programs, whether as a direct or an indirect cost, should submit their planned accounting and billing or allocation methodology to their cognizant DCA Regional Office for review. The federal government is using GASB 51 as the basis for changing how they reimburse states for ERP system costs which must be capitalized. Although federal financial participation for ERP system costs incurred during the preliminary project stage and the post-implementation stage will continue to be consistent with past practices, costs which should be capitalized must now be amortized over the estimated useful life of the system. States are faced with the option of either (a) appropriating the full amount for the one-time implementation costs from State funding and waiting to recover the federal financial participation over a number of years or (b) utilizing some form of debt financing to defer much of these costs over time to better match debt service payments with the anticipated receipt of the amortized federal financial participation. Interest cost incurred by a state for debt financing remains unallowable for federal financial participation under OMB Circular A-87. Federal regulations require costs to be allocated equitably among benefiting agencies. In the event that varying benefits can be documented, then multiple cost pools may be established to allocate the cost pools based on different factors that result in a more equitable distribution of costs. However, it is important to note that the federal government will not allow the federal financial participation for an agency to exceed its fair share of allocated costs. In the event an agency is able to contribute more than its fair share of allocated costs, then the amount above the allocated fair share amount would need to be paid entirely from State or other non-federal funding sources.
Funding Options Considered

There are two primary considerations for ERP system funding models: 1. Should current appropriations, debt financing, or some combination of the two be used to pay ERP implementation costs? 2. Should a central authority pay the ERP costs, should ERP costs be allocated to individual agencies, or some combination of the two? In addition, states may identify alternative revenue gains resulting from the implementation of the system that may be used to provide some funding for the ERP system. In general, debt financing options should only be used for ERP costs that may be capitalized in accordance with GASB Statement 51. All other funding options may be
Page 143
September 30, 2008
considered for both on-going operational costs in and one-time implementation costs. Funding options considered include: 1. Appropriation to a Central Authority This funding option would likely require the greatest amount of State funding because it implies that the project will be treated as a Section 1 allocated indirect cost for purposes of the SWCAP, which is the more inefficient vehicle for obtaining federal financial participation. Although many states simply appropriate general revenue funding for ERP system costs, under this approach Texas could also consider directly appropriating a proportionate share from general revenuededicated accounts and special revenue funds in those instances where projected fund balances could support the use of these funds. Presumably, the Texas Comptroller of Public Accounts would serve as the Central Authority for the State. 2. Appropriations to Individual Agencies This option should result in the highest level of federal financial participation by appropriating each agencys share of the ERP costs directly to that agency, and allowing each agency to utilize its normal method of finance for paying these costs. However, because of DCAs Attachment 2 guidance for ERP systems, agencies would need to capitalize most of the implementation costs of the ERP system and would only be able to draw the federal financial participation for their share of the amortized costs over the estimated useful life of the ERP system rather than as they pay their monthly bills. This option implies that the project will be treated as a Section II billed central service for purposes of the SWCAP. It also has the disadvantage of requiring agencies to take a double hit by paying a fair share of ERP system costs while continuing to pay for supporting legacy systems prior to going live. 3. Appropriations to Individual Agencies if Live and to a Central Authority if not Live This option utilizes aspects of option 2 by appropriating directly to agencies that have gone live along with the appropriation to a central authority concept from option 1 for agencies that have not yet gone live on the new ERP system. However, because of DCAs Attachment 2 guidance for ERP systems, agencies would still need to capitalize most of the implementation costs of the ERP system and would only be able to draw the federal financial participation for their share of the amortized costs over the estimated useful life of the ERP system. This option implies that the project would be treated as a Section II billed central service for purposes of the SWCAP. This option has a distinct perception advantage over option 2 because agencies would not be required to directly pay a fair share of ERP system costs as well as paying the cost to support legacy systems prior to going live on the new ERP system. 4. Debt Financing Options There are at least three debt financing options which are similar to options 1 through 3 described above except that debt proceeds would be used in lieu of regular State appropriations. The greatest advantage of using debt financing is that it would defer much of the up-front ERP cost for the State while better matching debt service payments to benefit realization. It would also be more consistent with DCAs guidance for federal financial participation over the estimated useful life of the ERP system. The greatest disadvantage is that the interest costs incurred for the debt financing would be unallowable for federal financial participation. It is also likely that only the ERP costs that should
Page 144
September 30, 2008
be capitalized per GASB Statement 51 would be eligible for debt financing. Noncapitalized ERP costs would likely need to be paid from current appropriations. 5. Option Combining Appropriations and Debt Financing The State also has the option of taking an approach which combines appropriations and debt financing to cover the cost of ERP systems. This option would provide the advantage of using debt financing to defer much of the up-front ERP related payments by the State while better matching debt service payments to benefit realization. This option would also be more consistent with DCAs guidance for federal financial participation over the estimated useful life of the ERP system. Again, the greatest disadvantage of debt financing is that interest costs incurred for the debt financing would still be unallowable for federal financial participation. It is also likely that only the ERP costs that should be capitalized per GASB Statement 51 would be eligible for debt financing. Non-capitalized ERP costs would likely need to be paid from current appropriations. The ERP system costs could be either a Section I allocated indirect cost or Section II billed central service for purposes of the SWCAP, depending on whether or not the State appropriated funding to individual agencies for payment. 6. Vendor Financing Vendor financing would require the successful ERP vendor to finance the purchase of the software over an agreed-upon number of years, similar to debt financing. The advantage of vendor financing is that it would help to level the amount to be paid. The most significant downsides of this option are that the cost of financing would most likely be higher than other State financing options and that the interest costs incurred for the debt financing would be unallowable for federal financial participation. This approach implies that this would be a Section II billed central service for SWCAP purposes. The States Data Center Services project utilized this approach, but this approach is not typically used for statewide ERP projects.
How Other States Fund ERP Projects

States have taken a variety of approaches to funding ERP systems. Some states use current appropriations while others use debt financing for one-time ERP costs. Additionally, some states appropriate funding to a central agency to pay ERP system costs, while others allocate the ERP costs and appropriate funding at the individual agency level. Based on the information STA has obtained, it appears that a majority of states have opted to use current appropriations as the primary means of financing ERP systems. Bonds or other debt instruments were used by a couple of states as the primary means of financing one-time implementation costs. Several states used a combination of current appropriations and debt financing to finance their ERP systems. The table below reflects the primary funding approach taken by a sample of states for their ERP projects.
Page 145
September 30, 2008
State
Current State Appropriations
Bonds or Other Debt Financing
Combination of Current Appropriations & Debt Financing
Delaware Georgia Indiana Iowa Kansas * Kentucky Louisiana Maine Missouri Montana New York * Ohio Pennsylvania South Carolina Tennessee Washington
*

These states are currently in the Pre-Implementation phase of their respective ERP projects.
Following are examples that provide additional insight into the various approaches states have taken in funding their ERP projects: Louisiana funding model provides for a central appropriation of State general funds to cover the implementation and on-going costs of the ERP system. Montana the State issued bonds to amortize the one-time implementation costs of the ERP system over a ten-year period. Ohio appropriated general revenue funding along with debt financing (certificate of participation) to fund the costs of the ERP project.
Page 146
September 30, 2008
South Carolina funding model provided that 25% of the implementation costs would be funded centrally with 75% to be funded by the agencies. South Carolina allowed agencies to establish restricted accounts to reserve funds for their share of the ERP project implementation costs. These accounts had full carry-forward authority and were protected from mid-year budget reductions. South Carolina also created a master lease option to allow agencies to amortize their one-time costs over a five year period by dedicating a portion of normal process savings to service the debt.
Recommended Funding Model

STA recommends that the State consider a funding model as described in option 5 above that utilizes debt financing to spread the allowable one-time ERP costs over a period of years while using current appropriations to pay ERP costs that are not eligible for debt financing. STA also recommends that the funding model utilize a central appropriation for the annual costs attributable to each participating agency that has not yet gone live while appropriating funds directly to agencies as they go live. As previously mentioned, the advantage of debt financing is that it would enable the State to defer much of the upfront ERP costs while better matching debt service payments to benefit realization. This approach is also more consistent with DCAs guidance requiring that federal financial participation be amortized over the estimated useful life of the ERP system. Although the associated interest costs would still not be allowable for federal financial participation, this approach combined with appropriating funding to each agency for their fair share of the debt service costs plus their fair share of ongoing ERP system operating costs would maximize the amount of federal financial participation in addition to allowing the State to utilize dedicated accounts and special State funds to the extent possible at each agency. It is likely that only the ERP costs that should be capitalized per GASB Statement 51 would be eligible for debt financing. Therefore, non-capitalized ERP costs would need to be paid from current year appropriations. The phased implementation schedule will result in some agencies going live on the ERP system years before other agencies. While most of the one-time implementation costs produce benefit for all agencies that will be utilizing the ERP system, the effect of allocating these costs to agencies before they go live results in these agencies taking a double hit by having to pay for their fair share of the ERP system while continuing to pay the costs to support their legacy systems. Conversely, simply allocating each years ERP costs among the agencies which have already gone live would probably not be acceptable to the Federal government. Therefore, for purposes of developing a fair and equitable ERP cost allocation methodology, it is recommended that the State utilize a cost allocation methodology that attributes a fair share of the annual costs to each participating agency regardless of whether they have gone live or not. However, STA recommends that the State appropriate the funding for the ERP costs for agencies that have not gone live to a central authority to avoid the appearance of double payment for ERP and legacy system costs.
Page 147
September 30, 2008
It also appears that the State could benefit from considering several of the innovative approaches that South Carolina implemented to help fund their ERP system costs while minimizing the impact on State agencies. South Carolina agencies were allowed to establish restricted accounts to set aside funds for their share of the ERP project implementation costs. These accounts had full carry-forward authority and were protected from mid-year budget reductions. South Carolina also created a Master Lease option to allow agencies to amortize their one-time costs over a five year period by dedicating a portion of normal process savings to service the debt. The Texas Public Finance Authority should be consulted regarding the feasibility of creating a special Master Lease program as the debt service vehicle for agencies to use to amortize ERP implementation costs that have been capitalized. An example of how the funding model might work would be to appropriate the ERP project funds and ERP operational funds to the Comptroller. This would include funding to cover costs incurred for the first stage, the preliminary project stage, costs incurred for the second stage, the application development stage in which design, configuration, interfacing, coding, installing the software and hardware and testing occur, and costs incurred for the third stage, the post-implementation/operation stage. The Comptroller would pay the expenses related to the ERP system implementation project and ongoing operational costs of the ERP system. In each biennial budget request, the Comptroller would seek enough funds to cover all its ERP related costs, including those costs required to be capitalized and as well as to fund ongoing operations. The budget request would also include an amount sufficient to cover the amount of capitalized costs to be amortized over the budget period. The Comptroller would develop the ERP cost allocation plan to distribute costs to agencies. When an agency is deployed on the new ERP system, it would be allocated enough of the Comptrollers ERP appropriations to cover their share of the ERP costs. This could be similar to the way across-the-board salary increase appropriations and benefit appropriations are distributed today. The Comptroller would, in turn, bill each agency for its share of the cost. The amount allocated/billed to each agency would include the current period cost of operations as well as its share of any capitalized costs. To the extent the amount paid by an agency reflects current operational costs, those funds would be used by the Comptroller to pay current costs. To the extent the amounts paid by an agency represent its share of capitalized ERP expenditures, the Comptroller would deposit the amounts received back to the State treasury to defray the costs paid earlier. This last amount should create a gain to the State treasury, which offsets the amounts the Comptroller was budgeted in that period to cover capitalized costs.
Cost Allocation Methodology

A cost allocation methodology should be developed to allocate costs that are directly attributable to an agency to that specific agency, to allocate costs which are attributable to a subset of agencies to that subset of agencies, and to allocate costs which are not directly attributable to a specific agency or subset of agencies among all participating agencies on a fair and equitable basis. FY 2007 Expenditure data and FY 2007 Average Fulltime Equivalent employee information were utilized in developing an equitable basis for allocating a fair share of
Page 148
September 30, 2008
costs attributable to each agency, including both agency specific costs and costs which cannot be attributable to a single agency. After reviewing a number of potential methods for allocating ERP costs among all agencies, or pools of agencies where applicable, STA recommends that the State utilize a methodology weighted 50% for total agency expenditures and 50% for total agency FTEs. This methodology tends to level the playing field for agencies such as the Texas Education Agency which have exceptionally large expenditure to FTE ratios and agencies such as the Texas Department of Criminal Justice which have exceptionally large FTE to expenditure ratios. The table below compares the results of using expenditures, FTEs, and 50% weighting for each as the basis for allocating ERP costs for some of the larger State agencies.
Agency Name Net 2007 Expenditures (Funds in Treasury)
3,004,219,604.65 17,501,762,122.56 19,057,959,843.55 8,380,436,714.55 5,364,471,945.62 2,714,908,090.72 1,137,469,467.82 3,537,739,718.09 903,545,334.69 3,654,512,268.11 2,344,147,376.37 2,618,213,005.72 525,095,754.22 584,339,056.43 264,186,102.11
2007 Ave FTEs
Percent of Net Expenditures

3.9402% 22.9544% 24.9954% 10.9913% 7.0358% 3.5607% 1.4918% 4.6399% 1.1850% 4.7931% 3.0745% 3.4339% 0.6887% 0.7664% 0.3465%
Percent of Ave FTEs

26.0905% 6.6046% 0.6440% 10.2288% 9.8485% 8.1092% 6.3724% 2.7899% 5.4786% 0.3090% 1.9847% 0.1993% 2.1487% 1.9803% 2.0091%
Weighted Percent of Expenditures & Ave FTEs

15.0154% 14.7795% 12.8197% 10.6101% 8.4421% 5.8349% 3.9321% 3.7149% 3.3318% 2.5510% 2.5296% 1.8166% 1.4187% 1.3734% 1.1778%
Texas Department of Criminal Justice Health and Human Services Commission Texas Education Agency Texas Department of Transportation Department of Aging and Disability Services Department of State Health Services Department of Family and Protective Services Attorney General Texas Department of Public Safety Teacher Retirement System of Texas Texas Workforce Commission Employees Retirement System of Texas Department of Assistive and Rehabilitative Services Texas Commission on Environmental Quality Parks and Wildlife Department
37,617.94 9,522.63 928.51 14,748.17 14,199.75 11,691.98 9,187.87 4,022.57 7,899.16 445.49 2,861.60 287.39 3,097.98 2,855.29 2,896.73
Page 149
September 30, 2008
Agency Name
Net 2007 Expenditures (Funds in Treasury)

233,483,763.99 813,274,170.97 588,755,583.68 427,715,472.39 77,035,987.09 184,810,025.98 170,789,996.12 183,639,896.63 11,608,780.80 1,961,758,748.55 76,245,878,831.41
2007 Ave FTEs
Percent of Net Expenditures

0.3062% 1.0666% 0.7722% 0.5610% 0.1010% 0.2424% 0.2240% 0.2409% 0.0152% 2.5729% 100.0000%
Percent of Ave FTEs

1.8974% 0.4034% 0.2135% 0.1863% 0.4700% 0.1956% 0.1884% 0.0099% 0.1759% 11.4622% 100.0000%
Weighted Percent of Expenditures & Ave FTEs

1.1018% 0.7350% 0.4928% 0.3736% 0.2855% 0.2190% 0.2062% 0.1254% 0.0956% 7.0176% 100.0000%
Comptroller of Public Accounts General Land Office Texas Lottery Commission Texas Higher Education Coordinating Board Railroad Commission of Texas Texas Department of Housing and Community Affairs Texas Water Development Board Texas Public Finance Authority GovernorExecutive Total, Other Included Agencies Grand Total, All Included Agencies
2,735.67 581.57 307.84 268.56 677.59 281.96 271.71 14.21 253.63 16,526.47 144,182.27
Business Case Analysis Recap

The schedule that follows was taken from the Business Case Analysis section of this report. It provides the summary costs associated with the recommended BCA 3 solution. It should be noted that the $335.2 million cost for BCA 3 (highlighted in yellow) was provided for Business Case Analysis comparative purposes only and reflects the costs of the various alternatives over a standard 11-year horizon commonly used for such analyses (FY 2009 FY 2019). This analysis includes both the costs incurred during the 6-year implementation period as well 4 subsequent years of operational costs.
Page 150
September 30, 2008
Page 151
September 30, 2008
The Funding Plan should address the costs incurred for pre-implementation services plus the implementation project and ongoing support costs incurred during the 6-year project timeframe ($248,458,189 highlighted in yellow below) because these are the costs that would be considered new funding until the Comptroller is able to retire the existing statewide administrative systems. In contrast, years 7 10 reflect ongoing support costs for the new ERP system. The schedule that follows reflects the costs to be included in the Funding Plan.
Estimated Method of Finance

To fully understand the budgetary impact of funding the ERP system, a method of finance projection model should be developed to estimate the type of funding that will be needed to fund the ERP system costs. This model should take into account factors that are not available at this time such as the estimated useful life of the ERP system, the estimated amount of debt financing, if any, and the amortization period for the debt service payments.
Page 152
September 30, 2008
For purposes of the table below, FY 2009 Appropriations were utilized in modeling method of finance percentages that were applied to estimated ERP costs for Year 0 and Years 1-6. It is important to note that the federal funds portion of the MOF estimate in the table below only represents a fair share of ERP costs attributable to the federal government in each year, not the amount of reimbursement expected to be received from the federal government during that fiscal year. As previously discussed, DCA intends to limit their federal financial participation in the capitalized value of the ERP system in each year to the amortized value based on the estimated useful life of the system. The following table reflects the estimated method of finance which will be required for total ERP related system costs incurred in Years 0 6. ERP costs incurred in Years 7 10 will reflect the ongoing operational costs for the ERP system and are not presented here since they do not reflect new funding requirements of the State.
Method of Finance Year 0 - 2009 Year 1 - 2010 Year 2 - 2011 Year 3 - 2012 Year 4 - 2013 Year 5 - 2014 Year 6 - 2015 6-Year Total General Revenue 1,784,986 21,595,522 21,887,894 18,093,495 26,179,685 13,444,853 21,294,970 124,281,405 GR Dedicated 2,275,597 2,696,461 3,328,996 2,812,630 1,523,747 3,630,855 16,268,285 Federal Funds 14,610,987 13,175,832 9,879,311 8,458,240 10,045,772 11,836,122 68,006,264 Other Funds 20,054 6,256,625 7,602,088 6,110,882 7,472,481 3,596,365 8,843,741 39,902,235 Total All Funds 1,805,040 44,738,731 45,362,274 37,412,684 44,923,036 28,610,736 45,605,688 248,458,189
Page 153
September 30, 2008
SECTION 8 HIGH-LEVEL IMPLEMENTATION PLAN FOR RECOMMENDED ALTERNATIVE

Background and Purpose of High-Level Implementation Plan
The purpose of this section of the report is to provide an understanding of the available deployment strategies, including the advantages and disadvantages of each strategy, major decision drivers associated impacting the selection of a deployment strategy to support a new statewide ERP system, and STAs recommended high-level approach and timeline for deployment for the new statewide ERP system. Statewide ERP implementation projects can be a complex and challenging undertaking due to the number of agencies, users and systems that are impacted. Our experience with large statewide ERP implementations has shown us that there is no single, preferred deployment approach and the unique requirements and decision factors for the ERP project will dictate which implementation approach is the most suitable to manage the complexity and the overall project risk.
Implementation Deployment Options

There are two primary high-level methods by which a statewide ERP system can be deployed throughout the State: Single Deployment or Big Bang where there is one deployment date for all agencies and institutions of higher education whereby all modules within scope are deployed on that designated date. This is referred to as the Big Bang approach due to the one implementation event that covers all functions and all agencies and institutions. Phased Deployment where the entire deployment effort is divided into logical phases or groupings, and the project team is focused on completing the deployment phases in a concurrent or sequential fashion. Each organizations go live date is based upon whatever implementation phase they are assigned by the project team. Deployments can be phased along two dimensions: Functionality or application software modules where the project phases are divided based upon the functional modules to be implemented across all agencies (e.g., Phase 1 implementation of General Ledger, Accounts Payable, Procurement, and Asset Management modules, Phase 2 implementation of Human Resources, Payroll, and Time Reporting modules). Agencies or organizational boundaries -- where the total agency or organization population is divided into deployment groups and all of the functional modules are implemented for each organizational phase (e.g., Phase 1 deployment of all functional modules for all Group 1 agencies). The agency groupings can be decided based upon any number of factors, including:
Page 154
September 30, 2008

Geographic or location boundaries (e.g., all agencies in Austin are in Group 1); Common purpose (e.g., all Group 1); health and human services agencies are
Critical system needs where agencies that have immediate needs for certain functionality are grouped together in earlier phases (e.g., all agencies currently on USAS are in Group 1); and Resource constraints where agencies that have significant numbers of end users to be trained or other special needs that require project resources are spread out through the phases to ensure that every phase has sufficient project team resources (largest agencies are spread across the various deployment phases).
Following is a description of each deployment option described above, including the benefits and risks associated with each option. Option #1: Single Deployment (Big Bang) Approach Using this strategy, all State agencies would be deployed on the following modules of the statewide ERP system simultaneously and every agency would go live with the statewide ERP system at the same time: General Ledger Accounts Payable Accounts Receivable Budget Development Billing Projects Grants Procurement Inventory Management Asset Management Payroll Human Resources Fleet Management Benefits Supports a true enterprise focus as all agencies go live on all ERP functionality simultaneously; Provides for a reduced implementation timeframe when compared to other deployment strategies;
Page 155
September 30, 2008
The State will begin realizing the benefits and efficiencies identified with the business case earlier than with a phased option and has the greatest potential to maximize realization of all benefits and efficiencies; Potentially least costly strategy as all system components are implemented in shorter time period; Allows for a more efficient approach for data migration from legacy systems and supports the early retirement of legacy systems which reduces ongoing operating costs; Eliminates the need for temporary interfaces to the Statewide systems (e.g. USAS, USPS, SPRS, etc.) that are required when deployment phasing is utilized; Most likely to keep agencies with compelling functional needs and/or pending software obsolescence from moving forward with new shadow systems independent of the ERP project due to simultaneous deployment of functionality at all State agencies; Less likely to have to implement a new ERP software release before ERP has been deployed at all State agencies due to shorter time period for software implementation and deployment (new software releases are typically issued by the major ERP software vendors every three to five years); and Risk of project team member turnover is reduced substantially due to compressed deployment time period for all State agencies. Risks Greatest change management impact to State as all functionality goes live simultaneously (decreased time period to absorb change); Major training impact as high volume of end users must be provided with just in time training within a narrow window of time; No benefits and/or savings are realized until all functionality has been deployed; Will require largest project team size in terms of FTEs; Considerable testing required at each test stage (e.g., unit, integration, acceptance) due to compressed timeline required to complete all system configuration, customization, data conversion, and other integration activities; User participation is required for a limited but intense period of time; Extensive data migration activities must be completed simultaneously; Higher risk of problems due to compressed timeline and large functional scope with less margin to correct / mitigate problems that arise; and Inability to take advantage of lessons learned or knowledge from previous phase(s) of deployment.
Page 156
September 30, 2008
Option #2: Approach)
Phased
Deployment
by
Agency
Groupings
(Phased
Agency
This approach is one in which all State agencies would be logically organized into deployment groups or waves. All functional modules would be deployed for all agencies within a specific group or wave. The first deployment phase would include the development of a prototype deployment model that would become the blueprint for deploying all functionality among the remaining agency deployment waves upon the successful deployment at the initial agency wave. Each deployment phase would be executed concurrently or sequentially until all agencies have been deployed on the statewide ERP system. Benefits Divides the project into manageable deployment phases which increases the likelihood of success and reduces the overall project risk; Allows early phase agencies to start receiving the benefits of ERP as they are deployed on the new system; Provides the ability to develop an implementation model or blueprint and use knowledge gained and lessons learned from the initial and early phases throughout subsequent deployment phases; Provides the ability to fund the ERP project over multiple budgetary periods; Change management impact is dispersed across longer period of time can be focused on only those agencies that are part of specific deployment phases; Fewer users to train at any point in time; Project team focus is on the initial implementation and deployment effort, and then on a single phased deployment at a time; and Risks Requires concurrent operation of legacy systems and new ERP system until all agencies have been successfully deployed on the new ERP platform; Requires a longer timeline to complete entire deployment across State government resulting in higher total deployment costs; May lead to difficulties in completing deployments for agencies scheduled for deployment late in project due to possible loss of momentum, lack of funding, and other issues that may arise due to an expanded rollout schedule; Requires the use of temporary interfaces due to deployment phasing; Complex data migration from legacy systems and ultimate elimination of legacy system usage due to deployment phasing; The expanded deployment schedule will result in a longer period to achieve the investment returns identified by the ERP business case and lengthen the overall investment payback timeframe;
Page 157
September 30, 2008
There will be inconsistencies in enterprise data and reporting during the deployment period due to the fact that some agencies will be on the new ERP system and other agencies will continue to utilize legacy systems until they are deployed; State agencies may be involved in the early stages of the project such as the system design and configuration but there may be a gap between their early participation and their actual deployment date. Changes in legislation or the agencies business environment during this interim period may cause the system configuration to have to be changed or modified at additional cost; The extended deployment time period may conflict with the selected ERP vendors software release schedule. Depending on the criticality of the release, there could possibly be a need to go through a software upgrade cycle prior to the full deployment which would further delay the overall deployment effort and increase the deployment cost and overall project risk; Some agencies may have compelling functional needs and/or pending software obsolescence that may cause them to move forward independent of the ERP project; such actions may erode executive support and will ensure that some benefits and efficiencies associated with the ERP business case will never be realized; and Major risk of project team member turnover due to lengthy deployment time period could cause problems for State agencies scheduled for the late phases of deployment. Option #3: Phased Deployment by Functional Groupings (Phased Functionality Approach) This approach involves grouping the functional modules into logical categories for deployment across all agencies. An example of this approach would be to group together all core financial modules (e.g., General Ledger, Accounts Payable, Procurement, Asset Management) into the first implementation phase and deploy these modules across all agencies simultaneously. The second phase would be the deployment of the core human resources and payroll modules across all State agencies simultaneously. The third phase would be the deployment of any remaining non-core modules (Applicant Services, Training, and Fleet Management) across all State agencies simultaneously. This type of phased approach also allows the State Project team to stage the deployment of the first phase, while building an implementation blueprint for the remaining phases. When using a Phased Functionality Approach, care must be taken to minimize the breaking of the integration within the broad functionality groupings. Benefits The benefits of the phased functionality approach generally include many, if not all of the benefits listed under Option 2. However, the phased functionality approach also includes the following specific benefits as well:
Page 158
September 30, 2008
Divides the project into manageable implementation phases and supports functional module deployments across state government which increases the likelihood of success and reduces the overall project risk; and Reduces overall impact on existing business operations due to limited functionality scope at any period of time. Risks The risks associated with the phased functionality approach generally include many, if not all of the risks listed under Option 2. However, the phased functionality approach also includes the following specific risks as well: Requires a longer implementation timeline than the phased agency approach to complete entire deployment across state government which may result in being the most costly option to implement due to the extensive time period required to implement all ERP functional modules; There is a significant risk that the initial design and configuration of the targeted module(s) may fail to take into account the requirements of other functional modules to be implemented at a later date, which can lead to fragmentation and silo thinking with focus on targeted functional modules only -- this can ultimately lead to functional needs not being met and/or the need to reconfigure certain components of the system at a later date; Considerable change management impact since state government business operations are in constant state of change across all agencies; May lead to difficulties in completing implementation of functional modules scheduled for deployment late in project due to possible loss of momentum, lack of funding, and other issues that may arise due to an expanded rollout schedule; Significant complexity for data conversion and migration from legacy systems since not all functional modules are implemented at one time; and Agencies do not start to receive the complete benefits of ERP until they go through their last implementation wave which will likely be several years from the start of the implementation project.
Driving Factors Impacting Deployment Strategy Selection

STA considers the following factors and considerations when determining the recommended ERP deployment strategy for an organization. These factors include: Value Proposition Do specific functional modules offer greater financial or service benefit than others? Mandate Is there an executive, legislative or federal mandate that requires a portion of functionality to be in production use on a specified date? Strategic Initiatives Is there specific ERP functionality required to support an ongoing or new strategic initiative or business program? Organizational Readiness How ready are the States end users and management for the amount of change associated with an enterprise project of
Page 159
September 30, 2008
this nature? What will be the impact of the change on the various agencies and user population? Risk Avoidance Are there risks that can be avoided by either implementing or not implementing certain functionality? Are there timing, sequence or dependency issues between agencies? Organizational Scope What is the organizational scope of the ERP project? Are all State agencies expected to utilize the new ERP system, including the Department of Transportation, which typically has unique financial reporting and comprehensive project management needs? Is higher education in scope? Will agencies be allowed to maintain their existing systems and build interfaces to/from the ERP in lieu of using the ERP system as the agencys administrative system of record? Organizational Size An organizations size and geographical dispersion often determines the feasibility of a big bang implementation. Typically, the larger the organization and the more geographically dispersed the organization is, the less feasible a big bang deployment is as a deployment option. Functional Scope What functionality is to be included in the ERP functional scope? Are all agencies required to utilize all functionality, or are some functional modules considered to be optional for agency use? Funding Availability The longer the period of time it takes to implement and deploy the ERP across state government, the greater the cost to implement. Deployment options that involve the phasing of functionality will cost considerably more because it will require the project team (State and consulting staff) to remain engaged for a longer period of time. Phased deployments also usually require the use of temporary interfaces and the continued, concurrent operation of the States legacy statewide administrative systems (USAS, USPS, SPRS, HRIS, SPA) and the new ERP system until the last agency or module is implemented. User Agency Needs Does the States user agencies have a history of developing their own shadow systems to meet their administrative business needs? Is this process being managed at the statewide level and if so, are any such projects underway and/or being planned for at this time? Politics Does the possibility of a change in the States executive leadership put the project at risk? If so, what is the timing associated with a potential leadership change? Track Record with Similar Projects Has the State previously taken on projects with the magnitude and complexity of the ERP project? If so, were such projects successful from the viewpoint of the project team, State leadership, and the general public? Often previous projects similar to the ERP projects that were implemented by large public sector organizations incurred significant budgetary and time overages, and failed to deliver the functionality and other benefits as intended. If such conditions exist, organizations sometimes pursue the option of completing a successful Pilot Project to obtain the sponsorship and funding necessary to complete the statewide deployment of the system.
Page 160
September 30, 2008
End User Training Regardless of the deployment method selected, executing a just-in-time training program for end users is critical to project success. The number of end users that must be trained within a given implementation window is usually a major logistical challenge for the project team. The ability of the project team to scale the training effort for large, geographically disperse end user populations will often dictate whether a Single Deployment approach can be utilized or whether a phased deployment strategy is more appropriate. Availability of Skilled and Experienced Resources The ability of the State to commit and retain the States most qualified and experienced resources on a fulltime basis is critical to the long term success of the project. If it is determined that the State may have difficulty attracting and retaining skilled resources for the project, a phased deployment strategy should be utilized. Performance and Operational Risk of Legacy Systems -- The performance, security, flexibility, stability, cost-effectiveness, and availability of the States existing administrative systems and their ongoing ability to provide baseline functionality are all factors in determining the implementation milestones and deadlines.
Small Agency Considerations

As part of the implementation planning process, it is important to take into consideration the number of small agencies, boards and commissions that will be included in the implementation scope of the ERP project and the unique issues and complexities associated with these organizations. Based on our prior experience with statewide ERP projects in other states, we have identified two issues that must be addressed as part of the overall ERP planning process: Because the business officers in small agencies typically perform multiple, and in some cases, all administrative functions, the ERP implementation has a greater impact on these people than their peers in larger agencies where the same administrative duties and responsibilities are spread among a larger employee base. The training time and effort and the amount of new information to be assimilated in order to use the new ERP functionality can be overwhelming. We recommend that the State develop specialized training for small agency business officers regardless of the deployment strategy selected. In smaller agencies, it is not uncommon for employees with basic bookkeeping skills (but no formal GAAP accounting educational background) to be promoted into roles involving major financial management responsibilities over time. Most ERP solutions are no longer transaction code driven (in which a user could enter a code for a particular accounting event and the system would assign the proper debit and credit). Additionally, GASB 34 requires a thorough knowledge of accrual and modified accrual accounting. This requirement, combined with new ERP functionality will mean that some financial staff or managers may require additional training in basic governmental accounting principles in addition to the end user ERP application training.
Page 161
September 30, 2008
Deployment Strategies of Other States

For the purposes of comparison, the table below lists the deployment strategies that were employed by fourteen (14) states for their respective statewide ERP projects. ALL means either all organizations or all modules were implemented simultaneously. Phased means that either the agencies or modules were implemented under a phased approach. The column on the far right indicates whether the State implemented the Financial modules (FIN) or Human Resources modules (HR) first or if they were implemented using a Big Bang approach (Concurrent).
Financials / Procurement Agency Module Timing Timing HR / Payroll Agency Module Timing Timing
State
HR or FIN First?
Arkansas Connecticut Georgia Indiana Louisiana Missouri Montana Nebraska New Mexico North Dakota Oklahoma Pennsylvania Tennessee Utah
All All All Phased N/A All All All All All All Phased Phased N/A
All Phased All Phased N/A All Phased Phased All All All All All N/A
All All All All All Phased All All All All Phased All All All
All Phased All Phased Phased All All All All All All Phased All All
Concurrent FIN FIN FIN N/A FIN HR HR Concurrent HR HR FIN HR N/A
Only the State of Arkansas and the State of New Mexico performed a true Big Bang approach where both Financials and HR/Payroll modules were implemented across all agencies under a single deployment date. The remainder of the entities successfully implemented the ERP system using a variety of phased and singular deployment strategies as depicted in the charts that follow.
Page 162
September 30, 2008
State of Arkansas
Financials/Procurement
2001
HR/Payroll
2002
The State of Arkansas utilized a big bang approach to implement all HR/Payroll, Financial, and Procurement functionality simultaneously across all State agencies in July 2001.
State of Connecticut
Financials (Projects, Grants, Billing, AM, Inventory) Financials (GL, AP, AR, Purch/eP)
2003
2004
HR (ESS, Labor Rel, Train) HR (Benefits, Time & Labor, Pos. Ctrl.)
The State of Connecticut utilized a phased deployment approach based on functionality phases. Utilizing this approach, the software was grouped into four functional components as follows: Core Financials and Procurement were implemented across all agencies in June 2003. These components were followed by Payroll and most Human Resource functions in September 2003. The Extended Human Resource functions were deployed in June of 2004. Lastly, Extended Financials (projects, grants, billing, asset management, and Inventory) were deployed in September 2004.
Page 163
September 30, 2008
State of Georgia
1999
2000
HR/Payroll
The State of Georgia utilized a phased deployment approach. Financials and Procurement were deployed in July 1999. HR/Payroll was deployed in October 1999.
State of Indiana
Procurement, then Financials phased by agency
1999
HR
2000
Benefits
The State of Indiana implemented HR functions in the State Personnel Department in October 1999. The Benefits Administration module was then rolled out in February 2000. In July 1999, the Department of Administration implemented Procurement, followed by Financials within the agency only. The Financial modules were then phased out to the other State agencies. The Department of Transportation was not included in the project scope and they maintain their own financial and procurement systems.
Page 164
September 30, 2008
State of Louisiana
(Financials/Procurement not in scope)
2000
HR
2001
Payroll
All HR functionality was deployed by the State of Louisiana to all State agencies in October 2000. Payroll functionality was deployed at all State agencies in March 2001. Financials and Procurement were not in the scope of the initial project; however, the State is currently in the early stages of their implementation of the Financials and Procurement modules.
State of Missouri
1999
2000
2001
HR/Payroll (in 4 phases)
The State of Missouri deployed all functionality for Financials and Procurement at all State agencies in July 1999. HR and Payroll were deployed to State agencies in four phases of agency groupings in October 2000, February 2001, April 2001 and June 2001.
Page 165
September 30, 2008
State of Montana
Asset Management Budget Development Financials & Procurement
1998
1999
HR & Payroll
The State of Montana deployed Budget Development at all agencies in August 1998. Asset Management was rolled out to all agencies in September 1998, while HR and Payroll were implemented at all State agencies in April 1999. The remaining Financial and Procurement modules were deployed at all State agencies in July 1999.
State of Nebraska
Financials Procurement
2003
Payroll
2004
The State of Nebraska implemented Payroll in January 2003, followed by Financials in March 2003, and Procurement in March 2004. For each functional phase, all modules were implemented across state government on a statewide basis through the use of a Big Bang approach. The Department of Transportation was included in the project scope.
Page 166
September 30, 2008
State of New Mexico

2006
HR/Payroll
2007
The State of New Mexico implemented all state agencies, including Department of Transportation and all functionality, including Financials, Procurement, HR and Payroll, on a statewide basis through the use of a Big Bang approach in July 2006.
State of North Dakota

2003
HR/Payroll
2004
The State of North Dakota deployed the HR/Payroll modules first on a statewide basis in April 2003 through the use of a big bang approach. In October 2004, the Financials and Procurement modules were implemented for all agencies, including the Department of Transportation through the use of a Big Bang approach.
Page 167
September 30, 2008
State of Oklahoma
Financials/Procurement Budget
2003
2004
2005
HR/Payroll phased by agency

The State of Oklahoma deployed its ERP system in the following manner: General Ledger, Accounts Payable, and Purchasing modules went live in November 2003. Group 1 agencies went live on Human Resources/Payroll System in July 2004. Group 2 agencies went live on Human Resources/Payroll System in August 2004. Group 3 agencies went live on Human Resources/Payroll System in March 2004. Department of Human Services Special Clients went live on Human Resources/Payroll System in November 2004. Department of Corrections Inmates went live on Human Resources/Payroll System in July 2005. Department of Corrections Inmates went live on Human Resources/Payroll System in July 2005. Budget Development modules went live in June 2005.
Page 168
September 30, 2008
State of Pennsylvania
Financials & Procurement (phased by agency)
2002
2003
Time Rules HR, Time, ESS, Payroll Recruiting, Personnel Dev, Training
The State of Pennsylvania deployed Financials and Procurement in agency groupings in July 2002, October 2002, January 2003, and April 2003. All Payroll functionality plus HR, Time, and Employee Self-Service were deployed in March 2003. Automated time rules followed in June 2003 and lastly Recruitment, Personnel Development, and Training were implemented in December 2003.
State of Tennessee
2008
HR/Payroll
2009
The State of Tennessees HR/Payroll functionality will be deployed on a statewide basis through the use of a Big Bang approach in October 2008. The implementation process for the Financials/Procurement modules is underway. The first wave of agencies will go live on the Financials/Procurement modules in December 2008. The second and final wave of agencies will go-live on the Financials/Procurement modules in March 2009. The Department of Transportation is participating in the implementation of all functional modules and is included in the first Financial/Procurement wave.
Page 169
September 30, 2008
State of Utah
(Financials/Procurement not in scope)
2003
2004
HR/Payroll
The State of Utah deployed HR and Payroll functionality at all State agencies in September 2003. Financials and Procurement were not in the scope of their project. They upgraded their existing Financials software in July 2006.
Recommended Deployment Option and Timeline

Implementing an ERP system across all agencies in the State of Texas will be a challenge regardless of the deployment option selected. As evidenced by our survey of other states deployment strategies, the ERP system can be deployed using each of several deployment options if proper funding, staffing, time, and executive support are provided. Recommended Deployment Strategy Based on information we have collected and evaluated as part of this study, we believe that the Option #2: Phased Deployment by Agency Group approach is appropriate for the States ERP project. This recommendation is based on the following driving factors as discussed previously in this report: Value Proposition This option allows the early phase agencies to start receiving the benefits of an ERP system as they are deployed and much earlier than the phased functionality approach. This option provides for the integration of major functional processes that are currently fragmented across state government, including human resources, payroll, procurement and asset management business processes. This option also provides the ability to develop a deployment model or blueprint and to use knowledge gained from the initial phase throughout subsequent deployment phases. HB 3106 requires the Comptroller to develop a Statewide ERP Plan and to report to the Legislature on progress made toward implementing the plan
Mandate
Page 170
September 30, 2008
prior to each legislative session but it does not mandate any direction as to how the system is to be deployed. Strategic Initiative Though more tactical than strategic, the following initiatives need to be taken into account when determining a deployment strategy for the new ERP system. It is a goal of the Comptroller to eliminate the States reliance on the existing statewide administrative systems (USAS, USPS, SPRS, TINS, SPA, and HRIS) as soon as reasonably possible to do so. The deployment of the 3 agencies that currently utilize DIRs GFAS accounting system should be considered a high priority. The change management impact will be dispersed over a longer period of time, which will allow the project management to allocate resources based upon criticality of need. This project will require a large change management effort from project initiation through deployment of the final agencies onto the new ERP system. This deployment option divides the project into manageable implementation phases which allows the Project Team to focus on the implementation tasks and the first agencies to be deployed, and then on sequential deployments of agencies assigned to specific groups, which increases the likelihood of a successful deployment and lowers the overall project risk. The phased agency approach will provide the ability to utilize a deployment model or blueprint, and leverage lessons learned from the initial phase across all subsequent deployment phases The ERP system will be utilized by all State agencies with the exception of the five (5) Health and Human Services agencies and institutions of higher education identified as part of BCA 3. The size and geographical dispersion of the State of Texas is considered too large to effectively support a big bang implementation. The functional scope is mandated by HB 3106, although some modules may not be applicable to all agencies. It is anticipated that the following modules will be required for use by all agencies: General Ledger, Accounts Payable, Budget Development, Procurement, Asset Management, Payroll, and Human Resources.
Organizational Readiness
Risk Avoidance
Organizational Scope
Organizational Size
Functional Scope
Page 171
September 30, 2008
Funding Availability The longer the period of time it takes to implement and deploy the new ERP system across state government, the greater the cost to implement. The phased agency approach requires a longer implementation/deployment timeframe than the Big Bang approach, which will allow the State to fund the ERP project over multiple budgetary periods. The phased agency option will provide a viable and timely solution to agencies with compelling functional needs and/or pending software obsolescence, and will allow agencies identified as having critical needs to be given higher priority in the implementation order. When ERP projects are deployed in phases over an extended period of time, the possibility of a change in the States executive leadership exists. No political issues are known to exist at this time. The States prior history of implementing similar projects has no impact on our recommended decision regarding the best deployment option for the State to use. However, it is notable that SPRS is the only major statewide administrative system undertaken by the State of Texas in over fifteen (15) years. The Big Bang option is not feasible for providing effective end user training due to the number of end users, their locations, and the anticipated complexity of the States To Be business processes. The phased agency approach allows the State to spread the end user training effort across several fiscal years. The extended deployment time associated with the phased agency approach will substantially reduce the amount of project team resources required at peak workload in comparison to the Big Bang approach. This approach will require a smaller project team size; however, the team member commitment will be for a longer period of time. The statewide administrative systems are fifteen (15) to twenty (20) years old. While these platforms may be cumbersome and expensive to operate, maintain and support, we believe that the existing legacy systems at the statewide level can continue to operate as required throughout the deployment period and will not require the State to consider an accelerated approach such as a Big Bang approach.
User Agency Needs
Politics
Track Record with Similar Projects
End User Training
Availability of Skilled and Experienced Resources
Performance and Operating Risk of Legacy Systems
Page 172
September 30, 2008
Recommended Deployment Timeline The recommended timeline for implementing and deploying the ERP system at all State agencies is depicted in the chart below:
Activity
Pre-Implementation Requirements Definition RFP Development and Award Phased Agency Implementation Group 1 Group 2 Group 3 Group 4 Group 5 System Retirement of: USAS USPS/SPRS/SPA/TINS HRIS
STATEWIDE ERP DEPLOYMENT TIMELINE for BCA 3 FY09 FY10 FY11 FY12 FY13
FY14
FY15
The specific details of the high-Level Implementation Plan are provided below. Pre-Implementation Activities (FY09 FY10) Per Comptroller direction, the Pre-Implementation Activities would commence in early January 2009 with the purpose of defining the system requirements for the new ERP system and developing a Request for Proposal (RFP) for Software Integration Services. It is anticipated that the remainder of FY 2009 and the first two months of FY 2010 would be used to complete all the activities associated with evaluation process and contract negotiations for the Software Integration Services. The Pre-Implementation Services must be completed over the ten-month period beginning in January 2009. Phased Agency Implementation (FY10 FY15) It is estimated that the ERP Implementation Project will commence in November 2009, and will be completed by the end of FY 2015. Agency deployments will be divided into five (5) phases or groupings of agencies. After an ERP software integration firm has been selected, the Project Team will focus on configuring the baseline ERP software solution, successfully deploying the software for the agencies in Group 1, and developing the deployment model for all other agency group deployments to follow. The initial Group 1 deployments should be completed by the end of FY 2011, which provides for a 22 month period from project commencement. For cost estimating purposes, STA and the Comptroller Project Team developed a detailed deployment schedule to support the estimates for the alternatives (BCA 2 and BCA 3) that were considered and evaluated in this study. This planning schedule will be made available to the Comptroller as part of project close-out activities. This planning schedule was used solely for the purposes of developing our estimates and the Comptroller has not made any decisions or plans regarding the deployment schedule should an actual ERP project be funded by the Legislature. In developing the deployment plan to support this study, the following criteria were taken into account to determine agency groupings by phase: Phase 1 agencies were included based upon those agencies with the greatest need for new administrative systems and those whose existing systems were subject to near-term retirement along with the Comptrollers Internal Operations.
Page 173
September 30, 2008
The remaining agencies were placed in logical groupings based on similar functions (Courts, regulatory, legislative, general government, public safety) in order to allow customization of the training programs for each group. Agencies that utilize USAS as their internal accounting system were placed in earlier phases in order to retire USAS as early as possible in the overall implementation effort. The largest and most complex agencies were spread across the remaining phases in order to balance and level the end user training volume. Based on these agency groupings, we were able to determine when SPA, SPRS, USPS, and TINS could be retired. HRIS would be retired when the last institution of higher education is operational under the Hub model associated with BCA 3 but for purposes of our planning effort, we assumed the final year of the implementation, FY 2015. Should a decision be made by the Comptroller to move forward with the implementation of a new ERP system under BCA 3, the ERP Project Team will review the factors above for each agency and will group State agencies based on the following goals: Identifying agencies with critical system needs or risks so that they do not have to procure or implement an interim solution while waiting for their implementation date; Moving agencies off the existing statewide administrative systems so that these systems can be retired as early as possible; and Balancing and optimizing the allocation of project team resources based upon the following agency factors: Total number of users to be trained within a given project phase; Overall complexity associated with the existing systems or business processing environment for a set of agencies; and The organizational readiness and resource constraints of a set of agencies.
Page 174
September 30, 2008
APPENDIX A: DETAILED ALTERNATIVE 2 ESTIMATING SCHEDULES FOR THE IMPLEMENTATION AND OPERATION OF NEW ERP SYSTEM
Please note that the totals in the following schedules may reflect variances due to rounding.
Schedule A1 Alternative 2 Estimated Costs to Implement and Operate ERP System over 10 years
Page 175
September 30, 2008
Schedule A1 Alternative 2 Estimated Costs to Implement and Operate ERP System over 10 years (cont.)
Page 176
September 30, 2008
Schedule A2 Alternative 2 Estimated Hours to Implement and Operate ERP System
Page 177
September 30, 2008
Schedule A2 Alternative 2 Estimated Hours to Implement and Operate ERP System (cont.)
Page 178
September 30, 2008
Schedule A3 Alternative 2 - Estimated Implementation Full-time Equivalents for ERP System
Page 179
September 30, 2008
Schedule A3 Alternative 2 - Estimated Implementation Full-time Equivalents for ERP System (cont.)
Page 180
September 30, 2008
Page 181
September 30, 2008
Page 182
September 30, 2008
Page 183
September 30, 2008
Schedule A4 Alternative 2 - Estimated Acquisition Full-time Equivalents for ERP System
Page 184
September 30, 2008
APPENDIX B: DETAILED ALTERNATIVE 3 ESTIMATING SCHEDULES FOR THE IMPLEMENTATION AND OPERATION OF NEW ERP SYSTEM
Please note that the totals in the following schedules may reflect variances due to rounding.
Schedule B1 Alternative 3 Estimated Costs to Implement and Operate ERP System over 6 years
Page 185
September 30, 2008
Schedule B1 Alternative 3 Estimated Costs to Implement and Operate ERP System over 6 years (cont.)
Page 186
September 30, 2008
Schedule B2 Alternative 3 Estimated Hours to Implement and Operate ERP System
Page 187
September 30, 2008
Schedule B2 Alternative 3 Estimated Hours to Implement and Operate ERP System (cont.)
Page 188
September 30, 2008
Schedule B3 Alternative 3 - Estimated Implementation Full-time Equivalents for ERP System
Page 189
September 30, 2008
Schedule B3 Alternative 3 - Estimated Implementation Full-time Equivalents for ERP System (cont.)
Page 190
September 30, 2008
Page 191
September 30, 2008
Page 192
September 30, 2008
Page 193
September 30, 2008
Schedule B4 Alternative 3 - Estimated Acquisition Full-time Equivalents for ERP System
Page 194
September 30, 2008
Schedule B5 Alternative 3 Estimated Costs to Implement and Operate ERP System over 10 years
Page 195
September 30, 2008

ERP Business Case Study v11

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ERP Business Case Study v11

Diunggah oleh

Hak Cipta:

Format Tersedia

September 17, 2008 Revised September 30, 2008

September 30, 2008

Mitt A. Salvaggio President

Report on Business Case Analysis for Statewide ERP Planning

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

SECTION 1 EXECUTIVE SUMMARY

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

Approach and Deliverables

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

The existing statewide administrative systems were developed and implemented

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

Business Case Analysis Results

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

FY 2012 FY 2013 FY 2014

T otal (335.2) 299.9 (35.4)

(1.8) (1.8) (1.8) (1.8)

(44.7) 122.0 77.3 75.5 77.3

(45.4) 0.9 (44.4) 31.1 1.9 (42.5)

(37.4) 1.9 (35.5) (4.4) 2.0 (33.5)

(44.9) 10.6 (34.3) (38.7) 2.1 (32.2)

(28.6) 16.4 (12.3) (51.0) 13.5 1.2

(45.6) 23.2 (22.4) (73.3) 17.3 (5.1)

(20.8) 29.1 8.3 (65.0) 23.0 31.3

(21.3) 30.6 9.3 (55.7) 22.1 31.5

(21.9) 32.0 10.1 (45.6) 22.8 32.9

(22.7) 33.0 10.2 (35.4) 23.5 33.7

(1.8) (1.8) (1.8) 60.5

75.5 73.6 71.8

33.0 (38.5) 33.3

(0.5) (28.9) 4.3

(32.7) (26.5) (22.1)

(31.5) 1.0 (21.2)

(36.5) (3.8) (25.0)

(5.2) 22.2 (2.7)

26.2 21.3 18.6

59.1 21.2 39.8

92.9 20.7 60.5 60.5

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

Tot al ( 93 0.3 ) 38 1.2 7 8.2 ( 47 1.0 )

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning

Salvaggio, Teal & Associates

September 30, 2008

Report on Business Case Analysis for Statewide ERP Planning