HC1028-13-R-0039-0005_Amend_Copy.doc

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION C - DESCRIPTIONS AND SPECIFICATIONS

The following have been modified:

PWS

PERFORMANCE WORK STATEMENT (PWS)

As of October 11, 2013

1. IDENTIFICATION INFORMATION

a. Primary Contracting Officer Representative (COR).

Name:

Organization:

Department of Defense Activity Address Code (DODAAC):

Address:

Phone Number:

Fax Number:

E-Mail Address:

b. Alternate Contracting Officer Representative (AltCOR).

Name:

Organization:

Department of Defense Activity Address Code (DODAAC):

Address:

Phone Number:

Fax Number:

E-Mail Address:

2. CONTRACT TITLE. System Integrator Professional Services for the Purchase Card On-Line System (PCOLS) Data Mining (DM) Application

3. BACKGROUND.

The Department of Defense (DoD) Purchase Card Program’s initial implementation strategy for the use of Government Commercial Purchase Cards was to encourage use of the purchase card wherever practical to streamline small purchase procurements and pass the internal savings on to the war-fighter. In March 1997 the Office of the Under Secretary of Defense (Acquisition & Technology) issued a memorandum that effective October 1, 1997, contracting officers shall not award contracts or purchase orders for micro-purchases unless a written determination is made by a member of the Senior Executive Service, Flag Officer, or General Officer that the source(s) available do not accept the purchase card, or the nature of the procurement necessitates a contract or purchase order so that the terms and conditions can be specified (e.g., safety/critical parts that require government source inspections). This action resulted in the issuance of a large number of cards and inadequate purchase card program internal controls. This lack of tight internal controls coupled with other purchase card policy compliance issues contributed to fraudulent and abusive spending, theft, and misuse of Government property by purchase card program officials and cardholders. Discussion of the specific purchase card policy compliance and internal control problems experienced can be found in numerous Government Accountability Office (GAO) and the DoD Inspector General (DoDIG) audit reports issued during FYs 2001-2003.

In March of 2002, the OUSD (Acquisition, Technology and Logistics (AT&L)) charted the Charge Card Task Force to evaluate departmental management and the use of cards issued through the Government Purchase Card (GPC) Program. The task force developed 25 recommendations that were to improve significantly the Departments charge card programs. Examples include: Increase management and accountability; strengthen internal controls; and enhance the capability of the workforce to accomplish assigned charge card responsibilities.

In 2002 the OUSD (Comptroller) signed out Management Initiative Decision (MID) 904 mandating remedies to control identified deficiencies. Comptroller DoD MID 904 directed approximately 50 actions, including:

- Develop methods to ensure controls over charge cards

- Develop a data mining tool to identify misuse of charge cards

Since the time MID 904 was signed out, DoD has taken numerous corrective actions to increase policy compliance and strengthen internal controls over the program. For example, the number of purchase cards issued has been reduced to a manageable level. Also, a consolidated list of internal controls specifying the minimum purchase card program requirements that must be met by all DoD component purchase card programs has been developed. Despite these actions, however, instances of fraud, misuse, and abuse continue to be identified. This has prompted DoD to look for additional means to identify fraud, misuse, and abuse. One of the key areas of focus is for identification of fraud, misuse, and abuse through At-risk Purchase Card Transactions.

Specifically, the Defense Procurement and Acquisition Policy Defense Pricing/Program Development and Implementation/Purchase Card Policy Office (DPAP/PDI/PCPO) has partnered with the Defense Manpower Data Center (DMDC) and Industry for the development, maintenance, and operation of a suite of applications that addresses the policy compliance and internal control issues identified by GAO, DoDIG, and the DPAP/PDI/PCPO. These applications are collectively known as PCOLS. The objective of PCOLS is to supplement the baseline internal control capabilities that are operational in the card issuing Bank’s electronic application.

The development of PCOLS is in direct response to Congressional, GAO, DoDIG, MID 904 and DPAP/PDI/PCPO mandate to:

· Capture the full purchase card hierarchy that re-establishes Supervisors into the reconciliation/review process

· Improve internal controls

· Use of the Common Access Card (CAC) to identify users

· Mine purchase card transactions for fraud and misuse

DMDC is the DoD’s human resource information source, serving as the authoritative source of information on over 42 million people now and previously connected to DoD. DMDC provides secure services and solutions to support DoD's mission, and is recognized as a world leader in identity management. Since 1974, service members and their families have been served by DMDC through individuals based all over the world.

In 2007, the DPAP/PDI/PCPO procured from Industry a Data Mining and Risk Assessment (DM/RA) capability to:

1) Identify and report fraudulent and abusive spending, theft, and misuse of government property associated with its purchase/payment cards.

2) Report on the overall health of DoD Purchase Card Programs at various levels in the reporting hierarchy.

The DM application uses the FICO’s Falcon Fraud Engine V5.2c™ as an integral part of the Risk Predictive Model for the identification of At-risk Purchase Card Transactions (See Section 6.2.1 Subtask 1 – DM Application Risk Predictive Model). The initial RA Application was developed to assess and report on the overall "health" of a DoD organization's purchase card program.

