ACCESS Florida System Replacement · ITN # 03F12GC1 - ACCESS FLORIDA System Replacement Page 1...

Copyright © 2012 Accenture. All Rights Reserved. Accenture, its logo, and Accenture High Performance Delivered are registered

trademarks of Accenture and/or its affiliates in the United States and other countries. This document may make reference to trademarks

that may be owned by others. The use of such trademarks is not intended to imply the existence of an association between Accenture and

the lawful owners of such trademarks. Accenture acknowledges application of Article I, Section 24, of the Florida Constitution, and Section

119.011 of the Florida Statutes. Only to the degree applicable, if Accenture has submitted information it claims is proprietary and

confidential to Accenture, such information should not be disclosed outside of or used for any purpose other than for the State of Florida to

evaluate this Proposal.

December 18, 2012

Submitted To:

Peggy Claborn, Procurement Manager Florida Department of Children and Families 1317 Winewood Boulevard, Building 2, Room 306 Tallahassee, FL 32399-0700 Email: [email protected]

Submitted By:

Accenture LLP Federal Tax Identification Number: 72-052904 John G. Martin, Senior Executive 2002 Old Augustine Road, Suite E45 Tallahassee, FL 32301 (850) 513-3534 Email: [email protected]

STATE OF FLORIDA

DEPARTMENT OF CHILDREN AND FAMILIES

Office of Economic Self-Sufficiency

ACCESS Florida System Replacement

ITN # 03F12GC1

Interim Revised Response (IRR) #3 Document

mailto:[email protected]

mailto:[email protected]

ITN # 03F12GC1 - ACCESS FLORIDA System Replacement Page 1

December 18, 2012

Ms. Peggy Claborn Procurement Manager Florida Department of Children and Families 1317 Winewood Boulevard, Building 2, Room 306 Tallahassee, FL 32399-0700

Dear Ms. Claborn:

Accenture is pleased to submit the Interim Revised Response (IRR) #3 to the Department of Children and Families’ IRR request of December 12, 2012 and addendum of December 13, 2012 in relation to the Invitation to Negotiate (ITN) 03F12GC1 for the ACCESS Florida System Replacement project. As requested, this response provides:

our approach to meet legacy O&M requirements if existing resources cannot be re-badged

adjustment to our legacy O&M price and scope reflecting DCF and NSRC services an updated list of legacy O&M assumptions clarification that our solution does not include “dual use” resources between legacy

O&M and ACCESS Florida Replacement a complete list of all assumptions for the ACCESS Florida System Replacement an updated Bill of Materials (BOM) list that totals to the new cost sheet format an approach to meet the requirement for workers to be able to resubmit the data for

eligibility determination (MAGI included) in one system adjustments made to scope, resources, schedule and pricing for the Training

requirements no longer in scope and the requirement clarified in this IRR updates to standalone project plan and schedule that reflect scope updates

requested in IRR #3 These clarifications reinforce the value that our team and solution can provide to the Department. As the result of this IRR, our legacy O&M price is significantly reduced, reflecting the information provided by the Department. We expect to deliver significant value by providing both Legacy O&M and ACCESS Florida Replacement Services. The scope of both services are priced and staffed so either or both scope of services could be provided as proposed. In the complete list of assumptions, we included assumptions that highlight the value of our solution and considerations the Department should evaluate in assessing alternatives to our proposed solutions. Finally, our clarification on the approach that our solution would use to meet the requirement of “resubmitting data for eligibility

2002 Old St. Augustine Road, E-45 Tallahassee, Florida 32301 PH: (850) 513-0620 FAX: (850) 513-3500


determinations” highlights how our Accenture Public Service Platform (APSP) and our service-oriented architecture (SOA) based solution enables business agility. The architectural capabilities of our solution give the Department flexibility to quickly implement new business requirements and respond to requests and insights on better ways to support the needs of the business. Accenture is prepared to help the Department “move to the next level” of capability and effectiveness through the ACCESS Florida Replacement System project. As DCF prepares for and evaluates this response for further discussions and negotiations, Accenture is available to answer questions and further discuss the best approach and value for DCF and the State of Florida. We have provided the responses to your questions and instructions in the format provided by the Department and have included updated Cost forms as requested. Our response has been developed to be fully responsive to your request. Please do not hesitate to call me at (850) 591 – 5364. I look forward to working with you in this very important endeavor. Sincerely,

ACCENTURE LLP

John G. Martin Senior Executive


2.1 LEGACY OPERATIONS AND MAINTENANCE - ADDITIONAL INFORMATION Vendor Instructions Please submit a backup approach and plan for dealing with the possibility of not being able to re-badge current ACCESS Florida O&M staff. The approach must either include named Accenture resources with the requisite skill set and/or a plan to partner with another vendor who is known as a marketplace leader in the skill sets necessary. Also please provide a timeframe for how long it would take to transition without re-badging.

Vendor Response:

Our approaches to deliver the requisite skills during the takeover of legacy O&M services are successful whether or not we are not able to re-badge current staff into our team. As a recognized leader in O&M services by market analysts like Forrester, IDC, and Gartner, we bring industrialized tools and processes that we have refined throughout our O&M work for clients around the globe. For example, at a large health payer, we took responsibility of the core O&M services without re-badging staff to allow our client to redirect their team members to focus on the key activities associated with a large DDI effort. The first group of resources included 139 personnel transitioned in waves over a 6 month period. The skills requirements ranged from late generation COTS products to decade’s old ‘legacy’ technologies. Our success in this example depended on a blend of our proven tools and approach to transition O&M services coupled with deeply skilled resources with the technical and industrial skills within the Accenture team.

Below please find summary representative qualifications of both Accenture and subcontractor staff with the requisite skills required to work through our industrialized knowledge transfer process to prepare them for support of the current ACCESS Florida O&M function.

We have extensive experience transitioning and successfully delivering O&M services. The timeframe for transitioning these services ranges from as quickly as 2 – 3 months and run as long as 6 - 9 months. We anticipate the timeframe to transition the ACCESS Florida O&M effort at 5 - 6 months if no re-badging is available.

Kyle Federico

Summary of Experience

Kyle is a Senior Manager within Accenture’s Technology practice and is responsible for managing

and leading Infrastructure and Application initiatives. He has experience with project leadership in

all phases of development with an emphasis on Data Architecture. Kyle brings strong skills in

Mainframe, Windows and UNIX technologies and technical architecture as well as significant

experience in logical and physical data modeling.

Kyle’s experience and knowledge includes:

15+ years – Experience with COBOL, IMS, DB2, and Mainframe technologies

15+ years – Experience managing and implementing projects using the proposed development

and testing methodologies

Multiple IBM technology certifications (between the years of 2002 – 2011)

Thomas H. Hawkins



Thomas is a Senior Manager within Accenture’s Health and Public Service practice. He brings over

15 years of experience with legacy system development, maintenance, and conversion activities.

Thomas has worked on multiple Florida legacy systems, as well as other statewide Eligibility system

projects. He brings project experience in analysis, design, development, testing, implementation and

production support of large and complex applications.

Thomas’ experience and knowledge includes:

15+ years – Experience with Legacy Application and Development

15+ years – Experience with Data Migration and Conversion



7+ years – Experience with COBOL and Mainframe technologies

7+ years – Experience with JCL

7+ years – Experience with IBM-TSO/ISPF

7+ years – Experience with VSAM and IBM-DB2

Santosh Duda


Santosh is a certified Application Developer and has over 4 years of Mainframe technology

experience. His most recent role includes multiple projects supporting a large U.S. financial

institution as a software developer, with responsibilities including developing code, unit testing,

coordination with the Release Management team on the movement of code between environments,

supporting the Implementation team, and participating in post-implementation support. In his

previous roles, he gained experience in resolving System Investigation Request (SIR) tickets, job

monitoring, resolving job ABENDS, preparing and executing monthly close-out procedures, creating

and executing DB2 queries and database maintenance, and setting up jobs in production using JCL.

He brings the following key technology experience:

4+ years – Experience with COBOL and Mainframe technologies

4+ years – Experience with FTP



2+ years – Experience with IBM-IMS/DB and IBM-DB2

John D. Mangiaracino


John brings experience across a variety of industries and roles, including systems analysis, design,

development and implementation. He brings over 30 years of IT experience, including significant

COBOL experience, system and program maintenance, debugging and testing. In his roles, John has

also been in liaison roles with user departments to troubleshoot and resolve production system

problems. The majority of his career included legacy application development and conversion, and

his most recent roles have focused on custom development activities and ensuring that project system

