Attachment_12_-_BD_Segment_Blueprint_Final.pdf

Benefits Determination

Segment Architecture Blueprint November 24, 2010

Benefits Administration and Payment Department

Office of Information Technology

Benefits Determination Segment Blueprint ii

Revision History

Version Date Change Description

0.1 06/20/2010 Draft revision

0.2 06/24/2010 Draft revision

1.0 07/08/2010 Removed “Draft” from the title page (blueprint approved by the Core Team). Reformatted to use tabs for high-level sections.

1.1 10/05/2010 Added Segment Architecture Approval Page

1.2 11/24/2010 Added Segment Architecture approval signatures (Executive Sponsor and Chief Architect)

Acknowledgments

We would like to thank the Executive Sponsors, the Core Team and interviewees from BAPD, OIT and throughout PBGC. Without their sharing of knowledge we would not have been able to attain this level of quality. The names of those who helped are in Appendix section 8.17, “BD Segment Contributors.”

Steve Finucane & the EA Team iii

Table of Contents

1 PBGC Segment Architecture Approval Form

2 Executive Summary

3 Introduction

3.1 Segment Scope

3.2 Background and Problem Statement

4 Recommendations

4.1 Summary of Recommendations

4.2 Improvement Area #1 – Data Quality and Master Customer and Plan Databases

4.3 Improvement Area #2 – BCVS Recommendations

4.4 Improvement Area #3 – Letter generation processes and supporting IT solutions

4.5 Improvement Area #4 – Self‐Service Capabilities

4.6 Improvement Area #5 – IPVFB Recommendations

4.7 Improvement Area #6 ‐ Participation in Implementation of Business Intelligence

4.8 Improvement Area #7 – Reuse of the Enterprise‐wide Services and Capabilities

4.9 Improvement Area #8 – BAPD Manuals/References and Training Materials Organization and

Search 49

4.10 Improvement Area #9 – Other Considerations

4.11 For Business Consideration

5 Transition Strategy

5.1 High‐level Transition Sequence Plan

5.2 Transition Activities

6 Current State Analysis

6.1 Performance Gaps

6.2 Business Analysis Detail

6.3 Data Detail

6.4 Technology Detail

7 Target State

7.1 Target Analysis and Improvements Summary

7.2 Business Detail

7.3 Data Detail

7.4 Technology Detail

8 Appendices

8.1 Segments Overview

8.2 Segment Architecture Roles and Responsibilities

8.3 Segment Architecture Methodology

8.4 Strengths, Weaknesses, Opportunities, Threats (SWOT)

8.5 Goals and Objectives

iv

8.6 Products and Services

8.7 Candidate Recommendation Owners

8.8 Interview Questions

8.9 Mapping of High‐Priority Gaps to Improvement Areas

8.10 Benefits Determination Performance Measures

8.11 Reference Model Mappings

8.12 Conceptual Data Model Information Object Definitions

8.13 Benefits Determination CRUD Matrix

8.14 Benefits Determination Target Logical Data Stores mapping to EDM

8.15 Benefits Determination Qualitative Analysis of Data

8.16 ADT Data Load Attributes

8.17 BD Segment Contributors

Executive Sponsors ‐ Rich Macy ‐ Bennie Hagans Resources ‐ Core Team of Business Representatives ‐ EA Team

2 Executive Summary

The Benefits Administration and Payment Department (BAPD) enables the

Pension Benefit Guaranty Corporation (PBGC) to meet its mission by providing timely, correct and uninterrupted payments to participants, beneficiaries and alternate payees. To achieve the goal of providing correct payments, Benefits Determination (BD) processes perform collection and verification of participant and pension plan information necessary to calculate correct benefit amounts based on legally mandated limitations of the PBGC insurance program and the ability to cover a terminated plan’s liabilities with its assets and recoveries. In doing so, BD provides indispensable input to the down‐stream processes administering benefits and issuing payments.

The BD Segment Architecture was performed by a cross‐organizational team comprised of BAPD and

Chief Operating Officer (COO) business representatives and the PBGC Enterprise Architecture (EA) team in order to define a set of recommendations for improving the determination of benefits at PBGC. The

Appendices 8.1‐8.3 contain complete descriptions of the effort’s approach, participants, and their roles.

Performance Gaps

The EA team used a number of sources and approaches to identify the following high priority performance gaps currently affecting the segment, including interviews, analysis, the Government

Accountability Office (GAO) report GAO‐09‐716, previous EA efforts, and the PBGC Annual Management

Report for Fiscal Year 2009 (Section 6.1 contains a detailed list of performance gaps and sources).

Gap Area: Data quality and organization issues; Need for synchronization and reconciliation.

Data Collection process often gives incomplete results.

Data discrepancy and duplication in several data stores; need for synchronization and reconciliation (Leo, Valuation and Genesis databases).

Lack of consistent and unique identifier of customer and plan records for all PBGC systems.

Gap Area: Inadequate IT support for communication of Benefit Determinations and Estimates.

No availability of Online Benefit Estimates for plans that are not in Ariel.

Gap Area: Inefficient BD applications environment.

Limited reuse of the calculation logic among the plans.

Insufficient support for acquiring and handling customer information.

Lost advantage of skipping the previously reviewed logic during reviews.