DM/RA went “live” in July of 2009. At that time, Authorization, Issuance and Maintenance (AIM), Enterprise Monitoring and Management of Accounts (EMMA), and the Sign-on and Referral System (SRS) were operational. A few defense agencies and Air Force bases were active within AIM.

Currently, the PCOLS Application suite consists of Government and Industry developed and maintained components. There are four (4) Government developed applications and the Government developed Single Sign-on Functionality. There is one (1) Industry developed and maintained application. The four Government applications listed below are hosted and supported by DMDC.

1) The Authorization, Issuance and Maintenance application.

2) The Enterprise Monitoring and Management of Accounts application.

3) PCOLS Reporting, and

4) PCOLS Risk Assessment Dashboard (RAD).

DMDC provides the Single Sign-on Functionality (SRS).

Industry developed and maintains the Data Mining application. This application is hosted within a Government enclave.

The Data Mining component of the PCOLS Suite of Applications was developed to perform Data Mining on DoD Purchase Card Activity. Purchase card transactions are processed by the banks and sent through the DoD Global Exchange Service (GEX) to DMDC. DMDC forwards the transactions to DM. The DM application begins with a DoD specific rules-based component and a neural learning component that: (1) measures and reports the risk of all transactions no less than daily; (2) initiates requests for review of At-risk Transactions no less than daily; (3) includes the user interface for transaction reviews; (4) creates and updates risk profiles for individual cardholder accounts based on buying patterns and review results no less than daily; and (5) stores and forwards the resolution results of At-risk Transaction reviews.

Benefits of DM:

· Programmatic review and scoring of all DoD Purchase Card Transactions,

· Facilitates the email notification of At-risk Transactions,

· Case Manager to allow end users to adjudicate cases,

· Maintains case escalation schedule, and

· Archival of adjudicated information.

The Data Mining functionality is accomplished through two main components within the existing DM application. The first component is the Risk Predictive Model and the second component is Case Management.

One of the key areas of DPAP/PDI/PCPO focus is for the identification of fraud, misuse, and abuse through At-risk Purchase Card Transactions. The Risk Predictive Model scores each of the DoD Purchase Card Transactions. DM cases are generated by the Risk Predictive Model either based on a score that indicates risk or random transaction. Industry-leading analytics that are used within the model for the scoring of purchase card transactions to detect fraud, waste, abuse, and misuse form part of the baseline application suite. The model is calibrated to flag 3% of the total transactions as At-risk Transactions and to flag 1% of the total transactions as random. Approving/Billing Officials are required to work all cases (flagged transactions). Also, At-risk Transactions that score 900 and above are considered High-risk Transactions. These High-risk Transactions require an Independent Review.

The Case Manager is the component that provides the graphical user interface to the user that allows for the review of transactions and documentation of At-risk Transactions. This interface allows the user to navigate to a specific case (At-risk Transaction) and disposition the case. Currently, the cases are categorized as New, Under A/BO Review, Legacy, and Closed. The Case Manger provides drill down capabilities for each case category. The Case Manager allows for self-initiation (by A/BOs only) of a case for review (as opposed to a case that is flagged for review by the Risk Predictive Model). Independent Reviews are performed within Case Manager. A/OPCs are required to perform Independent Reviews of high-risk transactions. Also, Independent Reviews are optionally performed on any case by A/OPCs and others higher in the organizations hierarchy. An 18 month rolling history is maintained and available for access. Also, a Find Transaction feature is available within Case Manager. This Find Transaction feature allows users to search through all transactions under their hierarchy to review the data or refer additional cases that have not been identified for review by the application.

The PCOLS Suite of Applications lives within the overall PCOLS ecosystem, which is described in detail in the DoD Micro-Purchase & Purchase Card Data Management Plan. This data management plan can be found at the DPAP PDI Web site: http://www.acq.osd.mil/dpap/pdi/pc/docs/DOD_PCPO_DataMgtPlan_June_2012.pdf In Fiscal Year (FY) 2010 DoD issued over 40,000 Government purchase cards, at any time having approximately 105,800 purchase card accounts and approximately 49,000 managing accounts; and processed over 8,000,000 purchase card transactions through the PCOLS application valued at over $7,800,000,000. In FY2011card accounts remained steady at approximately 105,800. Overall spend decreased to $7,250,000,000.

Currently, the Air Force and the Defense Agencies are fully deployed in PCOLS. The Army is expected to be fully deployed by the end of Calendar Year 2013. The deployed components disposition approximately 12,000 DM cases per month.

Additional background information on the purchase card program and PCOLS may be obtained at the Defense Procurement and Acquisition Policy Defense Pricing (DPAP), Program Development and Implementation (PDI) website: www.acq.osd.mil/dpap/pdi/pc/index.html

4. OBJECTIVE.