requirements and technical specifications are met.


John’s experience and knowledge includes:

15+ years – COBOL programming experience



13+ years – Experience with Packaged Application Integration

3+ years – Experience with IBM-IMS

Cijo Jose


Cijo brings over seven years of IT industry experience. His most recent roles include supporting large

financial institutions in multiple roles, including Application Development, Production and Warranty

Support, Configuration Management, Test Environment Management and Support, and Performance

Testing. In his current role as the Mainframe Technical Lead for a major U.S. credit card and

financial services company, he is supporting multiple technologies including Blaze rules engine, Java,

XML, MQ, and Mainframe technologies and is responsible for ensuring the timely delivery of the

Analyze, Design, Build and Testing deliverables and planning and implementing the software

changes in production. For three years prior to his current role, Cijo worked with a major UK based

banking service provider, filling several roles including Mainframe Developer, Configuration

Manager, and Testing Team Lead. He brings experience in the following areas:

5+ years – Experience with COBOL and Mainframe Technologies

5+ years – Experience with IBM-DB2



Harminder Anand


Harminder is a certified Application Developer, and has over six years of IT industry experience. For

the past three years on his most recent role at a large automobile manufacturing company, he has

supported multiple technologies and coordinated teams with Mainframe and Informatica skillsets. In

his role as a software developer, he is responsible for troubleshooting Production issues, assisting

functional teams for resolution of Production issues, creating documentation for resolution of

complex or recurring issues, analysis and identification of areas of improvement through data

analysis, and identification of enhanced application processes. He brings experience in the following

areas:

5+ years – Experience with COBOL


4+ years – Experience with IBM-CICS

3+ years – Experience with IBM-DB2 (UDB) Optimization & Tuning

3+ years – Experience with IBM-WebSphere-MQ Series

3+ years – Experience with Mainframe Technologies

2+ years – Experience with IBM-IMS/DB


Krithika Sivaramakrishnan


Krithika is a Project Management Professional (PMP), a Certified Software Quality Analyst (CSQA)

Certified Professional, and has over 12 years of IT industry experience including Project

Management, Software Analysis, Design, Development, Testing, and Maintenance on IBM

Mainframes, Web Technologies and SAP. His most recent roles include work with large utility,

healthcare, and retail companies where he has held various roles including Developer, Team Lead,

and Project Manager. In his current role, his responsibilities include Project Management, including

Planning, Execution, Monitoring and Control for the Build Phase, Resource Management, Risk and

Issue Management, Status Reporting, Assembly Test Planning, Monitoring and Control and overall

PMO Management.

He brings experience in the following areas:


6+ years – Experience with Configuration Management




Thomas J. Stidham


Thomas has led out multiple technology projects for Accenture and in his 15+ years in the IT

industry. Thomas spent a good part of his career doing mainframe programming activities for a large

Communications company. Additionally, he has focused on the area of Disaster Recovery. He has

significant Mainframe technology experience, and has supported systems design and development for

multiple applications.

Thomas’ experience and knowledge includes:

15+ years – Experience with COBOL, JCL, and Mainframe technology

15+ years – Experience with managing team activities throughout the Software Development

Lifecycle

10+ years – Experience with DB2 and IMS

Rajesh Nanoo


Rajesh brings over 14 years of systems experience. He has multi-platform experience and has

primarily focused on Application Outsourcing Development and Maintenance projects for a variety of

clients. In his most recent role as Application Lead with a large U.S. based global package delivery

company, he is responsible for leading multiple applications in the client’s portfolio and is

responsible for end-to-end delivery and maintenance of these applications, predominately on

Mainframes. He is responsible for quality delivery, management of risks and issues, capacity

management, management of the project work plan and execution, and proposing and implementing

remediation strategies to strengthen delivery. Rajesh brings experience in the following areas:





Rajib Chowdhury


Rajib is a Mainframe Professional who brings over six years of IT industry experience. He has

worked as a Technical Lead on multiple projects, including his current role with a large retail

organization. His specific responsibilities include developing functional specifications and technical

specifications, build, testing, and UAT support. He is also responsible for preparing management

reports, weekly status reports, and task allocation for resources. He brings experience in the following

areas:



4+ years – Experience with IBM-DB2/400

2+ years – Experience with Oracle-PL/SQL 10g

Rajiv Jayaram Kanugagadda


Rajiv joined Accenture in 2006 and brings over 12 years of IT industry experience in the areas of

Software Project Management, System Design and Development, and Technology Architecture. His

previous roles include experience with large communications and financial services companies with

hands on experience with Mainframes, DB2, IMS, and VSAM databases, a variety of application

development tools, and COBOL, JCL, CICS, REXX, and MQ Series languages. Rajiv he brings

experience in the following areas:




2+ years – Experience with Business Continuity Planning

Raghunatha R Narala


Raghunatha is a Software Engineer within Accenture’s Health and Public Service practice, and brings

17 years of extensive experience to this project. He brings project experience in analysis, design,

development, testing, implementation and production support of large and complex applications. He

has designed and coded programs using COBOL, DB2, SQL, IMS DB, CICS and MQ Series, and has

supported a variety of applications, including both online and batch systems.

Raghunatha’s experience and knowledge includes:

20+ years – Experience supporting online and batch systems

15+ years – Experience with COBOL, DB2, and IMS

7 years – Experience working in the Health and Human Services sector

4 years – Experience managing and implementing projects using the proposed development and


testing methodologies

Miles Bauer


Miles is a manager within the Accenture technology practice, and has more than 25 years of

experience in delivering successful IT projects. He brings experience from all stages of project life

cycle management from project inception to implementation, and enterprise-wide application

rationalization. In his current role, Miles is focused on leading out requirements management and

functional testing responsibilities across the team.

Miles’ experience and knowledge includes:

15+ years – Experience with COBOL, IMS, and JCL

15+ years – Experience with business analysis and supporting system solutions that meet

technical requirements

5+ years– Experience with DB2

2.2 LEGACY OPERATIONS AND MAINTENANCE –HOURS CLARIFICATION Vendor Instructions The average number of hours for standard ACCESS Florida O&M (non-enhancement) is 27,000 hours a year (based upon the past 3 years). The attached three (3) “NSRC SLA” documents have been provided to help identify the scope of services provided by the NSRC and would not be the responsibility of the vendor. The vendor should review these documents to clarify their assumptions for Operations and Maintenance. Please review your current estimates for standard O&M (non-enhancement) and adjust your price and hours accordingly. Vendor Response:

Please find the attached Microsoft Excel spreadsheet that includes the requested hours and pricing information.

Assumptions related to this item can be found below in the requested appendix for item 2.3.


2.3 LEGACY OPERATIONS AND MAINTENANCE – VENDOR ASSUMPTIONS Vendor Instructions Provide an up to date list of all assumptions made by the Vendor related to their legacy O&M proposal. Do not refer to another document or negotiation session. All assumptions must be provided in writing in the IRR response.

Vendor Response:

The SLA documents pertaining to the Legacy Operation and Maintenance provided a clearer understanding of the responsibilities the Department is requesting of the Provider. The assumptions that follow reflect the guidance outlined in the SLA documents and provide the basis of estimate for the scope of services Accenture is including within the pricing found within this IRR. We expect that the items outlined below are confirmed during the transition period where Accenture takes responsibility for the Legacy Operation and Maintenance function and reported through delivery of the service. Changes to one or more of these assumptions could lead to changes to Accenture’s price.

1. The on-site support hours for the legacy and replacement systems will be from 7:00AM to 7:00 PM Eastern Time during business days. On-call support will be provided from 7:00 PM to 7:00 AM on business days and during non-business days for high priority issues.

2. O&M support for the legacy ACCESS Florida system ends on June 30, 2016. 3. Transition for legacy support will occur from January 2013 to May 2013. 4. DCF will manage, compensate, and direct the incumbent legacy O&M provider throughout

the transition period. 5. Accenture is not responsible for any effort or cost to address Human Resource or personnel

impacts for the existing Legacy O&M team including retention of key personnel for knowledge transfer, or reassignment within DCF or the respective third party organization.

6. The existing operational reports, processes, and tools will continue to be used by Accenture. 7. DCF will provide all facilities, computers, phones, network access, printers, software,

hardware, and any other items required for Accenture to provide the Legacy Operation and Maintenance service at no cost to Accenture.

8. Basis of estimate items are included below. These items outline the amount of effort Accenture provides DCF in support of Legacy Operation and Maintenance activities and provide hours of effort for the Legacy Operation and Maintenance activities consistent with the hours provided historically by the incumbent provider. Accenture will work with DCF to prioritize work effort of the team described below:

a. 9,500 tickets/incidents a year are created for the ACCESS FLORIDA System; b. DCF’s Level 1 help desk will close 65% of the 9,500 tickets; c. The remaining 3,326 tickets/incidents go to the Accenture Level 2 support team; d. The average time to resolve Level 2 tickets/incidents is 4 hours; e. 15% of the tickets/incidents sent to Level 2 require the Accenture Level 3 support

team to resolve; f. The average time to resolve Level 3 tickets/incidents is 17 hours; g. We provide 3.75 full time resources for data and database administration,

environment support for development and production, and report and interface support.


2.4 ACCESS FLORIDA SYSTEM REPLACEMENT – RESOURCE PLANNING Vendor Instructions The Vendors are instructed that there will be no “re-use” or “dual assignment” of resources between the legacy O&M effort and the ACCESS Florida System Replacement effort (Phase 3, 4A, and 4B). If needed, adjust your staffing plans accordingly and provide an updated list of key resources for both efforts. If assigning new key resources, the vendors are instructed to provide resumes for the new resources. Please provide any net cost impact that this has on the vendor’s proposal (by phase). Vendor Response:

Our solution does not employ “re-use” or “dual assignment” of resources between the legacy O&M effort and the ACCESS Florida System Replacement effort (Phase 3, 4A, and 4B).

We assume very minimal cross project administration activities would be performed using resources included by the Provider that performs the ACCESS Florida System Replacement effort. Cross project activities may include tracking legacy O&M effort resource assignments, availability schedules, and actual time for tasks that are dependent on or contribute to the ACCESS Florida System Replacement effort. Additionally, we would expect the ACCESS Florida System Replacement PMO would handle any cross project account relationship management activities.

The information we submitted from IRR#2 on instruction 2.4 is unchanged.

2.5 ACCESS FLORIDA SYSTEM REPLACEMENT – VENDOR ASSUMPTIONS Vendor Instructions Provide an up to date list of all assumptions made by the Vendor related to their ACCESS Florida System Replacement proposal. Do not refer to another document or negotiation session. All assumptions must be provided in writing in the IRR response.

Vendor Response:

The assumptions are grouped into four primary sections: Cost Reply: Key Assumptions which are the assumptions originally included in Accenture’s cost proposal; Value and Other Solution Assumptions include additional assumptions that we have identified based on our discussions with DCF during negotiations to date; IRR #2 Assumptions which were provided based on a question about the departmental responsibilities; and the last section which includes other assumptions that have been identified but did not fit into one of the other categories. Grouping the assumptions in this manner provides DCF with an easy way to tie back to where the assumption came from and also allows DCF to avoid having to reconcile assumptions you may have already evaluated.

We have italicized assumptions that have been written or clarified since previous proposal or IRR submissions.

I. Cost Reply: Key Assumptions

General


1. Accenture assumes that the ITN and other information provided by or referenced by the Department to the respondents is accurate and complete. If, after the Contract is signed, it is determined that the ITN or other information provided by the Department to the respondents is inaccurate or incomplete in any material manner, the parties will negotiate an adjustment in the project scope and fees, as applicable, per the Contract’s change order process.

2. Accenture’s fixed price is based on delivery of the fixed scope of services in our proposal. The scope of the services as documented will remain unchanged, except as the parties may agree in writing. All other work will require the parties to agree upon a change order to the Contract, which may include applicable fees, if not addressed by other Contract mechanisms such as the included annual Service Hours.

3. Accenture's performance of the Contract is dependent on the Department's prompt and effective performance of its responsibilities, including timely decisions and approvals.