Manual interface between Integrated Present Value of Future Benefits (IPVFB) system and

Financial Operations Department (FOD) (significant deficiency on Annual Management

Report).

Gap Area: System design is inadequate for mitigating current risks or meeting future needs.

Processes and systems may not scale out smoothly to keep up with additional workload.

Use of Commercial of the Shelf (COTS) or Application Service Provider (ASP) model (when

PBGC does not own the code, in general) for the mission critical, core functionality which has to be operational for dozens of years elevates the risk of high cost of conversion efforts during the lifetime of the functionality.

Gap Area: Performance monitoring, work planning and accountability challenges.

Insufficient tracking of corrections and verification review efforts.

Delays in completion of upstream activities such as data gathering may cause crunch time for

Benefit Determination Letter (BDL) issuance, creating incentives to accelerate processing in a way that may compromise quality in order to hit the Benefit Determination Letter (BDL) issuance milestone despite a delayed start.

Gap Area: Inadequate or inefficient implementation of security controls.

Use of the databases with Personally Identifiable Information (PII) on local and shared drives as well as locations outside of HQ complicates mitigating the risk of its unauthorized exposure

User Access certification is time consuming.

Recommendations

To address these gaps, the Core Team developed and prioritized 36 recommendations by voting on groups of expected results or outcomes from these recommendations. Priorities of the recommendations were derived from the number of Core Team member votes that the corresponding result or outcome received. All recommendations are described in detail in Section 4

Recommendations.

Some recommendations, designated by an “Enterprise‐Wide Solution” badge as seen here on the right, are recognized to have a significant impact on PBGC as a whole, and thus, require enterprise‐wide coordination. Such recommendations present opportunities to control costs and improve the efficient stewardship of resources.

The information on the three top priority recommendations follows:

Improvement Area 2, Recommendation 2‐2:

Replace existing valuation systems with a flexible, secure, scalable Benefit Calculation and Valuation Solution (BCVS) using the strengths and lessons learned from the previous systems.

Key Performance Gaps Addressed: Processes and systems may not scale out smoothly to keep up with additional workload; Use of COTS or ASP model for the core functionality results in high cost of conversion efforts during the functionality lifetime; Ability to update valuation data without audit record in Leo; Limited reuse of the calculation logic among the plans; Actual data used to calculate benefit may be different from the currently approved data.

Candidate Owner(s): Program Manager – Beverly Lambert (BAPD), BCVS Business Representative ‐ LaCountiss Hopkins (BAPD), Actuarial Technical Lead ‐ Tom Stephanos (BAPD).

Actions Required:

1. Complete work on the following recommendations using as an input the high‐level requirements (section 7.2.1) and the Segment Architecture target state (section 7):

a. Perform analysis of at least 3 implementation options to implement the Centralized Plan Calculations Repository and the Inventory of Calculation Templates (section 4.3.1)

b. Convert active cases to use single Oracle database (section 4.3.5)

2. Initiate development program to

a. Implement BCVS components as suggested in the target state (section 7.4.2.1)

b. Integrate the Calculation Engine and the Inventory of Calculation Templates

c. Implement the BCVS Staging and Production Environments (as described in section

7.4.2.1.2)

Improvement Area 2, Recommendation 2‐4:

Stop using and exposing the PII during the development of the valuation logic.

Key Performance Gaps Addressed: Elevated risk of unauthorized disclosure.

Candidate Owner(s): Program Manager – Beverly Lambert (BAPD), BCVS Business Representative ‐ LaCountiss Hopkins (BAPD), Actuarial Technical Lead ‐ Tom Stephanos (BAPD).

Actions Required:

1. Implement customer identification mechanism which does not use PII data elements.

E.g., Complete work on the “Recommendation 1‐3 ‐ Implement the Customer Master Data Management (MDM) and High‐volume Data Integration Solutions.”

2. Design BCVS to prevent case actuary and reviewer roles from accessing the PII data elements.

Short Term:

1. Update Leo to allow creation and data merge into a PII‐free valuation database where the PII data element values are not real (e.g., auto‐generated).

2. Implement a mechanism in ValTool, BSRS, BET and DRS to identify customer records without use of the PII data elements.

3. Update Leo to allow population of the PII data elements with real values from the Leo valuation database. Only OASD may perform this PII population operation, during the software close‐out phase before generating Benefit Statements or running DRS.

Improvement Area 1, Recommendation 1‐4:

De‐duplicate, consolidate and provide access to Customer information from the Genesis and BFI databases.

Key Performance Gaps Addressed: Data discrepancy and duplication in several data stores; Need for synchronization and reconciliation; System interdependencies due to brittle code and shared objects on the database level; Lack of consistent and unique identifier of customer and plan records for all PBGC systems.

Candidate Owner(s): Genesis Business Representative ‐ Darlene McManus (BAPD).

Actions Required:

1. Conduct Alternatives Assessment to identify the technology for Master Data Management (MDM) and high‐volume Data Integration solutions using as an input:

Segment Architecture target state (Section 7.4) and the Recommendation description (Section 4.2.4).

Oracle Assessment Oracle Database recommendations and the BAPD Upgrade State presentation section.1

2. Complete work on the recommendations:

Establish data quality maintenance practice and processes for all Customer information.