The over-arching objective of this procurement is the acquisition of Information Technology (IT) Professional Services to perform comprehensive System Integration Services. The System Integrator (SI) shall bring together component subsystems into a whole and ensuring that those subsystems function together efficiently. Also, this SI shall provide data management that utilizes methods of artificial intelligence, machine learning, predictive analysis, statistics, and database systems for the data mining process to extract information from data sets and transform the data into a logical structure for use by the DM application. Additionally, this SI shall work with the Government to enable cross-functional DoD groups to support and enhance PCOLS. This support includes managing and integrating the baseline applications and data sets, evaluating alternatives to the baseline, management of workflows, software development, and the updates to the evolving data management strategy to engender efficiency and increased effectiveness in the PCOLS Program within the Procure-to-Pay ecosystem of systems in the DoD. Further, this SI shall work with DPAP/PDI/PCPO to address the initial objective of DM coming out of MID 904 to strengthen internal controls for the purchase card program and to identify fraud, misuse, and abuse through the identification of At-risk Purchase Card Transactions.

The functional business objective is to Mine Data from DoD Purchase Card transactions via the deployment of a data-screening application that uses a combination of discreet DoD-tailored business rules to detect card misuse and a "neural learning" capability that enables the identification of transactions at the most risk of being fraudulent or abusive. The transactions mined are screened, scored, and, when appropriate, referred to purchase card approving officials for review, adjudication, and archive. In some situations, the transactions are referred to program coordinators. The application was architected to "learn" from past transactions to build a knowledge base that improves scoring accuracy over time by reducing false positives.

The business requirements include:

1) Identification of At-risk Purchase Card Transactions

2) User Interface for Dispositioning and reporting of At-risk Purchase Card Transactions

3) Integration with the PCOLS Reporting and RAD applications

4) Production of metrics regarding the status of Purchase Card programs that are administered by DoD Components

5) Production of metrics that identify compliance with the laws and regulations governing the Government Purchase Card Program as directed by DPAP/PDI/PCPO

6) Sustainment of the existing Data Mining application

7) Little-to-no retraining of the Purchase Card Administrative personnel (A/OPCs at all levels and help desk personnel) in the use of the Data Mining and Risk Assessment components

In summary, the DM application provides improved surveillance of the DoD purchase card transactions through identification of At-risk Transactions, the notification of the cognizant GPC officials, and the follow-on dispositioning of those transactions by the cognizant GPC officials.

The Government requirement is to award a firm fixed priced (FFP) Indefinite Delivery/Indefinite Quantity (ID/IQ) Contract for the acquisition of services and software using a SI approach, which produces improved efficiency in the DoD GPC Program. This performance-based approach will apply to the baseline DM (See Section 6.1 System Integrator) or for other defined software enhancements via separate Task Orders (TOs).

5. SCOPE.

The Contractor shall provide the necessary facilities, qualified experienced personnel, supplies and equipment necessary to operate, update, and maintain the baseline DM application specifications as defined in this PWS. A single FFP ID/IQ Contract will be awarded with a base year and four (4) option years.

6. PERFORMANCE REQUIREMENTS.

6.1 Task 1 – System Integrator.

Background:

The primary source data for DM is GPC Transactional Data. This data is sent by the banks to the GEX, from the GEX to DMDC, and from DMDC directly to DM. DM consumes the transactional data sent by DMDC and passes the data through the Risk Predictive Model, of which the FICO’s Falcon Fraud Engine V5.2c™ is an integral part. For the purposes of determining the cost of the Risk Predictive Model, the Contractor shall obtain the cost of the FICO’s Falcon Fraud Engine V5.2c™ from FICO.

Any action taken on a transaction within Case Manager is recorded within DM and the action reflected in a data feed to DMDC. In addition to the daily transactional data, there are monthly files sent from the banks. The files generally follow the same path from the banks through the GEX to DMDC and then from DMDC directly to DM.

The GEX provides message broker and mediation services between multiple DoD and Federal Government agencies as well as Industry. As the GEX is used as the primary message broker for PCOLS, the DM application is required to be work closely with DMDC and the GEX to ensure that DM downstream interfaces are compatible with the GEX.

DM is deployed within a Government enclave. This enclave is the Defense Information Systems Agency (DISA) Defense Enterprise Computing Center (DECC) at Mechanicsburg, PA. The DM application is required to work closely with DISA to ensure ongoing operational capability. DISA provides virtual Continuity of Operations Plan COOP. The Contractor is not expected to provide COOP and the Contractor is not expected to change the existing, baseline application to support COOP Requirements.

All PCOLS components are CAC enabled. DMDC maintains the SRS for CAC authentication. The application user credentials for identity management shall be retained in the new business arrangement. User credentials are “inherited” as the user navigates within the PCOLS Application suite.

The DM application uses a role based access method. Once a user has been authenticated by SRS, the user is passed to DM for role based authorization. This role based authorization is accomplished in DM by using a Hierarchy File originating from DMDC. DMDC maintains PCOLS user hierarchies and active users.

The DM hierarchy is based on bank purchase card bank hierarchy. Navigation within the DM application is based on this bank hierarchy. Role based access to DM is dictated by the hierarchy established in EMMA and AIM.

6.1.1 Subtask 1 – Bank Files, GEX, and DMDC Integration.

6.1.1.1 The Contractor shall assist the Government in managing all interfaces for the DM application.

6.1.1.2 The Contractor shall develop and maintain (dependant upon their proposed solution) automated procedures for the validation of file transfers within stated interfaces. The Contractor shall develop (as required) and maintain automated procedures for exception processing for these stated interfaces and procedures for the manual processing of data as a back-up procedure.

