Technical Volume Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal 7-1

Transcription

1 7.0 Implementation and Integration Services We have focused our implementation and integration activities on the goal of being 100% ready for deployment day. Our implementation approach includes collaborative implementation planning and preparation with state and regional offices. Our Presumptive Eligibility Pilot models statewide implementation, and we bring support processes and procedures for the full solution deployment that would minimize disruption for the services and provide an effective transition to the K- MED system In this section of the proposal, the Proposer shall describe their approach in detail to implementing the full solution requested by the State in accordance with the approach Our experienced team provides a low-risk implementation approach that minimizes user disruption and facilitates a smooth transition Integration of implementation support, training, conversion, documentation, help desk, and readiness activities All organizational units involved throughout implementation Accenture implementation resources dedicated to each region to address specific assistance needs Experience from many large scale systems implementations, including California C-IV, Texas IMPACT, Idaho IBES, and other health and human services projects Implemented California eligibility system without increasing eligibility error rates in the counties outlined in RFP Section 2.6 Implementation and Integration Services Scope. Submission of an approach in accordance with RFP Section 2.6 is mandatory. If the Proposer believes that another viable approach to meet the requirements of this RFP exists, the Proposer may describe any such alternative approaches in TECHNICAL PROPOSAL TAB 14 ALTERNATIVE APPROACHES (see RFP Section ). Solution Overview and Approach to Implementation Our proposed solution is a state-of-the-art automated medical eligibility system for the Kansas Health Policy Authority (KHPA). We are proposing a fully integrated eligibility system with an online application and presumptive eligibility screening tool that increases customer satisfaction as it provides higher availability, reduces keying errors, and expedites the eligibility determination process. This is the right solution for Kansas. It provides the State with more flexibility, more accessibility, better reporting capabilities, and it fosters more consistent and less error-prone processes. In alignment with KHPA s business goals, the proposed solution would open new service channels, improve accuracy, facilitate staff management, support a mobile or out-stationed workforce, improve customer services, and assist in delivering cost-effective services. Such were the goals achieved by the implementation of the C-IV Solution in California. California has a mobile workforce and C-IV s great accessibility and availability enables workers to access the application and the cases they work from any location; it also gives them access to centralized information. Additionally, the customer portal, C4Yourself, provides availability to customers who want to apply for benefits or simply check on the status of their application. In order to help you achieve your goals, we are proposing to leverage Accenture s experience and methodology in large multi-site deployments for the implementation of the K-MED Solution Blueprint. We leverage our methodology, which has been used to deliver thousands of projects across hundreds of clients ranging from Fortune 500 companies to government agencies. The Accenture Delivery Suite (ADS) is the framework we use to deliver solutions and services, consistently, and collaboratively. The ADS applies standard proven methods, tools, and 7-1

2 architectures resulting in predictable and reliable delivery. It also provides a standard approach to use across the entire engagement; therefore, achieving greater efficiencies in activities ranging from project management to development to operations. Our Accenture Delivery Methods (ADM) supports all the global client work we do and are based on more than 30 years of real-world experience. Accenture uses ADM to successfully manage and implement complex and large-scale programs. We successfully use it on all our complex delivery projects, including the many projects for Health and Human Services and public service clients globally. We will use ADM as a guide and will customize the project management tools and processes in our methodology based on KHPA s needs. As illustrated in Figure 7-1, ADM is a one-stop shop, integrating methodology with tools, templates and our Knowledge Exchange of project experiences and recommended practice. We brought this right approach and solution to California, where we implemented, maintained and currently operate the C-IV system. This dynamic, outcome-oriented system provides an integrated, user-friendly, automated system to manage the increasing complexity of the Medicaid eligibility determination, public assistance and employment programs for approximately 2 million Californians. Our approach resulted in a system that is significantly easier and less expensive to maintain than comparable systems for the other two California consortia. We have also collaborated with Texas Family and Protective Services (FPS), where we implemented the Information Management Protecting Adults and Children in Texas (IMPACT) and Mobile Protective Services (MPS) program. We worked closely with FPS to define how to better serve their needs and meet their expectations. We developed a great working relationship with our client; they were excited to see the implementation completed and were active participants in our success. For example, the regional directors actively participated in creating engagement and providing support. This fostered ownership and helped us lower the costs of implementation. The benefit for KHPA is that we have captured and transformed these and other experiences into a set of processes, tools and assets and we bring that accumulated knowledge and toolset to our K-MED project efforts in the form of our hand-selected team, Accenture Public Service Accenture Delivery Methods (ADM) Accenture Delivery Methods Focuses on: Delivering quality, effectiveness, and success Plan Analyze Design Build Test Deploy Methodology provides: Full integration between application system engineering, organizational change management, and business process improvement to reduce risk and to deliver quality solutions Standardized practice across all teams promote consistency in project delivery Improved reliability, quality, and predictability of product and service delivery through CMMI Level 4 practices Application Technical Architecture Training and Performance Support Service Introduction Configurable project templates that improve productivity and accelerate project delivery and schedules T T T T T T T End-to-end integration facilitates business requirements traceability and verification Adaptability to client environment to enable cross-agency and cross-vendor collaboration T Holistic suite of methods, tools, and policies to guide project delivery Figure 7-1: Our solution proposes the use of ADM as our methodology, which promotes standardization and a quicker and less risky implementation Transition Point K-MED

3 Platform (APSP), and leading industry practices. Our proposed K-MED solution consists of a hybrid of COTS and transfer based components that would bring KHPA the technology and proven business model required to successfully meet your objectives. We propose three main components as part of our solution. First is the Accenture Public Service Platform (APSP), a service oriented architecture, which is the technical foundation that would support the day to day functions performed by users in the K-MED solution. Second, our APSP Public Assistance Portal component that is based on components of the California C-IV and Idaho IBES solutions. This functionality is the integration of eligibility determination and delivery of services and benefits, built on a well-defined and successfully adopted business model. Finally, the APSP Self-Service Portal that is based on the California C4Yourself Public Portal, which provides the customers a portal to access information, log e- applications, and review their benefits. We propose to implement this functionality in two different phases. First, we would deploy the Presumptive Eligibility tool, Online Intake Application, and Self-Assessment Tool. We propose conducting a Pilot Implementation before the state-wide deployment of this functionality 45 days prior to Phase One implementation, which is scheduled for 11 months from the contract start date. The second proposed implementation would be of the full K-Med solution, 21 months from the contract start date. The Right Team In addition to leveraging Accenture s standardized methodologies and tools, we bring a team with an unrivaled track record in health and human services, specifically in eligibility services. Our team brings the right experience to support the goals and vision of KHPA. We also bring successfully tested industry practices that lower risk while adding value to the effort. Our team has a thorough understanding of the State and KHPA s vision for access, quality and efficiency, affordability and sustainability, promotion of wellness, stewardship, and public awareness for Kansans in need. Our team understands your business and can support you in delivering your goals for this project and setting you up to manage future challenges and opportunities. The combination of our team, our assets, our approach, and our shared vision of ongoing growth and development makes us the best prepared vendor to helping KHPA achieve success for this project and to support the State s mission to develop and maintain a coordinated health policy agenda. Our Project Manager, Troy Myers, has over 15 years of health and human services project management experience and is a certified Project Management Professional (PMP) by the Project Management Institute. In addition to them, we propose a team that has demonstrated transfer and COTS solution implementation experience. We are bringing eligibility as well as indepth healthcare experience and technical expertise that provide for a less risky implementation. Our team brings over 133 combined years of IT experience, 92 years of health and human services experience, 27.5 years of medical eligibility determination experience and over 124 combined years of delivering large, complex systems, on time, on budget and to the satisfaction of the customer. For Kansas, this means reduced risk. Additionally, we know Kansas. The Accenture team has participated in many technology initiatives for different agencies in the State of Kansas. For example, we successfully completed the implementation of a new statewide financial system. Our solution was selected as the greatest value and lowest risk choice for software and implementation services for the new financial system. 7-3

4 In addition to our work implementing this financial management system, we are also supporting the State of Kansas in its strategic initiative to transform the way it delivers customer service for its Department of Motor Vehicles (DMV) functions. The DMV system we are implementing provides the authoritative record of data; it will enable service enhancements, and reduce errors, fraud and complaints. We are also helping our client, the Kansas Department of Revenue (DOR), re-align its business processes around a customer-centric model supported by a single, integrated system. Our experience and history working with the different agencies of the State of Kansas and the many initiatives to support development that provides platforms for future growth of Health and Human Services technological advances help us understand the general needs of the State, and to differentiate the particular business needs and requirements of the different agencies with which we work. We are committed to KHPA and its vision and will help you deliver quality healthcare for Kansas residents through the implementation of a modern and integrated medical assistance eligibility system. We want to deliver quality results for Kansas. We want to be part of your mission of serving Kansans in need. We believe we can realize this mission and deliver the expected results with the implementation of our K-MED Solution Blueprint. We would be proud to state that we helped provide better access to care and that together with the State we implemented a solution that creates infinite opportunities for the future of healthcare education and engagement of Kansas residents. As illustrated in Figure 7-2, in addition to our Kansas specific experience, the Accenture team has demonstrated success in the implementation of systems of similar size and scope in many states and worldwide. California C-IV Consortium Idaho Department of Health and Welfare Idaho Benefits Eligibility System (IBES) New York City HHS Connect Texas Information Management Protecting Adults and Children in Texas (IMPACT) New York Office of Children and Family Services Connection Large State MMIS Project Georgia PeachCare for Kids The Accenture Team Delivers Demonstrated Experience Successfully implemented an easy-to-use welfare system for over 6,500 users using a staggered schedule Implemented a flexible, cost-effective case management system. It equipped the Department to manage its growing caseload without the need for additional staff. The new capabilities delivered through IBES meant that employees can now focus more attention on their clients, and the Department now has the tools to achieve high performance Successfully implemented a case management system to improve access to information, break information silos and facilitate data sharing between Agencies, coordinate Agency practices, improve case management, and transform the delivery of health and human services in New York City. We also implemented a user-friendly web portal that enables 1.5 million NYC residents apply for 35 benefit programs across 15 agencies Successfully implemented IMPACT and Mobile Protective Services (MPS) solutions, which are used by over 7,000 caseworkers on a daily basis to manage their caseload and time Implemented the State s Automated Child Welfare Information System for 20,000 caseworkers with up to 5,000 concurrent sessions Successfully implemented a system that processes $13 billion in Medicaid claims per year PSI created the nation s first online SCHIP application. Today 69% of 7-4

5 The Accenture Team Delivers Demonstrated Experience Program (PSI) total applications are received online. PSI has consistently delivered a high level of customer service in Georgia and has partnered with the Department of Community Health on many innovations that make the Georgia PeachCare program a national model for other CHIPs Figure 7-2. Our wide variety of experience in health and human service projects coupled with our proven approach to project implementation provides for a less risky implementation of K-MED Advantage of implementing a hybrid transfer and COTS system In addition to our team s relevant experience and access to leading practices, we bring to you the right solution. Our K-MED Solution Blueprint is built on the Accenture Public Service Platform (APSP). KHPA would greatly benefit from our K-MED Solution Blueprint as APSP is the culmination of decades of public service and enterprise architecture projects. Additionally, our solution integrates proven components from numerous public service integration and architecture initiatives including the C-IV and IBES solutions. Figure 7-3 illustrates the components of the K-MED Solution Blueprint and how it provides a platform for future KHPA integration. We bring a solution built specifically for low-risk and low-cost implementation that is efficient and easy to maintain. Three key factors make our proposed solution the right alternative for KHPA and the K- MED Project. First, Accenture Public Services Platform (APSP) is the low risk option. The proven business functionality in APSP combined with our industry leading delivery methodology has resulted in on time on budget successful implementations in projects in California and Idaho as well as many other projects around the globe. Second, our proposed solution is designed to minimize disruption to daily operations, and impact on users and participants. We combine our extensive learnings and experience from similar projects with an implementation strategy tailored to KHPA requirements that focuses on the needs of your user community. By tailoring our implementation approach to the needs of the user community in Idaho we were able to go live without any increase to processing times or disruption of service delivery.. The third key factor that makes our K-MED Solution Blueprint the best solution is that it provides measurable value. Our proposed solution maximizes the State s investment by delivering intuitive robust functionality that supports your requirements today and by provides significant flexibility for future enhancements and expanded capabilities. The State of California implemented a significant policy change for TANF and Food Stamps. The flexibility of the C-IV Solution enabled the implementation of this policy change on time and at a cost of approximately $800,000, compared to two other competing systems that were both delayed in their implementation of the same policy change at a cost of $6,000,000 for one system and $8,000,000 for the other. This comparison demonstrated the ease and cost effectiveness of the C-IV Solution to accommodate ever-changing policy and legislative rules, and is representative of our approach to system design and development. 7-5

6 Proven componentized application allows for flexibility and future integration Integrates core set of eligibility business functions Transfer system proven is California and Idaho SOA with flexible rules engine Built specifically for HHS clients Minimizes risks associated to custom builds Open standards and highly scalable Incorporates efficient interfaces and interoperability for future collaboration with other entities programs C-IV/Idaho Functionality K-Med Solution Intuitive and easy to use Self assessment and online applications Facilitates staff management Increased system availability supports mobile workforce Improves customer service Assists in delivering cost-effective services Flexibility and accessibility Better reporting capabilities Promotes consistent and less error-prone processes Opens new service channels Improves determination accuracy and efficiency KHPA s vision and goals delivered Focus on Promoting Health and Wellness with low risk, scalable SOA foundation embraces future changes, including the Affordable Care Act Portal services bring Access to Kansans to increase outreach Shared Business Services provide reusable, common business functions based on best practices and our shared knowledge so that KHPA can emphasize positive outcomes with Quality and Efficiency in Health Care Integration of policy management is a vehicle for Stewardship to administer benefits with integrity, responsibility, and transparency SOA structure promotes seamless and sustainable information exchange to provide Kansans Affordable and Sustainable Health Care 2 K-MED Figure 7-3. Our solution delivers is low risk, minimizes disruption to users, and provides measurable value for KHPA while supporting your vision and goals The IBES solution at the State of Idaho is a great example of how we leveraged our APSP framework, transferred eligibility functionality, and were able to deliver strategy low risk, high value solution that minimized disruption to the user community and maximized the State s investment. The solution was a transfer of California s C-IV eligibility functionality. The new system, Idaho Benefits Eligibility System (IBES), replaced a 30-year-old eligibility system that could not be updated to accommodate new requirements nor support efficient administration of the State s health and human service programs. Working together with our client, we delivered the lowest cost implementation of a fully integrated eligibility system in the U.S. in the last 20 years. Additionally, the system s flexibility allowed us to quickly integrate CHIP functionalities to address Idaho s specific needs. The new capabilities delivered through IBES enable employees to focus more attention on the clients they serve and deliver timely and accurate benefits. Implementation and Integration services proposed in our approach This proposal explains our suggested approach, which will support a successful delivery of the K-MED solution. However, we go beyond just having a great methodology, we execute it. 7-6

7 We focus on all aspects of this implementation; the dependencies between them; the expected results of the different services and activities; and how we would accomplish them. We propose to manage the project using our standards and defined methodologies throughout the three major activities identified in the RFP, analysis, system development and ongoing operations. Furthermore, we work together with KHPA to incorporate our quality assurance standards and practices throughout the entire software development lifecycle. In the same fashion, and throughout the project lifecycle, we work with KHPA to enforce our security management activities applicable to the system functionality as well as to the project management. During the initial stages of the project, we collaborate with KHPA to validate requirements and define the application needs. This helps us identify system configurations. We also propose an integrated approach to testing, training and enterprise readiness as this supports knowledge transfer and a smooth turnover. We understand that an effective implementation hinges on attention to detail, on focusing on all the aspects of implementation and integration services. Our goal is to implement an application that answers to KHPA s business needs and supports its strategic goal of an integrated, customer-centric services model. The following sections provide details as to how we plan to accomplish this. Phased Implementation Approach As illustrated in Figure 7-4, we are proposing a phased approach to the implementation of the K-MED System. We believe that a multiple-release implementation minimizes business disruption and allows us to start deploying capabilities earlier. These capabilities begin reducing caseworkers workload and start satisfying some of the goals of the Kansas Access to Comprehensive Health (KATCH) program as it increases outreach and delivers a framework that KHPA and other agencies can leveraged to achieve common business functions. Self Portal K-MED System Pilot Go-Live Online Intake Application Self- Assessment Tool Presumptive Eligibility Tool Phase 1 Go-Live Phase 2 Go-Live Online Intake Application Self- Assessment Tool Presumptive Eligibility Tool Registration Caseload Management Case Review QA Cost Avoidance and Recovery Incorrect Benefits and Collections Hearings and Appeals PMDD Outreach and Notifications Workflow High Level Client Index and Inquiry Document Imaging Policy Management K-MED Figure 7-4. Our phased release implementation approach allows us to establish a foundation for key functionality quickly with minimal risk, so KHPA can realize benefits early in the project There are three implementation phases: Pilot, Phase One, and Phase Two. The first is a Pilot Phase. Based on relevant experience, we believe Kansas will be most successful implementing the portal functionalities first; moreover, we would suggest that KHPA considers an early deployment of these functionalities to a select group of locations only. The recommendation is to test deployment of this functionality in a pilot site, the Presumptive Eligibility sites, 45 days prior to Phase One implementation. Figure 7-4 identifies the functionality that would be deployed at this and the other go-lives. We would pilot the Presumptive Eligibility functionality piece of the K-MED solution at the current providers designated PE entities. Based on roles and security access, the PE functionality application would be available just to the designated users. Conversely, users would be able 7-7

8 to access just PE functionality. The PE functionality would enable providers to make Medicaid and CHIP determinations while the customer submits an application for full determination. Although this functionality later integrates with the full K-MED solution based on roles and security access KHPA can restrict access to only the PE functionality. On the other hand, if Kansas determines to expand PE privileges to other providers, the system is flexible enough to support the addition of new users. During the Pilot, we would also deploy the Online Intake Application and Self-Assessment tool. We would make this functionality available only at the PE sites, and it would be used as determined by KHPA. Use of the portal would be locked out for participants outside the designated pilot sites. Support for the pilot deployment would be provided in the form on online help and User Support Services. Phase One of the implementation approach parallels the functionality deployed during the Pilot Phase: Presumptive Eligibility tool, Online Intake Application, and Self-Assessment Tool. During this phase we would make the self-service functionality available to the general public through a publicly available website. We work with KHPA to determine how to best make the information collected available to the State for processing in the legacy system. We would also provide user support services to assist use of the portal functionality. Phase One of the implementation approach realizes the benefits identified for the Pilot Phase at a statewide and agency level. Additionally, Phase One Implementation further benefits KHPA as it would be an effective and efficient way of reaching Kansans who are currently uninsured. The Online Application tool is the building foundation to accomplish the HRSA grant goal of expanding coverage to residents who are currently uninsured. The deployment of an automated tool provides for quicker, and more accurate, data processing. In addition, self-service availability for clients reduces workload as it shifts the workload from traffic in the offices to traffic in the web. This phased implementation minimizes disruption to workflow by breaking the functionality that is deployed and needs to be learned by users. It eases the agency into the business processes and exposes the clients to the new way of doing business, thus fostering Kansas vision of connected health. Phase Two is the deployment of the full K-MED solution based on the requirements. At this time, and as illustrated in Figure 7-4, we would deploy all functionality needed to support medical assistance determinations. We are confident we could deploy the full K-MED System in 21 months from contract start date. In preparation of the full K-MED deployment, our team would work on completing several milestones to enable the implementation. For example, we work on completing the interfaces design and standards deliverable as well as the conversion files design and standards deliverable. We would also complete Operational Readiness Testing before Phase Two implementation. Additionally, we work on completing staff training just in time for them to apply their system knowledge in production mode. In order to support this deployment, we would work with KHPA to establish a robust postimplementation support strategy that guides users through the initial months of production in order to minimize disruption to work. We further describe this approach in the Post- Implementation Support Services section of this proposal. 7-8

9 Implementation Assumptions The State is providing going in assumptions regarding the delivery and implementation of the proposed solution. The proposed implementation approach must account for each of these preliminary assumptions. The following assumptions apply: 1. The Contractor will implement the K-MED System as a COTS solution or a state transfer from another state government, or a combination of state transfer packaged with COTS tools. 2. The Contractor will implement the K-MED System in three major Activities across three Phases within the specified timeframes as documented in RFP Section 2.3 and RFP Section The Contractor will implement the K-MED System in such a way that maximizes end user productivity and minimizes disruption of work. 4. The Contractor will implement the K-MED System in such a way to ensure that all system users are mentored, building their capacity to utilize and oversee the system. 5. The Contractor shall be responsible for developing and conducting staff training, as well as managing all logistics associated with that training. 6. The Contractor will ensure that User Support staffing will be bolstered during each deployment to provide the extra help needed to facilitate the increase of work to be accomplished. 7. The Contractor will ensure that all software product configuration activity shall be completed with KHPA personnel actively involved in configuring the system so that knowledge transfer is maximized. Figure 7-5 illustrates how we respond to the Implementation Assumptions as stated in the RFP. We further discuss these assumptions throughout this proposal. Implementation Assumption Our Approach 1. The Contractor will implement the K- K-MED is a hybrid COTS and transfer based system MED System as a COTS solution or a that has been successfully deployed and is state transfer from another state operational in Idaho and in 39 California counties government, or a combination of state This system is based on three components: the transfer packaged with COTS tools. Accenture Public Service Platform (APSP), the APSP Public Assistance Portal that is based on the California C-IV and Idaho IBES solutions, and the APSP Self-Service Portal that is based on the California C4Yourself Public Portal 2. The Contractor will implement the K- We deliver development, integration, implementation MED System in three major Activities and ongoing operational services for the K-MED across three Phases within the specified project in three major activities: Analysis, System timeframes as documented in RFP Development, and On-going Operations. Section 2.3 and RFP Section 2.6. Implementation of the system is done in three phases: Pilot Phase, Implementation Phase One, and Implementation Phase Two 3. The Contractor will implement the K- In order to prepare end users for the transition to the MED System in such a way that new system, we collaboratively work with KHPA to maximizes end user productivity and deliver enterprise readiness services and conduct minimizes disruption of work. training activities. This provides users a level of familiarity and comfort with the new processes and application We implement a post-implementation support structure to support end users as they transition to the new application 4. The Contractor will implement the K- KHPA personnel learn working side-by-side with 7-9

10 Implementation Assumption MED System in such a way to ensure that all system users are mentored, building their capacity to utilize and oversee the system. 5. The Contractor shall be responsible for developing and conducting staff training, as well as managing all logistics associated with that training. 6. The Contractor will ensure that User Support staffing will be bolstered during each deployment to provide the extra help needed to facilitate the increase of work to be accomplished. 7. The Contractor will ensure that all software product configuration activity shall be completed with KHPA personnel actively involved in configuring the system so that knowledge transfer is maximized. Our Approach Accenture teammates Our approach facilitates knowledge transfer and builds the confidence of the KHPA employees while at the same time, completes critical project work activities We provide the analysis, design, development, delivery and evaluation of K-MED training Training focuses on how to use the K-MED System to perform job duties We deliver training leveraging a variety of delivery methodologies and avenues Our training plan would also include our approach to managing training facilities, pre-requisites and other logistics such as scheduling We provide User Support Services beginning with the Pilot Implementation Phase During each deployment, end users have access to a variety of tools and methods, such as help desk services, online help and job aids, refresher user training, sandbox training environment, that facilitate users tasks in production Our knowledge transfer approach focuses on building KHPA s capabilities starting on day 1 We would implement a program that promotes working alongside with KHPA personnel in order to enable them to learn-by-doing and immediately apply their newly developed skills Figure 7-5. Our implementation approach responds to all implementation assumptions 7-10

11 7.1 Detailed of Services Provided In order to facilitate the State s comparison of Proposer solutions, the Proposer s response to this section of the RFP shall conform to the following format without exception System Development Methodology (SDM) Our experienced development team will use an open standards baseline solution, Accenture s CMMI Level 4 processes, and robust tools to build a high performance, maintainable and reliable K-MED Proposer shall propose and describe a system development methodology that is defined, documented, and repeatable. Building a maintainable, flexible K-MED requires a structured approach for predictable Our system development methodology provides a comprehensive delivery framework to meet KHPA future vision of integrated eligibility Experienced developers that supported the delivery of the transfer solution in California and Idaho Measurable and repeatable processes to achieve KHPA s objective of modernization of the medical assistance programs eligibility processes Methods and management practices enable Accenture s Public Service Operating Group to be the largest organization of its type to be supported by a CMMI Level 5 rating network of delivery centers Over 30 years invested in developing and executing implementation methodology Documented, repeatable processes and procedures that are compliant and consistent Best practices and requirements from selected industry standards delivery. It requires professionals who have mastered advanced component development and service oriented techniques. It calls for a judicious reuse approach that integrates APSP and commercial-off-the-shelf (COTS) components that fit and avoids those that require too much modification. During system development, we will work closely with KHPA resources not only to develop and deliver the best possible solution, but also to encourage KHPA s ownership of the final product from an early stage. Our process enables project team members and State stakeholders to identify, communicate, implement, document, and control changes in the documentation and systems environment. Our team would apply Accenture Delivery Methods (ADM) and guiding principles from our health and human service projects to develop components, services, and configuration items for K-MED that: Meet functional and technical requirements Scale for high performance and throughput throughout the development cycle Can be modified or extended in a straightforward fashion by future maintenance teams Support fix in one place by centralizing common, shared logic in a layered manner (business rules and workflow engines) Adapt to changes in requirements or business rules (e.g. prompted by new legislation) Integrate well with outside systems, both current and planned Follow industry, open standards The system development methodology we propose for the development of K-MED is a component of our Accenture Delivery Methods (ADM). Our K-MED Solution Blueprint methodology provides documented, repeatable processes and procedures that are compliant and consistent with industry standards and exceed SEI s CCM Level 4. Best practices and requirements from selected industry standards are incorporated directly into the ADM. Our proposed K-MED Solution Blueprint is a structured approach for predictable delivery that 7-11

12 leverages proven tools. The goals of our proposed software development methodology (SDM) are to reduce delivery risks, create measurable and repeatable processes, adhere to project management processes and confirm requirements are well defined and met by the project. As illustrated in Figure 7-6, we accomplish these goals through six major phases: Plan, Analyze, Design, Build, Test, and Deploy. The following section outlines these phases and the key activities performed. The teams that conduct these activities are integrated and always communicating and working with each other to provide a comprehensive solution. During each phase, we would mentor KHPA staff so they can participate in all activities of the different stages of the software development methodology and conduct knowledge transfer. Plan - During this phase, we would confirm the application s purpose with the stakeholders, resulting in a focus on the desired end-result Analyze This phase looks to confirm the application, technical architecture, and enterprise readiness requirements Design This phase analyzes and converts the high-level scope of work into a system design, which we validate against the State s business, technical, and enterprise readiness requirements. This is also the phase when we conduct the Conference Room Pilot (CRP) sessions Build The Build Phase produces a configured and working application, unit tested against the detailed technical design test conditions, using valid configuration data Test - The Test Phase would validate that the K-MED solution meets the State s design requirements. During the previous phase, Build, we would conduct significant testing on the system, and this phase would seek to demonstrate that the K-MED system meets KHPA s business requirements Deploy - During the Deploy Phase, we would create and deploy communication messages to prepare the user, employee, and vendor populations for go-live In addition to the tasks identified in Figure 7-6, using our software development approach, we leverage the APSP Public Assistance Portal and the SOA-based architecture of APSP to rapidly prototype and configure the APSP to KHPA processes. The combination of a configured APSP with new KHPA-based elements should result in a low risk, highly maintainable, state-ofthe-art K-MED that meets the specified KHPA requirements. Effectively, APSP and the fit/gap analysis serve as starting points that assist in configuration and development tasks. Plan Analyze Design Build Test Deploy Initial gap-fit analysis mapping Kansas requirements to APSP Refine/confirm solution blueprint Refine/confirm high-level requirements Analyze business processes Define application metrics Analyze integration solution Plan Product, Performance, UAT tests Define technical architecture Coordinate user interface designs Identify and design classes Design data conversion Select and design environments Build application components Plan, prepare and execute component test Start assessing deployment readiness Install and build environments Perform mock conversions Prepare and execute assembly test, product test, performance test, UAT Prepare for migration Perform ORT Set up deployment environment Convert data Support Production environment Migrate to production K-MED Figure 7-6. Our software development approach reuses requirements, design, components, and test artifacts from APSP to lower risk and expedite development 7-12

13 First, we use APSP components and architecture in developing a high performing K-MED prototype. This prototype is an effective means to demonstrate how we configure APSP to implement KHPA processes in K-MED. In addition, prototyping on the APSP with its new capabilities may provide KHPA ideas on process enhancements for the future. We will show the prototype during a Conference Room Pilot (CRP). The KHPA team would verify that the K-MED system implements KHPA processes correctly and meets requirements, as they would visually see those processes. By actually seeing the tailoring performed on the solution, KHPA users would get a much better idea that the result would meet their business requirements as opposed to just reading and reviewing design documentation. During these sessions, we would work with KHPA to verify requirements match and identify gaps. Our team would use the prototype during the CRP to validate that the prototype matches key State processes and to illustrate how gaps could be met. The use of the prototype would reduce the demand on line staff s time and lower the cost of development. Our approach would include customization and reuse, identifying where we would configure and change software. The fit/gap analysis would allow us to refine the initial KHPA requirements as specified in the RFP to a more granular level if necessary. After we complete the Requirements Analysis and Verification task, we would have an approved System Requirements Document and an approved Requirements Traceability Matrix (RTM). These would contain our baseline requirements. The proposal should identify certifications the Proposer has received, such as SEI CMM or CMMI assessments, the International Organization for Standardization (ISO) 900x certifications, the Institute of Electrical and Electronics Engineers (IEEE) Software Engineering Standards, or any other pertinent certifications. Through our many years of delivering quality products and helping clients become high performing organizations, we have been awarded or nominated for several recognition programs. We accomplished and maintain certification in many standardization organizations. Below is a list of some of Accenture s certifications: SEI CMMI: Accenture has one of the largest CMMI programs in the world. Our ADM supports the SEI s CMMI compliance, with model requirements built into the processes used globally. Our U.S. Public Services practice has achieved the SEI s CMMI Level 4. Furthermore, we have implemented CMMI across our Global Delivery Network, with over 90% of GDN employees working in Level 5 certified centers. International Organization for Standardization (ISO): Accenture s Quality Management System (QMS) is applicable to all work conducted by the company and has been reviewed and approved by the British Standards Institution (BSI) in accordance with the ISO 9001:2008 standard. The last assessments to verify compliance was in March 2010 and BSI granted maintenance of registration. Project Management Institute (PMI): Accenture is a Corporate Council Member of the PMI, project management s leading global professional association. MITA: The K-MED Solution Blueprint we are proposing is MITA level 3 compliant. National Information Exchange Model (NIEM): We were awarded the Best of NIEM Award in its inaugural year, 2009, for the information architecture and development work we did for NYC HHS-Connect client. Best of NIEM honors programs that demonstrate best practices and innovative solutions within complex legacy environments to effectively achieve results. 7-13

14 Figure 7-7 lists some of the awards we have received or been nominated for. Client Type of Work Award New York City ACCESS NYC Eligibility Screening Portal 2007 Citizens Budget Commission Prize for Public Service Innovation International Data Group s 2007 InfoWorld 100 Award Computerworld Honors Award Laureate award, Computerworld Honors Award State of C-IV Eligibility California Solution Georgia State GA SHINES Child Computerworld Honors Award Welfare State of Texas Texkat Katrina Best of Texas Award Best application serving the public Response State of Texas Mobile Protective Best of Texas Award Best application serving the public Services Solution Computerworld Honors Award Figure 7-7. Our human services clients are recognized for their leadership and innovative approach to meeting increased service demands Project Management Methodology Our project management methodology aligns to Kansas State project management policies. Our team will use comprehensive management plans and a successfully demonstrated methodology to seek to mitigate risk and improve the quality of the K-MED solution The Proposer shall describe its approach to managing the project, including the provision for a full-time, experienced Project Manager who will be accountable for all services and deliverables provided under the Contract resulting from this RFP, and who will work to ensure the on-time delivery and successful Our team has the experience, the know-how and the people to provide KHPA with the right project management solution that delivers low risk Our project management methods, refined over 30 years, have resulted in the successful delivery of hundreds of Health and Human Services projects Our team brings extensive Medicaid eligibility experience and capability proven through the implementation of many healthcare projects Our management team has previously worked together to successfully deliver largescale systems using our Accenture Delivery Methods deployment of a functioning system that meets the State s requirements and the successful ongoing operation of the solution. As part of its project management approach, the Proposer shall describe the project management tools, standards, controls, and procedures that will be utilized to create a proven, reliable process to deploy the system statewide. This section shall also include a brief description of the Proposer s approach for managing the project on a daily basis. Strong, collaborative project management is an essential element to the success of the K- MED Project, which is integral part of Accenture s overall approach to Project Management. We have organized the project management team for success and we are ready to help KHPA achieve its goal to modernize the KHPA medical assistance programs eligibility determination practices. We would provide KHPA with the right management approach; a carefully selected and experienced leadership team; an integrated methodology and tool set; and straightforward project, quality, risk, and issue management. We would provide the project leadership information about the status of the project that is current and comprehensive. All of this to accomplish a smooth transition to an integrated customer-centric Kansas Medical Eligibility Determination system, K-MED. 7-14

15 Additionally, our project management approach is in direct alignment with KITO s project management component statements. We acknowledge that these statements form the core of the State s policy for management of IT projects and are in alignment with ITEC s project management methodology. Figure 7-8 illustrates the activities or tasks that we complete as part of our project management approach and overall project implementation. of our approach Our project management approach is based on the Accenture Delivery Methods (ADM) as shown in Figure 7-9. We have combined the Accenture team and industry-leading practices, including those from the State of Kansas uniform Project Management Methodology (ITEC Policy 2530), to customize our project management and execution approach to the requirements of the K-MED Project. We believe that joint participation in project management is vital to the successful implementation of an on-schedule and on-budget K-MED solution that meets the needs of its users and the goals of the State. The jointly operated Project Management Office (PMO) would oversee the project and would reflect the true teaming relationship between KHPA and the Accenture team that we would like to establish. For the K-MED implementation, the Accenture team has defined five guiding principles of project management to guide the project and to facilitate achieving KHPA s requirements and goals. These guiding principles include: On Time complete the project according to the schedule that is developed and agreed to with the KHPA leadership Within Budget complete the project within the workday and cost budgets for both the Accenture team and the State team efforts Conformance to Specifications complete project deliverables in substantial conformance with mutually agreed upon requirements to facilitate value creation for the State and high performance for system users Effectively Manage Risks and Issues remove roadblocks to project success as expeditiously as possible Knowledge Transfer promote knowledge transfer to build capabilities and facilitate KHPA s ability to support the new system following implementation We have experience managing complex Health and Human Services projects. We successfully managed the delivery of the new Idaho Benefits Eligibility System (IBES), a similar system to our K-MED Solution Blueprint. We did this on time, and not only within budget but with great savings to the State. In fact, this project was the cheapest and quickest post-welfare reform transfer implementation in the history of the program for any state, anywhere. Similarly, we recently completed the successful delivery of an ERP solution for the State of Kansas. We were able to successfully leverage our standard set of tools and processes to successfully implement an integrated ERP solution that provided the State with a robust integrated financial management system. We will work with you to establish a management framework that supports the delivery of the K-MED system on time, within budget, and in conformance to the specified requirements. We work with KHPA to understand and leverage your existing management processes in order to effectively support the day-to-day operations of the project and overall system implementation. 7-15

16 KITO Project Phases Concept Planning Startup Execution Close Out Project Management Integration Requirement & Scope Management Project planning and Estimation Define Stakeholder Goals and Expectations Establish Project Perform Business Analysis Define High Level Requirements Plan Project Define Activities Gather Requirements Develop Baseline Plan & Estimates Estimate Work Schedule Work Validate and update Requirements Perform Gap-Fit Analysis Confirm Deliverables Identify Resources Monitor and Control Project Test against requirements Maintain Requirements Traceability Matrix Perform Integrated Change Control Management Update Workplan Monitor Actuals Monitor Budget Submit Post Implementation Evaluation Report Close Project Transition Deployed Application Report on Actuals Program Management Areas Quality Management Configuration Management Deliverables Management Communication Management Risk Management Issue Management Documentation Management Meeting Management Status Reporting Ideation, Concept, Initiation & Planning Create Quality Management Plan Develop Configuration Management Plan Develop and Receive signoff of Deliverables Expectation Document Define Stakeholder Goals and Expectations Develop Communication Management Plan Develop Risk Management Plan Develop Issue Management Plan Develop Document Management Plan Develop templates for meeting agenda, minutes, and action items Develop templates for status meeting reports Initiation & Planning Develop metrics Identify Configuration Items Conduct Kick-Off Meeting Capture initial risks Execution & Monitoring Monitor Metrics & SLAs Perform Corrective Actions Perform Peer Reviews Manage Configuration Items Deploy Configuration Items Manage and monitor Deliverable process Deliverables Signoff Track and Monitor project performance Monitor and Mitigate Risk Perform Risk Assessment Develop Risk Mitigation Plans Manage risks Identify and prioritize Issues Analyze and resolve issues. Monitor and track issues Define Standard Document Directory Structure Define a Document Naming Convention and Standard Report on Standard Document Elements Conduct Meetings Capture and address action items Deliver Status Reports Conduct Weekly Status Meetings Conduct Monthly Status Meetings Conduct KITO Quarterly Status meetings Execution & Monitoring Perform Project Review Delivery & Closeout K-MED Figure 7-8. Accenture s project management methodology aligns with Kansas Information Technology Office to successfully deliver the K-MED solution 7-16

17 In addition to our vast project experience, our proposed Project Manager, Troy Myers, has over 15 years of health and human services project management experience and is a certified Project Management Professional (PMP) by the Project Management Institute. Troy has led all phases of the software development lifecycle including the design, development testing, and implementation of large-scale systems. Troy brings Kansas-specific knowledge and experience, having served as Accenture s project manager for the Kansas Department of Human Resources (KDHR) Tax, Appeals and Benefits Self-Service System (TABS) implementation. Troy Myers team works collaboratively with other state agencies and programs, including the agency responsible for Medicaid eligibility determination, to provide smooth delivery of Medicaid benefits. As project manager, Troy Myers would manage the day-to-day operations of the project and would coordinate the completion of services and deliverables. The intent of this information is to provide assurance to the State of the Proposer s demonstrated ability to manage large, complex enterprise software projects in a manner that ensures quality, project success, long-term viability, and lowest cost of ownership. Our experience and demonstrated skills at managing projects of similar size and scope to K- MED is largely due to our ability to bring standardization in our project management approach through the use of our mature methods and tools. This standardization allows us to reduce implementation risks, as we are able to create measurable and repeatable processes. As illustrated in Figure 7-10, our approach is the product of years of experience and a comprehensive set of standards. Our successfully demonstrated methods have allowed us to create repeatable processes that help us to satisfy our clients needs and goals with efficient knowledge transfer processes, early identification of risks and mitigation strategies, accurate staffing models, effective quality assurance processes, effective communication approaches, and standard project management, among others. We work with KHPA to apply these processes, methods and tools in order to accomplish an effective transition to the K-MED solution. KHPA will identify the staff members who will serve in key roles beyond implementation so that they can participate in Knowledge Transfer activities during the project. KHPA Team members will participate in the development of their Personal Learning Plans, take part in the transfer activities and report their status. Include in this information a statement confirming that the Proposer s Project Management Methodology is in full conformance with the State of Kansas uniform Project Management Methodology for all Information Technology (IT) projects valued at $250,000 or more (see RFP Section 4.65 Project Management Methodology ). T Plan Analyze Design Build Test Deploy T Project Management Application Technical Architecture Training and Performance Support Service Introduction T T T T K-MED Figure 7-9. For effective project management, our Delivery Methodology spans the complete delivery lifecycle, with separate focus areas for Accenture s project management methodology was critical to our ability to marshal the appropriate resources and to focus them where and when they were needed most. The system of work plans, timelines, and status reporting tools enabled us to maintain control and ensure accountability throughout the project. Matthew W. Frymire Chief Information Officer Riverside County, CA T 7-17

18 Issue Management Issue Management Plan Identification and Tracking Evaluation and Prioritization Correction and Approval Supported by Tool Suite Risk Management Risk Management Plan Risk identification and assessment Risk assignment, escalation and tracking Defined mitigation strategies Monitoring and Control of risk list Supported by Tool Suite Other Project Management Information Security Plan Project Measurement & Reporting Plan Contract Management Fiscal and Procurement Management Project Administration Plan Incoming Orientation / Level 2 Screening Conflict Resolution Plan Knowledge Management Plan Supported by Tool Suite Quality Management Quality Management Plan QPI for CMMI Compliance Formalized and Structured Peer Review Executive QA Program Supported by Tool Suite Issue Management Risk Management Other Project Management Staffing and Resource Management Project Management Quality Management Communication Management Work and Schedule Management Change Management Staffing and Resource Management Staffing and Resource Management Plan The right people at the right time Integrated with Work Planning Retention and performance management Supported by Tool Suite Communication Management Communication Management Plan Includes governance and stakeholder planning and communication Audience, objectives, and schedule Determine feedback mechanisms Supported by Tool Suite Work and Schedule Management Project Work Plan and Schedule Integrated program timeline with cross-team-dependencies Deliverable Management Work Breakdown Structure (WBS) Organization Breakdown Structure (OBS) Phase Gate Reviews / Approvals Supported by Tool Suite Change Management Change Control Management Plan Scope Management Plan Analysis and Approval Control completeness and accuracy Configuration Management Document management Supported by Tool Suite K-MED Figure Our core management processes provide the cornerstone for KHPA to effectively monitor, measure, and control the delivery of the K-MED project Accenture s ADM Project Management Methodology aligns with and is in full conformance to the State of Kansas Uniform Project Management Methodology as described in ITEC Policy 2530-Project Management Detailed Project Schedule This section shall include a comprehensive Detailed Project Schedule that addresses the State s intended implementation approach. The Detailed Project Schedule shall include tasks to be performed by State personnel, as well as tasks requiring collaboration between State and Proposer personnel. It should include as much detail as possible, although it is understood that details about some later tasks are dependent on the results of other earlier tasks. The Detailed Project Work Plan was created by taking the State s requirements and entering the necessary data into our ADM for Custom Estimating Model. We entered the parameters and assumptions into the model, which resulted in an estimated number of work hours by work stream, phase, and deliverable. Our project work plan, which is a part of the overall K-MED Project Management Plan, would serve as the basis for executing project tasks. To develop our proposed implementation strategy, we estimated the task effort, team size, and duration of each project. We compared the staffing and effort against our estimates to validate effort and costs. After reviewing and validating the schedule and approach, we created an MS Project Plan that defined the task packages that drive deliverables, identified task relationships, timelines, milestones and critical path; and assigned resources to project tasks and showed resource loading and leveling. We identified external dependencies and integrated other activities that are under the control of other parties. During the Plan Phase, we would review and 7-18

19 refine the plan with the State. The PMO would manage the overall plan throughout the project duration. The following summarizes key points about the detailed work plan. As requested, we have included a copy of our work plan in electronic format (Microsoft Project). We have estimated the K-MED project, assuming a start date of May 30, 2011 and an implementation date of Phase 1 in March 2012 and Phase 2 in January We have estimated and included in our plan, the effort for the entire project The work plan outlines a plan for the entire project The K-MED project work plan and project management methods align closely with the KITO IT Project Planning Methods We have documented project management activities in the work plan Our work plan includes tasks to be performed by State personnel, as well as task requiring collaboration between State and Accenture team personnel. The work plan identifies the estimated work effort and shows dependencies, critical paths and resources assigned to each task Our work plan includes the deliverables supported by our ADM methodology and approach We have highlighted key milestones, such as Analyze Phase Completion, Design Phase Completion and System Test Execution Completion to help gauge the project s progress toward meeting the target completion dates. Additionally, we have included milestones for each deliverable. We have reviewed the State of Kansas work plan standards when developing the K-MED project work plan. We have incorporated ten (10) business days for State staff to review, request changes and/or approve deliverables in accordance with the State s Quality Assurance Review Process (QARP). The following minimum standards apply to the Detailed Project Schedule submitted with the proposal: Project management activities shall be documented in the Detailed Project Schedule. The Detailed Project Schedule shall outline a plan for the entire implementation project. The Detailed Project Schedule shall include dependencies, critical paths, and resources (both Proposer and State staff) assigned to each task. The Detailed Project Schedule shall include all deliverables listed in RFP Appendix 6 Deliverables, any deliverables mentioned in the RFP but not listed in RFP Appendix 6, plus any additional deliverables that the Proposer deems necessary to support the proposed implementation Methodology and Approach. Estimated work effort shall be shown for each task. Appropriate milestones shall be identified in the Detailed Project Schedule to help gauge the project s progress toward meeting desired target completion dates. Any assumptions made in developing the Detailed Project Schedule shall be included in this section. Proposers are to pay particular attention to the State of Kansas work plan standards found in Information Technology Executive Council (ITEC) Policy 2400A, IT Project Planning Instructions, found at

20 The State requires that the Detailed Project Schedule submitted with the proposal eventually support the Kansas Information Technology Office (KITO) IT Project Quarterly Reporting requirements found at Proposers are advised that the Detailed Project Schedule submitted with the proposal will eventually become the Project Management Plan deliverable (see RPP Appendix 6 Deliverables). This is the detailed project plan that must be submitted to the Executive Branch Chief Information Technology Officer (CITO) for approval. When the detailed project plan receives CITO approval, then the project can begin. This process is explained in RFP Section Explanation of K-MED Procurement Schedule and Process. The Detailed Project Schedule shall be accessible via Microsoft Project, and shall be included in electronic (Microsoft Project) format (do NOT submit in PDF format only). Printed copies of the proposal shall also include a high-level timeline in Gantt chart format. The Detailed Project Schedule shall allow a minimum of ten business days for State staff to review, request changes, and/or approve deliverables in accordance with the Quality Assurance Review Process (QARP) explained in RFP Appendix 10. Very complex deliverables or deliverables requiring an extended review period should allow additional time for review. Detailed instructions for inclusion of deliverables in the Detailed Project Schedule are provided in RFP Appendix 6 in RFP Section A During implementation, the Contractor s Project Manager shall be responsible for monitoring and updating the Project Management Plan, revising and developing further detail as appropriate. It is expected that the Contractor will provide highly qualified Project Management Office (PMO) staff to manage the work planning effort and to maintain the project schedule in Microsoft Project. The Contractor s Project Manager shall provide weekly Project Management Plan updates to the State project leadership for the duration of the project. Figure 7-11 presents our high-level proposal timeline. Our Detailed Project Schedule is provided in MS Project electronic format as Attachment 1 to the Technical Proposal. 7-20

21 Figure Our high level timeline provides our team approach and major tasks we would perform as we implement the K-MED Solution. 7-21

22 Staffing Plan The Proposer shall also provide a Project Staffing Plan that addresses each of the Proposer s project staff as well as the State s project staff (see RFP Section Resources to be Provided.) The Project Staffing Plan shall show the plan of usage (days per month) on a monthly basis for each resource over the period of the project. The Project Staffing Plan shall be included in Microsoft Excel format (do not submit in PDF format only). Costs shall be reflected only in the separate Cost Proposal. Our Project Staffing Plan is provided in MS Excel electronic format as Attachment 2 to the Technical Proposal. Our Plan shows both State and Accenture Team resource planned usage, by month, over the period of the K-MED Project. Costs are reflected in the separate Cost Proposal Deliverables The Proposer shall also list and describe each proposed Implementation Phase deliverable. For those deliverables already described in RFP Appendix 6, the Proposer may use the deliverable descriptions from RFP Appendix 6 as stated if desired. If the Proposer changes anything in the deliverable descriptions from RFP Appendix 6, then the Proposer shall explicitly point out the proposed change. KHPA is very interested in Proposer creative and inventive suggestions and ideas concerning the right set of deliverables for the K-MED Project and in getting the right content in that right set of deliverables. The following pages provide short descriptions of the deliverables. Deliverable Name Weekly Status Report The status report details team metrics, issues, tasks completed since the last report, planned key tasks and activities, departures from the work plan, delayed tasks, and topics for the State Director. Project Management Plan The project management plan documents the project tasks, deliverable, schedule, milestones, and resources assigned to the tasks with a Gantt Chart that depicts all the tasks on a one-page diagram. Monthly Status Report Quarterly Status Report Project Web Site Personnel Organization Chart Communication Plan Facilities Management The status report details team metrics, issues, tasks completed since the last report, planned key tasks and activities, departures from the work plan, delayed tasks, and topics for the State Director. The status report details team metrics, issues, tasks completed since the last report, planned key tasks and activities, departures from the work plan, delayed tasks, and topics for the State Director. The Project Web Site is used as a comprehensive repository of documents and other materials related to the project. It is also used to maintain versioning control on all documentation. The Personnel Organizational Chart outlines the final staff needed for the K- MED project. The Chart will contain a graphic depiction of the staff s hierarchy and a list of all individuals associated with the project, including all Contractor staff and subcontractor staff The Communication Plan is a detailed document about the communication structure and methods used on the FMS project. It documents the projected communications for the life of the project, the owner of the communication, the date the communication is released, the method of communication, and the status of the communication. The Facilities Management Plan contains the location of the facilities, the 7-22

23 Plan Deliverable Name Change Management Plan Configuration Management Plan Business Design Document Requirements Validation Document (RVD) Enterprise Readiness Assessment Report MITA Self Assessment KITO Reporting Requirements Cost Allocation Plan Capacity and Performance Plan Risk Management Plan Security Plan Detailed Design Document Help Desk/ AVR Plan timeline for operation, all equipment located there, all conferences and meeting rooms, and type of workstations provided. The plan will all include federal and state regulations. The Change Management Plan includes a process to make sure the project has adequate control over changes to all items necessary for creating or supporting the end deliverables. A visual representation of the change request process will be included. The Configuration Management Plan details the processes, configuration management tools, and procedures the Contractor would use for the duration of the K-MED Project, and for all project phases and activities. The Business Design Document details the current business processes of State s eligibility, entitlement, and enrollment programs for Medical Assistance. It will also identify and describe interfaces and data acquisitions with other systems or entities, and provide a gap analysis describing a system design that will support the requirements necessary to complete the development of the K-MED project. The Requirements Validation Document maps from the high-level requirements and the detailed product requirements to the various analysis, design, build, and test components (e.g., use cases, designs, test conditions), product functions/components, business areas, etc. throughout all stages of the project The Enterprise Readiness Assessment Report details the change management approach for FMS. This includes the templates, tools, methods, and timeline associated with the Communications, Training, Organization Redesign, Transition and Knowledge Transfer, and Agency Readiness. The MITA Self Assessment details our self evaluation of our proposed solution against the Kansas MITA Framework 2.0 Technical Capability Matrix Reference Quarterly Status Reporting. The Cost Allocation Plan provides documentation to support wages, fringe benefits, and other expenditure items in accordance with federal and state regulations. These requirements would be developed with help from the State and documented in the Cost Allocation Plan. The Capacity and Performance Plan details the strategy for assessing overall solution and component performance, and ) using this information to develop and plan for component acquisition, configuration, and upgrade. The Risk Management Plan details the appropriate methods, tools, and techniques for active and ongoing identification and assessment of project risks; development of risk avoidance, transfer, mitigation, or management strategies; and process for monitoring and reporting of risk status throughout the life of the project. The Security Plan details our plan to prevent unauthorized disclosure of customer / member data and information. It will also detail security specifications for all sites where system development will occur, KHPA data is stored, or interaction with the KHPA personnel will take place. The Detailed Design Document details the technical requirements for developing, testing, and implementing the K-MED System. The Help Desk/AVR Plan details requirements and performance standards 7-23

24 Deliverable Name System Test Plan System Test Results Tables and Rules User Guide Online User Guide Operating Procedures Guide specified in the requirements workbooks. The System Test Plan documents the combined set of test Scenarios, test Conditions, and test cycle Definitions. This deliverable documents the system test results of the system test conditions and scripts and the fixes or SIRs identified due to system test. The Tables and Rules User Guide details the code sets, code references, and rules used in the K-MED system. It also is a supplemental reference to other user and business practice guides and provides a reference for all of the subsystems within the K-MED system. The Online User Guide includes basic system documentation, key command instructions, and is included in the basic system training materials. The Operating Procedures Guide defines the relationships and responsibilities of Contractor and State personnel for K-MED operations. It will be updated to reflect changes identified during the acceptance test process. Business Continuity Plan The Business Continuity Plan details our core business processes and contingency plan in case of an emergency. The plan will identify triggers for activating plans and an establishment of a business resumption team. Disaster Recovery Plan Data Conversion Plan User Acceptance Testing Plan User Acceptance Testing Criteria and Procedures User Acceptance Testing Resolutions Document Performance Test Deployment/ Roll out Plan System Documentation Deliverables, Work Products, and Materials K-Med System Training The Disaster Recovery Plan details the retention and storage of back-up files, hardware and networks. It also includes a staff chart and back-up procedures and support to accommodate the loss of online communications The Data Conversion Plan documents the requirements, manual and automatic procedures, and programs needed to extract data from the current applications, cleanse it, and load it into the new application. The User Acceptance Testing Plan describes the test scenarios, test conditions, and test cycles that must be performed. It details a precise schedule that UAT follows to ensure that the K-MED System is thoroughly tested before moving into Ongoing Operations. User Acceptance Testing Criteria and Procedures contains test scenarios, scripts, and expected outcomes for all conditions to be test during UAT. It describes how testing will proceed and the schedule it will adhere too. User Acceptance Testing Resolutions Document details a summary of the testing process as defined by KHPA, description of the problems identified and the estimated timeframe for completion. This deliverable documents the required steps a tester must follow to execute a group of performance test conditions defined for a performance test scenario. The Deployment/ Roll out Plan details when and how the application gets rolled out to the target deployment groups and sites, as well as the tasks necessary to prepare for the rollout. This Deliverable details all the updates to the K-MED System Documentation incorporating into the documentation all changes, corrections, or enhancements to the K-MED System. This deliverable includes a complete list of all K-MED Deliverables, including Work Products and other related materials, as well as identification of all proprietary products used in the operational K-MED System. The Training Plan defines the approach to training and performance support 7-24

25 Plan Deliverable Name K-Med System Training Materials Performance Reports Turnover Plan for users and the support team upon completion of a more detailed needs assessment. This deliverable includes the training materials developed for each training course. It includes UPKs, training environment, presentations, and job aids. This deliverable documents the performance test results of the performance test conditions and the fixes or SIRs identified due to performance test. This deliverable details the overall approach and high-level tasks required to successfully transition operations of the K-MED System to another entity at the end of the contract period Project Time Reporting Project Time Reporting. The Proposer shall describe its approach to an automated method of project time reporting that integrates with Microsoft Project to support the Project Management Plan and other required reporting. KHPA wishes to avoid manual techniques which involve multiple keying of time by task information into various spreadsheets. Any software licenses or computing infrastructure required to support the automated time reporting solution shall be noted and described, along with any required team training for State staff. Associated costs shall be included only in the separate Cost Proposal. Like our other project management areas, we bring a robust and disciplined time management approach and process. Our team will track each task s progress against the work plan and evaluate progress toward deadline and budget expectations. Using successfully demonstrated tools, such as Microsoft Project Server, we will establish and communicate a strict and clear process to team members for tracking time and properly managing to our work plans. However, we go beyond just having a great methodology; we actually use it. We use these same processes globally and consistently. Accenture will use MS Project Server to capture and report time for K-MED project resources. Our approach integrates with MS Project 2007 to support the project plan. Accenture s Program Control Services (PCS) hosts MS Project 2007 and manages the mechanics of the time reporting processes, providing the essential data to the project manager via the weekly reports. Formal work plans will allow the project team to proactively identify cross-team dependencies and to manage resource allocation and utilization. This monitoring encompasses scheduling and balancing of the work assignments for State staff taking into consideration the need to support concurrent work streams. We establish a comprehensive and base-lined plan with KHPA at the beginning of a project, carefully monitoring and maintaining through the lifecycle, and continuing to be granular enough to track time at the task level and address significant variances. Firm project baselines will enable our PMO teams to track and report milestone achievements and variances. Our work plan management will also track cost and schedule metrics. The steps we will follow to manage work plans and time effectively include: Establish time tracking/reporting policies Establish submission schedule Enter and submit time in time-tracking tool time sheets will identify name of individual performing work and number of hours worked by project work plan task 7-25

26 Project management reviews and approvals time sheets indicating effort expended and work performed will be provided on a monthly basis accompanying the monthly status report to K-MED project management Update project work plan Time Reporting Process As part of our time reporting process, Figure 7-12 shows how we analyze, manage, and report the overall project schedule, including milestones, deliverables, and critical path dependencies. With our approach, project team members will enter their weekly time using Project Web Access. This tool eliminates the need for manual dual entry. Project team members will receive training on how to record their project time as part of the on boarding process and K- MED project orientation. We manage the project budget and schedule to keep the project on course with the proposed schedule. We organize the work plan schedule into a Work Breakdown Structure (WBS) that describes the planned deliverables, tasks, and activities. Estimates and budgets will be included in the WBS and accessible through the project management tool suite. Team members enter their time on a weekly basis to the specific tasks they worked on for a particular week. Reports produced by the PMO allow project management to review project progress status on a regular basis. Continuous timekeeping against the work plan provides up-to-date project status and feeds into key metrics. This approach facilitates transparency for KHPA and the Accenture project management teams to identify and respond to at-risk areas helping to decrease overall project risk and promote on-time delivery. This also helps the joint management team to quickly and proactively implement corrective actions to address schedule slippages and make necessary adjustments to stay on schedule. Work plans will be available with full resource loading, including a three-month view into the future allowing your project management to understand current progress and assess schedule risks. We will update work plans on a regular basis to reflect updated or adjusted project tasks, activities, and resources including estimated start and completion dates, actual start and completion dates, estimated and actual task hours and completion percentage for in-process tasks. Working with your PMO team, we will also track and report time in a manner to support State and Federal calculation of the level of effort expended by federal funding stream. Our dynamic, proactive management process will help us maintain the project schedule and Team 1 Team 2 Team 3 Actuals Actuals Actuals 5 PCS sends reminder s to project team members Project Web Access PCS uploads time Project Server 1 Resources submit 2 PCS uploads submitted 3 time on the web actuals to workplan 4 PCS adjusts workplans PCS generates reports Team Lead requests workplan adjustments Leadership Report PCS generates leadership reports Schedule metrics reports Non-compliance reports K-MED Figure We use MS Project Web Access hosted by PCS to capture all project team member s time and provide consolidated time management reports efficiently, without the need for multiple points of data entry 7-26

27 manage the impact of critical issues. We will provide KHPA s stakeholders with the information to make informed decisions. Specifically, these time reporting procedures will enable us to match actual cost incurred to the earned value plan. The costs and software licenses associated with MS Project Server have been included in the Cost Proposal Status Reporting Status Reporting. The Proposer shall describe its approach for project status reporting. KHPA requires that weekly project status reports are provided to reflect the major activities for the reporting period. As part of the Proposer s approach to status reporting, KHPA will expect weekly participation in status meetings with KHPA project team. Project management will use the weekly status report to monitor project activity and to detect potential problems or delays. The weekly status report should serve as the agenda for the status meetings. Topics to be covered include: 1. A listing of significant departures from the Project Management Plan with explanations of causes and strategies to achieve realignment; 2. A listing of tasks completed since the last report; 3. Tasks that were delayed and reasons for delay, with expected revised completion date; 4. Planned activities for the next scheduled period; 5. Summary of major concerns or issues encountered, proposed resolutions, and actual resolutions; and 6. Any other topics that require attention from the K-MED Project Director or KHPA executive management. Also, KHPA requires that the Proposer s weekly project status reporting approach support monthly executive status reporting, as well as the Kansas Information Technology Office (KITO) IT Project Quarterly Reporting requirements found at Our idea of project management is forward-looking. We understand that we need to know where we are first before being able to identify actions needed to achieve the project s goals. Status reporting is a key method; we provide status back to all key stakeholders. The Accenture team will use daily and weekly management meetings to report status, and review key milestones. Our project management methodology supports tracking and reporting progress and issues at weekly, monthly and quarterly intervals, as illustrated in Figure We understand that project status is not a static document. For this reason, we treat them as living documents. We will update status to provide KHPA accurate and timely status, often in real-time. We want you to have access to status to make the right decisions. Our approach encourages managers and stakeholders both to be aware and to have an active role in both being aware and resolving issues. This collaborative element reduces the chance of an issue surprising project management or our stakeholders. We will also support a reporting capability using our Accenture Delivery Tools (ADT) to display project metrics, summarizing the health of the K-MED Project initiative for Kansas and Accenture team managers. These tools feature: Easy-to-tailor templates Accenture s status reporting makes all players active partners in K-MED s success Emphasis on transparency and accessibility for KHPA and stakeholders Timely status that reflects real-time project status Forward-looking approach that places proactive vs. reactive action Treat project status as live instead of static Encourages active role by project management and stakeholders Reduces chance of surprise issues 7-27

28 Multiple security levels, with control of permissions by user, function, and record Report Audience Contents Weekly/Monthly Status Reports Weekly/Monthly Team Status Reports Weekly/Monthly Project Status Reports Monthly/Quarterly Steering Committee Reports Quarterly IT Project Reporting Team Leads Accomplishments during reporting period Work planned but not completed Work/Activities planned Issues/Risks Project Management Milestones Work completed this period Deliverables completed Work planned but not completed Work planned for next period Future activities Issues/Risks Performance metrics Meetings Project Management Milestones Work completed this period Deliverables completed Work planned but not completed Work planned for next period Future activities Issues/Risks Performance metrics Meetings Steering Committee Milestones Deliverables Issues/Risks KHPA s Chief Information Technology Officer (CITO) Business realization metrics Agency checklist for quarterly project status reporting Quarterly status transmittal form Estimated cost at completion Work product identification Change Management Work Breakdown Structure Figure We tailor our levels of status reporting to meet the needs of KITO IT Project Quarterly Reporting Weekly Status Reports and Meetings Throughout the project duration, we conduct regular status meetings to discuss items such as project progress, milestones, deliverable status, risks, issues, and overall work plan execution. These meetings are an excellent method to communicate and discuss project status. Our status reporting includes: Immediate reporting of staff changes Attending weekly project update meetings Providing ad hoc status updates Providing bi-weekly status reports Status reports help monitor project activities and detect potential delays or problems. The topics included in the weekly status report include: 7-28

29 List of tasks completed since last report Planned activities for next scheduled period Summary of major concerns or issues encountered, proposed, and actual resolutions Tasks delayed and reasons for delay, with expected revised completion date List of significant departures from the project work plan with explanation of causes and strategies to achieve realignment Any other topics that require attention from KHPA Project Director As illustrated in Figure 7-14, status reports will serve as the agendas for the weekly status report meetings. They will include invitees, approval of the previous meeting minutes, a discussion of action items from the previous meeting, progress reports on milestones and an update on deliverable status. The status report will also include a discussion of identified project risks and issues and, when appropriate, mitigation plans for those items. Status reports will have a two-day deliverable review cycle. We will provide the status reports to KHPA team members as well as your PMO and QA Contractors. The project team will capture meeting minutes and distribute to the group within one business day as well as store in the team s central location for documentation. Assignments, with due dates, will be documented and be part of the minutes and visible to K-MED leadership through regular status reports and meetings. At times, depending on the phase of the project, the frequency of these meetings may increase. For example, during the Deploy Phase, we may hold project status meetings as often as twice a week or even daily. Tracking Progress Our processes provide a series of tracking tools that manage system investigation requests, change requests, issues, risks, and peer reviews. We review each team s progress, the overall project schedule, recent accomplishments, activities planned for the upcoming period and the financial status of the project. We also review all issues and risks outstanding. Each month, we would collect metrics in order to analyze performance data and trends, assess potential problem areas, and identify opportunities. Each week, month, and at the end of each phase, we would prepare a summary report of the phase, that covers activities, tasks, and milestones completed. The report would include an updated plan and details for the next phase. The project managers would review and approve the report prior to the start of the next phase. Integrating status reporting into the project process is a key to a successful project. The Accenture team will confirm that the weekly status reporting is compliant with the K-MED Project Weekly Status Report Date: Meeting participants: A. Approval of previous status meeting minutes B. Overall status of the K-MED Project Work plan status (Gantt chart) Deliverable summary and status s of Activities/Sub-tasks: Completed in the previous period In Progress Planned for next period Delayed C. Issues and Risks Status New, existing, heightened and closed Recommendations/strategies for each D. Action Items (open, closed, new) E. Other Status/Announcements K-MED Figure Comprehensive status report agendas guide weekly meetings and inform attendees 7-29

30 K-Med K-MED Figure We will customize our Sample Project Scorecard for KHPA and use them for monthly and quarterly reviews with K-MED project leadership and Executive Steering Committee. format and substance requested by the KITO. Contents of the report would include project schedule, issues, hours spent and hours estimated to complete activities, risks, accomplishments and any changes from baseline. We will create narrative status reports and PowerPoint presentations for the Executive Steering Committee and monthly and quarterly reports, as shown in Figure We will customize our Sample Project Scorecard for KHPA and use them for monthly and quarterly reviews with K-MED project leadership and Executive Steering Committee. Our scorecards summarize information in an easy to read manner for K-MED Project team members using key data points from work plans, weekly status reports, deliverable logs and other tracking tools. At the end of the project, the Accenture team will produce a final project closeout report. This report finalizes all activities and includes recommendations to resolve any remaining outstanding issues Kansas Information Technology Office Kansas Information Technology Office. Quarterly project reporting to the KITO statewide PMO is required. The Contractor will provide the primary resource used in compiling this required reporting, as well as providing additional information, documentation, and/or related presentations and legislative testimony as required in support of this process, or any other related project reporting. To address this requirement, the Contractor shall submit a draft of each completed Project s proposed Quarterly Report submission to the K-MED Project Director at least ten days before it is due at the Kansas Information Technology Office (KITO) for review and approval or modification. Once accepted, the report will be filed with KITO by the K-MED Project Director. 7-30

31 In this section of the proposal, the Proposer will commit to providing the required KITO project reporting. Accenture recognizes that the K-MED project would require quarterly status reporting to KHPA s Chief Information Technology Officer (CITO) as defined in KHPA s ITEC IT Policy The Accenture team would provide KHPA with the primary information needed to satisfy the Quarterly Project Reporting requirements. The Accenture team s PMO will prepare an initial draft of the following documents, as specified in the Quarterly Report submission requirements: Agency Checklist for Quarterly Project Status Reporting Quarterly Status Transmittal Form (Rev. 09/2006) PM02-8 Estimated Cost at Completion Form PM02-6 Work Product Identification Form PM09 - Change Management Form Work Breakdown Structure-Quarterly Report The Accenture team would submit the completed draft to KHPA Project Director for review. We will submit this draft to the KHPA Project Director at least ten days before it is due to KITO. KHPA Project Director will review the report prior to submitting the report to KITO. In addition to preparing the draft quarterly report documents, the PMO team would support K-MED Project Director with other information, documentation and/or related presentations as required in support of this process Issue Resolution Issue Resolution. The Accenture s Issue Management process Proposer shall describe its approach to issue is collaborative identification, tracking, and resolution. This discussion shall include the use of any tools or Issue identification is combined with risk techniques that are integrated into configuration management for early detection of issues management, software change control, and the Process and tools allow issues to be raised overall project management methodology. at any level of the organization Topics to be addressed in this section include: Culture that supports early issue identification 1. Issue identification; and instills confidence in project management 2. Issue tracking; that they care and will provide the help 3. Issue review and prioritization; needed to address issue 4. Issue analysis; Prioritization is done jointly for quick 5. Issue resolution; and resolution of highest priority issues 6. Issue escalation. Issues are tracked and reported to prevent After award, KHPA and the Contractor shall delays and missed answers agree on a protocol for collaboratively resolving Proactive management drives project implementation issues. This protocol shall outcomes address the topics above, responsible parties, and specific steps to be taken on issues or disputes arising during the implementation process. We will work with your team to identify, assess, rank, assign, and resolve issues continuously to reduce the impact on the K-MED project s progress and outcomes. Issues are realized risks that we identify through the risk management process or when a team member encounters an unexpected problem. Simply put, the project s issues represent a list of barrier items for leadership to remove so project resources can get back to delivering a successful K- 7-31

32 MED solution. We closely tie our issue management efforts to the risk management process, using the same tool to track and report to the K-MED Project leadership. We have found it is crucial to provide a comprehensive view of risks and issues on a regular basis. You can never know too much about a risk or issue and cross-team involvement helps quickly get ahead of these possible showstoppers. Our clients can see a strong culture of collaboration in our past projects. For example, on the Idaho IBES project, we were able to notify our client of an issue outside of our scope that they owned before they were aware of the issue. This allowed the State to address the issue early before many of the negative impacts could occur. Our Approach Our issue management approach is to manage issues collaboratively with K-MED leadership in a well-defined, centralized, and proactive manner. This includes actively addressing, tracking and escalating issues across the project throughout all phases. Proactive management of issues is essential to achieve the outcomes of a project. Our approach begins by closely tracking potential issues with an automated tool and regularly seeking root causes, owners, next steps and ultimately, resolutions. Our experience at similar projects such as in NYC HHS-Connect and in California C-IV provides us with insight into potential issues a project of this scope may encounter. During the Plan Phase, we will work with KHPA to document the Issue Management Plan for the K-MED project. KHPA reviews and approves the plan before we would implement it for the K-MED project. As shown in Figure 7-16, the plan specifies the processes for the following: Issue identification Issue tracking Issue review and prioritization Issue analysis Issue Management Decision Analysis and Resolution Potential Issue is Discussed Has problem been determined to be an issue? Yes Issue Owner documents Can issue be resolved at The Team Lead or Management Level? Yes Team Lead or Management Determines Next Steps/Resolution Problem is Resolved Internally No Escalate Issue to Project Management Level No Issue Owner documents change Can issue be resolved at Project Management Level? Yes Project Management determines Next Steps/ Resolution Issue Owner updates the Next Steps/ Resolution and the Status to Closed No Escalate issue to Steering Committee Steering Committee determines Next Steps/Resolution K-MED Figure Our transparent issue tracking and resolution proactively seeks the root cause and resolution for issues to prevent reoccurrence and solve the right problem 7-32

33 Issue resolution Issue escalation (includes steps to take on issues or disputes arising during the project) Issue Identification, Tracking and Prioritization We will implement issue management procedures based on creating an Issue Management Plan to confirm we are tracking and resolving issues effectively with appropriate accountability. These procedures require the use of a centralized Issues Tracking Tool, Rational ClearQuest, which project management will oversee. We will rank issues, as outlined in Figure 7-17 based on user impact, policy impact, and project impact and determine the required action. Issue Analysis and Resolution The assigned issue owner would evaluate the issue, determine the resolution approach, and document the issue as follows: Provide a brief action plan for the issue Update estimated completion date Notify the individual who raised the issue of any difficulty resolving it by the due date, or if further clarification is needed Contact the individual who raised the issue if the assigned team member cannot resolve it Update issue resolution status continuously to reflect progress on resolving the issue Upon resolution, provide a detailed description of the solution in the Issues Log Update the Issue Log to Resolved upon resolution of the issue Issue Priority Immediate High Medium Low Priority User Impact Policy Impact Project Impact Critical business process cannot proceed Critical business process impeded; progress made but not finalized Critical business progress affected: workaround exists Non-critical business process State or Federal policy violation State or Federal policy violation Policy decision potentially affects work units Policy decision may affect future release Prevents project progress and jeopardizes project schedule Impedes project progress due to multiple work unit dependencies Project work units can continue: may impede approval Project work units can continue; noncritical business functionality Issue Resolution Timeframe Within hours Within 48 hours Within one week Within two weeks Figure By ranking issues based on user, policy, and project impacts, we can provide resolution within the right timeframe for the K-MED project Issue Management and Reporting During regularly scheduled management meetings, we will share our issue log information with you to track open issues, assess their impact, identify options for corrective action, and make proper assignments for resolution. These procedures will benefit the K-MED project by providing structure and procedures to resolving items quickly to stay on schedule and within budget. The Issues Tracking Tool will benefit the K-MED Project Team because it: 7-33

34 Enables team members to document items in one common repository Captures details about each issue consistently Provides an audit trail of decisions made and actions taken regarding issue resolution Enables team leads to assign and follow up on items assigned to team members Provides management reports to track, manage, and analyze issues in various ways (such as by team, by person, or by issue type) We will work with your leadership to regularly monitor and manage the issues through resolution and communication to the K-MED Project Team. Managing and reporting issues would occur as follows: Team leads would review open issues, make assignments, and monitor resolution status The team lead would review pending issues assigned to their team and follow up on issues that are past due or issues with approaching due dates The team lead would review the content of issue documentation and would follow up with team members if additional explanations or information is required The team lead would also own the escalation process for his or her team s related issues that were escalated Issue Escalation An important aspect of issue resolution is the escalation of critical issues to the project directors or steering committee. Functional/technical teams or project managers may resolve many of the issues. However, if they cannot resolve an issue at that level, they will need to escalate it to project directors or the executive steering committee, on a regular basis. Issue owners who are not able to resolve issues can escalate the issue and reassign to project management using the Issue Tracking Tool. K- MED project management would present and discuss issues that require management attention at weekly issues-review meetings. If project-level issues require the support of the K-MED steering committee, project management would escalate the issue to the appropriate K-MED stakeholders via the resolution process defined in the governance protocol. This approach will enable us to jointly resolve critical issues first. If the issue owner cannot resolve the issue during the initial timeframe, we will reassess issue priority. Sometimes lowpriority issues can become high-priority issues over time, and other times we may need to adjust priorities if the impact of the issue changes due to unforeseen factors. Once we have resolved an issue, we will notify the responsible team manager Large-scale web development projects are high-risk, and I have witnessed many companies struggle with delivery and performance. Accenture has consistently proved they can deliver on these types of projects. Their professionalism, planning, and teamwork are impressive. The IMPACT system is up and running, improving caseworker support and performing well. A great effort from an experienced and extremely committed team. Kim Weatherford Deputy Director of Information Technology Texas Family and Protective Services The Consortium sought a partner in the vendor community that would deliver on its commitments, no matter what challenges arose. We found that partner in Accenture. For the C-IV System, from the development and implementation phase and now in the maintenance and operations phase, Accenture has delivered on time, on budget and with high quality. Not only is the C-IV System one of the most innovative web-based public assistance systems in the country, it is probably the most maintain-able. We are proud of the success of the C-IV System and of our relationship with Accenture. John Boule Consortium IV Project Director 7-34

35 K-MED Figure Our sample issue log tracks detailed information about issues to appropriately assess, rank, assign and resolve the issue minimizing impact to the K-MED project of the solution so designated team members can implement it. Sharing issue resolutions across teams can help prevent future issues of a similar nature. The sample issue report template in Figure 7-18 includes descriptions of each detail tracked per issue. Tracking comprehensive information about each issue enables the team to more quickly assess and resolve the issue and potentially, prevent similar future issues from occurring. The Accenture team s issue management procedures allow transparency to issues affecting the K-MED project and provide leadership with the right tools to properly assess and act accordingly Action Item Tracking Action Item Tracking. The Proposer shall describe its approach to action item identification, tracking, and resolution. This discussion shall include the use of any tools or techniques that are integrated into configuration management, software change control, and the overall project management methodology. Topics to be addressed in this section include: 1. Action Item identification; 2. Action Item tracking; 3. Action Item review and prioritization; and 4. Action Item disposition. After award, KHPA and the Contractor shall agree on a protocol for collaboratively dealing with implementation action items. This protocol shall address the topics above, responsible parties, and specific steps to be taken concerning action items. In addition to regular status reporting, teams will maintain Action Item reports to track outstanding items to be performed resulting from a meeting. We manage action items using a similar process to our Issue Management process. After a meeting, we identify and document the appropriate action items in the Action Item log. The log 7-35

36 captures a description of the action item, the owner, a priority code, a start date, a targeted resolution date, a status code, and a closed date. Action item owners are responsible for reviewing the assigned action item, completing the action item, and updating the log. Project teams and management will review the Action Item log by date and by the priority assigned during the previous meeting to confirm that we complete the action items on time. A summarized Action Item report includes an issue description, owner of resolution, priority code, and date resolution. a status code to report the resolution status. We will report on the status of action items during status meetings. We will work with KHPA to determine how to best handle action items during implementation Project Controls, Standards, and Procedures Project Controls, Standards, and Procedures. The Proposer shall describe its proposed project controls, standards, and procedures for all project tasks. These items shall be reviewed and approved by KHPA s project leadership. Our approach for project controls, standards, and procedures combines KHPA s objectives with Accenture s quality control, standards, and procedures, which align with KHPA Kansas Information Technology Office (KITO). We have experience leading large-scale health and human services efforts and working The Accenture Team brings proven controls, standards, and procedures to deliver an efficient, high-quality K-MED solution to KHPA of Kansas Accenture s proven ADM controls and procedures facilitate appropriate levels of control and consistency across tasks, activities, and deliverables Project control is the element of a project that keeps it on track, on-time, and within budget Experiences with project controls, standards, and procedures applied from many other Health and Human Services system implementations with your organization. We bring standard and tested tools and templates that we can use and customize for the K-MED project to report on progress, issues and risks. We have executed and refined our approach to project management and controls on hundreds of projects of similar size and complexity, including our successes in Texas and California. Large system implementation projects have a reputation for budget overruns, cost increases, and schedule delays. Many times, poorly designed or implemented project control results in these unfortunate planning events. Accenture s successes in large Health and Human Services implementations relate directly to our management rigor and controls. We understand that: Agencies have a variety of stakeholders; many with different visions of how the solution should work. Together we would review the requirements with the stakeholders, resisting the temptation to increase scope without appropriate review and approval Some stakeholders may want to recreate exactly how the legacy systems operate. Together we would review requests for changes that recreate legacy systems Hard decisions need to be made in the interest of the overall program. Together we would analyze requests and changes and seek State approval Transformational projects represent a continuum of system and business changes. Not all good ideas need to be implemented for the initial K-MED release. Together we would capture and prioritize good ideas so they could be harvested in future phases Our approach to controlling the project centers on the people, documents, processes and software elements that define the overall project. In the Plan Phase, we would refine the standard 7-36

37 ADM project controls, standards, and procedures. We would validate compliance throughout the K-MED project lifecycle. KHPA project leadership would review and approve these processes before use by the project team. Figure 7-19 presents the features and benefits of our project controls, standards and procedures to KHPA. Features Accenture standards and procedures include interim checkpoints, deliverables, and quantitative metrics for on-going analysis and measurement Collaborative, up-front expectation and impact analysis to indentify the issues, concerns, and unique goals of each stakeholder organization Standard processes used for all change types requirements, non-requirements, and change orders Quality Management procedures institutionalized across Accenture and project personnel to confirm proper reviews, validations, and standards are followed Benefits Provides objective data for management evaluation and decision Enhances flexibility to adapt to changing implementation conditions Maximizes use of existing positive communication methods Minimizes false starts and stakeholder backlash Standardization simplifies and controls the change process Increases efficiency throughout the K-MED project Reduces risk to KHPA Figure The controls, standards and procedures that we apply throughout of the K-MED Project validate the quality of project deliverables Project Documentation Management This requirement includes, but is not limited to: 1. Managing project documentation Proposer shall describe templates used (configuration, design specifications, test scenarios, change request, etc.); organization of project directories; naming conventions; and version control procedures. Project documents and requirements are the main tools used to define and refine project scope. We use these documents to communicate status, design decisions, business process flows, and many other critical aspects of the project. Maintaining documentation, manuals, and source code libraries is a normal part of application development activities. Our ADM provides templates and samples of each type of document we would produce. The K-MED project plan and an associated deliverables list would detail specific documentation requirements. We would use Rational ClearQuest, as the repository and tool to manage K-MED documentation during the project s lifecycle. ClearQuest s version management and auditing functionality promotes the efficient management of documents and validates that they contain up-to-date material. Access-control features limit the editing and revision to only authorized individuals. Our standard document management practices include: Establishing and communicating a standard directory structure Establishing and monitoring document naming conventions and standards Capturing and reporting on standard document elements, such as: version number, author, change history and rationale, participants in document creation, and approvals Meeting Procedures This requirement includes, but is not limited to: 7-37

38 Prepare Agenda Advance Copies/ Read Ahead Packages Review Format/Process Facilities Location Summary of Key Decision Points Summary of Related Issues Advance Material We create a meeting agenda to promote meeting discipline Conduct Presentation Demonstration Interactive Table Top Review Walk Throughs Some reviews are conducted using a combination of formats We provide the State meeting minutes to permit review of topics and action items discussed Document Meeting Minutes Action Items/Issues Updates to Plans/ Specifications (We follow a standard document review and approval process) Updates to Project Master Decision-Approval Documentation Documentation conforms to an approved file-naming standard for storage in data repositories K-MED Figure We apply a standard process to structure our meetings to enhance productivity of meetings and accurately document results 2. Meeting procedures Proposer shall describe techniques to ensure that meetings are efficient, productive, and results are adequately documented. We use our standard process for preparing, conducting, and documenting meetings. Figure 7-20 illustrates this process. We create and distribute materials to the attendees prior to the meetings to allow sufficient time to review. This includes an agenda of the discussion items and objectives. Due to the importance of involvement of all stakeholders in many of the meetings, we work with the key stakeholders to determine a flexible schedule to meet their needs. Once we have determined the schedule, we provide the attendees with the details of the schedule including date, time, subject, and location of the meeting. We conduct meetings in formats that meet the needs of the participants. The meetings may have a variety of formats, such as tabletop reviews, walk-through reviews, and demonstrations, among others. As a standard practice, we create meeting minutes to document issues or items discussed during the meeting and, if necessary, modify the documents discussed during the meeting, such as design specifications or workflows, and conduct a follow-up meeting with KHPA to review the updated materials. This process continues until issues and questions are resolved. Once we obtain approval from KHPA, we store the final documentation in the designated documentation repository Development Standards This requirement includes, but is not limited to: 3. Development standards Proposer shall describe standards and procedures for design specifications, review processes, unit testing, and other controls to ensure the quality and consistency of custom design and development. We develop customizations, modifications and extensions in adherence to strict design and development standards. These standards provide high quality, portability across multiple platforms, consistent look and feel, ease of maintenance, and compatibility with future versions of APSP. Unit test plans are prepared during the Design Phase of a customization. This allows the design reviewer to confirm that the testing will validate all required functionality before coding begins. It is also a useful crosscheck for the developer during coding. Once the modification is developed, it goes through a peer review process by a fellow developer. We would review the source code, the code comments, unit test conditions, test scripts and sample test data to check compliance with the design and project standards. 7-38

39 We perform unit testing early in the development process. This helps the developers watch for potential issues with the design and tests each line of code. The final source code is unit tested against the module s test conditions before moving on to the next Test Phase. We provide additional information regarding the unit test process in Section , Testing Services Software Change Control Procedures This requirement includes, but is not limited to: 4. Software change control procedures Proposer shall describe the procedures and/or automated tools that will be employed to ensure the integrity of programs and configuration settings developed to support the solution. If any automated tools are to be used during the project, the costs for such tools must be included in the licensing costs section of the separate Cost Proposal. We would design a software change control (also known as configuration management) Features of our Change Control Management approach for the K-MED project Integration with other project management processes (e.g., work planning, resource planning) Integration with our systems development and implementation processes to support requirement traceability Change Control Board for the K-MED Project which meets on a scheduled basis for formal approval of the changes to maintain focus on scope Use of an integrated suite of tools to track change requests and is accessible to K-MED Project Team members process that provides for the controlled management of software and its related documentation as the software evolves from development to maintenance. Our process enables project team members and State stakeholders to identify, communicate, implement, document, and control changes in the documentation and systems environment. The goal of configuration management is to establish and maintain the integrity of outputs for the K-MED project. Features of the Accenture team s proven configuration management approach based on our extensive social services experience are: Clearly defines the items and categories to be placed under configuration management control, the owner of the item, and the level of configuration management control required Defines the tools the project will use to track configuration items Defines the process for making changes to different configuration items, and incorporating those changes into the project Configuration Management controls the issues and challenges related to multiple concurrent activities. These result from: Parallel phases and work streams planned and specified in our project work plan Changes and System Investigation Requests (SIRs) that are not part of the original parallel work stream plan. Changes can take one of two forms, either a Change Request (CR) or a System Investigation Request (SIR). A CR is any request for changes to a component and existing system baseline. The Change Control Board needs to authorize CRs since they may involve changes such as scope, cost, schedule, resources, acceptance criteria, method of delivery, documentation, quality, etc. Individuals formally submit CRs using a Change Request form. 7-39

40 Configuration Management Configuration Management Compliance Plan Configuration Control Process Identify Proposed Changes Systems Software Documentation Evaluate Impact of Change Change Control Board Review CCB Decision? Disapproved Example Tools VSS Excel eproject BI Navigator System Change Request Modify Objects / Document Changes Changed Item Configuration Database Systems Software Documentation Approved Unchanged Item Work Request Process New Requirement Requirement Change Other Release Management Process Authorize Design Review and Acceptance Build Test No CCB Approved? Yes Release Systems Software Documentation K-MED Figure Our approach for system, software and configuration documentation management uses a common repository to maintain currency with each system release A SIR is defined as a record of defect or discrepancy found between actual and expected results. System SIRs can be identified during peer reviews, testing, implementation, training, or even post-implementation. CRs will be reviewed by an established Change Control Board (CCB) specific to the K-MED project. Once the CCB has concluded the disposition of the CR, the decision must be implemented and tracked. Once the appropriate team has determined the disposition of a SIR, this decision must be implemented and tracked as well. As illustrated in Figure 7-21, our approach and methodology details how to perform configuration management in a controlled manner. We have used this methodology on many health and human services projects over the years. Figure 7-22 demonstrates the features and benefits of our configuration management approach. Our approach will provide effective control and management of changes to KHPA that does not require the KHPA staff to learn new tools, and will enable the disciplined and traceable implementation of changes to each project configuration item. Features Benefits Each requirement regularly updated so user and Improved usability of changes maintenance personnel can locate information for the current version or iteration Requirements Traceability Matrix enables Increased quality of end products continuous accurate tracking of project requirements to closure Established control levels to read and edit library- Lessened schedule risk and scope creep from 7-40

41 Features Benefits controlled content to make only authorized changes unnecessary changes Library controls limit access to sensitive materials Reduced security risk by preventing unauthorized access Library provides a single information source for Reduced chance of poor decisions based on decision-making and most current version of inaccurate or out-of-date materials configuration items Management of a single source repository protects Increased scalability of the product and maintains the common configuration, architecture, standards, documentation, and design Figure Establishing and maintaining clear baselines and managing the configuration management library will produce vital project team information and continuous schedule status Scope Management This requirement includes, but is not limited to: 5. Scope management The Proposer shall describe its scope control processes to ensure that work is not performed on out-of-scope features, functions, or tasks until KHPA grants authorization in writing. KHPA has a defined Change Control Process documented in RFP Appendix 11 for consideration by the Proposer. After award, KHPA and the Contractor shall agree upon and formally document a protocol for scope control. The goal of Change Control Management is to establish and maintain the scope of the project and manage changes that may arise to requirements, expectations and designs. From our extensive experience, social services projects that effectively manage scope reduce delivery and operation risks, especially risks associated with schedule, quality and cost. The K-MED Project s complexity demands an effective change control approach executed by a team with knowledge of your organization and tools and demonstrated experience delivering similar solutions. Our change control approach supports collaborative analysis and decision-making, creating a more effective process. It combines people, processes, and tools to enable project teams and stakeholders to identify, communicate, implement, document, and manage changes. This helps our team use correct versions, be aware of changes, and assess impact to their work. As we do on all projects, we would tailor our change control approach for the K-MED project. We would design, test, approve, and release controlled elements based on compliance with project requirements and specifications to verify the integrity of the K-MED project produces. The process assesses each change request for need, impact and appropriateness. Effective management of change can reduce delivery and operational risks, especially risks associated with schedule, quality and scope. Change Control Process Changes are inevitable; the goal of the change control process is to facilitate a controlled yet responsive environment. Control and management of this change are vital to the success of the project. The following process, depicted in Figure 7-23 outlines the high level process on how to evaluate, analyze, escalate and decide on proposed changes while seeking to minimize disruption to the project due to rework. After award, we would work with KHPA to document the details of this protocol for change control. The change control process begins with the identification of a change to a baselined deliverable or process such as a requirements or design change. Team members can identify a change. Change can manifest itself in many ways: as numerous small changes with little or no 7-41

42 Identify Possible Change Review Need for Change New Change? No Change Item in Status Project Teams Yes Review Change with Impacted Project Team(s) Yes Yes Are There New Requirements? No New Requirements Implement Change Request Agreement on Change? Yes Receive Change Approval Place Under Config Mgmt. Control No No Change Manager / Project Management Team Review Change Request and Meet with Impacted Project Team(s) Agreement Reached Yes Yes Change Control Board No Review Change Request Change Rejected or Deferred K-MED Figure Our change control process is rigorous with per step evaluation of proposed changes including key decision points and owning teams/individuals impact when considered singly; as a few large changes with great impact; or as a combination of these. We will use Change Requests (CRs) to request, monitor, track and control changes to project baselines. We establish an initial baseline for project scope in the contract and confirm it early in the project planning phase. We will establish additional baselines upon the approval of each deliverable (requirements, processes, code, test plans, hardware specifications, etc.). Controlling, managing and containing the evolution of requirements and design is one of the most challenging issues faced by large and complex projects. We will review change requests impacting scope, schedule, cost, or contract terms with the project leadership for authorization and to appropriately follow the contract management process before submitting them through the formal change control process. We expect the majority of changes would simply modify a project baseline with no other impact, while others would also have an impact on cost, scope, schedule, resources, and/or risks. When the Change Control Board (CCB), a combined KHPA/Accenture management team, approves change requests, we would update the project baseline appropriately and consistently across project work products and deliverables. We distinguish this process from identification, classification, review, and implementation of defects. Defects identify differences between actual and expected results when a system is tested or when we move a system to operational status. We develop expected results according to project baselines in effect. Defects that identify issues or defects from the approved baseline remain under the purview of the project and are not required to go through the processes 7-42

43 described here. Upon investigation, if recorded defects actually appear to require changes to approved baselines, these defects must generate a change request and use this process prior to implementation. K-MED Project Change Control Board K-MED Project Team stakeholders help to form the Change Control Board (CCB). This committee will meet on a regular basis to prioritize and approve the requests. We understand KHPA will establish priorities for system maintenance when multiple change requests are pending. Our experience tells us that a formal CCB provides our clients with control over project scope and allows us to implement the right changes. Representatives from key stakeholder groups will participate on the CCB. Regularly scheduled meetings and well-defined agendas will facilitate an effective process to review, approve or defer change requests Deliverable Management and Acceptance Processes Throughout the system development process, we practice a deliverables submission approach to define expectations and requirements up front. This process increases the likelihood deliverables meet your specifications and expectations and embeds our ongoing quality procedures into the process. Our deliverable process gradually introduces concepts, templates, drafts and eventual final products for your review and acceptance as depicted in Figure Prior to beginning work on a project deliverable, we would create and obtain approval of a Deliverable Expectation Document (DED), working with your teams to gain agreement on the goal, content and timeline for the deliverable. Because we base our deliverable process on years of experience combined with our methodology practices, you will receive DEDs that conform to KHPA s specific acceptance expectations as we have mutually agreed. We work with you to define the deliverable milestones up front using a Deliverable Tracking Log. This document lists each deliverable, DED delivery date, deliverable delivery date, deliverable reviewers and expected review completion dates. During project start-up, we will work with you to confirm deliverable templates, identify deliverable reviewers and review the schedule of deliverables per the K-MED project plan. We will track deliverables defined by statements of work using the central Deliverable Log and deliverables in review, and we will store final versions in a central location to quickly identify and easily access. Prior to submission of a deliverable, we conduct a walk through with the Deliverable Management Process Step 1 Step 2 Step 3 Tailor Template Review Period Draft Review Period Submission N Submission 2 Submission 1 Final Written Feedback Written Feedback Iterate, if necessary K-MED Reviewers Confirm scope Confirm template Confirm acceptance criteria Evaluate content for accuracy and completeness Evaluate document for usability Reaffirm acceptance criteria Approve or Reject with substantiation vs. acceptance criteria K-MED Figure Our Deliverable Management process is built into our Quality Assurance Plan (QAP), allowing for reduced review cycles and higher quality deliverables 7-43

44 designated deliverable reviewers to step through the documentation. The work plan accounts for a ten-day review cycle for initial deliverable submissions. By establishing a deliverable management process where we jointly review templates and expectations in advance, we can complete deliverable reviews on schedule to facilitate downstream tasks dependent on the deliverable. At a high-level, the deliverable submission and acceptance process encompasses three steps: notification, submission and acceptance. As a deliverable is completed, the owner will create draft copies for review according to the quality management process appropriate to a deliverable. This may include peer review, Accenture team lead review, or QA team review. We will formally submit each deliverable to your teams for review and approval following a mutually agreed upon submission process. When submitting deliverables to the K-MED leads, Accenture team project managers communicate submissions to the appropriate designated parties, including the K-MED project lead and the associated PMO and QA contacts. As part of the statements of work and documenting deliverable expectations, we will develop high-level specifications and acceptance criteria together with you for each of the following components to address: Timing of the availability of specific application functionality Timing of the installation of software upgrades, patches and fixes Training (for internal and external users, technical staff and train-the-trainer assistance staff) External interfaces and Enterprise Application Integration (EAI) processes Conversion/translation Testing Quality Assurance Monitoring and Improving system performance Working with parish personnel within work-day constraints Working with project team staff to mentor Transition to new system In addition to deliverable acceptances, we create close out criteria for each project. Because the K-MED project will be composed of a series of projects and the associated Statements of Work (SOW), projects will start, execute, and complete within the timeframe of the overall Agreement. We will specifically identify and agree upon the entrance and exit criteria for each project, between phases through final acceptance in each SOW. When we complete the KHPA project (triggering by acceptance of the final deliverable by KHPA or expiration of the associated post-production support activities), we are ready to close the project and complete the following activities: A project closure memorandum and Final End of Project report stating the provisions of the SOW have been completed and accepted (verifying required functionality, training, conversion, documentation and release specific requirements have been met) by KHPA will be prepared and forwarded to the K-MED leadership for review and confirmation The memo will serve as notification that acceptance of all work products/deliverables, and completion of the post-production support activities (if applicable), signify completion of Accenture s responsibilities under the SOW. The Accenture PMO team will perform tasks necessary to: Archive project deliverables 7-44

45 Prepare and submit final invoices Close projects in the time management tool to time posting Close projects in additional tracking tools Schedule and complete required quality assurance activities Release project resources to other initiatives, if applicable Risk Management Risk Management. The Proposer shall describe appropriate methods, tools, and techniques for active and ongoing identification and assessment of project risks; development of risk avoidance, transfer, mitigation, or management strategies; and monitoring and reporting of risk status throughout the life of the project. The Contractor must provide a Risk Management Plan within 30 calendar days of contract award. The plan must document all identified risks. An assessment must be conducted and documented for each identified risk. The Contractor will work with the KHPA Project Director to ensure appropriate mitigation strategies are identified, documented, assigned and implemented in a timely manner. The Our Risk Management approach provides a proactive method to identify, track, and mitigate risks Identification and assessment process tracks and manages all identified risks, compliant with CMMI Level 4 Preliminary risk watch list is based on prior experience from similar engagements Proactive risk mitigation planning reduces risk impact and priority On-going risk identification and management by the project team during the project life cycle helps to mitigate risk Risk metrics measure risk impact and exposure Contractor will identify any approach or work processes to address any risks identified to the K- MED Project Director. The K-MED Project Director will review the project risks on a weekly basis. Risk management involves the recognition, assessment, and mitigation of uncertainties that, if unaddressed, may result in schedule delays, cost overruns, performance problems, or other undesired consequences. Managing such risks is a key component of Accenture s overall project management methodology. Active risk management allows the K-MED project to prevent or mitigate the impacts of potential risks. We would base our approach on informed decisions and analysis of potential outcomes. Throughout its lifecycle, the K-MED Project may face many operational, technical and managerial challenges. Major business transformation projects of this kind involve inherent risks. We are experienced with the risks faced on these types of projects and know how to help KHPA aggressively manage the known risks and efficiently address the unexpected ones. We work in concert with KHPA s project leadership team to mitigate foreseeable risk by managing risks at each level of the project and escalating risks to the proper K-MED stakeholders when necessary. From our social services experience, Figure 7-25 outlines examples of those types of risks to be aware of and areas that require ongoing monitoring throughout the project duration. We will create a Risk Management Plan during the planning phase of the project. The plan outlines the approach we use to identify, assess, monitor and report risks. Once KHPA management has reviewed and approved the Risk Management Plan, we make the plan required reading for all K-MED Project Team members. This coordination enables us to follow a consistent process when monitoring and managing project risks. We create the plan at the onset of the project and treat risk management as an ongoing and repeatable process: revisiting the plan throughout the project lifecycle to verify it outlines identified improvement activities and 7-45

46 Risk Category reflects the current K-MED project structure. Our approach Kansas Medical Eligibility Determination (K-MED) Software with Successful risk management requires a clear and comprehensive approach that includes a successfully demonstrated methodology, detailed planning, comprehensive business solutions and disciplined follow-through. Our risk management approach, as illustrated in Figure 7-26 includes: Review of each risk to assess its importance and likelihood so we can prioritize available resources Regular reviews of risk matrices to review results of mitigation plan, and to understand trends in risks and to plan appropriate actions Establish clear communication with senior management to keep them informed of risk with recommended correction action Our successfully demonstrated risk management methodology can identify risks, quantify exposure and develop mitigation strategies as early as possible in the project lifecycle. Our approach identifies risks early, assesses the potential impact and defines clear, actionable mitigation strategies to reduce their probability and impact. These issue and risk management processes are an integral part of our U.S. Public Sector practice s ability to maintain Capability Maturity Model Integration (CMMI) Level 4 compliance, and to support the control and execution of the K-MED project. Risk Identification and Assessment Potential Associated Risks Operational Risks related to K-MED s organizational or business processes (business cycle, resource availability, etc.) Schedule Risks focused on ability of team to meet project plan and scope (out-of-scope change requests, issue resolution, etc.) Financial/Cost Risks that impact cost of project or business operations (such as schedule extensions) Resources Risks due to skill set necessary to deliver the project (such as subject matter advisor availability and knowledge) External Risks due to external project factors (legislation, stakeholder buy-in, funding) Technical Risks stemming from technology such as connectivity, system availability, and performance Political/ Risks related to conflicts on strategic direction and priorities Organizational Figure Types of risks the K-MED Project leadership may need to closely monitor and assess All too often, undocumented risks blind-side projects because risk management only occurs at the beginning of a project. We believe that risk management and identification occurs every day, throughout the life of the project. Much like for issues, we emphasize to all project team members that they need to watch for risks and encourage them to document risks as they observe them. Proactive and continuous risk management will reduce the likelihood of unexpected bumps along the road, providing an early warning system if a risk factor begins to occur. If a risk might affect the achievement of the project dates, the project leadership team would work to identify and evaluate potential courses of action as well as pros and cons associated with each. Accenture performs impact and probability analysis to determine if redirecting resources 7-46

47 Planning Assessment Analysis Handling Tracking Create/ Update Risk Assessment Plan Continuous Risk Identification Risk Categories Project Planning Scope Schedule Resources Cost Technical External Dependencies Quality Project Management Cost Disruptions Assess Probability of Risk Assess Impact of Risk Determine Risk Exposure No H Probability L Manage the Issue Yes Risk Realized Impact Risk Rating Identified as Medium or High? No Put Risk on Watch List H Yes No Risk Mitigated Yes Execute Risk Mitigation Plan or Contingency Plan Develop Risk Mitigation Plan and Contingency Plan Enter Change Request if Required Monitor Periodically and Retire When Handled Retire Risk Risk List and Risk Assessment Report from other activities can efficiently mitigate risk. KHPA and Accenture work together to identify the appropriate action and implementation of the selected action steps. Applying mitigation techniques to identified risks provides a more focused level of monitoring to minimize the potential effect of the high impact risks. The result of this process is an ordered list of risks the project uses to develop mitigation strategies. We assign ownership for tracking the mitigation and status of each risk. We capture a mitigation strategy for each risk in the Risk Tracking Document, conduct weekly updates, and communicate the risks to the K-MED project management as part of the Project State Report. In addition, we develop a detailed description of responses we plan to take for each risk. We review the mitigation strategy for each risk with KHPA and assess the effect on cost, schedule and resources. Figure 7-27 shows how we qualify identified risks by assigning to each a probability of occurrence and impact. Impacts may be in one of five areas: cost, schedule, business K-MED Figure Accenture s risk management process continuously monitors, assesses, and implements risk mitigation, lowering overall program risk and minimizing operational impact Probability of Occurrence (low, medium, high) Risk Radar and Assessment Severity of Impact (low, medium, high) Factor Level Management Attention Impact 6-9 High Management intervention Significant disruption to schedule and cost over required medium to long term 3-4 Medium Management attention Progress disrupted with moderate impact on required schedule and cost in short to medium term 1-2 Low Normal monitoring by Marginal impact with little or no impact on schedule and team lead cost K-MED Figure Risk assessment and classification leads to effective issue resolution 7-47

48 performance, acceptance and sustainability. A risk may affect more than one area so it is qualified in the area of greatest impact. We will combine the two scores to give each risk an overall risk exposure score of high, medium or low. These scores can accompany risks as part of our status reporting process to keep team members clearly informed about risks and their potential impact. Based on the risk rating, we will develop a corresponding risk mitigation plan to prevent the risk from occurring, if possible, or to reduce the severity of its impact. Mitigation actions for risks need to be tangible. We will assign each risk to an owning team or individual and closely monitor it. To help mitigate large-impact risks, we will incorporate into the K-MED work plan specific tasks to reduce or avoid the risk. Examples of various risks tracked early on at our social services clients in other states, include tracking State budget related risks that may impact scope or timelines. In addition, risks related to the availability of resources to complete required technical updates of existing systems or functionality in order to enable a new capability. One component of the risk mitigation plan is to develop a Risk Tracking document that we use to determine the magnitude of known risks and identify new potential risks. Risks include items of concern that require management involvement to enable project success by preventing issues from occurring. In summary, a key to the success of our risk management process is the ability and willingness of all team members to accept and understand the process and participate in it effectively to include the timely documentation and review of risks. Our risk management approach provides a simple methodology, a user-friendly toolset, and the training to implement an effective and proactive risk and mitigation process. Tools and Techniques Used to Manage Risk Good risk management is proactive, not reactive. Risks are an inevitable part of any project. We would bring the following to the K-MED project to help manage risk. Rational ClearCase as the repository we use to record, update, and report risk Microsoft Excel Quality management tools, such as Quality System Navigator (QSN), to manage and mitigate risks We would develop our Risk Management Plan early in the Plan Phase and continue to manage risk throughout the entire project lifecycle. As part of the monthly project management responsibilities, the project managers would review and update the Risk Tracking Document and mitigating strategies to reflect any changes. Risk Reporting Our team s leadership would work closely with your leads to keep risks visible, teams accountable, and escalate when necessary. Risk reporting will create project visibility and will engage executive leadership towards an acceptable mitigation strategy. We associate each risk to specific work streams to integrate risk management into our project execution fabric. This strategy limits the impact of realized risks on the project s schedule and cost baseline through timely information flow and mitigation. We will provide your leadership visibility into high-exposure risks including a three-month view to assess schedule risks. We will report risks and associated metrics to the K-MED Project Team management in weekly, monthly and quarterly status reports. This process will lower the likelihood project risks are realized by proactively identifying potential issues at each stage of 7-48

49 the project and by analyzing execution metrics to identify areas for improvement. We also monitor and track an Average Risk Exposure metric. This metric will measure the average level of risk exposure for all active risks and assesses our effectiveness at mitigating them. We report this metric monthly in our project s measurement tool and implement corrective actions as necessary. As part of the quarterly project reporting to KITO, we will work with KHPA Project Director to provide updated project risk information via the Risk Assessment Model (RAM) Summary Project Management Responsibilities Our proven project management methods and standards used around the world, combined with our understanding of your organization and working directly with you day to day will provide the K-MED project management team the tools to support our collaborative efforts Project Management Responsibilities A discussion of the project management responsibilities for the Contractor and the State follows. We believe that joint participation in project management is vital to the successful implementation of an on-schedule and on-budget K-MED System that meets the needs of its users and the goals of the KHPA. The Project Management Office (PMO) would oversee the project and will reflect the true teaming relationship between the KHPA and the Accenture team that you would like to establish. Figure 7-28 highlights the key features and benefits of our proposed project management approach. Project Management Responsibilities Benefits Oversight and Monitoring Allows for real-time analysis and decision making via a dashboard for centralized management data Augments KHPA s existing Project Management office Provides common processes / tools Governance Defines a clear structure for decision making and escalation of risks and issues Drives collaboration between key stakeholders Risk Management Assessment of risks Tight control, monitoring, escalation and active mitigation of risks Bring new ideas to mitigating existing organization risks to decrease issue realization ratio Focus on critical path activities and phase-containment Issue Management Tight control, monitoring, escalation and resolution of issues New ideas for resolving existing organizational issues Document Management Secure storage and easy retrieval of artifacts generated on project Strong foundation artifact storage and retrieval that support training and knowledge transfer services Configuration management of contractual documents Quality Management Vigorous internal Accenture measures that facilitates quality in work completed and deliverables created Enhances existing quality infrastructure across the organization Independent assessment of the project progress and risk through periodic quality reviews by an Accenture Quality Director 7-49

50 Project Management Responsibilities Benefits Scope Management Robust Change Control process that makes and communicates decisions on changes in a timely manner Active management of requirements and related changes to prevent scope creep and cost overruns Schedule Management Early identification of tasks that could delay schedule and hurt cost control measures Flexibility and ease of adjusting staffing to drive on-time completion of scheduled tasks Resource Management Highly qualified subcontractor that complements our delivery of services Virtually seamless integration Project Communications Promotes cross-team awareness and integration Encourages knowledge transfer and collaboration Figure The features of our project management approach help to facilitate an on schedule and within budget K-MED system that meets the expectations of the KHPA On time, on budget is no longer the sole true measure of success; the K-MED project needs to attain or exceed its value proposition. Our project planning and management approach will be closely tied to K-MED s overall strategy and as part of the KHPA s broader organizational transformation effort. We will establish a close working relationship with you to implement project management standards and practices aligned with the Project Management Body of Knowledge (PMBOK) and your State of Kansas Project Management Methodology. The leading industry practices have proven successful in hundreds of our health and human services projects around the world. We have a vision of One K-MED Project Team working in a streamlined manner throughout the project s lifecycle that includes both the Accenture team, KHPA and the State of Kansas stakeholder agencies and vendors Contractor Project Management Responsibilities Contractor Project Management Responsibilities These are mandatory activities that must be accomplished by the Contractor. 1. Prepare an outline and obtain approval from the State for the contents and format of each deliverable document before beginning work on the deliverable. 2. Responsible for taking minutes at meetings and providing written minutes within seven calendar days after the meeting. 3. Provide an implementation project manager and staff to conduct design sessions. 4. Obtain written approval from the State on the final deliverable. 5. Revise deliverables, if required, using State review findings to meet content and format requirements. 6. Develop, obtain approval, and maintain project work plan. 7. Identify issues related to the project using the State-approved process for documenting issues, processes for assigning issues to resources, and resolving issues. 8. Use State-approved change control / management processes for implementing changes in scope. 9. Report progress against the work plan through weekly written status reports, at weekly review meetings with the State Project Manager, and through a weekly update of the work plan / task schedule. 10. Deliver written status reports and updated work plans / schedules one business day before the status meeting. 11. Identify scope of work issues. Specify the basis upon which an issue is out of scope, including appropriate RFP references. 7-50

51 12. Obtain written State authorization before commencing work on changes to the scope of any task identified within the Work Breakdown Structure. 13. Identify any assumptions or constraints in developing the work plan. 14. Provide an approach to identifying and mitigating risk. 15. A work plan and schedule that addresses all activities required to accomplish the scope of work from project initiation through full statewide implementation of the K-MED System. 16. Deliver reports sufficient to meet Kansas Information Technology Office (KITO) Project Reporting requirements. The Accenture team will complete all of the Contractor Project Management responsibilities identified once awarded the contract. We will focus on the KHPA project vision, requirements and standards bringing our experience, tools and people to assist the KHPA s efforts. We are passionate about your mission and dedicated to working collaboratively with you to achieve it. We will produce project documents and artifacts necessary to successfully execute the tasks throughout the project as needed within time scheduling, deadlines, timeframes and milestones agreed to with the KHPA. Effective governance is an essential element to executing the K-MED project management responsibilities. K-MED governance would set direction for the K-MED project and would provide KHPA and the Accenture team leadership with decision-making guidelines to keep the project on track and to achieve the desired goals and project results. Our prior experience shows that the key elements of effective governance include organizational structure, leadership, and processes. In addition, clear roles and responsibilities to facilitate decision-making and issue resolution are essential. Figure 7-29 represents an example of a governance structure for the K- MED Project. The Accenture team will work with the KHPA to refine the project governance. This will include representation from Accenture leadership as Steering Committee participants. Additionally, from our prior experience, we suggest considering incorporating representation from other stakeholder vendors as well as representation from other large, medium, and small Management and Direction Strategic Direction Setting Program Schedule, Cost, and Resource Direction Program Scope/ Release Management Program Leadership and Decisions Status/ Risk/ Issue Resolution Status/ Risk/ Issue Communication Management Decisions = (Issue Resolution) Status/ Risk/ Issue = Communication Project Leadership and Direction Issue / Problem Resolution Governance Structure Project Steering Committee Monthly Program Management Weekly Kansas / Accenture Project Management Project Managers Quality Control Specialists Review performance metrics with Kansas executives Resolve quality concerns Use SharePoint to exchange knowledge Collect and validate performance metrics Maintain metrics on Executive Dashboard Coordinate QA reviews and QPI audits Weekly K-MED Weekly Leads Daily K-MED Members Reporting and Escalation Monthly Executive Briefing Steering Committee Meetings Project Status Reports Project Status Meetings Kansas Change Control Board (CCB) Financial Reviews Issue Resolution Schedule Variance / Performance Reporting Risk Management Cross K-MED Meetings Resource Management Team Status Reporting Risk / Issue Management Resource Management K-MED Figure We would help KHPA to establish a Governance structure and protocol that would facilitate timely decisions helping the project to achieve the State s desired goals and objectives 7-51

52 sized agencies that you will be working with. Accenture believes that a properly established governance structure will continue to provide the following benefits to the K-MED project: Facilitating implementation of an enterprise design and standardized processes Defining clear roles and responsibilities in decision making and issue resolution Driving collaboration between the K-MED project, the agencies, and all other key stakeholders Developing buy-in and commitment from executive leadership Providing a structure for checks and balances For details on the specific processes and the Accenture team approach to the various project management responsibilities please refer to the following sections: Deliverable Management - refer to Section Work plan/resource Management - refer to Section Project Status - refer to Section Scope Management - refer to Section Issue Management refer to Section Risk Management refer to Section State Project Management Responsibilities State Project Management Responsibilities The responsibilities of State personnel are stated for each task. There are a number of activities that reoccur in every task. Standard State responsibilities for each task are: 1. Perform overall monitoring and management overview of the project to ensure timely and satisfactory completion of all tasks and activities. 2. Review and approve the proposed outline format and content of all deliverable documents. 3. Review Contractor deliverables, determine the approval status of the deliverable, and provide written comment to the Contractor in accordance with the Quality Assurance Review Process (QARP) (see RFP Appendix 10). 4. Conduct weekly status meetings with the Contractor to review progress against the work plan. 5. Review weekly status meeting work products with the Contractor to review progress against work plan. 6. Analyze project issues and approve issue resolutions. 7. Monitor Contractor progress toward achievement of task milestones and contractor s adherence to the work plan and schedule. 8. Analyze proposed project scope of changes, and authorize those that are approved. 9. Provide notice to the Contractor of inadequate performance; request and approve plans of correction. 10. Assign State project managers to the various phases of the contract. 11. Prepare and deliver Project Management Reports. 12. Report on risk and status to the project Steering committee per project management standards. As indicated in Figure 7-30, we understand the KHPA responsibilities associated with project management and through our collaborative approach to management will work with the KHPA s project management team to provide the guidance necessary to keep the project on track to achieve the desired outcomes. State Project Management Responsibilities Acknowledgment 7-52

53 State Project Management Responsibilities Perform overall monitoring and management overview of the project to ensure timely and satisfactory completion of all tasks and activities Review and approve the proposed outline format and content of all deliverable documents Review Contractor deliverables, determine the approval status of the deliverable, and provide written comment to the Contractor in accordance with the Quality Assurance Review Process (QARP) Conduct weekly status meetings with the Contractor to review progress against the work plan Review weekly status meeting work products with the Contractor to review progress against work plan Analyze project issues and approve issue resolutions Monitor Contractor progress toward achievement of task milestones and contractor s adherence to the work plan and schedule Analyze proposed project scope of changes, and authorize those that are approved Provide notice to the Contractor of inadequate performance; request and approve plans of correction Assign State project managers to the various phases of the contract Prepare and deliver Project Management Reports Report on risk and status to the project Steering committee per project management standards Acknowledgment Figure Drawing on the KHPA experience and participation facilitates successful initiation of the project and provides timely direction, coordination, control, review and approval of the project efforts Specifically, the Accenture project management team will work closely with the KHPA project management team on the following efforts: Contract Management, including: supervision, control and coordination of our team s contractual obligations; managing contract compliance; managing deliverable process and schedule; managing the change control process; managing subcontractor agreements Fiscal Management, including: managing budgets, expenses, invoicing and financial reporting Project Management, including: risk and issue management, project schedule management and development, work planning and work tracking, resource management, quality assurance management, project measurement and reporting management, communication management, governance, regulatory and administrative budget management Office Management and Administration, including: project-office-facility management responsibilities; office administrative-support activities Information Security and Privacy including: data security protection, workplace safety and security functions Our Project Manager will work with the KHPA project manager and your project management team, to support the quality assurance process, formal deliverable review process, coordination of staff and stakeholder participation; work plan management, issue and risk management, organizing regularly scheduled meetings including the project kickoff and Steering Committee meetings. We will work collaboratively with your team on a daily basis to support compliance and reporting activities as they relate to the K-MED project. Additionally, working with you, our project management team will develop a Control, Standards and Procedures 7-53

54 document to emphasize and standardize consistency across activities, tasks, work products and deliverables. This will be developed using our methodology tailored to health and human services engagements as a starting point and then customizing it based on the standards in place for the State of Kansas. A well-organized project, following standards and common tools is one of the first steps to enabling a project to succeed Technical Architecture and Infrastructure Design The K-MED Solution Blueprint is our proposed enterprise architecture. It is built on the framework of the Accenture Public Service Platform (APSP), tailored to meet current and future healthcare challenges faced by KHPA. A proven enterprise architecture platform built from thousands of our public service projects worldwide, K-MED Solution Blueprint delivers simplified application and eligibility determination processes to Kansans needing healthcare services. KHPA is seeking a people-friendly, web-based system. Enterprise architecture will allow the separate, standalone systems to communicate using exposed shared services through a common architecture. Service Oriented Architecture (SOA) will have a prominent role in the implementation of the enterprise architecture required by the K-MED System APSP The foundation of the K-MED Solution Blueprint Accenture is a leader in delivering Service Oriented Architecture (SOA) solutions for systems large and small Accenture is active in standards organizations, including WS-I and W3C, to help shape the future of the SOA industry We invested $450 million in development of SOA technologies and methodologies over three years Accenture has a comprehensive understanding and point of view on SOA methods, standards, and roadmaps and how they would affect the K-MED Solution Blueprint enterprise architecture The proposed enterprise architecture and the supported standards are aligned with the specifications in the Federal Technical Reference Model (FTRM) KHPA has defined clear goals and objectives for the K-MED project. We have carefully studied your RFP to tailor an approach that helps increase reuse of your existing investments, provides a business focused solution and delivers a Service-Oriented Enterprise Architecture that meets your vision. We have identified 4 keys to successfully implement the K-MED Solution Blueprint enterprise architecture in Kansas: A Collaborative Focus on Your Vision, Requirements and Standards. Our teaming strategy outlines a mix of KHPA and Accenture resources for the configuration and installation of your architecture. We also will team with KHPA staff to create all proofs of concept. This approach allows us to better understand the current and ongoing requirements of the K-MED technical architecture. It also provides daily opportunities for Accenture team members to share project knowledge and skills with our KHPA teammates in preparation for a successful project transition. A Solution that Optimizes Your Existing Product Investment. As noted in the RFP, KHPA has devoted time and resources installing, configuring, and integrating a variety of current commercial products. We recognize the significance of this investment, and will work with you to incorporate its functionality in your new eligibility determination solution. The K-MED Solution Blueprint is a componentized approach that builds on and extends your investment in suitable ways through integration using a service-oriented architecture. A Service-Oriented Architecture Realizing Your Vision. The APSP Enterprise Architecture not only contains components, it also has the technical services and 7-54

55 documentation needed to develop quality applications. This lowers risk for Kansas and provides a loosely coupled approach for easy configuration and integration with other applications within KHPA. A Skilled and Dedicated Team. We selected an onsite delivery team that can begin confirming your requirements on Day 1 by working with your people to understand KHPA policies and requirements. Our team is committed to remain for the duration of the project and each member has strong skills in the delivery of service-oriented architectures. Our proposed solution for Kansas consists of two main components, APSP and several Oracle commercial products: Our robust asset, the Accenture Public Service Platform (APSP) APSP is a SOA-based Enterprise Architecture that provides a library of technical services specifically designed to integrate leading commercial products used by health and human service organizations. We have proposed the Oracle suite of products for the key components, and APSP integrates these components with your existing components for a map to the future. Our product roadmap A proposed mix of both new commercial products and those currently in use at KHPA, to help KHPA achieve its goals of modernizing its architecture while lowering total cost of ownership. APSP is a technical architecture that will enable KHPA to build client-centric healthcare services applications. By starting with APSP as the foundation for your enterprise architecture solution, we have lowered risk and cost through reuse of proven components. APSP is architected for modularity, and utilizes standards and open source protocols, including those set by the Web Services Interoperability Organization (WS-I), and World Wide Web Consortium (W3C). APSP integrates with leading commercial products from Oracle and IBM, as well as open source components from organizations such as RedHat, Spring and Apache, to deliver a complete, pre-integrated enterprise architecture. While we believe the Oracle products selected in this proposal provide the best solution for KHPA, APSP s modular approach allows integration with commercial and Open Source products from other vendors as well. APSP s modular approach allows Kansas the most flexibility to both re-use existing products and integrate with new products in the future. APSP contains established architecture libraries and frameworks providing patterns for business and technical services alike. APSP delivers a complete execution architecture that will benefit KHPA, as depicted in Figure These include security and audit services and application services including business rules, business process management, and workflow. APSP also provides integration with web portal, electronic forms, and reporting capabilities. APSP provides a next-generation, proven, enterprise architecture that will power KHPA s initiatives for years into the future. Figure 7-32 and Figure 7-33 show a selection of the services and frameworks available as part of APSP. Installing industry-leading components such as the products from Oracle is typically only one aspect to implementing a technical architecture. A large amount of technical development is required to build the business services required for new applications to communicate with commercial ones. APSP was designed and built from over a decade of public service experience, and includes the most common public service functions out-of-the-box. 7-55

56 More configurable, flexible portal interface APSP Self-Service Portal Portal Services A development platform and accelerators to speed business value APSP Public Assistance Portal Business Services Technical Services Technical services for quick modification, integration, and legacy renewal Integration and Workflow Services Application and Rules Engine Services Document Management and Reporting Services Common Services Open, highly scalable data services Data Services State-of-art Identity and Access Management Security Services Accenture Public Service Platform (APSP) K-MED Figure APSP is a flexible, services-based enterprise architecture that speeds development, lowers cost, reduces implementation risk and responds to change for better service APSP Technical Services Component Address Normalization Service Rules Engine Integration Services Code / De-Code Service Mail Helper Service Process Invocation Service Human Task Workflow Interface / Service Enterprise Search Service Security Audit Services The Address Normalization Service provides the developer with a service to validate and normalize an address. It can also calculate distance between two addresses. Product agnostic rules engine interface/service. Currently integrated and tested with Oracle Policy Automation (OPA) but service can integrate with other rules engines providing flexibility. Code/Decode service allows for a more flexible application through the externalization of static codes and related decodes. The Mail Helper Service provides a way for applications to send to users. It reduces the effort of the application developers, providing for sending an through the Spring mail protocol. This is a proxy service that provides for BPM invocation. By using a proxy service, APSP can integrate with other COTS BPM servers. A custom proxy service to integrate Human Workflow tasks with Oracle BPM or other COTS BPM product. This service allows human tasks to be integrated with automated tasks in BPM process flows. The Enterprise Search Service provides crawling, indexing and search capabilities across a wide-variety of data sources. Queries against the search service will be accomplished using Web-based graphical interfaces, XML Web services, or API interfaces. The APSP Audit Service writes data to a database/jms Queue/ File for recording authentication-related, authorization-related and business services events based on a common logging configuration. 7-56

57 Reporting Service Interface Document Management Integration Service Form Management Services (Forms Rendering) The Reporting Service Interfaces initiates and presents reports in APSP The Document Management Integration Service provides common services for retrieving and posting document metadata and documents. The Forms Management Service provides the capability for forms to be rendered and presented in APSP portlet views. System triggered events make use of the exposed services and API s in Adobe Livecycle Forms to produce and render forms. Figure APSP Technical Services APSP Technical Frameworks/Templates Component Effective Dating Utility The Effective Dating Utility provides an extensible effective dating framework that provides continuous and non-continuous effective dating methods. Non-continuous dating will allow conditional gaps in date ranges for data entities based on configurable type codes. Exception Handling Framework Application Integration Framework SOAP over HTTP Integration Adapter/Connector SOAP over JMS Integration Adapter/Connector Oracle Universal Content Management Provider Implementation Forms Architecture Framework Correspondence Architecture Framework Oracle Provider Implementation for Enterprise Search This framework provides application developers with a consistent way to handle exceptions across the application whether from services or object oriented components. APSP Integration Services provides the integration and messaging backbone of APSPbased applications. It uses open source protocols so it is not tied to a particular ESB or integration package. APSP connector that enables Simple Object Access Protocol (SOAP) to web services through the HTTP transport protocol, facilitating the integration and calling of web services. APSP connector that enables Simple Object Access Protocol (SOAP) to web services through the JMS transport protocol, facilitating the integration and calling of web services. Integration of Oracle Universal Content Management Provider Interface to provide document management and content management capability in APSP. The Forms Architecture Framework integrates Adobe LiveCycle forms within the overall APSP framework container to provide forms services for online applications. The Correspondence Architecture Framework provides for the ability to jointly handle singular, highly customized correspondence and high-volume, dynamic content correspondence. The correspondence architecture merges a layout with data to produce correspondence, then routes that correspondence to a printer, content management software or browser/pdf. Component that provides Enterprise Search Service through the Oracle Secure Enterprise Search. 7-57

58 APSP Technical Frameworks/Templates Component Simple Reference Application for Architecture This is a case management reference application that provides validation that the APSP technical architecture is configured properly. Batch Job Dispatcher Oracle Policy Automation Concrete Adapter for Rules Service Oracle Policy Automation Implementation Interface Encryption Services Custom job dispatcher to handle asynchronous batch execution using batch database queue. Oracle Policy Automation APSP implementation for in-memory or web-service based rules execution. This is an interface that allows a business object or service to call Oracle Policy Automation. It is built with open standards so that other rules engines could be called by the same interface. An encryption service and enablement service for APSP. Figure APSP Technical Frameworks/Templates The K-MED Solution Blueprint, based on the Accenture Public Service Platform, contains a comprehensive suite of commercial products from Oracle chosen to specifically address your requirements. The solution includes the Oracle products depicted in Figure KHPA Architecture Component Rules Oracle Product Engine/Transformation Hub Oracle Policy Automation (OPA) Access Administration and Management Oracle Access Manager ESB SOA Suite Workflow Component Business Process Management Suite Figure Oracle Components mapped to KHPA Architecture Component Rules These Oracle products were proposed after careful review of the RFP. In every case, these products meet or exceed the KHPA requirements listed. Our Experience using Oracle Accenture is a leading system integrator and operator of Oracle environments. Our Oracle practice has a special alliance with Oracle. We operate an Oracle Center for Innovation at Oracle s Headquarters in partnership with Oracle. Accenture is the largest system integrator of Oracle technology, in our twentieth (20th) year of teaming with Oracle. We top the list of all Oracle Service providers, including Oracle Consulting Services, with 3,800 Oracle projects completed or underway. Oracle products have been integrated with APSP from the earliest designs of the platform. Accenture works closely with Oracle experts in our San Antonio Delivery Center and our Oracle Center for Innovation to pre-configure SOA-based architectures built on top of the Oracle product line. We have a dedicated team of resources that is ready to deliver a successful technical architecture for KHPA. The Vendor must propose a solution that supports an SOA and Enterprise Service Bus (ESB) based solution. 7-58

59 The K-MED Solution Blueprint uses SOA Our Topeka team would work with KHPA to apply SOA methodology throughout the design and development, implementation and operational phases of the K-MED project. We have experience in implementing successful SOA systems for our clients, and have used that knowledge to develop a series of proven tools, assets and methodologies. We have applied these methodologies to the design of APSP, and would make them available to KHPA for use on the project. APSP, a true SOA architecture at its core, is the basis of the K-MED Solution Blueprint. Our APSP is a true SOA in that it we base it on the design of the services representing required business and technical activities. Our business services take into account your business processes, goals, principles, policies, service interfaces, and service components and implements services using service orchestration. Accenture SOA Strategy and Roadmap tools help businesses and organizations define prudent, immediate steps toward creating a solid business case to demonstrate likely benefits. KHPA will benefit from use of our Strategy and Roadmap Offering tool as it provides guidelines for identifying potential areas of your environment that can possibly benefit from SOA. The tool provides recommendations for steps the organization can take to help realize those benefits. Our Topeka Team is equipped with this tool as an optional activity to help KHPA identify how you can broaden the use of SOA in your environment. Our SOA Design and Delivery Excellence tools help our clients industrialize their delivery methods, supported by specific methodology, "accelerator" frameworks, training programs and development and test tools. Our SOA Design and Delivery Excellence tool assists in the establishment of SOA Governance. It provides a framework for formalizing the SOA development methods within the Software Development Lifecycle (SDLC). It looks at development activities, how they contribute to SOA, and makes recommendations for how SDLC development methods can be better organized/governed within the development environment. The Accenture Team is equipped with this tool as an optional activity to help KHPA identify application-methods of SOA governance throughout the development of the K- MED Solution Blueprint. Service Identification Framework (SIF) is a methodology based on practices and our extensive real-life experiences assisting our clients to identify services. Service Identification Framework (SIF) Fast Facts Our suite of SOA and web services assets and best practices cover the spectrum of needs for successfully launching, delivering, accelerating and managing an SOA initiative. Accenture has developed over 12,000 people with proven SOA/Enterprise Integration design and delivery skills, with 1,500 Global Technology Consultants who specialize in SOA architecture. Accenture has developed SOA and web services methodologies and tools from handson experience delivering 1,000+ SOA/Enterprise Integration programs. Our strategic alliances enable us to efficiently leverage vendor relationships to bring the latest capabilities to our clients, and implement them as rapidly as possible. Identifying services is a key aspect of an SOA implementation. The Accenture SIF, illustrated in Figure 7-35 above, enables our design teams to draw on past, successful experience and leading practices to assist KHPA in identifying business services. The result is an inventory list of reusable and maintainable services. Offers guidance on examining business and technical requirements for finding common functionality between components and systems 7-59

60 Identify Business Domains Service Identification Top-Down, Business-Driven Approach Identify Business Processes Analyze Existing Applications Identify Common Functionality Bottom-Up, Component-Driven Approach Identify Application Patterns Identify Business Services Identify Component Services Service Definition K-MED Figure The Service Identification Framework (SIF) can be used to assist KHPA in defining and developing services Focuses on the ability of services to be reused and maintained over time Assists in applying a service model, level of granularity, and quality for KHPA Offers top-down (business-focused) and bottom-up (application-focused) approaches in creating an inventory of services Accenture is a Leader in SOA Accenture is a leader in SOA. We have received accolades from IDC. We have technology alliance relationships with the leading providers of SOA products, including Oracle and others. We have thousands of system integration professionals skilled in SOA technology and experienced in delivering hundreds of projects using SOA approaches. KHPA can use existing investments and realize the SOA vision with our proposed solution. It integrates existing systems while being a scalable, yet flexible solution as your enterprise expands and your user base increases. It is the technology enabler behind our business solution and promotes reusability of shared services. We achieve this by integrating COTS and open source technology products using open standards. Accenture has experience implementing SOA A large State agency, where Accenture is implementing a pension/retirement modernization system, is undergoing development upon an Enterprise Technical Architecture (ETA), which we built based on open standards. The web-services frameworks of the ETA implemented standards supported by Web Service Interoperability (WS-I) and Organization for the Advancement of Structured and Information Standards (OASIS). A Large US Utility, where Accenture delivered a SOA enterprise architecture encompassing supply chain, customer care and billing, and distribution serving 15M people in 180,000 sq-km area. North American Retailer, who ranks among the Fortune 500, where Accenture delivered a SOA IT architecture and governance system to support trading-partner integration, store forecasting, and accounts payable automation systems across 900 store locations. French Revenue Agency, where Accenture and DGI delivered a service-oriented architecture implementation based on open-source solutions compliant with interoperability standards. Norwegian Savings Bank Consortium, where Accenture collaborated with the client on a major three-year program to design and implement a sophisticated SOA approach for building a credit process portal solution with common services and a common front-end interface for numerous credit-related business processes. 7-60

61 Australian Health Services Company, where we: Seamlessly transferred information between diverse parts of the organization Enabled connectivity between primary care providers and the public health system Provided a client-centric view of information, drawing data from multiple independent systems The ESB must be based on open standards and allow for the State to leverage existing IT investments. The ESB must be able to support a variety of standard messaging protocols and transform data into a common data format. It must allow the ability to change orchestration, rules, data mapping, and relationships between systems with minimal effort and disruption. The K-MED Solution Blueprint uses an Enterprise Service Bus (ESB) Our proposed ESB uses the Oracle Service Bus COTS product for internal and external service integration and interaction. The solution provides a central location to expose services using open standards. Figure 7-36 below describes the function of a robust Enterprise Service Bus and how the Accenture Team plans to incorporate each in delivering a flexible and easily maintainable eligibility determination system for the State of Kansas. RFP ESB Requirements The ESB must be based on open Standards Our K-MED Response Our proposed ESB solution uses the off-the-shelf product, Oracle Service Bus. Oracle Service Bus offers a ESB with support for standardsbased integration The ESB must leverage existing IT investments The ESB must be able to support multiple messaging protocols The ESB must be able to transform data into a common data format. The use of the proposed ESB to leverage existing IT investments is dependent upon the legacy system's ability to expose, produce or consume services. Oracle Service Bus includes native support for the following commonly used, standard messaging protocols/transports: EJB Transport HTTP, FTP, SFTP, and File Transports Java Connector Architecture (JCA) Transport Java Messaging Service (JMS) Transport Oracle BPEL Process Manager Transport Oracle Data Service Integrator (DSP) Transport Oracle Service Bus Transport Web Service Transport with support for web services interoperability through WS-I Basic Profile Oracle Service also provides the capability to create or install custom transport providers. Our proposed ESB solution provides message transformation to enable communication between systems. The APSP Integration Architecture provides an integration layer that transforms messages, adding a layer of abstraction over specific integration technologies for a modular and extensible solution Transformations are programmable using XML technology Oracle Service Bus acts as an intermediary between the sending and receiving systems in providing the following message transformation features: 7-61

62 RFP ESB Requirements The ESB must have the ability to change orchestration, rules, data mapping and relationships between systems with minimal effort and disruption. Use of the ESB must ensure that primary application functions and data are available via external industry standard APIs, web service calls or other acceptable processes. The ESB must support a High Level Client Index that is supported by services. Our K-MED Response Validation of incoming messages against schemas Selects a target service provider based on message content/headers Transforms messages into a common data format using XQuery or XSLT Supports message callouts to other services to gather additional information for transformation Our proposed ESB solution provides the ability to change orchestration, rules, data mapping and relationships between systems with minimal effort and disruption. APSP provides capabilities to configure integration capabilities The APSP Integration Architecture includes configuration properties in XML files using Spring Oracle Service Bus configures integration properties in a management console, for ease-of-maintenance Our proposed ESB solution ensures that complex, mediated integration occurs for message routing via external industry standard APIs or web service calls Our proposed ESB solution will support the K-MED acquisition and integration of a High Level Client Index through the use of web services or industry standard APIs. Figure Our ESB solution meets Kansas requirements now and in the future. Accenture brings extensive experience implementing ESB solutions to Kansas. We can leverage the knowledge and experience of more than 41,000 people worldwide with SOA skills, training and industry experience, including more than 5,600 people in North America with experience implementing Oracle solutions. Accenture has been teaming with Oracle for twenty years. Our people and experience provide Kansas with the key components for designing and implementing a robust yet modular solution ready to support Kansas needs today and establishing the foundation for the future. For example, Accenture implemented Oracle Service Bus at Norwegian Savings Bank Consortium to reduce the risk of its loan portfolios with an end-to-end, credit-processing platform that would deliver consistent, high quality credit assessments. Accenture collaborated with the Bank Consortium on a major three-year program to design and implement a sophisticated SOA approach for building a credit process portal solution with common services and a common front-end interface for numerous credit-related business processes. The Oracle ESB served as the messaging backbone, providing service reuse, routing and data transformation capabilities while exposing services to the Web Portal and orchestrating services across the enterprise. With Accenture s solution, Norwegian Savings Bank Consortium realized benefits of having established a flexible platform for future growth based on reusable services through web services and XML and stringent service contracts. In addition to experience, Accenture brings its methodologies. The Accenture Delivery Architecture for SOA provides a set of patterns, practices, designs and code shells to jumpstart the design and delivery of integration architectures. 7-62

63 Our Proposed ESB Solution uses APSP Our proposed ESB solution provides the sharing of information in a controlled, secure fashion. It uses a framework approach to lower risk. Figure 7-37 illustrates the APSP solution, which enables integration with internal and external services and systems. The ESB provides the following advantages while integrating with services: The ESB can act as the firewall and a gateway between the external system and the services exposed Additional security consideration can be enforced for external systems accessing the services without impacting their use by internal applications External services can be invoked by internal applications in the same manner as internal services Web Portal At the beginning of this section you indicated the desire to implement a people-friendly, web-based system. To this point, we have discussed the K-MED Solution Blueprint technical and enterprise architectures built on SOA and their use of an Enterprise Service Bus. Based on that architecture, we now turn to the APSP Public Assistance and the APSP Self-Service Portals that are the user interface for KHPA staff, Partners and Kansans needing healthcare eligibility determination. The K-MED Solution Blueprint Portals: a web-based, multi-channel solution The APSP Public Assistance and the APSP Self-Service Portals are the framework for integrating information, people and processes across organizational boundaries. It provides a secure unified access point in the form of a browser-based multi-channel user interface. It is designed to aggregate and personalize information through application-specific portlets. It is also Accenture Public Service Platform Portal External Systems (Consumer) Integration Layer (Consumer) XML Gateway (Security) Standards Based Invocation Enterprise Service Bus Adapter Legacy-, Standards-, Non-Standards Based Invocation Other APSP Components BPM-Rules-Forms-Reports (Provider-Consumer) Integration Layer (Provider) Integration Layer (Consumer) APSP Core Common Services Point-to-Point Interaction (if required) Integration Layer (Provider) Integration Layer (Consumer) APSP Security Services External Systems (Provider) K-MED Figure Accenture provides a flexible and modular ESB solution to support KHPA s SOA vision, building a foundation for future growth 7-63

64 an application style integrating many different types of applications and services. The APSP Public Assistance and the APSP Self-Service Portals provide workers and clients with a rich application using modularized task specific portlets that facilitate how worker progress through work elements and business processes or clients navigate self-assessment and online application tools. The APSP Public Assistance and the APSP Self-Service Portals unifies content, information and business functionality under a common theme to provide the user with a one stop tool to accomplish their chosen tasks. The APSP Public Assistance and the APSP Self- Service Portals sit within our SOA framework, facilitating how applications and services are tied and orchestrated to form unique and powerful business processes. The K-MED Solution Blueprint portals provide five fundamental features that create the K-MED System: Single Point of Entry Integration Federation/Reuse Personalization Security Single Point of Entry The APSP Public Assistance Portal provides single sign-on capabilities between users and various systems. It will integrate with security software and protocols to authorize and validate users of the system, requiring a user to authenticate only once. Access control lists manage the mapping between the services and content available through the portal and the user s access authority. This feature allows the APSP Public Assistance Portal to be the single point of entry to access information, content, and services for K-MED workers who use KHPA network sign in credentials or clients who must authenticate using a High Level Client Index (HLCI) number. Using additional portal features the APSP Public Assistance Portal is presented to workers as a single unified application under one common theme. The portal pages of the APSP Public Assistance Portal are job-based and are displayed to the user in a logical order to facilitate task completion. These job-based pages merge content and services from multiple sources and present them logically in functional areas directing users from page to page based on the task. Users have single sign-on access to several exposed independent business services which are displayed within the portal as functional areas. The services and content presented by the APSP Public Assistance Portal are coordinated by managed workflows leading users along a logical progression of activities to complete assignments. Integration Portlets are web components that have special properties to allow them to be easily plugged in and run in enclosed applications like portals. Portlets are discrete units of code that are aggregated into a portal page and represent self-contained modular functionality of an application or web service. The APSP Public Assistance Portal connects users to functions and data from multiple independent sources through the use of portal pages with discrete portlets. APSP Public Assistance Portal pages are displayed as a collection of non-overlapping portlet windows, with each portlet window displaying a functionally discreet portlet. Portal pages unify data, information, and functionality personalized for each user. The APSP Public Assistance Portal worker home page welcomes users with multiple portlets presenting Alerts and Notifications, Personal Calendar and New Requests, Learning Support, and Customized Modules that will pull such functions as Address Location Lookup. Additional portlets bring forward external system functionality and services. 7-64

65 APSP Public Assistance Portal portlets follow existing standards currently governing portlet development and interoperability. K-MED Solution Blueprint follows Web Services for Remote Portlets protocol (WSRP) which provides portlets with a web services standard. Following this standard, KSB is capable of plug-n-play of remote running portlets from disparate sources. These portlets also conform to Java Portlet Specification (JSR) 168. JSR 168 is the Java standard for portlets; its goal is to enable interoperability between portlets and various portals. It defines the contract between portlet and portlet container, and a set of portlet APIs that address personalization, presentation, and security. The specification also defines how to package portlets in portlet applications. Prior to JSR 168, each portal container had its own proprietary portlet API. This made switching vendors difficult. JSR 168 helped resolve those issues, as well as making it easier for third-party portlet developers to flourish. Portlets are developed using traditional presentation services technologies. K-MED Solution Blueprint leverages Oracle WebLogic Portal, which provides developers with portlet templates, libraries, and building blocks. These resources act as a starting point reducing development time as developers can drag and drop portlets using a graphical development approach. Following Web Services Definition Language (WSDL), the K-MED Solution Blueprint is capable of deploying remote portlets within its pages that are run and maintained by remote or external systems. Portlets will be defined and built once and placed graphically using the Eclipse-based Oracle Integrated Development Environment (IDE). Eclipse is a free software/open source, platform-independent software development environment. It integrates a source code editor, compile/link/interpreter, code object libraries, code generation and debugging tools into a single system. Since portlets are built using traditional presentation services technologies they can be extended using common JSP/Servlet and XML/XSL technologies. Federation/Reuse The APSP Public Assistance Portal promotes reuse of portlets by following JSR 168 standards and WSRP protocols. Adhering to these standards and protocols allows the portal to be modularized and gives it the ability to use content provided by other portals. Portlets from other internal or external portals can be added to APSP Public Assistance Portal pages with the ability to run remotely from the source portal without requiring additional code. Likewise, the K-MED Solution Blueprint will publish desired portlets for integration and use by other portal systems. This will allow the K-MED Solution Blueprint to improve interoperability between portal implementations and simplify the process of sharing functionality with other agencies or external systems. In addition, the K-MED Solution Blueprint allows for a create once-deploy many approach. Individual portlets can be designed and developed once and deployed to multiple portal pages across the APSP Public Assistance Portal. Portlets can also be deployed multiple times within the same page. Portlets built using JSR 168 standards prevent portal technology lock-in should KHPA desire to change vendors. Personalization The K-MED Solution Blueprint provides users with focused content and services based on role, profile, current session, user request, and other data. Portal pages and portlets display information, applications, and business services specified for the logged in user. The APSP Public Assistance Portal content can be targeted to individual users or customized for users based on group association or assigned role. Personalization portal services identify user access privileges and rights and displays appropriate portlets and content based on the user s access rights. Users are able to swap portlet modules within their workspace page to suit their business need. Furthermore, tabs and navigation are personalized to the user based on authorization. This 7-65

66 personalization feature provides an enhanced user experience as content is targeted to each user s interest and workload. Although content and services within the APSP Public Assistance Portal are specific to users-based roles and workgroups, there are areas within portal where the user can personalize information. The K-MED System enhances the work experience by providing Users portlets to view various data sources of their choice to aid in job completion. Portal Security Features The administration features of the K-MED Solution Blueprint portal make it easier to add groups, users, and portlets without having to recode the user interface to support these changes. Administrators can add new users, groups and roles and apply privileges at different security levels through the admin console. Portal administration features also provide a web interface for administrators to manage portal components such as pages and portlets. Portals allow administrators to adapt the look and feel of the portal to fit your organization standards, as well as customize page content in accordance with KHPA business rules and user profiles. The APSP Public Assistance Portal provides the ability for portal administrators to limit specific types of content and services users can access. It allows for the linking of external security services to users and groups established within portal itself. Our WebLogic based solution uses a unified security model allowing APSP Public Assistance Portal to tie our native portal security to a more robust security and access management implementation. The Portal user interface is managed through the incorporation of security and assigned privileges to users. Privileges drive what is presented to the user and ultimately what users can do within the K- MED Solution Blueprint portal. The proposed solution must ensure that primary application functions and data are available via external industry standard APIs (Application Programming Interfaces), web service call, or other acceptable processes. The architecture must support a High Level Client Index (HLCI) that is facilitated by services. The architecture of the K-MED Solution Blueprint is based on the APSP SOA using the Oracle Enterprise Bus. This allows internal and external application functions to be made available to KSB users, provided the primary application can expose the desired function as a service. Once services are identified and catalogued through the use of our Services Identification Framework (SIF) they can be made available to K-MED users through industry standard APIs and web service calls. The same interface approach will be used for the acquisition and integration of High Level Client Index (HLCI) numbers within the K-MED Solution Blueprint Multiple Environments The Vendor shall describe their commitment to multiple environments as defined by KHPA for a fully operational architecture for a system of this magnitude. At a minimum, KHPA expects the solution to include or support the below-named environments. The K-MED Contractor is responsible for the setup and maintenance of the Development environment and the Reference environment. This includes all network components, computer hardware platforms, software, servers, and the development facility. The K-MED Contractor must provide configuration information for the remaining environments to meet the requirements of this RFP. The State intends to provide hosting services separately. The setup and maintenance of the other environments will be the responsibility of the hosting provider. 7-66

67 When KHPA or the State upgrades software / hardware infrastructure to the next evolution / version of the software / hardware operating system or component, the Contractor must provide any system modifications or additions necessary to enable K-MED to operate according to the requirements of this RFP. KHPA shall provide a minimum of 30 calendar days advance notice to the vendor of any scheduled technical infrastructure changes. The Contractor is required to communicate any system modifications or additions required to maintain all mandatory technical and performance expectations due to software / hardware upgrades as soon as possible, or at least 60 calendar days prior to the upgrade. Each proposal shall address the Proposer s solution for recommended technical environments. The State has prepared a list of suggested technical environments presented below. The Proposer may alter this list or include additional environments, if necessary. The proposal must specifically state how any environment will be used and how the vendor would propose that support and maintenance of the various environments be handled (e.g., hosting provider or K-MED Contractor). Accenture will be utilizing multiple environments to develop the K-MED solution. We will work with KHPA and the hosting provider to configure and maintain environments that will allow the team to work effectively and efficiently developing, testing and delivering the K-MED solution. Following is a list of the proposed environments, the purpose of each environment, how each environment is to be configured, and the expectations for support and maintenance of the environment. Common components Accenture will be using a very cost effective approach to implementing our non-production environments. We will take full advantage of virtualization technologies and the power of the latest server technologies. Environments will share hardware devices but be segregated using zones from an operating system level. Figure 7-38 below is a high-level depiction of how the hardware and software may be configured using these technologies. The processing power and processor threading of the servers is such that one server can run multiple software programs simultaneously with very little or no impact on each other. It is expected that using these technologies will reduce the amount of maintenance due to the reduced number of physical servers. We have chosen to group environments with similar usage patterns or functions together. The top of Figure 7-38 illustrates the Production environment. Below that are the non- Production environments other than the Development and Reference environments (which will be housed separately). As an example of how we implement virtualization across hardware, the web servers for each environment will be located on the same hardware, but segregated such that each will be capable of having a different configuration. This is necessary as each phase of the software development lifecycle may contain different versions of the application. This concept applies to all components in the application tier as well. 1. Development. The Development environment will be used by the Contractor to develop and unit test all software and software updates. This Development environment will be used by the Accenture team to support the customization of components of the APSP solution. The Accenture solution will be primarily modified using the skills and experience from our San Antonio Delivery Center (SADC). Customizations specific to K-MED will be developed and integrated with the APSP solution 7-67

68 Production Environment Web Servers Access Mgt. Server Directory Server Application Server Web Logic Server BPMS Forms / Reporting Web Servers Access Mgt. Server Directory Server SOA OPA Forms / Reporting SOA OAP Application Server BPMS Web Logic Server Interfaces OEM Backup/ Replication Audit Vault Audit Vault Production DB Node 1 Production DB Node 2 Reporting DB Non-Production Environment SOA BPA OPA Web Logic Server Diagnostic and Management SOA BPA OPA Web Logic Server Diagnostic and Management Portal Dev Forms / Reporting Access Mgt. Server LDAP Diagnostic Develop Tools System Test Navigation Audit Vault UAT / Staging Audit Vault OEM System Test UAT Training System Test UAT Staging Conversion Integration Figure Accenture uses virtualization technology to stack more applications into fewer servers resulting in lower hardware, software and maintenance costs while still providing performance and redundancy K-MED using this development environment. The Development environment will consist of a small number of servers to support the K- MED specific modifications to the Accenture solution. One server will support a database with multiple instances of a small data set. This will be used by the developers to design and test their 7-68

69 code. The other severs will support the tools necessary to modify the pages, rules, and configurations necessary for development. This environment will be hosted from the SADC. The development environment will be supported by the Accenture team. Upgrades and patches will be applied by the Accenture team. Configuration changes will also be made by Accenture. The changes made to the environment will follow the Configuration Change process. 2. Reference. The Reference environment is a copy of the COTS or state transfer system as it was initially delivered to K-MED. This is where analysts can go to answer the question, How did the original work? This Reference environment is a copy of the C-IV system running on the APSP architecture as it was initially delivered to KPHA and will primarily be used during the design phase of the project as a reference to how features of the system work. Analysts will then be able to determine the necessary modifications to meet requirements and desired functionality. A small database will be set up with minimal data. None of the data will be taken from a production system. The Reference environment will be housed in the Accenture SADC. Due to the web-based nature of the application, an internet connection and web browser are all that are needed to access the reference application from anywhere. Access to the environment will be coordinated with KPHA. The reference environment will be supported by the Accenture team. Upgrades and patches will be applied by the Accenture team. Configuration changes will not be made. This will be a static environment with only hardware and system software changes being made as required remaining compliant with licensing and security measures. 3. Integration. The Integration environment will be used to conduct module or string testing in a very controlled technical setting. The Integration or Assembly Test environment will be used by the Development Team to verify the interaction of separate program modules. A test database, configured for the next release of software, will be set up with a smaller set of masked production data. The Integration environment shares servers and software instances with other non-production environments. A database environment is set up specifically for integration testing. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Development Team is expected for work done on this environment. 4. Interface Testing. Because of the unique nature of interface testing, the Interface Testing environment is used exclusively to test interfaces. The Interface Testing environment will be used by the Test Team to validate the connection and transfer of information with interface partners. A test database, configured for the next release of software, will be set up with a smaller set of masked production data. Interface testing deals mostly with connection to other systems and exchange of data. Interface connections and file drops will be tested on a server shared with web services. Figure 7-38 depicts the configuration in which the Interface Testing environment will reside. This environment should be supported by the hosting provider. Implementation of upgrades 7-69

70 and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test Team is expected for work done on this environment. 5. Conversion Testing. Because of the unique nature of conversion testing, the Conversion Testing environment is used exclusively to test conversions. The Conversion Testing environment will be used by the Conversion Team to validate the extract, transformation and load of data from the different source systems into the K-MED system. Multiple conversion databases, configured for the production release of software, will be set up with a set of masked production data. The Conversion environment is configured to mostly on a database server. The extract, transformation, and load of data will all be done on this database. It is expected that there will be several instances of the source and destination data as conversion routines are developed and tested. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Conversion Team is expected for work done on this environment. 6. User Acceptance Testing. The User Acceptance Testing environment will be used by the State to test major software updates before moving the updates to the System Testing Assurance environment. The User Acceptance Testing (UAT) environment will be used by the State to test major software updates before moving the updates to the System Testing Assurance environment. Prior to implementation, this environment will also be used by the State to test converted data. Other uses for this environment may be acceptable depending on the timing and coordination of testing activities. A production sized database will provide a masked copy of production data or actual production data depending on the scheduled use of the environment. As depicted in Figure 7-38, the UAT environment is configured as a copy of the production environment. The web and application tier servers are the same as those in production. In this environment, however, the hardware and software have been allocated across smaller pieces of the servers. Due to the smaller number of users accessing this environment, the scale is very similar to that of the production environment. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test Team is expected for work done on this environment. 7. System Testing. The System Testing environment will be used to perform the final testing on approved system changes before these changes are migrated to the Production or Training environments. The System Testing environment is an exact replication of the Production environment. This helps ensure that approved modifications do not have an undesirable effect or an unintended consequence on the system itself. The System Test environment will be used by the Test Team. It will have a production size database with production data masked for testing. 7-70

71 The System Test environment is configured as a duplicate of the Production environment. The databases use clustering technology and each of the web and application tier components are redundant across multiple servers. As shown in Figure 7-38, the hardware components are the same as in Production. This environment makes efficient use of the servers by only utilizing the processing necessary for the number of users expected in the System Test environment. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test Team is expected for work done on this environment. 8. Training. The Training environment will be used by State staff during initial, ongoing, new staff, and any other State required training. The Training environment will be used by the Training Team for training of State staff during initial, ongoing, new staff, and any other State required training. It will also be used by the Training Team for the development of training material. The training environment will use a pre-determined release of the K-MED code base along with the appropriately configured database. The data will be a masked production data configured for the various training scenarios. The Training environment is configured much the same as other non-production environments. Figure 7-38 shows the separate security server for training. This is due to the number of training users as well as the difference in Training environment users from user of other non-production environments. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Training Team is expected for work done on this environment. 9. Emergency Fix. The Emergency Fix environment will be a copy of the Production environment that will be used to apply emergency fixes for the system that can be tested without affecting the other environments as other testing or training may be occurring. The Emergency Fix environment will contain a copy of the code and database in production or staged to be put into production. This environment may be used to apply emergency fixes for the K-MED system that can be tested without affecting the other environments as other development, testing or training may be occurring. The environment may also be used by developers and/or KHPA analysts to verify specific, data related issues with the production system. Access to this environment will be tightly controlled. It will contain a set of production data. The Emergency Fix environment shares servers and software instances with other non- Production environments. A database environment is set up specifically for testing in this environment. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test and Release Teams are expected for work done on this environment. 7-71

72 10. Production. The Production environment will be used by the State to manage real client data, their eligibility, and cases. The Production environment is set up with redundancy for each hardware and software component in order to increase system availability as depicted at the top of Figure The servers are set up to operate multiple applications without affecting one another. For example, the Web Service application, the Access Management Service application and the Directory Service application are all on the same physical hardware but segregated using Solaris zoning features. The Production database is clustered across two server nodes using Oracle s Real Application Clustering technology. This will improve the availability of the database and reduce the load on each of the servers during normal operations. A third database is available for reporting. This database will be kept up to date with production data using Oracle s DataGuard feature. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with all teams is expected for work done on this environment. All environments must be controlled by the Contractor s proposed configuration management methodology. As indicated above in each specific environment description, the environments will be controlled using the Accenture Team Configuration Control process Proposed Environment Configurations Each proposal must outline the configuration requirements to support the set up and maintenance of all proposed K-MED environments, including those environments that would logically fall to the hosting provider to maintain. To the extent possible, the Proposer shall factor all known variables into this response, including business requirements, technical requirements, business continuity requirements, volume metrics, concurrent users, and transaction response time. The Proposer shall provide these specifications for each environment in the Technical Environment Configuration Requirements Report. A separate report form is required for each environment. The template for the Technical Environment Configuration Requirements Report is found in RFP Appendix 14. Due to the virtualization concept proposed, the following reports will include information that is shared across multiple environments. The non-production environments will refer to the Integration environment report for the hardware and software components that are shared across each of these environments. This will be done so that components are not mis-counted when determining quantities or cost. The production, development and reference environments will not be sharing components with any other environments. The development and reference environments will be hosted at the Accenture SADC. Technical Environment Configuration Requirements Report The proposal must provide configuration information to support the setup and maintenance of K-MED development, reference, integration, interface testing, conversion testing, user acceptance testing, system testing, training, emergency fix, production environments, and any 7-72

73 other vendor-proposed environment, as well as all data maintenance functions to be performed by the hosting provider. The Proposer shall use this form to provide the configuration information to KHPA as part of its proposal. A separate sheet is required for each environment as well as a total proposal summary sheet. 7-73

74 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing Conversion Testing User Acceptance Testing System Testing Training Emergency Fix _X Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer 9 kps 24 hours Inbound Transfer 16 kps 24 hours Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Cisco 2 Server Server (Web Server/Database Server) Describe each server and their configuration needed Shared server for the web tier and application tier Audit Server, Management Server, Backup Server, Interface server OS Version / License Sun T core 1.65GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16 GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Monthly backup OS Version / License Sun x cpu Intel Xeon E core, 2.40GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16GB Memory External Storage Connection(s) Backup option and Frequency Monthly backup

75 Production Database Server Reporting Database Server Middleware Hardware/Software OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup 2 1 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle SOA Suite for Oracle Middleware Oracle Business Process Management Suite Diagnostics Pack for Oracle Middleware Oracle Policy Automation Oracle WebLogic Portal COTS product 8 cores 8 cores 16 cores 8 cores 4 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Congnos Business Intelligence Adobe LiveCycle Forms Control-M Batch Scheduler APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product 7-75

76 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle Database Enterprise Edition w/ options Oracle Database RAC option Oracle Database Audit Vault option Oracle Database Grid Control option Oracle Database Diagnostic Pack Database Change Management Pack Configuration Management Pack for Oracle database Application Server Licensing 20 cores 16 cores 4 cores 4 cores 20 cores 20 cores 20 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle WebLogic Suite Reporting Software and Server detail 16 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. The Cognos BI software will run on the Reporting Server identified above. The licensing information for Congonos is also listed above. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 7-76

77 technical assistance. Oracle Access Manager employee users Oracle Access Manager non-employee users Monitoring and Reports 1300 users users Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Several Oracle products listed above as components of the database will be utilized for monitoring and reporting on the application and infrastructure. Included in this list is Oracle Grid Control. A component of Oracle Enterprise Manager that allows monitoring of all Oracle software components in the infrastructure. DBA Services Depending on the skill level of personnel, the K-MED database architecture solution proposed by Accenture should be able to be managed by 2 FTEs. In addition to the standard roles and responsibilities of a database administrator, the Accenture solution requires knowledge of the Oracle RAC technology. The production database will be set up on a two-node RAC. A separate database for reporting will be updated using Oracle s Active DataGuard technology. Backups should occur daily for incremental backups and weekly for full or snap-shot backups. Managed Backup Retention Schedule 2 FTE Most of the systems in the K-MED solution will be static in the configuration and data they contain. Therefore, other than the backup of database storage, the servers should only need backup on a monthly basis or as often as new releases or updates are applied to the systems. The retention schedule for the backups depends primarily on the tolerance that stakeholders will have for recovering missing or corrupt data. It is recommended that daily backups be secured for one month, weekly backups be secured for three months, and monthly backups be secured for one year. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Oracle database tools included in the components above will be used to manage database backups. 7-77

78 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference _X Integration Interface Testing Conversion Testing User Acceptance Testing System Testing Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer hours Inbound Transfer hours Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Cisco 2 Server Server (Web Server/Database Server) Describe each server and their configuration needed Web Servers Audit Server, Management Server, Backup Server, Interface server OS Version / License Sun T core 1.65GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16 GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Monthly backup OS Version / License Sun x cpu Intel Xeon E core, 2.40GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16GB Memory External Storage Connection(s)

79 Database Server Conversion Database Server Middleware Hardware/Software Backup option and Frequency Monthly backup OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup 2 1 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle SOA Suite for Oracle Middleware Oracle Business Process Management Suite Diagnostics Pack for Oracle Middleware Oracle Policy Automation Oracle WebLogic Portal COTS product 8 cores 4 cores 8 cores 4 cores 4 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Congnos Business Intelligence Adobe LiveCycle Forms Control-M Batch Scheduler APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product 7-79

80 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle Database Enterprise Edition w/ options Oracle Database RAC option Oracle Database Audit Vault option Oracle Database Grid Control option Oracle Database Diagnostic Pack Database Change Management Pack Configuration Management Pack for Oracle database Oracle Data Integrator Application Server Licensing 36 cores 32 cores 4 cores 4 cores 36 cores 36 cores 36 cores 4 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle WebLogic Suite Reporting Software and Server detail 8 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. The Cognos BI software will run on the Reporting Server identified above. The licensing information for Congonos is also listed above. Security and PCI Services 7-80

81 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle Access Manager employee users Oracle Access Manager non-employee users Monitoring and Reports 650 users 500 users Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Several Oracle products listed above as components of the database will be utilized for monitoring and reporting on the application and infrastructure. Included in this list is Oracle Grid Control. A component of Oracle Enterprise Manager that allows monitoring of all Oracle software components in the infrastructure. DBA Services Depending on the skill level of personnel, the K-MED database architecture solution proposed by Accenture should be able to be managed by 2 FTEs. In addition to the standard roles and responsibilities of a database administrator, the Accenture solution requires knowledge of the Oracle RAC technology. The UAT database will be set up on a two-node RAC. Due to the virtualization of the servers, the databases will contain instances from multiple servers. Managed Backup Retention Schedule 2 FTE Changes in the non-production environments are very dynamic and requires backup on a routine daily basis. Also because of the dynamic nature of the environments, retention of configurations and data is not necessary beyond a short period of time. Different environments will have different backup and retention schedules. These schedules will also change as the activity in an environment changes. Standard retention should be based at one month. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Oracle database tools included in the components above will be used to manage database backups. 7-81

82 Proposer Name Environment (Provide detail for each environment) Accenture _X Development Reference Integration Interface Testing Conversion Testing User Acceptance Testing System Testing Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Web Server and Application Servers Database Servers Middleware Hardware/Software The Reference Application is hosted in Accenture s Delivery Center. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle SOA Suite for Oracle Middleware 7-82

83 Oracle Unified Business Process Management Suite Diagnostics Pack for Oracle Middleware Oracle Policy Automation Oracle WebLogic Portal COTS product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Congnos Business Intelligence Adobe LiveCycle Forms Control-M Batch Scheduler APSP for Eligibility with Public Assistance Accelerator Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle Database Enterprise Edition w/ options Oracle Database RAC option Oracle Database Audit Vault option Oracle Database Grid Control option Oracle Database Diagnostic Pack Database Change Management Pack Configuration Management Pack for Oracle database Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. 7-83

84 Oracle WebLogic Suite Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. The Cognos BI software will run on the Reporting Server identified above. The licensing information for Cognos is also listed above. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Oracle Access Manager employee users Oracle Access Manager non-employee users Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Several Oracle products listed above as components of the database will be utilized for monitoring and reporting on the application and infrastructure. Included in this list is Oracle Grid Control. A component of Oracle Enterprise Manager that allows monitoring of all Oracle software components in the infrastructure. DBA Services Depending on the skill level of personnel, the K-MED database architecture solution proposed by Accenture should be able to be managed by 1 FTE. In addition to the standard roles and responsibilities of a database administrator, the Accenture solution requires knowledge of the Oracle RAC technology. The production database will be set up on a two-node RAC. A separate database for reporting will be updated using Oracle s Active DataGuard technology. Backups should occur daily for incremental backups and weekly for full or snap-shot backups. Managed Backup Retention Schedule Changes in the Development environment are very dynamic and requires backup on a routine daily basis. Also because of the dynamic nature of the environments, retention of configurations and data is not necessary beyond a short period of time. Different environments will have different backup and retention schedules. These schedules will also change as the activity in an environment changes. Standard retention should be based at one month. The Reference environment will be very static and only monthly 7-84

85 backups of the configuration and data are necessary. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Oracle database tools included in the components above will be used to manage database backups. 7-85

86 Proposer Name Environment (Provide detail for each environment) Accenture Development _X Reference Integration Interface Testing Conversion Testing User Acceptance Testing System Testing Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed All Servers for the Reference Application Middleware Hardware/Software The Reference Application is hosted in Accenture s Delivery Center. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. COTS product 7-86

87 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and 7-87

88 Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. DBA Services Managed Backup Retention Schedule Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal 7-88

89 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration _X Interface Testing Conversion Testing User Acceptance Testing System Testing Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environment form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product 7-89

90 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Monitoring and Reports 7-90

91 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. 7-91

92 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing _X Conversion Testing User Acceptance Testing System Testing Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environment form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product 7-92

93 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical 7-93

94 assistance. Refer to the Integration environment form. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. 7-94

95 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing Conversion Testing X User Acceptance Testing System Testing Training Emergency Fix Production Other Middleware Hardware/Software Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing 7-95

96 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. 7-96

97 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing Conversion Testing User Acceptance Testing _X System Testing Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environment form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product 7-97

98 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and 7-98

99 Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. 7-99

100 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing Conversion Testing User Acceptance Testing System Testing _X Training Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environme nt form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product 7-100

101 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Monitoring and Reports 7-101

102 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form

103 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing Conversion Testing User Acceptance Testing System Testing Training _X Emergency Fix Production Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environment form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product 7-103

104 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance

105 Refer to the Integration environment form. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form

106 Proposer Name Environment (Provide detail for each environment) Accenture Development Reference Integration Interface Testing Conversion Testing User Acceptance Testing System Testing Training Emergency Fix Production _X Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer Inbound Transfer Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Server Server (Web Server/Database Server) Describe each server and their configuration needed Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environment form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. COTS product 7-106

107 Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Application Server Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. Security and PCI Services Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x

108 technical assistance. Refer to the Integration environment form. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. DBA Services Refer to the Integration environment form. Managed Backup Retention Schedule Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Refer to the Integration environment form. The Proposer shall use this form to provide the configuration information to KHPA as part of its proposal. A separate sheet is required for each environment as well as a total proposal summary sheet

109 Proposer Name Environment (Provide detail for each environment) Total Proposal Summary Sheet Accenture _X Development _X Reference _X Integration _X Interface Testing _X Conversion Testing _X User Acceptance Testing _X System Testing _X Training _X Emergency Fix _X Production _X Other Bandwidth Frequency Aggregate Bandwidth Data Transfer Outbound Transfer 9 24 hours Inbound Transfer hours Firewall (w/ VPN and DMZ options) Firewall VPN Load Balancer Production: Cisco 2 Integration: Cisco 2 Development: Cisco 1 Reference: Interface Testing: Conversion Testing: User Acceptance Testing: System Testing: Training: Emergency Fix: Other: Server Server (Web Server/Database Server) Describe each server and their configuration needed Production: Shared server for the OS Version / License Sun T core 1.65GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning

110 web tier and application tier Integration: Web Servers Development: Web Server and Application Servers Production: Audit Server, Management Server, Backup Server, Interface server Integration: Audit Server, Management Server, Backup Server, Interface server Production: Production Database Server Integration: Database Server 16 GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Monthly backup OS Version / License Sun T core 1.65GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16 GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Monthly backup The Reference Application is hosted in Accenture s Delivery Center. OS Version / License Sun x cpu Intel Xeon E core, 2.40GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16GB Memory External Storage Connection(s) Backup option and Frequency Monthly backup OS Version / License Sun x cpu Intel Xeon E core, 2.40GHz Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 16GB Memory External Storage Connection(s) Backup option and Frequency Monthly backup OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris

111 Development: Database Servers Production: Reporting Database Server Integration: Conversion Database Server Reference: All Servers for the Reference Application Interface Testing: Servers are shared using the same configuration as identified in the Integration environment. Conversion Testing: Servers are shared using the same configuration as identified in the Integration environment. User Acceptance Testing: Servers are shared using the same configuration as identified in the Integration environment. System Testing: Servers are shared using the same configuration as identified in the Integration environment. Training: Servers are shared using the same configuration as identified in the Integration environment. Emergency Fix: Servers are shared using the same configuration as identified in the Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup The Reference Application is hosted in Accenture s Delivery Center. OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup OS Version / License Sun M quad core Sparc VII(2.53GHz) Server Hardware and Minimum Configuration Solaris 10 Server Drive Partitioning 32GB Memory External Storage Connection(s) 2x300GB internal disk Backup option and Frequency Weekly backup The Reference Application is hosted in Accenture s Delivery Center. Refer to the Integration environment form. Refer to the Integration environment form. Refer to the Integration environment form. Refer to the Integration environment form. Refer to the Integration environment form. Refer to the Integration environment form

112 Integration environment. Other: Servers are shared using the same configuration as identified in the Integration environment. Middleware Hardware/Software Refer to the Integration environment form. Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. For All Environments NOTE: The following list of software components are shared across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Production: Oracle SOA Suite for Oracle Middleware Production: Oracle Business Process Management Suite Production: Diagnostics Pack for Oracle Middleware Production: Oracle Policy Automation Production: Oracle WebLogic Portal Integration: Oracle SOA Suite for Oracle Middleware Integration: Oracle Business Process Management Suite Integration: Diagnostics Pack for Oracle Middleware Integration: Oracle Policy Automation Development: Oracle SOA Suite for Oracle Middleware Development: Oracle Unified Business Process Management Suite Development: Diagnostics Pack for Oracle Middleware Development: Oracle Policy Automation Development: Oracle WebLogic Portal Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. 8 cores 8 cores 16 cores 8 cores 4 cores 8 cores 4 cores 8 cores 4 cores COTS product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Production: Cognos Business Intelligence Production: Adobe LiveCycle Forms 7-112

113 Production: Control-M Batch Scheduler Production: APSP for Eligibility with Public Assistance Accelerator 1 Integration: Cognos Business Intelligence Integration: Adobe LiveCycle Forms Integration: Control-M Batch Scheduler Integration: APSP for Eligibility with Public Assistance Accelerator 1 Development: Cognos Business Intelligence Development: Adobe LiveCycle Forms Development: Control-M Batch Scheduler Development: APSP for Eligibility with Public Assistance Accelerator Reference: APSP for Eligibility with Public Assistance Accelerator 1 Interface Testing: APSP for Eligibility with Public Assistance Accelerator 1 Conversion Testing: APSP for Eligibility with Public Assistance Accelerator 1 User Acceptance Testing: APSP for Eligibility with Public Assistance Accelerator 1 System Testing: APSP for Eligibility with Public Assistance Accelerator 1 Training: APSP for Eligibility with Public Assistance Accelerator 1 Emergency Fix: APSP for Eligibility with Public Assistance Accelerator 1 Other: APSP for Eligibility with Public Assistance Accelerator 1 Any other Third party product Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Production: Integration: Development: Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Database Licensing Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. For All Environments NOTE: The following list of software components are shared across the Database Server hardware. Oracle Premier Support provides 24x

114 technical assistance. Production: Oracle Database Enterprise Edition w/ options Production: Oracle Database RAC option Production: Oracle Database Audit Vault option Production: Oracle Database Grid Control option Production: Oracle Database Diagnostic Pack Production: Database Change Management Pack Production: Configuration Management Pack for Oracle database Integration: Oracle Database Enterprise Edition w/ options Integration: Oracle Database RAC option Integration: Oracle Database Audit Vault option Integration: Oracle Database Grid Control option Integration: Oracle Database Diagnostic Pack Integration: Database Change Management Pack Integration: Configuration Management Pack for Oracle database Integration: Oracle Data Integrator Development: Oracle Database Enterprise Edition w/ options Development: Oracle Database RAC option Development: Oracle Database Audit Vault option Development: Oracle Database Grid Control option Development: Oracle Database Diagnostic Pack Development: Database Change Management Pack Development: Configuration Management Pack for Oracle database Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Application Server Licensing 20 cores 16 cores 4 cores 4 cores 20 cores 20 cores 20 cores 36 cores 32 cores 4 cores 4 cores 36 cores 36 cores 36 cores 4 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. For All Environments NOTE: The following list of software components are shared 7-114

115 across the Application Server hardware. Oracle Premier Support provides 24x7 technical assistance. Production: Oracle WebLogic Suite Integration: Oracle WebLogic Suite Development: Oracle WebLogic Suite Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Reporting Software and Server detail Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. Production: The Cognos BI software will run on the Reporting Server identified above. The licensing information for Cognos is also listed above. Integration: The Cognos BI software will run on the Reporting Server identified above. The licensing information for Cognos is also listed above. Development: The Cognos BI software will run on the Reporting Server identified above. The licensing information for Cognos is also listed above. Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Security and PCI Services 16 cores 8 cores Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. For All Environments NOTE: The following list of software components are shared across the Identity and Access Management Server hardware. Oracle Premier Support provides 24x7 technical assistance. Production: Oracle Access Manager employee users Production: Oracle Access Manager non-employee users 1300 users users 7-115

116 Integration: Oracle Access Manager employee users Integration: Oracle Access Manager non-employee users Development: Oracle Access Manager employee users Development: Oracle Access Manager non-employee users Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Monitoring and Reports Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. For All Environments: Several Oracle products listed above as components of the database will be utilized for monitoring and reporting on the application and infrastructure. Included in this list is Oracle Grid Control. A component of Oracle Enterprise Manager that allows monitoring of all Oracle software components in the infrastructure. DBA Services 650 users 500 users Production: Depending on the skill level of personnel, the K-MED database architecture solution proposed by Accenture should be able to be managed by 2 FTEs. In addition to the standard roles and responsibilities of a database administrator, the Accenture solution requires knowledge of the Oracle RAC technology. The production database will be set up on a two-node RAC. A separate database for reporting will be updated using Oracle s Active DataGuard technology. Backups should occur daily for incremental backups and weekly for full or snap-shot backups. Integration: Depending on the skill level of personnel, the K-MED database architecture solution proposed by Accenture should be able to be managed by 2 FTEs. In addition to the standard roles and responsibilities of a database administrator, the Accenture solution requires knowledge of the Oracle RAC technology. The UAT database will be set up on a two-node RAC. Due to the virtualization of the servers, the databases will contain instances from multiple servers. Development: Depending on the skill level of personnel, the K-MED database architecture solution proposed by Accenture should be able to be managed by 1 FTE. In addition to the standard roles and responsibilities of a database administrator, the Accenture solution requires knowledge of the Oracle RAC technology. The production database will be set up on a two-node RAC. A separate database for reporting will be updated using Oracle s Active DataGuard technology. Backups should occur daily for incremental backups and weekly for full or snap-shot backups. Reference: 2 FTE 2 FTE 7-116

117 Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Managed Backup Retention Schedule Production: Most of the systems in the K-MED solution will be static in the configuration and data they contain. Therefore, other than the backup of database storage, the servers should only need backup on a monthly basis or as often as new releases or updates are applied to the systems. The retention schedule for the backups depends primarily on the tolerance that stakeholders will have for recovering missing or corrupt data. It is recommended that daily backups be secured for one month, weekly backups be secured for three months, and monthly backups be secured for one year. Integration: Changes in the non-production environments are very dynamic and requires backup on a routine daily basis. Also because of the dynamic nature of the environments, retention of configurations and data is not necessary beyond a short period of time. Different environments will have different backup and retention schedules. These schedules will also change as the activity in an environment changes. Standard retention should be based at one month. Development: Changes in the Development environment are very dynamic and requires backup on a routine daily basis. Also because of the dynamic nature of the environments, retention of configurations and data is not necessary beyond a short period of time. Different environments will have different backup and retention schedules. These schedules will also change as the activity in an environment changes. Standard retention should be based at one month. The Reference environment will be very static and only monthly backups of the configuration and data are necessary. Reference: Interface Testing: Refer to the Integration environment form. Conversion Testing: Refer to the Integration environment form. User Acceptance Testing: Refer to the Integration environment form. System Testing: Refer to the Integration environment form. Training: Refer to the Integration environment form. Emergency Fix: Refer to the Integration environment form. Other: Refer to the Integration environment form. Managed Backup Database Agents Specify licensing terms and options. NOTE: DO NOT include cost information here. Cost information must be provided only in the separate Cost Proposal. For All Environments: Oracle database tools included in the components above will be used to manage database backups

118 Technical Activities and Response Instructions The following technical activities are within the Contractor s scope for this project. The Proposer shall describe its approach to providing the services and activities associated with each of the following 1. Provide Technical Architecture and Infrastructure Design. Each Proposer must clearly explain the proposed technical architecture solution. This includes, but is not limited to, enterprise infrastructure services, Enterprise Service Bus / Enterprise Data Bus, Service manager, Service Registry, Business Process Management, etc. As a part of this discussion, incorporate, correlate, and tie in the items listed in RFP Section 2.9 Other Scope Considerations and discussed as a part of the Future Direction topic in Technical Proposal TAB 6 (please see RFP Section ). The proposal must also explain why the Proposer feels that this technical architecture and infrastructure design is the best solution. Accenture s proposed technical architecture is designed around the same ideals that the KHPA technical architecture embraces. The APSP architecture is relevant and flexible to KHPA goals. The reason for this is the concept KHPA identified as high cohesion and low coupling. The Service Oriented Architecture (SOA) is built on this concept. Accenture is a leader in implementing this technology. Our APSP enterprise framework uses the latest innovations from our technical labs, combined with lessons learned from the world s largest collection of SOA implementations. This platform gives KHPA a solution that is adaptable to your changing needs, while simultaneously helping to manage cost and risk. Because APSP uses proven technology and closely aligns with the requirements and goals you have set for this project you will get the benefits of modern SOA technology and a low risk implementation. APSP is flexible and extensible, enabling speedy integration of new systems in the future. This flexibility allows KHPA to leverage and extend it technology applications in a speedy, low-risk, cost-effective manner. Not only does the Accenture solution offer a rich set of services with APSP, but the services use an Enterprise Service Bus (ESB) to communicate. This improves both the internal flexibility of being able to replace components and only change the bus interface, and allows for external services to be connected to the architecture. This concept is powerful and is in line with the KHPA goal of interfacing the K-MED system with other vertical applications. This concept pulls together the integration of other systems such as Medicaid and HealthWave21. Using services across the ESB will allow K-MED to be the single eligibility system for many programs and services. A key component to the technical architecture is the data layer. The APSP solution offers a data model that has been proven to be flexible and robust. The data model that Accenture will base K-MED upon has been in use for six years. It provides sub-second response time with over 2TB of data. The model is built on many of the same concepts shared across eligibility applications. It is implemented with a relational database model, giving it the flexibility to separate entities into discrete functions and then combine them through the application pages or reports. Other components of the APSP architecture such as the business rules engine, the business process manager and the content management service are all components shared across the ESB. Accenture implements the business rules engine using Oracle s Policy Automation products. The business process manager is implemented using Oracle s Business Process Management Suite

119 Content management is supplied using the Perceptive ImageNow product, which is the same product used by Accenture on other eligibility system implementations. In line with the KHPA and Medicaid Information Technology Architecture (MITA) principles, Accenture has developed and tested the APSP architecture. The architecture goes beyond the K-MED system, though. With its ability to support a vertical application for eligibility and link together systems using a SOA and ESB, the KSB can expand to use and include additional programs as anticipated under the Affordable Care Act. 2. Evaluation of Existing Security Architecture. The Contractor shall provide an evaluation of how the proposed technical architecture design fits within KHPAs existing network security architecture, composed of unique logical areas separating development / test environments from production environments. Accenture is aware of the network security architecture of KHPA and have adhered to the principles that provide the strongest security; separation of environments with different security classifications. We will work with KHPA to place the proper network devices and logical separations between the environments that are internal and those that serve an external user base. The technical architecture proposed combines testing environments used by KHPA together on a set of servers that are distinct from the set of servers where the K-MED system resides. Access for internal users and those entering from outside of the trusted domain of KHPA users will be separated by firewalls. The final implementation of the environments will have the flexibility to reside in different locations deemed to be most secure and practical by Accenture and KHPA. 3. Technical Assistance. Technical assistance to KHPA and the hosting provider for the sizing, procurement, maintenance, and installation of essential hardware, systems software, maintenance, and installation services necessary to support the new technical architecture. Accenture has unequalled experience sizing technology solutions for our clients. We understand that over sizing wastes precious state resources and under sizing results in a poorly performing application. We right size our solutions by combining our experience with the knowledge of hardware providers to meet your technology needs efficiently. To size the KSB infrastructure, we would use transaction, user, and organizational size data you have supplied to work with your hosting provider and their hardware vendor. The hardware vendors analyze the input and develop recommendations using tools based on their customer experience and performance guidelines you provide. These tools allow for: Modeling and testing for different KSB-specific solutions before committing to purchases Evaluating and reviewing the proposed configuration and capacity changes using anticipated growth and their impact on systems Finally, we take the recommendations of the hardware vendors and compare the results against our successful client history. We do this because modeling is much more effective when compared to actual field experience. This review process accounts for any unique Kansas needs not accounted for in the modeling process. Figure 7-39 lists some of the clients for which we performed sizing. Client Applications Size Solution State of Connecticut HCM, FIN, EPM, PORTAL, 8.4 Tools 73,000 employees, $13B budget Unix Database server (IBM p690) running Oracle Windows Application and Web servers (Dell) 7-119

120 Client Applications Size Solution EMC Storage State of HCM, FIN, 65,000 Unix Database server (HP RP4720) running Ohio EPM, PORTAL, employees Oracle CRM, 8.4 Tools $57B Budget Windows Application and Web servers HP Storage City of New HCM, 8.4 Tools 350,000 Unix Database server (IBM p570) running York employees Oracle Unix Application and Web servers (IBM AIX) EMC Storage Figure We validate each new configuration against both vendor recommendations and our real life experiences to provide an appropriately sized solution During the Design Phase we would work with State personnel and the State s selected hosting vendor to refine hardware and software requirements for all State provided environments. As an initial step, we have provided configurations for all ten development, test and production environments in the preceding section ( ). We base these assessments on numbers provided by KHPA. 4. WAN Evaluation Assistance. Evaluation of the Kansas Wide-Area-Network capacity as it relates to the implementation of the proposed software, and specific recommendations concerning any needed WAN upgrades. The K-MED Solution Blueprint uses HTML and JavaScript and does not require Java plugins, proprietary components, or other heavy footprint client software. As a result, the application operates effectively over low bandwidth connection with minimal impact to the State s network. Because the network impact is minimal, the State s existing TCP/IP network infrastructure can be used to provide wide-scale worker and client access. Our APSP experience shows that 56kbps of bandwidth supports good performance for 10 average users. As with all browser-based applications, network latency is the single most important factor in system performance. In addition, Accenture uses a combination of pragmatic modeling and measurement to determine if network changes are required for our clients. We propose for the KSB the same steps we used successfully in Connecticut, Ohio and our recent Kansas ERP implementation: Identify all end users of the new application and consolidate by location. Measure current bandwidth usage by location to determine current constraints and bottlenecks If the data is available, remove the impact of the legacy applications that will be replaced Add K-MED applications to the model and analyze any network link that would exceed performance guidelines Upgrade any network links Conduct connectivity testing from user locations to confirm viability of design If more sophisticated network analysis and modeling tools are available (e.g. Application Expert, Fluke, OPNET, NetMRI), the technical team can use those results to assist in the analysis process. Figure 7-40 shows the process steps of WAN Analysis

121 1) Identify user types and number of users per location Agency LAN 2) Analyze current available bandwidth from user locations 3) Remove impact of existing KAECSES application (if possible) WAN 4) Add K-MED application to model to identify network bottlenecks Data Center Networking 5) Address potential bandwidth issues 6) Perform connectivity tests from user locations to confirm network response K-MED Figure Pragmatic network analysis provides appropriate data to plan network needs for K-MED 5. Initial Hardware and Systems Software. The Contractor will be required to provide and maintain the hardware and systems software necessary to support the design and development process and unit testing at its Topeka facility. The Proposer will describe the proposed Development environment hardware and systems software configuration, as well as its hardware and systems software change management methodology and tools. A similar response is required for the Reference environment. Accenture will leverage our San Antonio Delivery Center for the necessary hardware and software needed to support the design and development of modification to the APSP solution for K-MED. The environments will be accessed remotely from the Topeka facility where the design and development staff will be located. Leveraging this Delivery Center will provide KHPA with a fully functional environment on day one. It will also have the necessary skills and experience needed to operate the APSP solution. As code is developed or modified, it will follow Accenture s Change Management methodology. For a complete description of our Change Management methodology and tools, refer to section in this proposal response. 6. Proposed Environments: This is the structure and maintenance of planned database instances / environments named above in RFP Section The proposal must address additional environments needed as well as any differences in the vendor s approach. We agree with the required environments that Kansas has identified for K-MED. The Development environment will be used by the Accenture team to support the customization of components of the APSP solution. The Accenture solution will be primarily modified using the skills and experience from our San Antonio Delivery Center (SADC). Customizations specific to K-MED will be developed and integrated with the APSP solution using this development environment. The Development environment will consist of a small number of servers to support the K

122 MED specific modifications to the Accenture solution. One server will support a database with multiple instances of a small data set. This will be used by the developers to design and test their code. The other severs will support the tools necessary to modify the pages, rules, and configurations necessary for development. This environment will be hosted from the SADC. The Development environment will be supported by the Accenture team. Upgrades and patches will be applied by the Accenture team. Configuration changes will also be made by Accenture. The changes made to the environment will follow the Configuration Change process. The Reference environment is a copy of the C-IV system running on the APSP architecture as it was initially delivered to KHPA and will primarily be used during the design phase of the project as a reference to how features of the system work. Analysts will then be able to determine the necessary modifications to meet requirements and desired functionality. A small database will be set up with minimal data. None of the data will be taken from a production system. This is the unmodified APSP COTS application. The Reference environment will be housed in the Accenture SADC. Due to the web-based nature of the application, an internet connection and web browser are all that are needed to access the reference application from anywhere. Access to the environment will be coordinated with KHPA. The Reference environment will be supported by the Accenture team. Upgrades and patches will be applied by the Accenture team. Configuration changes will not be made. This will be a static environment with only hardware and system software changes being made as required remaining compliant with licensing and security measures. The Integration or Assembly Test environment provides a testing environment where integration between the eligibility support systems and other applications is tested. Initially this environment would be used to test integration with MMIS, HealthWave21 and the PSI Clearinghouse environments. It will be used by the Development Team to verify the interaction of separate program modules. A test database, configured for the next release of software, will be set up with a smaller set of masked production data. The Integration environment shares servers and software instances with other non-production environments. A database environment is set up specifically for integration testing. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Development Team is expected for work done on this environment. The Interface Testing environment will be used by the Test Team to validate the connection and transfer of information with interface partners. A test database, configured for the next release of software, will be set up with a smaller set of masked production data. Interface testing deals mostly with connection to other systems and exchange of data. Interface connections and file drops will be tested on a server shared with web services This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test Team is expected for work done on this environment. The Conversion Testing environment will be used by the Conversion Team to validate the extract, transformation and load of data from the different source systems into the K-MED 7-122

123 system. Multiple conversion databases, configured for the production release of software, will be set up with a set of masked production data. The Conversion environment is configured to operate mostly on a database server. The extract, transformation, and load of data will all be done on this database. It is expected that there will be several instances of the source and destination data as conversion routines are developed and tested. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Conversion Team is expected for work done on this environment. The User Acceptance Testing (UAT) environment will be used by the State to test major software updates before moving the updates to the System Testing Assurance environment. Prior to implementation, this environment will also be used by the State to test converted data. Other uses for this environment may be acceptable depending on the timing and coordination of testing activities. A production sized database will provide a masked copy of production data or actual production data depending on the scheduled use of the environment. The UAT environment is configured as a copy of the production environment. The web and application tier servers are the same as those in production. In this environment, however, the hardware and software have been allocated across smaller pieces of the servers. Due to the smaller number of users accessing this environment, the scale is very similar to that of the production environment. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test Team is expected for work done on this environment. The System Test environment will be used by the Test Team. It will have a production size database with production data masked for testing. The System Test environment is configured as a duplicate of the Production environment. The databases use clustering technology and each of the web and application tier components are redundant across multiple servers. The hardware components are the same as in Production. This environment makes efficient use of the servers by only utilizing the processing necessary for the number of users expected in the System Test environment. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test Team is expected for work done on this environment. The Training environment will be used by the Training Team for training of State staff during initial, ongoing, new staff, and any other State required training. It will also be used by the Training Team for the development of training material. The training environment will use a pre-determined release of the K-MED code base along with the appropriately configured database. The data will be a masked production data configured for the various training scenarios. The Training environment is configured much the same as other non-production environments. There is a separate security server for training. This is due to the number of 7-123

124 training users as well as the difference in Training environment users from user of other non- Production environments. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Training Team is expected for work done on this environment. The Emergency Fix environment will contain a copy of the code and database in production or staged to be put into production. This environment may be used to apply emergency fixes for the K-MED system that can be tested without affecting the other environments as other development, testing or training may be occurring. The environment may also be used by developers and/or KHPA analysts to verify specific, data related issues with the production system. Access to this environment will be tightly controlled. It will contain a set of production data. The Emergency Fix environment shares servers and software instances with other non- Production environments. A database environment is set up specifically for testing in this environment. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with the Test and Release Teams are expected for work done on this environment. The Production environment is set up with redundancy for each hardware and software component in order to increase system availability. The servers are set up to operate multiple applications without affecting one another. For example, the Web Service application, the Access Management Service application and the Directory Service application are all on the same physical hardware but segregated using Solaris zoning features. The Production database is clustered across two server nodes using Oracle s Real Application Clustering technology. This will improve the availability of the database and reduce the load on each of the servers during normal operations. A third database is available for reporting. This database will be kept up to date with production data using Oracle s DataGuard feature. This environment should be supported by the hosting provider. Implementation of upgrades and patches to the hardware and software are expected to be completed by the hosting provider. The Configuration Control process should be followed to schedule upgrades and patches. Coordination with all teams is expected for work done on this environment. All environments must be controlled by the Contractor s proposed configuration management methodology. As indicated above in each specific environment description, the environments will be controlled using the Accenture Team Configuration Control process. Figure 7-41 displays the different KSB instances and the paths along which items would progress. Our approach provides procedures to manage the following items: KSB Program data records, pages, images, workflow, and other data structures that are changed via patching or modification 7-124

125 System Reference Patches & Fixes Development Modifications Integration Modifications Modifications Testing System Testing (QA) Production Interface Testing Data Conversion (Temporary) Performance and Volume Testing Fiscal Year End Testing (Temporary) Program Objects Data Training Development Data and Programs Training Execution Figure Multiple environments support the Big Bang go-live strategy and the unique requirements of the Kansas FMS timeline Configuration Objects configuration changes affect how FMS processes data. Administrators make configuration changes in a non-production environment and promote them through different phases of testing. Security Administrators would make user-level security changes directly in production; however, developers should test security setup changes to roles and permission lists in nonproduction environments. Test Data Precise management of test data make test cases easier to execute and reduce the effort required for regression testing. 7. K-MED Software Migration. The Proposer will describe how the K-MED software will be ported to another hosting environment after the development process is completed. K-MED Migration of K-MED software will be accomplished through the use of the Rational Suite versioning software (ClearCase). Environments needing to port the KSB application following completion of the development process will access the ClearCase server and upload the.ear file associated with the latest software release. The.ear file is then deployed on the destination server to load the KSB application. 8. Specify Desktop Requirements. Provide desktop requirements and specifications necessary to support the new K-MED System software. The State will perform all preparations for its desktop computers to be ready for the new system implementation. As a web-based application, the K-MED Solution Blueprint is useable from most desktop configurations. State of Kansas workstations using contemporary operating systems that can render a browser such as Internet Explorer, and have proper security controls in effect should be able to access the K-MED Solution Blueprint. 9. Business Continuity. Proposer shall describe a standard methodology for developing a business continuity plan, continuity capabilities, and high-availability infrastructure, as well as 7-125

126 a detailed explanation of the related approach, activities, procedures, tools, and templates and how the Proposer manages these activities and leverages the tools and templates. We understand that continuity of operations is an essential ingredient for the successful operation of K-MED. The impact and resolution of business disruption varies depending on the nature of the disrupting event. A one-size-fits-all disaster recovery approach is unlikely to provide the most beneficial or cost effective method of providing business continuity. Application level contingency planning addresses infrastructure components not shared with other applications. Enterprise level contingency planning addresses business continuity risks including, but not limited to, shared-application component interruption. The Accenture team s approach calls for planned, tested, and documented procedures and processes to restore mission-critical business functions and avert unacceptable business interruptions in the event of an unplanned outage. Our strategy places emphasis on the business functions that are critically impacted, focusing on the exposure or potential loss areas in the event of a disaster, the timing and responsibility for immediate action, the key contacts for notification, the specific recover procedures that must be used for continuous operations, and the testing necessary for continuous readiness. Identification of business continuity requirements early in the project provide the opportunity to develop options that minimize cost and increase flexibility by leveraging existing State capabilities. Our ADM methods include a robust methodology for business continuity. Figure 7-42 shows this methodology structure. We are not however proposing that the State of Kansas undertake a full Business Continuity and Disaster Recovery (BC/DR) effort for KSB. Many customers attempt to fit the scope of their application solution into a broader BC/DR initiative. Our ADM for APSP includes activities that would facilitate fitting KSB into existing BC/DR initiatives. The steps of our BC/DR methodology include: Project vision and startup Determine how the State s future strategic plans may influence the performance of the project Identify operational activities and vision which may impact the performance of the project Identify and implement appropriate documentation tools Assign and indoctrinate Kansas team members Conduct project introduction meeting Risk assessment Business Continuity Methodology Project Vision and Startup Risk Assessment Business Impact Analysis Recovery Strategy Development Recovery Plan Development Maintenance Procedures Development Recovery Plan Training Recovery Plan Testing Rollout Continuing Support Activities K-MED Figure Business Continuance Methodology covers activities required for Kansas to prepare for, respond to and recover from a Disaster 7-126

127 Document resource inventories by applicable business function Review policies, statements, and controls related to emergency procedures Identify potential interruptions Identify risk avoidance measures Business impact analysis Gain an understanding of the general business environment and process Quantify the impact of a catastrophe by timeline Determine minimum required service levels Recovery strategy development Identify outage scenarios to be addressed by recovery plan Develop preliminary recovery strategies across time Develop declaration decision table Quantify critical resources by function and develop recovery timeline Quantify and qualify recovery options Present findings to stakeholders Recovery plan development Identify and select an alternate recovery site vendor, if required Develop and document an untested recovery plan Develop and document appropriate recovery team procedures Maintenance procedures development Identify and document organization triggers which could alter the recovery plan s appropriateness Develop and document recovery plan update procedures and responsibilities Develop testing strategies Integrate recovery planning into existing change management procedures Recovery plan training Develop recovery plan training materials and scenarios Train organizational members in the implementation of the recovery plan Recovery plan testing Develop recovery plan testing scenario Conduct and evaluate the test Identify and implement changes to the recovery plan as a result of the test Present findings and recommendations to stakeholders Recovery plan rollout Roll out recovery plan Continuing support activities Provide continuing support on a scheduled basis Render emergency service as required 10. Disaster Recovery Process. Proposer shall describe architecting, implementing, and testing a disaster recovery process for the new K-MED System. Accenture recommends several leading practices as a part of our solution to simplify recovery options: Implement operating system imaging, and virtualization when possible to reduce the dependency on specific hardware in a recovery setting

128 Use commodity hardware where possible to lower the costs of external DR solution providers. Use a warm site to vault critical information at the data tier. Recovery from tapes and logs is error prone and subject to long recovery times. This approach can include either SANbased or database-delivered (DataGuard) replication. Establish a domain name for the application and have it registered with external DNS providers. In the event of a disaster, only the DNS entry need be changed for user to access the restored application. Enable collaboration and terminal services to allow for remote recovery and DR testing. This lowers overall costs. Include the discussion of business continuity during conference room pilot and business process workshops. This allows the business architects to collect the BC options while they are considering the entirety of the business process. Implement a robust high-availability solution. Many organizations can avoid declaring a disaster by having robust backups of all critical components. Figure 7-43 describes the key differences and relationships among business continuity, disaster recovery and high availability. 11. Performance Tuning. The Contractor will be expected to assist the hosting provider with performance tuning activities as necessary. The Proposer shall describe its performance tuning methodologies and techniques for databases, application servers, web servers, and other software and devices deployed as part of the proposed solution. This includes batch and online software tuning, as well as data conversion software tuning. Early detection is the key to efficient performance tuning. While end-users will report performance issues, if they are the first line of defense, it is likely that larger problems exist within the application. The ADM for APSP builds performance tuning into the development process, catching any issues early in the process, when they are easier to complete. Critical elements of our performance tuning approach include: Identify performance targets during the Analyze Phase. It is during this phase that business analysts are documenting key transaction volumes. Include a technical review for all reports, interfaces, configuration items, application Business Continuity (BC) The process which uses prevention and crisis management as well as alternate resources and procedures to sustain minimum required business functionality during a crisis. In many cases, prior to IT recovery. Disaster Recovery (DR) Provides the technical ability to maintain critical services in the event of any unplanned incident that threatens these services or the technical infrastructure required to maintain them. High Availability (HA) Ability to automatically switch to alternate resources when a portion of the system is not or cannot remain functional. BC DR HA K-MED Figure Minimizing Business Continuity risks requires thorough planning, using a Business Requirement-driven approach and a proven Business Continuity Planning methodology 7-128

129 enhancements and workflow designs. This review looks for inefficiencies in design, large transaction volumes, and opportunities to use technology more efficiently. Monitor individual transactions during development for poorly performing candidates. Early identification of performance issues can improve the efficiency of testing. Monitor batch, conversion, interface and online programs for deviation from baseline during all phases of testing including mock conversions. This includes ETL programs for the data warehouse. Plan and execute a specific performance test to stress the infrastructure for both batch and online transactions. Report performance issues and resolutions back to Oracle for inclusion in the next possible patch / release level. Our solution includes a robust set of tools and approaches for identifying and correcting performance inefficiencies. We recommend the use of the Oracle Enterprise Manager 11g for efficient performance tuning. The project DBAs would use these tools during both development and ongoing production to optimize K-MED. Using Oracle Enterprise Manager, a Web browser-based graphical HTML console, systems administrators manage performance, plan for future capacity, and easily troubleshoot daily issues within the system. This tool combines Oracle performance statistics data and can be used to easily spot trend anomalies. It is also used to identify high wait-time events, which may indicate forms of contention within the database or underlying storage structures. Use of Performance Monitoring tools, such as Oracle Enterprise Manager and the Diagnostic Pack for Oracle Middleware, helps system administrators manage the performance of web servers, application servers, databases and batch processes. It can be used to manage historical trends and user activity levels within the application. 12. Software Upgrades and Updates. The Proposer shall describe its software upgrades and the update methodology, as well as a detailed explanation of the related approach, activities, procedures, tools, templates, and how the Proposer manages these activities and leverages the tools and templates. Upgrade Methodology We accomplish Configuration Management (CM) using our Accenture Delivery Tools (ADT) suite. For CM, we rely on the following products: Rational RequisitePro Requirements tracking and traceability management ClearCase Change control and code/document version repository ClearQuest End-to-end management of configuration from requirement definition to code item definition to defect management to traceability verification All of the Rational tools in the ADT have been pre-configured with templates, processes, and documentation from the Accenture Development Methodology. These enhancements promote adherence to the methodologies and faster uptake for Accenture teams. This benefits KHPA by providing the K-MED solution by lowering risk and increasing quality through the K-MED implementation lifecycle. We store code and deliverable documentation in ClearCase. Once it is completed, we indicate completion in ClearQuest. We lock down ClearQuest when we begin the test phase so that only code associated with a defect can be changed or fixed. We build test scripts to test the 7-129

130 satisfaction of the requirements. As testing continues we use the Rational Test Suite to indicate the completeness of test scripts, and, therefore, the overall completeness of the fulfillment of the requirements. Because our requirements traceability chain is intact, we know that the K-MED solution is ready for User Acceptance or Pilot when the test scripts are 100% complete. Upgrade Activities APSP Platform upgrades consist of swapping out existing architecture code with the new code. This typically requires some customized build scripts, which Accenture provides, to be run to deploy the new version. The APSP Public Assistance and APSP Public Portal applications also require custom build scripts and usually database scripts to deploy the new version of the code. Accenture will perform all K-MED upgrades in our labs before shipping the code on-site to a K-MED staging environment. We will assist KHPA at every step when fixing, patching, and upgrading. Oracle provides a full suite of upgrade tools, including analysis tools, fix and patch automated implementation tools. Oracle Enterprise Manager provides a single tool that can monitor and manage every Oracle software element in the K-MED solution. Configuration Management Pack and Provisioning and Patching Pack can be added to the Oracle Enterprise Manager to help automate and manage upgrades. Upgrade Tools and Templates Our project methodology for development of the system is based on our Accenture Delivery Methods (ADM), which we describe in the System Development Methodology section of this proposal. Our team members are well trained and experienced in this proven methodology. It not only includes procedures, processes and techniques; it also includes an integrated toolset based on the industry-leading IBM Rational Lifecycle. It includes the suite of Rational tools, including RequisitePro, ClearCase, ClearQuest, and an Integration Development Environment (IDE). It is geared specifically for Java development with our Accenture Public Service Platform (APSP) software product. In managing the many requirements, business processes, and potential changes, the RequisitePro tool helps manage the thousands of requirements and tracing them to designs. The Rational toolset helps document the changes in standard document templates and diagrams, using standards like the Unified Modeling Language (UML). Because the requirements, designs, and proposed changes are in the integrated Rational toolset (with RequisitePro, ClearQuest, and ClearCase), a comprehensive impact analysis can be performed to help locate the right place in the project schedule to implement the approved changes. Accenture will work with KHPA to determine the necessary upgrades from APSP and the schedule for their implementation. We will also collaborate on the implementation of K-MED specific modifications. For a complete description of our Change Management methodology and tools, refer to section in this proposal response Requirements Validation, Analysis, Business Process Design, and Software Configuration Requirements Validation, Analysis, Business Process Design, and Software Configuration. The Proposer shall describe its approach to analyzing the State s system requirements and demonstrating the proposed software s ability to satisfactorily meet those 7-130

131 requirements. This approach may include a Conference Room Pilot or a pilot prototype system integrated with the business process analysis and software configuration process. The State desires to receive a formal fit/gap analysis documenting the disposition of each functional requirement and the resolution of identified gaps (e.g., customization, workaround, eliminate requirement). The Contractor will assist KHPA in identifying appropriate business process improvement opportunities, documenting the recommended changes, and planning and implementing the KHPA approved business process changes. When documenting the business process design, the State encourages the use of Business Process Modeling Notation (BPMN). Our approach to demonstrating that the system meets the requirements is based on collaboration. We believe in an integrated, highly-collaborative team. Our project team works together with KHPA project personnel throughout the project development lifecycle. From the onset of the project, our team shares the pre-project analysis appearing in this proposal with the KHPA project team. Throughout business project design, configuration of the software and validating the requirements, our team members work with KHPA staff as a single, integrated team working toward the common goal of meeting or exceeding the requirements. Our project methodology for development of the system is based on our Accenture Delivery Methods (ADM), which we describe in the System Development Methodology section of this proposal. Our team members are well trained and experienced in this proven methodology. It not only includes procedures, processes and techniques; it also includes an integrated toolset based on the industry-leading IBM Rational Lifecycle. It includes the suite of Rational tools, including RequisitePro, ClearCase, ClearQuest, and an Integration Development Environment (IDE). It is geared specifically for Java development with our Accenture Public Service Platform (APSP) software product. More information on our proposed toolset is in Tab 6 of this proposal. Analyzing Requirements and Collaborative Joint Sessions We work with you in analyzing the K-MED requirements, and exercising the business processes through Joint Design Sessions. During these sessions, KHPA business analysts, APSP process skilled advisors, and technical team members work together. We demonstrate a working, live reference version of our Accenture Public Service Platform (APSP) product. We collaborate with KHPA staff to be involved for feedback and approval of deliverables. KHPA staff are involved in the entry and exit criteria of each major task or phase. We develop and confirm our work products and identify potential errors early in the process when they are easier to correct. To further maintain this collaborative environment and process, we also make a strong commitment to seek to maintain constant communication whether it is a regularly scheduled status meeting or announcements posted to the project web site. The result for KHPA is no surprises and ongoing updates with clear messages. The result is a natural transparency to project status and issues. Requirements Traceability Our team uses the industry standard requirements management tool Rational RequisitePro for managing requirements. We track, trace, and link requirements to design documents and test scripts throughout the system development lifecycle. This tool is well integrated with our ADM methodology, and our people are already well trained in this tool

132 We use this tool because it is robust and successfully demonstrated. It also saves time. Changes to requirements are tracked through a history log. Visual tools show a dynamic linkage between requirements. Traceability features in ReqPro enable the creation of links between each requirement and other related requirements and documentation. ReqPro is also useful for determining the impact of changing a requirement, design document, or other linked documentation. As requirements evolve, and become more detailed, they can be captured, tracked and documented in ReqPro. Automated capability built into the tool can notify KHPA management of changes automatically, for hands-off and simple communication of requirements status. Fit-gap Analysis As part of this proposal response, our team has performed an initial fit-gap analysis between the business components of the APSP and the requirements for K-MED. The analysis appears in the Requirements Responses (Appendix 1) section of the proposal. Our proposed APSP product contains business rules, components, architecture and automation that meet a majority of the K- MED requirements. The gaps of the remaining requirements can be met with configuration changes in the form of business rules, workflow, codes tables, and related configuration items. APSP is a significant head-start in the configuration and development of K-MED. It will help KHPA realize the benefits of the system sooner than comparable solutions. Figure 7-44 shows the reuse from our APSP product throughout the development activities of the solution. The live running APSP product is available throughout the lifecycle of the project. It enables the project team to rapidly prototype and configure APSP to the unique specifications and processes required for K-MED. The availability of the live APSP product reduces the demand on KHPA staff time and lower cost of development. Collaborating to Improve Business Processes One challenge is identifying appropriate business process improvement opportunities for K- MED. This is where the collaboration we talked about earlier in this section is important. Delivering a strong result is accomplished through our experienced APSP process staff working hand-in-hand KHPA project staff. Using the APSP reference application, our joint team works together to identify the process improvement, and document the change in the business process. Using the live running APSP Requirements Analysis General Design Detail Design Development Testing Implementation Fit Gap Analysis of requirements to APSP Traceability matrix listing candidate reusable design, build, and test artifacts Use Cases, Data Model and Pages from APSP JAD setup/training Guides, Standards, and Templates Known capability and technical parameters for APSP Training designs from APSP Templates Live running APSP UML designs Workflows Cookbooks Test Scripts Java Docs Test scenarios Sample Code Base Stereotypes Reusable components Execution architecture Training curriculum Reuse of APSP Data Model K-MED Figure Our software development approach reuses requirements, design, components, and test artifacts from our Accenture Public Service Platform (APSP) to lower risk and expedite development 7-132

133 helps identify the changes in an easy to understand manner early in the design process. Team leads work with the business analysts to plan the implementation of the process changes at the appropriate time, so as to minimize negative impact. In managing the many requirements, business processes, and potential changes, the RequisitePro tool helps manage the thousands of requirements and tracing them to designs. The Rational toolset helps document the changes in standard document templates and diagrams, using standards like the Unified Modeling Language (UML). Because the requirements, designs, and proposed changes are in the integrated Rational toolset (with RequisitePro, ClearQuest, and ClearCase), a comprehensive impact analysis can be performed to help locate the right place in the project schedule to implement the approved changes. The K-MED project teams take a similar approach with developing business rules and workflow for service-oriented processes. Oracle Workshop development tool, with its Policy Automation toolset and its BPMN-compliant Process Modeler, enable analysts to implement rules and business processes (workflow). The tools can also turn rule-sets and workflow designs into initial code that the developer can integrate into the K-MED solution. For example, Figure 7-45 shows a portion of just one of the hundreds of Use Case models Illustrative Use Case Diagram Determine Residence Eligibility Configure Case Determine Household Status Eligibility Determine Living Arrangement Eligibility Close Program Case Person Determine Eligibility and Benefit Determine Minor Parent Budget Configuration Determine Deprivation Verify Program Case Minimum Requirements Identify Initial Program Person Identify Mandatory Persons Set Applicant Roles Identify Optional Persons Determine Financial Responsibility Set Family Map Only Role Set Person s Role Set Person s Role Close Program Case Determine Person Noncompliance Determine Citizenship Eligibility Determine School Attendance Eligibility Determine Residence Eligibility Determine Household Status Eligibility Determine Living Arrangement K-MED Figure The hundreds of Use Case diagrams available with APSP provide an appropriate starting point for design, reducing cost, and increasing reliability 7-133

134 available in APSP with related code and components. We integrate them into the overall K-MED design model along with new components using the project's document standards. The reuse of designs, workflows, and rules from our SOA-based APSP help reduce cost and lower risk of the design effort Software Configuration Tools, Documentation, and Validation The Proposer shall then describe its approach and methodology to be used to configure the new K-MED software in accordance with the approved business process design. This section shall also describe: 1. The tools and procedures available to aid in the software configuration process; 2. The documentation provided to support the software configuration; and, 3. The process for validating the configuration against the State s documented requirements. APSP represents 25 years of work within our human service practice and is composed of business services, portlets, and a technical platform for implementation in KHPA's environment. APSP is easy to configure because it is modular and SOA-based. It is composed of true business services. The business services are reusable business objects and business rules designed to be readily configurable to implement in multiple jurisdictions, different programs, policies, procedures and business needs. We designed these components for reuse from their inception. No re-platforming is required to meet the architectural standards of K-MED. Business analysts and developers to work together in joint teams of KHPA staff and our experienced APSP staff. Working together, they configure business rules and workflows specific to KHPA s policies, practices and operations. Configure APSP with Open, Integrated Tools Using open, standards-based, and industry-leading tools, the K-MED project teams edit, compile, tune, integrate, and test. Staff developers and configurers use industry leading development tools, methodology, standards, automated procedures, and quality tools. Figure 7-46 shows an illustrative view of our open workbench for SOA-development, based on Eclipse. Integrated design and configuration tools for traceability Built in help to explain processes such as Peer Reviews Links to methodology to enhance process standards Links to architecture reference models and other key information Automated procedures to increase productivity Debugging and Junit plugins help verify code quality K-MED Figure Our developers use the integrated development environment, Eclipse workbench, for our APSP configurations. It is open, standards-based, has integrated plug-ins for portal, rules, configuration management, debugging, and testing to increase quality, reduce cost, and enhance productivity 7-134

135 Project Staff Eligibility Workers Admins Supervisors Other Departments Help Desk Staff Clerks Office Managers Other Staff Online Offline Job Aids Manuals Documentation Examples/Details Method of Delivery Commercial product manuals Oracle Weblogic Portal, OPA, Service Bus Online Application software manuals, Data administration manuals System-wide instructions on system navigation, inquires available, reporting mechanisms, security procedures, etc. Online Orientation manuals Several hours of segments introducing navigation, technology, and background of the Online project User manuals/training Materials Training manuals Desk aids, Online Learning aids Formal Training and also during Targeted Topic Training during the first month after One-pagers used as desk aids implementation, assists users at time of need Tutorials Available anytime on demand for Staff Online Technical infrastructure system Information on configuration and support of development, execution and operations Online administration manuals environments Practices and procedures Sort by topic key words Online Online help Embedded in the system available at point of need, follows each page Online Code, Baseline application documentation Baseline application software source code, Object code, Rules documentation Electronic format, read-only medium Use cases Tailored to the application requirements Electronic format K-MED Figure Access to documentation helps staff find answers quickly whether functional, technical or policy related Built on the Eclipse Web Tools platform, the Oracle Workshop and the IBM Rational suite provides an integrated development environment. Combined with ClearCase and ClearQuest from the Rational suite, it provides a fully integrated configuration management environment as well. For portal and services development, Oracle Workshop provides configuration of SOA deployment objects on the Oracle Weblogic Portal and Service Bus products. The JUnit plug-in provides reliable, automated unit testing for the development of K-MED. The configuration "code" of our SOA-based APSP product is based on open industry standards. A few of these standards include Business Process Modeling Notation (BPMN), Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), Structured Query Language (SQL), Extensible Markup Language (XML), Document Type Definition (DTD), XML Schema Division (XSD), and Web Services Language (WSDL). APSP Includes Standards-based Documentation The document repository of K-MED configuration includes the source code, object code, JavaDocs and other associated documentation, unit test scripts and results, JUnit scripts, code review checklists and peer reviews for the application software components. Figure 7-47 shows an illustrative documentation set that provides access to the right information at the right time. Our project teams employ a user-centric approach to documentation. It is based on hundreds of project implementations with human services business analysts and administration staff. Project procedures enable KHPA representatives to add approved documentation to the K-MED processing environments, as required. Our documentation tracking processes will support staff by providing access to the latest and greatest documentation

136 Plan Analyze Design Build Test Deploy Service Introduction Implementation Goals and Expectations Pilot/Emergency Fix Requirements Traceability Matrix Functional Technical Training User Acceptance Test (UAT) Test Planning Design Configuration Software System and Integration Test Usability Test Unit Test Security Test Performance Test Test Execution Verify Validate Test K-MED Figure Our V-Model testing approach confirms implementation across test phases to validate the software meets the requirements and functions correctly APSP is Validated by our Proven V-Model Testing Methods We validate that the configurations to APSP meet the requirements through our successfully demonstrated testing methodology, the ADM V-Model. Figure 7-48 shows how we apply our Accenture Delivery Methods (ADM) to tailor our processes for a collaborative approach to testing. The V-Model provides the methods to test the K-MED application, verify its operation, and validate that the configurations of APSP meet the requirements. Other areas included in the testing are security, technical architecture, and system performance. The Top Down (left) side of the V-Model shows requirements and test plans. The highestlevel requirements are drilled down to specific code requirements and test conditions. The Bottom Up (right) side of the V-Model shows the execution of individual test plans beginning with the lowest level of detail. Unit Test begins to validate that we fulfill individual requirements. As the test planning steps on the left side of the V-Model complete, the paralleled activities on the right side follow along. Consider the following example to understand how the V-Model works for a specific K- MED requirement. A general expectation (left side) is that the K-MED provide search capabilities for persons We include Pilot testing (right side) as part of the preparation for KHPA Implementation. The user would execute a simple search to determine that he or she can find an individual using the search function. We review feedback from the users to determine if they are satisfied with the K-MED s search capabilities. One or more of the specific requirements (left side) defined for this expectation might be allow search individuals by name. During User Acceptance Test (right side), the UAT testers would search with a name that 7-136

137 exists and then search with a name that does not exist. When we design the search-by-name requirement in detail, the Design (left side) may specify that the program needs to search both the Client table and the Contact table During System Test and Integration Test (right side), we test with a name that exists only on the Client table. We then test with a name that exists only on the Contact table. Finally, we test with a name on both tables. We would also test a name that is not on either table. During software configuration (left side), we build the code to handle areas such as errors in accessing the tables and multiple matches on both tables. We conduct Unit Test (right side) for that section of code and for items such as abnormal error handling, multiple logic, and display issues when there are more matches than the system can display on one screen As this example illustrates, our methodology provides a consistent, comprehensive approach to defining and implementing the necessary tests throughout the entire V-Model testing process. We perform our tests in alignment with CMMI Level 4 processes and preferred practices. On a monthly basis, we report key quality statistics such as defect reopen rate to our North America quality team Customizations KHPA anticipates that certain development items will be necessary to meet the requirements referenced in RFP Appendix 1. In the following sub-sections, the Proposer will describe its approach for addressing the various types of customizations as follows: 1. Reports Analysis and Development 2. Enhancements and Modifications 3. Interface Development 4. Data Conversion 5. Workflow Configuration 6. Automated Forms Configuration. Customization represents the fine tuning of what is already a powerful engine for eligibility determination APSP. When implemented in the form of the K-MED Solution Blueprint, these adjustments to KSB key platforms and integrated systems provide KHPA with the ability to resolve key challenges inherent in the current system and meet the business goals you have set for yourselves. Reporting Analysis and Development will be key to the future direction of KSB. Lack of insight into systems and processes inhibits the ability to determine their effectiveness. As a remedy to the limitations of the reporting currently available, the K-MED Solution Blueprint offers a robust set of standard reports that can be either scheduled or run on demand. Easily derived Ad Hoc reports will allow K-MED staff to extract information relevant to evaluation and decision-making that may not be contained in standard report formats. KSB further provides web-based content from a variety of sources that can replace the use of traditional reports. The reporting structures in KSB also accommodate the future development of a broader range of reports allowing KHPA to keep pace with the impacts and requirements of legislative policy changes such as the Affordable Care Act. Enhancements and Modifications to the KSB platforms and applications will be required to stay current with technology, implement new programs or improve existing ones. Changes to the 7-137

138 APSP platform or the APSP Public Assistance Portal may reflect innovation from the K-MED team, response to legislative mandate or the need to apply upgrades and patches to KSB components. Our methodologies reduce the risks associated with these types of change, allowing KHPA to implement new initiatives while keeping the KSB technically viable. Interface Development is essential to the K-MED Solution Blueprint. The focus of the KSB Enterprise Service Bus is to connect a variety of disparate systems for the purpose of secure data exchange. While KSB uses a centralized database, integration with MMIS, PSI Clearinghouse and other systems is necessary to provide needed functionality and reduce or eliminate the collection of redundant data. At the core of the solution, APSP provides a variety of application interfaces that can be used to jump-start the development of interfaces needed for KSB. Our Data Conversion methodology defines the strategy and approach we will employ for safely and accurately moving client records into the KSB database. We will work with KHPA to determine the correct access approach to legacy data systems, assess data quality prior to conversion, generate test methods to validate data conversion and set timelines for data conversion. A key element to the KSB data conversion plan is risk mitigation. Through our collaboration with KHPA, we will identify areas of potential risk and adjust the conversion plan accordingly. KSB provides a Workflow Configuration that is flexible and easy to use. It is programmable without the use of IT resources, allowing business analysts to make workflow changes themselves. Templates developed in APSP using Oracle s Business Process Management tool enable users to build customized workflows on a foundation of common business processes. Simulation tools allow testing of workflow designs prior to introduction into the KSB production environment. This is particularly important for KHPA, given the diversity of your service delivery model. The Client Correspondence module of the K-MED Solution Blueprint will be used for Automated Forms Generation. Triggers set in KSB workflows will create requests for forms specific to need. KSB users may also generate forms on demand, using templates from the KSB document library. We will work with KHPA to create templates that address future communications requirements

139 Reporting and Business Intelligence The K-MED reporting solution will provide reports to support system functions allowing users the ability to access information, providing required standard reports, data for trending and monitoring of operational performance, as well as ad hoc reporting capabilities for day to day operations Reporting and Business Intelligence In this section of the proposal, the Proposer shall describe its approach and methodology for providing reports analysis and development. Detailed reports requirements and response instructions are located in RFP Appendix 3 Reporting and Business Intelligence. A3.1 REPORTING The reporting function will provide data support for a wide range of uses from executive decision makers to power users responsible for in-depth research, staff managing a caseload, as well as managers managing day to day work load and program performance. Our reports approach provides a real-time view of performance across KHPA programs, providing key information to assist in management level decisions and streamline day to day business operations Over 25 years experience in eligibility systems with staff that are knowledgeable in modernized Medicaid reporting structures and current industry trends The Accenture team has experience developing RDBMS reporting through popular off-the-shelf query products which are flexible and easy-to-use for end users Accenture s teammate PSI has in-depth knowledge of existing KHPA business processes and Clearinghouse performance metrics reducing risk in K-MED Reports design Web-based analytical processing capabilities that allow for quick analysis of complex data Drill down capabilities for summary reports allowing users to view and analyze detailed information Reports can be produced in common formats (PDF, Excel) so they can be saved to the desktop, printed, or ed Management of complex health and human services programs requires real-time access to information and a reporting platform that put tools into the end users and management staff s hands. Evolving program changes, new populations and complex business rules make immediate access to information critical for program administration. As is typical in most legacy systems adequate reports are not available from the current KAECSES-AE system. The creation of reports requires technical intervention by programmers that understand the current system. As a result, KHPA management and staff are limited in their ability to access program performance information needed for decision making and program oversight. Accenture s Reporting and Business Intelligence solution puts comprehensive tools into the user s hands to analyze program information, and facilitate program management decisions. To address these problems, Accenture brings a unique blend of people, process, and technology to the K-MED project that will provide KHPA with the business intelligence and reporting capabilities necessary to efficiently manage and act upon data within the state s Medicaid Program. The Accenture team brings over 25 years of experience in the design, development, and implementation of human service eligibility systems. The collective Medicaid, CHIP, Reporting and Business Intelligence, and Eligibility Determination systems experience between Accenture and PSI allow us to collaborate with KHPA to design a reporting solution that is sensitive to the unique current and future needs of KHPA

140 The goal of the Reporting and Business Intelligence component of K-MED is to provide a straight-forward method for allowing users to develop and run critical reports so that actionable information can be used to better serve the needs of eligible applicants, including children, and low-income citizens of Kansas. This section includes specific responses to the requirements included in Appendix 3 of the RFP. In order to meet the requirements for both standard and ad hoc reports, we are proposing to implement the Cognos 10 Business Intelligence as the reporting and business intelligence engine. Cognos 10 provides the scalable reporting functionality necessary to satisfy business intelligence (BI) needs, such as reports, dashboards, scorecards, analysis and planning. This powerful set of tools will allow KHPA the ability to access useful information to support the day to day operations and derive tactical data analysis associated with program performance and strategic data analysis associated with long-term planning. PSI is currently using Cognos to generate management and performance monitoring reports to support the Kansas Clearinghouse. As a result, the collaboration of Accenture and PSI brings a team of business and technical resources to the K-MED project with insight to the reporting needs of KHPA. The use of Cognos 10 as the Reporting and Business Intelligence solution provides KHPA with a platform that delivers complete, consistent and timely information for various user communities, on an easily scalable infrastructure allowing reporting to change and grow as the program matures. Reports generated from K-MED can be transformed into several different file types such as text and spreadsheets in order to utilize the data. We structure the reporting and business intelligence platform to support the needs of management personnel, caseworkers, and administrative personnel and provide reporting mechanisms including: Scheduled reports predefined and performance reports automatically produced by the system at a predefined time and date with specific predefined parameters. On-request reports standard reports initiated by users online within the K-MED. application. The user selects a desired report and inputs report parameters such as dates, organizational units, or programs and schedules the report for execution. Ad hoc reports custom reports that are created by users in the reporting environment and run on an as needed basis. Results are provided a soon as possible based on system performance needs. Online web pages the structure of the K-MED application provides direct access to an extensive amount of required data through on-line web pages so users do not have to run as many reports as they do today. Figure 7-49 depicts the components of the K-MED reporting infrastructure. The design uses both the production database as well as the reporting database to provide data to users of the reports. Scheduled reports along with the online web pages will principally use the production database as the data source. On request and ad hoc reports will be run from the reporting database. Users can obtain scheduled, on-request, and ad hoc reports in printed format or electronically through the K-MED application interface. In addition, report content can be exported to a number of PC file formats or other analytical tools such as MS ACCESS or a data warehouse for analysis. Cognos 10 Query and Reporting has the functionality to develop reports (standard or ad hoc), providing ability to create any number of charts, cross tabs and lists, as well as non-bi components such as images, logos and live embedded applications that can be linked to the 7-140

141 Screens from KMED application provide summary case and participant information online Online Pages Display data currently in reports User selects data to be displayed Reports requested through Cognos Query Builder using database On Request Reports views Report provided directly to user in required formats Can be run anytime system is available Report parameters entered by user View View K-MED User User Enter Data through Web Pages K-MED Production Database ETL Functions Synchronize Data Daily K-MED Reporting Database Scheduled Reports (Standard, Performance and Dashboard) Report provided directly to specified users in required formats Produced daily, weekly, monthly or quarterly according to the schedule Executed automatically based on predefined parameters Ad Hoc Reports Custom report specified by user Report displayed as soon as executed Report can be exported to PC format or database Can run anytime system is available Ad hoc Query Results can be saved as PDF files, Excel Spread sheets and other file types K-MED User K-MED Figure The Reporting and Business Intelligence Components will be integrated with K-MED facilitating scheduled, on-request, and ad hoc report creation information. This standard component of Cognos 10 will be customized to support both standard report execution and ad hoc reporting features. Within K-MED reporting, users would have the ability to customize and save standard reports specific to their role or use the ad hoc reporting tool to develop custom reports which can be saved. Authorized users can see the cases assigned to him or her including re-evaluation dates, customer names, and application dates. The variety of data offered with the application provides staff and management easy online access to the common information. K-MED reporting would allow users to create and request reports with minimal training. When users do have to produce reports, the K-MED reporting interface is user-friendly and data is quickly accessible enabling non-technical staff and management to make decisions faster. Our reporting solution also allows data input from outside sources to be used alone or in conjunction with system data to produce reports and queries. Using the Cognos Virtual View Manager, data can be combined from multiple sources into a virtual view which can then be used for reporting purposes. However, this function must be supported by data professionals who understand the data structures and can combine both system and outside data into a single, easyto-query view, without incurring the overhead of physically building a data warehouse or data 7-141

142 mart. As with all critical data, security is a key consideration within our solution. Cognos 10 Business Intelligence leverages existing enterprise security making single sign-on for authentication possible and restricting access to data according to business requirements in at the report, dashboard page, data model or individual record level. It also provides the ability to link to one or more security systems simultaneously. Cognos 10 supports LDAP, NTLM, Microsoft Active Directory, Netegrity, and SAP Business Information Warehouse (SAP BW), among others. The Accenture Team would facilitate the reporting and business intelligence platform conformity to the K-MED security architecture. The K-MED reporting solution will also support the creation of reports relating to system performance and produce metrics related to Service Level Agreements (SLAs) in the help desk and other supporting production operations environments. The Figure 7-50 below details our response to each requirement included in RFP Appendix 3, Sections A3.1 A3.8. Requirement The system will provide reports to support all system functions providing users the ability to quickly and easily access timely and useful information, providing for tactical data analysis associated with program performance, data for trending and monitoring of operational performance, as well as invaluable support for day to day operations Ad hoc reports will be produced by users with a variety of report writing expertise and will vary in range from a simple report listing to complex multi level listings The report writing solution will utilize data input from outside sources to be used alone or in conjunction with system data to produce reports The report writing solution will provide outputs in various media and formats for maximum flexibility Reporting Solution The reporting platform will include production data allowing direct access to pertinent information available for report creation. The reporting database will be optimized to allow access to data for reporting and business intelligence. Cognos 10 includes a set of comprehensive tools that will allow users to analyze data sets from ad hoc or standard reports. Cognos 10 Business Intelligence will support the creation of ad hoc reports for specified users. The platform interfaces directly with existing enterprise security making single sign-on for authentication possible and allowing the use of the same security profiles used in the core K-MED application. The reporting platform supports the full range of ad hoc reports and will allow simple queries, complex logic specifications, multiple table joins and reports with multiple levels and drill down capabilities. The reporting solution also allows data input from outside sources to be used alone or in conjunction with system data to produce reports and queries. This function is supported by a custom set of ETL functions which allow outside data to be loaded to the reporting database. Using the Cognos Virtual View Manager, data can be combined from multiple sources into a virtual view which can then be used for reporting purposes. This function will be limited to specified users with an understanding of the data relationships necessary to utilize the outside data. Cognos 10 Business Intelligence provides a comprehensive reporting solution that provides the ability to create reports containing a number of report objects charts, cross tabs and lists, as well as non-bi components such as images, logos and live embedded applications that can be linked to the information. The platform also enables users to create a single report that users can access on multiple devices, in 7-142

143 Requirement All requests for access to data for reporting or other purposes shall be accessed only through a comprehensive security handler that will manage authorization and authentication The K-MED system must be able to gather, analyze, and produce information that can be utilized by KHPA or partners to make basic business decisions The reporting system shall have a portal look and feel It shall be simple and intuitive The portal will provide access to a fully web-based reporting tool that will provide flexibility so that users can create the report they want The Contractor shall deliver the reporting tool with an initial library of the reports listed at the end of RFP Appendix 3 The reporting tool will have a compact but flexible user interface that will enable users to maximize access to information using a single screen and a minimum number of commands Reporting Solution multiple formats, in multiple media and in other applications and processes to allow for maximum flexibility for end users. Cognos 10 Business Intelligence is designed to leverage existing enterprise security allowing user profiles to restrict access to data according to business requirements including at the report, dashboard page, data model or individual record level. The K-MED enterprise security solution will be used to control access in the reports accessed through the application. Access to reporting tools would adhere to similar access controls. Cognos 10 Reporting and Business Intelligence offers various reporting approaches that can be used in any combination to deliver data in the format and with the frequency required by KHPA and its business partners. The platform expands traditional business intelligence (BI) with planning, scenario modeling, real-time monitoring and predictive analytics. Integrated access to analysis, reporting and output capabilities is a key aspect of the system. The User view provides an integrated, user-defined mechanism for bringing together the functions included in the reporting platform. Cognos is the basis for the user portal. It provides a Webbased enterprise reporting solution that provides access to reports, output from previous executions and a mechanism for filtering the output as necessary. Cognos 10 Reporting and Business Intelligence is designed to allow business users to author and modify their own reports with minimal training or IT involvement. Users can arrange report objects by dragging and dropping them into the report authoring window. Report layout automatically adapts and rearranges as report objects are added or removed. The flexibility of the task based interface reduces the time required to author and modify a report, giving business users the ability to find insights on their own, in an easy-to-use interface, using system information. Cognos 10 Reporting and Business Intelligence will integrate into the overall K-MED solution allowing users access to reporting functionality in a similar manner the rest of the application. The Cognos user interface will be shown using standard web browsers allowing users to access all of the functionality included in the tool set from desktop computers. The K-MED reporting library will be pre-configured to include the standard reports listed in the RFP. As part of the system development effort, the Accenture Team will work closely with KHPA to define each report and validate the parameters, data and formats conform to existing report requirements. Cognos 10 Reporting and Business Intelligence will be presented in a web-based format. The user interface allows user configuration

144 Requirement The reporting tool will have some basic options that work in conjunction with any applicable selection criteria as determined by KHPA Reports will permit drill downs The reporting tool will permit users to specify report breaks / sorts, font size, paper margins, and other output parameters such as output type (e.g., including but not limited to Web, Excel data file, PDF, Word, Excel report, etc.) Reports and queries may be tabular, graphical, or spatial The reporting tool must have the ability to create reports for the purpose of trending and forecasting (e.g., caseload growth with a population) The reporting tool must have the ability to use all current and future data elements so that when the software application is modified, new reports can be created by accessing the new data elements Users shall be able to store individualized selections of these reports and related dashboard elements The Proposer shall estimate the work effort required to complete all custom reporting needs Proposer shall assume that contingency reports are to be custom-developed and are NOT part of the reports delivered as part of the proposed software solution, are NOT a part of the reports proposed to meet requirements, and are NOT those listed at the end of RFP Appendix 3 The Proposer shall include the estimated cost of providing this reporting contingency for custom reports in the Reporting Solution Cognos 10 Reporting and Business Intelligence contains a comprehensive set of tools that support reporting and business intelligence. The toolset has basic features that will allow users to run redefined reports on-demand with the set of input parameters desired. Cognos 10 Reporting and Business Intelligence allows for report and query design to include drill down capability as well as complex analytical functionality. During design specific drill down requirements will have to be defined within summary reports. Calculated values may also be used as query parameters (e.g. request unearned income for cases in counties greater than a certain amount). Cognos 10 Reporting and Business Intelligence places reporting control directly in the user s hands allowing authoring and modification of their own reports with minimal training or IT involvement. Users control report formatting by arranging report objects by dragging and dropping them into the report authoring window. Report layout adapts and rearranges as report objects are added or removed. A set of report object is supported and the output of reports can be exported to a large number of PC formats. The reporting solution facilitates the creation of reports containing a number of report objects charts, cross tabs and lists, as well as non-bi components such as images, logos and live embedded applications that can be linked to the information. Cognos 10 delivers traditional business intelligence (BI) with planning, scenario modeling, real-time monitoring and predictive analytics. Reports would be created from both the production and reporting databases. As data elements are added or modified, both databases would be updated to reflect the new data allowing the reports to access and utilize the new data elements. Cognos 10 Reporting and Business Intelligence stores user work and report results in a folder structure allowing users to save and access report components. The K-MED reporting solution includes the estimate for all custom reporting needs. The contingency reports are not included in the standard reports that will be created by the Accenture Team. The Accenture Team has provided estimated costs of providing reporting contingency for custom reports as part of our cost proposal

145 Requirement Reporting Solution separate Cost Proposal The Proposer shall plan for: The reporting solution contains the 111 reports included in Seventy-five (75) pre-defined reports the RFP Appendix 3. We have also included in our estimate or queries in the reporting tool 75 pre-defined reports or queries that will be developed and library; included in the report library. We have assumed that a The reports listed at the end of RFP number of these reports will be used for dashboard and other Appendix 3 performance reporting. Because of the extensive online data The reports or queries deemed available from K-MED application, we have not assumed any necessary to meet requirements new reports will be developed to meet non-reporting A contingency for 60 custom reports requirements. The K-MED solution will use Cognos 10 as defined by the level of complexity Reporting and Business Intelligence as the basis for the in RFP required reports. We have included contingency for 60 custom reports as required by the RFP. Figure Our response to RFP Appendix 3, Sections A3.1 A3.8 requirements Standard Reporting Standard reports are a critical component of the K-MED solution and standard reporting represents a large amount of the functionality included to fulfill your reporting and BI needs. Standard reports are used in monitoring program utilization, managing daily operations, overseeing the program budget and initiating program changes in response to trends identified through the analysis of data. Standard reports generally have a fixed format, are parameterdriven and, in their simplest form, are automatically run according to a pre-defined schedule. The Accenture Team has reviewed the reports included in RFP Appendix C and is prepared to deliver the pre-defined reports. In addition, our standard reporting estimates include an additional seventy-five (75) pre-defined reports or queries that will be included in the report library. Given the requirements for performance analysis and dashboards, we have assumed that many of these 75 reports will be used to meet these requirements. The Accenture Team will prepare the initial set of standard reports and save them in the report library. In addition, state and federal reports may include functionality to enable sequential creation with necessary parameters present. Reports will be developed to contain a save path that points to the report repository directory structure. The report repository will be designed as an online application which authorized end users can search for, view and print reports contained in the reporting platform based on a static set of parameters. Optionally, we can configure the standard reports to be electronically distributed to a target user audience via an attachment through . Cognos 10 Reporting and Business Intelligence facilitates the generation of standard reports by allowing report templates to be developed to include standard report objects, queries, and layouts. Cognos 10 Reporting and Business Intelligence include analysis tools which can be used on the data results of the reports with drill down capabilities to allow users view the detailed data sets used to create the summary. The reporting tools will support the development of standard reports including: The generation of standard reports with or without customization and functionality to allow modified reports to be saved for future use. The execution of standard reports automatically on a pre-determined schedule with a static set of input parameters. Security on the report repository

146 A user-friendly and graphic environment that allows fast and flexible views of data, including summaries and drill downs. Functionality to allow incorporation of charts, graphs, images and GIS data. As part of our standard reporting design, we provide the ability to measure performance for multiple KHPA business processes through definition of Key Performance Indicators (KPIs) and dashboards. During design, we will work with KHPA to define the KPIs for each of the high profile business processes supported by K-MED. In parallel with the definition of our KPIs, we will work with the K-MED data architects to validate that required data elements are included in the K-MED data model. Once the KPIs and associated dashboards have been defined, we can configure the reporting solution to provide numerous performance monitoring capabilities for KHPA, including: The use of performance measures to compare outcomes at multiple organizational levels. (e.g. regional comparisons, caseworker comparisons, etc.) Selection of a pre-defined list of data elements related to performance in a particular monitoring area, such as timeliness, to assess performance in that particular business function. Outreach tracking, based on the desired outcome measurements identified by KHPA during design. Trend analysis between different outcome measures (e.g. increased caseload size may cause increase in eligibility determination errors) Through integration with the K-MED workflows, we can configure the solution to alert users when performance indicators are not within specified parameters (e.g. if pending benefit authorizations have exceeded a pre-defined amount). Creation and maintenance of parameters used to measure expectations at the program, organization, and worker levels. Tracking of progress-related objectives (e.g. worker increase in the rate of completing redeterminations as compared to a previous period of time). Parameter driven tracking, which allows tracking of new objectives based on a potential change in KHPA policy (e.g. timeliness standard changes). Our parameter driven approach also allows users to set the timing and update frequency of performance reports in their areas of responsibility. The K-MED reporting solution will also produce standard reports relating to mass change processing. Our mass change processes track all changes made to case information at the program and the client level. We produce monitoring reports and control reports based on the results of any mass change process Ad hoc Reporting One of the main functions of a reporting and business intelligence system is to provide a mechanism for customizing standardized reports or building ad hoc queries on any aspect of an enterprise s data whenever a need arises without having to utilize technical staff to develop the query. In many instances special requests are received which require reports to be generated immediately. Our K-MED solution provides a mechanism to allow this to occur. Ad hoc reporting is a key component of the K-MED reporting system. The Ad Hoc reporting function will be handled through Cognos 10 Reporting and Business Intelligence. This component of the reporting platform contains multiple functions. The ad hoc 7-146

147 functions of the reporting platform will be configured to access data in the reporting database which is scheduled to be synchronized on a timely basis. Cognos includes the following functions to be performed during the generation of an ad hoc report: Insert Data this functionality allows users to choose the data they want to include in the report from a listing of available database tables in a published schema. The data selected is included in the query. Drag and Drop functionality is included. Edit Data this functionality allows users to specify what functions should be performed against the data. This feature can be used before the query is executed or after a result set has been created. Change Layout this function provides users with the ability to select how the data is displayed. It contains the ability to create charts, define conditional studies or change the format of the report being generated. It also contains additional functions to summarize data within the report or create different sections. Run Report this function allows users to specify the run time execution parameters and decide how much data should be extracted. It also allows the user to specify how they want to view the results sets including direct integration with Excel, XML and PDF. Manage File this function provides users with the ability to create new reports or save a report once it has been developed. It also includes the functions for defining a new report. Cognos 10 provides extensive functionality to users, with powerful, yet easy to use, tools to define custom queries. Users can further limit the parameters through a blank report layout screen. Users can simply drag and drop the desired data elements into the report format portion of the report. Once data has been selected for an ad hoc query, the user can execute or edit it to determine what filters will be needed, and what, if any, calculations or summarizations will be applied. The K-MED data model tracks the source of data (e.g. data that originated from an interface) which allows users to filter reports based on data origination. Cognos 10 Business Intelligence provides tool bar functionality as well as drop down windows and lists of functions to make the process of Integration of Cognos 10 Business Intelligence (BI) with the APSP platform will provide KHPA with a real-time view of performance across programs and organizational units Cognos BI supports Web Browser access to reports, dashboards and ad hoc reporting pages allowing users to customize the tools they see. End-users can build ad hoc reports or queries through a web browser interface allowing an integrated view of the K-MED data or run preexisting reports using the same web functions. End user can easily generate a report on ad-hoc basis or put the report generation on pre-built scheduler for distribution. Cognos 10 Reporting and Business Intelligence leverages existing enterprise security making single sign-on for authentication possible and restricting access to data according to business requirements. defining the data effective and efficient. Reports are stored in a directory structure when executed and users are able to store both the reports and the results. The ability to analyze data is another key component of the ad hoc reporting functions. Cognos will be used to access the reporting database data model and metadata models and provide large volume data analysis capabilities. Analysis tools will be deployed as a Web-based tool to support data analysis. Cognos expands traditional business intelligence with planning, scenario modeling, real-time monitoring and predictive analytics. The Accenture Team will work with KHPA to determine the best methods for implementing this functionality into the reporting environment. The combination of our database design and the use of the flexible Cognos 7-147

148 reporting tool will allow users to retrieve data at multiple levels and utilize all data elements to produce reports. For example, the user will be able to specify queries that will return data at the case level, customer level, supervisor level, and count level, etc Reporting Infrastructure and Environments The K-MED reporting and business intelligence environment has been designed to provide the functionality specified in the RFP. We propose Cognos 10 Business Intelligence as the basis for defining all reports, implementing the various reporting environments and executing the reports as required. We have developed an approach that uses the production database as the basis for performance and dashboard reports along with pre-defined production reports. We have coupled this approach with a separate mirrored reporting database that will house the ad hoc reporting environment and be used to run reports on-demand. Cognos 10 Reporting and Business Intelligence provides comprehensive tools that allow access to the complete mix of data sources included in the K-MED solution including the production environment, reporting database, OLAP cubes, legacy data sources or modern data sources. We would implement Cognos 10 Business Intelligence across the K-MED databases to facilitate synchronization between the production and reporting databases. This approach allows the reporting and business intelligence to easily integrate additional program requirements; data modeling changes, and the use of historical data for trend analysis. We will work with KHPA during design to review the data requirements for each component of the reporting and business intelligence infrastructure to determine the best solution for providing the required reporting. We intend to maximize the use of Cognos 10 Reporting and Business Intelligence to support dashboards, data analysis and drill down capabilities; using the production database only for those items that require real-time data. The reporting database will be used to support all other reporting and since it has the same data structures as production, it can be used form the majority of the additional reporting requirements. Figure 7-51 depicts the reporting infrastructure being proposed for the K-MED solution. Real-time and Scheduled Batch Top Tier Portal ETL functions sync daily K-MED OLTP Cognos Data Cube Cognos 10 BI Real-time Cognos 10 BI Pre-Defined Reports Performance Reports and Dashboards Standard Reporting Reporting Cognos 10 BI Ad hoc Reports On Request Reports K-MED Figure The reporting database architecture and integration of Cognos BI Facilitates the creation of actionable reports and dashboards

149 The Accenture Team understands the performance considerations that must be contemplated when final infrastructure decisions are made. We have designed the reporting environment to use real-time production data as the basis for the creation of performance and dashboard reporting. We intend to build a series of OLAP Cubes that will facilitate this reporting, allow performance standards to be met and minimize the impact of these reports on the overall performance of the production environment. The Accenture Team will work closely with KHPA to identify specific dashboard and performance reporting requirements that must access real-time data. For reporting that does not require real-time data, functions will be included in the reporting platform to minimize the impact on the production system. The reporting and business intelligence platform will also use the production environment for pre-defined reports. We plan to run daily, weekly, monthly and quarterly pre-defined reports based on static input parameters and timeframes directly against the production environment after ordinary work hours. The reports will be run automatically and the output will be distributed appropriately. Using this environment for the production pre-defined reports allows us to utilize up-to-date data. The Accenture Team will work with KHPA to determine approved operation time parameters for running reports against the production (OLTP) database. Ad hoc and on request reports can be run against the reporting database nearly anytime, except in the cases where the database may be offline due to maintenance or upgrade. In order to support ad hoc reporting and the execution of on-demand reports, the reporting and business intelligence platform will contain a separate reporting database. This environment will support KHPA s need to create ad hoc reports or to execute pre-defined reports in an ondemand fashion. The reporting database will be synchronized with the production database on a timely basis following the work day. The synchronization process will provide the State with a reporting environment that closely mirrors the production database with minimal lag. This approach allows KHPA access to a close mirror of the production database at any time to support program reporting and management needs Enhancements and Modifications APSP provides a modifiable solution with end-to-end modification methodologies, tools and processes to lower implementation risk during patch, fix, and upgrade scenarios. A flexible modification process, including tools and methodology, provide ongoing flexibility in the K-MED solution. End-to-end support during modification process Easily modifiable products evolve with K-MED Standard modification processes to ease patch, fix, and upgrade efforts Enhancements and Modifications The Proposer shall describe its approach to making enhancements or modifications to the baseline software solution in a manner that facilitates an easy, low-cost, and low risk migration to new releases of the baseline product. The Proposer shall describe its approach to coding and documenting modifications in such a way as to ensure that they can be easily re-applied when the State upgrades to new releases of the proposed software. The Proposer shall also include its business-justification process for prioritizing and approving each of the identified potential enhancements. While the State intends to minimize modifications made to the software to the maximum extent possible, it is expected that some modifications will be required. Once proposed modifications are identified through the fit/gap analysis process, the Contractor shall work with the appropriate State business analyst(s) to prepare a high-level design document with cost estimates for review and approval by State project leadership. Upon approval, the Contractor 7-149

150 shall produce the detailed technical design and develop the approved modifications. The Contractor shall be responsible for the functional and technical designs, coding, unit testing, and integration testing of all modifications. All modifications shall be documented in such a way as to ensure that they can be easily reproduced when the State upgrades to new releases of the proposed software. The APSP products proposed in the K-MED solution provide the flexibility to be modified as needed to satisfy current and future K-MED requirements. The types of modifications are dependent on the APSP product. The following paragraphs will detail each APSP product, the type of modifications possible for that product, and the process for retaining those modifications as the product is upgraded or patched. APSP Platform Upgrades The APSP Platform is a technical architecture that provides application programming interfaces (APIs) for access to the underlying COTs products and myriad frameworks and services provided by the platform. Figure 7-52 shows the modification points in the APSP Platform. Architecture Layer Modifiable? Supported Modifications Integration Architecture Product Adaptors New Yes Adding new in-bound and out-bound Web Services Editing inbound and outbound Web Services Adding new calls to invoke services locally Editing calls to invoke services locally None Architecture Dependencies Yes Adding Adaptor for new product Product libraries Product No None Applicable None Applicable Adaptors - Existing Architecture Code Yes Adding code alongside existing libraries for new framework or service. APSP libraries. API Adding APIs Yes Adding API alongside existing libraries APSP libraries. for new framework or service Adding API alongside existing libraries for new product API Changing APSP APIs No None Applicable None Applicable Figure Modification Points for the APSP Platform APSP modifications most often come in the form of custom architecture code that extends the APSP libraries and in new API additions added alongside the APSP APIs. For example, in the future, K-MED might seek to integrate a medical diagnosis code search engine, such as ICD- 10. K-MED developers would complete the following steps to add an architecture service that interacts with a diagnosis code search engine. K-MED engineers contact the APSP Service Desk and complete an APSP Enhancement Request. This will give APSP engineers an opportunity to share any possible road map details concerning the enhancement and provide design and implementation guidance to the K-MED engineers

151 K-MED engineers build the diagnosis code search engine enhancement. The implementation will likely require a lightweight product adaptor for the diagnosis code search engine, some basic code for handling inbound requests and outbound responses, and a well defined API so that all applications running on APSP know how to access the service. At this point, K-MED has successfully created a new architectural service. K-MED will test the enhancement according to K-MED standards. Upon deployment of the new diagnosis code search engine service into production, K- MED engineers update the APSP Enhancement Request to document usage changes made relative to APSP architecture code/libraries. This documentation is focused on library dependencies and build and deployment changes. At this point, the enhancement is in production and accounted for by the APSP team. Custom build scripts will be created to include the latest changes to the architecture code. As with every patch, fix, or upgrade, APSP engineers will apply the upgrade to the K-MED codebase in the APSP test lab. Once the upgrade has been verified in the APSP test lab, Accenture will work with KHPA to install and fully regression test the new platform upgrades in a KHPA staging environment to verify that platform changes did not introduce any issues prior to promoting the platform upgrade into production. The APSP APIs, architecture code, and product adaptors are not directly modifiable by K- MED as these enforce the interface contract between APSP, the APSP Public Assistance Portal and the APSP Self-Service Portal, and the underlying commercial products. If an enhancement is required for these layers, then the K-MED engineers would contact the APSP Service Desk with an APSP Enhancement Request. APSP engineers would then modify the API or adaptor in question and it would be made available in the next APSP release. APSP Public Assistance Portal and APSP Self-Service Portal Upgrades The APSP Public Assistance Portal and APSP Self-Service Portal can be extended via page flow, screen layout, user defined fields, business processes, rules, and table/schema changes. Figure 7-53 shows the supported modifications for these two applications. Application Layer View Components Modifiable? Yes Supported Modifications Adding or editing of: Portlets Screens Panels Menus Controls Labels Stylesheets Controller Logic Yes Adding or editing of: Application page flow Conversation Logic Business Processes Yes Adding or editing of: Process flow Process routing rules Escalation rules Business Rules Yes Adding or editing of: Rule determination calculations Rule thresholds Rule priority Code Item Changes to APSP Public Assistance Portal and/or APSP Self-Service Portal code. Changes to APSP Public Assistance Portal and/or APSP Self-Service Portal code. Changes to BPEL and Human Task workflows. Changes to Rulesets

152 Application Layer Modifiable? Supported Modifications Model Logic Yes Adding or editing of: Object Model Data Access Database Components Yes Adding or editing of: Data Model Database applications Code Item Changes to APSP Public Assistance Portal and/or APSP Self-Service Portal code. Changes to APSP Public Assistance Portal and/or APSP Self-Service Portal code. Configuration Yes Configuration files Changes to APSP Public Assistance Portal and/or APSP Self-Service Portal code. Figure Modification Points for the APSP Public Assistance Portal and APSP Self-Service Portal The process for changing these items is that same as that outlined in APSP above. The overall process offers end-to-end support for K-MED resources during both application modification and then again during the upgrade, patch, and fix cycles. Note that several configurable aspects of the K-MED solution, such as business rule changes, business process management workflows, and service orchestrations are not included in this modification process. Accenture believes this is one of the primary benefits of the APSP-based K-MED solution. Changes to these objects should be efficient and tool-based to promote flexibility in the system, the opportunity for continuous improvement, and ease of use for business analysts that don t require technical or programming support Interface Development The Accenture Public Service Platform (APSP) already performs many of the required Federal system interface processes. We modify our alerts, reminders, and control functionality to meet the unique needs of K-MED. A Flexible SOA-based Interface system supports accurate and timely exchange of information with external systems Exchanges data with over 60 external systems Reviews and conveys information for over 1.1 million cases and 2.1 million participants New interfaces easy to create and modify Deep experience with building and supporting interfaces similar to MMIS A4.1 The Proposer shall describe its approach for the design, development, testing, and deployment of automated interfaces between the K-MED system and all other systems. The K-MED system must interface with various State and Federal Agency systems, and with various contractor systems. With the implementation of the Affordable Care Act, KHPA will be required to interact and exchange data with a significantly increased number of customers and entities. The degree to which new eligibility systems are deemed successful is based on many criteria. One such criterion is whether the system is successful in transferring information between the myriad of stakeholder systems. Past performance successfully demonstrates Accenture s ability to execute interface development and significantly reduces K-MEDs implementation risk. Figure 7-54 provides an overview of the Accenture Enabling Features that we provide as part of our K-MED solution for the State s requirements for interface processes with other systems, internal and external to the State

153 K-MED Objective Value to State Accenture Enabling Features Accurate, timely extract and exchange data of with other agencies and entities Identify discrepancies, notify the worker as appropriate, and proactively manage resolution Proactively update appropriate case information Reduces the paperwork burden, enhances the verification of data, and prevents the duplication of data entry Enhances the coordination of services and timely exchange of information with other agencies Promotes case accuracy and customer service Reduces paperwork burden on users Promotes case accuracy and provides a record of action taken Existing, proven, and operational interface configurations Easy creation and/or modification of new or existing interfaces Proven business logic to identify discrepancies User-friendly, non-code notifications to workers Automatic entry in Case Comments of action taken by K- MED Figure Effective electronic interfaces reduce the workload burden on caseworkers while also enhancing case accuracy and customer service Interfaces provide the State a mechanism for identifying case or client information discrepancies and/or changes to an individual s information. Our fully configurable interface solution supports the K-MED requirement to exchange information with other systems, internal and external to the State. Our SOA based Application Architecture allows for open and secure communications between the K-MED and other systems. Our K-MED solution achieves this in several ways. One way is a real-time interface. A real-time interface opens up a connection with the interface partner through a transaction initiated through the online K-MED application. Another way is through a scheduled batch process. We work with the State to establish a schedule for the frequency of the batch interface processes. Our K-MED interface solution supports one-way and two-way communications and the need to send and receive information among systems. K-MED receives information automatically from matches with external and internal systems and updates the database accordingly. The system uses parameterized rules provided by the State to identify individual and case discrepancies such as SSN mismatches, dates of birth, income and other information variances. We use our APSP alerts functionality to notify the State-specified users of these discrepancies. Our APSP controls functionality track and monitor the resolution of discrepancies identified in the interface process that require worker review/action. Executing interfaces with other entities and systems is a valuable process for identifying individual, case and/or assistance group discrepancies. It is also critical for important fiscal, issuance, referrals, reporting and other administrative functions MMIS Interface A4.2 INTERFACING WITH THE MEDICAID MANAGEMENT INFORMATION SYSTEM (MMIS) The interface with the MMIS is a critical component of the K-MED system. This connection must operate timely and correctly in order for consumers to receive necessary benefits. The MMIS currently provides some processes that K-MED will assume upon implementation. This is being done to gain efficiency and to improve the exchange of information between the eligibility and delivery components of the medical programs

154 Accenture develops and supports highly successful key interfaces that are very similar to the MMIS interface. We work closely with KHPA to develop an interface that is accurate, timely, and secure and can meet set requirements. Our APSP eligibility calculation tools enable K-MED to calculate and store each member s eligibility information and only send the final eligibility segment to MMIS. Thus, the MMIS would no longer calculate member eligibility. Our K-MED solution would exchange Long Term Care information, Third Party Liability information, and incorrect payment information with MMIS through the MMIS interface. This solution positions K-MED on track to meet KHPA s long term goal of completely integrating K-MED as a member sub-system of MMIS. We continue working closely with KHPA to accomplish this goal, and submit a detailed proposal to KHPA with the planned procurement in Interface Implementation Services A4.3 INTERFACES IMPLEMENTATION SERVICES Three primary areas of responsibility for interface implementation services are: 1) management of all K-MED related interface activities; 2) development of interfaces from K-MED; and 3) development of standards for interfaces into K-MED and assisting KHPA business partners interfacing into K-MED. More specifically: Our dedicated Interface development team is responsible for design, development, testing, maintenance, report reconciliation, and procedure documentation of the K-MED interfaces. Additionally, the interface development team develops interface standards to be used by K-MED and the related interface business partners. We work to manage the interface development processes in accordance with the interface standards and Federal, State, and agency regulations. Additionally, we provide consulting to the related interface partners with the interface process and assistance with interface testing. As part of our interface management process we create a master interface development schedule to track the development progress. We integrate the interface schedule with the overall project schedule. Additionally, the interface development team works with the State and its business partners to meet agreed upon development and testing deadlines. We work closely with the State throughout the development process and report agency progress accordingly Requirement Responses We provide responses to interface K-MED requirements. Where applicable, we provide responses to logical groupings of K-MED requirements. Figure 7-55 below is representative of these groupings. Also, where individual requirements are addressed in the body of the text, the requirement number follows in parenthesis. Requirement (A4.4 1, 2, 3, 16) (A4.4 5, 7, 8, 9, 10, 11, 12, 14, 23, 25) (A4.4 4, 13, 15) (A4.4 6) (A4.4-17, 18, 19, 20, 21, 22, 24) Requirement Summary General Data Exchange Analysis & Notifications Information, Access, Records, and Reports Security & Compliance Figure The requirement categorization within each requirement group 7-154

155 General APSP is a SOA based system, and it includes proven batch and interface processes that facilitate accurate and timely data exchange between internal and external interface partners (A4.4 Req 2). Our proven batch and interface solution exchanges data with over 60 external systems and reviews and conveys information for over 1.1 million cases and 2.1 million participants (A4.4 Req 3). The Batch/Interface processes are managed by a full time development team (A4.4 Req 1). Our APSP tools facilitate easy additions, deletions, and modifications to interfaces for data import and export (A4.4 Req 16) Data Exchange Our APSP tools support system interfaces and integration between the K-MED application and the multiple technologies of users, external systems, and various application service components. The K-MED System automatically triggers a request for information from a specified business partner (A4.4 Req 14). The request is then sent to the respective partner through the interface, and information is retrieved similarly through the interface. Alerts and reminders are generated automatically during the interface process and sent to the respective K-MED users (A4.4 Req 5). Figure 7-56 illustrates the Interface process cycle of our K-MED solution. Data transferred through the K-MED interfaces is secured using SFTP protocol to protect the information s integrity. Once a file is received by K-MED, the file is archived on a file server, and access to the archived files can be limited by the State as needed (A4.4 Req 7, Req 8). The Interfaces are customized to transfer a variety of file formats determined by the State (A4.4 Req 9). Similarly, our solution enables the K-MED system to send and receive files with various media and file types (A4.4 Req 11). The interface processes can be scheduled to transfer information daily, weekly, or monthly, as specified by the State (A4.4 Req 10). Database tables are created to store data received through each interface. Thus, if a received file needs to be removed from the K-MED system due to an issue, we create a data change request to remove the error records from the respective interface table, and if needed, archived files can be removed from the file server one by one or in mass (A4.4 Req 20). Our APSP solution supports an interface with the Image Now Document management system Interfaces External/Internal System K-MED Triggers System Updates Interfaces Federal State County Generate Alerts and Reminders System Updates Resolve Alerts and Reminders K-MED Figure Our K-MED solution s interface function allows K-MED to exchange information with other systems, reducing processing cycle time and helping maintain low error rates 7-155

156 (A4.4 Req 23). Thus, facilitating easy on-site scanning of the documents, and input into the K- MED application. Our outbound interfaces are designed to be able to re-query the external systems and resend datasets back to the K-MED application as needed (A4.4 Req 12). Additionally, our K-MED solution includes an interface to the Geographic Information System (GIS) that supports KHPA s business objectives including address creation and maintenance (A4.4 Req 25) Analysis and Notifications Our solution validates incoming interface information, checks for file duplicates, transforms the data to the format needed by the K-MED system, and loads the incoming data into the K- MED system (A4.4 Req 13). The rules for data filtering, validation of data matches, and data manipulation for each interface are determined by the State (A4.4 Req 4). Our solution identifies and determines the significance of discrepancies between the K-MED data and data received from external interfaces. Our K-MED solution takes automatic action on these discrepancies or provides an alert to designated users so that they could research and resolve the discrepancies. Our K-MED solution parses and display these alerts as system-related and user-related errors with reports generated for analysis and corrective action. We analyze interface alerts, perform corrective action for system-related errors, and provide recommendations for interface alerts resulting from user-related errors. notifications can be sent to appropriate personnel once a data transfer is successfully or unsuccessfully transmitted or received (A4.4 Req 15) Information, Access, Records, and Reports Our APSP application tools display summary and detailed interface data received from external systems. This information can be easily searched and reviewed by staff members (A4.4 Req 6). Our K-MED reporting and application tools track and keep a history of all interface activity and information. They also provide the ability to compile statistics and generate standard and ad hoc reports Security and Compliance Our K-MED interface solution archives all interface files in accordance with Federal, state, and agency statutes, regulations, and policies (A4.4 Req 21). This includes compliance with National Information Exchange Model (NIEM) and National Institute of Standards and Technology (NIST), and Health Insurance Portability and Accountability Act (HIPAA) standards (A4.4 Req 22). Security profiles are assigned to all inbound and outbound interface data at the data element and record levels (A 4.4 Req 17, 18). Thus, limiting who can review, send, and receive interface data. To maintain an audit trail of all interface data, each interface data record includes the worker id of the worker that created the record and the worker that updated record, and also a timestamp of when the record was created or updated. Each record also includes a description of the action taken by the worker (A4.4 Req 19). We work with KHPA to create an interface and data storage process for Social Security Administration (SSA) data. Our K-MED solution includes an audit tracking application that tracks system usage and allows K-MED to be compliant with SSA regulations including the requirement to capture who created, updated, and looked at records and data elements with SSA data (A4.4 Req 24)

157 Contingency Interfaces A4.5 CONTINGENCY INTERFACES The Proposer shall include the estimated cost for providing contingency interfaces in the separate Cost Proposal. Interfaces contingency funds shall be used or not used at the discretion of the State, and any interfaces contingency funds not used for that purpose may be applied to other project areas as the State deems in its best interest. Our Interface development team works closely with KHPA and if contingent interfaces need be developed, we work with KHPA and the respective business partners to develop and integrate the new interface(s). Please refer to the Cost Proposal for pricing estimates Interfaces Our K-MED solution uses our APSP tools to support interfaces as described in RFP Appendix 4 Interfaces Requirements and s. We have reproduced an excerpt of the interface list (A 4.6) below in Figure 7-57 providing a list of some of the interfaces that are to be developed as part to the K-MED solution as well as an Approach Summary for each interface. Interface Name - Information Exchanged Referrals to Child Support Enforcement Medical Eligibility Information PARIS (Public Assistance Reporting Information System) Interstate Recipient Match Information Driver s License & Vehicle Registration Purpose of the Exchange Referrals are received from AE, when a Medical case has opened. Provides absent parent (AP) name and other details such as marital status, location of AP, child support court orders/payments. The State determines eligibility for medical programs, and records this information in KAECSES. KAECSES transmits a file of eligibility to the MMIS daily and once a month. The MMIS then determines the benefit plan, issues medical cards and pays claims etc. A file of applicant/recipient records are sent to match to other records of other states beneficiaries. The file of match results is used to produce reports for staff Allows eligibility staff access to Driver s License and Motor Vehicle Registration databases to obtain required personal information such as drivers license number, SSN, DOB, address, or to verify vehicle registration for use in eligibility determinations. Approach Summary Our development estimates include working with KHPA to develop and integrate this interface with K-MED. A similar capability exists in APSP. Our development estimates include working with KHPA to develop and integrate this interface with K-MED Our development estimates include working with KHPA to develop and integrate this interface with K-MED Our development estimates include working with KHPA to determine the feasibility of integrating this interface with K-MED and developing a solution accordingly. Figure The capabilities of the APSP lower the risk in the development and implementation of the K-MED interfaces 7-157

158 Data Conversion Accenture, KHPA, and agency collaboration throughout the K-MED conversion process would increase the ability to provide complete eligibility history of medical assistance participants, completion of pending processes upon implementation, and limit disruption to work required for eligibility determination Data Conversion In this section, the Proposer shall describe its approach to performing all required data conversion activities associated with the project, including developing a Our conversion approach results in a successful data migration with minimal disruption to participants and to County Operations Accenture successfully converted 35 additional counties from disparate legacy systems to the C- IV Welfare and Eligibility Determination system with a high level of accuracy Accenture successfully converted 122 million person accounts, 250 million addresses, 500 million relationships, 120 million assessment components for the U.K Department for Works and Pensions Experience from many large scale human services systems implementations, including California C- IV, Texas CAPS, and Idaho IBES that were completed using Accenture Conversion Methodology and expert resources comprehensive Data Conversion Plan. The detailed requirements and responsibilities for data conversion are described in RFP Appendix 5 Data Conversion Requirements and s. A5.5 CONVERSION PROPOSAL INSTRUCTIONS Each proposal must lay out a conversion strategy/approach that the vendor feels will best meet the needs of K-MED. The approach shall include conversion planning and analysis activities as well as execution. The approach shall identify any perceived conversion risks/unknowns based on the proposer s experience in converting key data. The proposer should review the requirements above and the requirements associated with the Conversion Plan deliverable (RFP Appendix A ) and explain how these requirements shall be met. The proposal must clearly describe the processes that will occur, the expected length of time of each step, and other information necessary to provide a complete picture of the proposed solution. The proposed conversion approach must address statewide, agency-specific, and supplier data conversion requirements, and include a Data Conversion Plan. The Contractor shall have on its project team a dedicated full-time Conversion Lead. The scope of the data conversion shall include data elements from KAECSES-AE, the PSI Platform, and MMIS. Conversion data, associated source (e.g., PSI, MMIS, KAECSES-AE), and related tables must be clearly identified during the data mapping effort. Please see the list of required conversions at the end of RFP Appendix 5 (this Appendix please see below). For purposes of the procurement and to ensure an apples to apples comparison of data conversion costs, each vendor shall develop their proposal assuming that the following data comprise the final system file: Demographic and personal data required to set up the master case; Application/review dates; Eligibility coverage periods/dates; Individual history; Case history; Detailed past eligibility history; Detailed non-financial eligibility determination; Detailed financial eligibility determination (income and resources); Detailed assistance plans; Detailed past budget information, as applicable; Eligibility segments for individual eligibility and history; Case log; and Ensure that medical cases are no longer recorded in KAECSES-AE

159 Proposers shall bid the costs and approach if five years of data is converted, and provide the additional cost if another five years of data is converted, bringing the total to ten years of converted data available at go-live. Please see RFP Section (COST PROPOSAL TAB 5 -- SCHEDULE 5 -- STAFFING PLAN BY POSITION). In addition to the conversions listed at the end of RFP Appendix 5 (this Appendix please see below), the Proposer shall also plan for the following contingency conversions as determined to be needed by the State. The Proposer shall assume that the custom conversions are defined by the following levels of complexity: The Proposer shall include the estimated cost for providing contingency conversions in the separate Cost Proposal. Conversions contingency funds shall be used or not used at the discretion of the State, and any conversions contingency funds not used for that purpose may be applied to other project areas as the State deems in its best interest. The Cost of the conversions contingency shall be shown as a Payment Deliverable titled Contingency Conversions in Cost Schedule 3 Deliverables Payment (see RFP Section 3.6.7). KHPA prefers a big bang conversion. KHPA may consider a phased conversion approach depending upon the risk and cost. The Contractor shall be expected to complete conversion and implementation according to the prescribed approach. Under KHPA s direction, the Contractor is responsible for developing conversion routines and scripts to bring KHPA data into the new environment(s). The Contractor shall be responsible for conversion to target multiple environments, as necessary (e.g., development, system test and user acceptance testing, operational readiness test and production). All data conversion plans, approaches, and data mapping scripts must be reviewed and approved by KHPA prior to execution. These conversion services shall be described in TECHNICAL PROPOSAL TAB 7 (see RFP Section ) and priced in the separate Cost Proposal. Figure 7-58 below highlights the RFP requirements for the Data Conversion Plan deliverable, along with a reference to the sections within the proposal that explain how the unique needs of KHPA, agencies, and ultimately K-MED s clients would be addressed through the Accenture Team s successfully demonstrated conversion methodology. This plan represents the Conversion Plan that will be further developed by the Accenture team with input from the K-MED stakeholders throughout the K-MED project. Requirement Developing and testing automated conversion programs to support the commencement of test and production operations Working with the KHPA to map the conversion by field, define the conversion logic, and design the conversion processes Developing programming specifications Coding conversion programs in accordance with specifications Performing unit and integration testing of the conversion programs Response Section Develop and Test Design Design, Develop and Test Develop and Test Develop and Test Executing programs to convert legacy data into the new system Building any crosswalk file structures required to assist KHPA in developing test scenarios Conducting acceptance testing Building history records Running the conversion programs and assisting KHPA with verification of the converted data in the production environment Developing data transformation and purification cleansing procedures System Test and UAT, Mock Conversion, Execute Design System Test and UAT System Test and UAT, Mock Conversion Analyze, Design, Develop and 7-159

160 Requirement Response Section Test, System Test and UAT Producing conversion reports (missing data, bad data) before Develop and Test, System conversion, so that KHPA can facilitate data correction Test and UAT Develop programs and / or procedures to add missing data or correct Develop and Test, System invalid / incorrect values Test Transform data to the new format per KHPA s specifications, so that the Develop and Test, K-MED System can accept the values (e.g., changing code value from one byte length to longer length of meaningful name) Develop data correction/validation programs. These procedures can Develop and Test correct bad data identified during or after conversion for an individual case or an entire group of cases Develop assisted manual conversion procedures for loading all data System Test and UAT that cannot be loaded using automated conversion programs and provide oversight and support for KHPA, agencies, and KHPA contractors as requested If determined necessary, develop assisted conversion protocol, so that System Test and UAT a staff person will be able to attach documents from case file Provide workflow for conversion, so that a staff person can easily Document Imaging transition any case fully to the new system. This process may include Services attaching imaged documents, updating data in K-MED, correcting an incorrect determination, etc. The workflow process must link associated electronic documents (existing images in KHPA ImageNow) from the converted data to make electronic case records. This conversion workflow must be reviewed and approved by KHPA. Figure Each of K-MED s unique requirements will drive the various stages of Accenture s Conversion Methodology Conversion Strategy and Approach According to the K-MED RFP, the KAECSES-AE system manages approximately 2.8 million clients, PSI source contains more than 880,000 member records, MMIS contains greater than 815,000 cases determined by SRS, and PARTS contains approximately 42,000 Presumptive Eligibility Disability determination cases. Based on these data volumes and disparate sources, Accenture s proven conversion methodology should be considered throughout the development phases for the automated conversion process. With our K-MED Blueprint solution and data conversion approach, the system file required allowing pending work to be completed by workers, and coverage to remain in place for clients would be priorities as outcomes of a Big- Bang Approach. Our conversion strategy is to use tools and previous eligibility systems conversion strategies to maximize automation and reduce the impact that manual conversion presents for K-MED users. Figure 7-59 provides a high-level illustration of the K-MED Project data migration process. Accenture would work with the KHPA to refine our conversion approach and provide documentation in the Data Conversion Plan throughout the development of the conversion processes leading to execution. The Data Conversion Plan would include several deliverables that would be developed, refined, and ultimately approved by KHPA. Two of such deliverables will be the Conversion Data Dictionary, and the Detailed Conversion Cutover Plan. The conversion approach would include details for: Loading data from current systems using standard file-format definitions Collaborative analysis of the source systems between KHPA, agencies, and Accenture Conversion team to develop programming specifications 7-160

161 Planning and Design Execution and Build Implementation KHPA Conversion Analysis Design Develop and Test System Test and UAT Execute KHPA Data Sources include: MMIS, KAESCES-AE, PSI, PARTS KHPA Data Analysis KHPA Data Quality Assessment Gap Analysis Design Automatic Conversion Modules Design Manual Data Acquisition Process Design Data Validation Process Conversion Data Dictionary Develop Automatic Conversions Modules Develop Manual Data Acquisition Process Develop Conversion Validation Modules Unit and System Integration Tests Conversion Modules Dry Run Conversions System Test and UAT K-MED with Full Converted Data Set Mock Conversions to Simulate Go-live Big Bang Rollout Conversion 2 K-MED Figure Our Conversion process methodology guides the migration of data and mitigates risk inherent in Big-Bang conversions Processing the data through automated conversion programs that reflect the documented conversion programs Completing unit and integration testing of all coded data mappings Evaluating errors to determine the appropriate corrective action for cleansing data Providing reports to validate successful conversion of data Iterative dry-run testing and mock conversions to simulate the final conversions and achieve data-quality targets Figure 7-60 summarizes the potential conversion risks and corresponding mitigation strategies. Accenture and KHPA would work together to manage these risks according to the K- MED Risk Management Plan that will be developed after the contract award. Potential Risks Conversion deadlines are not met Difficulties in collecting data from various sources Disruption of Conversion due to inadequate data preparation or cleansing prior to data conversion Change of legacy database design during conversion development Data problems encountered during actual conversion Mitigation Strategy Confirm that the Conversion team is adequately resourced with the proper skills to meet defined deadlines Confirm that the Conversion team is well managed and keeps to its deadlines Identify key KHPA representatives to assist in gathering the requested information timely Identify data gaps and communicate to the appropriate stakeholders to allow sufficient time in preparing the data Identify and communicate data preparation and cleansing requirements to KHPA Conduct testing on conversion modules Conduct mock conversions in production-like environment Monitor and track data cleansing progress closely Review data with KHPA Work closely with Legacy System administrators Include the Conversion team in the database modification changes Define mutually acceptable criteria for data quality and focus on the subset of data that is most likely to be clean Perform and review dry run conversions to identify data problems at earlier stages to confirm data accuracy/integrity Review exception reports and expected outcomes for identified exceptions with KHPA throughout dry runs 7-161

162 Poor performance of conversion tools/modules Test conversion tools/modules thoroughly during development stage During mock conversions, undertake a series of trials to verify timing requirements Configure hardware, software, and database for production volume batch processing Work closely with KHPA stakeholders at all stages of the conversion process from analysis through testing Conversion does not meet end user expectations Incorrect data converted Identify and communicate data to be converted to KHPA for confirmation Information lost during actual conversion Conversion process delays external agency processing Incomplete Transactions (such as Pending Cases) not accounted for in the conversion process Legacy system platforms do not support the development and testing of conversion processes Test conversion tools/modules thoroughly during development stage During mock conversions, undertake a series of trials to verify that data is not lost Identify and perform checkpoints during mock conversions and the actual conversion Review all conversion reports, including control reports and exception reports confirming that the numbers extracted, transformed, and loaded are reconciled Clearly identify and document benchmark/load tests and results during full volume mock conversion runtime estimates Clearly document and review conversion schedule, cut-over procedures, business procedures, and back-out procedures with external agencies Update conversion plan to clearly specify which cases are targeted for conversion (New Applications, Pending Cases, Recently Closed, etc.) Schedule conversion to occur immediately after monthly cutoff in Legacy system Clearly document and communicate programming and testing requirements to KHPA Figure Risks associated to K-MED Project conversion and mitigation strategies Prior to starting the first phase (Analysis Phase), we need to establish plans for how the automated conversion process accesses the legacy systems data. We would work with KHPA and administrators for each legacy system to establish the data acquisition process for the K-MED Project conversion. Rather than access legacy data directly using conversion tools, we work with each legacy system operations team to define a file extract process for each system. We would work together to define standard file formats for each conversion file and develop a schedule for performing data extracts to support the conversion development and testing effort. This level of collaboration provides our team with the data access we need to complete the conversion on schedule and reduce the risk of disrupting legacy systems operations. Figure 7-61, below, identifies the Analyze Phase of the overall conversion process. KHPA Conversion Analysis The purpose of the analysis effort is to identify and analyze the sources of data to be converted. We also develop an inventory of existing data formats, data mapping, and data conversion requirements of the legacy systems to define the scope of the K-MED Project conversion effort. The analysis effort primarily focuses on analyzing the following: KHPA Data Sources Technical environments Physical characteristics of the data processed and maintained Commonality and relationships among the case management data elements 7-162

163 Planning and Design Execution and Build Implementation KHPA Conversion Analysis Design Develop and Test System Test and UAT Execute KHPA Data Sources include: MMIS, KAESCES-AE, PSI, PARTS KHPA Data Analysis KHPA Data Quality Assessment Gap Analysis Design Automatic Conversion Modules Design Manual Data Acquisition Process Design Data Validation Process Conversion Data Dictionary Develop Automatic Conversions Modules Develop Manual Data Acquisition Process Develop Conversion Validation Modules Unit and System Integration Tests Conversion Modules Dry Run Conversions System Test and UAT K-MED with Full Converted Data Set Mock Conversions to Simulate Go-live Big Bang Roll-out Conversion 2 K-MED Overall stability, accessibility and the process for maintaining the data Level of data quality Potential extraction point in time and or business processes for each system A combination of the following techniques is used to facilitate the collection of information about the KHPA data sources: Review available legacy system documentation Analyze system data models and data dictionary Analyze sample data files if available Schedule small, manageable meetings with cross-system operations personnel and other conversion stakeholders We would work with KHPA and existing system administrators to confirm our understanding of the data in each source system and validate our assumptions. We would take care to use KHPA and existing system administrators time effectively as we complete our analysis. This analysis will help our team develop a detailed understanding of the content and structure of each data field involved in the K-MED data-conversion process. The results of the data analysis will serve as input into the remaining tasks for developing the Conversion Plan and performing source-to-target data mapping. We drafted a list of existing systems for planning and estimating purposes. We would work with KHPA to refine this list and finalize the source systems in scope for the K-MED conversion. We will document the final list and the results of our analysis in the Conversion Data Dictionary. The draft list includes the following systems: KAECSES-AE MMIS PSI PARTS Data Quality Assessment Figure Analyze Phase of Conversion Methodology A preliminary data quality assessment plays an important role in the data conversion process. Through the preliminary data quality assessment process, data quality issues are discovered and resolutions are determined prior to Design and Development phases of the project. KHPA Business Representatives play an essential role in supporting the data quality assessment effort. The Business Representative s understandings of the business requirements help confirm how the source data supports current business processes

164 Performing an analysis of actual source data alleviates gaps that arise from potentially unreliable documentation and contributes to a more thorough analysis in the following areas: Understanding the record construction, domain sets, and logic of the system file data (e.g. does the source data form the basis of a minimum system file in K-MED?) Defining the requirements for complete conversion logic (record selection, data integration, and data field value transformation) Developing a more detailed understanding of the data situations that are encountered during conversion (e.g. how many duplicate clients exist? current level of client coverage?) Understanding of the relationships between the source systems data elements and highlighting compatibility issues with the target database (e.g. are the data elements translating to new values?) In the event data is found to require correction, Accenture will assist KHPA in developing procedures to correct the data through the source systems if possible. We would analyze the possibility of fixing the data through the current legacy system as part of the pre-conversion data cleansing process. This would require collaboration between Accenture, KHPA, and the legacy system administrators. Gap Analysis The initial Gap Analysis results drive the more complex activities in the later stages of conversion. In order to identify the initial gaps, we complete a logical source to target data mapping. This allows us to identify gaps between the data available in the legacy systems in comparison with the data requirements of the K-MED System. We refine the Gap Analysis in the Design phase and work with KHPA, legacy system teams, and agencies to design processes to address each gap. These processes can include assigning default values, developing automation to derive the data or developing manual processes when options for automation have been exhausted. Design Stage The defined target data model per KHPA objectives to continue medical assistance programs will be used as the required target elements for detailed design of data transformation and load. The required target elements will then be mapped to source elements with regard to format, business functionality, data integrity, and data relationships. The source mapping element will require considerable collaboration between data and functional experts, conversion developers, and target database interested parties (rules developers and data model designers). The documentation of the mapping designs will be stored in a Conversion Data Dictionary (CDD). In addition, the CDD contains an inventory of conversion items that facilitates the use of data conversion software tool for conversion. The CDD can also be used to document a Fit/Gap analysis started during the Analysis Phase. The KHPA Subject Matter Experts (SMEs) will have final approval of designed mappings. Changes to approved mappings will go through a rigorous change approval process where KHPA has the final approval/input. Figure 7-62 below, identifies the Design Phase of the overall conversion process. The defined requirements and the analysis performed to-date drives the conversion design specifications of the data cleansing, extract, transformation, and load modules. The conversion design specifications will: Confirm that the data elements (automated or manual) are accounted for Refine the initial Gap Analysis and document processes to address each data gap 7-164

165 Planning and Design Execution and Build Implementation KHPA Conversion Analysis Design Develop and Test System Test and UAT Execute KHPA Data Sources include: MMIS, KAESCES-AE, PSI, PARTS KHPA Data Analysis KHPA Data Quality Assessment Gap Analysis Design Automatic Conversion Modules Design Manual Data Acquisition Process Design Data Validation Process Conversion Data Dictionary Develop Automatic Conversions Modules Develop Manual Data Acquisition Process Develop Conversion Validation Modules Unit and System Integration Tests Conversion Modules Dry Run Conversions System Test and UAT KMED with Full Converted Data Set Mock Conversions to Simulate Go-live Big Bang Roll-out Conversion 2 K-MED Define Detailed Source to Target Data Maps and translation rules Confirm that the historical data elements as defined in the RFP are accounted for Confirm modules are reused where possible Confirm validation of data relationships from disparate data sources Baseline the control totals in order to measure the completeness of the conversion modules Confirm data cleansing processes Design Automatic Conversion Modules We plan to automate data conversion activities for the K-MED solution to efficiently convert and integrate data. Our designs will outline logic required to automatically move data from the disparate KHPA source systems to K-MED. We will define the flow of information and the tools to use. Tools and processes can support high levels of automation for data conversion and data integration projects. The documentation of Automated Conversion Modules will be placed and continuously updated within the Conversion Data Dictionary. The Conversion Data Dictionary will also be a tool used to validate all design modules are reviewed and accepted by KHPA. The automated activities will help reduce manual data conversion and the related work effort during the K-MED Implementation phases. Design Manual Data Acquisition Processes Figure Design Phase of Conversion Methodology We design data acquisition procedures to address the manual conversion of cases that we could not convert through automated means. In some situations, we cannot avoid manual data conversion. Our Conversion team works with KHPA and agencies to assess the implications of manual case conversion and other data involved in manual conversion processing. We document manual conversion processes thoroughly and work with KHPA staff to verify that our documentation is complete. We work with our Training Delivery and Implementation Support teams to verify that KHPA users have the information they need to be successful when we begin the Implementation phases. The small number of expected manual conversion procedures would allow further verification of coverage of current clients remains. We would work with KHPA to confirm which cases have associated manual conversion activities and when they should occur. The source data identified for manual data conversion can be determined by assessing how the data is maintained, the volume of data and the effort required to develop an automated approach. The availability and quality of the data are also important factors to consider. We develop reports to present this information in an organized manner. These reports can be organized in a manner that allows KHPA management, and Implementation Support to quickly delegate the manual data conversion process. Our objective is 7-165

166 to provide information that supports an effective manual data conversion and reduces the overall impact on the user, while maintaining current coverage to clients. Design Data Validation Process Conversion data validation processes verify that the conversion is successful. This activity includes design of the overall validation and control totals of the key criteria such as, cases that will be fully converted, cases that will need assisted manual conversion, cases that failed the criteria for full or assisted conversion, cases with bad/corrupt data by data types and data element so that the case can be corrected before conversion. The Conversion team designs a structured validation process that confirms the data is correctly converted. One of the most common problems with conversion is that data is not accounted for in the reconciliation process of conversion. Control totals and balancing mechanisms must be in place for key data fields in the conversion. The conversion validation process consists of automated and manual balancing and tracking. Each data mapping is tracked through the use of Oracle Warehouse Builder and the records that could not complete load into the target table will be tracked in database tables. The manual tracking can be done using specific data validation queries between the source database and the target database. The data validation design will include queries and/or reports detailing that coverage remain in place for current recipients. Using plans and scripts developed by Accenture, KHPA will be able to verify the accuracy of the converted / loaded data. Conversion Data Dictionary It is imperative that data identified for conversion has a target in the K-MED database. Equally as important is confirming the data element types, sizes, default values, relationships between data elements, and the integrity constraints of the source and target databases. We must also understand how the data supports the business functions that the systems support. We develop a Conversion Data Dictionary to illustrate detailed translation mapping between the KHPA source systems data structures and the K-MED data structures. The detailed data analysis results and the initial Gap Analysis serve as primary inputs. The Data Conversion Plan includes the source-to-target data mapping rules and logic by database target table. These rules and logic for validating source-to-target data maps and transformations are based on our analysis of the actual data values and the relationships within and between data sets. The completion of each element data mapping will require review and approval by KHPA prior to execution, and can be done within the Conversion Data Dictionary. The Conversion Data Dictionary would be used to lead interactive conversion strategy sessions that include KHPA, agencies, and other contractor staff and produce an input to the Data Conversion Plan. The Conversion Data Dictionary will have the ability to report status through Microsoft Project. Develop and Test The Development phase of the K-MED conversion lifecycle produces the actual conversion modules, configured tools and utilities that transform validate and load the data in to the K-MED data model. Figure 7-63 illustrates the Develop and Test phase in relation to the remaining phases in the conversion development lifecycle. Code generation capabilities in the Oracle Warehouse Builder tool facilitate a quick transition from the Design phase to the Development phase. Accenture will build and unit test the needed conversion programs to transform the KHPA 7-166

167 Planning and Design Execution and Build Implementation KHPA Conversion Analysis Design Develop and Test System Test and UAT Execute KHPA Data Sources include: MMIS, KAESCES-AE, PSI, PARTS KHPA Data Analysis KHPA Data Quality Assessment Gap Analysis Design Automatic Conversion Modules Design Manual Data Acquisition Process Design Data Validation Process Conversion Data Dictionary Develop Automatic Conversions Modules Develop Manual Data Acquisition Process Develop Conversion Validation Modules Unit and System Integration Tests Conversion Modules Dry Run Conversions System Test and UAT K-MED with Full Converted Data Set Mock Conversions to Simulate Go-live Big Bang Roll-out Conversion 2 K-MED Figure Develop and Test Phase of Conversion Methodology and subsystems (source) data into the K-MED (target) data. The Accenture Conversion team will develop conversion rules, and code for the detailed design mappings in the CDD with the use of a data conversion software tool, such as Oracle Warehouse Builder (OWB). Apart from development effort, testing of individual work units would also take place. Component testing is a test of an individual component of the solution such as an OWB load program using extracted source data. The objective of a unit test is to help confirm that the component correctly implements the design specifications defined in the CDD. Each work unit will be independently tested during component test by the developer. Develop Automated Data Conversion Modules The ETL capabilities provided with Oracle Warehouse Builder is our primary development tool. We supplement these capabilities with custom developed Oracle tools/utilities to support the conversion process, specifically PL/SQL. Prior to the installation and configuration of any conversion software, we verify that we adhere to the Software Installation Plan and address State-approved software importation requirements. In the event that correction of source system existing data is required at the point where altering the source system data is no longer plausible, the Accenture Conversion team will develop custom processes with the aforementioned tools and utilities. These procedures would correct bad data identified for an individual case or an entire group of cases as part of the transformation processes prior to data loading. Develop KHPA Legacy System Extract Modules We collaborate with KHPA, and other legacy agencies to define mutually acceptable formats for extract files from each legacy system targeted for conversion to K-MED. We then work with KHPA to coordinate the development and testing schedule for conversion. This provides the legacy system teams with advanced notice on when extract files are expected to reduce the impact on legacy system operations. This will also provide clear roles and responsibilities, and timing requirements to generate the load ready files. This information would be an input to the overall Data Conversion Plan. Once we have access to the extract files, we would begin pre-processing activities to validate the data and start applying K-MED transformation rules. Pre-processing activities start with loading the source extract files into an Oracle staging environment. The staging environment serves two primary purposes: 1.) it preserves the source data to facilitate post-conversion reconciliation activities; 2.) it exposes the data to the Oracle Warehouse builder tools, Oracle 7-167

168 utilities and any required custom programs to enable data transformation activities. Develop Manual Data Acquisition Processes Our approach for manual data acquisition of data is to enter the affected data into K-MED post conversion. This approach reduces the risk of introducing data quality issues because the system s data validation rules are applied to the data as it is entered. Two important components must be in place for this process to be successful. First, workers need specific instructions on how to interact with the K-MED System to complete manual data conversion. We work with the Training and Implementation Support teams to confirm that our documentation is accurate and effectively supports the manual data acquisition process. The second important component is manual conversion reports. KHPA needs reports to help organize the overall work effort and prioritize manual data conversion activities. To provide for a successful conversion from KHPA to the K-MED System, the following must occur: Testing the conversion process, including dry run testing and mock conversions Testing the K-MED System with and without converted data The conversion modules are thoroughly tested before being used for system testing. We conduct dry run tests prior to the first mock conversion. These test executions validate the conversion modules and the expected results of the data conversion. The conversion modules undergo the following testing stages prior to the mock conversions defined in the next section: Unit Test each individual component of the conversion process, including extract, transformation and load modules are unit tested. Data validation and data cleansing modules are also subject to unit testing. This test helps confirm that each conversion module works according to the design specifications System Integration Test validates dependencies between the conversion modules and verifies that that the conversion modules are integrated. It focuses on passing data from KHPA legacy systems to the transformation and load modules. At the end of the System Integration test, the conversion process should be functioning according to the technical requirements in the design specifications System Test and UAT The Accenture Conversion Team will complete all Conversion Build activities including Unit, Assembly, and System Test so that Mock Conversions (or migration rehearsals) can begin approximately 3 months prior to go-live. All testing of the conversion programs shall be done using an extract of data from the source system databases loaded onto the Conversion Staging Database. System Test verifies that we can complete end-to-end business transactions. We will begin processing full-scale Dry Run testing during the System Test phase and provide converted data for system testing with the K-MED application. The System Test phase is illustrated in relation to the other development phases in Figure The Conversion Team will execute a System Test of the Conversion processes, procedures, and activities in an effort to make certain that the expected outcomes of the conversion processes and tools are functioning properly. The key to success in correcting conversion data issues is executing an iterative process. Many issues do not become apparent until we execute the dry run 7-168

169 Planning and Design Execution and Build Implementation KHPA Conversion Analysis Design Develop and Test System Test and UAT Execute KHPA Data Sources include: MMIS, KAESCES-AE, PSI, PARTS KHPA Data Analysis KHPA Data Quality Assessment Gap Analysis Design Automatic Conversion Modules Design Manual Data Acquisition Process Design Data Validation Process Conversion Data Dictionary Develop Automatic Conversions Modules Develop Manual Data Acquisition Process Develop Conversion Validation Modules Unit and System Integration Tests Conversion Modules Dry Run Conversions System Test and UAT K-MED with Full Converted Data Set Mock Conversions to Simulate Go-live Big Bang Roll-out Conversion 2 K-MED Figure The System Test and UAT Phase of Conversion Methodology will complete Iterative Mock Conversions to simulate Go-Live procedures, finalize a detailed conversion plan, and provide converted data for user acceptance test tests to examine the data. The system test conversions are used to monitor performance problems, simulate partial and full production volumes, and sequence automated and manual conversion activities. These activities also test data verification rules, data dependencies, validate that converted data is clean, verify data integrity, and highlight potential business process issues associated with cut-over. Accenture and KHPA can identify these issues with time to implement alternative work procedures for current systems. Mock Conversions After K-MED System testing activities are complete, the Conversion team begins to focus on UAT and three planned Mock Conversions. Mock conversions simulate the final conversion with production data volumes in a production-like test environment. These efforts verify readiness for the final conversions. We focus on performance testing the automated conversion process and work with the Implementation team to verify that all conversion related action items are accounted for in the implementation plan and readiness checklists. The mock conversions demonstrate that the final cutover can be completed with acceptable errors and the subsequent mitigating processes. Mock Conversions also serve as a baseline time window in which the execution of all processes will take. The specific order, timelines, and responsibilities of cutover activities will be documented in the Detailed Conversion Cutover Plan and will serve as a guide to all parties involved. As part of dry run testing and the mock conversion process, data cleansing is conducted to verify the integrity of the data that is converted to the K-MED database. Data cleansing activities consist of the following: Data Validation The different points at which data validation occur can be seen in Figure Programmatically verifying that the system file data passes the required validation rules and does not contain corrupt or duplicate data. This process takes place within the conversion process through exception handling logic and after conversion with data validation scripts. Data Reviews Reviews conducted by KHPA and the Conversion team to confirm that the data is complete and accurate. Involvement from KHPA is critical during conversion testing. KHPA has an in-depth understanding of the current business applications and their 7-169

170 Legacy Sources Accenture KHPA KAECSES-AE MMIS PSI PARTS SQL Loader Control File Load Structure Schema and load data using Oracle SQL Loader 4 1 Source Schema Extract and Transform Staging Database 6 Extract Transform Load 2 Target Schema Source Database Table Structure, Load Ready Files, Data 7 8 Tablespace Load 3 Data Validation Application Production Database Data Validation Conversion Logic Code Application Validation 5 Data 9 Mapping and Data Validaton Transformation Logic Data Validation K-MED Figure Our Conversion Execution Process will provide clear responsibilities and major milestone validation procedures communicating conversion status insight makes significant contributions to resolving issues with the converted data. The converted data is available through the K-MED application screens, queries and reports generated by program modules. In order to simulate an actual conversion cutover during Mock Conversion testing, actual data would be used and all the conversion processes, procedures, and activities will be executed. Following the successful completion each Mock Conversion, the results would then be used to validate the data as well as the test integration of converted data with the functionality of K- MED. The objective of each mock conversion is to validate: The conversion procedures and steps developed, including any dependencies The conversion programs (data extraction, formatting and uploading) Software configurations Source data Database size estimates Execute Go-Live Conversion Execution of the Detailed Conversion Cutover Plan involves deploying the system Statewide. The specific timing, sequence and list of all cutover activities will be developed and refined in the Detailed Conversion Cutover Plan during the Mock Conversions. When the mandatory requirements have been satisfied and the appropriate KHPA legacy data has been frozen, the required data is extracted to a staging database. The Conversion team works with KHPA to communicate the cut-over timeframe and the period the legacy system data is frozen based on 7-170

171 Planning and Design Execution and Build Implementation KHPA Conversion Analysis Design Develop and Test System Test and UAT Execute KHPA Data Sources include: MMIS, KAESCES-AE, PSI, PARTS KHPA Data Analysis KHPA Data Quality Assessment Gap Analysis Design Automatic Conversion Modules Design Manual Data Acquisition Process Design Data Validation Process Conversion Data Dictionary Develop Automatic Conversions Modules Develop Manual Data Acquisition Process Develop Conversion Validation Modules Unit and System Integration Tests Conversion Modules Dry Run Conversions System Test and UAT K-MED with Full Converted Data Set Mock Conversions to Simulate Go-live Big Bang Roll-out Conversion 2 K-MED Figure Execute Phase of Conversion Methodology business processing (e.g., cut over period may occur immediately after month-end processes have been completed). Once complete, the transformation and load modules are executed during the final conversion to the K-MED System. Figure 7-66 shows an initial outline of the activities that are to be performed during the Execute Phase of Conversion, according to the Detailed Conversion Cutover Plan: Extract and transform data from specified legacy systems into an intermediate facility, in which KHPA and supporting Agencies can supply the Accenture Conversion team with a periodic replication of the data included in KAECSES-AE, MMIS,PSI, PARTS. Transform legacy data into a common format, with a defined table structure, Data Definition Language (DDL), and flat files that can be loaded into Staging Database using Oracle SQL Loader or similar. Perform Baseline Data Validation #1 to which future data validation points will be compared. This shall include analysis of important high level data such as count and type of program, total persons, and total caseload. Import data from load ready files, supplied to Accenture by KHPA and Legacy System administrators, onto the Staging Database using Oracle SQL Loader according to import definitions specified in the SQL Loader Control Files, completing the Source Schema. Data Validation #2 of the Source Schema load will be compared to the Baseline Data Validation from the source systems. Extract, Transform, and Load the source schema into the target schema based upon the Data Mapping design used to build the conversion logic code with the use of software tool such as Oracle Data Integrator or Oracle Warehouse Builder. Once the data is loaded into the target schema, KHPA, Legacy System Administrators and the Accenture Conversion Team can Perform Data Validation #3 and Application Testing to help confirm that data has been loaded and processed correctly. The Accenture Conversion Team will perform a database table space load from the Staging Database Target Schema to the Application Production Database. Perform the Final Data Validation #4 of table counts from Staging to Production

172 Workflow Configuration Our approach to workflow configuration provides KHPA with a flexible solution capable of supporting the varied office structures within your service delivery model. Our tool requires minimal IT involvement so that Business Analysts can design, document and run simulations of complete business processes without involving programmers Workflow Configuration Accenture s experienced team brings Kansas one of the world s largest and most successful business process analysis and continuous improvement firms. More than 2,000 Business Process Management (BPM)/workflow professionals globally Over 20,000 capability and process reference models for over 71 industries Considerable BPM experience: United Nations Development Program City of Boston National Oceanic and Atmospheric Administration The Proposer shall describe its approach to analyzing, establishing, documenting, and assisting in the deployment of workflow, electronic notification, and electronic approval processes that are built into the proposed system, as well as those developed during the project. Poorly defined or poorly functioning business processes cause many of the tactical and strategic challenges that government agencies, like KHPA, face in day-to-day operations. Some of these challenges are: Slow and inconsistent responses that cause low Participant satisfaction Complex systems and procedures that frustrate users Manual exception handling causes long cycle times Unclear processes make it difficult to meet compliance requirements Rigid infrastructure cannot support new initiatives. In order to address these challenges, your K-MED Solution includes a robust workflow solution. Our workflow solution allows business analysts to design, document and run simulations of a complete process without IT or Java programming. Our Plan is to assist KHPA with the lifecycle of implementing the workflow solution: Plan, Analyze, Design, Build, Test and Deploy. We bring our experiences gained from projects such as C-IV, where we worked with users in offices of all different sizes. We also assist in designing workflow templates by assembling a set of activities which can be shared, copied, imported and exported. These tools enable KHPA to continue expanding the workflow solution into the future independent of the Accenture Team. Because we integrate your workflows with APSP Public Assistance Portal, we avoid hard coding and greatly reduce the effort required to scope, specify, develop and test frequent changes. Figure 7-67 provides additional details of the features and benefits of our workflow configuration. After researching your workflow requirements and comparing them to available tools and our recent client experience, Oracle s Business Process Management (BPM) Suite is the right choice for KHPA. BPM Suite is the industry's most unified and complete business process management suite. Oracle BPM is easy to use, supports multiple service delivery models, and has rules-based automation. With these features, Oracle s BPM can support your service delivery model involving a number of different agencies and contractors. Oracle s BPM is an integrated workflow solution for creating, executing and optimizing business processes. The tool enables collaboration between business and IT through specialized modeling and design tools. Oracle BPM is a highly flexible workflow system that can be 7-172

173 managed and maintained by non technical staff. Whether the process is a legislative mandate or KHPA systems integration, Oracle BPM Suite offers both the flexibility that your business users need and the power required for your complex processes. Features Benefits Flexible Accommodates a wide variety of current and future service delivery models Supports frequently changing business models Enhanced compliance with ongoing legislative and policy changes Improved business agility Rules Based K-MED determines the correct orchestration of steps involved Role-based and skill-based workflow to help enforce consistency of process within K-MED Supports the modeling and analysis of tasks, roles, decisions, approvals, reviews, escalations, collaborations, flows, rules, policies, and forms Business Activity Monitoring (BAM) Collect and retain activity data as well as data about how processes are working Real-time business intelligence and alerts based on business metrics Provide the ability to take corrective actions when certain conditions are met/not met Optimize business processes over time with reduced programming effort Graphical User Interfaces Common language to bridge the communication gap that frequently occurs between business process design and implementation Provides a graphical representation of business processes based on a flowcharting technique Enables business analysts to focus solely on business-process optimization without concerning themselves with technical implementation details Figure By integrating K-MED with workflow, we design the business processes required to efficiently support your unique service delivery model. The service delivery model used by Kansas involves a number of different agencies and contractors. Each location may organize their staff and work processes differently so the workflow must be flexible to accommodate these various needs. Some offices have only one staff member to work the whole case from application intake to authorization, while in another location clerical staff registers the application only. Once registered, the application is assigned to another worker or to work queues for the next task(s). Virtually every location has different staffing structures for different functions, and it is the intent of KHPA to accommodate the needs of each, using flexible workflow models without necessarily changing the business process. Additionally, the implementation of the Affordable Care Act will introduce new entities, agencies, and consumers to our business which will add complexity to the business models and the system workflows. The proposed solution must: Be flexible to accommodate a wide variety of current and future business models. Experience tells us it is better to create several sub-processes that can be linked instead of creating one large, monolithic process. BPM Suite allows the end user to manage sub-processes, 7-173

174 and call other sub-processes from within a sub-process. This flexibility allows users to orchestrate fully-functional workflows. The BPM Suite also brings the capability to merge workflows to allow one worker to process multiple programs, or individual workflows can be kept independent allowing different groups to follow a program-specific workflow. This will help KHPA address the challenges introduced with offices that organize their staff and work processes differently by providing flexibility in task assignment and authorization, while maintaining the necessary consistency in tasks completed. The workflow tool is built around a robust functionality of defining, routing, alerting and monitoring the status of tasks within a business process. As shown in Figure 7-68, the process begins with developing the Use Cases during the design phase of the K-MED project. Business analysts will then use the Use Cases to design the business process. Each workflow is built by defining the tasks/steps that make up each process. Once these tasks are defined, the tool provides the ability to route tasks to multiple destinations, and continually track status and completion of tasks. For example, based on defined criteria, a task could be routed back to a Business Owners 1 Use Cases 1.0 Presumptive Eligibility 2.0 Registration 3.0 Determine Eligibility Requirements 1.1 Process Diagram 2.1 Launch screen 3.1 Monitoring screen Process Management and Real-Time BAM 5 Historical & Trend Analysis Tools Business Analysts 1. Business Owners define use cases, requirements and KPIs 2. Business Analysts design the process 3. Processes are deployed into the BPEL / Process server 4. Process/workflow changes are integrated into the application 5. Process KPIs are displayed to Business Owners for process monitoring and optimization Process Modeling, Simulation and Documentation Process Server and Monitoring Repository 3 2 Workers 4 K-MED Figure Our workflow solution will provide controlled process management to authorized KHPA staff and permit the optimization of KHPA business processes 7-174

175 previous person for correction or to the next step in the process (if data is determined to be complete and no corrections are required). This allows users to track the status of an individual task within a workflow, and also track the status of the entire workflow. A workflow is not flagged as complete until all individual tasks have been sufficiently addressed. We work collaboratively with KHPA to define how the status of each individual task will drive a workflow to completion. An additional feature involved in defining tasks is the ability to use a timer. The timer can be used to create a delay before running an activity, configuring a deadline for an activity, configuring a deadline for a process, triggering additional activities after an elapsed time, starting a process, and trigger a process periodically. To further support these functions, event triggers can define and prioritize an alert to the appropriate staff or online/batch processes. This alert will inform the worker or system process of the required action(s). These alerts are stored in an inbox where users can review and take action based on the alert status (such as pending or in-process). To assist in the management of these alerts, and reduce the opportunity for delays, we are able to initiate Reminder and Deadline notifications to assist workers in completing their required action(s). We are careful not to overengineer the use of alerts. If workers receive too many alerts while performing their duties, workers will begin to ignore them. We plan to work with KHPA to find a successful balance to attain maximum efficiency through the alert functionality. Include templates and other aids to support design and modification of workflows by nontechnical staff. As our clients use cutting edge technology to address their workflow needs, we hear the following question: Can Business Users and process experts with no programming experience design and run workflows? The answer is YES. When business users log in, technical details are hidden. This enables business users to focus only designing the flows. Your workflow solution features Visio-style interfaces. Most business users that are familiar with creating basic process boxes or swim-lane diagrams find the BPM design tools very straightforward. During the design phase, we work with your process specialists on using the BPM design tools. Oracle BPM supports template creation which can be used to create re-usable workflow modules or templates. Process developers can create a catalog of preconfigured components such as services, tasks, and rules in Oracle BPM Studio. This catalog can be included in project templates that process analysts can use to create new projects. There is even a web-based environment that can be used in conjunction. Provide workflow version control. Because BPM Studio and Process Composer ties into the existing version control systems such as CVS, Subversion, and other version control systems. Be rules based. The Accenture Team understands that a complex workflow can be composed of multiple steps that can include one or all of the following: evaluating data against variables entered in a previous step 7-175

176 The initiation of a step based upon variable rules The initiation of a step based upon the results of a multi-table query of the database Multi-step approval, rejection, and re-approval processes. In order to manage these complex workflows, the K-MED solution provides rules based automation of business processes. The rules engine provides the flexibility to route work within a process between both system and human based activities. There are multiple types of rules/criteria that can be incorporated into the K-MED workflow solution, including all four criteria listed above. The rules-based automation supplements the task functionality discussed above by providing the ability to route transactions based on complex criteria. This helps to expedite the handling of an application for a pregnant woman, or task specialized workers if special circumstances are identified. The rules based automation can also be applied to the overall approval/authorization processes. For example, a document that requires timely supervisor approval can automatically be routed to a different approver if the first approver doesn't handle it within a required timeframe. This accommodates busy supervisor schedules, or unexpected time out of office. This feature further enables KHPA to accommodate differing processes across offices, as well as continuing to focus on the critical nature of consumers needs. Provide for a workflow administrator. Our proposed workflow solution provides for two types of administrators: Business administrators: Users responsible for administering Process Workspace for example, adding fields, changing the look and feel, or ensuring that the web application is both running and accessible. Process administrators: Users responsible for administering processes for example, creating shared views; assigning or removing roles, permissions, and groups; and mapping roles. Monitor workflow statuses and flows. Our workflow choice includes monitoring tools you can use to review the overall status of workflow, including submitted, executing, completed. This monitoring allows business/workflow owner(s) to validate that the data is as clean as possible and processed as efficiently as possible. If defined conditions are not met, the business/workflow owner(s) receive messages of errors that occur during the processing of the workflow. The simulation tool set also enables business owners to visualize process flow during simulation to help identify bottlenecks and performance issues. With the tools that we integrate with the APSP Public Assistance Portal, KHPA could continually optimize its business processes over time with reduced programming effort and IT involvement. Collect and retain activity data as well as data about how processes are working and provide for both standardized and ad hoc reporting capabilities using this data. Business activity monitoring enables business owners full reporting capabilities to generate ad hoc custom dashboards based on real-time data. Users can then interact, filter, set alerts, and create rules on the data being reported dynamically. Your administrators will have the current and historical data about how processes are working at their fingertips

177 Handle multiple workflow actions done concurrently. Yes, Oracle s BPM Suite can handle multiple workflow actions concurrently. Oracle s BPM Suite can accommodate AND, OR, complex branching and parallel patterns. It can perform synchronous/asynchronous sub-process invocation and inter-process communication. Provide a means for designing (modeling) workflow templates in graphical and test modes. Workflow processes can be viewed with standard flow diagrams during design time and during runtime. Figure 7-69 is a view of the BPM Studio with a process displayed. There is also a web-based modeling tool called BPM Processor Composer, where users can view processes within a web browser. Provide electronic notifications / alerts. The Oracle BPM platform provides four types of electronic notifications and alerts: Web-based portal that enables an inbox where work items are accessed, notifications generated from the process, SMS notifications generated from the process, and K-MED Figure Our workflow tool facilitates the automation of business processes and human interactions, resulting in improved customer service for KHPA 7-177

178 End-user dashboards providing visual insight into the process. In addition, Oracle BPM provides a rich integration platform which integrates into a number of third party applications to enable seamless notification. Oracle BPM supports real-time notification via SMS, , VOIP, and Business Dashboard alerts. Accommodate complex workflow styles (e.g., straight-line, loop, branch, and/or chained workflows). Yes, Oracle BPM can accommodate complex workflow styles. Oracle BPM supports the full notation of BPMN 2.0. Gateways are used to model complex control flow branching in BPMN. Gateways split and join sequence flows. For example, the Exclusive gateway enables you to split your process into two or more paths. However, the process only continues down one of these paths. Conversely, a Parallel gateway enables you to split your process into two or more paths when you want your process flow to follow all paths simultaneously. The proposer shall recommend an approach to meet the State s needs for a highly flexible workflow system that can be managed and maintained to a high degree by non technical staff. Detailed workflow requirements are referenced in RFP Appendix 1 in the General Functional Requirements Workbook (Workflow Worksheet). As described above, Oracle BPM Suite and Accenture bring the tools and experience to meet the State s needs for a highly flexible workflow system that can be managed and maintained to a high degree by non technical staff. We will work with you to efficiently utilize Oracle s BPM Suite to meet the detailed workflow requirements listed in the RFP Appendix 1. The Proposer shall assume that the workflow processes are defined by the following levels of complexity: Complexity Simple Average Complex Complexity s A two-step process that includes evaluating data against up to two variables from step one, then the initiation of step two based upon the results of the query. A process with up to five steps that includes evaluating of data against up to five variables from step one, the initiation of step two based upon the results of the query with a simple approval process, including the development of a simple data entry screen and an approval screen. A process with greater than five steps that includes evaluating data against variables entered in step one, the initiation of step two based upon variable rules, the initiation of step three based upon the results of a multi-table query with a multi-step approval, rejection, and re-approval process, including the development of related data entry screen and approval screens

179 As a workflow contingency, the Proposer shall plan on designing, developing, and testing workflows of the following complexities: Complexity Level Number of Workflow Processes Simple 5 Average 10 Complex Workflow Configuration The Proposer shall include the estimated cost of providing workflow contingency in the separate Cost Proposal. Workflow contingency funds shall be used or not used at the discretion of the State, and any workflow contingency funds not used for that purpose may be applied to other project areas as the State deems in its best interest. The cost of the workflow contingency shall be shown as a payment Deliverable titled Contingency Workflow in Cost Schedule 3 Deliverables Payment (see RFP Section See Cost Schedule Workflow Configuration In this section, the Proposer will also present a recommended list of workflows (with Complexity Level) that the State may require. This list of workflows need not be priced separately in the Cost Proposal. It is provided for informational purposes only. We reviewed K-MED solution requirements, core business functions, and project objectives and determined a list of recommended workflows. (Figure 7-70). Six out of the nine workflows are included in APSP out of the box. The common workflow tasks are defined and established in the application, only requiring Kansas s specific process points. The six workflows included in APSP out of the box are: Registration, Determine Eligibility, Case Maintenance, Quality Assurance, Hearings and Appeals, and Fraud. Standardizing these workflows gives KHPA confidence that program polices are implemented as intended and reduces program administration costs. Workflow Steps Complexity Presumptive Eligibility File Clearance Intake PE Determination Documents Generated Registration Application Received File Clearance Worker Assignment Intake Verifications Received Application Assigned to Eligibility Specialist Determine Eligibility Verify/Complete Intake Eligibility Determination Supervisor Authorization Average Average Complex 7-179

180 Workflow Steps Complexity Documents Generated Active Program Re-assigned (if needed) Case Maintenance Receive Update/Re-application Average Process Update/Re-application Eligibility Determination (if needed) Documents Generated (if needed) Quality Assurance Random Sample Case Identified Average Worker Assignment Process Review Decision/Outcome Cost Avoidance and Recovery Hearings and Appeals Potential Case Identified Worker Assignment Research Cost Avoidance/Recovery Action Documents Generated (if needed) Request Filed Worker Assignment Review Decision/Outcome Fraud Identification Worker Assignment Process Decision/Outcome Presumptive Medical Disability Determination (PMDD) Application Worker Assignment Documents/Verification Disability Determination Final Authorization Documents Generated Simple Simple Simple Average Figure 7-70 The recommended workflows focus on the core business processes supported by K- MED, to enforce consistency of process Our design further supports flexibility and modularity by enabling specific workflows for each program in K-MED. Through the collaborative design process, we configure this capability for K-MED specific requirements. For example, we together determine if Poverty Level programs (pregnant women, children, newborns, etc) require unique workflows, or can share the same workflow. One area where our clients have appreciated our experience is Status and Exception Management. As we work together on workflow, we design a comprehensive error handling process to manage errors and exceptions that occur when processes are executed. The error handling and resolution process will be specific to KHPA. We bring suggestions for designing an effective error handling process for end-to-end business process management: Develop a standard error process model which manages all errors that occur within the automated business process workflows Develop a standard error event to be used across all applications and automated workflows Build in default logic or timers within workflow states or process flows that will trigger error notifications if the proper events or information is not received to transition out of the current state or flow Pass descriptive error messages in any error events or notifications 7-180

181 Write all errors to a log file in order to organize, track, and provide a history of errors that occur within an end to end business process Allow for the re-submittal of business events once errors are corrected. We look forward to the opportunity to share additional insights gained over years of collaboration in addressing the workflow needs of our clients. Our collaborative effort will result in a solution where implementation time frames are driven by rules and policy changes, therefore reducing the ongoing problems government agencies face of technology limitations delaying these time frames Automated Forms Configuration Our K-MED Client Correspondence Solution automates the production of required forms, notices and letters. It provides flexibility to address the unique communication needs of applicants and participants, and it supports compliance with State and Federal requirements Automated Forms Configuration The Proposer shall describe its approach to analyzing, establishing, documenting, and assisting in the deployment of automated electronic forms. KHPA currently uses many forms to support both the management of its programs as well as its overall operations. The Contractor shall recommend new electronic forms and incorporate existing forms into the overall K-MED solution design as agreed to during the analysis activity. A list of current KHPA business forms is referenced in RFP Appendix Solution Summary Accenture s K-MED solution provides flexible and integrated client correspondence functionality which supports timely and accurate communication to applicants, participants, and others Integrated correspondence process that allows for easy and responsive correspondence Rule based Notices that are created dynamically by actions on a case Our K-MED solution provides an integrated, flexible, and multi-featured client correspondence and forms creation process. The K-MED solution process for the production of letters, notices, and forms is business driven, highly automated, and integrated with other system applications and services. This design enables our K-MED solution to generate correspondence to applicants and participants with little user intervention in English and other required languages. Communications reflect KHPA s current policies to maintain accuracy. Our approach enables KHPA and project staff to keep the K-MED solution current to policy with minimal effort. Our K-MED solution is integrated with industry leading forms generation tools such as Adobe LiveCycle and the APSP configurable workflows to help K-MED users provide client correspondence that meet the needs of applicants and participants. Figure 7-71 provides an overview of our K-MED Client Correspondence solution. A user or system-generated action triggers the request for production of client correspondence. The K-MED solution accesses the standard correspondence templates and retrieves the necessary data and case information to fulfill the request for a notice, form, letter, stuffer (flyer) or other communication. The K-MED System generates the correspondence and the configurable security and editing rules control which correspondence or forms Statespecified users can customize for specific case situations. Correspondence documents can be printed locally by the user or bundled with other sets of correspondence to be printed and mailed by the central printing office

182 Client Correspondence Triggers Data & Templates Generation Notices Forms Letters Stuffer Historical Record Customization Editing Rules Bundling Delivery Process Local Printing e-delivery Central Printing Recipients Applicants Participants Caregiver Sponsor Authorized Representative K-MED Figure Our K-MED Solution provides correspondence functionality that is flexible, intuitive, user-friendly, and enables workers to customize communication to meet individual applicant and participant needs. Accenture s proposed K-MED solution leverages the open services based architecture of the APSP platform to provide opportunities for KHPA to expand notification methods to applicants and participants. This includes the ability for members to view notices via a window on the APSP Public Assistance Portal. Our solution also offers the ability to send correspondence to clients via , based on the preferred method of communication selected by the client. Our APSP services based platform allows us to integrate core components of our solution with commercial off the shelf (COTS) products to further enhance the user experience and to provide business process efficiencies for KHPA. We leverage the robust electronic forms capabilities of Adobe LiveCycle to further enhance the document generation capabilities and e- forms capabilities of K-MED. With digital signatures and electronic routing, approval cycle times can be significantly reduced. Figure 7-72 provides an overview of the Adobe LiveCycle workflow. By integrating Adobe LiveCycle into our K-MED documentation generation solution, we are able to extend the core eligibility business processes and workflow automation capabilities for KHPA more securely and cost-effectively Proposed Approach Our K-MED solution offers multiple channel communication methods with KHPA clients, including the capability to allow members to view notice information using the easy-to-use APSP Self-Service Portal. When a member accesses an electronic document previously sent, it is a non-editable PDF document that looks exactly like what the client received. Members can use this portal to print notices, or, if applicable, fill them out and return them to the case workers for further review. We also maintain a history of all recipients for each notice generated with viewing capabilities for the recipients of each notice. Our solution provides robust search capabilities on all previously sent notices, including the ability to view notices sent based on date, action, case, and recipients. We can configure the solution to allow for users to designate which notices are kept indefinitely as a permanent part of the case record and not archived (e.g. - notices related to claims), based on KHPA defined policy. Our application, document management, and correspondence tools generate written materials, including notices, forms, flyers, letters, and other materials in English and other required languages. In our transfer solution the text displayed on notices is stored as short 7-182

183 Adobe LiveCycle Forms ES 1. Design form 2. Deploy form 3. Enter data Form is designed and managed in LifeCycle. LifeCycle ES User adds the necessary business logic to ensure accurate data collection. Completed form goes back to LifeCycle. Personalized form is opened by the end user to complete. 4. Process form Completed form are sent to the LifeCycle archive. XML data is extracted and processed in the back-end system. K-MED Figure Integrating Adobe LiveCycle with our K-MED solution allows for an easy-to-use and robust form generation process that significantly reduces processing time. paragraphs or sentences called snippets in reference tables with columns for English and Spanish. The logic to assemble the snippets into meaningful notices is written once, and the text snippets require translation only once during the design phase. Unlike other systems and products, our solution is very flexible and allows for easy additions or changes of notice designs. Our K-MED Solution supports Federal, State, and local laws, rules, regulations, ordinances, guidelines, directives, policies, and procedures that govern the provision of notices, forms and correspondence to applicants and members. Moreover, the K-MED solution is highly flexible, providing effective and timely adjustments in relation to new and changing laws and regulations. Since notices are assembled using messages from a reference table; the maintenance of notices is relatively easy. Messages within the snippet library can be added or updated to keep the notices current with State regulations. Our K-MED solution allows users to print notices locally or add them to a print bundle to be printed by the print facility using a scheduled batch process. Correspondence sent using the batch process requires minimal user intervention and can be scheduled as needed, including weekends, to provide timely information to all recipients. Correspondence mailed out to all applicable recipients with minimal user intervention. A program time limit notice is an example of a notice that we generate in batch. Our K-MED solution automatically sends these notices to the State s central print facility. Our solution allows users to configure the timing of notice distribution by establishing mailing time frames by customer, case, responsible person, nursing facility, and service providers. During design phase we work with the State to determine the print facility specifications needed to print and mail correspondence efficiently and accurately. General requirements of the 7-183

184 central print facility include: Must be able to receive files over SFTP Print bundles are sent to the print facility using SFTP Must be able to print in a duplex format Printing correspondence in a duplex format saves money and resources Must be able to print barcodes Barcodes need to be printed on each page of a form distinguish forms within a bundle Our K-MED solution provides users with the ability to override the submission of notices that are scheduled for automatic generation by the system. Additionally, users may manually request the creation of a notice or request the resubmission of a previously sent notice. Our notice templates are configured to allow forms designers to create notices in multiple font sizes. Users have the ability to control the content of each notice depending on the intended recipient of the notice. Our solution can be easily adapted to provide other flexible template and print generation features including: Generation of single and multi-page notices on KHPA or other standard letterhead. Controlling the length of a notice with no system restrictions depending on KHPA policy. This feature includes the ability to print a notice front-and-back (duplex) and control the content placement accordingly. Incorporation of approved writing standards. Inclusion of legal disclaimers or standard informational text that corresponds to the case situation, such as right to appeal and reporting requirements. Inclusion of graphics in a notice (e.g. charts, logos, graphs, etc.) Capture of a graphic signature of the designated worker or unit as one of the standard components of the notice template. The K-MED solution allows workers to specify multiple recipients for outgoing notices on all cases. The additional specified recipients receive a notice whenever a worker sends out a notification to the primary recipient of the notice. In addition, our solution offers the capability to distribute notices to multiple parties using different communication channels. For example, the primary recipient may opt to receive the correspondence via , whereas the secondary recipient (e.g. authorized representative) may opt to receive the correspondence via mail. Users can also generate a third party notice with the option to send a copy to the customer in their preferred method of correspondence (e.g. a letter sent to a client s employer with a copy sent to the client). Our solution provides a feature that allows users to retract notices or groups of notices prior to the file transfer to the central print facility. Our K-MED solution includes a Template Repository that includes electronic templates for all notices, forms, letters, and flyers. These electronic templates can be easily maintained by a non-technical specified user. Our document management toolset also provides version control for correspondence templates. The K-MED solution provides a user friendly, business driven model for designing, creating, and distributing communications to KHPA clients. The K-MED rules engine automatically generates and customizes Notices of Action (NOAs) for the specific circumstances of the customer(s) and benefit(s). Thus, by simply processing a case, a worker can easily send a NOA to the respective client. Figure 7-73 illustrates how we use snippets (logical groupings of approved text) to build our automated NOAs. Our K-MED solution uses application, document management, and production tools to 7-184

185 Save EDBC Action Determination Creates the Action snippets Discontinuances Denials Changes Approvals No Change Supplements Reason Determination Attaches a reason snippet to each of the appropriate actions Add Budgets Attaches a Budget to the Action for Cash and Food Stamps Programs when needed Add Messages Adds information snippets to the Notice. These snippets can be related to the action or generic to the program Put Snippets in Order and attach Regulation References K-MED Figure The dynamic NOAs generated from our K-MED Solution arrange snippets based on ED/BC results, dramatically reducing manual effort for the worker and creating quality correspondence for the customer combine multiple actions into a NOA. This includes providing all appropriate reasons for each proposed action, and a consolidated calculation/computation showing the net result of all changes made by a program or combination of programs, as the State specifies. Our K-MED rules engine enables us to generate a single correspondence that reflects the net results on individual or case changes and actions. The snippets used to dynamically generate notices use standard language based on KHPA defined policy. Our security and application tools allow State-specified Users to add free-format text to the standard NOA template language only when State policies or Federal regulations permit. In these cases, the user also has the capability to edit and/or delete the free-format text prior to the Notice being sent to the client. Our K-MED document management tools confirm the use of the appropriate NOA version based on the month/year of eligibility determination and the regulations in force at that time. As a part of our design activities, we perform an analysis to recommend new electronic forms and incorporate existing KHPA forms into the overall K-MED solution design as agreed to with KHPA. We also document the new business process that is supported by the use of new or enhanced e-forms capabilities through the K-MED solution. During the design phase, we work with KHPA to determine the appropriate text for notices and correspondence in order to meet KHPA s forms and notices requirements. KHPA would validate the quality and accuracy of notices throughout the construction and test phases. The foundation for the K-MED solution is a data model that we normalize for optimal flexibility and data integrity. During the design phase, we would define, document, and map the data elements required for correspondence and notices to our baseline data model. We use this information to verify the addition of the data elements required to the K-MED data model including case conditions such as status and language that dictate which text snippets we use to assemble a notice

186 Security Management Services Accenture s comprehensive Data Protection Program includes dimensions for People, Process, and Technology, addressing Access, Data, and Management controls, all working toward the goal of securing sensitive data and preventing data loss. The Proposer shall describe its approach to analyzing, establishing, and documenting security functions across all software modules and integrating these security functions into the State s security network. Administering the medical assistance Our proven approach provides a comprehensive, collaborative and modular security program for the K-Med System Utilizes standards and open source protocols, including WS-I and W3C Integrates with leading commercial products and open source components Supports the current applicable HIPAA, HI-TECH and CMS security compliance requirements Contains established architecture libraries and frameworks Multi-layered solution based on preferred practice defense-in-depth design principles Saves cost and provides consistent security standards by leveraging the State s existing architecture programs requires KHPA to obtain and retain highly confidential Protected Health Information (PHI) and Personal Identifying Information (PII). KHPA takes the responsibility to protect this data very seriously and expects the Contractor to provide a solution that includes necessary safeguards. It is imperative that all Federal and State rules and regulations, as well as KHPA policies, are followed to ensure customer information is not put at risk. Data must be protected through every phase of development and implementation, when it is stored, being accessed, or transmitted. The solution must also support audit trail functions to easily trace historic information. Accenture takes the responsibility to protect highly confidential Protected Health information (PHI) and Personal Identifying Information (PII) very seriously. We use a holistic approach to analyzing, establishing, and documenting security functions. Security is an integral piece of each stage of the Accenture Delivery Methods. In other words, each phase from early requirements gathering through deployment and ongoing run - has a security component, whether it is stored, being accessed, or transmitted. In this way, security is baked-in to the Accenture methodology. Accenture s Data Protection Program targets people, processes, and technology in pursuit of protecting sensitive data. The program is a methodology that encourages a comprehensive approach to security. Rather than concentrating solely on tools, Accenture s approach is to analyze the objectives around information protection, and the different types of controls that are in place (or are being considered) to address these objectives. Figure 7-74 illustrates the program, and provides some descriptions of the different types of controls that might be present in each of the arenas: people, process, and technology. Our approach (Figure 7-75) includes layered technology and integrated, logical controls to secure and monitor data based on industry accepted principles of defense in depth. It encompasses relevant security domains and follows Federal and State rules and regulations, Kansas ITEC & KHPA Policies, NIST, HIPAA, ARRA/HI-TECH and other preferred rules and standards. Data access is routinely logged and archived in order to support an audit trail to easily trace historic information. Protecting your client data is of utmost importance to Accenture. Data Protection addresses confidentiality, integrity and availability. We are responsible for securing some of the most sensitive data in the world, and it is critical to maintain the public trust in the government and the contractors with whom the government chooses to do business. Accenture has developed a 7-186

187 Information Protection Control Objectives Key Controls Access Controls Data Controls Management Controls People Process Technology Least privileged access to sensitive information Regular user certification for sensitive information access Define legitimate business requirements for access to sensitive information Sensitive information accountability and ownership is well defined Establish end user information security awareness program Monitor end user compliance to the information security policies and procedures Provisioning and de-provisioning process for sensitive information access Access to sensitive information in accordance to customer notification Information is properly classified according to data classification standard Establish information handling and collection procedures in accordance to data classification standard Conduct regular risk assessments to assess information protection controls effectiveness Regularly monitoring regulatory compliance requirements Application access controls exist to restrict access to sensitive information Technology infrastructure capable to support access control requirements Sensitive information in non-production environment should have same production access controls Data is stored in accordance with Federal and State rules and regulations as well as KHPA policy Appropriate application and system logs are retained and available for forensic research Management of application and infrastructure meets information protection requirements FTC Data Security Principles GAPP CobiT 4.0 ISO 17799:2005 Industry Data Loss Prevention Frameworks and Standards PCI Data Security Standard K-MED Figure Accenture s Data Protection Framework targets people, process, and technology to prevent data loss robust Client Data Protection (CDP) Program (shown in Figure 7-76) to define and address baseline controls from which KHPA would benefit as we apply it on the project. Our CDP Program is a globally recognized ISO compliant data privacy and security focused initiative. The BSI (British Standards Institute) assessed Accenture s global CDP program and found it consistent with ISO/IEC (International Electrotechnical Commission In addition, a number of our delivery centers including our San Antonio Delivery Center - have ISO27001 certifications. We include necessary safeguards to protect data through every phase of development and implementation, when it is stored, being accessed, or transmitted at both the Kansas and the San Antonio Delivery Center locations. Core CDP Access Controls Data Controls Endpoint Application & Data Servers Network Infrastructure OS Controls I&AM OS Controls I&AM NAC Network Segmentation Strong Authentication Access Control (Profile & Roles based) Encryption Messaging Security Data Discovery & Classification Data Backup & Replication File Integrity Checking Data Quarantine Mobile Devices Digital Rights Management Filtering Content Filtering Data Relocation Training & Awareness Learning Management Vulnerability Management Endpoint Monitoring Management Controls, (People, Process, Technology) Change Management Centralized DLP Monitoring Testing Security Event Management Audit Risk Assessments Availability Management K-MED Figure Accenture s layered approach provides multiple complimentary measures to protect the State s data 7-187

188 components include: Independent global oversight Data privacy training and awareness for staff A global Code of business ethics which incorporates data privacy Global and local policies on data protection, privacy, confidentiality and security Global client data protection controls and standards Procedures for response and prevention of privacy and security incidents Global Data Privacy Team integrates applicable changes in HIPAA, HI-TECH, etc. security and privacy rules and regulations and monitors implementation of these changes in the CDP Plan Security Program Feature Manage commitments to Federal, State and Department regulations for security and confidentiality Security program based on NIST SP and ISO 27001/27002 Detailed security policies, standards and guidelines Potential Benefit to Kansas Constant reinforcement of security processes and data protection requirements Independent audit of project security plan and security measures by the Accenture Public Service Data Protection Group Streamlining the security control and compliance across regulations Elimination of duplicate controls to meet independent requirements Clear, concise and enforceable security rules for Accenture and subcontractor personnel Provides site specific security policies and procedures Adheres to KHPA information technology security policies and standards Security awareness for personnel to include review of KHPA security, confidentiality, and auditing requirements Regular assessment of security program elements Ability to rapidly adjust security program elements Mandatory security education and training Continual improvement supported by a security metrics program Figure Our security program includes measurable and repeatable processes that potentially lower security risk and enhance data protection Security The Proposer must fully describe its approach to security for the proposed solution, including but not limited to the use of firewall hardware and software, intrusion detection/prevention systems, other protective measures, and other measures that provide in depth defense for the proposed solution. The proposal must fully describe the risk management approach to application development and deployment in terms of threat and vulnerability identification, analysis and prioritization, and mitigation techniques. We appreciate that security is a fundamental concern for Kansas in their K-MED implementation. We share your concern. Our solution includes a balanced approach that blends security risk management, architecture and policy compliance with industry tested technical controls, delivered by embedded security resources in multiple delivery teams. Since the State already has an existing infrastructure in place, we would complement and expand the Kansas Information Technology Architecture (KITA) and integrate with the State s WAN (KANWIN) to secure the K-MED System to save cost and provide consistent security 7-188

189 standards. We would use the State s existing intrusion detection and prevention solutions as part of our initial security infrastructure. The State also has an existing firewall in their data center which we would leverage as part of our solution, clearly identifying access requirements and following standard port designations. Similar to the FMS system, we would use a tiered architecture approach to keep the majority of the application behind this firewall. The database and application server tiers would reside behind the State s existing firewall, while the web server tier would reside in the DMZ. During the infrastructure design phase, we would assess the existing network security measures, including firewall configurations, intrusion detection and prevention, and other existing security measures. At that time, we could provide the state with recommendations for enhancements to their existing solutions. As described above, our solution includes a balanced approach that blends security risk management, architecture and policy compliance with industry tested technical controls, delivered by embedded security resources in multiple delivery teams. We base our security architecture on the proven capabilities of market leading commercial-off-the-shelf (COTS) security products and the existing security capabilities of our APSP solution. We use Oracle s powerful Identity and Access Management Suite as the backbone of our K-MED access and management control solution. We use the Oracle Identity Manager and Oracle Role Manager products to provide flexible web-based centralized and decentralized role and security profile management capabilities to meet KHPA s requirements. We have organized our solution capabilities into five domains, as shown in Figure Security Risk Management Our security solution architecture includes significant risk management solution components. This solution lays a foundation of policy as well as analysis, establishment, implementation and documentation of prescriptive security procedures and processes. This component covers the management and governance of risk and security controls. It includes functionality for continually assessing and mitigating risk as well as documentation and vetting of requirements for security controls. The security risk management architecture function delivers processes and technical controls derived from the identified policies and requirements, as well as tools used to enhance the security of development efforts, measure risk, and manage it. Security professionals would be part of the Accenture team to build security into the solution from requirements through deployment and run. The security risk management portion of the architecture includes four core capabilities: Security Policy and Architecture: Defining and documenting expected security behavior, acceptable use, and the controls for monitoring and enforcing them. Security Development Integration: Execution of the technical and procedural controls defined by the architecture and policies, such as complying with the Secure System Accenture is an especially good fit for buyers that: - Require substantial expertise in implementing security technologies. Accenture s strongest area of expertise is IT integration and implementation, and its security services leverage this wealth of knowledge to drive customer success. - Need to complete large-scale, comprehensive security initiatives. Very large projects are not new territory for Accenture s extensive consulting staff, and the company s expertise is well divided among the various technical domains of security Forrester Research The Forrester Wave, Security Consulting, Q

190 Security Risk Management Security Policy and Architecture Security Development Integration Security Awareness Client Data Protection Data Protection and Privacy Data Classification and Discovery Data Loss Prevention Security Solution Domains and Capabilities Identity and Access Management Directory Services Access Management Entitlement Management Identity Management Infrastructure Security Data Center Security Database Encryption Endpoint Security Encryption Network Security Security Information and Event Management Messaging Security Business Continuity and Disaster Recovery Backup Business Impact Analysis Disaster Recovery Planning Business Continuity Planning K-MED Figure We apply our security capabilities throughout our solution maintaining tight controls Development LifeCycle (SDC) to avoid introducing potential errors and risks like the CWE/SANS Top 25 Most Dangerous Software Errors and the OWASP TOP 10 Web Application Security Risks. Security Awareness: Communications with and training of users on the expectations, requirements and acceptable behaviors outlined and mandated by the identified policies. Client Data Protection (CDP): Client data protection is a mandatory, pervasive process that applies preferred practice security and privacy methodologies to the way Accenture teams handle sensitive client-owned data. This includes such recommended practices as performing internal and external (by a KHPA approved 3 rd party entity) penetration tests and vulnerability assessments of the network and supported servers and applications. Prior to production phase go-live, we would provide these results to KHPA, jointly review, and provide recommendations on how to best address or remediate the findings prior to production installation. We would then continue to perform regularly scheduled scans of the K-MED System post-installation, review the findings and remediate as needed as part of our ongoing warranty and maintenance support. Data Protection and Privacy Our data protection and privacy capability addresses the need to identify and protect sensitive data. The data environment is dynamic with new elements being added all the time, so the process of classification and protection is ongoing. Data protection and privacy includes the following capabilities: Data Discovery and Classification: Identify, map, and classify the data in conformance with identified policies and requirements Data Loss Prevention: Control access to data, encrypt it, and monitor access. Control usage, modification, and transmission of data once access is allowed

191 Identity and Access Management Our Identity and Access Management (IAM) capability addresses the need to provision users with access rights across systems and services, control their access to systems and data in conformance with those access rights and do so in a consistent, scalable fashion. Identity and access management includes the following capabilities: Directory Services: Centralized, standardized system automating network management of user data, rights, security, and distributed resources and supports interoperation with other directories Access Management: Provides consistent, centrally managed control over user access to applications, web portals/pages, and the system Entitlements Management: Supports the configuration and management of data-elementgranularity access controls Identity Management: Enables scalable, consistent assignment of user identity, roles, access rights, authentication parameters, and application access information We base our access management and control solution on a hybrid model. Our hybrid model uses the powerful and complementary features of Oracle s Identity and Access Management Suite and the existing capabilities of our APSP platform. This model provides KHPA with powerful and flexible access control technologies to protect access to sensitive data and support simplified user administration. Oracle provides the most comprehensive suite of Identity and Access Management solutions in the industry. These products have been subjected to rigorous testing by both commercial and government standards organizations. Access management technologies continue to rapidly evolve and our access management and control platforms and products can be easily refreshed throughout the life of the K-MED program. Figure 7-78 shows the features and benefits to KHPA related to our selection of a leading identity and access management suite. Features Comprehensive Identity and Access Management solution from Oracle the industry leader in Identity Management Users sign on once and get access to authorized functionality and page views Centralized control over application security Protects applications with policy agents to enforce rules and role-based authorization Oracle Identity Management Suite provides web services security capabilities with Oracle Web Services Manager Contains advanced functionality and centralized web services security console Web based administrative tools to manage federated partners Benefits Widely deployed and tested solution deployed to a wide variety of organizations Enhanced user experience and increased productivity through simplified access to K-MED Ability to quickly modify access policies based on KHPA s policies or requirements or new legislation Secure and widely validated mechanism to define access rights, page views and user actions Flexibility for future growth and SOA evolution Advanced capabilities to support future KHPA Identity and Access Management programs and partnerships Simplified integration with partner Identity Management platforms Figure The Oracle Identity Management Suite provides powerful policy based access controls for users, support for future access schemes by KHPA partners, and rapid integration based on the successful alliance between Accenture and Oracle 7-191

192 Infrastructure Security Our infrastructure security capability addresses the access controls, monitoring, incident management, and protection of data at the system and network layers of the solution. The solution infrastructure must also comply with appropriate regulations such as HIPAA, HI-TECH, and CMS requirements and NIST security standards. The infrastructure security portion of the solution includes the following capabilities: Accenture offers good consulting capabilities but an almost unsurpassable level of technical competence. Accenture is able to offer a robust set of services by maintaining deep technology expertise and ensuring high-value and high-impact partnerships. Forrester Research The Forrester Wave, Information and Risk Consulting Services, Data Center Security: Protect the data centers, processing facilities & physical environments in which computers, and electronic data systems reside Database Security: Protect the database systems that store process and serve data to applications Encryption: Provide encryption services for data in transit or at rest in systems Endpoint Security: Secure and protect the individual servers and systems processing data or hosting applications which process data Network Security: Control and protect network traffic between critical systems and users of the systems Security Information and Event Management: Aggregate and correlate system logs and events and prescribe action to mitigate risk and address threats Messaging Security: Protect the integrity and confidentiality of data being transacted through messaging systems such as . Business Continuity and Disaster Recovery Our Business Continuity (BC) and Disaster Recovery (DR) capability addresses the planning and functions that reduce the risk of data loss and that support the restoration of data and of system function on a day to day basis, and during times of disaster or system failure. This solution element includes: Back-Up: Make secure copies of data so that these additional copies can be used to restore the original after a data loss event Business Impact Analysis: Identification of critical (urgent) and non-critical (non-urgent) organization functions and/or activities Disaster Recovery Planning: Allows for resumption of applications, data, hardware, communications (such as networking) and other IT infrastructure Business Continuity Planning: Identify the organization's exposure to internal and external threats and identifies policies, processes, plans and procedures to provide effective prevention and recovery for the organization in the event of an unforeseen event. The proposed solution shall provide application controls to prevent unauthorized use of the system, maintain system process controls, and log all transactions. In addition, the system shall provide security to limit availability to application functionality, software screens, data records, data elements, and data element values where appropriate. Application Access Controls The APSP and underlying Oracle components provide a comprehensive facility for 7-192

193 controlling user access to different parts of the K-MED System. The APSP Authentication capability provides coarse- and fine-grained authorization based on access policies. It leverages Spring Security Framework to manage application security and utilizes Oracle s Access Manager to secure access to KHPA s systems. Its abstraction architecture insulates the application from changes in security infrastructure, allowing for ease of maintenance and data access for easy-to- generate audit reports. The APSP Authorization capability provides that only registered and authenticated users or services can access protected resources, including securing business objects and application resources and software (e.g., URLs, EJBs, JSPs, etc.). It accesses a 3rd Party Web Access Control (WAC) and Spring Security s Authorization framework to provide an enhanced security platform to abstract authorization decisions from application logic. The underlying Oracle Identity Management Suite provides user, system and application security by providing user provisioning and identity auditing for efficiently and securely managing identity profiles and permissions across applications. For example, it allows customers to securely log into the APSP Self-Service Portal with a unique username and password to access their own personal and protected information, but not that of any other customer account. It enforces corporate security policies by disabling user accounts in target systems to prevent unauthorized access to applications and information, such as locking out previous household members to prevent them from viewing former case information. The system would also logout accounts after being idle for an established length of time, and suspend accounts after an established number of unsuccessful logon attempts. It also provides detailed traceability and accountability of user interactions with the K-MED System. The APSP implementation of the Oracle Access Manager integrated with the Spring security authorization framework provides an abstraction layer for easier maintenance, or transition to an upgrade of the Oracle Access Manager or other product. It protects applications from unauthorized access and provides a centralized identity and access management system, which enables user access as well as protects application and system access by limiting availability to application functionality and data. The Proposer shall describe its approach for integrating security with overall system security using a single sign-on. Single Point of Entry Our APSP Security Architecture provides single sign-on capabilities by integrating security software and protocols to authorize and validate system users, requiring a user to authenticate only once. Access control lists manage the mapping between the services and content available through the portal and the user s access authority. This feature allows the K- MED System to be the single point of entry to access information, content, and services. Using additional portal features the K-MED System is presented as a single unified application under one common theme. The portal pages of the K-MED System are job-based and are displayed to the user in a logical order to facilitate task completion. These job-based pages merge content and services from multiple sources and present them logically in functional areas directing users from page to page based on the task. Users have single sign-on access to several exposed independent business services which are displayed within the portal as functional areas. The services and content presented by the K-MED System are coordinated by managed workflows leading users along a logical progression of activities to complete assignments

194 Our underlying Oracle Identity and Access Management Suite is also scalable - by leveraging a modular, component-based architecture it is compatible with LDAP directory stores, such as Active Directory. By making use of user security roles for fine-grained data access, it provides for user authentication, access authorization, auditing, monitoring and administration. The proposed Security Architecture provides a SSO solution that allows an end-user access to one or more protected resources after a single successful authentication. This also applies to multiple records. For example, an attorney who serves as a guardian for multiple programs or a foster parent with several foster children would only have to log into the APSP Self-Service Portal once to view multiple records or information for all members of a case for which they are authorized. The K-MED System would also interface with the MMIS Member Web Services portal, allowing customers to access information in the member portal without an additional log on. Figure 7-79 shows the capabilities of providing SSO through optional approaches. Capability Approach Single Domain SSO Authenticates a user for a set of URLs within a single domain Creation of a cookie that is passed along and used for authentication within the domain, in lieu of requesting credentials Definition of a primary domain for authentication Product integration capabilities provided by Oracle Access Manager Multi Domain SSO Authenticates a user for a set of URLs residing on multiple domains Third-Party Product Authenticates across third-party Integration products Figure APSP Security Architecture is sufficiently open and flexible to support a variety of singlesign-on (SSO) models The Proposer must describe how the proposed solution will: 1. Ensure data confidentiality, including protection from unauthorized access, while: In transit either through execution of secure, authenticated, two-way transactions as well as ensuring that all other data is encrypted beyond the reasonable threat of a successful brute force attack, or comparable risk-based mechanisms; In storage ensure that confidential data in databases from which public data is being extracted will not be compromised; Data Protection in Transit and in Storage Data protection is the main focus of the security strategy. Data must be protected while in storage and in transit to protect data confidentiality and prevent unauthorized access. Our encryption strategy is based on 128-bit SSL/TLS for protection of data in transit, and data encryption appliances for key management and encryption of data at rest. This strategy enhances data protection, simplifies key management, and yields high data integrity and availability. Data in storage is protected by multiple layers of security measures. If a user intentionally tries to bypass the first security measure, the next security measure would prevent them from gaining access to the data. Four typical levels of data protection are as follows: Level 1 - Application security. Users must authenticate to the K-MED application, and their authorizations only let them access the appropriate data according to their role. Level 2 - Database security. The Oracle database provides its own level of authentication, and typical users do not have direct database access. Only authorized administrators have access to data at the database level

195 Level 3 - Operating System security. In order to access the database files, it is necessary to gain access to the operating system. Typical users do not have this access, preventing them from accessing the raw data files. Level 4 - Network security. The network devices can be configured to allow access only from authorized terminals. This further prevents unauthorized users from gaining access to the physical machines where the data resides. Data in interface files is protected by operating system security, as detailed in the foregoing list of data protection methods. However, an additional security measure protecting interface files is file encryption. Using a product such as PGP, our interface architecture encrypts interface files on external-facing FTP servers to prevent data exposure. Data in report files fall into two different categories those that are stored in the K-MED Report Repository, and those that are downloaded to users machines. Reports stored on the Report Repository would be protected by operating system security and network security, as detailed in the foregoing list of data protection methods. Reports downloaded by a user become that user s responsibility. The K-MED System cannot protect data once it is brought outside the system by a user. The user is responsible for ensuring the security of any downloaded, printed, or otherwise externalized reports. As illustrated by these measures, our solution provides comprehensive protection of data in storage. A malicious user would need to compromise several levels of controls in order to gain access to sensitive data. At each tier of the architecture, we secure data in transit via industry-standard methods. We use dedicated encryption appliances designed for high performance processing and that are FIPS certified. Figure 7-80 shows the encryption methods that would be employed for communication between the architecture tiers. These encryption methods would prevent a malicious user from intercepting the data in transit. Encryption provides protection for sensitive data but can be quite problematic to implement. Poorly conceived encryption strategies lead to complex key management processes and reduced application performance. We offer a highly simplified encryption solution that provides KHPA maximum protection for sensitive data with high application performance. We use 128-bit Secure Socket Layer/Transport Layer Security (SSL/TLS) by default for Users SSL/HTTP (i.e., HTTPS) Web Servers JOLT (Encrypted) Application Server Application/Batch Servers SQL*Net (Encrypted) RDBMS Server Oracle Instances SSH FTP (i.e., SFTP) and PGP encrypted FTP Interfacing Systems K-MED Figure Encrypted protocols provide network security between the architecture tiers, securing data in transit 7-195

196 protection of data in transit between users and the K-MED architecture. We enable SSL/TLS with server-side digital certificates from a leading encryption provider. We use server and database encryption to provide high security for data at rest. Data sent to and from the K-MED Storage Area Network (SAN) is also encrypted so that the data is protected from compromise. 2. Include preventive and detective access controls and reporting mechanisms, ensuring a timely and reliable process for notification to the user, custodian, owner, and/or customer in the event of a security breach; Preventive and Detective Access Controls and Reporting Mechanisms While measures are taken to avoid security breaches, the possibility always remains that one could potentially occur. In the event that one does, we understand the importance of a timely and reliable notification process to the various parties involved. Following the principle of defense in depth, multiple technical controls would be in place and software installed on the servers to help detect and block network intrusion attempts at the endpoints. Some of these technical controls include checkpoint firewalls, which would be used as access control points with rule sets/policies restricting traffic to only what is necessary for the K-MED applications to operate. Cisco Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) at the firewall level / network layer would be leveraged to analyze incoming packets. These technical controls are used to detect and report network traffic patterns that could represent a risk or malicious attack in progress. When found, the systems can be configured to automatically address the attack by modifying router configurations to cancel the suspect traffic. We provide a configurable notification capability within the K-MED System that collects and reports security data from multiple sources. Primary data sources include the access management and control platform and the core K-MED solution. Activity that meets KHPA defined parameters initiates alerts available as s or sent to mobile devices. We deliver the alerts using an SMTP engine for and an to Short Message Service (SMS) conversion interface for mobile devices. The alert function operates with solutions including Lotus Notes and Microsoft Exchange. Figure 7-81 shows the capabilities of our alert and notification capability and the sources for valuable alert information. 3. Ensure that access controls are strictly enforceable and auditable; Enforceable and Auditable Access Controls The APSP Authentication and Authorization capabilities and underlying Oracle Identity and Access Management Suite provide a robust facility for controlling user access to the various parts of the K-MED application by enforcing powerful policy based access controls. The APSP Authentication capability provides coarse- and fine-grained authorization based on access policies. It leverages Spring Security Framework to manage application security and utilizes Oracle s Access Manager to secure access to KHPA s systems. Its abstraction architecture insulates the application from changes in security infrastructure, allowing for ease of maintenance and data access for easy-to- generate audit reports. The APSP Authorization capability provides that only registered and authenticated users or services can access protected resources, including securing business objects and application resources and software. It also provides detailed traceability and accountability of user 7-196

197 Alert To Smartphone Alerts From K-MED Application, ArcSight ESM, and Oracle Access Manager Alert To Conventional Phone K-MED Figure Our solution includes a configurable alert and notification capability which aggregates security data from multiple sources, and sends alerts via or to mobile devices for prompt investigation and management interactions with the K-MED System. Our APSP Audit Service writes access data to a database, JMS queue, or file for recording authentication and authorization events based on common logging configurations. Please refer to Section (Security Audit Trails and History) for more information regarding the K-MED solution audit trails and history. 4. Ensure data integrity maintain data and transaction integrity and confidentiality; where applicable address legal and regulatory issues with regard to unauthorized access, misuse, or fraud audit trails, and options for resolution. 5. Ensure data reliability maintain sufficient detail and summary information to ensure statutory and regulatory reporting and compliance responsibilities. 6. Ensure data availability maintain data and network access continuity ensuring its availability for required business processes. Data Integrity, Reliability and Availability Data and transaction integrity and confidentiality is maintained with our K-MED security program depicted in Figure The APSP inherent architecture provides data integrity, reliability and availability via the logical unit of work concept. Transactions are either fully applied or fully rolled back there are no partial commits. If a user enters a transaction involving multiple database records, and the application fails when it tries to write to one of these records, the entire transaction is rolled back from the companion records, allowing the user to correct the error, and thus maintaining data integrity. Our APSP architecture addresses data integrity, reliability, and availability in a number of 7-197

198 Govern Security Program Monitor Assess Build Plan Policies Standards Metrics Report Report Compliance K-MED Applications & Data Control Network Access Control System Access Monitor Application Report User Access Monitor Network Manage User Identity Security Roles and Profiles Monitor User Access Report Security Configuration Changes Monitor, Log & Alert and Audit K-MED Figure Our K-MED security program provides security governance, effective processes, and market-leading technologies to protect KHPA data and systems across the entire security life-cycle additional ways. The robust, strictly enforceable application security, as well as the encryption methods employed at multiple tiers of the application architecture, both assist in providing transaction integrity and confidentiality. These security measures provide robust protection against malicious attacks on data, maintaining the confidentiality of the transaction. Within our APSP architecture, our Oracle Identity Management Suite products only allow authorized access to applications and information, and provide detailed traceability and accountability of user interactions within the K-MED System. Authorized users keep their identities up-to-date through a self-management console, and updated data is spread through the various systems connected to a single provisioning architecture by using a reconciliation engine, helping maintain its integrity through the entire enterprise. Another layer of security involving data integrity and confidentiality is built into our K-MED web services. Information exchanges between Web services consists of XML payloads over SOAP and HTTP or HTTPS. Where secure web service exchanges are required, we comply with Organization for the Advancement of Structured Information Standards (OASIS) WS-Security mechanisms for SOAP message integrity, confidentiality and authentication. We use dedicated encryption appliances to protect K-MED data. These powerful appliances automatically perform integrity checks during decryption operations to verify that data has not been modified. We encrypt data both in transit and at rest, strictly limiting access to the data and helps prevent unauthorized tampering. Where applicable, legal and regulatory issues are addressed with regard to unauthorized access, misuse, or fraud audit trails, and we would work with KHPA to determine possible options for resolution. Throughout each phase of the K-MED project, we would address compliance with the most common Medicaid security laws and regulations, such as HIPAA and Kansas Administrative Regulation (KAR) As seen in Figure 7-82, our solution incorporates robust and dynamic reporting capabilities on compliance, user access, and security configuration changes. These capabilities help enforce data reliability by maintaining sufficient detail and summary information to help confirm statutory and regulatory reporting and compliance responsibilities

199 Because APSP is a SOA based architecture, the distribution possibilities of the architecture and applications it supports is very flexible. All proposed components of the solution are designed to follow standard J2EE high availability patterns. The Web UI components are designed to scale vertically by using multi-cpu servers and / or horizontally by using multiple servers behind a load balancer. The Application server parts are also designed to scale vertically and horizontally in the same manner, supporting parallel processing and failure recovery of server processes. Since the solution uses standard J2EE patterns for database and messaging system connectivity, it is also able to leverage the high availability capabilities of the underlying application server, database and / or message buses. The result is an architecture that supports massive redundancy, which in turn improves scalability and provides continuous access to the network and data, and thus high availability for required business processes. Oracle Data Guard (DG) provides the ability to set-up and maintain a standby (mirroring) copy of the production database, providing replication capability and high availability. DG propagates changes through archived redo logs to the standby database at a remote disaster recovery site. The remote standby database takes over for the primary database in the event of a primary database failure or a disaster in the primary production data center. DG is configurable for handling the failover to the remote site using either automatic or manual failover. Oracle Real Application Clusters (RAC) allows us to use several database servers in a cluster to provide redundancy and manage load. Using high-availability features allows real time fail over to a different RAC server if one server fails, and provides an efficient and cost-effective way to balance load and provide scalability. In the traditional dedicated database server environment, you would have to replace the single database server with a larger database server. In an Oracle RAC environment, you could add another low cost, smaller blade server to the cluster to add the additional delta you need. KHPA has requested a system capable of 99.8% availability, and we have architected a system to match this requirement. Details of our system configuration and how it meets this high availability requirement can be found in the Technical Architecture and Infrastructure Design Section (7.1.3). 7. Ensure physical and environmental control working with the State, identify mechanisms ensuring only authorized operations personnel access data or computer facilities unless expressly approved by the owner of the data, and determine environmental control required to mitigate the risk of loss. Physical and Environmental Control Physical and environment control is another aspect of holistic security design. Our solution would make use of existing KHPA data center facilities and their attendant physical access controls to provide a secure solution. These physical and environmental controls may include: Physical access controls such as ID card readers, fingerprint readers, security guards, and security cameras Environmental controls such as full climate control, raised flooring, backup power sources, and fire prevention, suppression, and detection systems During the infrastructure Design Phase, we would assess the existing State facilities to determine the viability of using these facilities to host the K-MED infrastructure. If deemed 7-199

200 necessary, we would recommend additional physical and environmental controls to provide the necessary level of security for the K-MED application. We would work with KHPA to identify any additional physical or environmental mechanisms to help confirm only authorized personnel have access to the facilities in order to mitigate the risk of loss. Please see Section 11.5 (Facilities Location and Space Requirements) for a sample of our Security Plan which would encompass the proposed physical and environmental controls. 8. Ensure application audit capabilities implement date-time stamp, or other mechanism sufficient to provide an audit trail for identifying critical data and resource application activity, and the reporting of unauthorized intrusions and activity or attempted breaches. Application Audit Capabilities APSP is delivered with various levels of auditing capability. KHPA may choose to audit data at the field or record level, via the application or via database triggers. Auditing of data is specific to each implementation, as different organizations have unique auditing requirements. We would work with KHPA to determine the appropriate auditing strategy, and assist in implementing that strategy in the K-MED System. Our APSP Audit Service writes data to a database, JMS queue, or file for recording authentication and authorization events based on common logging configurations. It can be configured to include a date-time stamp, user ID, data accessed and other identifiers determined by collaborating with KHPA in order to identify critical data and resource application activity. The reporting of unauthorized intrusions, activity, or attempted breaches would follow the established Incident Notification Process. Please refer to Section (Security Audit Trails and History) for more information on our proposed security audit trails and retention. 9. Ensure a rigorous change management and configuration management implementation implement processes to maintain data integrity, confidentiality, and availability in the application change management processes. A rigorous change management process will include preventive and detective controls ensuring only authorized software changes are implemented. The Contractor must provide in its proposal a detailed description of its configuration management methodology which must include at a minimum: a. A description of how the Contractor will control multiple activities occurring simultaneously across multiple environments; b. A description of tools and business processes to control software development, including check in/checkout procedures and audit trails; c. A description of business processes and procedures for controlling the migration of code from design through coding, testing phases (e.g., unit, integration, acceptance) and promotion into production. d. A description of the organizational structure to control all system development and maintenance. e. A description of tools and business processes to control documentation and User Guides. Change and Configuration Management Our solution includes a robust configuration management process to help maintain data confidentiality, integrity, and availability. For projects of this size, we recommend configuration 7-200

201 management software that can help to enforce rigorous processes and policies. We have, in the past, used various applications for this purpose, including an application that we used (and which was well liked) at the State for the SHARP implementation. That application, called CPSS Utilities, is no longer supported; however, our recommended solution is built on similar technology and incorporates much additional, useful functionality unavailable in CPSS Utilities. We accomplish application change and configuration management using our Accenture Delivery Tools (ADT) suite, for which we rely on the following products: Rational RequisitePro Requirements tracking and traceability management ClearCase Change control and code/document version repository ClearQuest End-to-end management of configuration from requirement definition to code item definition to defect management to traceability verification All of the Rational tools in the ADT have been pre-configured with templates, processes, and documentation from the Accenture Development Methodology. These enhancements promote adherence to the methodologies and faster uptake for Accenture teams. This benefits KHPA by lowering risk and increasing quality through the K-MED implementation lifecycle. The ADT delivers a powerful configuration and change management solution that spans application and infrastructure lifecycles, from development, testing and deployment to monitoring and change management, across multiple environments. Potential benefits include simplified management, improved service, and enforced compliance. The ADT includes automated discovery and the ability to track configuration changes in real time simplifies management of both applications and server infrastructure. Organizations can also avoid unplanned downtime with better configuration management and patch consistency across both application and server lifecycles. Compliance reporting dashboards and out-of-the-box policy frameworks for popular industry and regulatory requirements are also available. The ADT offers full configuration management features: Complete workflow capabilities Automated migrations Versioning of objects and file-based objects using check-in/check-out procedures Full audit capability Ability to administer multiple environments and versions The strict workflow controls within the ADT provides that only authorized changes are promoted to the Production environment by a dedicated Configuration Management team, and proper approvals would be required. The ease of use and implementation also promote compliance, leading to fewer issues with team members trying to circumvent the process. These tools are not only used for managing code migrations and versioning, but for maintaining documentation and User Guides as well Security Profile Management The Proposer shall describe its approach for providing security profile management. In order to support a flexible business model and the various phases of the K-MED solution, we expand the existing role and profile management capabilities of our APSP platform to include a role and profile maintenance portal. Figure 7-83 shows the basic functionality of this portal. Our approach provides the ability to create, delete, modify and assign role-based security profiles 7-201

202 K-MED Application End User User Login Request Access Manager Identity and Role Management Component Administer Users & Roles Administrator Console Access Decision User & Role Updates Role Data K-MED System Pages All Rights for this Page Child Care Staff Child Care Supervisor Clerical Staff Clerical Supervisor User Data (Directory) Reports Search V V V V Enter Report Parameters V V V V Select Organization V V V V Select Worker V V V V Select Unit V V V V Select Office V V V V Address Detail E E E E E Office Search V V V V V Office Detail V, E V V, E V V K-MED Figure Our powerful web based role and profile maintenance portal is based on existing role management functionality in our high performance human services platform for a flexible, decentralized, and secure role-based user rights management capability quickly as KHPA business processes change. This new capability supports decentralized role creation, modification and deletion and features embedded controls to prohibit assignment of incompatible roles. Administrators can rapidly create or update user permissions with immediate effect. KHPA s authorized representatives may also rapidly suspend a user s access (temporarily or permanently) to critical functions or sensitive information as warranted. The role and profile maintenance portal provides significant capabilities to administrators and security officers because multiple actions are performed from a single Web-based interface. The portal features contextual menus and drop down boxes to reduce the need for specialized training for KHPA staff. The portal also includes group functionality to allow administrators and security officers to make consolidated changes to groups of users to reduce role management administrative overhead. The portal includes features for recording a history of profile changes tied to the administrator that initiated the change. Figure 7-84 shows the powerful features of our role and profile maintenance portal and the benefits the portal provides to KHPA. Our Access Management and Control platform includes the Oracle Role Manager product. Administrators can use this powerful product to perform advanced role discovery and simplify complex and repetitive role maintenance functions. We log and securely store a wide range of role and profile maintenance activities for auditing purposes. Features Online role creation using contextual menus and drop down boxes Access changes and denials with immediate effect Highly granular access restriction choices down to individual screens, reports, and data fields Management of access and denial by groups Benefits Limited additional training required for KHPA administrators and designated staff Users can be productive with newly granted privileges or be immediately barred from access Users have access only to data and functions based on their work requirements Reduced effort for administrators and security officers 7-202

203 Features Benefits Online access to detailed history of security profile Tool to research system anomalies, security changes incidents, or profile management errors Highly intuitive interface; no special programming Rapid acceptance by KHPA administrators and skills required designated staff Figure Our web based role and profile maintenance portal provides authorized administrators and security officers the ability to quickly grant, restrict, or suspend user privileges and provide exceptional protection for sensitive citizen information Oracle Identity Analytics supports the creation and management of Business Roles. The business roles are assigned to users to provide access to applications and systems. Business roles can contain IT (provisioning) roles called "Policies" that contain access level entitlements. The Role Engineering module in Oracle Identity Analytics delivers sophisticated role mining, identity correlation, and risk management functionalities. Robust identity correlation reengineering capabilities offer an innovative approach towards traditional role engineering techniques. Oracle Identity Analytics defines Role Engineering in three process steps, which are as follows: Role Discovery Describes the process of discovering relationships between users based on similar access permissions that can logically be grouped to form a role. Role Entitlement Discovery Describes the process of mining role content or discovering the content of these roles by analyzing and finding correlations in user access patterns in applications across the Enterprise. Rules Discovery Describes the process of discovering rules that can be used to govern assignment of mined roles to new users, a powerful graphical feature that is embedded with the role mining process. Oracle Identity Analytics Role Engineering methodology supports the top down, bottom up, and recommended hybrid approaches. A hybrid approach is one that accounts for a users job function and HR attributes such as manager or geographical location along with account permissions (entitlements) when mining for roles. Within the framework of SOA, Oracle Identity Management functions in an applicationcentric fashion. As such, identity management becomes a function of application management - not systems management. Application-centric identity management is the next wave of identity management. It offers several distinctions over the way identity management is approached today: Woven in vs. bolted-on: Security is integrated into applications from the start - not forcefit afterward potentially providing improved security, easier development and lower administrative costs. Standards-based vs. proprietary: An open, heterogeneous solution assures interoperability and co-existence with current and future platforms and architectures. Integrated suite vs. point solution: A complete out-of-the- box integrated solution potentially speeds deployment and delivers continued gains in efficiencies and improved user experience. This solution aligns with APSP and industry recommended practices and trends advocating for a centralized infrastructure built and exposed as a service-oriented framework. The suite provides pluggable and reusable components that can be combined with APSP in various ways to address a myriad of security requirements posed by KHPA

204 The system must provide for multiple security profiles. K-MED will be utilized by KHPA eligibility workers, program staff, contractors, state agency staff, presumptive eligibility entities, and other external partners. All will require access to different data elements and have different functions within the system. KHPA must have the ability to establish canned security profiles as well as easily establish specific security profiles for special situations. In order to protect client information, separation of duties is of the utmost importance. The corresponding separation of data elements and functionality to which users have access, based on need-to-know, can then be mapped to different security profiles and functions within the K-MED System. For example, certain programs and eligibility conditions available on the portal could be limited to only State or other authorized staff, to discourage such activities as Medicaid Estate Planning if the transfer of property calculator were available to the public. Oracle s Identity & Access Management Suite supports a flexible business model which accommodates multiple role-based security profiles for eligibility workers, program staff, contractors, state agency staff, presumptive eligibility entities, and other external partners. It provides canned and custom, specific security profiles for special situations, such as community partner views for approved external entities to allow viewing of protected information and interaction with other users for cases with proper identification and authorization (i.e. nursing homes, foster care contractors, etc.). Our solution includes flexible profile-building to allow the ability to define profiles at multiple levels (by screen, field, case, etc.) and by function (ability to view, update, authorize, activate, inactivate, etc.). For example, it can provide administrative profiles for internal staff to mirror a customer profile as they see it or allow authorized staff to manually override an eligibility determination. Some of the identified security profiles include, but are not limited to: Eligibility Workers (with the ability to limit by location, specific job function, and medical programs) Clerical or Support Staff Line Supervisors Regional Managers Quality Assurance Staff Regional Performance Improvement Staff Program/Policy/Rules Engine Managers (Administrative profile to allow internal staff to update rules tables and other elements necessary to support policy and process changes) Interface/Exchange Managers Presumptive Eligibility Staff Presumptive Eligibility Support Staff System Administrator Password Administrator System Access Administrator Our system has the ability to easily add a vast array of profiles, and we would work with KHPA to identify additional security profiles during the Design Phase. A special security profile for a Long Term Care Community Partner role must also be included. A special security profile for a Long Term Care (LTC) Community Partner role would also be included with the above established security profiles. This would enable them access to the 7-204

205 system to contribute information necessary to the eligibility determination process or to report any changes in circumstances which may affect the individual s eligibility. This also applies in reverse eligibility staff members would have the ability to (automatically or manually) communicate information to the partner entity. This LTC Partner profile would enable real-time updates to eligibility information a vast improvement over the current method of communicating this information over mail, fax, or . Members and other individuals assisting them would have the ability to access individual information through self-service features. Some profiles that would be established are: Members and their Legally Responsible Persons Medical Representative (acting on a member s behalf), such as a guardian or medical representative who can complete an application or check benefits for the applicant / recipient. This allows the customer to have the same access, but with their own log on. Facilitator View (read-only / limited access) for individuals helping others with a medical assistance application We would work with KHPA to identify any additional self-service security profiles during the Design Phase. The Vendor shall propose a solution allowing State staff to manage profile creation, maintenance, and tracking, including authorization and assignment of profiles for individual users. As an option, the proposal shall also include a solution in which the Contractor provides profile maintenance services. With this option, State staff shall authorize all individual profile assignments, but the Contractor will create profiles, modify profiles, track profile changes, and perform all related profile support functions and data entry. This option shall be priced separately in Cost Proposal TAB 10 - Optional Costs (see RFP Section ). The Oracle Identity and Access Management Suite would allow State staff to manage profile creation, maintenance, and tracking, including authorization and assignment of profiles for individual users. However, Accenture can also provide profile maintenance services such as creating and modifying profiles, tracking changes, and performing related support functions and data entry, while allowing State staff to authorize the profile assignments Security Audit Trails and History The Proposer shall describe its approach for providing security audit trails. Our APSP solution is delivered with various levels of auditing capability. KHPA may choose to audit data at the field or record level, via the application or via database triggers. Auditing of data is specific to each implementation, as different organizations have unique auditing requirements. We would work with KHPA to determine the appropriate auditing strategy, and assist in implementing that strategy in the K-MED System. Our audit trail records can be configured to contain transaction history at field levels, and can maintain separate audit trail files for transactions processed by the K-MED System, initiated by a user, or users who update or view a record. Our audit trail records can be configured to contain such information as: Case identifier Recipient identifier User or system performing the action 7-205

206 Location of the user performing the action (IP address) Date and time the action was performed Name of the field being changed Field value before and/or after the change Our solution automatically collects security related data from a wide range of devices and platforms including firewalls, routers and intrusion detection systems to generate alerts and provide security personnel with customizable reports. We collect and securely store quality log files for a wide range of network devices, providing high security for log information and powerful capabilities to perform searches and investigate security anomalies and incidents in order to restrict access when necessary. The logging mechanism performs log integrity checks and automatically enforces configurable log retention policies, providing non-tamperable audit logs. The K-MED System would only allow authorized Audit Trail Administrators to administer the audit logs, and would support debugging system errors for troubleshooting purposes. The Audit Trail Administrator responsibilities would include: Maintaining a set of Audit Trail Users having access to the audit trails Defining the data allowable for viewing by individual Audit Trail Users (i.e. disallowing access to certain fields containing financial or Personal Health Information (PHI) for certain users) Performing activities permitted to any Audit Trail User Archiving and restoring any portion of the audit trail to/from an archival file Backing up, restoring, and/or refreshing the audit trail Shutting down or starting up the audit trail Generating audit trail reports, including limited ad-hoc reports (i.e. limited by size, record count, etc.) Similarly, Audit Trail Users would have the ability to: View the contents of the audit trail permitted by the Audit Trail Administrator Determine the viewing criteria (i.e. list audit trail records created during a specific period of time) Determine the sort sequence for viewing the selected audit trail records The APSP access management and control platform, based on Oracle s Identity and Access Management Suite, detects and logs unauthorized attempts to access the K-MED System, providing detailed traceability and accountability of user interactions. Our APSP Audit Service writes data to a database, JMS queue, or file for recording authentication and authorization events based on a common logging configuration. Figure 7-85 shows the features of the APSP access management and control platform and its benefits to KHPA for rapidly identifying and investigating security events and anomalies. Features Collection, aggregation, and storage of log data from a multitude of sources Secure security appliance with a hardened operating system and tamper proof log storage Support for a wide variety of log formats with minimal custom configuration Benefits Centralized security log repository supports rapid inquires, investigative support and forensic searches Self-contained appliance reduces maintenance, supports availability of log data and strengthens security for log data Future sources of log info can be easily added to the collection and storage strategy 7-206

207 Features Capability to store significant volumes of log data with on-line accessibility Powerful and flexible HTML based analysis portal Benefits Two terabyte log capacity and log file compression provide maximum accessibility and thorough historical analysis Portal facilitates high-speed pinpoint searches of large volumes of log data; search queries and report formats can be customized for ease of use Audit quality controls for log data Log files are securely collected and stored with integrity checks, configurable retention policies and restricted access based on need-to-know Figure Our APSP access management and control platform provides accessibility of log data from a wide variety of sources, high security for collected log data, and supports rapid investigation of security anomalies and events The K-MED system must provide a user friendly audit trail which captures a history of every transaction processed by the system. It must also record every user who views a window or other system feature. We would work with KHPA to determine the specific criteria and information desired in the log files to produce a quality, user-friendly audit trail to capture a history of every transaction processed by the K-MED System. Its reporting capabilities would include a variety of criteria, such as security level, location, IP address, user ID, data elements, etc.). In accordance with the HITECH Act, our compliant auditing capability would capture every user who views a K-MED window or other system feature Security Requirements The Proposer shall also respond to the detailed requirements related to Security referenced in RFP Appendix 1 under the Security Management Workbook. Please refer to Appendix 1 for responses to the detailed Security requirements referenced in RFP Appendix 1 under the Security Management Workbook

208 Testing Services Our testing specialists draw upon State specific experience, a documented application baseline, successfully demonstrated methodology, and an integrated toolset to implement a collaborative, comprehensive test plan resulting in reduced schedule risk, a well tested K-Med application, and a smooth implementation. The Contractor will be responsible for carrying out unit and integration testing for all programs, modules, and sub-systems throughout the development life-cycle. The Contractor is responsible for successfully completing system testing prior to both the pilot phase and implementation phases. The Contractor is responsible for certifying that Our successfully demonstrated approach will provide comprehensive, collaborative and transparent testing of the K-MED System Robust Accenture Delivery Tools maintain automated traceability between requirements, design and test scripts Tested and integrated methodology used in our 50 delivery centers worldwide provides consistency in testing Extensive testing on 50 external interfaces confirms that data is sent and received as specified Automated regression testing throughout all testing stages helps reduce introduction of new, unintended defects Transparent, real-time testing metrics presented via dashboards depict the global testing status throughout the development test-cycle each program, module, and sub-system meets or exceeds all of the functional, technical, and performance requirements prior to pilot and statewide implementation. The Contractor will be responsible for working with KHPA staff in structuring testing environments that mirror the production environment. The Contractor is also responsible for the initial development of User Acceptance Testing test scenarios, building detailed testing scripts, determining expected results, establishing testing procedures and protocols, etc. KHPA must approve all test scenarios prior to testing and KHPA reserves the right to request that additional test scenarios be developed and tested. The Contractor will be responsible for providing and maintaining an organizational plan showing Contractor personnel responsible for each type of testing. The Contractor is responsible for the management of the testing effort and other related events and communicating this ongoing information with the KHPA Testing Team. The Contractor must provide KHPA, in a timely manner, with all test results, to include the tracking and correction of deficiencies. Comprehensive testing is critical to the delivery of a quality product to the Kansas Health Policy Authority (KHPA). We strive to thoroughly test all aspects of the application including program modules and subsystems throughout the development life cycle. Prior to the pilot and statewide implementation phases, we carefully test the application to confirm the functional, technical and performance requirements specified in the contract are being met. We execute testing in an environment that is structured by our team and mirrors production. Our team takes ownership in creating the initial User Acceptance Testing (UAT) test scenarios. Throughout all phases of testing, we establish testing procedures and protocols, build detailed testing scripts, and determine expected results. All test scenarios are reviewed with the KHPA Testing Team for sign-off before proceeding with test execution and provide the opportunity for the team to introduce new scenarios if necessary. We engage the KHPA Testing Team within all testing activities. We finalize the details of the number of test teams and roles and responsibilities of each team member during project set up to create a thorough organizational plan. We manage all testing 7-208

209 activities and provide the KHPA Testing team with details regarding testing results, testing deficiencies and the resolution of each within all testing phases. Our Accenture Delivery Methods (ADM) testing strategy provides the foundation for an on time, low-risk, and reliable implementation. Figure 7-86 depicts the key activities involved in our testing strategy. Our extensive experience with Accenture Public Service Platform (APSP) implementations, reusable assets, and field tested methodologies contributes to a successfully demonstrated approach that potentially lowers risk while enabling accelerated testing and cutover KHPA Testing Team KHPA will designate a Testing Team for the K-MED project. The KHPA Testing Team will work with the Contractor to ensure testing activities are carried out as necessary. The Contractor shall involve the KHPA Test Team in testing activities as necessary throughout the system development life cycle. The KHPA Testing Team is responsible for overseeing the development of User Acceptance Testing test scenarios, building detailed testing scripts, determining expected results, and establishing testing procedures and protocols, etc. Effective use of KHPA s staff time contributes to a successful delivery of the K-MED System. We recognize that the staff s time is limited and by the time the staff engages in user acceptance testing, the software needs to be functioning at an extremely high level. We approach the incremental phases of testing in a way that will enable KHPA staff to focus on the testing of end-to-end processing of core business functions. Testing is a cooperative effort throughout the system development lifecycle. We collaborate with the designated KHPA Testing Team throughout the testing lifecycle. The needs of the KHPA project team are discussed during test planning. We engage the KHPA Testing Team and leverage their knowledge during test planning, test script creation, expected results determination, defect management, status reporting, and test closure throughout all test phases. Additionally, we work with the KHPA team to help identify and train select KHPA end-users to execute test scripts during User Acceptance Testing (UAT). We confirm that the test scenarios are approved and signed off by the KHPA project team prior to UAT testing and all other test phases. Analyze Design Build Test Deploy Prepare and Execute Assembly Test Prepare and Execute Product Test Prepare and Execute Technical Architecture Assembly Test Prepare and Execute Performance Test Perform Mock Conversion Prepare and Execute Product Test Prepare and Execute User Acceptance Test Prepare and Execute Performance Test Transition Deployed Application K-MED Figure Our tools and models consistently deliver deployment phase functional, technical, and people- specific recommended practices throughout our implementation 7-209

210 Testing Approach Our testing methodology is based on the industry recognized V Model providing requirements traceability, phase containment between environments and lowering costs of bug discovery in later phases, as detailed in Figure The V-Model requires verification and validation at key points so that issues can be detected and addressed as early as possible in the testing life-cycle. Early detection is critical because discovery and phase containment of errors has proven to have at least a 10:1 multiplier effect on cost and schedule savings. Our robust testing approach includes multiple layers of testing with a focus on defect stage containment. We test at these multiple layers and use test automation and tool support where appropriate. Automation with testing tools simplifies our testing process, especially for a large, complex application such as the K-MED solution. We include regression testing after major builds on a subset of the test scripts. This helps us to verify that a fix does not cause problems in the code and does not affect other related requirements. Regression testing confirms the system continues to operate as expected if there are significant changes or enhancements to the hardware or application architecture. Based on our Accenture Delivery Methods (ADM), we follow our three-pass approach for each of the testing phases. The approach dictates that we execute each test script three times in each test phase. We have the following objectives for each test pass: Pass 1: Execute the test script finding as many defects as possible. Pass 2: Re-execute the entire test script, emphasizing testing of defects fixed in Pass 1. Pass 3: Re-execute the entire test script, emphasizing testing on defects fixed in Pass 2. We should find no further defects in Pass 3. If we identify defects, management determines the appropriate course of action. The Proposer shall describe its approach and commitment to all phases of testing required Plan Analyze Design Build Test Deploy Service Introduction Implementation Goals and Expectations Pilot/Emergency Fix Requirements Traceability Matrix Functional Technical Training User Acceptance Test (UAT) Test Planning Design Configuration Software System and Integration Test Usability Test Unit Test Security Test Performance Test Test Execution Verify Validate Test K-MED Figure Our V-Model testing approach confirms implementation across test phases to validate the software meets the requirements and functions correctly 7-210

211 for a system of this magnitude, including, but not limited to: 1. Maintain the application aspects of online technical environments for system testing, user acceptance testing, training, and production. Our technical architecture team establishes each testing environment and verifies that the infrastructure is properly set up for testing, training and production. This includes testing of the equipment setup and ongoing maintenance on each test environment as shown in Figure Our configuration of test environments permits efficient testing and supports defect stage containment. We build a master test database and use it to refresh each of the test environments before testing. The database contains the data necessary to test the functional, technical, and training requirements. The data set is refreshed before the start of each test phase. We also have the ability to refresh individual test data for testing each scenario. 2. A structured, automated system for identifying, prioritizing, tracking, fixing, and re-testing programs found to have errors or failures; The combination of our Accenture Delivery Tools (ADT) Suite and Accenture Delivery Methodology (ADM) creates a structured and automated system for identifying, prioritizing, tracking, fixing and retesting defects throughout the testing effort. We track software defects in Rational ClearQuest. The defects are traced to requirements, coding activities, peer reviews and tests through ClearQuest. With these features, the entire K-MED project team has visibility into the status of defects and the requirements and functionality that have a higher defect rate. A key element of our quality approach is tracking and reporting test-related metrics. These metrics verify that defects are identified and resolved and requirements are met. Defects are prioritized by the urgency of the required fix. Urgency also determines the order in which defects are resolved. The urgency of the defect is primarily determined by the impact to the test schedule and the severity of the functional impact of the defect, as defined in Figure Unit Test Environment Instance per Functional Area Instance per Functional Area Instance per Functional Area Partial Data Set for Unit Test Test Environment Instance per Functional Area Instance per Functional Area Instance per Functional Area Establish the Environment Implement test tools Configure environment Select/create test data Load data Load applications Integration Test Environment Partial Data Set for Integration System Test Environment Snapshot of Full Database for Cycle and Batch Testing Snapshot of Full Database for Performance and Load Testing Partial Data Set for Testing Time Sensitive Scenarios Partial Data Set for System Test 2 Partial Data Set for System Test 1 Test the Environment Verify infrastructure UAT Environment Partial Data Set for User Acceptance Test Conversion Environment Full Data Set for Conversion Test Maintain the Environment Apply patches/fixes Create backups Problem Solve Regression Test Environment Partial Data Set for Regression Test K-MED Figure Our test environments are configured, tested, and maintained for each stage in the testing lifecycle to allow for efficient testing 7-211

212 Severity Code Severity Value Severity 1 Urgent Defect must be resolved immediately. Impact is the system is not working, or there is a negative impact to a large number of functional areas in testing. 2 High Defect must be resolved. While testing potentially could continue, there is a significant negative impact downstream in a functional area of testing. Work-arounds are available but not sustainable. 3 Medium Attempts should be made to correct this prior to continuing further testing. The workaround is simple with no negative impacts to downstream testing activities. Issues are usually localized within a particular test case. 4 Low Fix defined as being nice to have. Does not impact downstream testing activities. Execution continues with minimal impact to the test. Examples include formatting, or cosmetic defects to user interfaces. Figure By establishing clear guidelines for defect severity, we will be able to make decisions on how to keep the incremental releases on schedule and address KHPA s the requirements 3. Structured promotion of programs to subsequent testing levels; Our test approach entails a structured process to promote applications to subsequent testing levels. We collaborate with the KHPA Testing Team during test planning to establish entry and exit criteria for each phase of testing. Entry criteria are the states and conditions of project outcomes from the previous stage that must be satisfied before beginning the next stage, such as: Required tasks and steps to complete Required deliverables to complete or update, review, and receive sign-off Exit criteria provide control of the project milestone completion. In order to seek to maximize phase containment, is it important that each test phase meets the specific exit criteria, as defined in the test plan, before the next phase can begin. 4. Adequate integration (string) testing of all programs, modules, and sub-systems related with one another; 5. A complete and comprehensive System Test, to allow for the testing of all portions or sections of the application, with multiple programs running concurrently; 6. Testing of pre-defined scenarios that are representative of actual cases; 7. Testing of recovery processes or component outages/failures; 8. Interface Testing; 9. Conversion Testing; 10. User Acceptance Testing; 11. Performance (load/stress) testing; and 12. Batch processing functions. The Contractor must have a plan for involving end-users in System Testing. The test plan must provide for end-users to exercise the entire system, including the use of converted data, in a controlled environment that is completely separate. The Contractor will work with KHPA to provide staff for this process. Throughout the test effort, we use pre-defined test scenarios that are based on actual use cases. Our test approach consists of executing these scenarios during the following types of testing: Unit Test Integration Test System Test 7-212

213 Disaster Recovery Test Interface Test Conversion Test User Acceptance Test/Operational Readiness Test Performance (load/stress) Test Details of our approach for the above types of testing are depicted in subsequent sections Batch Performance impacts a system s capability to process backend business logic and meet batch windows. Automated batch processes, if not started on time and on schedule can have negative impacts on the system s infrastructure. Our batch testing entails the validation of manual processes as well as any automated daily, weekly, monthly and exception reporting processes. We carefully test all batch process in all phases of testing. We test the execution of batch processes independently and associated processes in threads. Our testing strategy for batch processes safeguards the K-MED System from failed batch processing and interrupted batch scheduling in production. The Contractor shall be responsible for providing detailed testing deliverables that include test plans, a testing methodology, test scripts, test conditions, expected results, and actual results. Performance Testing will provide, as a minimum, testing against both anticipated initial go-live and anticipated one year post go-live amounts of data. We apply our testing framework during the initial phases of Design to develop the Test Plan deliverable. We collaborate with the KHPA Test Team during the Test plan development. Figure 7-90 shows a sample Test Plan. We create a thorough Test Plan within each test phase to establish the baseline from which to conduct our tests. In addition to the test plan, we provide other testing deliverables for each phase of testing including test scripts, test conditions, expected and actual results. During performance testing, we provide test results and data from performance tests against initial go-live tests and anticipated one year post go live tests. Resource Availability Accenture Public Service Platform Validated Requirements Test Plan 1.0 Document Control 2.0 Assumptions 3.0 Review and Signoff From Stakeholders 4.0 Scope and Guiding Principles 5.0 Roles and Responsibilities 6.0 Overall Test Approach 6.1 Summary of Techniques 6.2 Testing of K-MED Functionality 6.3 External System Interfaces 6.4 End to End System Tests 7.0 Test Execution Schedule 8.0 Requirements Traceability 9.0 Tools 10.0 Automated Regression Testing 11.0 Configuration of Environments 12.0 Software Acceptance 13.0 Management of Testing and Results 14.0 Approach to Specialty Testing 14.1 Usability 14.2 Security 14.3 Performance K-MED Figure Our comprehensive Test Plan, based on key project artifacts, describes the overall approach to testing the K-MED solution and meeting the KHPA test objectives 7-213

214 The Proposer shall also list and describe any tools used to facilitate the testing process, including Performance Testing. KHPA will not procure testing tools for this project and any testing tools proposed shall be provided by the Contractor and licensed by the Contractor for use by its staff and the applicable State staff for the project at the testing site. The Contractor shall provide any required training on the proposed testing tools to all State staff that will be required to use the proposed testing tools. At the end of the engagement, ownership of the testing tool will be transferred to the State at no cost. The Contractor shall also provide any needed testing infrastructure (desktops, servers, etc.) to support the provided testing tools. At the end of the engagement, ownership of the testing infrastructure will be transferred to state at no cost. We use the Rational Toolset, which is part of Accenture Delivery Tools (ADT) Suite for testing activities. This approach creates repeatable test scripts for use during testing and enables reuse during regression testing. Using established test tools, we tie requirements to test scripts to provide certainty of requirement coverage. This reduces overall technical risk and promotes improved KHPA user buy-in. We provide any needed testing infrastructure and software licenses required to support the Rational Toolset. Software licenses for the testing tools are transferred to KHPA at the end of the engagement at no additional cost to KHPA. Software tools from the Rational Toolset used during testing includes the following: Rational ClearQuest: Tool used to provide defect management, process automation, lifecycle traceability and reporting for better visibility and control of the software development lifecycle Rational Functional Tester: Tool provides testers with automated testing capabilities for functional testing, GUI and data driven testing. Used to create automated regression test scripts. Rational Performance Tester: Performance testing tool used to identify system performance bottlenecks. Our team conducts training on any tools needed by the KHPA Testing Team to prepare for User Acceptance Testing or ad-hoc testing within other test phases. The training provides an overview of the release, how we use the various tools within the Rational Toolset, our K-MED solution test processes, as well as relevant application training prior to testing. As part of the mentoring process, the KHPA Testing Team works with our testing team counterpart during the execution of their test scripts. This approach focuses on providing information and support to KHPA personnel as needed post functional training sessions Unit Testing The Contractor is responsible for providing unit testing. The Unit Testing Plan may include a single web page with related fields (verification of valid values, completeness, accuracy, presence when required, etc.), or a single action (system sign-on, print screen functionality, etc.). Screen copies of individual screens, with appropriate messages when required, data base changes (when data is saved, or updated) will be included for each test case. The Unit Test stage is essential in detecting and correcting any problems early in the development lifecycle. The earlier problems are identified, the easier and quicker they may be fixed. Unit tests focus on the operation of a single program and try to verify that detailed design specifications have been properly translated into code. The conditions for each Unit Test are identified during the detailed design of the program being tested. This checks that the system 7-214

215 functions as designed. Our unit test plan for the solution includes clearly documented and detailed component test conditions and test scripts for web page components or single actions (system sign-on, print functionality, etc...). Throughout unit testing, we document the results of each test, capturing screen prints if necessary, and make them available to the entire KHPA Test Team for review Integration Testing The Contractor must conduct a comprehensive Integration Test in a tightly controlled technical setting. The plan for the test will include, but may not be limited to, a series of web pages with related fields (verification of valid values, completeness, accuracy, presence when required, etc.), or a single action or thread (system sign-on, print screen functionality, complete screening process, etc.). Verification of a thread or process path will be documented to include a screen print of all screens and data base changes which occur as during the completion of a process or test case. Integration testing is conducted to verify the assembled solution components. This includes the testing of assembled single action or threaded use case scenarios and the passage of data between each component. Comprehensive tests for batch processing are conducted as well as the correct display and reading ease of error messages, warnings, and other system messages. Our Integration Test Plan addresses the test approach, test schedule, and required resources. We include details regarding test environments, entry and exit criteria, and integration test metrics. We perform stress, performance, security, and usability testing during Integration Testing System Testing The Contractor must conduct a comprehensive System Test in a technical environment that is an exact replication of the Production environment. The plan for the test will include, but may not be limited to, a series of web pages with related fields (verification of valid values, completeness, accuracy, presence when required, etc.), or a single action or thread (system sign-on, print screen functionality, complete screening process, etc.). Verification of a thread or process path will be documented to include a screen print of all screens and data base changes which occur as during the completion of a process or test case. During system test, we verify the implementation of the software solution s functional specifications are correct as per the business requirements. This test stage focuses on business event-driven system functionality of the software solution consisting of valid, exception, and error conditions. We validate all system components for completeness, accuracy and presence when required. We confirm data elements within components such as web pages are displayed as designed using actual production data or manually created data. We verify system single action processes such as sign-on and print screen. We also conduct extensive tests for required batch processing and validate error messages, warnings, and other system messages display correctly. We will execute system test based on our established test procedures. As illustrated in Figure 7-91, we apply a use case driven approach to system testing, as we do for integration testing. We create our system test conditions and expected results based on our use cases. Throughout system test, we thoroughly document the results of each test and make them available to the entire KHPA Test Team for review. Test results include screen prints and database changes. We coordinate with the KHPA team to engage select end users within the system test phase to exercise the entire system. Training is provided to the select KHPA Testing Team resources 7-215

216 involved in end user system testing. The select team executes system test scenarios in a separate controlled environment utilizing converted data Interfaces Testing The Contractor must conduct comprehensive unit, integration, and system testing of all interfaces. At the system testing level, samples from actual production data must be used, simulating the actual interface process. All interface manual procedures must be formally tested as well. All internal and external interfaces will be tested, verified, and confirmed at both ends with supporting documentation for each interface. Our interface testing consists of a thorough unit, integration and system test of all system internal and external interfaces. We test that the interfaces work properly and meet internal and external specifications. We conduct testing at both ends in accordance with the Interface Control Document (ICD) created during the design phase. We focus on service interoperability across platforms, operating systems, and programming languages. We set up test harnesses to test internal and external services. We use this harness to test that a service is responsive, that inputs and outputs meet expectations, and that we receive failure notices. We begin working proactively with the interface partners early in the software delivery lifecycle. We run input files from the interfacing partners containing actual production data to verify that the interfaces still work as required. We follow these interface testing guidelines: Synchronize data sets with the interface partner Agree on inputs and expected results Run interface tests Log defects found Resolve defects from interface tests Retest to verify that tests are correct We work with the external entities that interface with the K-MED solution to test the data we receive from those entities. The data received is expected to be representative of the transactions that the external entity will forward to the K-MED solution. We also work with external entities to create interface transactions that the recipient will process and return to the sender. We capture all test results from interface testing and make them available to the entire KHPA Testing Team for review Conversion Testing Use Case Model Analysis Model Specified by Use cases based on business processes drive our design, build test bringing KHPA in line with the business solution Realized by Design Model Implemented by Implemented Code Verified by Test Plan The Contractor will be responsible for unit, integration, and system testing of all conversion routines prior to use in Production conversion activities. The Contractor will be responsible for the preparation of a conversion plan, preparation of a conversion test plan, development of K-MED Figure Use cases provide traceability through the system development and testing phases to support the team meeting the objectives of KHPA

217 conversion test criteria, and establishment of the test environment. To ensure a thorough test, the Contractor's conversion approach must include all of the following: Samples from actual case files must be used; Multiple sets of trial conversions must be conducted; Conversion testing must simulate the actual conversion process, including all manual conversion procedures, and must ensure that all subsequent processing cycles operate normally; and System Testing shall include the use of converted data. Testing with production data when possible is important to the success of testing. We do this by taking data from source systems and running the data through the data conversion process. We include samples from actual cases within the data set. Figure 7-92 shows the conversion process and objectives for each test environment. Testing data conversion allows us to test conversion routines and to test the system with real data. We design the data conversion and confirm our conversion activities during system test. We provide a sampling of converted data from the legacy systems. Accurate data is vital for performing detailed data conversion. The Conversion team develops the conversion test plan to outline the testing criteria and activities. The process which we follow to test functions and features of conversion software reduce the potential risk of conversion inaccuracies. We identify inputs, steps, and expected results of the test activities. We use testing tools used by the Testing team. We will work with the KHPA Testing Team to obtain approval for the conversion test plan prior to system test. Once testing begins, we document inputs, outputs, problems identified, corrective action(s) taken and re-test results within the conversion test results report that we deliver at the conclusion of the test activities. We test the K-MED solution components with the testing database in an iterative, release driven manner. We coordinate conversion testing with system testing to confirm that the solution can process transactions successfully with converted data and created data. Source Systems Interface Staged Repositories Load Scripts Conversion Test Test Environments Unit Test Integration Test System Test User Acceptance Test Performance Test ADM Tasks Unit Test Integration Test System Test User Acceptance Test Performance Test Execute component testing and record actual results Actual source system data is used Execute interface testing and record actual results Identify and resolve data cleansing and performance issues Execute interface testing and record actual results Identify and resolve data cleansing and performance issues Load converted data into UAT environment Identify issues with application converted data Test full production replica for performance and load testing and record actual results Resolve data integrity issues K-MED Figure We include multiple test phases to maximize data review time and reduce the number of data issues in the final conversion 7-217

218 User Acceptance Testing (UAT) UAT is designed to demonstrate that the system meets Kansas specifications and performs all processes correctly. This shall include operational readiness and on-going testing for maintenance, modifications, and enhancements, regardless of the number and complexity of the modifications. All system functions and interfaces shall be tested with fully converted data. Components of the test shall require that the Contractor demonstrate readiness to perform all Contractor system functions and contractual requirements, including manual processes. The State shall identify the schedule for test cycles and delivery of output. User Acceptance Testing shall be conducted in a controlled and stable environment. No modifications to the software or files in the UAT library shall be made without written prior approval from the State. User Acceptance Test (UAT) follows Unit/Integration/System Testing and enables the KHPA Test Team to formally verify specified capabilities were properly designed and implemented. UAT allows a final review of the system prior to Pilot. Our UAT test plan consists of Structured Data, Operational Readiness and Disaster Recovery Testing with fully coverted data. We work with identified users as these tests are performed on the system during UAT. We manage and maintain overall responsibility for UAT. In addition, we coordinate the creation and execution of test scripts and assist during execution of batch and interface jobs. We support the K-MED solution UAT process using our approach for the project as depicted in Figure Together, we develop a UAT plan and conduct incremental reviews that involve our team and the KHPA UAT Testing Team. The UAT plan incorporates feedback, addresses concerns and includes proposed UAT tests, tools, necessary environments, and a proposed test schedule. We provide weekly status reports on UAT progress. We provide transparency throughout testing and the other phases of the project. Status reports are reviewed together at agreed upon times during UAT and each report will summarize the UAT tests and results identifying deficiencies found, corrected, and outstanding. Each status report includes a detailed deficiency report with root cause analysis and our proposed corrective action. We manage the UAT test results and perform fixes on deficiencies identified. Defects found will be logged in Rational ClearQuest and we will follow project standards regarding prioritization and resolution. Together, we prioritize fixes to identify those requiring a turn- UAT Base Plan Draft Incremental Reviews Draft UAT Plan Draft UAT Plan Draft UAT Plan Draft UAT Plan Review by User Acceptance Test Lead Peer and Executive Reviews Review by Test Management Lead and KHPA SMEs Final Comments Responses to Comments Approval by KHPA UAT Plan Updates Approval by KHPA KHPA Quality Review K-MED Figure Our User Acceptance Test Plan is developed collaboratively with KHPA to confirm we provide adequate support during this testing phase 7-218

219 around within two business days to keep UAT on schedule and allow users to successfully complete UAT. The KHPA team can access Rational ClearQuest on-demand to monitor and retest defects once fixed. Defects found during UAT are prioritized to enable KHPA to systematically and proactively determine what changes are necessary prior to pilot as well as prior to release deployment. KHPA requires three types of User Acceptance Testing: 1. Structured Data Test. This test is designed to ensure that the system data structure design is consistent. Individual and case data are stored correctly and referential integrity is enforced. This test will ensure that all data elements captured on a screen or derived by the system are consistent and stored correctly throughout the life of a case. This test must be performed at the data level in terms of following: Medicaid Case Structures are correctly created and all Medicaid case related data (entity, attribute, and their relationship) values are captured and stored correctly. All data related to individuals are captured and stored correctly. Individuals participating in one or more cases are correctly associated with respective Medicaid cases. All history information (effective dated records, version history, and span history) are correctly created and stored with audit information. All history records must be associated with base data In case of de-normalized attributes for performance and reporting, it must be consistent in value with the base data. Default values for data attributes are set correctly per business rule. Structured Data Testing Our Structured Data Testing consists of validating the consistency and integrity of data against requirements. We verify that all data elements captured on a screen or derived by the system are stable and stored correctly throughout the life of a case. We perform a thorough analysis on the data and focus on the following key KHPA specific areas: Medicaid case data can be created, stored and referenced via the K-MED System according to requirements. Individual related case data can be created, stored and referenced via the K-MED System according to requirements Individuals linked to one or more cases can be created, stored, referenced and possess the correct association via the K-MED System according to requirements. Historical data can be created, stored, referenced and possess the correct base data association within the K-MED System according to requirements. Defaults values are displayed on K-MED System web pages according to requirements. KHPA requires three types of User Acceptance Testing: 2. Operational Readiness Test. This test is designed to ensure that the State, the Contractor, and the new K-MED System are ready to process all inputs, determine eligibility, and distribute correct benefits; that they meet all reporting requirements, utilize a properly functioning data communications network, and have a demonstrated back-up capacity. It shall include a full volume test, as defined by KHPA, of production capacity cases to demonstrate that the K-MED System and the State and Contactor s staff are prepared for full production. In addition, a pilot test of actual cases processing in a full operational environment, from application intake, through eligibility determination, benefit authorization, benefit distribution and the sending of notices, including all reporting functions, shall be conducted. A demonstration and verification of physical security, data security, user profiles, and overall system security is 7-219

220 also required. The Contractor shall allocate a minimum of six weeks in the Detailed Project Schedule to execute Operation Readiness Testing. Operational Readiness Testing The Operational Readiness Test (ORT) verifies the production environment s ability to handle the new system. Our field tested ORT testing approach consists of verifying 3 areas: Verifying that the correct functional architecture and procedures are defined and implemented to allow production support teams to run, maintain, and support the system. Verifying that system components can correctly deploy to the production environment in the time required. Verifying that the system is correctly installed and configured in the production environment. We include a full volume test. We demonstrate and verify the physical security, data security, user profiles, and overall system security. We allocate a minimum of six weeks in the project plan for Operational Readiness Test execution. KHPA requires three types of User Acceptance Testing: 3. Disaster Recovery Test. This test is designed to ensure that, in the event of a manmade or natural disaster, the Contractor can have the system available in the disaster recovery location within the prescribed time and with no loss of data. Disaster Recovery Testing We go beyond data recovery and consider the bigger picture of KHPA s business resumption in case of catastrophic failure. By conducting high availability and fail-over scenario testing, we will meet your requirements related to providing reliable business continuity and disaster recovery to KHPA s K-MED solution. We include test scenarios covering fail-over, recovery and back-up/restore capabilities during Integration Test. Testing these requirements demonstrate that the K-MED solution continues to provide services even if business is interrupted. Our database replicates data throughout the day. Business continuity testing lowers the risk of any disruption to K-MED operations Performance / Stress Testing The Contractor will be responsible for developing a series of performance tests to demonstrate that the K--MED System meets all performance requirements. Performance Testing shall include all local office and central office functions and shall include stress testing of appropriate batch processes as well. The Contractor will be responsible for carrying out two distinct performance tests in order to verify system performance against requirements. The Contractor shall suggest the timing of those tests and they are to be executed in a manner that would be most advantageous to KHPA should deficiencies be detected that require strategic redirection. In no event will pilot implementation occur unless successful Performance Testing has been carried out. In the event that Performance Testing is unsuccessful, or if the test results indicate that the K-MED System performance requirements may not be met as the converted caseload increases, the Contractor will be responsible for beginning corrective action(s) no later than five (5) workdays after notification from KHPA. The Contractor will be responsible for corrective action at no additional cost to the State. Following any corrective action, the Contractor is responsible for completing all Performance Testing. If K-MED operates on multiple tiers, then Performance Testing shall be appropriately designed to test each tier of processing. The 7-220

221 Contractor must provide to KHPA complete analysis of network traffic generated during all relevant tests. KHPA reserves the right to perform independent Performance Testing of the K-MED System at any time. The Contractor must use its best efforts to cooperate with KHPA or its designee, and provide data and technical support as requested for Performance Testing. Performance testing is an iterative process that examines and enhances the K-MED solution s performance. We test that the application complies with its performance requirements and effectively supports the required number of users and planned data volumes. Performance testing stresses the new system s capacity to add data, users, and user activity. A full stress test is performed to demonstrate that the system can handle the required response times and estimated capacity thresholds. We base the performance test on performance requirements as specified by KHPA. We integrate KHPA local and central office functions within the performance testing plan. Figure 7-94 shows that we conduct performance testing with converted data throughout the software development lifecycle. This allows us to identify and eliminate performance bottlenecks from design through pilot implementation. Performance testing consists of three unique testing cycles: Load testing: subjects a server to load conditions that will be realized in live production environment Capacity testing: determines the estimated maximum number of concurrent users the application can manage Stress testing: validates the application s upper thresholds, stability and reliability over time If performance test results do not meet specified requirements, we immediately perform a root cause analysis and determine the recommended corrective action. A root cause analysis entails a careful investigation of the technical and application infrastructure to determine where performance is slowed. Our analysis begins no later than 5 working days after notification from the KHPA Team. The process of analyzing the problem and recommending a solution is performed at no additional cost to KHPA. Performance Testing Design Development System Test User Acceptance Test Review Design for Performance Considerations Review Code Impact to batch window for Performance Tables accessed Efficient design Considerations Follows performance standards Review complex joins Transaction volumes and database size Baseline server requirements Well defined test scenarios Network infrastructure Conduct Performance Test Review, database access paths Perform stress tests Perform load tests Endurance test Batch test Correspondence test Network throughput Conduct Benchmark Test Verify performance targets Apply Performance Code Fixes Pilot Monitor Production Performance Tune application as necessary Project impact of growth Monitor impact of other systems on solution Tune Solution K-MED Figure Performance Testing is analyzed throughout all phases of the application development lifecycle to confirm that performance requirements are met 7-221

222 Throughout performance testing, we cooperate with KHPA to assist with any ad-hoc testing required. We provide visibility to all test results and network traffic information from our performance testing Software and Revisions (Patches and Fixes) Our efficient COTS revision and patch application and testing process reduces support effort and risk This section applies only to a proposed solution involving a COTS product. If a State transfer system is proposed, then the Proposer shall Our successfully demonstrated approach will provide comprehensive, collaborative and transparent testing of the K-MED System Our process was successfully integrated and used at other State implementations. Process Integrates well with the project schedule dictated by our Accenture Methodology Process applies patches during the project lifecycle when they are most critical, while causing minimal disruption to the project. simply indicate that fact in a one sentence response to this section, unless the State transfer system relies on some COTS components. In that case, the Proposer shall respond regarding these components. In the course of conducting the K-MED Project, the State expects that a COTS Software Provider will release revisions (i.e., patches and fixes) to the software being implemented for a variety of reasons, including, but not limited to, correcting errors and bugs detected in the proposed software, to extend or enhance capabilities that have been requested by users, and/or regulatory updates. Because of the anticipated length of the K-MED Project, it is likely that such revisions may resolve issues encountered during the development and testing phases of the project and thus need to be applied during the project. The application of revisions may also be required by a COTS Software Provider in order to be able to provide support for certain functionality that has been modified by the revision. However, it is difficult to continuously apply all revisions upon their release throughout the project because of the nature of their release schedule, the potential for disruption of project activities by their application, and the likely need for retesting and rework to accommodate their effects. Given this situation, the Proposer shall describe the recommended strategy and approach for the application of COTS software revisions during the project lifecycle, including a specific discussion of what revisions (categorized and explained as to their general subject, level of complexity, potential impact, and associated strategy) are likely to be released during the duration of the project based on the software proposed, and how the releases will be monitored and candidates identified and evaluated for application during the project. If, for any reason, the recommended strategy includes delaying application of certain categories of revisions based on the project phase in which they are released until after go-live, an explicit strategy for how these revisions would be addressed in the post-implementation support period, and how the expected impacts can be mitigated, shall be provided, based on the Proposer s experience in previous projects. The scope of the approach to the revisions discussed should not be limited to only that software provided by the COTS Software Provider, but also include any other recommended / anticipated required elements of the software "stack used to support the scope of the software implementation requested in this RFP. Our proposed solution is a hybrid licensed COTS solution and transfer system based on Accenture s Public Service Platform (APSP) and the eligibility functionality developed for the C-IV system. The COTS products must be periodically updated in order to stay on a supported version and take advantage of the latest security and functional enhancements. Our proposed 7-222

223 solution contemplates an ongoing maintenance fee that incorporates patches and fixes for integrated COTS software. We will implement a software update strategy to provide fixes and maintenance for software including third party vendor software. We will maintain revisions and apply patches COTS software as part of our maintenance fee. Our COTS software update strategy includes: Monitoring the vendor channels for critical updates (i.e. security updates), and apply them as deemed necessary. Apply version updates on COTS products and other critical security updates and patches that directly affect functionality used by the State The overriding principle is If it s not broken, don t fix it. Patches should be tested and applied if they are fixing a problem we are directly experiencing, or fixing a critical security issue. This strategy will help KHPA maintain supported versions of its software without causing instability or disruption to the project. Any costs associated with this activity that the Proposer wishes to include in the separate Cost Proposal shall be identified and included in Cost Schedule 7 Other Implementation Costs (see RFP Section ). Please refer to Cost Schedules. Also, the State requires confirmation that the proposed approach to software revisions has been successfully used elsewhere in previous projects. The Proposer shall provide a client reference contact name, title, organization, and telephone number. This contact cannot be an employee of the Proposer or any of its proposed subcontractors. Accenture has implemented this software in partnership with our client at the Idaho Department of Health and Welfare. The Department selected C-IV, a transfer system that Accenture built for the C-IV Consortium. Once C-IV was selected the Department decided to seek a sole source contract with Accenture to provide functional and technical assistance related to the transfer of the system to Idaho. The Department chose to own the risk and responsibility for delivering the system and strategically use Accenture resources to support that effort. Accenture worked with the project team to come up with an innovative approach that would facilitate system implementation within 18 months. We have included references from both the Idaho client and our C-IV client in our reference section. Below is a brief overview of our work from our Idaho client. Accenture provided resources with extensive eligibility system implementation experience combined with functional and technical knowledge of the C-IV system. They provided the right resources at the right time. Accenture has been a true partner in our effort to implement C-IV and it is clear they are invested in our success. While the Department owns the responsibility for implementing the system, Accenture has made available their extensive resources from across their company to support us in this effort. We spoke to a number of System Integrators and product sales people over the course of our search for the right system and Accenture was the most willing to help us think outside the box and find a solution that could meet our functional needs and our budget. They understand the challenges facing small and medium sized States and have been willing to innovate and adapt to meet our needs. Greg Kunz is the contact and his information is listed below

224 Idaho Department of Health and Welfare Greg Kunz, Deputy Administrator Deputy Administrator and Project Sponsor (208) Training Services Our experienced Training Team subject matter experts work with you to develop a comprehensive approach to training K-MED users at all levels. We have a proven track record of working with public sector clients like KHPA to deliver effective training at the right time. Our Training Services, in conjunction with Enterprise Readiness, Documentation Services, and User Support Services, equip and support K-MED users throughout the implementation process and beyond. Training Approach Our training approach equips K-MED users with the knowledge, skills and abilities needed to work with the new system and processes effectively Uses a blend of varied learning methods and styles Hands-on learning provides training that is relevant and meaningful Evaluates training and builds in continuous improvement Provides incremental learning to build confidence and facilitate retention The Contractor is required to provide training to system users at all levels in order to achieve a successful implementation and transition to K-MED. Our training approach for K-MED draws upon our experience preparing users for successful transitions to new processes and technology. Our approach is to deliver effective training that also fits the scope of change K-MED users are experiencing as part of the overall K-MED implementation. We approach training in the following way: Training is part of a larger user-readiness approach We maintain that training does not begin or end in the classroom, regardless of topic. K-MED users experience a range of readiness, training and user support initiatives that enables them to move through the change journey effectively. Readiness initiatives present business process change content so that users can absorb and act on the role changes and job changes in their areas. Training teaches them the skills to do their work in K-MED, and user support initiatives sustain them as they begin to reap the benefits of the K-MED implementation. Learners must understand how their jobs are affected To learn how to use K-MED effectively, we develop Change Discussion Guides and other tools to help staff must understand changes to their jobs and the everyday tasks required to complete them. Training is hands on and interactive Both instructor-led training (ILT) and web-based training (WBT) include exercises and interactivity that maintain interest and reinforce training concepts. Adults learn in a variety of ways After training, users practice training scenarios in a sandbox training region that mirrors the real world. This enables learners to interact with the system in a risk-free environment that looks and feels like production K-MED. The 7-224

225 sandbox offers users another practical way to learn by doing and to reinforce the skills they learned in training. Our best practices have shown that training and operation manuals become a primary tool for system users as they learn the system initially, but also as a point of reference for complex or difficult situations they encounter months or even years after initial training. Since hard copy materials are difficult to update and become quickly outdated, we take full advantage of electronic materials and training guides, teaching users to use the most current material available as their reference. Hard copy materials are kept to a minimum and typically only involve supporting training exercise scenario material that again refer users to the accurate and current online manuals during training. The starting point for developing an effective program for K-MED training is identifying KHPA stakeholder groups at all levels. After contract award, our Training Team would work in conjunction with the KHPA and Accenture Enterprise Readiness (ER) Team members and KHPA subject matter experts to document user groups who will be impacted by the K-MED implementation and assess the specific impacts that K-MED will have on each one. Once we document the user groups, the Training Team maps them to the K-MED functions they need to master in order to be successful in their jobs. The analysis conducted during these activities enables the team to customize training to meet the unique requirements of staff at all levels. Our phased training approach delivers learning content with the appropriate training delivery method, tailored for each group. Figure 7-95 depicts our phased approach to training, assessment and reinforcement through the practice environment. During Stage 1, users attend Readiness Workshops that focus on explaining upcoming business process and job changes. Understanding process and job changes in advance helps alleviate users concerns about the K-MED implementation and increases preparedness. The workshops also introduce key elements of K- MED system functionality, providing a preview for staff in advance of Stage 2 training. Stage 2 Training focuses on helping each user develop functional skills in his or her specialized area. Staff take role-specific WBT courses to learn the functional skills necessary to perform their jobs using the K-MED system. Stage 3 Training focuses on the workers who will use K-MED to perform eligibility tasks and select Central Office personnel who need to learn specialized skills. Each eligibility worker receives 16 hours of instructor-led training in addition to applicable WBT courses. The training follows the model that Accenture used in Idaho where the agency experienced a smooth and highly successful implementation. For small numbers of specialized staff such as Central Office, we deliver Small Group Walkthroughs. Walkthough Training is face-to face training conducted in an informal setting by Accenture team functional experts. Walkthrough training takes place in the Sandbox environment so that the participants have freedom to enter a variety of scenarios. An example of a walkthrough is Rules Engine Maintenance. Stage 4 Training consists of post-implementation Targeted Topic Training. Onsite support Competency Assessment Stage 1 Readiness Workshops Stage 2 Role-Based WBT Stage 3 Role-Based ILT Stage 4 Targeted Topic Training Practice in Sandbox Environment K-MED Figure Our phased approach to K-MED Training will help provide staff with the skills necessary to use the new system and business processes 7-225

226 staff conduct these ad hoc sessions when they identify a particular issue that users are experiencing in the field after deployment. This approach is highly flexible and responsive, because the support staff are already there onsite, ready to assist K-MED users. Beginning just after the initiation of instructor-led training throughout the onsite support period, users have access to the training sandbox environment. The sandbox provides a useful way to reinforce skills after users return to their offices. The sandbox is less structured than the classroom training database because it contains converted production data that enables users to practice their own real life scenarios. For example, an SRS eligibility worker attends the Eligibility in K-MED course where she learns K-MED functionality using carefully planned training scenarios that demonstrate specific outcomes. After training, she goes back to her desk and logs onto the sandbox environment where she enters a case similar to one from her own caseload. This experience reinforces the skills she learned in training and strengthens her readiness for K-MED implementation. Training Components The training component includes development of training materials as well as presentation and course work. Training evaluation is also included. Training shall provide instruction in the proper use of the K-MED System and the procedures for using the system to perform job responsibilities. Materials and sessions are job-specific. KHPA or other contractors provide program and policy training. Accenture provides the analysis, design, development, delivery and evaluation of K-MED training. Training focuses on how to use the K-MED system to perform job duties. WBT modules and instructor-led courses are job-specific. KHPA provides program and policy training and may also participate in K-MED system training. The amount of program and policy content needed for training will be determined during the training design phase. Assessing and evaluating trainers and end users is an ongoing process to improve training rather than a one-time event. Our proposed evaluation and assessment approach is based on components of the widely accepted Kirkpatrick Model. This model identifies four levels at which to evaluate learning. We apply the first two levels, Reaction and Learning, to the end users. We apply Levels 1, 2, and 3, (Reaction, Learning and Transfer) to the State project team trainers. Level 4 documents results and measures the success of K-MED training on preparing users for their jobs after implementation. We conduct evaluations at the completion of training delivery to answer the following questions: Did the participant complete the required training? Can the participant perform the skills identified? Does the participant know which support tools are available and can the participant effectively use those support tools? Can the participant appropriately apply the skills they learned? We analyze the evaluation results and work with you to identify and implement corrective action. We share the results of evaluations with KHPA s training organization so that the collective team continues to improve the delivery of training for the future. Users from all organizations must be proficient in using the K-MED System in order to ensure effective and efficient service delivery. The Contractor shall provide training services in order to ensure this outcome is realized

227 Our training approach and implementation methods, demonstrated to be effective with other similar agencies, address the needs of each organization. If awarded the K-MED System contract, we will provide training services, including competency assessments throughout, to confirm mastery of training content. Training Methods The training program will utilize a variety of delivery methods to best meet the training objectives. Examples include computer-based training, classroom lectures, written material, and demonstrations. It is particularly important to provide practical sessions to Eligibility Staff responsible for making medical determinations, regardless of where the user is located in the state. After contract award, we would work with you to confirm the training curriculum, which includes a variety of delivery methods including: On-line demonstrations Instructor-led training, including written material Web-based training Target training for specialized groups Training sandbox environment to support users after training Our training approach and methodology includes several training methods and tools to present content in different ways to address different learning needs. On-line demonstrations Training tools for customer-facing functionality that are presented in an easy to understand format Instructor-Led Training (ILT) Onsite or offsite classroom-based training by an instructor using a presentation, training database, and online help/documentation. End users gain knowledge about the system and the associated business processes. Web-based Training (WBT) Self-paced, interactive learning completed at any time and at the user s own pace. Job Aids Documents that provide step-by-step instructions to complete processes in the system. In our experience at previous states, job aids are a critical support tool that helps users complete their day-to-day jobs. Users access Online Help and Job Aids directly from the K-MED System. Target Training Ad hoc sessions conducted by onsite support staff who respond to a particular issue that users are experiencing in the field after deployment Training Sandbox A copy of the training environment, which provides a risk free production-like environment to practice scenarios at any time after training. Our training program places particular emphasis on KHPA staff who make eligibility determinations statewide. Eligibility workers receive 16 hours of instructor-led training, as well as access to web-based training modules and demonstrations. We address the needs of a geographically dispersed group of Eligibility Staff by: Establishing a - network of change agents, one per location, who provide communication, readiness and training support for users statewide Providing instructor-led training in regions, reducing travel time and disruption Developing easily-accessible Online demonstrations Providing a Sandbox environment to be used after instructor-led training at the users desktops to reinforce concepts and provide an opportunity to practice realistic scenarios

228 Making On-line help and system documentation available directly from the system Required Training Sessions and Modules KHPA has identified the following training modules / sessions which must be provided by the Contractor. Unless specified as required face-to-face delivery, the Vendor will propose the most appropriate training delivery method for the session. The Proposer is encouraged to propose additional sessions that will be necessary to meet the training needs of KHPA 1. Develop and maintain training, tutorials, and demonstrations online throughout the life of the contract. 2. Provide face-to-face instruction to Presumptive Eligibility Entity staff and necessary Central Office staff prior to the implementation of Phase 1. These sessions will take place off-site. 3. Provide training to all Eligibility Staff to use the Online Intake Application. 4. Provide train-the-trainer sessions to a small group of KHPA staff who will be responsible for implementing additional Presumptive Eligibility entities and training community partners to use the online application. 5. Provide pre-implementation training to designated project staff as determined necessary based on the proposal. KHPA recognizes that in some instances it may need to facilitate or conduct some of these sessions, depending on the content. An example of preimplementation training would be that if the Proposer proposes a COTS package or a state transfer system, then each functional project team member will need to be trained on the baseline version of that software at the beginning of the project prior to any analysis, design, or configuration activities. 6. Provide face to face implementation and conversion training at all locations where Eligibility Workers are present. This will include SRS offices, the Clearinghouse, Health Departments, and Central Office. These events shall be conducted as close to go-live as possible. Specifically, these sessions shall include the following: a. Classroom instruction for all users is required. These may be conducted at regional locations and do not have to take place at the employee s work location. The general sessions shall include instruction for implementation/conversion and ongoing use of the system. These sessions shall include material specific to the current work-arounds that are used to assist in the business processes. b. KHPA will be responsible for any policy or procedural change training being implemented at the same time and may wish to co-present at these sessions with the Contractor. c. Following classroom instruction, individual assistance will be available at the work location of the employee. Contractor staff will be available to assist with conversion issues and use of the new system. Much of this assistance is expected to be one-on-one, but the Contractor may also conduct small group sessions or other effective ways to handle questions and issues that arise. d. The Contractor must offer additional training to ensure all functionality is adequately covered. This will be especially critical if some features are implemented at different time intervals. KHPA may require face-to-face training if necessary. 7. Provide train-the-trainer sessions for KHPA and other contractor staff who will assume the responsibility for training new K-MED System users (e.g., supervisors). 8. Provide specialized training for Central Office / Administrative Roles (e.g., System Administrator, Rules Engine, etc). If we are selected as your K-MED System contractor, we will provide the specified training modules/sessions, and develop, deliver, and maintain our proposed training services over the life of our contract. We outline our approach to the specified training modules/sessions in Figure 7-96 below

229 Audience/Role Content Method Timing/Length Location Pilot We train Pilot audiences using Phase I training materials and content. We use pilot training results to adjust training prior to conducting Phase I training. KHPA Trainers participate in Train the Trainer prior to system pilot. Phase 1 Clients Presumptive Eligibility Entity staff plus Necessary Central Office staff Eligibility Staff Phase 2 Eligibility Workers (SRS Offices, Clearinghouse, Health Departments, Central Office) KHPA/Contractor staff Central Office/Administrative staff Eligibility Workers Other Accenture Team Staff (conducted by KHPA) User Acceptance Testers Self-Assessment and Online Intake Application PE Tool Online Intake Application System Functionality and workarounds; Policy/procedures (KHPA presenters) System Functionality Specialized Training (System Administrator, Rules Engine, etc.) Varied according to support needs KHPA policy and KHPA existing systems System Functionality Online Demonstration Instructor-led/ Demonstrations Web-based Training Instructor-led plus applicable Web-based training courses Train the Trainer Small Group Walkthrough or WBT Target Training sessions Small Group Walkthrough Small Group Walkthrough or Webinar Prior to Phase 1 and Ongoing Prior to Phase 1 Prior to Phase 1 Prior to Phase 2 Prior to Phase 2 Prior to Phase 2 Postimplementation Project Initiation Prior to UAT APSP Self-Service portal Central Training Facility Desktop or lab setting Regional Training Sites and/or Desktop Central Training Facility Central Training Facility/Desktop Eligibility locations Project Site Project Site and distributed locations where testers are located Figure Our training curriculum fully prepares eligibility staff, while also providing effective targeted training for other K-MED users. Preliminary training modules The following are examples of courses we anticipate as applicable for the K-MED project. If we are selected as the State s contractor, we will work with you after audience analysis to define the curriculum and map the appropriate users to the courses. Customer Self Assessment (On-line Demo) Online Intake Application for Customers and Community Partners (On-line Demo) Online Intake Application (Web-based Training) K-MED System Navigation (Web-based Training) Presumptive Eligibility (Instructor-led Training) Eligibility in K-MED (Instructor-led Training) 7-229

230 K-MED for Clerical Roles (Web-based Training) Hearings and Appeals (Web-based Training) Office Administration (Web-based Training) Security Rights Administration (Web-based Training) Cost Avoidance and Recovery (Web-based Training) Calendaring (Web-based Training) Administrative Tools (Web-based Training) Data Synchronization in K-MED (WBT) Workload Reassignment (Web-based Training) Quality Assurance (Web-based Training) Rules Engine Maintenance (Small Group Walkthrough) Reporting for Central Office (Small Group Walkthrough) Eligibility for PMDD (Small Group Walkthrough for PMDD conducted via webinar) Each proposal shall provide detailed information regarding the Proposer s training strategy, plan, and approach. The Accenture team works closely with KHPA to design and develop the end user training curriculum, tools, job aids and other support materials. Our training is relevant to K-MED users jobs and facilitates understanding of their changed roles. Our approach is to use courses that were effective on the Idaho IBES and California C-IV projects as a starting point for developing K-MED courses. We developed these courses using our training methodology, which is part of the Accenture Delivery Methods (ADM). Our approach, coupled with the intuitive nature of the APSP application, streamlines training and creates less disruption to workers jobs. For example, we successfully developed a practical, focused training curriculum for the Idaho IBES project team that resulted in Idaho personnel moving from classroom training to successful execution of practice scenarios in the training sandbox within one day. Figure 7-97 includes the features and benefits of our training strategy and approach. Approach Training is conducted using realistic data Workers have access to a sandbox environment from their desks Supervisors and Managers are trained first Benefits Workers see data in the classroom and sandbox training environments that reflects conditions they will see on the first day of implementation Provides a risk-free way to practice real life scenarios on production-like data, which reinforces skills learned in training and prepares users for implementation Supervisors can answer worker questions on the new automated system as well as the training experience Training becomes more effective, shortening the overall learning timeframe Training is more portable to the end users which makes the training easier to deliver and maintain Training improvement are made quickly and on an Training design reflects business process and role changes Approach includes web-based training and webinar delivery methods Course and instructor evaluations are completed for every training ongoing basis throughout implementation Targeted topic training Provides specific training targeted to postimplementation needs Figure K-MED Training features demonstrated training development and delivery methods designed with the user in mind 7-230

231 Training Development Process Figure 7-98 depicts our training methodology. Training Team members use approved training designs to develop and test the classroom materials, WBT content, training environment, and user support tools. Analyze Within this phase, the training team determines training needs for each audience affected by the new business processes. When conducting a needs analysis, the team identifies roles and their corresponding tasks/responsibilities, which then drive the required skills, training needs and training schedule for that role. At the end of the Analyze Phase, the Training team develops the Training Plan that includes the key elements of the training program, as well as course outlines for each WBT and Instructor-led Training course. Design During the Design Phase, the training team works with KHPA Subject Matter experts, KHPA Training Team members and leadership, and the K-MED functional teams to determine the overall look and feel for the instructional content and online help. The team builds on the outlines for each course identified in the training plan, identifying specific exercises that illuminate and reinforce the course objectives most effectively. From experience on similar projects, such as the Idaho IBES implementation, the Accenture team recommends the following practices for the design phase: The training and functional teams work closely together to validate that all content required by State users to do their daily jobs is included in the course outlines The team uses existing course templates and reference material from other successful projects to minimize design efforts The team builds upon standards already developed by Accenture for training documentation Build During this phase, the training team develops K-MED-specific training materials, online help, job aids, WBTs, exercises, a training environment and training sandbox based on the approved designs. Our current approach is to use Adobe Captivate to develop web-based content in order to facilitate reuse of existing WBT material. However, we understand that the State is pleased with its current authoring tool Lectora. Our team is experienced with a variety of training technologies and will work with you after project initiation to confirm the training development tool. The training team will use baseline material from C-IV plus project deliverables (standards, templates, etc.) as a starting point for K-MED training materials and online procedures. The Build phase requires coordination with multiple teams. For example, we work with the technical teams to create the training environments, establish the procedures for moving converted data into the sandbox, and establishing technical support plans for WBTs and online customer demonstrations. After completing development of training and online help content, team members thoroughly test the content, conducting run-throughs of training sessions to confirm the training data supports the scenarios. The team also prepares the logistics and completes the administrative functions for end user training delivery, including preparing the Central Training Lab and confirming with regional representatives that the regional training sites are ready to go. From experience on similar projects, the Accenture team recommends the following practices: 7-231

232 Analyze Design Build Deploy Post- Implementation Map Training to Users Design Training Develop Training Materials Test Training Materials Deliver Phased Training Targeted Topic Training Performance Feedback Training Evaluation Reports Conduct Training Needs Analysis Map training to audiences Develop Training Plan Create course outlines with prerequisites for each course and walkthrough Design instructor-led materials Design WBT and demonstrations Design job aids Design online help Develop instructor-led training Develop and test WBT courses and demonstrations Identify scenarios and training data needed Build and test training database for instructor-led training Build and test sandbox environment Develop course evaluations Develop online help content and job aids Prepare training labs Administer training registration Conduct Train the Trainer Conduct pilot training within Train the Trainer Deploy WBT Conduct instructor-led training Conduct small group walkthroughs Evaluate training Conduct small group (target) sessions in support locations Complete knowledge transfer and turnover activities to KHPA K-MED Figure Training Development Our approach continues to provide benefits, even after formal training is complete Use delivered WBTs and Instructor-led materials from Idaho and California as the starting point to minimize development efforts State subject matter experts (SMEs) and functional experts review and help test all training materials to validate the accuracy and usefulness of the training materials The training team does not rely on functional team members to be training experts. The training team takes responsibility of determining how the material should be organized and delivered. Deploy During this phase, the training team delivers the following: Pilot training serves as a final walkthrough of the training materials with State subject matter experts and functional experts before training delivery begins. This training captures any last minute edits. During training for User Acceptance Testing, the team will identify additional refinements. Train the trainer (TTT) begins with finding ways for KHPA trainers to be involved in day-to-day training development activities. Our experience in past projects demonstrates that this is the most effective way for the State to gain an in-depth understanding of training and functional content, while minimizing disruption closer to implementation. Formal Train the Trainer sessions are then more like walkthroughs or practices/pilots of the course, which further benefits the project and KHPA trainers. The State trainers have multiple opportunities to practice each course and teach back the course to the Accenture and State training developers before the training delivery begins. Trainers complete their training experience by conducting actual end user training classes during training deployment. Instructor-led training and small group walkthroughs begin shortly after Train the Trainer completes. Just-in-time training enables K-MED users to develop knowledge and skills applicable to their jobs and confirms that the proper employees receive the right skills 7-232

233 at the right time. End user training occurs either at the project site or in regional training facilities. Web-based Training and online demonstrations become available for use during this phase. Also during deployment, users who have been involved in project activities such as user acceptance testing and who have more knowledge and skills than new users serve an informal coaches or super users for their peers. These early adopters often become a natural source of support and enthusiasm for the new system. During and after training deployment, the team completes the following activities: Assess and evaluate the trainers and end users on an ongoing process Administer evaluations during training Analyze the results of evaluations to identify and implement timely corrective action when training does not achieve the expected results Post-Implementation During this phase, Regional Support Teams provide onsite assistance to K-MED users and pull together Target Training sessions on topics they identify as problematic for users Training Plan As shown in Figure 7-99, the K-MED System Training Plan details activities for training staff at all State locations in the proper use of the K-MED System. Although the State s requirement is for the Contractor to submit the System Training Plan to KHPA one month prior to the first training session, we propose to create the Training Plan earlier in the project timeline to allow time for collaboration with KHPA. Developing the plan early leaves ample time to design and develop all the training materials based on the approaches approved in the Training Plan. If we are selected as the Contractor, we will submit annual updates to the training plan at least 60 days prior to the beginning of the contract year Training Requirements The Contractor shall provide a training facility as defined in RFP Section Our Topeka Project Site includes a training facility that meets the State s requirements as defined in RFP Section Please see Section Training Lab, which includes our proposal for the centralized Training Lab. Our approach also includes conducting Instructor-led Training in regional training facilities. There is one training facility per region. The central training lab in the Topeka project site serves as the K-MED Training Plan Table of Contents 1.0 Training Strategy/Approach 1.1 Methods 1.2 Materials 1.3 Training Audiences 1.4 Timing 2.0 Training Team Organization and Staffing 3.0 Training Work Plan 3.1 Planning 3.2 Design 3.3 Implementation 4.0 Training Curriculum 4.1 Training course outlines 4.2 Remedial training 4.3 Ongoing training New staff Changing positions K-MED changes/enhancements Staff with less than six months experience Ad hoc training 5.0 Train the Trainer Approach 6.0 Training Facilities 6.1 Training/student ratio 6.2 Student/training workstation ratio 6.3 of training facilitates 6.4 Reference libraries 7.0 Training Schedule 8.0 Training Evaluation 9.0 Review and Signoff of Training Materials K-MED Figure The K-MED Training Plan defines an effective curriculum that is timely and minimizes disruption 7-233

234 training location for that region. The Contractor shall provide clear and sufficient system reference materials and documentation must be available during training sessions. Examples include a security guide, reports guide, testing plan, batch documentation, processing schedules, detailed system design, and system modification design documents, etc. The K-MED solution includes system documentation that is accessible from the application and the training environments. In addition, training participants regularly refer to online user procedures (online help) throughout training. All reference material remains online for easy accessibility. The Contractor shall collaborate with KHPA staff to identify potential prerequisites to any training session. This will also involve developing a plan on how trainees can fulfill the prerequisites. The curriculum developed as a part of the K-MED Training Plan includes prerequisites for all planned training sessions. The Contractor shall provide develop an online training demonstration that customers may select to take them through the self-assessment and the Online Intake Application. This will be part of the public self-service portal. As shown in the initial curriculum, if we are selected as the Contractor, we will develop an online training demonstration for KHPA customers that will be available through the APSP Self- Service Portal. The demonstration provides instructions for customers on the following: Accessing the self-assessment and online intake application Navigating through the assessment and intake application Using the online help features of the application Contacting the Help Desk Understanding next steps after completing the application. Materials, curricula, and lesson plans shall be reviewed by KHPA prior to training sessions occurring or materials being released. Training must be presented to KHPA for review at least 30 days prior to change unless sufficient notice is not given by KHPA to meet this time frame (e.g., an emergency policy change). Includes all materials including training modules, desk guides, power point presentations, and the online training demo. Training materials shall be distributed according to a KHPA approved plan. The K-MED Training Plan documents the procedures for review, sign-off, deployment and distribution for all K-MED training materials. KHPA remains involved throughout all phases of training analysis, design, development, testing and deployment and has ultimate review and approval responsibilities. We work with you to establish review points for key milestones in the training effort including the training plan, training designs and completed training materials, including training data and scenarios. The Contractor shall ensure that all training materials are kept current and are readily available for KHPA staff as well as its miscellaneous partners. As part of this objective, the Contractor must update all printed and online training materials when changes occur, making these available to customers by COB of the day prior to the implementation of the change. All updates to training materials shall be submitted to KHPA for review and approval 30 days prior to implementation

235 If we are selected as the Contractor, we will keep training materials up to date throughout the project. We work with you to establish the pace and timing of the updates. We establish and document maintenance procedures that support keeping the training materials synchronized with the K-MED application and other system and user support documentation. For example, we confirm that procedures in place on the functional and technical teams include communicating any system changes to the Training and Readiness teams. The K-MED training plan defines review and sign-off procedures. Once training materials have been signed-off, we adhere to a change control process so that training is not put at risk by making changes too close to training deployment. In addition: We work closely with implementation teams to stay up-to-date on system changes. We incorporate changes prior to roll-out. We establish communication mechanisms so that users know changes are occurring. We submit final training materials to KHPA for review and approval 30 days prior to implementation. Training personnel shall be hired and available to KHPA a minimum of 90 days before the first training session. The Contractor shall also ensure that there are sufficient FTEs or personnel available to meet the training needs of KHPA staff, Presumptive Eligibility entities, SRS, and Clearinghouse staff, etc. If we are selected as the Contractor, we will staff the project with sufficient personnel to meet the training needs for all K-MED users identified during audience analysis. Our approach is to use Accenture and KHPA training team members who have been involved in the K-MED implementation to both conduct training sessions and to confirm any additional training staff are prepared to deliver training. The Contractor shall be generally responsible for developing and conducting staff training as well as managing all the logistics associated with that training, except where specifically otherwise noted or agreed to. A schedule of all proposed training sessions must be submitted to KHPA at least 30 days prior to their actual implementation. Training sessions must be set in accordance to a time and date that is agreed to by KHPA. KHPA staff reserve the right to attend any training sessions presented by the vendor. The delivery of training sessions must occur prior to the date that each phase of the system is implemented. Our approach is to use the State s existing Learning Management System as the delivery mechanism for online training content. This approach keeps a consistent delivery mechanism for K-MED users. However, if we are selected as the Contractor, we will work with you to determine the most appropriate tool to use for the Learning Management System. We can discuss options such as Moodle, an open source learning management system that delivers content and provides learning evaluation. The Contractor is responsible for coordinating and scheduling training from KHPA to ensure that their staff is adequately schooled in KHPA policy and KHPA existing systems. During Project Initiation, we identify the specific KHPA policy and systems training required and make the appropriate arrangements with KHPA

236 Documentation Services Thorough documentation is a key component of Accenture s project approach, which facilitates consistency, accuracy and the successful transfer of knowledge from Accenture to KHPA Documentation Approach The Proposer shall describe its proposed approach for developing and maintaining technical and end-user documentation, systems and operational documentation, system configuration documentation, and procedural documentation, including manuals, quick reference guides, tutorials, online help, job aids, and other techniques as appropriate. We start with proven documentation and tailor it to reflect K-MED customizations We tailor documentation to reflect customizations, configuration or procedural information specific to K-MED Documentation supports all K-MED users and maintenance personnel, from eligibility workers to technical personnel to program administrators Documentation management tools provide version control, traceability and search features Clear and updated technical and end user documentation, systems and operational documentation, system configuration documentation, and procedural documentation that represents KHPA s customizations is necessary to capture historical procedures and provide reference material during or after the project. Project documentation provides an accessible record for future reference that is important to making changes and modifications. Section of our proposal outlines our project methodology which includes six phases plan, analyze, design, build, test and deploy. During each of these phases, project teams develop and modify the documentation associated with activities during that phase. Our approach includes three main methods for developing project documentation: 1. Accenture Delivery Tools (ADT) - Our Accenture Delivery Tools prescribes the types of documentation and deliverables to produce for each phase. Using these documents as the basis for K-MED project documentation supports our goal of bringing Accenture s depth of experience to the K-MED implementation. Each team references ADT for the specific document template they need and tailors it for the K-MED project. Accenture and State team leads review and approve the template, per agreed upon review and signoff procedures. For example, during the Test Phase, the functional team creates test scripts by starting with the ADT template, then customizing it for use on the project. 2. Existing documentation from other projects - Where appropriate, we modify existing systems documentation from successful projects that are similar to K-MED such as the C- IV Eligibility project. This reduces cost and effort to KHPA, leverages proven practices and expedites delivery. We use this documentation as a starting point to create required K- MED deliverables such as the Online User Guide, Operating Procedures Guide and Online Help and Job Aids. Revised documents reflect the specific customizations that are made for the K-MED system. 3. Custom development - The team develops some documentation from scratch, particularly when it relates to new functionality that is exclusive to the K-MED system or business processes. Figure summarizes the features and benefits of our documentation development and maintenance approach

237 Features Tailored for the K-MED implementation, and updated throughout the project lifecycle Thorough technical, end user and operational documentation Document repository for easy access and point of need reference Integrated with Training and Knowledge Transfer approaches Benefits Increases the usability and relevance of the documentation Supports knowledge and skills development among KHPA staff throughout the project Provides documentation to support targeted audience needs Reduces implementation risk by providing accurate and current reference information Enables KHPA to maintain documentation post-implementation Provides the State easy access to reference documentation Improves effectiveness as each audience group has point-of-need access to reference information and procedural help Increases KHPA s familiarity with the content and use of the documentation Emphasizes how KHPA staff will use the documentation on the job Figure Our approach provides technical and end user documentation regarding K-MED customizations, configurations, operational and procedural information that can be used as reference before, during, and after go-live Documentation Maintenance The Proposer shall describe the approach used to keep technical and user documentation current throughout the project, and throughout the life of the system. We realize that up-to-date documentation is paramount to effective production transition and knowledge transfer. Project documents and requirements are the main tools used to define and refine project scope. Documents communicate status, design decisions, business process flows, and other critical aspects of the project. Maintaining documentation, manuals, and source code libraries is a normal part of application development activities. Our approach to maintaining K-MED project documents includes the following: Project teams develop and modify documentation during the course of planned project design, development and testing activities. As the teams create initial versions of the documents and receive sign-off, the signed-off documents become the point of reference for team activities. System changes go through the project s defined configuration and change control process. For approved changes, the associated documentation requires updating in order to maintain an accurate historical record and to confirm that project documentation is up to date. Time to make updates to documentation is included in the change control approvals. As changes to documentation occur, the project repository automatically applies version control functionality to keep accurate records of changes. Our standard document management practices include: Establishing and communicating a standard directory structure Establishing and monitoring document naming conventions and standards Capturing and reporting on standard document elements, such as: version number, author, change history and rationale, participants in document creation, and approvals Using an online document repository with version control to manage project documentation 7-237

238 Online Help The Proposer shall describe the online help functions delivered with the proposed software, and the processes available, if any, to customize the online help to support the software as configured and customized (if necessary) to meet the State s business needs. Our solution contains online help that we modify for the K-MED project. Online Help is a tool users can access directly from within the K-MED system. Online Help opens in a new window, retaining all information already entered while the worker searches for help. In addition to explanations for the user s current web page, online help provides many Job Aids. These Job Aids help with job specific tasks that may use multiple parts of the application (Add a Person to a Case/Program, for example). The Job Aids contain step-by-step procedures that guide a user through completing a job function using the K-MED solution. Examples of the procedures we already have developed that we will tailor for the K-MED solution include the following: Journals, Tasks, Reminders Person Search - Clearance Add a Person to Case/Program Add a Program to Existing Case EDBC Override Eligibility Process Overview Establish a Case Existing Customer Establish a Case New Customer Imaging Workflow Imaging Document Split/Copy Customer Schedule Maintain Re-Evaluation Process Referrals Manage Resources Manage Security Rights Manage Workload Reassignment Manage Per the requirements of the RFP, our approach includes using Online Help in conjunction with the K-MED Online User Guide as part of the basis for end user training. These documents supplement the instructor-led courses during the initial training effort, remain accessible to users during their practice in the Sandbox environment, and provide support to users after deployment. We deliver baseline Online Help with our solution. The Online Help delivered with the software supported the 12,000 users who transitioned successfully to the C-IV eligibility system in California. Online Help is developed in Adobe RoboHelp, a widely-used tool that includes many features and benefits including robust search capabilities. Throughout the project, as customizations for the K-MED solution are identified, the Training team will be responsible for implementing the applicable changes in Online Help. Accenture provides the necessary development licenses for customizing Online Help during the project period. KHPA training team members learn how to use RoboHelp to create, modify and test online procedures so that they can maintain online help into the future Access to Documentation System documentation will support users at every level as they navigate the system from the front line user to program administrators to technical staff. Our approach includes varied types of documentation that meet the reference needs of K- MED solution users at every level. If we are selected as the State s K-MED Contractor, we will develop and/or customize system documentation to support each K-MED user group. System documentation will be maintained in a dynamic shared repository available through the project website, and will include all documentation from online user manuals to technical documentation of the system software. All documentation will be linked to and with all other associated documentation. All documentation will be accessible from the internet and be version 7-238

239 controlled with easy to learn navigation principles. The Contractor keep the documentation up to date, providing updates incorporating all changes, corrections, and enhancements. System documentation must be available and updated on electronic media. All documentation must be organized in a format which facilitates updating, and revisions must be clearly identified and dated. Documentation must include system and subsystem narratives that are understandable by non-technical personnel. Based on our experience, user documentation has different uses and applications than technical documentation. For this reason, we adapt the channels that we use to provide access to each. For example, front line users will have access to online help and job aids directly from the K-MED System through direct links. This enables users to quickly find the appropriate document in a familiar interface. If we are selected as the State s Contractor, we plan on posting business user documentation to a dynamic shared repository available through the project web site. As shown in Figure 7-101, we propose using a Microsoft SharePoint site for this purpose. For more robust tracking that is tied to requirements and releases, we maintain project, system, and technical documentation in Rational ClearCase. Standard features of these tools include secure version management and auditing, both of which promote the efficient management of documents and validate that they contain up-to-date material. Although the project web site contains links to the document repositories, access-control features limit the editing and revision to only authorized individuals. We keep documentation up to date, and work with you to establish the timing and pace of maintenance activities. We organize project documentation so that project team members can easily locate the information they need for reference or maintenance purposes. Figure depicts the data management/documentation process that the project team uses to maintain K-MED project documentation. The K-MED System documentation must contain an overview of the system, including but not limited to a narrative of the entire system, business process models, and a description of the operating environment. If we are selected as the State s contractor, we will develop the necessary documentation to meet the State s requirements including the narrative of the entire system, business process models, and a description of the operating environment. Additional documentation includes required documentation as outlined in the RFP such as the following: General system design and modifications design documents Security Manual Reports Manual Testing Plan Batch documentation Data Structures/crosswalks/data definitions and processing schedules K-MED Figure We propose SharePoint as an easy to use tool for sharing information and documentation across the project 7-239

240 Documentation Management Create/Update Documentation Operational User Doc Configuration Technical Apply Configuration/ Change Control Save to SharePoint K-Med Team Documents not subject to configuration/change control ClearCase Document Repository K-MED Figure We apply KHPA configuration and customization details to APSP system documentation, use change control protocol to keep it current, and store it in an easy to access document repository System Administrator/Operator support manual and technical reference sheets for supporting system(s) Database design documentation Activity/process models System documentation for all third party software products Capacity sizing data documentation Backup and disaster recovery plans Data flow diagrams showing data stores and flows Document Imaging Services By building on the experience gained from Accenture s integration of ImageNow with APSP, PSI s experience developing Kansas-specific workflows, and Perceptive Software s Kansas-specific document management, imaging, workflow products, the Accenture team provides well-proven and lowest risk integration approach. The proposer shall describe its proposed approach for integrating with the existing KHPA ImageNow system as well as other State imaging systems. Prior to final implementation of the K-MED System, all paper case files will need to be scanned into ImageNow and indexed into an electronic case file. The State will be providing these services. SRS and other partner agencies may currently have or may purchase their own imaging system / services. Thus, the K-MED System will need to be able to integrate images created from other document imaging systems (e.g., File Net, Documentum) so that these images can be viewed and used to determine medical eligibility It is a future goal of KHPA to receive the majority of applications through the Online Intake Application, but consumers will always have the option to use a paper application. Therefore, KHPA will continue to have the need to image any paper applications and all other supplemental documents in the future. The K-MED System shall work seamlessly with KHPA s imaging system. KHPA is currently using ImageNow provided by Perceptive Software, Inc. The proposal shall describe how the proposed solution will seamlessly interact with the KHPA imaging system. The system will work seamlessly with other State imaging systems (e.g., Documentum and File Net). The proposal shall describe how the proposed solution will integrate with other State imaging systems

241 The Proposer shall respond to the detailed requirements related to document imaging referenced in RFP Appendix 1 under the General Functional Requirements Workbook in the Imaging Worksheet. Technical specification documents related to ImageNow are referenced in RFP Appendix 15. Accenture s imaging integration solution builds on KHPA s existing investment in the ImageNow solution. We support cohesive integration with the K-MED System and enhanced workflow capabilities. Our solution allows document scanning and image processing to continue with a minimum of impact to current processes, while giving users the ability to store and retrieve case related documents electronically, and view the stored images online from within the K-MED System. Accenture has extensive experience integrating imaging solutions with our eligibility systems. Specifically, Accenture has successfully integrated ImageNow with our C-IV system, a predecessor to APSP. This integrated solution is successfully implemented in 39 counties across California. For the K-MED project, we leverage our team s collective experience in integrating eligibility systems with imaging applications using the ImageNow platform. PSI successfully integrated ImageNow within the Kansas Medicaid Clearinghouse to process all inbound and outbound documents required for Medicaid and CHIP eligibility. Perceptive Software is the enterprise content management vendor and imaging vendor for the State of Kansas now. We will bring this experience to the K-MED project, leveraging existing interfaces and web services to the maximum extent possible to reduce risk and provide a rapid design and configuration effort. We leverage the inherent flexibility of our solution and our team s knowledge of existing KHPA Medicaid workflows to integrate with the state s preferred ImageNow enterprise document management system. The integration of our solution with the ImageNow repository will provide K-MED users with robust workflow capabilities and other business benefits, as described in our proposed solution below. Our Approach Our general approach maximizes reuse of the current Document Imaging setup. This reduces time to implement, added variables which can in turn increase risk, and lower costs to implement. The two main efforts to integrate the K-MED solution with ImageNow are for Interfaces and Workflow. These two areas can be seen in Figure which describes how our integration would handle both the indexing of a new image and the retrieval of an existing one. Indexing In our solution, images will continue to be scanned using ImageNow by the current imaging users. As before, a unique identifier for the image is established in ImageNow. The new image would also trigger a document image be sent to the K-MED System. The utilization of the Clearinghouse resources to index documents as they are scanned at the mail room will be maintained. The imaged document would initiate the appropriate workflow based on the document type and barcode. We anticipate there would be three workflows, one for each of the following document types: Application Redetermination Change 7-241

242 Image Indexing 1. Document Scanned 6. User Indexes document 4. Workflow triggered based on doc type Workstation 2. Image and doc type captured and stored 5. Document added to user s queue 3. Interface to K-Med triggered Image Retrieval K-MED User 1. User opens case and selects associated image 7. Metadata captured and stored K-MED System 2. K-MED recalls image location from metadata 8. Interface passes metadata to ImageNow 3. Interface call requesting image ImageNow 9. Metadata saved to image repository K-MED User 5. Requested image displayed in user s session K-MED System 4. ImageNow returns requested image. ImageNow K-MED Figure We optimize reuse of document imaging processes and technical infrastructure with integration to the K-MED solution K-MED users would see an image for them to process in their queue. By following the workflow they would capture the required index metadata. This metadata would then be sent via our second interface from the K-MED System to ImageNow. Once received, ImageNow would update its repository with the new metadata. Retrieval Users would also be able to retrieve images from the K-MED System. A user would pull up a case and find all of the associated documents linked to the case or person. Clicking on the link triggers K-MED to recall the image location and make a call of the third interface to be developed. This makes a web service call to ImageNow, which still remains as the image repository. ImageNow would then return the document to the K-MED System and the user within the same session. To retrieve the images, users would connect to the ImageNow server while using the K-MED System and be given a context sensitive list of images to view. The ImageNow Server Administrator (ISA) Console is the tool that allows the management of services, logging, and auditing. For example, when a user is viewing the Case Summary page, the images link could be easily configured to return only the case-specific documents versus customer-specific documents (e.g., birth certificates, pay stubs). Similarly, the income pages could return only the documents specific to the income (e.g., pay stubs, employment letter) of individual(s) whose data is being viewed. Other K-MED System pages would be configured in a similar manner to pull back relevant documents. This allows users to view only the images they need

243 The entire retrieval process occurs without the user leaving the K-MED System screen or session. Imaged documents in our solution would also be associated with the corresponding K- MED System pages. This would potentially help reduce the number of documents that users would need to sort through in a list. Since the list of available documents would be customized based on the Web page the user would be viewing, a small number clicks would be enough to access most documents. Lastly, another benefit of our retrieval process is that it can be applied to different image repositories in the future. From an integration standpoint, all that would need to be done would be the interfacing definitions since the workflows are already defined. Architecture We will maintain a similar system and data structure to what is currently found in the ImageNow and PSI platform integration. ImageNow will continue to be the image repository. However, we will replace the interfaces and web service calls to/from the PSI platform with web service calls to/from the K-MED System. We would utilize document imaging links that can be altered to interact with the K-MED System. This direct switch builds upon the effort already invested by KHPA and PSI to ingrate the current systems. We also see a potential reduction in errors and effort in training, as all users will be performing the same or very similar tasks. We also understand with the importance of maintaining the current imaging efforts throughout our K-MED solution implementation. Interfaces Much like the current implementation, we would build interfaces using web service calls between the K-MED solution and KHPA. We expect to develop the necessary repository connections used for the following purposes: To begin workflow in K-MED to capture the image metadata, including linking to an individual or case To update ImageNow with the newly captured metadata To retrieve an image from ImageNow We again can leverage the existing integration work done by our team members PSI and KHPA to speed the process. In addition, these web services take advantage of APSP s flexible SOA-compliant architecture. This web service-friendly architecture allows us to easily adapt to both receiving and making web service calls. Workflow We will build update current workflows to take advantage of K-MED s adaptable workflow engine. For this effort, we will leverage PSI s work developing the custom workflows housed in the PSI platform to create similar workflows in K-MED. For example, as shown in Figure 7-104, we can integrate the current clearinghouse processes into document imaging and retrieval into K- MED. Using the established workflows reduces the effort to adjust and adapt the workflow to meet requirements as that refinement has already been done during the past integration. This also allows users to continue using the processes that they are currently used to, helping maintain productivity

244 Document Entry Point Scan QA Index Workers Receive Application / Document Manually Routed to Worker Find and/or Open Case Scan Tracking Barcode Yes Tracking Barcode? No Scan Document Insert Patch Codes Document Linked at Case Level / QA Scan Document w / Imaging Barcode Index Document QA Batch Imaged Complete Queue Auto- Routed to Worker Yes Mailroom Sort and Open Mail Imaging Barcode? Receive Application / Document No Find and/or Open Case Scan Document Document Linked at Case Level / QA K-MED Figure K-MED would allow for integration of current Clearinghouse workflows, indexed documents could be retrieved via web application KHPA can take advantage of the solution s workflow tools to automate processes such as Intake, Re-determinations/Re-evaluations, customer reporting processes, and processes for fax or mail in documentation and forms. During requirements gathering, we would work with KHPA to determine how automating business processes using workflow would benefit certain locations. Because of APSP s easily configurable workflow engine, we can quickly adapt the workflow to accommodate process changes to locations, teams, roles, even individuals. This provides KPHA with a measure of confidence that the system can handle additional changes. Future Imaging Solutions We have also developed a flexible solution for the future. As future imaging systems are implemented, we provide a framework that can be reused. The open APSP framework is SOAcompliant and can integrate with other systems using similar web service calls as we have described between K-MED and ImageNow. The advantage to using web services is that we can also use the existing web services as a template for future K-MED to imaging system interfaces. This not only simplifies and speeds up implementation times. We can also reduce risk and potential issues by using such a tried and true framework Knowledge Transfer Services Our proposed knowledge transfer process enables KHPA to operate K-MED effectively immediately upon go-live. The Proposer shall describe its knowledge transfer strategy throughout the project to ensure that KHPA employees are prepared to use the system at go-live. Describe the specific procedures that the Proposer will undertake to mentor State staff and ensure adequate State experience and knowledge of the system by the time of transition

245 Knowledge Transfer Approach Knowledge transfer begins day one of the project and continues through training and day-today activities for the life of the project. KHPA functional, technical and training personnel responsible for maintaining the K-MED system after deployment receive hands-on experience with all phases of the project. Understanding the full project lifecycle from analysis, through design, development and implementation puts KHPA staff in the best position possible to operate the system after turnover. KHPA personnel learn working side-by-side with Accenture teammates. This approach facilitates knowledge transfer and builds the capabilities of KHPA employees while at the same time, completes critical project work activities. Figure displays the features and benefits of our knowledge transfer approach. Features Structured Knowledge Transfer Approach Personal Learning Plans Benefits Focuses from Day 1 on building KHPA s capabilities Lowers the risk of transitioning the operation and maintenance of K-MED Provides visibility for KHPA executives into the knowledge transfer process Minimizes the risk of consultants leaving the project without adequate capture and transfer of knowledge Provides for periodic checkpoints so that the State can assess progress and adjust if needed Provides individual context for each employee and increases the effectiveness of their knowledge transfer process Establishes clear metrics and methods to help the State validate that the right level of knowledge and skills have been acquired Confirms that the transition of knowledge is not occurring at the planned pace Mentoring Program Provides one-on-one mentoring, increasing productivity with K-MED Stresses individual accountability for the Accenture team mentors Enables the employees to learn-by-doing and immediately apply their newly developed skills Mix of Methods and Tools Increases effectiveness by appealing to differing learning styles and needs Figure Our approach to knowledge transfer combines proven techniques with tracking and oversight to deliver the most effective program Figure displays the structured knowledge transfer approach proposed by the Accenture team. Our approach includes the following activities: Identify maintenance and support staff end-state roles and responsibilities. During the Analysis Phase of the project, we work with you to refine the roles and responsibilities included in our proposal. Develop Knowledge Transfer Plan. The Knowledge Transfer Plan is the key document that includes details about the Knowledge Transfer program. In order to develop an effective Knowledge Transfer Plan, we first conduct a training needs assessment. In the same way we define the future skill and knowledge requirements for K-MED users, we do the same for maintenance and support staff. Our needs assessment includes comparing future requirements to current skills and knowledge. We close identified gaps through knowledge transfer and training programs. The Knowledge Transfer Plan includes results of the training needs assessment. The Knowledge Transfer Plan also identifies the specific knowledge transfer modules that encompass the functions to be transferred. Examples of transition modules include: Migration procedures 7-245

246 Identify Knowledge Transfer Roles/ Responsibilities / People Knowledge Recipient Develop Knowledge Transfer Plan Knowledge Sponsor Review Knowledge Transfer Process and Personal Learning Plans and Assign Mentors to Personal Learning Plans Knowledge Transfer Approach Mentors Conduct Knowledge Transfer Activities Exit Criteria Met? No Update Personal Learning Plan Yes KHPA Sign-off Knowledge Transfer Complete Preceding the Start Date First Day for Individual Mentors Conduct Knowledge Transfer as per the Personal Learning Plan for the Individual(s) Tracking and Reporting of Knowledge Transfer K-MED Figure We use a structured approach to transfer skills and knowledge to KHPA personnel effectively and efficiently Custom code updates and reviews Help Desk processes and ticket management Batch monitoring Security administration Training material maintenance Interface updates or processing Test planning and execution The Knowledge Transfer Plan maps the transition modules to the specific roles that require knowledge for each one. Multiple people can participate in transition and mentoring activities (such as one-on-one transition, training meetings, etc.) for a module. Develop a Personal Learning Plan for each member of the maintenance and support staff. Maintenance and support personnel cover a wide range of responsibilities. Some require deep skills not widely distributed through the organization. For example, there may be few database management specialists, but they will need to be experts in how the database operates. For this reason, each member of the maintenance and support staff receives a Personal Learning Plan outlining individual learning and skill development objectives. Conduct knowledge transfer activities and check exit criteria, until knowledge transfer is complete. Expand on the concepts articulated here to propose mentoring activities that are actionable and can be practically accomplished on the go in the K-MED Project environment. Our experience has shown that the knowledge transfer/mentoring program needs to be practical and accommodate the busy schedule of project activities. Specific knowledge transfer methods include the following: Peer Programming Includes working side-by side to provide detailed instruction on how to complete a task with one-on-one interaction to confirm mastery Shadowing Direct observation, or over-the-shoulder knowledge transfer 7-246

247 Training sessions More formal training used for knowledge transfer to large groups Monitored Tasks Assignment of tasks to knowledge recipients that are completed independently and then reviewed by the transferor/mentor Role Sharing Accenture and KHPA staff each complete job responsibilities associated with a single role Job aids Custom step by step instructions to complete a task, created with the specific knowledge recipient in mind The Accenture team also proposes using innovative knowledge management tools, such as blogs and chat sessions. We propose using these Web 2.0 collaborative and social networking tools as an innovative method to answer and resolve common issues and learn from other users. Blogs and chat rooms provide many benefits to KHPA, such as: Simple, inexpensive, and easy tools Popular, especially with younger employees KHPA employees learn from each other Users learn common answers to common questions Provides historical information through previous posts from users Our approach focuses on transitioning information gradually to your team starting early and through deployment. As your staff becomes more proficient and comfortable with the role, responsibilities and associated technologies, the transition occurs more smoothly and naturally. In Idaho, transition activities were underway prior to user acceptance testing, allowing their staff to be prepared to support the system independently just 3 months after deployment. As the Accenture team, we plan to bring our experience from the Idaho project and many others to KHPA to execute a successful knowledge transfer strategy and prepare your team to complete their jobs successfully Model Support Organization and Knowledge, Skills and Abilities Expand on a model business support organization for the new system with key roles identified. Expand on the knowledge, skills and abilities identified for each role. Following the successful implementation of K-MED and the completion of Phase 2, the Accenture team plans to transition to a support structure that includes Accenture, KHPA, and hosting provider resources in key support roles. Our approach is to utilize functional and technical resources in dual roles performing maintenance functions and also supporting user support needs. Please see Section , Post-Implementation Support Phase Organization Chart, to see a visual depiction of the organization structure after deployment. Figure expands on the description of each role in the model support organization. During the post-implementation phase, the Account Director works with KHPA leadership to provide overall management and direction of K-MED and support continuous adoption and utilization of the system. Application development team members resolve issues related to the functionality of K-MED, code any new requirements, code system test fixes and change requests, modify workflow, and develop new reports. The Technical Infrastructure team/hosting Provider is the primary contact for technical issues, such as computer operations, patching, maintaining the databases, migrating objects into production, maintaining servers, etc. The Training Team will maintain K-MED training, provide ongoing training, and manage communications related to the K-MED system and revised business processes. When staffing the support organization, it is also important to consider the organizational 7-247

248 structure, the role descriptions, whether the compensation and rewards should change, and how to retain the resources that are already on the project.. - Key Support Role Responsibilities Account Director Assumes the duties of the Project Manager following implementation Responsible for overseeing the overall operation of the K-MED system Serves as the primary point of contact with KHPA s Project Director through the completion of the contract and manages the Accenture team on a day-to-day basis Provides Tier 2 support during Post- Implementation Support Phase Deputy Account Director/System Manager Implementation/ User Support Manager Serves as the backup for the Account Director; also serves in the System Manager role Provides Tier 2 support during Post- Implementation Phase Responsible for Tier 2 and 3 User Support / Help Desk operations and leading all implementation-related support activities Monitors the initial operation of the K- MED system and reports on postimplementation issues Provides Tier 2 support during Post- Implementation Support Phase Hosting Provider Responsible for design and maintenance of the K-MED system database Verifies the rules engine and shared system logic correctly accesses information from the system to make accurate eligibility and benefit issuance decisions Installs application software Maintains server security Applies patches from server Evaluates and installs server related software for backups, transfers Establishes, executes and maintains server backup/recovery procedures Sets up and monitors server backups Reviews application for performance and standards Reviews log directories for growth and Knowledge, Skills and Abilities Knowledge of KHPA s organizational culture and business requirements Relationship development skills Knowledge of the K-MED Project Business system integration skills Large project management experience Leadership and motivation skills Professionalism and interpersonal skills Risk assessment and control skills Project management skills Strong communication skills Experience coordinating subcontractors, stakeholders, and other third parties Same knowledge, skills and abilities as Account Director plus the following as they relate to the System Manager role: Ability to understand impacts of proposed change requests and fixes on the K-MED system Detailed knowledge of the system development life cycle and methodology used on the K-MED project Knowledge of KHPA s organizational culture and business requirements Understanding of the K-MED application Understanding of change management principles Business process analysis skills Project management skills Strong communication skills Experience implementing the K-MED system and revised business processes Strong knowledge of K-MED system and architecture Strong technical skills Deep understanding of KHPA s technology landscape 7-248

249 Key Support Role Application Maintenance Team Members Responsibilities manages appropriately Reviews table sizes, indexes for capacity planning and performance impact Plans, tests, and executes disaster recovery Manages overall application environment Develop detailed designs to support desired functionality for enhancements Construct and test modifications and enhancements to APSP Develop reports, forms and imaging components of K-MED Create unit test plans which detail test conditions and expected results Set up test data Test code changes and resolve differences between expected and actual results May work with business function owners to understand requirements May work with business function owners to develop tests Follow established processes and documentation standards Conversion Lead Works closely with the Application Development/Interfaces Team Lead and Database Administrator to verify that data needed is accurately converted to K- MED system specifications Develops conversion approach and oversees conversion activities Drives the crosswalks from legacy data to K-MED system values Coordinates the project work plan and schedule for the Data Conversion Team Assists with the deployment of the data conversion interface Assists in the validation of converted data Drives development of extract programs created by legacy application personnel Oversees development of manual conversion processes Tier 2 Lead Day-to-day responsibility for functional aspects of the K-MED system including requirements definition, design, and testing of any fixes or enhancements Validates requirements Works closely with the KHPA Business Functional Team Manager and the Implementation/User Support Manager to plan for business changes needed to accommodate any system modifications Knowledge, Skills and Abilities Knowledge of the K-MED System including processing procedures and system architecture Ability to interpret policies and standards into application requirements Knowledge of relational database structures K-MED system development training Skilled in application programming languages Understanding of application / technical architecture Database manipulation skills Strong programming skills Understands data translation Able to translate client requirements into specifications and aid in test planning Knowledge of data handling methodologies Ability to create client reports as needed Knowledge of K-MED system functionality Data analysis skills Knowledgeable of K-MED functional requirements Knowledge of KHPA s organizational culture and business requirements Prior experience on the K-MED project Possesses a thorough knowledge of functional or specialty areas Strong K-MED application background with a broad exposure to the technologies being used 7-249

250 Key Support Role Tier 2 Support Members Technical Application Lead/ Tier 3 Lead Technical Team Developer/Tier 3 support Responsibilities Leads the Tier 2 Support Team Investigates and responds to Tier 2 end user issues Resolve basic technical issues that do not require code changes Validate reported incidents against system requirements to determine if the system is performing as designed Fix known issues Escalate any new or undocumented issues to Tier 3 Determine if incidents requires APSP product support and direct the incident to the APSP Service Desk if warranted Coordinates ongoing efforts of technical support team members Primary point of contact for Tier 3 technical issues Provides status of production system and related technical issues Reports status of technical support efforts Identifies ways to streamline technical support efforts Assists developers to estimate level of effort associated with modifications/enhancements Coordinates training activities for technical team members Maintains and supports K-MED customized code Provides COTS interface support for the K-MED system Handles the most difficult or advanced Knowledge, Skills and Abilities Understanding of the K-MED applications the State has implemented and the revised business processes Critical thinking skills Strong writing skills; ability to articulate a problem resolution in such a way that is easily understood by others Create answers to Frequently Asked Questions for Tier 1 Completion of core APSP Product Training Knowledge of KHPA s organizational culture and business requirements Prior experience on the K-MED project Possesses a thorough knowledge of functional or specialty area Strong K-MED application background with a broad exposure to the technologies being used Understanding of the K-MED applications the State has implemented and the revised business processes Critical thinking skills Strong writing skills; ability to articulate a problem resolution in such a way that is easily understood by others Create answers to Frequently Asked Questions for Tier 1 Completion of core APSP Product Training Knowledge of KHPA s organizational culture and business requirements Knowledge of the K-MED system and other third party COTS products Prior experience on the project team Ability to interpret policies and standards into technical requirements Ability to supervise and manage technical resources Knowledge of relational database structures Ability to analyze and design computer applications Ability to supervise and manage technical development Project management skills Strong communication skills Proficient in the technologies required to support K-MED customizations Detailed knowledge of the system development life cycle and methodology used on the K-MED project 7-250

251 Key Support Role QA System Tester COTS Support Security Manager Tier 1 Help Desk Manager Tier 1 Help Desk Agents Responsibilities support issues Reviews all tasks and troubleshooting completed for escalated issues Approves test criteria Develops test scripts Creates test data Executes testing Analyzes and diagnoses problems encountered within software and recommend solutions Logs system defects and retests resolution Maintains communication with COTS providers Stays up-to-date on COTS system updates Analyzes COTS product updates and identifies impacts to K-MED system Performs Tier 3 support tasks Manages end-user access and overall security of the system Provides expertise and leadership in the area of K-MED security administration Works with functional experts to develop security requirements for each application/module Manages K-MED user accounts in multiple instances Assists with defining, implementing, and managing any security requirements external to K-MED Coordinates application specific security setups to support functional requirements including the setup of developer security and user profiles and roles for production Oversees Tier 1 Help Desk function which includes all incoming contacts/incidents from internal and external customers Gather customer information and determine customer issues by analyzing the symptoms and figuring out the Knowledge, Skills and Abilities Testing skills Completion of core APSP Product Training Knowledge of the testing methodologies used on the project Ability to test system changes against approved test criteria and document results Critical thinking skills Understanding of the K-MED applications the State has implemented and the revised business processes Proficient in the technologies required to support K-MED customizations Detailed understanding of third party COTS products related to the K-MED system Detailed knowledge of the system development life cycle and methodology used on the K-MED project Testing skills Completion of core APSP Product Training Understanding of K-MED application Knowledge of K-MED security and security administration tools Project management skills Strong communication skills Strong technical skills Knowledge of State security requirements Knowledge of KHPA s organizational culture and business requirements Project management experience Customer service experience Prior experience on the K-MED Project team Help Desk application knowledge and skills Project management skills Strong communication skills Strong knowledge of the Customer Care function Analysis, judgment, and sensitivity to 7-251

252 Key Support Role Application Maintenance Team Member Training Team Member Enterprise Readiness Team Member Responsibilities underlying problem Handle basic problems, including resolving username/password issues or basic help application usage. Escalate issues to Tier 2 Communicate resolutions back to users Identify and define business and user requirements and functional design/configuration requirements for ongoing changes and enhancements Work with programmers as needed to transfer clear and complete understanding of the requirements Assist in translating requirements into test conditions and expected results for product, performance, and user acceptance testing Assist with test data creation and test execution Serve as a resource for the Implementation/User Support Team as they evaluate changes to enterprise readiness, training and communications materials Develop readiness, training and communications materials as needed Updates training materials and training data to correspond to system modifications Tests changes to training materials and hands-on exercises Creates training communications Executes ongoing training Creates training evaluations and analyzes evaluation results Assesses/monitors help desk requests to determine additional training needs Works closely with KHPA Business Functional Team members and Change Agents to support KHPA staff after implementation Reports implementation status to project management and executive leadership Facilitates two-way communication between Change Agents, Regional Readiness Managers and project team to Knowledge, Skills and Abilities customer needs; tolerance to deal with irate customers under stressful situations Strong verbal and written communication skills Ability to exercise good judgment with minimal supervision Good organizational, negotiations and problem resolution skills Knowledge of Medicaid Terms Ability to work effectively in a team environment under coaching Ability to work flexible shifts & days Knowledge of KHPA s organizational culture and business requirements Prior experience on the K-MED project Understanding of the K-MED applications the State has implemented and both the former and current business processes Ability to translate business needs/gaps into system requirements Ability to analyze changes to the system and apply the changes to existing training materials or create new materials as needed Training design and development expertise Ability to create and test training data Ability to consolidate documents and oversee production Instructor and coaching skills Knowledge of functions within K-MED Understanding of the K-MED system Understanding of change management principles Understanding of business process analysis Knowledge of both former and current business processes and the ability to explain the changes to staff Ability to use the K-MED system to 7-252

253 Key Support Role Communications Team Member Responsibilities monitor post-implementation issues Provides user support in the field during Post-Implementation Phase, including target training sessions Maintains the Communications Plan Populates project homepage on the web Develops and distributes project updates Defines specific communication messages Monitors communications and adjusts as needed Knowledge, Skills and Abilities perform essential job functions and to demonstrate the functions for staff Strong written and oral communication skills Clear writing skills Graphics/layout skills Coordination skills Meeting planning Existing relationship with State departments and personnel Figure The State must identify the staff members assigned to these key support roles so they can be the recipients of knowledge transfer Personal Learning Plans Expand on specific Personal Learning Plans (PLPs) for each key State staff assigned to key roles delineating learning goals and timeframes. Each individual working on the K-MED project creates a Personal Learning Plan (PLP). A Personal Learning Plan is a document that lists the activities, skills, or knowledge that a person needs in order to complete their post-implementation job tasks. These plans document the individual s current skill level for a certain topic, the desired skill level, the Accenture mentor assigned to the PLP, the reference materials, the time frame, the percentage completion, the signoff, and any next steps for the transferor/mentor or transferee. We monitor Personal Learning Plans on a quarterly basis, and as the project nears completion, on a monthly basis. Figure displays a prototype of a Personal Learning Plan. If we are selected as the State s Contractor, we will work with you to revise the Personal Learning Plan prototype to address specific K-MED requirements. To facilitate success, the K-MED project sponsors and management must support the knowledge transfer process. The project schedule must also include adequate time to transfer Defines knowledge to be transferred Knowledge Details How to Conduct Instructor Led Training How to use the Presumptive Eligibility Tool Desired Skill Proficiency X Defines to-be skill proficiency of employee X Defines existing knowledge assets that can be leveraged Accenture Team Mentor Knowledge Assets Train the Trainer materials Instructor-led Materials, Online Help, Online User Guide, Sandbox Personal Learning Plan Time Frame Current Skill Proficiency Defines next steps required to attain to-be skill proficiency % Complete KHPA Sign off Next Steps Start Date End Date Duration /1/2012 3/30/ days X 25% Attend Train the Trainer 3/15/2012 3/30/ days X 10% Attend Train the Trainer, Assist Training Session, Practice in Sandbox Defines current skill proficiency of employee Figure We use personal learning plans to monitor progress in a structured way K-MED

254 knowledge. The Implementation/User Support Manager oversees the knowledge transfer program which includes the following responsibilities: Identifying individuals that need to complete the Personal Learning Plans Monitoring the completion of Personal Learning Plans Reviewing the Personal Learning Plans with the appropriate team leads to make certain all knowledge that needs to be transferred is transferred Reporting status on the completion of Personal Learning Plans Working with the Project Manager for final approval/signoff of the Personal Learning Plan Knowledge Transfer/Mentoring Methods Expand on assigned mentors from the Contractor s staff to teach or demonstrate items from the PLPs. For each transition module, the transition manager and team leads identify mentors who are responsible for transferring the knowledge for that module to the applicable person or group of KHPA personnel. For example, there is usually one mentor responsible for the Test Planning transition module. Mentors are available to KHPA employees for questions and assistance throughout the project. In addition, it is a formal part of the mentor s job responsibilities to fulfill the requirements of the KHPA staff member s personal learning plan Personal Learning Plan Verification Expand on documented confirmation/verification that PLP items have been learned by key staff. We know that you need to be able to operate your system effectively. We implement a transition plan that addresses the inventory of skills you need, a process to transition the skills and verification that the skills that were transitioned. Knowledge/skills transfer occurs through a variety of training and mentoring activities. Knowledge recipients measure their own progress on a predetermined schedule by taking skill assessment surveys and report the results to project management. The results of the skills assessments are an element to measure business readiness. Measuring their own progress, aided by input from mentors, and then reporting the results to project management encourages the recipients to take ownership of their own learning process. As part of the skill assessment process, the recipients and mentors work together to confirm attainment of the required skills, adjusting training and mentoring activities where necessary. Management escalates any trouble areas and adjusts the knowledge/skills transfer process to correct the problems. Ultimately, key KHPA staff members sign-off that the Accenture team has executed the knowledge transfer plans for all of the identified transition modules effectively

255 Enterprise Readiness Assessment Along with Training and User Support, our field tested Enterprise Readiness methodologies form the basis for successfully transitioning K-MED users to the new system, business processes and roles Approach The K-MED project will bring positive change to KHPA personnel, as well as customers and service providers. For example, customers will start the data entry process themselves by accessing applications and information about services. The time and energysaving capabilities in the K-MED system will radically change the interactions between KHPA staff, customers and providers in positive ways. However, helping these groups through the transition period is a critical component to overall project success. Our approach to Enterprise Readiness includes customizing Accenture s proven methods to address KHPA s specific change requirements as we work closely with KHPA to transition users to the new system and processes Key Readiness Challenges The success of the K-MED implementation relies on thoughtfully tailoring our methodology to address KHPA s unique challenges, which include: Creating a shared language and vision among leaders from different agencies, programs and locations Meeting the communication and training requirements of a diverse user population Supporting customers as they transition to a new way of working with KHPA that includes unfamiliar technology Building support for changing job roles and skill needs among staff from KHPA, SRS and other organizations Meeting the complex logistical and project management requirements of a phased change readiness implementation the size and scope of K-MED Enterprise Readiness Assessment Report Our proven Cultural Change Management and Readiness methodologies enable low risk implementations by preparing K-MED users every step of the way Tailored for KHPA, Enterprise Readiness initiatives move stakeholders from basic awareness to commitment quickly and efficiently Change Readiness approach has been executed successfully at similar social services clients nationwide Change is supported and facilitated from within by building sponsorship at every organizational level Defined readiness assessment methods validate user preparedness for implementation The Contractor must evaluate and provide an Enterprise Readiness Assessment by gathering information from KHPA, other state agencies, and contractors involved in the eligibility determination process. The Contractor will prepare a report that rates various aspects of enterprise readiness and provides suggestions for improving KHPA s overall business processes. The report shall include a cost benefit analysis by using the Enterprise Readiness Assessment to identify key areas for improvement and how the K-MED System will be integrated into the solution. The Contractor shall provide inexpensive, less disruptive options in addition to larger changes as part of the report. If we are selected as the State s Contractor, we will conduct the Enterprise Readiness Assessment. To complete the assessment, we create a K-MED-specific version of Accenture s Human Services Delivery Diagnostic and Roadmap Tool. The diagnostic tool provides a way to approach complex agencies unique situations in a logical, progressive way. The tool contains a 7-255

256 framework for interviewing and surveying KHPA and other state agencies and contractors involved in the eligibility determination process to gather the most pertinent information for assessing the agency s readiness for change. KHPA has dedicated one full time team member to serve in a communications role on the Enterprise Readiness team. We look forward to working with this person as we gather information from other state agencies and contractors during the assessment. Interview and survey questions cover a range of areas, including the following: Mission and Vision (i.e. How well are the organization's mission and vision understood by customers, stakeholders, and employees?) Programs and Services (i.e. Discuss how the program is coordinating its activities to avoid duplication or conflict with other programs.) Customers and Funding Authorities (i.e. What are the needs and expectations of customers regarding the products and services the organization provides?) Program Access Characteristics (i.e. Are clients directed/routed to different locations for different services?) People and Organizations (i.e. What is the estimated time it takes, following training, for service delivery staff to reach the expected level of minimum proficiency?) Processes (i.e. Describe any departmental/agency handoffs required in processing of a case.) Technology (i.e. Are the organization's technology and systems effective at enabling its performance? Why or why not?) Team members synthesize and refine findings from data-gathering, interview, focus group, and survey activities and report the findings and recommendations in the Enterprise Readiness Assessment Report. The findings include ratings for the various aspects of enterprise readiness and provide suggestions for improving KHPA s overall business processes. Key recommendations/options have accompanying cost/benefit analysis to aid KHPA leadership decision-making. The report includes a timeline of recommended initiatives, including quick wins that can be accomplished quickly and inexpensively with minimal disruption to KHPA service delivery. The Enterprise Readiness Assessment Report shall, at a minimum, address the following items: Communications; Culture Change Management; Skills Needs and Gap Assessment; Creating and Mentoring Change Agents; Leadership Alignment and Executive Sponsorship; Role Mapping; Organizational Readiness; Production Transition; and Establishment of a K-MED helpdesk. KHPA will work with the Contractor to identify those changes that will be implemented as part of the K-MED System. The assessment team presents the results and recommendations to key agency leaders and K- MED sponsors and support KHPA leadership during their evaluation, consideration, and selection of recommendations for improvement. Figure shows the key steps that comprise the Assessment Process

257 Steps to Execute Diagnostics Step 1 Prepare and Initiate Diagnostic Review Step 2 Conduct Interviews, Host Group Sessions and Perform Survey Step 3 Analyze Information and Develop Findings Step 4 Report Findings and Recommendations to Agency Governance for Consideration K-MED Figure Our diagnostic tool helps agencies assess their current level of readiness and identifies recommendations for consideration Enterprise Readiness (ER) Team The Contractor will work with KHPA to form the Enterprise Readiness (ER) team. The team has the primary responsibility for leading and coordinating cultural change management for all parties involved in the medical assistance determination process. Communication with parties outside of KHPA is essential, and the ER team shall establish communication protocols with state agency representatives about the changes that will take place with the new system and provide assistance in implementing these changes within their infrastructure. Additionally, the ER team will work with the training team to ensure all staff members are fully educated and fully prepared. We work with you to form the Enterprise Readiness (ER) team. Our team focuses on developing a strong understanding of the cultural characteristics and parties that make the K- MED implementation unique. We build relationships among all levels of K-MED sponsors and change agents - from project sponsors to individual change agents from various locations such as PE and SRS locations. Using the Enterprise Readiness Assessment Report as a guide, Accenture and KHPA ER Team members create the K-MED Change Plan, Communication Plan, and Training Plan, with each playing a part in preparing staff for the K-MED implementation. The plans clearly lay out when and how we plan to communicate with outside parties so that KHPA knows the purpose, timing and content of communications with these organizations and can participate in the process if desired. We communicate with the appropriate state agency representatives about the changes that will take place with the new system and provide assistance in implementing these changes within their infrastructure. One of the primary outcomes of the overall enterprise readiness effort is well-trained users who confidently complete their job responsibilities using the new system. There is overlap between enterprise readiness initiatives and training initiatives, and coordination between the two efforts is essential. Our team has experience executing multi-faceted readiness efforts that prepare diverse user groups for successful implementations Enterprise Readiness Program The ER team implements the K-MED Readiness Program, which includes the approved initiatives outlined in the Enterprise Readiness Assessment Report. Our proposal describes the methods and initiatives we believe would be effective components of the K-MED Enterprise Readiness Program. Upon completion of the Enterprise Readiness Assessment Report, we work with you to identify the exact initiatives to implement and the best ways to incorporate KHPA staff in the ER efforts. We look forward to working closely with KHPA personnel on the team as we create change readiness and communications materials together. Figure shows the key initiatives we employ to move K-MED users along the journey from basic awareness to commitment

258 K-MED Project Enterprise Readiness Key Activities Project Initiation Design Build & Test Go-Live & Support Introduce key sponsors and leadership messages from beginning of project Use project communications to build initial awareness of project goals, purpose, rationale and benefits Communicate project timeline Inform users of where they can obtain project information Inform all stakeholders about the readiness, training and user support initiatives that will support them through the process Provide initial information about changes to business processes, skills and job roles Establish a network of change agents Figure CAFÉ-103. Action Caption Conduct Readiness Workshops to provide specific details about process, procedure and job changes Conduct skills training to teach stakeholders how to use the K- MED system and online help Prepare users for rollout Provide support to users throughout K-MED deployment Change Commitment Curve Commitment Help users experience the benefits of K-MED We use our feedback mechanisms including the change readiness assessments and training evaluations to collect feedback, assess outcomes, and adjust strategy where needed K-MED Figure We tailor our cultural change management, readiness and training activities to move stakeholders from awareness to commitment quickly and efficiently Communication Effective two-way communication is one of the most powerful tools that support positive change. Sending the right message at the right time to individuals affected by the K-MED implementation helps build ownership and facilitates successful process and role changes. Properly informed stakeholders have an easier time accepting and using the new system and adjusting to new process and job functions. We stage communication in a logical sequence and tailor it to the unique needs of each user group. For example, we plan to tailor specific communications for PE users as we near the implementation of Phase I. We design the communication strategy for the K-MED project to be: Relevant to the phase of the implementation effort Tailored to the needs each stakeholder group Considerate of State and project events, such as work deadlines and milestones KHPA has dedicated one person to work on the communications effort. We anticipate that the KHPA team member will work side by side with the rest of the team to create the K-MED Project Communication Plan and communications/readiness materials Culture Change Management Managing cultural change across a complex organization like KHPA requires close collaboration between our team and KHPA from working together to form the right vision for the project, to working side by side on the readiness, training and implementation teams. From the beginning of the project, during the Enterprise Readiness Assessment activity, we ask the right questions together to understand the context, content and complexity of the change. The context of the change addresses Why does KHPA need to change at this time? The content of the change answers What is changing, when will the changes occur, and who is affected? The complexity of the change answers How big and how challenging will it be for KHPA and its customers and providers to change? These three elements are instrumental in developing an effective Course of Action for change. The Course of Action refers to the mix, sequence, pace, and measures associated with Cultural Change Management activities. The 7-258

259 Course of Action Manage the Transition Sustain and Realize Benefits Context The Why Content The What Complexity The When, Who, and How Much Drives Manage How well are the outcomes of change being managed? The right plan, milestones and priorities Supply Enable What support is in place? The right knowledge, skills, abilities and resources Organizational Manage Enable Lead Own Individual The How Lead How well is the change being led? The right vision, sponsorship, leadership alignment and communications Demand Own How well is the change owned? Is there commitment to change? The right people, process, roles and system alignment K-MED Figure Our strategic Cultural Change Management approach asks the important questions to understand and integrate with KHPA culture and start change from the inside Course of Action becomes the roadmap for the change journey and the basis for the K-MED Change Plan that we execute together. Figure shows how our Change Methodology reflects many of KHPA s priorities for the Change Management Program defining the right plan, creating sponsorship, enabling KHPA staff, and fostering commitment to change throughout the process Skills Needs and Gap Assessment During the Design Phase, we conduct a skills needs and gap assessment. The objective of the skills assessment is to identify the current skills of K-MED users and to identify what additional skills will be needed to carry out the State s business using the new system. We consider the organization impact, constraints, and requirements of the business process and technology changes as input. We document specific impacts as they relate to a number of factors, including processes, systems, employee skills, role definitions, or State policies. The results of the skills assessment help us plan for communications, training, readiness, and knowledge transfer activities. We use the following methods to gain input for the skills and gap assessment: Project fit gap activities - Accenture team members meet with KHPA functional experts to document differences between the as is and to be business processes. Through interviews and joint application design (JAD) sessions, our team gains a progressively deeper understanding of KHPA s processes and technology and how KHPA workers perform their tasks today, as well as the gaps between today and the desired future state. Using this knowledge as a starting point, we work with KHPA subject matter experts to document the current skill levels that are required to perform job roles effectively. We then apply the information we gather to assess the gap between the current skill level and the skill level needed by end users for after K-MED implementation. Audience Analysis documentation We perform analysis of the agency users, such as what roles/titles are currently performing the business process, how would the process change for them, what is the new process, and what are the possible new roles? 7-259

260 Skills Needs and Gap Assessment Conduct Task Analysis Perform Gap Assessment Identify Requirements Define Enterprise Readiness Initiatives Identify future business processes: What will need to be done? Who needs to do it? When it should be done? Where should it be done? How it should be completed? Compare current way the task is done to future way Identify current skill, performance and knowledge gaps What is the required skill level to perform each new business process? What are the competencies required to eliminate the skill gaps? What knowledge is needed? Are there any external needs to consider? Identify the required communication, cultural change management, readiness, and training initiatives required to address users needs K-MED Figure We use a structured approach to conduct a thorough Training Needs and Gap Analysis that helps to identify the learning needs of the K-MED users Questionnaires Agency contacts fill out to surveys that address such topics as how many primary and secondary users there are at the agency. Figure depicts steps we take to identify cultural change management and training requirements to fill skill needs for K-MED users Creating and Mentoring Change Agents We work with KHPA to identify staff in each location who can serve as liaisons between the project team and users affected by the K-MED system. These change agents help interpret project communication messages and upcoming process changes for the specific users in their locations. This is particularly useful in an environment like KHPA where there are process and procedural differences among various programmatic and geographical locations. Change agents also serve as resources for their co-workers throughout the project. They serve a practical role in helping to prompt users in their areas to complete implementation readiness activities such as surveys or training registration. Generally, there is one change agent for each location. So, for example, each SRS location would have at least one change agent. In some instances, a location might be large enough for multiple change agents, or small enough to share a change agent with another small location. The change agent role includes the following responsibilities: Serve as project representatives to the KHPA employees in their areas Receive advanced knowledge of process changes and other project-related information Provide information about their areas to the KHPA team throughout the project Disseminate information and reminders to their areas about project status and schedules Participate in communication initiatives for their areas Gather information needed by the project Provide input to the project team from their areas (questions, concerns, issues, etc.) Monitor and support implementation activities in the department, such as completing readiness checklists Figure depicts how change agents play a crucial role in facilitating two-way communication between end users and other sponsor groups

261 Executive Sponsors own the change. They have the authority to legitimize and drive a change. Regional Sponsors have the authority to legitimize and drive a change for a particular region and/or function. Local Sponsors have the authority, responsibility, and credibility to advocate and drive a change for a particular site and/or function. Change Agents are influential people who are responsible for promoting and supporting the change at each impacted local site or department. End Users are all affected individuals who are required to live the change. (All Sponsors and Change Agents are usually also End Users!) Top Down Communication End User Change Agents Local Sponsors Regional Sponsors Change Agents Executive Sponsors Local Sponsors Regional Sponsors Change Agents Local Sponsors End User End User End User Change Agents Bottom Up Communication End User Lateral Communication on all levels K-MED Figure We utilize change agents and sponsors from all KHPA levels to foster communication and support for change After finalizing the list of change agents, we prepare and conduct a change agent kick-off to orient them to the project and their roles. The Enterprise Readiness Team mentors and supports the change agents through scheduled readiness meetings, targeted workshops, and tools/aids to facilitate change within the affected locations. Change agent meetings provide the change agents with new information about the project and upcoming business process changes, as well as the opportunity to ask questions. Change agents also attend readiness workshops that discuss how to complete implementation readiness items or explain a specific topic. An example is a role alignment workshop that explains the new roles and job changes. Change agents then take information back to their locations and conduct workshops with users. The project provides tools and aids, such as action item checklists and Change Discussion Guides, to facilitate the completion of tasks to prepare for go-live Leadership Alignment and Executive Sponsorship Agencies like KHPA that forge successful change within their organizations share a key trait: strong consistent leadership that supports a defined vision for change. The appropriate sponsorship must be involved throughout the project -- before, during and after implementation. The K-MED project sponsorship program starts with the project sponsor and Steering Committee and builds support throughout all levels of the organization to every user of the K-MED system. Implementing a defined project sponsorship approach helps to: Confirm the mission and objectives of the project are clearly understood by all involved Obtain commitment to the project from those with the authority to enforce decisions Obtain commitment to the project from those with responsibility for carrying out the work Validate that the project is publicly and privately supported by all levels of management Provide a medium for the ongoing dissemination of information Ensure that all the separate groups involved in the project are kept informed of each others activities so that duplication of effort can be avoided 7-261

262 Verify that policy and organization issues are addressed across organizational entities and that KHPA management is comfortable with all decisions. Figure depicts key leadership alignment activities Role Mapping Change Management team members will work with KHPA subject matter experts and members of the Accenture functional/business teams to document how the new business processes and the K-MED system will affect the various K-MED user groups. Information from this analysis helps inform several activities, including skills and gap analysis, as well as role mapping. As a part of the role mapping process, the team will complete following tasks: Identify the current roles within the organizations affected by the K-MED implementation (SRS locations, PE locations, etc.) Map existing roles to current ( as-is ) business processes and events Identify future ( to-be ) business processes Identify the changes in roles that are required to support the new business processes Analyze the relationships that exist between roles and how those relationships will be affected by the K-MED implementation Revise roles which support the new business processes The Change Team will integrate information about revised roles into the Change Discussion Guides Organizational Readiness As stated in earlier sections, the basis of many of the Change Management efforts, including Organizational Readiness centers around the differences between the as-is business processes and the to-be processes. Both Accenture and KHPA Enterprise Readiness Team members take a lead role in supporting the assessments of current business processes (the as-is model) and documenting the amount of change between the as-is and to-be. Having KHPA representation on the ER Team will facilitate this process. We design specific organizational readiness initiatives to address the gaps. Examples of readiness activities include the following: Create Change Discussion Guides Identify the expectations of each sponsor for K-MED Establish a shared K-MED vision and project goals Articulate clear vision to stakeholders Deliver targeted messages such as introducing specific changes or modeling desired behaviors and attitudes Drive and implement the desired changes Timely resolution of issues and interactions with the project Leadership Alignment One-on-one interviews Executive workshop and orientation K-MED Communications strategy and coaching Communications strategy and coaching Coaching Monthly sponsor briefings and coaching K-MED Figure We identify and align the expectations of K-MED leadership and sponsors with the project organization structure and goals to actively engage them throughout the project lifecycle After identifying change recommendations, Enterprise Readiness Team members develop role-specific Change Discussion Guides that describe the process changes that affect job functions and roles. The ER Team conducts workshops with the change agents to explain he information in the guides and prepare the change agents to deliver the material back in their own 7-262

263 areas. Change agents use the guides to generate discussion among managers, supervisors and staff in their locations about how business processes and job roles would change with the new system. Conduct Readiness Workshops Readiness workshops are dedicated sessions that focus on identifying and communicating changes to business practices, processes, and procedures. The main goal of Readiness Workshops is to help organizational units prepare for implementation by demonstrating features of the new system and giving them the tools and the time to plan. Workshops are conducted prior to skills training. The objectives of Readiness Workshops include the following: Give organizational units the time and opportunity to think through personnel, process and operational decisions about how to successfully implement the K-MED system in their areas Communicate known operational and job changes to affected staff Improve training effectiveness, because participants can focus on how to perform tasks in K-MED, rather than how their operations and jobs will change Give organizational units and liaisons specific Implementation Readiness Tasks for items that need to be completed prior to implementation Minimize disruption to the work of KHPA staff during and after implementation by establishing revised business processes early. We work with the KHPA Project Change Readiness Manager and the KHPA Communications Lead to determine the timing, pace and content for the workshops. Workshops are generally presented by program or project experts to unit management, change agents, or other select users who can then conduct the workshops themselves as needed. During the workshops, facilitators and users work together to identify the change implications of new business processes and technology. Cross-area issues may be uncovered as well, since people from various programmatic or geographic offices may attend the same session. An important component of change readiness is providing areas with tools to make critical decisions before implementation. These decisions may include such diverse items as: Determining who will have access to view, enter, and update information Determining how tasks not handled by K-MED workflow will be assigned and completed Determining any personnel changes (i.e. will everyone be performing the same tasks they do now, or are changes needed?) As a part of each readiness workshop, participants receive the following tools: A list of action items that includes information for each decision they need to make A schedule for decisions to be made and implemented Documentation outlining the future K-MED process flows for the processes covered in the session Production Transition The Enterprise Readiness team conducts the following activities to support the transition to production K-MED: Work with designated KHPA executives and the K-MED Implementation Manager to plan for production transition 7-263

264 Establish a network of Change Agents and Regional Implementation Leads who assist in preparation for rollout Prepare Implementation Readiness Checklists to track preparedness Support Regional Implementation Leads as they prepare the locations and users in their regions Conduct readiness reviews at 90, 60, and 30 days prior to go-live, and weekly during the month prior to deployment Track readiness in an overall tracking tool that contains each location and the status Near the beginning of the project, the ER team works with KHPA Leadership to identify one or more KHPA representatives per region to serve as Regional Implementation Leads. The Regional Implementation Lead is the person responsible for supporting, monitoring and reporting on production transition readiness for all locations in the region. Because the K-MED implementation affects SRS users and sites, we recommend that they also participate in readiness planning and transition activities. For example, SRS could also designate an Implementation Lead to focus on site preparedness for their affected locations. Likewise, the Clearinghouse may want to designate its own Implementation Lead due its unique business processes and implementation challenges. We assign one member of the ER Team per region who works closely with the State Regional Implementation Lead throughout production transition. The ER Team conducts formal readiness reviews with the regions to confirm everything is on track for a successful K-MED implementation. Reviews occur at the 30, 60 and 90-day periods prior to go-live and weekly during the month prior to deployment. Implementation Readiness Checklists At regular intervals prior to implementation, the Enterprise Readiness team distributes readiness checklists to the locations affected by the K-MED implementation. Checklists include all tasks the locations need to complete prior to go-live, with assigned target dates for completion. Readiness Checklists reduce implementation risks and minimize disruption to work at KHPA because they provide an organized way to track all the various tasks that are necessary for a smooth transition to production. Examples include: Is data cleansing on track so that the project can have a successful conversion? Are users mapped to security profiles? Are all users scheduled for training and/or has the training been completed? Are all PC s upgraded as necessary to run K-MED? As shown in Figure 7-115, items on the checklists come from the entry criteria defined in the Implementation Plan. Regional Implementation Leads work with each location in their regions to complete the implementation items listed on the checklist. The Enterprise Readiness Team supports the Regional Implementation Leads throughout the process. The ER Team travels to meet with the Regional Implementation Leads and to conduct site visits at select locations. The ER Team and Regional Implementation Leads identify readiness gaps related to site and/or people readiness, and manage them proactively. K-MED project management reviews readiness metrics as input into the Go / No-Go recommendation for system deployment Establishment of a K-MED helpdesk Strong Help Desk services are an integral part of Enterprise Readiness. The Enterprise Readiness Assessment Report will include information on the scope of the K-MED Help Desk 7-264

265 1.0 Executive Summary 1.1 Introduction 1.2 Document Organization 1.3 System Functionality Overview 1.4 Implementation Summary 1.5 Key Assumptions 2.0 Requirements 3.0 Implementation Approach 3.1 Strategy 3.2 Roles and Responsibility 3.3 Implementation Support Staff 3.4 Conversion Strategy 3.5 Process and Procedures 3.6 Deployment Approach 3.7 Planning Activities 3.8 Entry Criteria. 3.9 Exit Criteria Implementation Plan Table of Contents 3.10 Implementation Management Approach 4.0 Contingency Plan 4.1 Implementation Phase 4.2 Implementation Support Phase 5.0 Recovery Plan 5.1 Recovery Approach 6.0 Open Items 7.0 Appendices A. Implementation Schedule B. Proven Practices Sample Template C. Go-Live Weekend Checklist Template D. Implementation Readiness Assessment Checklist Template E. Risk Factor Calculation F. Sample Question Log G. Implementation Related Meetings Define Entry Criteria to coordinate the completion of critical path activities prior to the start of implementation K-MED users have completed readiness workshops Issue escalation process is defined and communicated to staff Conversion dry runs have been successfully executed Locations have reviewed and accepted their change discussion guide All required staff have attended K-MED training User names and passwords have been distributed to users Implementation Readiness Checklist Template Activity Team Contact K-MED users have completed readiness workshops Issue escalation process is defined and communicated to staff Conversion dry runs have been successfully executed Locations have reviewed and accepted their change discussion guides All required staff have attended K-MED training User names and passwords have been distributed to users Implementation Implementation Conversion / Implementation Implementation / Change Management Training Implementation Implementation Readiness consists of validating completion of each item on the list to verify that staff, system procedures, and support processes are ready for K-MED implementation K-MED Deployed Completed (Yes / No) Com Da K-MED Deployed K-MED Figure Accenture s Implementation team closely monitors the progress of the Implementation Entry Criteria as part of managing the project s critical path and how users will utilize the Help Desk for support through the various phases of the project. Please see Section User Support Services for more information about the K-MED Help Desk Implementing approved changes The proposal shall address how the assessment and implementation of approved changes will be managed We have outlined the key initiatives and approaches we see as the foundational elements of the K-MED Enterprise Readiness effort. The formal Enterprise Readiness Assessment report defines the appropriate emphasis to place on each element of the effort and the specific characteristics of the initiatives. For example, we know that a Communication Plan is essential to the overall Readiness approach. The Enterprise Readiness Assessment Report shows the specific communication channels, targets and messages to incorporate into the Communication Plan. We know that Sponsorship is a crucial element to project success. The Enterprise Readiness Assessment Report addresses details of how various sponsors of different levels and organizations should work together to achieve project objectives. After the Enterprise Readiness team works with K-MED leadership to refine the Assessment Report, the revised report becomes the K-MED Cultural Change Management Plan. The Change Plan guides the activities conducted by the Readiness Team. Accenture and KHPA team members work together to implement the initiatives outlined in the plan. It shall also outline any experience the Proposer may have in completing Enterprise Readiness Assessments for other organizations, and the results that were achieved Prior Experience We have implemented enterprise readiness assessments for numerous public services clients, 7-265

266 and incorporate enterprise readiness initiatives into all of our successful implementations. The following is a representative list of similar projects where we have conducted Enterprise Readiness Assessment activities: California C-IV Consortium New York City HHS-Connect Merced County MAGIC Ontario Ministry of Community and Social Services State of Maryland s Department of Human Resources Client Information Systems (HRCIS) Nebraska N-Focus Texas IMPACT and Mobile Protective Services (MPS) Norwegian Labour and Welfare Administration Norwegian Pension Idaho IBES Integrating Enterprise Readiness Assessment activities into our project methodologies yields positive business and implementation results. Examples of results achieved include the following: The Change Management Team at C-IV employed business process assessment methodologies to identify changes to processes, job roles and skill needs. The resulting change management program prepared 12,000 users and 200,000 providers for a successful implementation with minimal business disruption and with no increase in eligibility error rates in the Counties. The HHS-Connect project conducted process and stakeholder analysis, communication needs assessment, organizational impact analysis, and training needs assessment to lay the foundation for effective enterprise readiness efforts. The HHS-Connect project has resulted in improved access to information, greater data sharing between agencies, coordinated agency practices and improved case management. As part of the Ontario Ministry of Community and Social Services project, Accenture provided recommendations and prioritization input regarding business process changes and enterprise change readiness. The Ontario automated eligibility system has achieved savings of $692 million over 5 years by improving error rates, reducing fraud, and delivering legitimate benefits more quickly to the families in need. Enterprise Readiness initiatives at the Texas Department of Family and Protective Services supported caseworkers through the transition to mobile technology that provides access to critical case information in the field. Users can now capture case documentation anywhere, anytime, directly into a mobile version of the IMPACT system. Accenture and the Norwegian Labour and Welfare Administration implemented extensive changes to all pension administration processes, which helped reduce application processing time from three months to just a few minutes. Extensive skill training and change management efforts helped users learn and use the revamped processes effectively. The 18-month implementation of the Idaho Benefit Information System was the lowest cost, quickest implementation of a transferred system in the last 20 years

267 User Support Services We provide an effective mix of electronic and human service options that supports K- MED users throughout implementation and beyond. Strategy and Approach The Proposer shall define and describe its User Support strategy and approach. The Proposer shall also respond to the detailed requirements related to User Support referenced in RFP Appendix 1 in the User Support Requirements Workbook. Our User Support approach addresses the needs of K-MED s diverse user groups through an effective mix of human and electronic support methods Varied approach includes self-service options users can access directly from the system Online Help, Job Aids, Web-based Training, System Documentation, and a Sandbox environment help users become self-sufficient Accenture works side by side with KHPA to establish the K-MED Service Desk Our strategy is to offer a variety of tools and methods that address the needs of the diverse K- MED user population - from the citizens of Kansas who need support during benefits application, to seasoned eligibility workers who want to minimize disruption to their jobs by finding answers on their own. For this reason, our User Support Services approach features selfservice tools such as role-based online user procedures, as well as human support in the form of onsite support and technical help desk services. The Contractor shall provide technical support services for all users, including system logon, navigation, and functionality. As K-MED will be used by a wide range of individuals with different roles and skill levels, various types of technical support services must be offered to meet the support needs of all users. KHPA expects users to have access to a range of user support resources and options to use to quickly resolve a problem or question. User support services are role-based where appropriate. In addition to the K-MED Service Desk (also referred to as the K-MED Help Desk), K-MED users benefit from a range of User Support resources including the following: Online Help and Job Aids Users can access role-based user procedures and desk aids, directly from the K-MED system Web-based training Users can refer to their web-based training courses to refresh themselves on problematic concepts or get a quick answer Sandbox Environment Users may access the sandbox at any time to practice a scenario in a risk-free environment that mirrors production. This is a hands-on way to see how the system performs without risking changes to the production K-MED system System Documentation Technical users can access the User Support Guide and other system documentation to find what they need quickly Change Agents Users receive support from their change agents, State personnel assigned to each location who can provide insight and support in the days leading up to and after deployment Regional Support Teams During the days immediately following deployment, users can seek support from their onsite support K-MED team member. During deployment and afterward, regional support teams will be available for questions and can pull together ad hoc target training sessions to address issues

268 K-MED Service Desk We propose that KHPA and Accenture work together to establish a K-MED Service Desk onsite in Topeka that would be staffed with State personnel. In our approach, we use our Help Desk experience to support KHPA through the process of creating an effective K-MED Service Desk. Your dedicated State personnel who have been performing in application development, testing, and technical roles during earlier project phases transition into support and maintenance roles for the post-implementation and ongoing operations phases. For example, members of the business functional teams use their knowledge of the K-MED system and revised business processes to provide Tier 2 support for K-MED users. Technical team members transition into Tier 3 roles. Operating a KHPA-staffed Help Desk with our support provides KHPA the opportunity to realize the following benefits: Leverage Accenture s extensive experience in establishing successful Help Desks Jumpstart KHPA s long term capability for supporting the K-MED system Take advantage of the experience and knowledge your dedicated resources develop during the implementation phases of the project Develop proficiencies among KHPA staff that will facilitate a smoother turnover at the end of the contract Reap significant cost savings when compared to staffing Accenture resources on the Help Desk APSP Service Desk The scope of services provided by the APSP Service Desk does not change in our proposed model. The APSP Service Desk remains available to deliver product support services as outlined in Section 6.4, Product Maintenance. Figure depicts the flow of information between the K-MED Service Desk, APSP, and other third party product support. Accenture Support Accenture has extensive experience helping our clients establish effective Help Desks. We bring personnel, tools and templates to facilitate the process. We would customize our approach for Phase 1 and Phase 2. Phase 1 focuses on establishing the Help Desk infrastructure. Experienced Accenture resources spend time with you prior to Phase I implementation helping you perform the initial tasks required to set up the Help Desk and prepare to support Phase I functionality. Tasks during this period of time include the following: Problems/ Requests K-MED Help Desk Tier I Triage Open Ticket Log and Track KHPA Users Resolutions Open Ticket Close Ticket Verify Resolution Close Tickets Problem Tracking System KHPA User Support Call Flow Inquiries, Resolutions Telephone / Webpage / / Remote Control Ticket Assignment Resolution or Pass-back K-MED Help Desk Tier II and III Triage Log and Track Resolve Problems Software Consultation Verify Resolution Close Tickets Report Key KHPA APSP Svc Desk APSP Public Assistance Self-Service Third Party Oracle, etc. Product Support K-MED Figure K-MED Tier 2 and 3 Service Desk personnel escalate issues to the APSP Service Desk and other third party COTS products as needed 7-268

269 Developing Help Desk policies and procedures Developing Help Desk scripts Working out initial procedures for escalating issues and communicating with the APSP Service Desk Selecting and integrating an AVR/AA system and a ticketing system Integrating the ticketing system with the APSP toolset Locating and implementing telephone translation services Training Tier 1 Help Desk personnel to properly take and record incidents Support for Phase 2 focuses on preparing KHPA Project personnel transition to their Tier 2 and 3 Support/Maintenance roles. Our approach includes three full-time Accenture resources who work with the State to train KHPA staff, launch the Phase 2 Help Desk and support Help Desk operations. User support services provided for the public shall accommodate non-english speakers and diverse populations. We plan to work with you to establish the ability to support multiple languages. Next to English, the most common language spoken in Kansas is Spanish, with significant percentages of certain counties speaking Spanish as a first language. Accenture accommodates other languages through the use of telephone translation services. If we are selected as the State s contactor, we will work with you to confirm the appropriate languages for translation so that we can help you arrange an appropriate solution for telephone translation. Based on our understanding of language requirements within the state of Kansas, the following languages are likely candidates for telephone translation services: German Vietnamese Russian Hmong Lao Somali Swahili Arabic Farsi The Contractor shall provide user support through all Implementation Phases, including the Pilot Phase. If we are selected as the State s contractor, we will provide user support (online help and job aids, refresher web-based training, sandbox training environment, onsite support and Help Desk consulting services) beginning with the Pilot Phase and continuing through the project, as outlined in the proposal. We work with you to define the required service levels to accommodate increased usage during peak need stages of system development, implementation and operations. The Contractor is not expected to provide policy or program support, but KHPA will provide approved scripts to respond to general program questions received by the public. KHPA-approved scripts provide an important means of referring customers to the appropriate resource for program questions and support. We recommend housing the scripts in an online knowledge base that is accessible to all Help Desk personnel

270 Customer Support Levels Each proposal must include a description of the number and types of staff as well as any automated or electronic services that will be used. Accenture defines customer support levels using the following terminology: Tier 1: Tier 1 resources gather the customer s information and determine the customer s issue by analyzing the symptoms and figuring out the underlying problem. Tier 1 resources typically handle basic problems, including resolving username/password issues or basic help application usage. They escalate those they cannot solve to Tier 2. Tier 1 support typically resolves 65-70% of the contacts to the Help Desk with a handle time of 12 minutes per contact. Tier 2: Tier 2 resources perform more advanced technical support than Tier 1. Tier 2 resources work with Tier 1 personnel to solve basic technical issues that do not require code changes, confirm escalated issues and review completed troubleshooting tasks. They validate reported incidents against system requirements to determine if the system is performing as designed. Tier 2 resources attempt to fix any known issues and immediately escalate any new or undocumented issues to Tier 3. In addition, Tier 2 determines if the problem requires APSP Product support and directs the incident to the APSP Service Desk if warranted. Tier 2 support typically resolves 80-85% of the incidents passed to Tier 2. Resolution times at tier 2 vary depending on the complexity of the incident. Tier 3: This tier supports Kansas customized code and COTS interface support for the K- MED system. Tier 3 resources are responsible for handling the most difficult or advanced issues. Tier 3 resources closely review all tasks and troubleshooting completed on the issue prior to Tier 3. Like Tier 2, resolution times vary on the complexity of the incident. Figure includes the number and type of resources we propose for staffing the K-MED Help Desk. We propose identifying 6-7 KHPA staff to provide Tier 1 services throughout the project. For Tier 2 and 3 support beginning during Phase 2, we propose transitioning 13 KHPA staff from project roles to support and maintenance roles. During and after Phase 2, three Accenture resources provide guidance, training and support for help Desk staff. We propose the hosting provider support database functions. Type of Staff Number Varied Roles as identified by KHPA (Tier 1 Support) 6-7* Business Functional Team (Business Analyst) 1 Business Functional Team Manager (Tier 2 Lead) 1 Business Functional Team Member (Tier 2 Support) 4 Technical Team Manager (Tier 3 Lead) 1 Technical Team Developer (Tier 3 Support) 3 QA System Tester (Testing) 1 QA System Tester (COTS system analysis/coordination) 1 QA Tester (Security Management) 1 Hosting Provider (DBA Logical Infrastructure) 1 Hosting Provider (DBA Physical Infrastructure) 1 Hosting Provider (Development Environment Support) 1 Account Director (Accenture) 1 System Manager/Deputy Account Director (Accenture) 1 Application Maintenance (Accenture) 1 * We used our experience on other similar engagements to develop the estimated number of Tier

271 Type of Staff Number resources. We based our estimate on approximately 36,000 contacts placed by 1350 users annually at industry-standard productivity rates and call times. The estimates reflect additional time to account for an unknown volume of calls from the public. We will work with KHPA to determine the appropriate citizen call volumes to use for revised estimates after project initiation. Figure We propose a mix of KHPA, Accenture and hosting provider resources to staff the K- MED Help Desk. The Contractor shall provide access to the technical / help desk support 24 hours per day, seven days a week. Access to personnel (telephone, , etc.) must be provided a minimum of Monday through Friday, 7 am to 7 pm, and Saturday and Sunday, 8 am to 5 pm, except State holidays. The Vendor shall provide details regarding coverage for after hours support, such as an automated paging system, built-in notification, or other alternatives for emergencies. At a minimum, the Contractor shall provide a toll-free telephone service, a toll-free facsimile line, online services, services, and User Manual / Guides which are easily accessible from the system. An Automated Voice Response System (AVRS) or Automated Attendant (AA) shall be provided with system selections based on criteria approved by KHPA, as outlined in the RFP. As part of the establishing the Help Desk infrastructure with you, we help you establish the complete schedule for coverage, after hours emergency procedures, and intake methods (telephone, fax, , AVRS/AA). We provide user manuals/guides which are accessible directly from the system. The Proposer must clearly outline the mix of electronic and human service functions included in the proposal. Our proposal includes a mix of electronic and human services functions as outlined in Figure Electronic Human Online Help, Job Aids and Online User Manual Help Desk Personnel Phone, , Fax (recommended) Change Agents AVRS (recommended) Onsite Support Personnel Web-based Training Sandbox environment Figure We propose a range of user support functions to support K-MED users diverse needs of K-MED users. The help desk / technical support personnel shall be knowledgeable and technically trained to answer / resolve K-MED System technical support problems. The Accenture resources supporting the K-MED Help Desk effort provide consistent knowledge transfer throughout the project and post-implementation support period to prepare KHPA staff for Help Desk operations. We work with KHPA to provide and adjust the activities that KHPA finds most effective. For example, Accenture staff provide direct support to Tier 2 and 3 resources during deployment and post-implementation, providing assistance during calls if needed. We also offer to shadow customer calls or conduct call simulation training where KHPA staff practice root cause analysis activities. KHPA support and maintenance resources will participate in APSP training in preparation for their roles

272 The help desk staff shall be able to answer how to type questions about the K-MED System, as well as questions about hardware and Internet setting configurations, and assist with password or log-on issues, including password reset methods. Include levels of human involvement necessary for each procedure. We work with you to define the types of how to inquiries that the Help Desk fields. Users can answer most how to inquiries by referring to online help procedures and job aids, or by contacting support personnel during the onsite support phase of the project. In our experience, the number of these how to questions declines quickly after implementation, as users get more familiar with the system. During the course of providing technical support, functional questions do arise, and Help Desk Tier 2 personnel are able to provide support for functional issues. Help Desk personnel educate the user on the online help and job aids that are accessible through the K-MED application. Help Desk personnel have access to KHPA scripts as well, so that they can make the appropriate referrals for program and policy questions. Figure depicts the level of human involvement necessary for common procedures. Procedure Level of Human Involvement How To questions No human involvement is necessary. Users Can refer to Online Help to view how to type information in easy to follow steps. The user can view refresher web-based training or practice in the sandbox environment. Hardware questions Some human involvement necessary to understand the nature of the question and determine appropriate action Internet setting configurations Some human involvement necessary to understand the nature of the question and determine appropriate action Password/resets Some human involvement necessary; however, the State may choose to consider an automated password reset tool to reduce the level of human involvement required Figure Users have self-service alternatives that minimize the need for human involvement, while always keeping human interaction as an option Contact & Response Times Users must have questions and issues dealt with in a prompt, courteous, and secure manner. Telephone calls and s must be picked up and answered quickly and securely, as outlined in the RFP. During the process of setting up the Help Desk infrastructure, we focus on training Tier 1 resources to deal with issues in the manner outlined in the RFP Grievances The Contractor shall document and investigate and resolve all grievances in a courteous and prompt manner. Grievances may include: 1. Untimely resolution of issues; 2. Unclear or inaccurate information given by staff; 3. Lack of action on a problem; and 4. Business relationship issues, such as attitude or lack of respect. All grievances are reported on the User Support Log. Our project team members are motivated to address user issues and minimize disruption to KHPA business. We will help KHPA achieve your goals for the grievance process by: 7-272

273 Working with KHPA to develop appropriate response and resolution time guidelines and other metrics Providing Accenture resources to support the Help Desk who exhibit positive attitudes and value customer service Helping select and integrate the User Support Tool for tracking grievances Establishing a process to identify and resolve problems early Working with KHPA to establish a customer satisfaction process Electronic Support System / User Support Log The Contractor shall provide an electronic support system for tracking and data collection in the User Support area. The system shall track all problem reports and keep a detailed log of all maintenance / technical support calls and inquiries made to help desk / technical support personnel. This will serve as a record for technical issues as well as for grievances or complaints which need resolved or reviewed. The User Support Log shall be accessible to KHPA each month, or upon request of KHPA. The log must include information on calls, s, and voice mails. It must indicate which type was received and how / when the issues were handled. The Contractor must provide summary reports of User Support activity monthly. If we are selected as the State s contractor, we plan to include tool selection and integration in the services we offer to KHPA prior to Phase User Support Prioritization of Calls KHPA expects the Contractor to prioritize issues coming into the Help Desk. Some issues must be resolved immediately. The department reserves the right to determine and assign levels of severity for the issue / support problems. The severity of the issue / support problem shall determine the problem resolution response time in any calendar month of the contract as outlined in the RFP. We plan to work with KHPA to establish the processes for assigning priority and severity levels and to configure an electronic support system to support the State s requirements Problem Resolution Response Time KHPA defines problem resolution response time as from initial contact to final resolution. Initial contact is defined as Contractor s qualified service technician has been contacted by the end-user and the system error / nonconformity severity level has been determined. Final resolution is defined as the time that the issue or problem has been fixed, tested, and verified by KHPA as being resolved. We understand the State s problem resolution response time definitions and will work with you to put the processes in place to meet your response time requirements User Support Requirements We have outlined our approach in this section of the proposal. Please see specific responses to each requirement in the User Support Requirements workbook

274 Deployment (Rollout) Support Services Accenture brings unique tools, methodology and experienced staff, which would deliver deployment and post-implementation support to the State of Kansas while adding value and reducing implementation risk KHPA requires the assistance and expertise of the Contractor to put the proposed solution into production at all K-MED locations. The Proposer shall describe its approach, and the services and level of staffing needed to ensure a successful deployment of the K-MED System. We have managed the deployment of our proposed solution in numerous health and human service implementations. Most recently, this includes the multi release implementation of C-IV in 39 counties in California and the statewide deployment of Idaho IBES. We acknowledge that the success of the K-MED implementation relies on thoughtfully tailoring our methodology to address KHPA s unique challenges. This is why based on our experience and knowledge of the State s needs we have developed an approach to support deployment and confirm the readiness of the organization as well as that of the system components. Successful system deployment is the result of activities that happen prior and post cutover. Figure shows how these activities surrounding system deployment impact the success of the transition into the new system. Features Transition begins on Day 1 of the project Commitment to minimizing work disruptions Robust support framework post system deployment Our deployment approach will result in a successful transition with minimal disruption to participants and State operations Accenture deployed the C-IV system to 39 counties in California for a total of 25% of the State s welfare caseload Accenture created a Common Client Index (CCI) for the HHS-CONNECT Project that set the foundation for exchanging and sharing client and program data between programs and agencies We draw upon our deep experience to provide step-by-step guidance in development of automated and manual deployment processes We conduct dress-rehearsals of critical steps to confirm the team is well prepared Benefits to Kansas Accenture and State collaboration maximizes knowledge transfer from day one in preparation for system deployment and post production ownership Improves solution ownership through engagement of State employees throughout the deployment process and post implementation support End Users and State operations team learn the skills to support the system at go-live Pre-testing of all conversion procedures prepares the ground for a smooth and uneventful deployment Honesty and transparency through all conversion activities create no surprises for the State during cutover Key Implementation Team members provide onsite support for 6 months after Go-Live Additional support provided during the critical system stabilization period after go-live State of Kansas operations staff will have additional time to learn and transition from the Accenture team Figure Our deployment approach is a comprehensive strategy that fosters a smooth transition to operations; it emphasizes State ownership, and provides unparalleled on-going software support As depicted in Figure 7-120, a well thought out deployment approach is the culmination of a sequence of activities happening before, during and after the specific system cutover. For KHPA, this means that we take a comprehensive look at deployment, assess all items that may have an 7-274

275 impact on the implementation of K-MED, and work with you to create a strategy that minimizes risk and promotes a smooth and uneventful deployment of K-MED. Our goal is to have no surprises that can impact business operations and hamper user s transition to the new solution. Pre-deployment transition activities, conversion happening throughout the project, and the specific cutover activities to deploy the application support the transition. Production Transition Prior to deployment, the enterprise readiness team will work with the central and regional offices to get users ready for the transition into the new system. This team will work with KHPA to conduct readiness reviews, complete implementation checklists, and assess the users and the organization s overall readiness. We will also work with you to establish User Support Services that are effective at delivering support to the organization. This pre-deployment work that the enterprise readiness team conducts with KHPA is foundational for the success of the application rollout and its acceptance among users. Conversion - In addition to working with KHPA on production transition readiness, and as part of our overall deployment strategy, we will extensively test our conversion processes prior to executing any final data conversions. The Conversion team will complete all Conversion Build activities including Unit, Assembly, and System Test so that Mock Conversions (or migration rehearsals) can begin approximately 3 months prior to go-live of Phase Two implementation. These tests will simulate the final implementation across all areas including application, technical infrastructure, conversion and implementation support. Mock conversions will help us to confirm the details unique to the implementation of K-MED and its associated impacts. We would verify that we could complete all deployment readiness activities in the allotted time in order to prepare for the final conversion and deployment. Results from Mock Conversion will help us refine our cutover plan. We would also work with the Kansas Project Management team to determine acceptance criteria for transitioning from the KAECSES-AE system to the new K-MED system. Additionally, acceptance criteria are used to address the readiness of other items that must be in place prior to cutover such as help desk support, the completion of data conversion, user training, and documentation. The resulting criteria would serve as an input to a deployment and cutover plan deliverable. Legacy system data will be of sufficiently high quality to enable a high degree of data integrity for inbound data to the new system. Key features of legacy data that are required include: Unique identifiers present in all legacy databases to associate data with cases, individuals and/or families as appropriate. Linkage of identifiers between disparate source systems to reliably de-duplicate source data and resolve case and/or individual association issues Limited amount of duplicative case and/or individual data that must be resolved for clarity and accuracy as it is converted into the new system and specific, acceptable rules for determining which source system has precedence when duplicate information exists. The legacy system administrators will provide the extract source files from legacy systems in a mutually-agreeable format for testing purposes and the formal conversion. These files will be made available early enough to support unit testing, system and integration testing, and user acceptance testing by the team. The legacy system administrators will provide the mutuallyagreed upon detailed reports for each source file to allow for data verification and control totals. Cutover Pre-deployment production transition and conversion activities would be completed and tested prior to the deployment of K-MED. Their successful completion would serve as a barometer for all deployment activities and their expected results. During cutover we 7-275

276 would execute the steps necessary to successfully deploy the K-MED solution into the production environment. The days immediately leading to K-MED go-live we will execute and complete all deployment activities as stated in the Deployment / Roll-Out Plan (Detailed Conversion Cutover Plan). We have successfully used this comprehensive approach to system deployment in most of our health and human services implementations. For example, most recently we worked with different counties to coordinate deployment of the C-IV system in 35 counties in California. The C-IV system is an integrated case management system that supports multiple public assistance programs. We released the system in three waves. In preparation for each deployment, we worked with the State and the impacted counties on change and implementation readiness activities, communicating changes, completing data conversion and mock conversions. Throughout the project activities, we worked closely with consortium staff to facilitate knowledge transfer and to accomplish the ultimate goal of State ownership of the system. Our approach helped us prepare users, consistently convert legacy data and set the scene for a smooth transition into the new application. In order to prepare for these deployments, we worked with the State to define the activities needed to deploy the application, to identify risks and mitigation plans, and to minimize disruptions to operations. We also defined an effective escalation process for issues that came up during cutover. This thorough planning, along with the activities that were completed prior to deployment, and a robust post-implementation support structure made C-IV a success. We were able to deliver a system that is flexible as it quickly responds to changing needs in policy and legislation; a user-friendly system that eliminates the need for manual workarounds and makes accurate determinations; and, overall, a C-IV system that has improved productivity and provides better citizen services. Another example of our success with system deployments is the deployment of HHS- CONNECT in New York City. HHS-CONNECT was implemented to provide an enhanced tool for case management to accomplish the City s goals of improved accessibility, transparency and accountability of city government. From childcare to assistance for the aging, New York City s nine Health and Human Services (HHS) agencies provide essential benefits and services, helping to protect the health and well-being of the City s eight million residents, particularly those who are least able to help themselves. Through a successful system implementation, we helped deliver more holistic health and human services rather than only solving immediate, ad hoc needs. We worked with the Department of Information Technology and Telecommunications (DoITT) to define the best deployment strategy and to document the activities necessary to successfully deploy the application to all users. Our implementation of HHS CONNECT has enabled the largest city in the United States to dramatically transform how it operates, serves customers, and measures performance by breaking down information barriers among its agencies. Please refer to Technical Proposal Tab 11 for our proposed levels of staffing. Deployment / Roll-Out Plan KHPA also requires a detailed Deployment / Roll-Out Plan deliverable. Listed below are some aspects of the deployment / roll-out process that KHPA envisions. Proposers shall expand on the concepts articulated here and propose any other deployment / roll-out activities that are applicable. Comprehensive pre-testing of key deployment procedures. Pre-staging of all components to the extent possible

277 A detailed deployment and conversion schedule, with the cut-over components planned at the hour or minute level, orchestrating all tasks, both manual and automated, that need to occur during the deployment period. This shall include every aspect necessary to ensure a smooth and successful cut-over. Detailed checklists for individuals engaged in executing deployment and cut-over tasks. Comprehensive data integrity checkpoints to confirm that all data has been successfully converted. Multiple back-ups at various recovery points so that a minor error discovered during deployment does not mean a complete start over from step one. A special reporting structure or protocol for problems and bugs to ensure that trouble shooting and defect correction can proceed without major interruption. An onsite all hands on deck support structure. System performance monitoring during cut-over. Key GO / NO GO decision points, with a comprehensive roll back plan in the case of a serious error that cannot be corrected on the fly during the deployment process. The existing systems would then be re-installed and the implementation of the new K-MED System would be delayed until the error is corrected. Retirement planning and schedule for relevant existing processes and systems or components of systems We will work with KHPA to prepare a detailed Deployment / Rollout Plan (Detailed Conversion Cutover Plan) similar to the sample plan provided in Figure that would list deployment tasks and metrics in sequential order by date and by time with resources assigned. The purpose of this plan is to detail all activities that will be necessary to get the new system up and running on time so that users can start processing medical eligibility claims first thing after go-live. The plan would outline the when and Deployment / Rollout Plan Table of Contents Executive Summary... Introduction... Approach... Scope & Objectives... Deployment Approach Strategy Objectives... Scope of the K-Med Deployment... Overall Approach... Key Principles... Approach Defined... Outcomes... Critical Success Factors... Stakeholders... Management, Control, and Reporting... Progress Monitoring and Reporting... K-Med - Measurements of Success... Implementation Risks... Timeline and Key Milestones... K-Med Deployment Roles and Responsibilities... K-Med Deployment Core Team:... K-Med Deployment Team:... K-Med Management... K-Med Deployment Tools... K-Med Deployment Transition Timeline... APPENDIX A - Deployment Checklist... K-MED Figure The Deployment/Rollout plan defines the overall framework for the deployment of the new system and it enables consistent communication of K-MED deployment activities how for the application to get rolled out to the target deployment groups and sites, as well as the tasks necessary to prepare for the rollout. This deliverable would help key stakeholders understand the deployment activities, including their roles and responsibilities as it would define: The overall deployment plan The deployment activities The responsibilities of each of the participants involved in the K-MED deployment The overall schedule and milestones for the K-MED deployment We will review the plan with cutover participants ahead of time. This review would confirm that the Deployment / Rollout Plan, along with the Data Conversion Plan include all tasks that the team would perform, including the ones identified in Figure The Deployment Plan would also allow the 7-277

278 combined team to identify any issues and key dependencies, and take corrective action without jeopardizing the cutover schedule. We will look at KHPA to work with us on obtaining approval for the plan from key stakeholders, to communicate cutover timeframes, and to communicate the plan to the larger user community. We would also use the approved plan to monitor and track the status of cutover and deployment activities. KHPA Requirements Comprehensive pre-testing of key deployment procedures Pre-staging of all components to the extent possible A detailed deployment and conversion schedule, with the cut-over components planned at the hour or minute level, orchestrating all tasks, both manual and automated, that need to occur during the deployment period. This shall include every aspect necessary to ensure a smooth and successful cut-over Detailed checklists for individuals engaged in executing deployment and cut-over tasks Comprehensive data integrity checkpoints to confirm that all data has been successfully converted Multiple back-ups at various recovery points so that a minor error discovered during deployment does not mean a complete start over from step one A special reporting structure or protocol for problems and bugs to ensure that trouble shooting and defect correction can proceed without major interruption An onsite all hands on deck support structure System performance monitoring during cut-over Key GO / NO GO decision points, with a comprehensive roll back plan in the case of a serious error that cannot be corrected on the fly during the deployment process. The existing systems would then be re-installed and the implementation of the new K-MED System would be delayed until the error is corrected Deployment / Roll-Out Plan Activities During mock conversions we would work with cutover participants and key stakeholders to perform comprehensive pre-testing of key deployment procedures such as security access mapping and validation Mock Conversions would be conducted in environments pointed to converted data We will work with KHPA to prepare a detailed Deployment / Rollout Plan that will list all deployment tasks and metrics in sequential order by date and by time with resources assigned necessary to get the new system up and running The Deployment / Rollout Plan is a checklist detailing the cut-over activities. It will be used to aid the deployment team in stepping through all of the necessary conversion activities in logical order, identifying responsibilities and hand-offs Data integrity checkpoints will be performed at different points during the cut-over data Extract, Transform and Load (ETL) process Our team would take a snapshot of the staging database legacy source data. If minor errors occur during cut-over, we would refer back to this data for individual data fixes after cut-over is completed If problems are discovered during cut-over, the team would quickly resort to the reporting structure established to escalate troubleshooting and defect correction All deployment activities will be supported onsite by the conversion team Our expectation is that the legacy system and the new application will be non-operational during cutover. Nothing would be processed while conversion is in progress. System performance monitoring will be done after cut-over activities are completed The mock conversion review results would support sound and objective GO / NO GO decision-making prior to deployment. Our iterative Mock Conversions prior to cut-over will help us identify any problems in the system in advance, thus giving our team sufficient time to address any remaining issues before they delay the cutover and deployment schedule 7-278

279 KHPA Requirements Retirement planning and schedule for relevant existing processes and systems or components of systems Deployment / Roll-Out Plan Activities We will work with KHPA s legacy system administrators to coordinate the retirement of the legacy systems based on business processing Figure We know KHPA s concerns about a smooth cut-over and we are prepared to address those concerns as we have experienced them in hundreds of previous implementations During mock conversions we would work with cutover participants and key stakeholders to perform comprehensive pre-testing and pre-staging of key deployment procedures such as security access mapping and validation. During this activity, and prior to full data conversion execution, we would conduct data reviews to confirm that the data is complete and accurate. These reviews would confirm that core, interface and legacy components are ready for cut-over. Conducting these reviews further reduces risk to Kansas as it adds an additional layer of testing prior to deployment. Since the reviews would occur prior to the actual cutover, we would have sufficient time to address any remaining issues before they delay the cutover and deployment schedule. We would take the results of these reviews and use them to further define the activities and specific steps in the deployment approach and Deployment / Roll-Out Plan. The review results would also support sound and objective GO / NO GO decision-making prior to deployment. As stated, the mock conversions are an important part in refining our cutover approach as they lay the basis for a solid and effective deployment plan. We work with the resources listed in the Data Conversion Plan to develop a separate environment and execute these practice deploymen3 runs for the Mock Conversions and for the User Acceptance Test as illustrated in Figure While executing practice runs, we measure the timing and sequencing of each step in the process. We revise the deployment and conversion schedule based on the results recorded. Lastly, we meet with participants to discuss the results of the practice run and revise the deployment and cutover plan based on their observations. Once the practice run is complete, the Accenture team would prepare the target environment for the final transition according to the steps listed in the Data Conversion Plan. Actual cutover involves the Extraction, Transformation and Load (ETL) of the legacy data into the K-MED system and the transition of batch and interface processes. The Deployment / Rollout Plan will be a checklist detailing the cut-over activities and it will be used to aid the deployment team in stepping through all of the necessary conversion activities in logical order. Analyze Design Build Test Deploy Assess Deployment Readiness Prepare for Migration Authorize Deployment Set Up Deployment Environment Convert Data Migrate to Production Roll Out Application Fine Tune Application Support Production Environment Launch Communication Effort Transition Deployed Application Launch Training Perform Production Simulation Roll Out Organization K-MED Figure Our tools and models consistently deliver deployment phase functional, technical, and people-specific best practices throughout our implementation resulting in successful completion of project activities 7-279

280 We will update and refine the checklist after the Conversion Team completes each Mock Conversion. This checklist outlines the order, timing and dependencies in which scripts and procedures are run so that the conversion cut-over timeline will be followed. Additionally, the checklist will be closely monitored throughout cutover allowing the deployment team to track status, make decisions in the event of variances, and communicate to all involved participants. We perform data integrity checkpoints at different points during the data Extract, Transform and Load (ETL) process. Performing checks at all points during cut-over allows the conversion team to confirm the data has been successfully converted and is at an acceptable starting point at each stage in the conversion process. If the check fails during the process, the Conversion Team may need to revert to the data backed-up from the staging database legacy source. Right before the start of deployment activities, we will work with KHPA s legacy system administrators to coordinate the replication of the data included in KAECSES-AE, MMIS, PSI, and PARTS for validation purposes. We will also work with them to coordinate the retirement of the legacy systems. The conversion team would continuously monitor progress during deployment of the application. If problems are discovered during the process, the team would quickly resort to the reporting structure established to escalate troubleshooting and defect correction. All deployment activities will be supported onsite by the conversion team Post-Implementation Support Services Our operational skills acquired over decades of experience and hundreds of successful implementations, coupled with our awareness of its importance, provides KHPA with a proven, reliable, effective approach for post-implementation support The Proposer shall describe its approach, the services, and level of staffing needed to ensure a successful Post- Implementation Support period. The Proposer shall also describe the nature and structure of the proposed Post- Implementation Support Services, including: Post-Implementation Support activities by on-site Contractor staff; Telephone support available from Contractor subject matter experts; Problem reporting and resolution procedures; and Our experienced team provides an implementation approach that is designed to lower risk and facilitate a more consistent deployment of K-MED across the different project phases We collaborate closely with KHPA on all aspects of preparing for deployment Deployment activities will reflect an integration of change management, training, site preparation, and conversion Deployment resources will be dedicated to each rollout region to address the varying needs of each region migrating to K-MED Process improvements and applied experiences from many large scale implementations including California C-IV, Texas IMPACT, and Idaho IBES Other support offered (e.g., remote dial-in, web site access to patches or fixes, and knowledge base). We understand that post-implementation support activities, such as daily monitoring of systems, answering user questions, and processing program eligibility are essential to KHPA s ability to serve customers. It is the critical final step to facilitate the success of the K-MED implementation and user acceptance both from the standpoint of the end-user and for KHPA s technical staff. We will work with KHPA staff to provide post-implementation functional and technical support while operating the K-MED system. The post-implementation support team will include State and Accenture members skilled in conversion, security, and system functional 7-280

281 areas. We will also provide technical resources necessary to help answer help desk questions, as well as assist K-MED technical staff in maintaining the application, and addressing technical problems following the full implementation of the K-MED system. In addition to this support structure, we recognize that a successful post-implementation is the result of activities that begin much earlier than cutover. This is why we would work from project inception with KHPA to establish a robust foundation for post-implementation support. Our approach The State of Kansas would experience an effective transition to operations through Accenture s focus on transition from day one of the program. Support and learning begin with the conference room pilot and continues throughout the life of the project. We propose a threepronged approach to support, and a six-month onsite support period conducted by team members who know the business processes and the application. Our goal is to help users become independent because the sooner they start mastering the new application, the sooner they can start focusing on their customers and other mission-critical tasks. Through the Accenture s team focus on transition from the start of the project, the State of Kansas end users and support team are trained and ready to operate the system upon implementation, thus reinforcing post-implementation success. By proactively focusing on the transition of the solution and the State s ability to move into an operations mode, the State of Kansas would achieve the confidence and skills to run the system at go-live. We will provide post-implementation support for a period of six months. However, preparation for sustainable operations with minimal disruption to end users begins before go-live and continues through an ongoing user support structure. User support does not stop. Our ongoing User Support Services will provide assistance as needed. This implementation approach supports KHPA in its goal to deploy a fully integrated medical eligibility system while reducing the impact on business processes and user performance. Accenture strives to engage our clients in creating success for their projects. For example, in Idaho, we worked closely with stakeholders to develop and later deliver the Idaho IBES solution. We sat side-by-side with the State resources to promote transparent communication, foster mutual understanding, and to deliver a solution that answered the State s needs. The acceptance of this application after deployment was successful, as users felt comfortable with what was developed and with how our team gradually introduced it to the project and users. This collaboration established from the beginning of the project helped Idaho transition to the new application quickly and with no major issues. KHPA requires a minimum of six months of post-implementation support services by on-site Contractor staff. The composition of the Post-Implementation Support Team shall be approved by KHPA prior to the team s deployment. Support structure An implementation of this magnitude will inevitably have a brief period of stabilization after deployment. In order to support this stabilization period the post-implementation support team and structure will assist end users, KHPA s IT team, as well as its leadership team through the transition into the new system and changes to business processes. We will work with KHPA to put together a joint team of resources that through different activities and methods will provide support to end users after go-live

282 We will support the transition to the new system through multiple channels. End users will count with the support of the onsite regional support team. They would also leverage our robust user support services, including the K-MED help desk services. Additionally, we will provide a centralized support team, Central Support, that will coordinate support, report and resolve issues across the State, among other activities. This multi-tiered approach to post-implementation support, as illustrated in Figure 7-124, will prepare the users and the enterprise for the change, and aligns to KHPA s desire to be involved in the process and to achieve minimal disruption to operations. We address go-live issues leveraging a network of resources and demonstrated procedures, while fostering knowledge transfer and the eventual self-sufficiency of KHPA users. We work with KHPA to identify a team of State and Accenture resources to support postimplementation activities. KHPA would greatly benefit from this approach as it furthers a robust knowledge transfer and it empowers the State to master the application and achieve functional autonomy. Immediately after go-live, we will have a team of resources provide onsite support to the central office, regional offices and out-stationed workers. This Regional Onsite Support team supports end users by answering questions, and helping them become more comfortable with the new application and processes. They identify ongoing issues and suggest targeted topic trainings to address some of those issues. We leverage the resources from the enterprise readiness and training teams as well as some conversion resources, in addition to KHPA resources. The biggest advantage to such a team is that there is no ramp up for our resources; they are knowledgeable about the application and the business processes. Additionally, many of them have established relationships with many regional offices. This team works with State identified change agents to continue to develop their knowledge and keep providing functionality support to users during turnover and ongoing operations as needed. Post Implementation Support Services Implementation Readiness Activities K-Med Go-Live 30 days post Go-Live 5 months post Go-Live Support End Users and answers questions immediately Provide Target Topic Training Escalate issues as needed Communicate status to project leadership Provide SME support to regional teams Regional Onsite Support Central Support Onsite as needed Accenture + KHPA Resolve login and access issues Assist with application maintenance Provide functionality support online Other Support: Help Desk / User Support Services Online Support Tools K-MED Figure Our approach to a successful K-Med transition focuses on preparing the State and its users from project inception, before system go-live, and continuing to provide ongoing support to develop the needed level of knowledge and self-sufficiency 7-282

283 The regional onsite support team supports users directly at the regional offices for one month starting the day of go-live. At the end of these 30 days, we continue to provide support to the regions from a central location in Topeka. We acknowledge that some offices will need more attention and support than others will so we would provide onsite assistance to the regions on an as-needed basis. On these occasions, a team member will travel to the locations that need support. This approach delivers accurate and tailored support to KHPA. At the same time, it creates an environment that enables users to gain self-sufficiency and does not allow them to become complacent and dependent on external help. The idea is to build user s confidence in the system so they reach a point where they no longer need external help. In the eventuality that this regional onsite support team is unable to address the issues raised in the field, they can escalate issues to the Central Support team. Central Support is the second channel in our support approach and it would be centrally located in Topeka. Central Support provides support to the Regional Onsite Support team over the phone and . Central Support would be a team of functional, technical and conversion subject matter experts that in addition to providing back up support to the field teams would be able to communicate status and issues to project leadership. This support tier coordinates the efforts of the regional support teams; it also prepares and distributes communications that could emanate from lessons learned, project leadership, or others. Central Support also operates as a sounding board for all teams that are on the ground; it is able to gather information from varied sources. Because of its privileged central position, Central Support would also identify potential problems before they become issues statewide and can quickly provide and distribute the best resolution. We will ask for the participation of KHPA resources in Central Support as process and policy questions may come up. Also, this participation fosters effective knowledge transfer. After the first month of post-implementation support, Central Support would continue to be operational and would continue to provide support to users through a central point of contact. The third support channel in our approach is key to the ongoing operations of the system and acceptance of the users. We work with you to enable leveraging of User Support Services to assist end users directly. The range of possible user support resources includes the K-MED Help Desk, system documentation, and sandbox environment, among others. The online help provides documents and job aids that will assist the user in completing tasks or processes. This will guide users through the resolution of issues they may be experiencing, either through the presentation of online job aids or manuals. Additionally, we will work with the K-MED Help Desk to communicate expectations after K-MED go-live so they are better prepared to support system users during the transition. The K- MED Help Desk will log the issues received in the User Support Tracking Tool. They will create tickets that will help track the progress of the issue and communicate resolution back to the user. The help desk resolves system login and access issues, assists with navigation and functionality questions, and assists with application maintenance problems.. The deployment of C-IV in California is a good example of our multi-channel postimplementation support strategy. Although this was not a statewide implementation, we provided support to users that were scattered throughout the State, and that had different geographical as well as political constraints. For each County that was migrating, we deployed an Implementation Support team that provided onsite support to the local offices. The size of this team depended on the number of users being supported. Also depending on the number of users, the teams split between the different offices in the county or provided over-the-phone support to secondary offices if there was not a critical mass of users at that location. Implementation 7-283

284 Support staff teams responded to user questions and helped them with login and navigation on the first days after go-live. They also identified issues and escalated trends to Central Support. Additionally, when needed these teams organized targeted topic trainings and conducted regular status meetings with office leadership to understand their concerns, if any. Part of the implementation team was centrally located in Sacramento Central Support. They coordinated the different onsite implementation support teams. Central Support provided answers to issues that were not resolved onsite, identified trends of issues and created communications or plans for resolving these issues across all counties. Additionally, they coordinated data cleanup activities in all counties. Central Support also worked with Project leadership to keep them abreast of user progress and of any potential issues with the application. The implementation support teams along with Central Support and user support services such as the online help and the C-IV Service Desk, created a support environment that promoted a smooth transition to the new system. The teams were able to identify problems before they became real issues, they were able to help users become self sufficient, and they were able to maintain transparent communication with project leadership, hence building trust on us and the system. We will work with KHPA to better identify its support needs and to delineate the strategy that addresses business goals, requirements and needs most effectively. We will work with you to plan activities and tools such as stakeholder meetings, targeted topic trainings, checkpoints, and checklists that are demonstrated tools and that will support a smooth transition. In the same manner, we will support you in defining escalation procedures that foster a quick issue resolution and that provide assistance to all locations impacted by the transition. The implementation support strategy we are proposing will greatly benefit KHPA. Our multipronged approach to implementation leverages existing resources and fosters knowledge transfer. In addition, our post-implementation approach addresses KHPA s requirement for a transition to the new application with minimal interruption to user s work and to business processes. Please refer to Technical Proposal Tab 11 for our proposed levels of staffing

285 Quality Assurance (QA) Plan Excellence in the delivery of services is a cornerstone of our vision for the K-MED project and all of our social services projects. We inherently build quality assurance into all phases of the K-MED project, validating compliance throughout the project lifecycle In this section, the Proposer shall describe its standard Quality Assurance methodology, as well as provide an explanation as to how the Proposer ensures that its project personnel (including subcontractors) have been trained on the methodology, and that the methodology is in fact used and followed. The methodology description shall provide a detailed explanation of the quality assurance activities, tools, and templates, how the Proposer manages these activities and leverages the tools and templates, and how KHPA and its personnel are integrated into the Proposer s QA processes. Features of our Quality Assurance and Management approach Our U.S. Public Service practice is the largest organization of its type to achieve CMMI Maturity Level 4 We have implemented CMMI across our Global Delivery Network, with over 90% of GDN employees working in Level 5 centers Full time Accenture Quality Coach from the Quality Team promotes adherence to Accenture s delivery practices and verifies process compliance Prior projects results have typically shown the following: Reduced development schedules by up to 30% to 40% Increased productivity with a medium gain of 35% per year Historically rework reduced up to 80% by proactively performing process of product quality reviews Our Quality Assurance approach is inherent in our project methodology and it incorporates standard processes, reviews, and performance metrics to produce high-quality deliverables and reduce the overall implementation risk for the State. We bring to KHPA a standard and field tested methodology to drive the creation of products and deliverables that are of the highest quality. Quality Assurance (QA) and delivery excellence are essential components of the Accenture team s implementation methodology. Our QA approach combines leading industry practices with internal proprietary practices that provide: Tools to evaluate quality and monitor performance Processes that help to provide an early warning/detection system to identify and address issues Standard quality methodologies and performance metrics Quality reviews throughout the project lifecycle The best and most cost effective way to build a system is to get it right the first time. Setting the highest standards of quality provides great customer and employee satisfaction. Quality of our services begins with successfully demonstrated methods. Project teams would use projectrelevant methods from our methodology library to execute the agreed-upon project plan step-bystep. Secondly, we put in place a Quality Assurance Plan to monitor, measure, and report the quality of project delivery processes and outputs and institute corrective actions when necessary. Figure illustrates features and benefits of our Quality Assurance Process and the various components of our plan specific to the K-MED project. Features Quality built into day-to-day Accenture Delivery Methodology (ADM) Benefits to Kansas Promotes social services with industry-preferred practices Provides quality deliverables and solutions to address K- MED s project requirements Provides increased efficiencies in completion of work 7-285

286 Features Project Quality Management Plan outlining day-to-day processes and tools for use by project team to verify and monitor quality Multiple levels of quality management reviews including: Peer and supervisor reviews Independent Quality Assurance (QA) client satisfaction review Metrics against base-lined project schedule and budget Benefits to Kansas Identifies and describes roles of each project team member and clients relevant to quality management Outlines processes at every level of project effort, such as stage and phase reviews, to verify and validate quality output Provides a planned schedule that promotes continuous quality monitoring and when necessary, corrective action Maintains or improves process and product quality by putting in controls as far upstream as possible Verifies project services address baseline project requirements Minimizes adverse impact to project(s) Assesses and monitors KHPA s satisfaction with project progress and output through client satisfaction surveys Facilitates on-time and on-budget delivery Provides visibility into project performance and health Measures satisfaction of project performance requirements Identifies need for corrective action early Quality Processes and standards Minimizes risk by building quality into each deliverable and work products Provides guidance and standards that are followed consistently by all KHPA members V-Model Validates that the K-MED solution meets functional, technical, operational and maintenance requirements Quality Processes and Standards Monthly verification of progress against performance metrics Identifies deliverable discrepancies or misalignments early on in the process Holds all team members accountable for quality Quarterly Client Quality Assessments Provides periodic external review by an Accenture executive Validates project progress and business value against expectations, budget, schedule and resources Allows for corrective actions to minimize risk Expectations Management Clearly articulates the goals and expectations of the stakeholders Minimizes implementation risks and issues that may result from misaligned expectations Project Metrics and Status Provides tools and measures to monitor and control project Reporting performance Identifies risk areas early Figure Our Quality Management approach would validate project progress against requirements, minimizing project risk and providing a number of benefits to the K-MED project Quality management is a critical requirement of a project. We build quality into our methodology, incorporating it throughout the project lifecycle to help produce required results and continuous improvements. Whether it is the creation of a functional requirements document, a technical design specification, program code or training material, or a simple communication to users, we take pride in producing the highest quality deliverables that meet your requirements. Our quality goals support delivery of quality services and solutions that seek to meet K- MED s requirements of on time and on budget delivery. Our field tested Health and Human Services methodology helps us deliver results in a predictable, repeatable, and coordinated manner. We embed quality at all stages to introduce, promote, reinforce and acknowledge quality in related activities and deliverables. These methods potentially reduce execution risk by driving delivery consistency and promoting recommended practices we have developed from our 7-286

287 experiences in delivering similar large-scale social services transformation efforts. On the K-MED project, we would apply our established Quality Management processes, which we have implemented in similar projects such as IBES in Idaho, NYC HHS Connect, and California C-IV. Our approach includes layers of quality review, processes operating under the US Federal and State & Local Service Group rated at CMMI Level 4, client satisfaction surveys and adherence to quality guidelines and standards. Our approach combines different elements to deliver quality: Building quality into our products using our delivery centers attributes V-Model and testing guidelines: Our Quality Approach comprises a set of processes that include quality checklists, process-level checklists, and transition points. The V-Model is a key component of this activity. The V-Model emphasizes building quality into the project from the initial requirements stage to the final testing stage. The model also structures delivery processes to deliver quality at every point in the process, thus lowering cost and risk to the K-MED project. Key elements of the V-model include: Validation Doing the right thing Verification Doing it the right way Testing- Working as designed Quality Guidelines: Quality Guidelines provide a set of approaches, techniques, metrics, tools, and considerations for planning, managing and executing the K-MED project. These guidelines help facilitate process repeatability and predictability. They include application quality, requirement guidelines, performance metrics, CMMI guidelines, operations acceptance criteria, quality checklists, risk management guidelines for distributed work, and software quality assurance guidelines. Monthly Quality Team reviews of our project management processes Accenture has a Quality and Client Satisfaction (QCS) Program to provide added focus on improving delivery capability and reducing execution risk. Within the QCS Program, our Quality Team promotes adherence to Accenture s delivery practices and verifies process compliance. The Quality Team confirms the use of CMMI Maturity Level 4 for the State of Kansas K-MED Project and provides technical assistance to boost process effectiveness and efficiency. The Quality Coach conducts monthly checkpoints with the K-MED project team to verify methodology utilization and the implementation of Accenture s practices. Feedback on leading practices and process improvement from the Quality Team Reviews provides the State with the added benefit of knowing that Accenture is constantly striving to bring its most effective and efficient practices to the K-MED project. Accenture also requires that its teams conduct deliverable reviews. This provides the State with the benefit of the knowledge from Accenture s leaders across the Public Service operating group. Quarterly Client Quality Assurance reviews from an outside independent observer that also includes establishment and evaluation of stakeholder expectations and client satisfaction surveys. Accenture requires that every project conduct formal, quarterly reviews, known as Quality Assurance Reviews. An Accenture senior executive, external to the K-MED engagement, conducts the review. The program s foundation and success begins with an objective, quality executive 7-287

288 Quality Assurance Process Key Inputs Key Benefits Expectations and Performance Requirements High Performance Quality Standards and Measures Continuous Improvement Governance Low risk for KHPA Value Management High Stability Plan Product Identify Process Improvement Requirements Figure Our additional Opportunities support avenue, Central Support, coordinates knowledgeable Management agents who have the resources they need Program to answer questions quickly and accurately Scope Management Service Implement Preventative Maintenance Proactive Measures Governance Report and Communicate Gather and Analyze Metrics Report Portal Score Cards Dashboards Quality Reviews Satisfaction Surveys Performance Reviews Root Cause Analysis Trend Analysis 2 K-MED Figure Our Quality Assurance Process continuously monitors quality efforts on the project and identifies improvement opportunities through all phases sponsor for the State of Kansas. This executive meets quarterly with K-MED leadership to assess and review progress, recommend courses of action and help verify that quality is a focus for the outcome of the project. The QA review would provide objectivity, independence, broad subject matter experience and a careful assessment of all viewpoints. The external QA review would also include inspections of deliverables to assess technical quality, an evaluation of QA program metrics and interviews with managers from the K-MED project. The support of Accenture provides the State of Kansas with a seamless transition to operations and unparalleled ongoing software support. We are able to accomplish this because, as shown in Figure 7-126, quality is embedded in everything we do. Our approach to quality management reduces implementation risk by building quality early and allowing for continuous improvement throughout the project lifecycle. The State is particularly interested in a Quality Assurance process and methodology which is future oriented, identifying and mitigating project risks well before they become significant issues requiring executive management intervention. Our methodology will provide the K-MED Project Team with a starting point and a quality checklist for each stage of the project's lifecycle. Our team members would use this checklist to verify the quality of our work. We train our teams to use our quality methodology to quickly ramp up projects and guide quality management of delivery processes. During the K-MED Analysis activities, our project team will work with you to tailor our methods to align to your organization s needs. Our quality-driven methods have enabled Accenture to achieve sustained client satisfaction. CMMI s framework serves as a guide for organizational self-improvement. CMMI contains key elements for implementing effective processes and leading practices addressing productivity, 7-288