Implement the Customer Master Data Management (MDM) and high‐volume Data Integration solutions.

Remedy and maintain data quality in Genesis.

Define per‐application migration path to the Customer Core, Benefit and Payment logical data stores for BA and BD applications.

3. Gradually migrate applications to the Customer Core, Benefit and Payment logical data stores according to the migration path.

4. Decommission the legacy databases as applications are migrated to the new data stores.

The rest of the 36 recommendations created by the BD Core Team are grouped by improvement area and presented in the table below:

# Improvement Area # Recommendation Title

1 Data Quality and

Master Customer and

Plan Databases

1‐1 Remedy and maintain data quality in Genesis (and satellite databases and successors)

1‐2 Define per‐application migration path to the Customer Core, Benefit and Payment logical data stores for BD and BA applications

1‐3 Implement the Customer Master Data Management (MDM) and high‐ volume Data Integration solutions

1‐4 De‐duplicate, consolidate and provide access to Customer information currently in the Genesis and BFI databases as applications are migrated

1‐5 Participate in implementation of the Plan Master Data Management

1‐6 Establish data quality maintenance practice & processes for all

Customer information

1 Oracle Assessment: Target State – V3.0. Final Draft, slides 20-23, 48-49 at http://pbgcportal.prod.ent.pbgc.gov:80/portal/server.pt/gateway/PTARGS_32_0_345_0_- 1_47/http;/pbgcportal2.prod.ent.pbgc.gov;11930/collab/do/document/overview?projID=2939&documentID=179365

2 BCVS

Recommendations

2‐1 Perform analysis of at least 3 implementation options to implement the Centralized Plan Calculations Repository and the Inventory of

Calculation Templates:

1. Flavor of Excel‐like spreadsheet for which PBGC owns code

2. MS Excel

3. Custom solution allowing custom calculation formulae and multiple‐step calculations

The analysis includes evaluating a Plan Summary Tool to assist users with capturing plan provisions and making them easily available to

FBAs, Appeals, etc.

2‐2 Replace existing valuation systems with a flexible, secure, scalable

BCVS using the strengths and lessons learned from the previous systems

2‐3 Use data profiling and quality tools to assess data quality, cleanse the data and move the customer data to Consolidated Customer Database sooner

2‐4 Stop using and exposing the PII during the development of the valuation logic

2‐5 Convert active cases to use single Oracle database

2‐6 Normalize and standardize as appropriate the information in the

Staging, Audit, Valuation and Actuals database using business taxonomy

2‐7 Implement the process to manage reusable calculations in the

Inventory of Calculation Templates

3 Letter generation processes and supporting IT solutions

3‐1 Develop detailed business rules outside of the system to aid users in selecting the correct letter template and merge data validation rules

3‐2 Enhance existing eALG capabilities

3‐3 Implement Letter/Message Generation System (LGS) capabilities as enterprise‐wide services

3‐4 Promote use of pbgc.gov, participant information verification and customer self‐service on all customer correspondence

4 Self‐Service

Capabilities

4‐1 Enable Secure Online Portal to provide support for Plan

Administrators, PBGC Auditors and plan participants to supply and verify plan and participant information

4‐2 Store plan and customer information submissions in the Source

Document Archive

4‐3 Implement ‘Secure Messaging Center’ functionality to allow PBGC to deliver Benefit Determinations via the Secure Online Portal

4‐4 Allow deferred vested participants to estimate their benefits online

5 IPVFB

Recommendations

5‐1 Implement automated interface with FOD

5‐2 Modernize portions of IPVFB which are using obsolescent technology

6 Participation in implementation of

6‐1 Populate and maintain BD business taxonomy in the Business

Intelligence (BI) platform

Business Intelligence 6‐2 Establish and maintain BD data services in the BI platform and assign data stewards

6‐3 Identify BAPD and corporate reporting requirements

6‐4 Develop and maintain BD enterprise reports

6‐5 Collaborate with DISC on establishing access to the information needed for valuation and IPVFB

7 Reuse of the

Enterprise‐wide services and capabilities

7‐1 Use the corporate‐wide services in BD systems

7‐2 Use enterprise‐wide search capabilities

7‐3 Implement the Source Document Archive

7‐4 Add detailed monitoring and retrospective transparency of the benefits determination stage as a requirement for the corporate‐wide case management or project management solution

8 BAPD

manuals/references and training materials organization and search

8‐1 Consolidate and organize the content of Actuarial manuals/references in a manner that allows effective search, retrieval, presentation and use of the information. Identify optimal technology to support both

Actuarial Resources and the BAPD Manual

9 Other considerations 9‐1 Automate posting of benefit information in Spectrum (or successor

Benefit Management Application) after 45 day appeal period

9‐2 Provide TPDs and BAPD Management controlled access to DISC information in TeamConnect

9‐3 Ensure network capabilities will support responsive BCVS solution at

HQ and remote sites

Table 1: Benefits Determination Segment Recommendations

Before the recommendations were prioritized from a business perspective, the EA team derived a set of milestones or activities and identified natural or technology dependencies among them. The business priority and the dependency information determined the relative position of the activities and milestones on the Benefits Determination sequence diagram shown below.

Figure 1 depicts the major milestones that PBGC will need to achieve as recommendations are followed.