6.1.1.3 The Contractor shall support the baseline data mapping requirements between the deployed Data Mining application, the Risk Predictive Model, and the Case Manager.

6.1.1.4 The Contractor shall support the creation of data migration tools (load utilities/programs) for data migration. The Contractor shall support the following areas:

1) Testing the data extraction, transformation and load process

2) Performing tests for QA

3) Performing data validation to ensure no loss of data occurred during the data load

4) Establishing data archival and historical data retention plan data, including retention timeframes for archived data

5) Documenting the data migration and loading steps and sequence required to extract and load data from all legacy systems.

6.1.1.5 The Contractor shall support updates that occur within the PCOLS ecosystem.

6.1.1.6 The Contractor shall support the creation of Data Loading and Migration Specifications (to include the data loading Application Programming Interfaces (APIs) required for loading new bank data into the application as new banks are brought on-board (e.g., Non-Appropriated Fund (NAF) purchase card issuing bank).

DELIVERABLES:

Applications Architecture

6.1.2 Subtask 2 – PCOLS Application Integration.

6.1.2.1 The Contractor shall assist the DPAP/PDI/PCPO to maintain and support applicable DM system interfaces to ensure effective PCOLS application integration.

6.1.2.2 The Contractor shall maintain the CAC authentication process that is currently in place to ensure that a user of the DM application has the proper authentication. The Contractor shall document this information in an Applications Architecture.

DELIVERABLES: Applications Architecture

6.1.3 Subtask 3 – Role Based Authorization.

6.1.3.1 The Contractor shall support the capability to consume the DMDC Hierarchy File. Normally, this file is transferred to DM twice daily, Monday-Friday. The Contractor shall process the hierarchy file when sent by DMDC.

6.1.3.2 The Contractor shall maintain the role based authorization capabilities of the DM application. The Contractor shall use the data within the hierarchy file to update role based access each time the file is processed.

6.1.3.3 The Contractor shall support the process by which the user selects a role. The Contractor shall ensure that the user is granted access to only data within their hierarchy.

6.1.4 Subtask 4 – DM Integration Rollout Management.

The Contractor shall perform and support activities during Initial Rollout for off-site and on-site activities that are focused on providing guidance, assistance and support for the Go-Live event and a post Go-Live transition period. This support may include, but is not limited to, functional business scenario solution support and guidance (e.g., over-the-shoulder support), data and process validation, workflow support and Go-Live preparation and post Go-Live assistance to overcome any initial cutover problems. The Contractor shall describe the support activities, assistance, and time frames associated with the Initial Rollout in the Integration Strategy Report.

DELIVERABLES:

Integration Strategy Report

6.2 Task 2 – Data Mining Application

Background:

Data Mining reviews 100% of the DoD Purchase Card Transactions to provide transaction monitoring and historical access to the transactions. The input to the model is the purchase card transaction from the bank and the output is the scored transaction file that contains a risk score for each purchase card transaction. This risk score is based on multiple factors that are indicative of perceived transaction risk. These factors include the DoD-specific business rules along with Credit Card Industry standard risk predicative indicators.

The DPAP/PDI/PCPO has furnished the model developer DoD-specific business rules that are related to card misuse. Hence, these rules form the basis of the DoD-specific business rules that influence the transaction score. The outcome of these business rules are reflected in the Reason Codes that are assigned to transactions by the model. More than one Reason Code may be assigned to a transaction. The risk scored is affected by the Reason Codes. The table of current Reason Codes is attached (See Attachment 2 – Reason Codes). Point of sale, real time fraud monitoring is accomplished by the purchase card issuing bank(s) and the purchase card associations (VISA/MasterCard). If the risk score exceeds a defined threshold, the transaction is flagged at-risk and a case is created for review in the Case Management Module (See the following Section 6.2.2 Subtask 2 – DM Application Case Manager and Case Management.).

The DM Risk Predictive Model, of which the FICO’s Falcon Fraud Engine V5.2c™ is an integral part, includes a neural learning capability whereby the system can “learn” from cardholder and A/BO behavior (e.g., buying patterns, disposition of prior cases, etc.) to improve the model’s ability to detect purchase card fraud, waste, abuse, and misuse. This learning capability is an integral part of the model solution that assists in avoiding false positive cases. The model retains this information in account profiles. These account profiles are used by the model when a transaction is scored.

When a transaction scored by the Risk Predictive Model exceeds a defined threshold and is flagged “at-risk”, a case is created for review by the A/BO. The case is presented in a role-based user interface (Case Manager) that functions as a tool for adjudication of the case. This user interface enables authenticated and authorized users to find purchase card transactions and cases where risk has been identified. The user interface collects information from the user about an At-risk Transaction by presenting to the user a series of questions based on the transaction type. The user interface enables the assignment of a disposition to the case by the end user. The user interface functionally includes:

1) Interview process to facilitate the disposition of a case,

2) Action History of the case,

3) Independent Review of the case (if applicable),

4) Drill down navigation within the hierarchy,

5) Statistics related to the cases,

6) Find Transaction functionality,

7) Other display functionality (screen navigation).