4. The Department will commit resources and management involvement as described in the Contract or as required by the work effort in order to support Accenture’s delivery of the services and to perform the agreed upon acceptance procedures in a timely manner. (This assumption was further defined in response to IRR #2. That response is included below.)

5. The Department will be responsible for its operation and use of Accenture’s services and deliverables upon acceptance, subject to applicable warranties and indemnities, if any, and for determining whether the services and deliverables provided by Accenture under the Contract, including any revised business processes implemented pursuant to the Contract, meet the State's business requirements and applicable internal guidelines.

6. The State will obtain all consents necessary from its third parties (i.e., those not under contract with Accenture) required for Accenture to perform its obligations under this Contract. The State will be responsible for the contractual relationship with such third parties and for facilitating their cooperation with Accenture. Accenture will not have any responsibility for the performance of other contractors or vendors engaged by the State (other than Accenture’s subcontractors) or delays caused by them. There are no third party beneficiaries to this Contract.

7. The State will be responsible for obtaining, at no cost to Accenture, consents for Accenture’s use of any State Furnished Property necessary to perform its obligations hereunder. Unless otherwise agreed to by the parties in writing, the State will provide all software and hardware necessary for Accenture to perform its obligations under the Contract consistent with the ITN provisions.

8. Each party will retain responsibility for its compliance with any laws, regulations, or other authorities, in effect on the date of submission of our proposal, including those areas on which it relies on the other party’s performance under the Contract.

9. Additional clarifying details and assumptions for the application and measurement of Service Level Expectations beyond that included in the ITN and our proposal will be defined and mutually agreed upon by both parties in writing prior to the execution of the Contract.

Basis of Estimate


10. We have assumed in our estimates that our effort will be focused on configuring the Florida-specific business rules, data rules and implementing the identified gaps. To address gaps, we have estimated the following customizations to the ACCESS Florida replacement system:

50 Reports

86 Interfaces

190 Forms/Notices

31 Batch Programs and Modules

Data Conversion

11. We are proposing an approach that converts only the data needed to continue to process existing cases on the ACCESS Florida Replacement System. We are not proposing to convert all data in legacy systems to the new system. Data that is not converted would be available by looking at the legacy system or an extract of the system that is stored for ad hoc inquiry purposes.

12. Our conversion approach assumes each data element is converted from a single legacy system. Should data elements exist in multiple legacy systems, Accenture will work with DCF to identify one system as the data owner.

13. The total number of unique data owner systems shall not exceed four based upon our experience on numerous conversions from legacy welfare systems into the ABMS database.

14. Because roles on the new system are likely to be different, we not planning to convert user identity and access control data for system users. We may provide “a migrate your id” function that creates a new id on the new system that runs as part of the logon process.

15. We have included 3 simple programs to meet the requirement to import data from "Excel Spreadsheets and other sources".

16. Document images and associated meta data will be converted as-is without modification to image format or resolution.

17. To address data conversion requirements we have estimated the following:

46 Data cleansing and scrubbing programs

4 Data duplication reports

70 Tracking reports

18. DCF is responsible for correction of errors in manually converted data.

19. Our conversion approach assumes the use of standard conversion tools including load


programs.

20. We have assumed 3 formal mock conversions prior to pilot and 1 per month during rollout.

Operations and Maintenance

21. Operations & Maintenance and Warranty will begin upon production implementation for Phase 3 and Phases 4A /4B. We include this as clarification that O&M services cover the entire duration of the contract.

22. The on-site support hours for the legacy and replacement systems will be from 7:00 AM to 7:00 PM Eastern Time. On-call support will be provided from 7:00 PM to 7:00 AM for high priority issues.

23. O&M support for the legacy ACCESS Florida system ends on 10/31/2015. Refer to Legacy Operations and Maintenance Assumptions.

24. Upon successful implementation and conversion of a region/county/office, the replacement system becomes the system of record. All O&M activities related to converted cases is included within the ACCESS Florida replacement system O&M.

25. Hardware and Infrastructure support for legacy applications involving operations and maintenance of hardware and software at the NSRC data center will be performed by the state staff. NSRC staff will continue to provide the services outlined in the SLA documents provided by the Department in IRR #3 throughout the period of legacy operations and maintenance.

26. The following stabilization phase is considered for support of each phase of the replacement system:

Phase 3 - 1 month

Phase 4A - 2 months

Phase 4B - 2 months post final roll-out

27. Knowledge Transition for legacy support will occur between 1/14/2013 to 5/31/2013. Refer to Legacy Operations and Maintenance Assumptions.

28. DCF will manage, compensate, and direct the incumbent legacy O&M provider throughout the transition period. Refer to Legacy Operations and Maintenance Assumptions.

29. Our cost estimates for DDI O&M support are based on an estimating model of the number of contacts and contact duration. The actual number of calls will be driven by number of users trained and calls per user per month. Initially, we estimate calls per user would average 1.5 calls per month decreasing to an average of .7 calls per user per month. During the implementation of Phase 4A/4B Integrated Release, there will be a spike in the demand support because of the cumulative impact of new users being added to the system.


30. Department resources will provide support to users on the topics of policy questions, how-to support case scenarios, remedial training, and case specific processing questions. Users are expected to contact a super user or other department resource on non-system problems or questions. The Accenture Help Desk and O&M support is structured to handle system problems, technology support and system defect issues.

31. SLAs will be calculated for Accenture commitments from the time it is recorded in the tool.

32. We plan to use Accenture’s Service Desk tool (BMC Remedy) for DDI O&M. We assume there are no requirements to integrate the BMC Remedy tool with other systems.

33. DCF will continue to provide an Enterprise Level 1 help desk to cover network and desktop support.

34. Accenture will utilize an agent-at-home model to provide help desk services.

35. The help desk support will provide support in English. We anticipate less than 1% of total contacts would occur outside of normal hours. After hours calls will be answered by the Level 2 team.

36. DCF will handle all effort and cost to address personnel impacts of the existing Legacy O&M team including retention of key personnel for knowledge transfer, or reassignment within the organization. Refer to Legacy Operations and Maintenance Assumptions.

Hardware and Software

37. We assume DCF will secure a disaster recovery facility or services that provide hardware, software licenses, hosting services and network connectivity and bandwidth.

38. We assume use of state data centers (e.g., Northwood Shared Resource Center) for hosting services and that DCF will pay for hosting service costs. Hosting services include: secure server space, power, network connectivity, bandwidth, backup services, physical security for the hosting center and other hosting related items.

39. We have scheduled the purchase of production software to minimize the maintenance charges prior to system implementation. We have scheduled purchases to occur based on the date of procurement provided in the detailed Hardware Software Bill of Materials (BOM). Changes in the timing of purchases could impact the maintenance payment amounts and timing.

40. We have optimized our hardware and software license purchases to support the number of development resources we have proposed. For example, we have purchased named licenses for development where the breakeven was much less than the server license price. If DCF (including IV&V, PMO or other agency users) needs to participate and use these environments, DCF may need to purchase additional named licenses or purchase server licenses.

41. We assume that hardware software purchases for the project will be made by the State using Accenture Proquire / Alliance Services organization. We assume software and hardware will be titled to DCF and that DCF will be responsible for maintenance payments.


Training

42. DCF is responsible to make sure workers have completed any prerequisite training (e.g., computer literacy, HIPAA, etc.) needed for ACCESS Florida Replacement System Training to be effective.

43. ACCESS Florida Replacement System Training will consist of a combination of Web Based Training followed by 2 days of instructor led classroom based training.

44. DCF is responsible for all training facilities being delivered in a ready for training state on the days of training and will provide policy staff.

45. Users will be able to access a shared training sandbox environment to practice using the system after they have attended web based training. This will be a shared environment in which any case worker can use the shared data in the system. Data in the training sandbox may be refreshed on a periodic basis.

46. Instructor led classroom based training sessions will accommodate up to 20 attendees. We have estimated the average class room size would be 15 users.

Implementation

47. During roll-out of the system, it is likely that resources may be needed to work onsite at user locations to provide a smooth transition to operations using the new system. Accenture expects the majority of this support would be provided by DCF business representatives. Accenture has proposed to provide up to 10 FTEs per month that can participate in onsite support activities.

Security

48. Accenture team members will use remote access technologies to access development and test environments hosted at NSRC. Accenture team members will access these environments from locations within the continental U.S.

49. We request that DCF only provide HIPAA or PII data to Accenture resources in compliance with the data security policy agreed to between Accenture and DCF.

50. We have proposed software that can anonymize sensitive data so that production data can be used for testing. We prefer that DCF perform data anonymization and that production data not be accessible for design, development and testing. The only potential exception might be conversion which may need limited access to production data to support conversion analysis.

Accenture Software

51. We are proposing to use COTS products that have proven they can support eligibility processing for similar organizations. We are planning to use out-of-the-box functionality with the performance profile and capabilities that come with these products.

52. We are assuming purchase of APSP, ABMS, ACSSP software products and maintenance


during the plan phase at the start of the project. These Accenture Software products require an agreement with the C-IV Consortium whose cost is included within our price.

Pricing

53. Our price is inclusive of the MyFloridaMarketPlace 1% transaction fee.

54. Our fixed price is exclusive of taxes.

55. For years where we do not provide 12 months of support, the monthly costs that we have included in Part 4 Legacy Operations and Maintenance (O&M) Proposed Costs reflects the total cost for the months we are providing support divided by 12. This assumption may be tied only to the originally proposed approach.

56. Pricing in Part 4 Legislative Enhancements in FY12-13 represents 800 hours of work reflecting a prorated support period between the contract start date and June 2013. This assumption may be tied only to the originally proposed approach.

57. Pricing in Part 4 Legislative Enhancements in FY15-16 represents 2,000 hours of work reflecting a prorated support period between July 2015 and October 2015. This assumption may be tied only to the originally proposed approach.

II. Value and Other Solution Assumptions

Best Value Assumptions

Definition of Best Value – We have assumed best value to mean risk adjusted net present value. We assume the evaluation of our offer considers the net costs, net benefits, timing of costs and benefits, and risk adjusted likelihood of costs and benefits occurring over the life of the State’s investment. Considering risk adjustments are extremely important because they create more realistic projections which results in better decisions. For example, if an investment (e.g. a car) promises a certain operational cost (MPG), but only has small likelihood of achieving that cost, that would affect savings (gas) you would get and should affect the price you are will to pay for the car.

Risk Adjusted Cost for State Incurred DDI Costs Associated with Implementation Delays - Our solution assumes zero cost for additional State Incurred DDI costs based on the risk adjusted likelihood that our solution implementation timeframes will extend past the federal deadlines. The Risk adjusted likelihood of implementation taking longer than contracted for is calculated by taking our company historical average the number of months later than original contracted implementation date (zero) for statewide eligibility project implementations and statewide enterprise system implementations in Florida. Achieving this same on time delivery is what historical experience would support as an assumption for our offer. Historical experience would predict a very different result and requisite assumption with our competitors which should be incorporated in their risk adjusted cost.

Risk Adjusted Cost for Loss of Expected Feasibility Study Benefits Associated with Implementation Delays – Our solution assumes zero cost for Loss of Expected Feasibility Study Benefits because of Implementation Delays. The Risk adjusted likelihood of implementation


taking longer than contracted for is calculated by taking our company historical average number of months later than original contracted implementation date (zero) for statewide eligibility project implementations and statewide enterprise system implementations in Florida. Achieving this same on time delivery is what historical experience would support as an assumption for our offer. Historical experience would predict a very different result with our competitors which should be incorporated in their cost and assumptions. This assumption is a major consideration since the value to the state likely exceeds the DDI Provider fees by several times.

Risk Adjusted Cost for DDI Costs that do not Receive Enhanced Federal Match – Related to State Incurred DDI Costs assumption above, our solution includes a zero cost assumption to cover the risk adjusted likelihood of reduction in Federal Match due to schedule delays. Because the Federal government is clear that enhanced match is only through December 2015, if Medicaid eligibility implementation activities occur after December 2015, the State would not receive enhanced match on the expenditures after 2015. The Risk adjusted likelihood of implementation taking longer than contracted for is calculated by taking our company historical average of the number of months later than original contracted implementation date (zero) for statewide eligibility project implementations and statewide enterprise system implementations in Florida. Achieving this same on time delivery is what historical experience would support as an assumption for our offer. Historical experience would predict a very different assumption with our competitors which should be incorporated in their cost.

System Life Costs for O&M Cost – This solution requires a small O&M staff resulting in an assumption of ~36 O&M staff. This assumption results in a substantial annual recurring cost savings that continues for the life of the new system. The cost evaluation sheets only evaluate the contract period which is a small fraction of the expected system life. Our solution is designed to meet the overarching objective of maximizing overall value. We assume that value generated by our solution beyond the contract period is considered.

Program / Policy Change Implementation Speed –Our solution provides value by being able to implement program and policy change quickly. In our oral presentation, we described the speed and cost advantage our solution creates for implementing program and policy changes. Because program / policy changes often create value that benefit the State or people of the State, faster implementation means the benefits of policy / program changes can occur faster, producing a higher amount of value. We assume this value differentiator applies to this project.

Solution / Capability Assumptions

This section contains assumptions about proposed solution components, clarification of capabilities provided by the solution, insights on effort, cost and elapsed time to develop and provide equivalent capabilities.

Call Center Solution

Our proposed call center solution includes costs to meet call center processing requirements in a manner that is designed to achieve the lowest net cost / highest net benefit for the State.


The differentiated solution capabilities / value of our proposed solution include:

• Multi-channel Contact Management including chat, web collaboration, email • Workforce Management • Courtesy Call Back reduces on hold time charges • Outbound Calling • Routing to best available worker • Low/No cost to support call growth • Eligible for Enhanced Fed Match for Medicaid Transactions (90% DDI; 75 O&M)

Our proposal also described the option of using the existing hosted call center solution used by DCF. Our analysis below shows the costs included for of our recommended solution compared to costs of the existing hosted solution as an alternative.

Note that Benefits / Saving exist for the Cisco UCC solution as a result of improvements related to intelligent call routing, courtesy call back, increased self-service, and an overall reduction in call minutes.

Note that Net Cost to State is the result of Total Cost less (Federal Match + Benefits / Savings).

Our cost sheets include DDI and O&M costs associated with our solution. We have not included the bottom line difference in Net Cost to State as a cost reduction in our response. However, if the State were willing to direct the current payment stream of existing usage based costs based on current service costs to the Provider, we would be open to discussions on a significant cost reduction in our DDI price. Alternatively, we assume from a solution comparison basis the

5 Year Cost ($M)

PatLive

Hosted

Cisco

UCC

One Time Costs

DDI Services 0.20 10.00

DDI HW / SW 0.00 5.25

O&M Costs

O&M Services 0.0 2.9

O&M HW/SW Main 0.0 1.5

O&M Usage Fees 106.5 0.0

Total Cost 106.7 19.7

Federal Match 53.4 15.6

Benefits / Saving 0.0 10.0

Net Cost to State 53.3 -5.9


State is including expected per minute operational usage fees as an O&M cost in cost evaluations of any competitors that elected to propose the existing hosted service instead of proposing a new infrastructure.

Identity and Access Management

Our solution assumes the requirements to use a single id includes the expectation that the single id is not just a separate id that happens to have the same id name. Our solution includes the hardware and software cost for identity and access management capabilities that automate and support user provisioning and single sign-on. Use of single sign-on creates significant value in saving user time, reducing support calls, administering and managing system access on timely basis. For a modern system this is a common expectation. We assume from a solution comparison basis the State is instructing competitors to reflect the development and rework costs in their proposals to provide equivalent capabilities or would instruct us to reduce or remove our Identity and Access Management capabilities to create an equivalent comparison across bidders.

Enterprise Service Bus

We have included no additional cost to achieve the architectural integration approach and capabilities described in our solution and orals demonstration. These capabilities are inherent within and are an important enabler of our solution. We estimate the minimum cost of services and elapsed time for a competitor to replicate equivalent capabilities would be approximately $3M and an elapsed time of 12 months prior to which integration work could not begin without being redone later when the described capabilities we designed, developed, tested and stabilized. The ESB and integration capabilities help reduce DDI and O&M cost and schedule risk. We assume from a solution comparison basis the State is instructing competitors to reflect the development and rework costs in their proposals or would instruct us to remove our ESB integration capabilities to create an equivalent comparison across bidders.

Enterprise Content Management

Our solution includes hardware and software cost for the ImageAPI iCenter solution to support eligibility document management requirements. This solution in conjunction with ImageAPI’s document processing services provides a proven low cost solution for high volume document ingestion, indexing, storage and lifecycle management. We understand the operational services related to centralized document handling are not in the scope of this ITN. We are able to fully articulate the value of our proposed solution including specific eligibility domain considerations that may not have been explicitly stated as requirements. Some examples include controls and processes necessary to meet court document validation and chain of evidence requirements. We assume from a solution comparison basis, the State is instructing competitors to reflect the development and rework costs in their proposals to provide equivalent capabilities or would instruct us to reduce or remove our Enterprise Content Management capabilities to create an equivalent comparison across bidders.

Oracle Policy Automation

Our solution includes Oracle Policy Automation. This product is used to perform rule based eligibility decision making. The capabilities of this tool are superior to just rules engines that


solely focus on execution of rule based processing logic. The OPA product includes impact analysis capabilities and capabilities that help policy makers and program staff through the entire lifecycle of identifying, analyzing and implementing policy and program changes. We assume from a solution comparison basis the State is instructing competitors to reflect the costs in their proposals to provide equivalent capabilities or would instruct us to reduce or remove policy automation capabilities to create an equivalent comparison across bidders.

DBMS Product Features

Our solution includes hardware and software cost for the Oracle DBMS. We have proposed the enterprise edition version of the core product and many other licensed products including real application clustering, partitioning, compression, data masking, active data guard, and enterprise manager options. The capabilities and flexibility provided with the set of products we have proposed is significant. Using these products has significant benefit in reducing the time for operational and maintenance activities, increase system availability, reduce system recovery time, improve security and improve system response time. We assume from a solution comparison basis the State is instructing competitors to reflect the costs in their proposals to provide equivalent capabilities or would instruct us to reduce or remove specific DMBS capabilities to create an equivalent comparison across bidders.

Adobe Life Cycle

Our solution includes Adobe Life Cycle for correspondence generation. The capabilities provided by Adobe Life Cycle are a significant contributor to creating easy to read and understand communications that include dynamic content customized to the client. The features of our solution should reduce client confusion and ultimately help reduce client calls to the call center. This tool also adds value in presenting consistent communications to clients and system stakeholders. Additionally our solution comes with starting point correspondence that uses this architecture. We assume from a solution comparison basis the State is instructing competitors to reflect the costs in their proposals to provide equivalent capabilities or would instruct us to reduce or replace Adobe Life Cycle capabilities to create an equivalent comparison across bidders.

Audit Vault

Our solution includes Oracle Audit Vault. This tool captures audit records of activity in a way that is externalized from application logic. This architectural approach reduces the dependence on application code to write audit records. This approach is superior in capturing records of access and changes that are made regardless of the application that is used. This reduces ongoing application development, testing, O&M and security compliance effort. Additionally, it reduces interactive user response time compared to the approach of synchronously writing audit records with application code during the course of each user transaction. We assume from a solution comparison basis the State is instructing competitors to reflect the costs in their proposals to provide equivalent capabilities or would instruct us to reduce or remove specific audit logging capabilities to create an equivalent comparison across bidders.

Use of Portlets


Our solution uses a true portal architecture that includes use of standards compliant portlets. A solution that uses a portal architecture compared to an application that is simply java pages provides very different capability and value profiles. We would estimate converting a non-portlet based application that is simply java pages to portlets would be a significant cost and potential impact to schedule that could cause work to be redone later when the described capabilities are designed, developed, tested and stabilized. We assume from a solution comparison basis the State is instructing competitors to reflect the development and rework costs in their proposals to provide equivalent capability or would instruct us that the Department does not want a true portal architecture with portlet capabilities and that we could reduce or remove and costs with these capabilities to create an equivalent comparison across bidders.

APSP Service Layers, Services and Frameworks and Product Specific Adapters

The APSP SOA architecture solution we have proposed includes a layered architecture that allows architecture and business service capabilities to be replaced with different products. This flexibility is a capability will have value during the life of the system. It allows the Department to change products or vendors helping to reduce vendor dependence and encouraging competition to provide better and more cost effective processing capabilities. We assume from a solution comparison basis the State is instructing competitors to reflect the development and rework costs in their proposals to provide equivalent capability or would instruct us that we could reduce or remove these capabilities to create an equivalent comparison across bidders.

III. Departmental Responsibilities (IRR#2 Response) Assumptions

Accenture has assumed the State would perform the State tasks outlined in the ITN. We have assumed State resources will provide zero days of effort performing the vendor tasks outlined in the ITN.

Department Responsibility Recommendations

In implementing Department responsibilities, we would recommend DCF consider performing responsibilities using the following techniques that have been proven to streamline implementations in other enterprise system implementations.

• Establish a formal business team that is responsible for decision making on business processes and policy of DCF.

• Provide a small core set of business team representation who participates in all conference room pilot sessions. We have seen benefits from involving a core set of participants throughout as a “common thread” as opposed to involving a changing set of participants representing different perspectives in each session.

• It is a common interest to have an efficient and timely deliverable review process. The latest version of Microsoft Office allows concurrent review, comment and editing of documents. Traditional deliverable review processes are sometimes paper based, involve sequential passing of a document, or require an effort to validate and consolidate reviewer comments -- all of which increase the elapsed time. We recommend that Deliverable reviewers use the collaborative


features of MS Office to concurrently review and comment on deliverables. Additionally, for minor corrections, we would encourage the reviewer to enter the change with track changes enabled. If access is provided to Provider personnel to participate in review deliverables, Provider personnel can begin to address deliverable review issues and concerns as they are identified, resulting in a shorter elapsed time to approving the deliverable.

Outside of the responsibilities in the SOW, Accenture assumptions about Department responsibilities are listed below and are organized and referenced by SOW section:

8.1 Project Management

Clarification – 8.1.2.5. Define reporting structures between various participants in the Project (Project Governance). – We assume this includes defining a strategy for geographic stakeholder representation and participation and that the Department will communicate that strategy to stakeholders.

Clarification – 8.1.2.6. Monitor the Availability and Participation of State Staff – We interpret this to mean the Department will include Department and non-provider and subcontractor staff, their activities, and availability for inclusion in the Integrated Master Schedule. Relevant non-provider and non-subcontractor staff will record and track availability in the Integrated Master Schedule.

Clarification – 8.1.2.17. Provide a SharePoint repository for Project documents and deliverables. – We assume the provided SharePoint repository is from a contracted provider. Provider would provide a SharePoint development resource(s) if necessary to support implementation of basic SharePoint based tools and processes.

Missing - Manage and direct Department personnel and external (other agency) personnel (non-Provider or subcontractor staff) to complete Department activities.

8.2.2 Phase Gate Reviews

Clarification – 8.2.2.2 – Review and comment on deliverables submitted for phase gate reviews. – We assume the Department will be able to review completed portions of Phase Gate Acceptance deliverables and provide informal comments for portions provided prior to the completion of all components to the deliverable.

Clarification – 8.2.2.3 – Approve or reject phase gate acceptance deliverables. – We assume for any rejected phase gate deliverable, the Department will provide specific actions required for acceptance and will provide timely accessibility to review revised deliverables.

8.5 – Disaster Recovery

Clarification – 8.5.2.3 –Coordinate and assist with the testing of the disaster recovery process. - We assume the testing relates only to the new system and related support processes. The testing process may use a simulation test approach to validate understanding of disaster recovery processes prior to operational use of the system.

Missing – Department is to contract for or provide the disaster recovery hosting service.


9.2.2 Define Phase Responsibilities

Clarification – 9.2.2.1 – Review and approve requirements elaboration schedule […] within 10 days - We assume Department personnel will perform define phase orientation activities (e.g. Web based training) prior to the first scheduled elaboration session.

Clarification – 9.2.2.3 – Provide comments [..] with 15 business days … - We assume the need for 15 business days is based on completion of all requirements (Phase 3, 4A, and 4B). We would expect a significantly faster turnaround if the stand alone project approach is used.

9.9.2 Develop Forms and Correspondence

Clarification 9.9.2.1 – Work with Provider to design and develop forms and correspondence – We assume Department personnel will provide and validate translation of forms and correspondence content that are not produced in English.

9.12 – Test Phase – User Acceptance Test

Clarification – 9.12.2.1 – Review and approve UAT Plan – We assume the Department will provide user input on desired plan, and test scenarios at the initiation of Provider’s work to generate the UAT plan and test scenarios.

9.14 – Data Conversion

Clarification - 9.14.2.2 – Provide support to enable the Providers staff to write and execute data extract programs … - We assume the Department would be responsible for logistics, tools and environments involved in providing access and enabling Provide staff to write and execute data extract programs. We will collaborate with Department resources to help define and have the appropriate Department legacy support resource(s) perform a basic data extract of information from legacy sources.

Clarification - 9.14.2.7 – Determine level of manual effort... – We assume Provider will participate and consider input in the Department’s determination of the level of manual effort.

9.15 Implement Phase - Training

Clarification - 9.15.2.1 - … Provider will be expected to provide resources[…] to participate in procedure training – We assume content would be incorporated into training curriculum (WBT or instructor led sessions) in a way that could leverage proposed sessions and Provider training staff.

11. Operations and Maintenance

Clarification – We assume the Provider help desk will only receive initial contacts related to the new system. The Department would provide help desk support for non-system items like policy, procedures, Department learning management system (LMS), user desktops, other Department systems, and other Department functions.


14. Operations Transition

Clarification – On request of the department […] – We assume the Department will provide advance notice of request to develop an Operations and Maintenance Transition Plan at least 90 days prior to desired transition completion.

IV. Other Assumptions

Deadlines for Starting Phases

Our current proposal assumes a January 14, 2013 start date. A “drop-dead” start date for Phase 3 to meet the October 2013 and January 2014 ACA deadlines is February 4, 2013.

If the project start date is delayed past the February 4, 2013 “drop-dead” date, we will need to work together to mitigate a shorter schedule with considerations around changes in the methodology, solution approach, deployment approach, and environment set up and usage.

The “drop-dead” date for Phase 4A to meet the December 2015 enhanced funding deadline while not altering our current proposal is January 6, 2014.

2.6 ACCESS FLORIDA SYSTEM REPLACEMENT - BILL OF MATERIALS (BOM) Vendor Instructions The BOM totals should tie to the hardware and software costs provided in the Vendor’s cost proposals. We have provided an updated cost template to assist in this exercise. Please complete the Cost Reply using the Part 1, Part 2, and Part 3. Note that the Software and Hardware in the Cost Reply has been rolled up into Development, Test and Production totals. The vendors Cost Reply totals for Software and Hardware should match the Software and Hardware totals provided in the Vendor’s BOM response. Using the electronic BOM templates provided please provide the appropriate information on the hardware and software components of your proposed solution. Vendor Response:

We have attached updated cost templates in the requested format. Please note that this submission includes the miscellaneous corrections including the correction of an error/inconsistency in the IRR #2 submission where the cost provided for three software products was shown on the original proposal BOM detail list, but was not shown on the standalone option BOM detail.

In the previous version of the cost sheets, there were separate line items for initial purchases versus renewals/upgrades. In IRR #2, we put all software maintenance costs including first year maintenance in the lines labeled renewals and upgrades in the cell corresponding to the month when the maintenance expenditure was made. The new IRR #3 restructured BOM does not distinguish between initial purchases and renewals/upgrades. In the new Cost sheets, we include the total of both purchases and maintenance for item expenditures associated with the phase, environment, and time period. To enable the Department to reconcile the detail in the BOM with the totals in the Costs sheets, we have included supporting hardware and software total sheets


within the workbook that contain pivot tables that total the detailed purchases and maintenance expenditures.

Note: In the BOM sheet for the column labeled “Licensing Renewals Price (per License)” we included the license renewal cost for first year maintenance. We anticipate maintenance cost increases of 3% per year, except for ASW software products which have an expected increase of 0%. Our overall cost sheets reflect this, but there is no way to reflect this on the BOM detail lines. For this reason. We have included supplemental columns that show anticipated maintenance costs for each item by month.

The “Proposed Price per License” that we have provided is based on our alliance relationships and pre-negotiated discounts Accenture and the vendor’s have agreed via our global alliance relationships or our North American alliance contracts. In most of these cases (i.e. Oracle) the pricing we have provided is BETTER than our standard discounts (35% off list) outlined in our alliance agreements.

We were not able to populate the “Most Favored Nation per License” fields with pricing from our suppliers for any proposed product that reflects a Most Favored Nation (MFN) price per license. In most situations, vendors are not able to tell us what pricing they are giving to other partners/customers. Generally, the pricing listed here for Provider’s products reflect the uniqueness of the work contemplated for the Project to be completed under the Final Agreement and are not readily comparable to other Projects or other Customers that may require a different product mix under other contracts or contract terms.

2.7 ACCESS FLORIDA SYSTEM REPLACEMENT - PHASE 3 REQUIREMENTS Vendor Instructions


In the Accenture response to IRR 1 - Section 2.3 – Question 4 it states: “For Medical applications submitted from ACSSP that do not pass MAGI eligibility rules and Federal Data Hub verifications, the application will be passed to the FLORIDA system with an indicator that the MAGI rules apply to the application and a reason the application did not completely pass MAGI eligibility determination and/or Federal Data Hub verifications. Based on DCF policy in business process flows, workers would review and act on cases with specific reason codes and complete eligibility processing decision making in the FLORIDA system.”

There will be numerous instances where the household’s information for MAGI cases must be updated upon discussion with the customer or upon receipt of documentation of information different from that submitted on the application initially. It is the Department’s understanding that Accenture’s current proposed architecture would not connect the MAGI rules component to the Florida system in a way that would allow for the automatic MAGI and non-MAGI reprocessing of an updated application.

ACCESS Florida currently supports the ability to make application updates in one system without dual entry. This is a requirement for the new system as well (including Phase 3). In other words when updating an applicant’s household data, the worker must be able to resubmit the data for eligibility determination (MAGI included) in one system. Please clarify that this requirement is met and how it is met, or provide an alternative architecture solution that would meet the Department’s requirement.

Please provide any net cost impact that this has on the vendor’s proposal (by phase).

Vendor Response:

The requirement for workers to be able to resubmit the data for eligibility determination (MAGI included) in one system is met by our solution and can be implemented in a variety of different configurations. We would expect the Department’s preferences and input from business and Legacy O&M support would factor in the selection of the specific alternative to be used.

A significant advantage of our service-oriented architecture (SOA) based solution is the architectural capabilities that enable integration and reuse of business processing logic and system components. By using our APSP SOA solution, the Department is able to assemble and reuse discrete system processing capabilities in new ways. This ability gives the Department the flexibility to change processing as required or as more innovative approaches are identified. There are three foundational architectural capabilities that are implemented as part of Phase 3 that enable our solution to meet the requirement of resubmitting data for eligibility determination (MAGI included) in one system.

Enterprise Service Bus (ESB)/ Integration – Using the Accenture Public Service Platform (APSP) architecture, the ESB and integration capabilities of our solution enable secure information exchange across system, organizational and technology boundaries. The ESB assists systems to exchange data and take advantage of processing services regardless of the source or target system or platform.

Rules Engine – Using the APSP architecture, the Oracle Policy Automation (OPA) rules engine can be called as a web service. The rules engine web service does not care whether the client data needed to make an eligibility decision originated from a client entered


application in the Accenture Citizen Self-Service Portal (ACSSP) portal, from data that originated from the Insurance Exchange or data that originated from the FLORIDA system.

Business Process Management (BPM) – Using the APSP architecture, we are able to configure and perform business processing flows that consist of both system and worker performed tasks. The business process flows perform a sequence of discrete processing activities which might include calling the ESB for data, running the rules engine or running other processes.

These three capabilities together are the core of our SOA solution that create tremendous flexibility to adapt to new or changed processing needs of the business.

Our Phase 3 solution implements many discrete eligibility determination capabilities provided by our APSP and ACSSP solution that can be reused to address Department requirements:

1. Inbound application data interface – This interface receives application data collected from another source (e.g. Insurance Exchange) and starts the business process flow to determine eligibility.

2. File Clearance request – This outbound request checks an external source (e.g. a common client index or legacy system) to determine if the requesting person already exists. The results of the request could optionally be used as a starting point for data collection.

3. No Touch Application Business Process Flow – The application flow is driven by the business process engine. For applications where all data has been collected (e.g. by an external Insurance Exchange or legacy system), the business process flow would treat the data collection task as complete.

4. Verification Service– Verifies information provided on eligibility transactions (e.g. check provided data against the Federal Data Hub).

5. Rules Engine and Eligibility Rules – Calculates eligibility for the requested program(s).

6. Correspondence Service – Creates correspondence and notices related to eligibility decisions.

7. Integration to Legacy System – Used to push eligibility data to legacy system of record

These components are highlighted on the Phase 3 processing swim lane diagram below.


Phase 3In

terf

ace

sA

BM

SA

CC

ES

S F

LO

RID

AA

CS

SP

/ A

PS

P

Yes

Yes

No

Yes No No

Additional

Program

MAGI Processing

Insurance

Exchange

Process Data from

Application and

Interfaces

Federal Data HUB

Existing

Medicaid

Eligibility?

Potentially

MAGI eligible?

Check Existing

Eligibility

Route

SNAP / Cash

Other

Medical

Application

Additional

MAGI

Processing

Application

Healthy Kids /

CHIP

(Existing

Eligibility)

File Clearance /

Check Existing

Determination(s)

This workflow depicts a scenario in which case an application could be for multiple programs with

a no-touch processing for MAGI processing. It is not intended to cover all possible scenarios

only the most likely. Some steps such as additional processing of verifications or processing of

non-MAGI programs have been condensed for simplification.

Route

MAGI

CHIP

Eligible

Result

Accept for Eligibility

Processing

Non-MAGI Programs

Required

Verifications

Confirmed?

Application

Received in SSP

MAGI Eligible

Result No Touch

Processing

Service Call to

HUB and Other

Interfaces for Data

Get/Verification

Additional Program

Requested or

MAGI processing

needed?

Run Rules Engine

EDBC with MAGI

CHIP Rules

Generate NOA

Non MAGI

Types

Application from

Insurance

Exchange IRS

(Taxable

Income)

DHS

(Non US

Cit/ID

Status+ Date

of Entry)

Display

Program

NOA for

MAGI

CHIP

PUPS

(Incarceration)

CHIP Eligible

Route to Healthy

Kids

SSA

(Name, DOB,

SSN,

US Cit/ID)

1

5

42

6

Enterprise Service Bus7

Business Process Management3

Overview of Phase 3 Capabilities

There are many viable alternatives and variations to those alternatives that address the requirement of being able to resubmit data from a single system. Below are three different alternatives that include a description of the approach, pros and cons, and cost impact. We are able to further discuss these alternatives, variations to these alternatives, and other options.

Alternative 1 – Call Rules Engine from FLORIDA

Description: When the worker wants to evaluate eligibility (for example after a group of changes have been made in the FLORIDA system), the worker would initiate a request from within the FLORIDA system. That request would assemble all client information needed for rule based eligibility determination and pass the information to the ESB. Passing information from FLORIDA to the ESB could be done in a variety of different ways (via MQ, batch, etc.) leveraging existing ACCESS Florida integration capabilities. The ESB would act on the request and call the web service that invokes the new rules engine. The ESB would pass back the results of the rules engine web service to FLORIDA. The FLORIDA system would then act on the decision information provided by the rules engine web service based on business / policy requirements.


Phase 3In

terf

ace

sA

BM

SA

CC

ES

S F

LO

RID

AA

CS

SP

/ A

PS

P

Yes

Yes

No

Yes No No

Additional

Program

MAGI Processing

Insurance

Exchange

1

Check Existing

Eligibility

IRS

(Taxable

Income)

Service Call to

HUB and Other

Interfaces for Data

Get/Verification

Healthy Kids /

CHIP

(Existing

Eligibility)

Existing

Medicaid

Eligibility?


Processing

Non-MAGI Programs

Potentially

MAGI eligible?

Display

Program

NOA for

MAGI

CHIP6

Application from

Insurance

Exchange

Run Rules Engine

EDBC with MAGI

CHIP Rules

Required

Verifications

Confirmed?

MAGI Eligible

Result No Touch

Processing

Additional Program

Requested or

MAGI processing

needed?

SSA

(Name, DOB,

SSN,

US Cit/ID)

File Clearance /

Check Existing

Determination(s)

PUPS

(Incarceration)

Application

Received in SSP

Business Process Management

Route

MAGI

CHIP

Eligible

Result 2






Federal Data HUB

Generate NOA

Non MAGI

Types

Route

SNAP / Cash

Other

Medical

Application

DHS

(Non US

Cit/ID

Status+ Date

of Entry)

Additional

MAGI

Processing

Application

Process Data from

Application and

Interfaces

CHIP Eligible

Route to Healthy

Kids

7

4

3

5

Phase 3 – Alternative 1 – Call Rules Engine from FLORIDA

Pros:

FLORIDA workers stay in one system Minimal impact on ACSSP COTS portal and MAGI application processing

Cons:

Would potentially require FLORIDA to call or duplicate the MAGI processing that ACSSP provides (Verification, Correspondence, Notices, …)

Would need to verify information needed for determination can be passed from FLORIDA system (e.g., MAGI household composition)

Costs:

FLORIDA system would need to: 1. assemble all client information needed for rules engine determination 2. initiate the request that passes data to the ESB and rules engine service 3. receive and act on the rules engine determination decision from ESB 4. handle other processing performed by ACSSP before/after eligibility step


Replacement System would need to: 1. Assist with ESB information exchange transaction and transformation to invoke

rules engine as a web service if FLORIDA cannot directly call a web service

Alternative 2 – Pull Data from FLORIDA with File Clearance Service

Description: This option would enhance the file clearance check performed by ACSSP to pull updated data from the FLORIDA system. Clients or workers could re-determine eligibility by starting another application and using the standard application process. The file clearance would pull updated data from FLORIDA that would be populated in client’s application dataset. The updated data would be run through verification checks, rules engine determination and decision processing as if it were a new application. The updated decision information would flow to the FLORIDA system using the same path as other applications. The FLORIDA system would receive the updated decision and workers would process the application in the same way other MAGI determinations are processed.

Phase 3

Inte

rfa

ce

sA

BM

SA

CC

ES

S F

LO

RID

AA

CS

SP

/ A

PS

P

Yes

Yes

No

Yes No No

Additional

Program

MAGI Processing

Insurance

Exchange

Enterprise Service Bus7

Application from

Insurance

Exchange

1

MAGI Eligible

Result No Touch

Processing

Run Rules Engine

EDBC with MAGI

CHIP Rules

Federal Data HUB

Existing

Medicaid

Eligibility?

File Clearance /

Check Existing

Determination(s)

Process Data from

Application and

Interfaces

2

Check Existing

Eligibility

Route

SNAP / Cash

Other

Medical

Application

SSA

(Name, DOB,

SSN,

US Cit/ID)

PUPS

(Incarceration)

Additional

MAGI

Processing

Application

Display

Program

NOA for

MAGI

CHIP

Application

Received in SSP

Additional Program

Requested or

MAGI processing

needed?

Generate NOA

Non MAGI

Types

IRS

(Taxable

Income)

Service Call to

HUB and Other

Interfaces for Data

Get/Verification


Processing

Non-MAGI Programs





DHS

(Non US

Cit/ID

Status+ Date

of Entry)

Potentially

MAGI eligible?

Required

Verifications

Confirmed?

CHIP Eligible

Route to Healthy

Kids


Route

MAGI

CHIP

Eligible

Result

Healthy Kids /

CHIP

(Existing

Eligibility)

4

3

65

Phase 3 – Alternative 2 – Pull Data from FLORIDA with File Clearance Service


Pros:

No impact on ACSSP COTS portal MAGI application processing Low impact on FLORIDA system and user screens in FLORIDA

Cons:

Potentially new or more complex interface in FLORIDA to pull client data Workers use ACSSP for MAGI applications Would need to check that FLORIDA system could merge transactions that are

submitted multiple times and determine any downstream processing concerns (i.e., BI).

Costs:

FLORIDA system would need to: 1. assemble all client information needed for rules engine determination 2. respond to web service requests for existing client information in FLORIDA 3. handle reapplication requests including recognizing and merging the request to

the same application 4. validate processing statistics are not impacted

Replacement System would need to: 1. confirm client or worker identity prior to exposing updated information in

pulled from FLORIDA

Alternative 3- Push Data from FLORIDA through Inbound Application Interface

from FLORDA to push data back into the portal and kick off a no touch workflow that automatically runs eligibility and sends the application (if approved) to FLORIDA system (recommended)

Description: When the worker wants to evaluate eligibility (for example after a group of changes have been made in the FLORIDA system), the system would initiate a request from within the FLORIDA system. That request would assemble all client information needed for rule based eligibility determination and pass the information to the inbound application interface. This could be the same interface used for Insurance Exchange or a clone using the same inbound information exchange format. The updated application data would flow through the application eligibility determination work flow in no-touch mode (like an application that originates from the Insurance Exchange). The workflow would send the resulting decision or alert to FLORIDA system using the same integration channel that is established for user entered application decisions. The FLORIDA system would receive the updated decision and workers would process the application in the same way other MAGI determinations are processed.


Phase 3In

terf

ace

sA

BM

SA

CC

ES

S F

LO

RID

AA

CS

SP

/ A

PS

P

Yes

Yes

No

Yes No No

Additional

Program

MAGI Processing

Insurance

Exchange

1

Route

MAGI

CHIP

Eligible

Result

Potentially

MAGI eligible?

IRS

(Taxable

Income)

Run Rules Engine

EDBC with MAGI

CHIP Rules

Additional Program

Requested or

MAGI processing

needed?

File Clearance /

Check Existing

Determination(s)

2

MAGI Eligible

Result No Touch

Processing

Required

Verifications

Confirmed?


Process Data from

Application and

Interfaces





Healthy Kids /

CHIP

(Existing

Eligibility)

Generate NOA

Non MAGI

Types

Application

Received in SSP


5

Existing

Medicaid

Eligibility?

Federal Data HUB

Check Existing

Eligibility


Processing

Non-MAGI Programs

PUPS

(Incarceration)

7

DHS

(Non US

Cit/ID

Status+ Date

of Entry)

Additional

MAGI

Processing

Application

CHIP Eligible

Route to Healthy

Kids

SSA

(Name, DOB,

SSN,

US Cit/ID)

Application from

Insurance

Exchange

Route

SNAP / Cash

Other

Medical

Application

Display

Program

NOA for

MAGI

CHIP

Service Call to

HUB and Other

Interfaces for Data

Get/Verification

6

4

3

Phase 3 – Alternative 3 – Push Data from FLORIDA through Inbound Application Interface

Pros:

Minimal impact on ACSSP COTS portal MAGI application processing Low impact on FLORIDA system and user screens in FLORIDA

Cons:

Potentially new outbound interface from FLORIDA to push client data updates Unknown potentially longer elapsed processing time for complete the entire work

flow than making discrete calls per service Would need to check that FLORIDA system could merge transactions that are

submitted multiple times.

Costs:

FLORIDA system would need to: 1. assemble all client information needed for rules engine determination


2. push information to an inbound interface that would be processed by ACSSP 3. handle reapplication requests including recognizing and merging the request to

the same application 4. validate processing statistics are not impacted

Replacement System would need to: 1. Confirm inbound application interface could support requests from different

source systems (FLORIDA and Insurance Exchange) without impacting reports, statistics, and operational considerations

Recommendation

Of these three alternatives described, we would recommend Alternative 1 or 3. Alternative 1 would expose FLORIDA with more discrete and interactive capabilities. Variation of Alternative 1 could be to perform a service that is a composite process that includes verification, eligibility determination and correspondence. Alternative 3 is the recommendation that would probably require the least amount of change to FLORIDA and the Replacement system.


INTERIM REVISED RESPONSE (IRR) #3 ADDENDUM

A. ACCESS FLORIDA SYSTEM REPLACEMENT – REMOVE SCOPE REQUIREMENTS Vendor Instructions The table below has been provided to help identify system requirements that are no longer required by the Department as part of this ITN. The vendor should remove the two items in this table (“PM TRN 1000” and “PM TRN 1040”) from their project scope and update their cost and project plans accordingly using the cost forms provided with IRR3. The vendor’s should also use this opportunity to provide overall price reductions to the Department if possible, keeping in mind that this may be the last opportunity to provide reductions in price.

Vendor Response:

Accenture reviewed the requirements to be removed from scope and adjusted our costs associated with their removal. The attached pricing sheets have been updated to reflect their removal.


B. ACCESS FLORIDA SYSTEM REPLACEMENT – SCOPE REQUIREMENTS

CLARIFICATION Vendor Instructions The table below has been provided to help clarify the requirements for “PM TRN 1060.” The vendor shall update their project scope, pricing and project plans accordingly.

Vendor Response: Accenture reviewed the clarification to this requirement and adjusted our costs associated with the change. The attached pricing sheets have been updated to reflect the clarification.

C. ACCESS FLORIDA SYSTEM REPLACEMENT – PROJECT PLAN AND SCHEDULE Vendor Instructions The vendor should review and update their project schedule to reflect the Standalone phases. Separate project schedules should be submitted for each of the three Standalone phases. Vendor Response: We have reviewed and updated our project schedule to reflect the Standalone phases and have submitted separate project schedules for each of the three Standalone phases showing condensed schedules based on the scope, approach, phase start dates, and proposed cost. As discussed in our orals sessions if further reductions in schedule or cost are desired then the levers of scope, approach and cost can be adjusted to fit the Department’s schedule or cost constraints. Our current approach seeks to maximize overall value delivered based on the requested requirements. If the Department’s available DDI funding is limited, we are able to factor in that constraint and provide a different approach, solution, cost and level of value that maximizes value within the Department’s DDI funding constraint. These schedules are submitted as Microsoft Project files and include tasks, hours, duration, start date, finish date as well as show the most condensed project schedule possible for each of the three phases assuming the standalone start dates outlined in prior IRR submissions. The project schedule also includes fully loaded resource usage, assignments and work hours.

Date post:	23-May-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

ACCESS Florida System Replacement · ITN # 03F12GC1 - ACCESS FLORIDA System Replacement Page 1...

Documents