Each milestone is represented by a color‐coded horizontal arrow with the milestone title in the middle.

The color of the milestone arrow signifies the improvement area containing the milestone. The system names used in some of the milestone titles may change as Alternatives Analysis maps the functionality to systems. The EA team presented the sequence diagram to the Core Team and obtained approval.

Figure 1: High-level Activity Dependencies and Sequencing

3 Introduction

The Benefits Determination (BD) Segment Architecture was performed by a cross‐organizational team at

PBGC to define a set of recommendations for improving benefits determination operations within PBGC.

This effort was sponsored by the Chief Operating Officer (COO), Rich Macy, and Benefits Administration and Payment Department (BAPD) Director, Bennie Hagans, and was facilitated by the Office of

Information Technology (OIT), Enterprise Architecture (EA) team. The results of this effort will guide decisions about future investments and the (IT) transformation of this segment. This effort supports

PBGC’s approach to IT modernization as an “Architect” portion of the “Architect – Invest – Implement” process.

3.1 Segment Scope

The scope of the segment is defined by the business functions that comprise this segment. The scope of the segment was validated and agreed upon by the Core Team and Executive Sponsors. The functions comprising the BD segment scope depicted in the figure below are as follows:

Plan Trusteeship (BD Initiation)

Data Gathering, Verification, Analysis and Integration

Calculation of Termination and Estimated Benefits; Valuation

Notification of Benefits

Determination of IPVFB

Figure 2: Business Functions

3.2 Background and Problem Statement

The Benefits Determination (BD) segment performs activities crucial for correct determination of the payment amounts for current and future payees. In doing so, BD provides indispensable input and services to the Benefits Administration segment processes which are responsible for uninterrupted payments to PBGC customers in trusteed plans. BD performs:

Data collection, data audit and verification to build data sets necessary to determine benefit amounts.

Activities and actuarial calculations including allocation of plan assets leading to determination of estimated benefits, the participant termination benefits, and the valuation of those benefits as plan liabilities reported in the PBGC annual financial report.

Development and customization of the benefit determination logic per plan provisions and packaging the logic so that it can be used throughout the Benefits Administration processes.

Issuance of benefit statements for customers.

The Benefits Determination segment was selected by executive management as an area of focus at PBGC due to its strategic importance, the growing workload due to the increasing number of the plans being trusteed and the cost associated with it. Opportunities exist for BD to improve efficiencies through:

Increased reuse of services.

Better integration with the Benefits Administration (BA) and financial systems as well as securing, unification and better organization of the Benefits Determination tools and data sets.

Less expensive reporting through unification of the foundational data sets.

Identification and processing of groups of similar customers instead of processing customers one‐ by‐one.

Technology that is aligned with business needs.

More efficient processes for both participants and PBGC staff.

Modernization will improve BD’s security stance, ability to handle an increasing workload, and agility to handle unprecedented plan provisions.

The PBGC executive management initiated the Benefits Determination Segment Architecture to support future investment and development decisions by evaluating the business and technical environment, defining the target state, and providing recommendations and a plan for transitioning to the target state.

4 Recommendations

The following recommendations, made by the Core Team, describe business and technology changes required for transitioning to the target state. They are based on a comprehensive understanding of the challenges affecting the Benefits Determination Segment in the current business and technology environment. Implementation of the recommendations will enable PBGC to achieve its goals and objectives for Benefits Determination and provide target services to its stakeholders. While each recommendation represents a discrete set of activities, dependencies among the recommendations do exist and are taken into consideration in the Transition Strategy (Section 5). In addition, the estimated costs and benefits of each recommendation would, of course, also need to be considered at the appropriate point in the process.

Each recommendation is assigned to a candidate owner, which is outlined in the Appendix Section 8.7, Candidate Recommendation Owners.

4.1 Summary of Recommendations

The Benefits Determination Core Team developed 36 recommendations grouped by the Improvement

Areas in the following table:

The Benefits Determination Core Team recommends that PBGC:

# Improvement Area # Recommendation Title

1 Data Quality and

Master Customer and

Plan Databases

1‐1 Remedy and maintain data quality in Genesis (and satellite databases and successors)

1‐2 Define per‐application migration path to the Customer Core, Benefit and Payment logical data stores for BD and BA applications

1‐3 Implement the Customer Master Data Management (MDM) and high‐ volume Data Integration solutions

1‐4 De‐duplicate, consolidate and provide access to Customer information currently in the Genesis and BFI databases as applications are migrated

1‐5 Participate in implementation of the Plan Master Data Management

1‐6 Establish data quality maintenance practice & processes for all

Customer information

2 BCVS

Recommendations

2‐1 Perform analysis of at least 3 implementation options to implement the Centralized Plan Calculations Repository and the Inventory of

Calculation Templates:

1. Flavor of Excel‐like spreadsheet for which PBGC owns code

2. MS Excel

3. Custom solution allowing custom calculation formulae and multiple‐step calculations

The analysis includes evaluating a Plan Summary Tool to assist users with capturing plan provisions and making them easily available to

FBAs, Appeals, etc.

2‐2 Replace existing valuation systems with a flexible, secure, scalable

BCVS using the strengths and lessons learned from the previous systems