The Case Management functionality determines the notifications that are to be sent to the end users of Data Mining. The Case Management functionality is responsible for determining when an A/BO should be notified that a case has been flagged and requires adjudication. The notification information is populated in a file that contains the flagged transaction information. This file is referred to as the At-risk File and is transferred to DMDC for end user email notification (email addresses shall be provided by the Government and addressing is accomplished by the Government). The Case Management functionality maintains the escalation schedule to determine when notices should be sent if a case has not been dispositioned in a timely manner. This notification information is transferred to DMDC in the At-risk File. The Case Management functionality facilitates the notification of the A/OPC when a case has been closed and when there is high-risk transaction that requires an Independent Review. This notification information is transferred to DMDC in the At-risk File. DMDC is responsible for the actual email notifications.

Approving/Billing Officials are the first line users of the DM Application. Email notifications inform A/BOs that there is a case that requires a review within DM Case Manager. The A/BO documents the review within Case Manager. The referred cases are assigned for examination and displayed on the "Case Statistics" page. There is an escalation process that affects the risk assessment rating, which is reflected within PCOLS RAD. If the cases are not reviewed timely, the case may be escalated through the hierarchy and ultimately to the DPAP/PDI/PCPO.

The A/BO opens a case for review in order to answer the interview questions pertaining to the case review. The A/BO can open a case by various methods including link in email, drill down from Case Manager Case Statics, etc.

“Case Statistics” are shown in the “Case Management” view:

1) The first column "Level" in Figure 4 shows all the managing accounts that are under the purview of the A/BO.

2) The second column "NEW" shows the number of cases that have not yet been reviewed.

3) The third column "UNDER A/BO REVIEW" shows the number of cases under review (pending cases).

4) The fourth column "LEGACY CASE" shows the number of cases that have been marked as Legacy.

5) The fourth column "CLOSED" shows the number of dispositioned cases that have been reviewed and closed by the A/BO.

Once all the questions are answered and the disposition selected along with Recommended Action (if applicable), the case is fully dispositioned. The review data is stored within the application when the "Save" button is selected. Action History is updated at this time.

All A/OPCs and above have “read only” access to review transactions within their organizational hierarchy. This access allows A/OPCs and above to see everything the A/BO has entered to close a case including the case disposition, description, and any notes. A/OPCs and other authorized users may conduct an Independent Review. This review can only be done after the A/BO completes an initial review of the transaction.

Within the Case Details screen there is an "Add Independent Review" button. This button is in the Action History Frame. After reviewing the A/BO's case analysis, the independent reviewer clicks the "Add Independent Review" button and completes the information in the popup box displayed documenting his/her assessment of the A/BO's determination. The user has the following choices for case disposition: Valid Transaction, Administrative Discrepancy, Misuse, Suspected Fraud, Abuse, Lost, or Stolen. Users must include any discrepancies or justification in the comments field. If applicable, a Recommended Action must be selected.

The Contractor is not to provide a new DM application (includes the Risk Predictive Model and Case Manager), but is to only maintain and support the existing, baseline DM functionality.

Periodically, upgrades to hardware and software components within DM are required in order to assure continued supportability and interoperability of the system. (e.g., changes to browser versions). The System Service Lifecycle is extended through these planned and cost effective technology upgrades that address and avoid hardware and software obsolescence. This requirement does not apply to optional changes selected by the Government, such as application or database changes, which shall be adjudicated in task orders as appropriate.

6.2.1 Subtask 1 – DM Application Risk Predictive Model.

6.2.1.1 The Contractor shall maintain and support the existing, baseline Risk Predictive Model, of which the Falcon Fraud Engine V5.2c™ is an integral part, that scores purchase card transactions based on multiple factors that are indicative of risk. The Contractor shall utilize the baseline cardholder account profiles that are used within the baseline model solution. The Contractor shall utilize the existing, baseline model that includes a neural learning capability that increases the probability of detecting purchase card fraud, waste, abuse, and misuse while decreasing false positive cases.

6.2.1.2 The Contractor shall link model output so that it can be accessed in the DM application Case Manager (i.e., the flagged At-risk Transactions can be viewed by the DM application users through a graphical user interface). Controls shall be developed and maintained to ensure data quality and integrity of the data from source inputs, through the model, and all downstream processes. The Contractor shall provide an assurance mechanism to account for transaction data being transferred from the model to the portal and the reverse.

DELIVERABLES:

Risk Predictive Model (software)

6.2.2 Subtask 2 – DM Application Case Manager and Case Management.

6.2.2.1 The Contractor shall maintain the baseline Case Manager User Interface. The user interface, shall consume scored transactions from the model, provide functionality for the display of case statistics, capture and record case disposition data, and provide access to all transaction information to authorized users.

6.2.2.2 The Contractor shall maintain Case Management functionality that populates the Case Manager User Interface and facilitates the notification of users of the status of flagged transactions. This functionality includes all of the notifications related to the dispositioning of cases and the associated escalation schedule.

DELIVERABLES:

Case Manager (software)

Case Management functionality (software)

6.3 Task 3 – Operations and Maintenance.

6.3.1 Subtask 1 – At-Risk Notifications.