2‐3 Use data profiling and quality tools to assess data quality, cleanse the data and move the customer data to Consolidated Customer Database sooner

2‐4 Stop using and exposing the PII during the development of the valuation logic

2‐5 Convert active cases to use single Oracle database

2‐6 Normalize and standardize as appropriate the information in the

Staging, Audit, Valuation and Actuals database using business taxonomy

2‐7 Implement the process to manage reusable calculations in the

Inventory of Calculation Templates

3 Letter generation processes and supporting IT solutions

3‐1 Develop detailed business rules outside of the system to aid users in selecting the correct letter template and merge data validation rules

3‐2 Enhance existing eALG capabilities

3‐3 Implement Letter/Message Generation System (LGS) capabilities as enterprise‐wide services

3‐4 Promote use of pbgc.gov, participant information verification and customer self‐service on all customer correspondence

4 Self‐Service

Capabilities

4‐1 Enable Secure Online Portal to provide support for Plan

Administrators, PBGC Auditors and plan participants to supply and verify plan and participant information

4‐2 Store plan and customer information submissions in the Source

Document Archive

4‐3 Implement ‘Secure Messaging Center’ functionality to allow PBGC to deliver Benefit Determinations via the Secure Online Portal

4‐4 Allow deferred vested participants to estimate their benefits online

5 IPVFB

Recommendations

5‐1 Implement automated interface with FOD

5‐2 Modernize portions of IPVFB which are using obsolescent technology

6 Participation in implementation of

Business Intelligence

6‐1 Populate and maintain BD business taxonomy in the Business

Intelligence (BI) platform

6‐2 Establish and maintain BD data services in the BI platform and assign data stewards

6‐3 Identify BAPD and corporate reporting requirements

6‐4 Develop and maintain BD enterprise reports

6‐5 Collaborate with DISC on establishing access to the information needed for valuation and IPVFB

7 Reuse of the

Enterprise‐wide services and capabilities

7‐1 Use the corporate‐wide services in BD systems

7‐2 Use enterprise‐wide search capabilities

7‐3 Implement the Source Document Archive

7‐4 Add detailed monitoring and retrospective transparency of the benefits determination stage as a requirement for the corporate‐wide case management or project management solution

8 BAPD

manuals/references and training materials organization and search

8‐1 Consolidate and organize the content of Actuarial manuals/references in a manner that allows effective search, retrieval, presentation and use of the information. Identify optimal technology to support both

Actuarial Resources and the BAPD Manual

9 Other considerations 9‐1 Automate posting of benefit information in Spectrum (or successor

Benefit Management Application) after 45 day appeal period

9‐2 Provide TPDs and BAPD Management controlled access to DISC information in TeamConnect

9‐3 Ensure network capabilities will support responsive BCVS solution at

HQ and remote sites

Table 2: Benefits Determination Segment Recommendations

4.2 Improvement Area #1 – Data Quality and Master Customer and Plan

Databases

A number of data collection, data quality, and data management issues were identified during SWOT analysis and were fully supported by the results of analysis of Benefits Determination business, technology and data. The results of the segment business and data analysis suggest that Benefits

Determination is driven by the information auditors collect from the previous plan administrators on the plan and participant levels. In addition to this plan‐specific information, ERISA laws and PBGC internal policies affect the body of work performed by the Benefits Determination processes.

Benefits Determination shares a number of data sources with the Benefits Administration and produces the information necessary for the Benefits Administration processes. As the result, Benefit

Determination analysis led to confirmation that many of the gaps discovered by the Benefit

Administration segment effort affect the Benefits Determination. In addition, Benefits Determination processes rely more on plan provision and participant employment source information.

In summary, quality, organization and ease of access to plan and participant information are prerequisites to improving the efficiency of Benefits Determination and Administration processes.

Below are key findings made during the analysis phase:

Lack of consistent and unique identifier of customer and plan records for all PBGC systems.

GENOWN entries with invalid or abbreviated customer name grew 17% between 2005 (71,023) and 2007 (83,044)2.

Data discrepancy and duplication in several data stores; need for synchronization and reconciliation (Leo, Valuation and Genesis databases).

System interdependencies due to brittle code and shared objects on the database level.

MyPBA, Spectrum and CRM maintain 5 schemas in 3 databases with duplicates of Core

Customer information.

This Improvement Area contains recommendations for the improvement of organization and quality of the Customer and Plan information. It includes a number of the recommendations approved for

Benefits Administration in order to address the gaps confirmed to have impact on Benefits

Determination. A couple of recommendations related to data organization in the valuation system are presented in other improvement areas if they are part of the transformation covered by another improvement area.

The recommendations described in the following subsections aim at improving the data quality and restructuring the Plan and Customer data stores used for Benefits Determination. Such database restructuring is based on transitioning from the application‐centric view of the customer and plan data to the realization that customer and plan information are the data assets requested and used by many parts of the PBGC business. Therefore, the core customer and plan information should be maintained at the level of quality inherent to a key enterprise‐wide resource and should not be owned by any one system, but rather shared by the entire PBGC. The recommendations described below set the roadmap for system migration to use the restructured data stores.

Expected key benefits from implementation of the recommendations described in this section include:

Consistency and integrity of the Core Customer and Plan information available for use by all

PBGC systems.

Only anomalies and duplicates left out by the automated cleansing and matching rules are forwarded for Data Steward’s manual resolution (resolution by exception).

Improved system reliability due to elimination of data anomalies.

Reduction of development cycle cost as the result of elimination of hidden dependencies.

Elimination of costs associated with customer information synchronization among non‐COTS systems.

2 GENown Data Quality Monitoring. Baseline audit report, 2007 (most recent audit)

Successors of the ACT, Spectrum, CRM and MyPBA (Participants Information Management

System), Interactions Log and the Secure Online Portal) will have a single store of the Core

Customer information and use the same customer information.

Successors of the ACT, PAS and CMS will have a single consistent store of the Core Plan information to share.

4.2.1 Recommendation 1‐1 ‐ Remedy and Maintain Data Quality in Genesis (and Satellite Databases and Successors)

PBGC can improve the quality of the information in the Genesis database (with a focus on the customer information) before transitioning its information systems to the Consolidated Customer

Databases. Information anomalies should be identified, categorized and eliminated. The Team also recommended that PBGC archive or move from the operational data stores the records that are not used or that are irreparable or unusable due to low quality or age as determined by the set of defined business rules and parameters.

The Genesis database is the authoritative source of the customer information in Benefits Administration with many data stores receiving feeds from it. Leo is one of such data stores synchronizing its information with Genesis, and ADT loads the participant valuation information with the benefits determination results. It is essential to make sure that data stores and applications keeping replicas of the Genesis information obtain the cleansed version of the information once it is available in Genesis

(before these applications are migrated to the Consolidated Customer Databases).

Reducing the number of records in the operational databases by moving the irreparable or aged records to the archival data store will improve performance of the databases and quality of the production reports. PBGC may use the high‐level activities described in the section 6.3.2.4 to prepare for and perform data archival.

The scope and schedule of the data quality activities (including the first clean‐up of the data) should be determined by the data quality process (discussed more in the Recommendation 1‐6, section 4.2.6) created to ensure the proper level of quality of the Customer data.

4.2.2 Recommendation 1‐2 ‐ Define Per‐application Migration Path to the Customer Core, Benefit and Payment Logical Data Stores for BD and BA Applications

PBGC needs to develop a detailed migration plan to adopt use of the Consolidated Customer

Databases (CCD) for each application that currently uses Genesis as well as an overall migration plan.

PBGC should begin by assessing each connected application. In the context of the Benefits

Determination segment, such applications include Leo, ADT or the successor of the ACT system, since the successor of ACT will directly access the CCD. The assessment should result in the migration path of all the impacted applications toward the new state in which they access the Consolidated Customer

Databases for Customer’s Core, Benefit and Payment Information and the redesigned application data stores for the application‐specific data.

Benefits Administration segment effort produced a diagram depicting the GENown schema in the

Genesis database participating in the data exchanges which are part of the 18 major BAPD processes

(please see Figure 11). Benefits Determination systems ACT, Leo and IPVFB are depicted on the diagram as interfacing systems. The number of the applications impacted by the implementation of the

Consolidated Customer Databases dictates having a thought‐through migration plan and effective governance ensuring that the plan is followed.

The benefits of creating and approving the migration plan include:

Migration plan is the basis for planning (including budgeting)

Single common vision of the path to the desired target state

Ability to measure the progress of moving to the target state

Effective use of the resources

4.2.3 Recommendation 1‐3 ‐ Implement the Customer Master Data Management (MDM) and High‐volume Data Integration Solutions

Core Customer Information can be managed in the Master Data Management (MDM) solution. Core

Customer Information (e.g., name, address, SSN, date of birth, etc) is described in the section 7.3.3.3.

PBGC needs to select the MDM solution. The Team also recommended that PBGC select and employ the high‐throughput Data Integration solution capable of interoperating with the MDM.

Analysis of the CRUD matrix (sections 6.3.2, 8.13) and business analysis (section 6.2) demonstrated that the Core Customer Information is routinely updated – entirely, or piece by piece ‐ from different business processes based on the sometimes imperfect or unverified information which is often obtained from unrelated sources. Business analysis of the data acquisition phase during plan termination confirmed that the data obtained is incomplete and unreliable due to a number of factors within and outside of PBGC control. The data verification process improves the customer and plan information needed for benefits determination and BDL issuance. PBGC may rely on subsequent phases to fill in the remaining gaps or correct the information before it can be used in benefit administration. Such an approach to improving the data quality of the customer information will likely not change and the business will need a formal and standard mechanism of versioning, controlling and approving changes to the Core Customer Information.

Benefits Determination processes and applications will use the Consolidated Customer Database instead of the internal Staging, Audit, Valuation and Actuals database for core customer data after the enhanced customer information from Staging database is uploaded into CCD. This upload will occur as soon as the data is verified and certified. From that time on, Benefits Determination will automatically use the most recent customer information known in PBGC even if it is updated via Benefits Administration processes.