The Contractor shall support functionality to achieve parity with the baseline At-risk Notification File. PCOLS relies heavily on email notifications to ensure the end users are aware of actions being taken with the PCOLS ecosystem. The DM Case Management functionality facilitates the notification of actions taken within DM. The DM application produces an At-risk Notification File that includes information that DMDC uses to notify end users (DMDC maintains the email addresses and sends emails). Notifications are sent when a new case is generated, when the case is closed, and if the case has been escalated.

DELIVERABLES:

At-risk Notification File

6.3.2 Subtask 2 – Bank File Processing.

The Contractor shall consume the daily and monthly bank files. As mentioned previously, DMDC receives the daily bank transactional files from the GEX. The data file is forwarded along to the Contractor (Tuesday through Saturday). Also, there is a monthly bank file. DMDC is responsible for the archive of both of these file types.

6.3.3 Subtask 3 – Daily Transaction File.

The Contractor shall return to DMDC the scored daily transaction file (Tuesday through Saturday). As daily bank files are received by the Contractor, they shall be processed through the Risk Predictive Model. The model will assign a score to the transaction.

DELIVERABLES:

Scored Transaction File

6.3.4 Subtask 4 – Case History File.

The Contractor shall return to DMDC an updated case history file (daily). The case history file provides to DMDC updates that have been made through the DM Case Manager User Interface.

DELIVERABLES:

Case History File

6.3.5 Subtask 5 – Government Hierarchy File.

The Contractor shall consume the Government Hierarchy File from DMDC and use the data contained within the file for role based access. The Contractor shall provide assurances that Government Hierarchy file has been processed. The baseline functionality is that an email is sent when each file has been processed and loaded.

6.3.6 Subtask 6 – DM Application Data.

The Contractor shall maintain a rolling 18 month history of transactions available through the DM application. The Contractor shall delete all transaction data from the DM application database that is older than 18 months. The Contractor shall report on the number of transactions that have been purged.

DELIVERABLES:

Database Purge Report

6.3.7 Subtask 7 – DM RPM Reporting and Updates.

6.3.7.1 The Contractor shall provide to the DPAP/PDI/PCPO evidence that demonstrates the level of correlation between the DoD-specific risk indicators along with the other scoring factors and the transactions actually determined to be fraudulent or abusive. The Contractor shall report to the DPAP/PDI/PCPO this evidence quarterly. At a minimum, the Contractor shall produce a report that contains the following:

1) Summary of all of the bank transactions processed,

2) Summary of the cases flagged by the model as At-risk Transactions,

3) Error and warning codes produced by the Risk Predictive Model,

4) Risk Predictive Model score distribution of all transactions,

5) Summary of reason code occurrences for flagged transactions,

6) Summary of Case Dispositions based on closed cases,

7) Relative performance of the model (random cases versus model score),

8) Statistical evidence that the model is learning and providing specific instances where the referral of cases was affected (reduction in false positives) due to neural learning and/or dynamic changes to the model affecting flagging resulting from neutral learning. Statistical evidence shall consist of, at a minimum, a selected case study of an organization’s card transactions, an examination of the results, and recommended changes to the Risk Predictive Model resulting from the organization’s profile and results.

9) Recommendations for model improvements.

6.3.7.2 The Contractor shall recommend to the DPAP/PDI/PCPO updates and refinements to the DoD-specific risk indicators based on information acquired from the implementation of the model and experience obtained during the performance of the contract. The Contractor shall recommend to the DPAP/PDI/PCPO updates to the model based on new or modified rules, which may be weighted as to their importance. The Contractor shall update the Risk Predictive Model not less than semi-annually upon a review of Model Performance in conjunction with the DPAP/PDI/PCPO.

DELIVERABLES:

DM Model Metrics Report

6.3.8 Subtask 8 – Technology Refresh.

6.3.8.1 The Contractor shall be responsible for the effective management of technology refreshment and attendant tasks within the scope of this contract.

6.3.8.2 The Contractor shall provide a yearly report on the status of all system software used in the program. The Contractor shall use this report as a basis for the planned migration path for systems upgrades (technology refresh) and contractor support (i.e., when will the version go out of general support, require additional maintenance costs, etc.). The Contractor shall include this information in the Software Production Plan.

DELIVERABLES:

Software Production Plan

6.3.9 Subtask 9 – Weekly Status Reporting.

6.3.9.1 The Contractor shall schedule and host Weekly Status Meetings with DPAP/PDI/PCPO and other Government agencies designated by the DPAP/PDI/PCPO. Other integrations partners may be called in as needed. The Contractor shall distribute an agenda 24 hours prior to the meeting. The Contractor shall document the meetings with meeting minutes published within 48 hours after the completion of the meeting.

6.3.9.2 The Contractor shall maintain an enhancement development schedule. This schedule shall be updated no less than weekly and submitted to the DPAP/PDI/PCPO. The Contractor will provide weekly processing statistics to ensure the integrity of the interface points. The weekly report shall contain the following processing statistics:

1) Number of transactions received in each bank file and the date and time the file was processed.

2) Number of transactions processed through the Risk Predictive Model and the date and time the file was processed.

3) Number of transactions in the At-risk Notification File and the date and time the file was processed.

4) Number of transactions in Case History File and the date and time the file was processed.

The Contractor may provide any additional Management Reporting to the DPAP/PDI/PCPO.