The concept of the Consolidated Customer Databases includes mediating data services, which encapsulate details of physical implementation of the customer information and allow consumers of the customer information to access it. In such architecture, a Data Integration solution is needed to provide a mechanism for other systems – especially COTS, warehouse, and reporting applications – to obtain and update a high volume of customer information. Benefits Determination will use this mechanism for customer information updates based on the results of customer information verification and determination of participants’ benefits (whenever the data elements being updated are among the core customer information). It is absolutely essential that the updates made via the Data Integration solution be monitored and processed via the same verification mechanisms as stand‐alone update requests.

Introduction of the MDM and the high‐volume Data Integration solutions will provide the following key benefits:

Capturing the change requests.

Creating an audit trail of the information updates as the approved change is applied.

Automation of the update approval decisions based on predefined rules.

Supporting the data steward’s manual decision making.

Exposing the Core Customer Information via data services and the selected Data Integration solution.

Ability to realize benefits of the Consolidated Customer Databases with COTS instead or custom‐ developed solution.

Please consult Figure 5, High‐level Transition Sequence Diagram, for the information on dependencies and precedence that may determine when this recommendation may be acted upon.

4.2.4 Recommendation 1‐4 ‐ De‐duplicate, Consolidate and Provide Access to Customer Information Currently in the Genesis and BFI Databases as

Applications Are Migrated

PBGC can implement the MDM and Data Integration solutions and organize the customer information among the four data stores for Customer Core, Benefit, Payment and Payment Fulfillment information, as described in full detail in the Sections 7.3.3.2‐7.3.3.4. The Team recommends that Core

Customer Information be protected with the MDM solution services and that there be no direct access to the data stores of Customer Benefit or Payment information.

PBGC should gradually transition to the target state by following the detailed migration plan developed according to recommendation 1‐2 above (please see section 4.2.2 for more details). As applications are migrated to use the new data services providing access to the Customer Core, Benefit and Payment information, old application databases must be modified to exclude the customer information and consolidate the remaining application‐specific data in a minimum number of the data stores necessary to meet the application’s non‐functional requirements. BCVS needs to follow this guideline to obtain customer information from CCD but leave its customer information verification and certification data structures to be used before the newly acquired customer information is prepared to be merged into

CCD.

At the same time, adding new consuming applications to the customer data services may introduce requirements that were not expected before. In such cases, a new version of the data services must be implemented within the release schedule of the new consuming application being migrated. Whenever a new version of a data service is implemented, it is recommended that the data service implementation project takes into consideration the high‐level requirements expected from the applications scheduled for migration in the coming 2 years.

Benefits Determination is one of the sources of customer information in PBGC. Information about new participants is acquired, verified and enhanced, and then synchronized with existing customer records.

This is one of the core functions of Benefits Determination, which is supported now and will have to be supported in BCVS (future of ACT). This requirement differentiates BC VS from other systems that use customer information. In particular, the BCVS’ Staging, Audit, Valuation and Actuals database will have to maintain an area for the customer information even after it fully uses the CCD. BCVS will use this area only for the period of time necessary to prepare the newly acquired customer information for merging into the CCD. Once the information is merged, CCD becomes the gold source of the customer information (not the valuation details) for the plan and BCVS will use the data access services of CCD to obtain current information for the plan participants.

It is also recommended that legacy database objects be considered for consolidation and de‐ duplication once the customer information is migrated to the Consolidated Customer Databases.

The expected outcome from this recommendation is that the number of duplicate replicas of the customer information will be minimized and thus eliminate the possibility of inconsistent results in different applications and cost of developing and maintaining synchronization and reconciliation interfaces. For example, there will be one single trusted version of the customer information for determination of benefits. And there will be no need for regular synchronization between the Benefits

Administration store of customer information (currently PRISM and Spectrum in Genesis) and the Leo database. or additional synchronization of the Leo database with the valuation database in ACT.

Establishing the data access services layer around customer information will eliminate interdependencies among applications.

4.2.5 Recommendation 1‐5 – Participate in Implementation of the Plan Master Data Management

Core Plan Information should be managed in the Master Data Management (MDM) solution and

Benefits Determination assess and provide its requirements for the Core Plan Information to the

Pension Plan MDM development effort. Core Plan Information (e.g., identification of the plan, name, address, status, participant count, etc) is described in the section 7.3.3.3. PBGC needs to select the

MDM solution.

EA performed analysis of the areas of PBGC business that rely heavily on the pension plan information.

In particular, EA analyzed FOD Collection and Compliance Division (CCD) business processes, PAS system accounting filings and premiums received from active pension plans and the plan termination sequence of milestones supported by the CMS system. Analysis showed that PBGC systems managing plan data use different identifiers for the same pension plan. It also noted that identification of the pension plans is not a primitive operation taking into consideration possible mergers, spin‐offs, etc. PBGC needs a common way to identify the pension plans and a single view of basic information about pension plans shared by the entire corporation. EA drafted a Pension Plan MDM model3 and presented it to CCD and

ITBMD managers. The presentation built consensus that Pension Plan MDM will be incorporated into the target state of the PBGC systems using the plan information. Meanwhile, these systems have to start analysis of their usage of the pension plan information and contribute to the definition of the requirements for Pension Plan MDM store when the project starts.

Benefits Determination needs plan information to perform its functions and will benefit from using the

Pension Plan MDM repository in its systems (BCVS, Leo, etc). Benefits Determination is recommended to analyze its use of plan information and contribute its requirements to the Pension Plan MDM implementation effort.