DELIVERABLES:

Weekly Status Meeting Agenda

Weekly Status Meeting Minutes

Weekly Status Report

6.3.10 Subtask 10 – Monthly Status Reporting.

6.3.10.1 The Contractor shall provide to the DPAP/PDI/PCPO a Monthly Status Report. This monthly report shall contain the following program status information:

1) Program info (contract number, prepared by, key resources, including subs, etc.)

2) Estimated Financial "snapshot"; to include current month production support labor costs, next month forecast, total allocated and remaining budget by prime and subs, fixed operational costs, travel

3) Overall project status, and status of schedule, cost, quality, deliverables, risk and issues, denoted by green, yellow, or red

4) Project actual percent complete and forecast percent complete

5) Description of current month project activity (production fixes, new releases)

6) Description of next month's project activity

7) Issues resolved from the previous month

8) Open issues/problem areas and program risks

6.3.10.2 The Contractor shall prepare and deliver a monthly System Availability Summary Report. This report provides reporting on application availability. This report would, at a minimum, include any and all unscheduled and scheduled outages. Also, any scheduled processes that were missed or delayed. The Contractor shall provide within the System Availability Summary Report, reporting on general application utilization. This reporting would, at a minimum, include:

1) Number of logons per day,

2) Daily high concurrent users,

3) Hourly distribution of concurrent users,

4) Hourly CPU utilization, and

5) Case Manager Transaction timing (high, low, average).

6.3.10.3 The Contractor shall develop and deliver a DM Monthly Metrics Report. This monthly reports shall summarize all files that were sent and all files consumed and confirmed as being loaded. This summary should include metrics such as the number of roles that are loaded from the hierarchy file. This summary shall report on all of the At-risk Files, Daily Archive Files, and Case History Files that are transmitted to DMDC. File statistics shall be reported on. Summary reporting shall include reporting on the controls that are in place to ensure data quality and integrity of transaction data being transferred from the model to the Case Manager and the reverse. The summary report shall include reporting on any exception processing that occurred during the month.

6.3.10.4 The Contractor shall develop and deliver a DM Adjudication Summary Report. This monthly report shall contain a summary of the cases adjudicated (closed) during the month. This report shall reflect the total number of cases closed during the month and the case disposition that was selected for the case when the case was closed. This report shall include TBR Level 2 and TBR Level 3 summary levels.

DELIVERABLES:

Monthly Status Report

System Availability Summary Report

DM Monthly Metrics Report

DM Adjudication Summary Report

6.3.11 Subtask 11 – Quarterly Status Reporting.

The Contractor shall conduct Quarterly Program Management Reviews. This meeting shall include, at a minimum, a detailed review of the DM Model Metrics Report, any contractual issues, CDRLs review, status of planned software releases, status of production support, review of any pending enhancements, and any required design reviews.

DELIVERABLES:

Quarterly Program Management Review Agenda

Quarterly Program Management Review Minutes

6.3.12 Subtask 12 – Annual Operations Plan.

6.3.12.1 The Contractor shall provide a detailed Annual Operations Plan. This plan would include all staff working on the contract (labor categories and allocation), supplies and equipment necessary for support. The plan shall report on all key personnel actions.

6.3.12.2 The Contractor shall be proactive when it comes to systems operations and maintenance of the DM application. For example, consideration should be given to ensure end user access to the application is meeting agreed metrics. Currently, about one quarter of the entire DoD community are using the application on a regular basis. DPAP/PDI/PCPO expects that number to increase considerably over the next couple of years. The Contractor shall ensure that end user access is not affected by the addition of the new users and shall be able to provide load testing reports to demonstrate the application continues to function as expected with the additional users. The Contractor shall annually, at a minimum, use WinRunner (or similar tool) as a load testing tool operating at the Graphical User Interface (GUI) layer to report on application performance. The Contractor shall include this information in the Annual Operations Plan.

DELIVERABLES:

Annual Operations Plan

6.4. Task 4 –Support Services and Training.

Background:

All PCOLS application end users for the DoD submit their initial requests or issues through the Defense Logistics Agency’s (DLA) Level 1 Helpdesk, which is the Customer Interaction Center (CIC). Inquires not immediately responded to by the CIC, are referred to the DLA Level 2 Helpdesk. Tickets that require a DM specific response that DLA Level 2 staff cannot respond to are referred to the DM Helpdesk.

The Contractor shall expect an average referral of one DLA Level 2 help desk ticket per week. Please note that if multiple tickets are issued for a similar issue, then only one ticket will be escalated to the Contractor.

The DPAP/PDI/PCPO sponsors DM training at the annual General Service Administration (GSA) SmartPay Training Conference or equivalent, with an open lab staffed with technical expert support. Training materials are vetted by GSA approximately 90 days in advance of the conference. The DPAP/PDI/PCPO is responsible for the final review and recommended edits for the training conference content. The expanding deployed PCOLS population will require accurate, updated, timely training to assure mission success.

6.4.1 Subtask 1 – DM Helpdesk.

6.4.1.1 The Contractor shall establish and maintain a DM Helpdesk for the production support of the DM application. The Contractor shall provide support to the DLA Level 2 Helpdesk on DM application requests or issues. This support generally will exclude those issues that are related to logon or system access.

6.4.1.2 The Contractor shall record all incoming requests or issues to the DM Helpdesk in the Contractor Ticket Management System. The Contractor shall compile and distribute an Open Ticket Report to review at the weekly status Meeting. The Contractor shall be prepared to address all open issues at the weekly status meetings.

DELIVERABLES:

Open Ticket Report

6.4.2 Subtask 2 – DM Helpdesk Escalation Procedures.

The Contractor shall establish an escalation procedure in the event that support falls outside of the normal support hours or when the normal procedures are not available. The Contractor shall advise the DPAP/PDI/PCPO to ensure that these procedures are incorporated in the PCOLS Communication Plan. The Contractor shall be responsible for the review of the PCOLS Communication Plan and provide updates when and where applicable.

DELIVERABLES:

PCOLS Communication Plan Updates

6.4.3 Subtask 3 – DM Technical Assistance.

6.4.3.1 The Contractor shall provide technical assistance to the DPAP/PDI/PCPO DM Trainers on questions regarding the DM User Manual, system diagrams, and PowerPoint slide presentations for resolution. The DPAP/PDI/PCPO Data Mining Trainers shall notify the DPAP/PDI/PCPO Contracting Officer Representative (COR) in the event questions submitted to the Contractor go unresolved for more than 15 working days.

6.4.3.2 All training and training materials to include PowerPoint presentations shall be 508 Compliant to meet Federal requirements.

6.4.3.3 The Contractor shall attend relevant meetings with integration partners. The location may vary but generally the meetings are hosted in the DC Metro Area.

6.4.4 Subtask 4 – Training Support and System Documentation.

The Contractor shall create complete and accurate training material. The Contractor is not required to maintain a training staff for the purposes of DM Training. The Contractor shall provide detailed DM User Manual and system diagrams for all DM user roles. The Contractor shall provide PowerPoint slide presentations for each user role to include clear, concise information with clear legible screen prints of each screen relevant to the user for the DPAP/PDI/PCPO trainers to conduct live and webinar training sessions. The Contractor shall include more than one screen print of any individual screen to ensure the user can legibly see and understand the screen(s). The Contractor shall circle or highlight areas on the screen prints to emphasize the section(s) of the screen for the focus of the user. Highlighted areas shall not be a dark shade to diminish the user’s ability to read or view the highlighted area. The Contractor shall update the DM User Manual, system diagrams and PowerPoint slide presentations when any updates impact the user role(s). Training updates are required for the duration of the contract performance period(s). Upon Government request, the Contractor shall provide updates and edits to DM training materials to ensure updated business processes, associated functionality, and configuration is accurately reflected in the training material.

DELIVERABLES:

DM User Manual Updates

System Documentation

DM Training Material Updates

6.4.5 Subtask 5 – Training Conference Support.

The Contractor shall provide technical support for four (4) days at the annual GSA SmartPay Training Conference or equivalent. Technical support shall include assistance in the open computer lab for all role users and assisting the DPAP/PDI/PCPO DM trainers before, during and after training sessions to address questions from participants on the training content. The Contractor shall ensure that the DM User Manual, system diagrams and attendant presentation materials are provided to the DPAP/PDI/PCPO 120 days prior to the conference date. The Contractor shall perform the actions required to assist in the maintenance of conference training material; review feedback collected at the conference; incorporate relevant feedback into training material; and develop new training material content.

6.5 Task 5 – Testing and Documentation.

6.5.1 Subtask 1 – DM Application Documentation and Testing.

6.5.1.1 The Contractor shall prepare supporting documentation (e.g., briefing materials) as required to support Requests for Changes identified by the field test site users that are vetted and approved by DPAP/PDI/PCPO.

6.5.1.2 The Contractor shall support the issues resolution process by conducting analysis to resolve the issues, providing issues resolution alternatives and recommendations, and preparing supporting documentation as required.

6.5.1.3 The Contractor shall support the creation, review, completion, and update of all necessary design and system documentation, including Functional Design Specifications (FDSs), Technical Design Specifications (TDSs), and other models as appropriate based on the DPAP/PDI/PCPO requirements. This effort culminates with a comprehensive technical documentation package. The Contractor shall provide examples of each artifact well in advance of delivery of the artifact to ensure that the artifact is meeting DPAP/PDI/PCPO requirements. Upon Government request, the Contractor shall review and update artifacts with DPAP/PDI/PCPO (i.e., joint review sessions).

6.5.1.4 The Contractor shall support the DM application design efforts, taking into account previous lessons-learned from end user deficiencies and associated fixes.

6.5.1.4.1 The Contractor shall support creation and review of Functional Prototype Unit Test Cases to meet the DPAP/PDI/PCPO requirements. The Contractor shall support functional unit testing and shall document results and any deficiencies along with an associated corrective action plan.

6.5.1.4.2 The Contractor shall support creation and review of the Functional String Test Cases to meet the DPAP/PDI/PCPO requirements. The Contractor shall support the functional string testing and shall document results and any deficiencies along with an associated corrective action plan.

6.5.1.4.3 The Contractor shall support the creation and review of Functional Test plans for role based end-to-end…