Introduction of the MDM solution will provide the following key benefits:

Consistent approach for pension plan identification throughout PBGC.

Capturing the change requests to the core plan information.

Creating an audit trail of the information updates as the approved change is applied.

Automation of the update approval decisions based on predefined rules.

Protection of the core plan information from direct access via data services.

3 Pension Plan MDM model presentation materials can be found on the PBGC portal at:

http://pbgcportal.prod.ent.pbgc.gov/portal/server.pt/gateway/PTARGS_32_0_345_0_- 1_47/http;/pbgcportal2.prod.ent.pbgc.gov;11930/collab/do/document/overview?projID=104779&documentID=1940

Please see Figure 5, High‐level Transition Sequence Diagram, for the information on dependencies and precedence that may determine when this recommendation may be acted upon.

4.2.6 Recommendation 1‐6 ‐ Establish Data Quality Maintenance Practice and Processes For All Customer Information

PBGC should establish and follow the data quality maintenance processes4 to achieve and maintain high quality of the customer and core plan information while migrating the applications to the

Consolidated Customer Databases and after the migration activities are finished. The processes established must add the formal structure, sustainability and direction of the data quality activities on the customer and core plan information and fully utilize the data quality capabilities of the MDM and other data quality solutions available in PBGC (Trillium products, Address Validation Service (AVS), Bulk

AVS, etc.). These processes should also have the success‐measuring component to monitor the improvement in overall data quality and to coordinate future activities based on the performance results. PBGC should consider for reuse the conversion, monitoring and data profiling processes used as the basis of the pilot data quality initiative in 2005‐2007. PBGC should also reuse the validation rules and reasonableness checks currently employed by the Benefits Determination in the data acquisition phase.

Benefits Determination processes require quality customer information as a basis for the determination of customer benefits. BCVS in the target state is envisioned to obtain the customer information from the Consolidated Customer Databases. So that Benefits Determination will be one of the biggest beneficiaries of the data quality improvements in the CCD.

Business and data analysis performed as part of this segment effort highlighted the significance of the reliable customer information for Benefits Determination processes. These analysis results along with the results5 of the data quality audit of the BAPD databases performed by EA in 2005 and 2007 underline the need in establishing coordinated, sustainable and persistent processes for maintaining the quality of the customer information.

Having the two pilot audits performed on the same area of data (GENown schema of the Genesis database) also allows for the comparison of the results of data quality monitoring performed in different years. Monitoring results show that the number of records in GENown with invalid or abbreviated

4 EA Data Quality audit effort produced several processes which can be found in PBGC portal at:

1_47/http;/pbgcportal2.prod.ent.pbgc.gov;11930/collab/do/document/overview?projID=3904&folderID=96759

5 Results of the previous Data Audit are available in PBGC portal at

1_47/http;/pbgcportal2.prod.ent.pbgc.gov;11930/collab/do/document/overview?projID=3904&folderID=96759 customer names grew 17% between 2005 (71,023 records) and 2007 (83,044 records)6 despite the data clean‐up initiatives BAPD (called IOD in 2005) has done.

The expected benefits of this recommendation are:

Establishing the focus areas and validation rules for use in preparation of the existing Customer information for implementation of the MDM solution (prerequisite to MDM implementation).

Ability to monitor the data areas in scope, plan data quality improvement or remediation efforts.

Ability to define and monitor the progress and success of the efforts.

Ability to monitor the scope, depth and complexity of the data quality profiling and monitoring.

Consistent and effective use of the available data quality products for automation of the data quality activities.

4.3 Improvement Area #2 – BCVS Recommendations

The Benefit Calculation and Valuation Solution (BCVS) is the PBGC vision for the next generation of the system for determining individual benefits of participants and plan and PBGC liabilities. BCVS must replicate the strengths and overcome the weaknesses of the existing systems used for these purposes:

Actuarial Calculation Toolkit (ACT) and Ariel.

ACT is a suite of custom‐built applications. Actuaries use MS Excel to define calculation logic which is applied to the data stored in a MS Access database on a local client workstation. Once the actuary’s work is complete, reviewed and approved, all relevant electronic files are archived using a standard tool.

The main strength of ACT tools is the flexibility and unlimited control that they provide to case teams.

Ariel is an externally hosted and owned system provided to PBGC as a service offering by Morneau

Sobeco. Morneau Sobeco is the Application Service Provider in relationship to PBGC and other of its clients. Ariel has substantial sets of calculation rules and algorithms its clients may choose from to build their calculation sequence and provide input into. Ariel’s biggest strengths are in standardization of the calculations and availability of controls over the changes in data and logic.

Benefits Determination analysis performed a more detailed comparison of the strengths and weaknesses of ACT and Ariel as well as the combination of the high‐level requirements that BCVS will need to achieve. The high‐level requirements can be found in section 7.2.1.

6 GENown Data Quality Monitoring. Baseline audit report, 2007 (most recent audit) in PBGC portal at http://pbgcportal.prod.ent.pbgc.gov/portal/server.pt/gateway/PTARGS_32_0_345_0_- 1_47/http;/pbgcportal2.prod.ent.pbgc.gov;11930/collab/do/document/overview?projID=3904&documentID=96945

This improvement area provides a description of specific…