Mainframe
Historical Data Migration,
Application Decommissioning,
&
Reporting
Project Plan
Revision History
Editor Review
Date Version Description Author
Draft Mainframe Historical Data migration, Application decommissioning and reporting project plan
EXECUTIVE SUMMARY ... 5
1.0 INTRODUCTION ... 7
1.1 Purpose of this document ... 7
1.2 Background Information ... 7
1.3 Project Scope and Objectives ... 7
1.4 Key Project Phases ... 8
1.5 Key Deliverables... 8
2.0 PROJECT ORGANIZATION ... 10
2.1 Project Structure ...10
2.2 Key Project Roles ...10
2.3 Project Stakeholders ...10
2.3.1 Accounting Department...11
2.3.2 Auditors and Regulators ...11
2.3.3 Legal Department ...11
3.0 PROJECT MANAGEMENT AND IMPLEMENTATION ... 12
3.1 Project Requirements and Key Tasks ...12
3.1.1 Historical data migrations of fully deployed systems ...12
3.1.2 Coordination with in-progress and future migrations and deployments ...12
3.1.3 Coordination with other data migration projects ...12
3.1.4 Coordination with other data warehouse activities ...13
3.1.5 Future archival projects ...13
3.2 Project Phases ...13
3.2.1 Legacy application usage identification and high level decommissioning strategy formulation 13 3.2.2 Resource Identification and Acquisition ...15
3.2.3 Decommissioning Implementation ...15
3.2.4 Project Closeout ...18
APPENDIX A – LEGACY HARDWARE AND SOFTWARE PLATFORMS ... 19
APPENDIX B – LEGACY APPLICATION DESCRIPTIONS ... 20
B.1 Replaced Applications ...20
B.1.1 GEAC ...20
B.1.4 CMIS ...24
B.2 Ongoing Replacements ...24
B.2.1 GOTRS ...24
B.2.2 Bus System Maintenance ...25
B.3 Scheduled Replacements...25
B.3.1 Fixed Asset System (FAF) ...25
B.3.2 OTRACS ...25
B.4 Replaced and migrated applications ...26
Executive Summary
The goal of the mainframe application decommissioning project is to retire legacy applications in a strategic manner that will ensure that relevant business data and information contained in these legacy applications that hasn’t already been migrated to other applications is not lost. The mainframe decommissioning project will focus on archival and retrieval of historical data.
Historical data of migrated applications will be identified and archived using a tiered data storage methodology that will ensure that suitable procedures are formulated to retrieve data in an efficient manner to satisfy needs of existing end users, executives, auditors, and other stakeholders for dispute resolution, research, and regulatory compliance purposes. This will reduce maintenance costs associated with upkeep of scarcely used mainframe applications and allow IT personnel to focus on current high-usage
applications. The high costs associated with maintenance and upkeep of the mainframe will also be eliminated.
A significant amount of historical data continues to reside in legacy applications that are occasionally used by few users mostly for research and dispute resolution purposes. Applications are typically retired once all the historical data has been migrated or suitably archived however the existence and usage of historical data in the legacy applications has prevented the retirement and decommissioning of these applications. Historical data from different time periods may not be consistent. This project will identify any existing inconsistencies and factor such differences into the archival and retrieval procedures. In most cases it is not enough to merely archive historical data prior to decommissioning. It is very important to ensure that the archived data can be retrieved in a timely and reliable manner in a form that reflects the business context and original use of the data to be useful to end users and stakeholders. Thus suitable retrieval mechanisms that end users feel confident about also needs to be in place to ensure that all stakeholder needs are met. Such retrieval mechanisms need to ensure that the reports and query results of archived data is reliable and accurately reflects specific business contexts especially for dispute resolution scenarios and regulatory compliance purposes.
The archiving methodology will focus on ensuring that the original business context of the archived data is retained in the archived data. Thus the archival and retrieval methodologies will examine the legacy applications to determine if business rules are reflected in the data or are coded in the application. Usually this may be a combination of both and thus the archival strategy will ensure that business contexts are sufficiently captured to make the archived data meaningful and relevant. Archived data also needs to be guarded against data corruption and referential integrity problems to ensure data reliability so these factors will also be included in the archival and retrieval mechanisms. A small project team will perform initial evaluation of the legacy applications slated for decommissioning. A questionnaire will be prepared and feedback from relevant end users
strategy. Special attention will be given to regulatory compliance requirements pertaining to data retention rules while formulating decommissioning strategies and methods.
The strategy will focus not just on the archival and retrieval of historical data in legacy applications, but will also consider ongoing data archival and retrieval requirements of existing data as they become candidates for archival in future. Thus the strategy developed will encompass enterprise-wide retention and retrieval requirements. Even though data in different legacy applications are different, a common methodology will be prepared for all data to ensure uniformity across all current and future archival needs. This will also ensure that historical data will be consolidated where possible and standard retention platforms and standard retrieval procedures will be used for all decommissioned applications. This will ensure that IT is not dependent on particular staff or consultants since a standardized approach to archival and retrieval and conforming to a single RDBMS (or archival application) will also ensure that any skilled DBA can perform archival and retrieval tasks.
The industry best practice for enhancing application performance is to initially move historical data to a data warehouse with strong reporting capabilities and then to archive the data to a more permanent storage media based on archival rules. Thus this plan will focus on a tiered data storage approach in which historical data will be initially moved using ETL (Extract Transform and Load) technology to a SAN environment and then to WORM (Write Once Read Many) storage for archival. Suitable retrieval mechanisms will also be suggested.
After determining the high level strategy resource requirements will be identified and procured in accordance with WMATA policies to implement the decommissioning strategy. Requests for information (RFI) will be sent out initially followed by Requests for Proposals (RFP) to prepare suitable requirement specifications that vendors can evaluate and respond to. Suitable evaluation criteria will be prepared to ensure the selection of the most suitable vendor. The retention strategy will be robust enough to prepare critical success criteria to evaluate vendor responses as well as to monitor
implementation of decommissioning and data retention proceedings. Major emphasis will be placed on ensuring that the data retention procedures capture the correct business contexts in which the data was originally used.
1.0 Introduction
WMATA-IT has deployed most of the functionality in its old legacy applications to several web-based state-of-the-art applications over the last few years. However a number of these applications are still not decommissioned because they are occasionally being used to look up and research historical information. Functionality in a couple of legacy applications like OTRACS that deal with employee work history and Fixed Assets have still not been deployed to other modern applications. Deployment of this
functionality is expected in the near future. Functionality in other applications like the Fare Collection and FLEETWATCH are in different deployment stages at present.
1.1 Purpose of this document
The purpose of this document is to identify the approach and key activities required to successfully decommission high cost mainframe applications in a timely manner. The Plan will also determine the data retention method that will be followed for data archival and retention of currently used applications.
1.2 Background Information
The mainframe applications were not decommissioned following their replacement by other modern applications. Only a limited amount of the historical data was converted and the legacy systems were retained for researching older historical data.
Most of the legacy applications are CICS/COBOL, CICS/COBOL/IDEAL, or CICS/IDEAL based and use VSAM or CA-DATACOM/DB data formats. The new applications are web or client-server based with Oracle as the database management system.
Data retention requirement for most applications is 7 years. Historical data retention periods vary based on type of data and retention policy.
1.3 Project Scope and Objectives
The aim of this project is to migrate critical historical data from the mainframe applications listed below to a standardized archival and retrieval system:
GEAC – contains historical accounting, budget, accounts receivable/payable, procurement information
CMIS – contains contract and cost information relevant to major Metro capital projects
GENESYS – contains HR & Payroll data that must be maintained for historical research
MARS – contains maintenance records that must be kept for seven years to support litigation
Usage of the above legacy mainframe applications will be identified and suitable steps will be taken to store needed data. Means to access such data via reports or other search tools in a timely manner will also be prepared. This will ensure that all stakeholders can access required data when needed in the original business context that the data was used in. This project will enable WMATA to achieve its goal of retiring the mainframe in the near future. Since a few ongoing and planned replacement projects are currently
scheduled or in different implementation stages, this project will exchange information with those projects to ensure consistency in managing historical data across the
Authority. The archival and retrieval of these ongoing and scheduled replacement projects is NOT in scope for this project. Similarly if necessary, this project may
coordinate with other warehousing projects to prevent potential data conflicts that could arise if the same data from different sources is loaded to a common data-warehouse. The key project objectives are:
Mainframe legacy data archival of fully migrated applications
Data retrieval in original business context
Coordination with other mainframe application functionality deployment efforts
Historical Data Archival Strategy for applications currently in production
Coordination with other data-warehousing projects
1.4 Key Project Phases
The project will consist of the following phases:
I. Identification of Mainframe application usage and high level decommissioning strategy formulation
II. Decommissioning resource requirement identification and procurement III. Data archival and retention, data access and reporting, and decommissioning
implementation
1.5 Key Deliverables
All project phases will focus on the following: • Business context of the data to be archived
• Stakeholder (end-users, auditors, and management) needs • Compliance regulations and dispute resolution requirements Key deliverables for phase I are:
1. Brief descriptions of Mainframe Applications to be decommissioned
2. Questionnaire to collect information about application usage, data volumes, etc 3. Consolidation of questionnaire responses into a high level requirements document 4. High level data archival and retention strategy for historical as well as currently
used data
Key deliverables and actions for phase II are:
1. RFI preparation, issuance, and response evaluation 2. Updated data archival and retention strategy 3. Personnel Resource requirements document 4. RFP generation
5. Vendor evaluation criteria 6. Vendor analysis and selection
7. Infrastructure, Hardware, Software, personnel seating arrangement identification and acquisition plan
Key deliverables and activities for phase III are (these could change depending on RFI responses):
1. Detailed stakeholder requirements document 2. Data mapping and transformations document 3. Data archival
4. Preparation/Implementation of Reporting and data access software 5. Test Plan
6. Signoff from all stakeholders 7. Post Implementation support 8. End user training
2.0 Project Organization
Preliminary research will be performed by a small team that will identify the key requirements, decommissioning scope, and strategies for each of the applications to be retired. Additional resources will be obtained on a temporary basis to implement decommissioning tasks.
2.1 Project Structure
Depending on data characteristics, data cleansing, data conversion and data retrieval requirements one or more sub-project teams will be obtained either internally or
externally for the duration of the project. These teams will report to the Project Manager or Project Management team who will control scope and schedule, resolve issues, coordinate with internal and external groups, report status to senior management and perform other project management and administrative tasks.
2.2 Key Project Roles
PM, Leads, SMEs – technical and functional, coordinators, implementation support staff, production support staff. (Details TBD)
Role Activities/Responsibilities IT Responsibilities • • • • • • Contractor Responsibilities • • • • • •
2.3 Project Stakeholders
Data retention compliance regulations drive archival and retrieval policies and are critical for dispute resolution and legal matters. The accounting departments are the main users affected by external entity claims pertaining to unpaid invoices. It is important to ensure that payment information that cannot be disputed is retained to ensure that funds are sufficiently protected from errors or fraud by external vendors and collection agencies. It is important for all stakeholders that the data they are using reflects the original business context of the data to be useful for research and dispute resolution purposes.
2.3.1 Accounting Department
The Accounting department users depend on reliable and accurate data for research, dispute resolution, and payment claim investigation and resolution purposes.
2.3.2 Auditors and Regulators
Reliable data is required to respond to Auditors and other regulators.
2.3.3 Legal Department
Financial and HR related information is critical for the legal department when dealing with litigation issues.
The key users of historical data are mentioned above. These and other stakeholders of legacy application data will benefit by having their data in relational databases that are sturdier and easier to use.
IT staff will be freed of performing miscellaneous tasks associated with supporting obsolete systems and can concentrate more on their regular tasks.
This project will enable WMATA to reduce significant costs associated with maintaining legacy applications. Retirement of the mainframe will also eliminate large costs
3.0 Project Management and Implementation
The goal of this project aligns with the overall strategic goal of the IT department to retire the mainframe in the near future. All relevant historical data will be identified and
suitable steps will be taken to ensure that the data is retained in a usable form to satisfy dispute resolution and research requirements so that the mainframe can be fully
decommissioned and retired in a timely manner.
This project will concentrate on historical data of mainframe legacy applications that have been fully replaced by other state-of-the-art applications. This project will also work with the other legacy application replacement project teams to ensure that historical data migration activities are consistent for all WMATA applications.
3.1 Project Requirements and Key Tasks
The major and minor requirements and tasks of this project are described in the sections below.
3.1.1 Historical data migrations of fully deployed systems
Migrate historical data from the mainframe applications listed below to relational databases and provide reporting capabilities for the migrated data based on end-user requirements:
GEAC
GENESYS
MARS
CMIS
3.1.2 Coordination with in-progress and future migrations and
deployments
Ensure uniformity in archival and retrieval procedures for historical data for ongoing and future migrations by providing knowhow and methodologies to the following application teams:
Bus System Maintenance (FLEETWATCH)
GOTRS
The mainframe Fixed Assets to PeopleSoft deployment team
The mainframe OTRACS to PeopleSoft deployment team
3.1.3 Coordination with other data migration projects
If necessary, coordinate activities with the following teams to avoid potential data conflicts and work duplication:
SQL Server warehouse to PeopleSoft EPM/COGNOS migration team
3.1.4 Coordination with other data warehouse activities
While this not a data warehousing project there will be some data warehouse related activities particularly if a tiered approach to data archival is used. WMATA has several data stores on different platforms like SQL Server and Oracle that are deemed as data warehouses by their users. PeopleSoft EPM 9.0 is the most modern warehouse application with modeling, warehousing and data mart capabilities however it is only being used for budgeting purposes as of April 2009. The mainframe retirement project will need to factor in WMATA’s overall data warehousing plans since large amounts of historical data are involved. The goal of this activity is to prevent duplication of historical data in multiple data warehouses. Thus the data migration approach should consider current developments in the data warehousing field and incorporate them into the archival and retention approach.
3.1.5 Future archival projects
Provide data archival and retention standards for data that will become candidates for archival in future in the following production systems:
PeopleSoft Financials PeopleSoft HCM PeopleSoft EPM PeopleSoft CRM Trapeze
3.2 Project Phases
The project will consist of the following phases:
I. Identification of Mainframe application usage and high level decommissioning strategy formulation
II. Decommissioning resource requirement identification and procurement III. Data archival and retention, data access and reporting, and decommissioning
implementation
3.2.1 Legacy application usage identification and high level
decommissioning strategy formulation
A high level decommissioning strategy will be prepared after identifying the needs of all stakeholders. This strategy will be updated at later stages as more details are collected during the procurement and detailed requirement gathering stages.
3.2.1.1
Mainframe Application Usage Identification
Questionnaires will be prepared in order to collect information from end users and technical staff in order to determine the application data and its usage based on the following:
o Who uses the application
o How often are the applications used o Expected response times
o Means of access
Application – obtain location, user-ids, passwords
Reports
Direct database access – obtain location, user-ids, password o Functionality/modules used
o Data used
Data volumes
Conversion requirements
Data cleansing requirements self-deprecating
Data retention requirements
Anomalies – data inconsistency, multiple lookup tables etc
Data collected from the questionnaire will be consolidated to identify end user requirements and determine the decommissioning strategy.
3.2.1.2
Analysis and Decommissioning Strategy Formulation
Analyze the above information and identify decommissioning strategies and methodologies for each of the mainframe applications.
Initial high-level research and analysis has shown that some users (GL and AP) still log into the legacy application to research historical data. Others namely the capital group users have been provided with a web application (possibly Cold fusion) that uses a SQL Server based or Access based database to research old contracts, grants, funds, accounts etc.
GL users access Fixed Asset information from legacy applications on a monthly basis indicating a significantly higher usage. Legacy data archival of this application is not in scope for this project.
Data retention regulations will be similar for most applications even though usage and access methods vary. For example most of the data will need to be retained for a period of 7 years for compliance purposes. Data pertaining to payments will mostly be required for dispute resolutions and could assume greater significance if legal resolution is needed. Another important factor to consider is that even though some of the data may have been moved to SQL Server databases some critical data may be missing. For example AP requires check numbers for dispute resolution and these are not available in the SQL Server databases, but are available in the legacy application.
Thus the legacy applications will need to be analyzed from compliance as well as end user requirement perspectives in order to formulate effective data migration and retrieval strategies. The application sizes will also need to be factored into such strategies. For example GEAC comprises of multiple financial applications most of which have been replaced, however only partially converted historical data is currently available in the
replaced application. The CMIS application on the other hand contains data limited to contracts. Thus the decommissioning strategy for GEAC will differ considerably from the CMIS decommissioning strategy. The decommissioning scope and timeframe will also be significantly larger for GEAC than for CMIS.
3.2.2 Resource Identification and Acquisition
The high level decommissioning strategy will be uniform across all applications to ensure that a common approach is used for all existing and future data archival needs. An initial decommissioning strategy will be prepared based on the mainframe usage information gathered from the questionnaires. Requests for Information (RFIs) will then be issued to potential vendors to obtain additional information that will be factored into the
decommissioning strategy.
High level plans will be sought in the RFIs issued. Responses expected will probably mention methodologies and tools. Vendors are expected to have expertise with the tools as well as with the methodologies. Thus the implementation team will consist of
WMATA employees as well as external consultants. Detailed personnel requirements for the project will be compiled. Resources that are available internally will be identified and Requests for Proposals (RFPs) will be prepared to meet additional resource needs based on the following:
Personnel (internal and external) Resource Requirements
Personnel Resource acquisition plan
Data migration scope
Costs (if necessary)
Data migration schedule
Project monitoring and control criteria
Critical Success Factors
Infrastructure, Hardware, Software, Personnel seating and other requirements along with procurement lead times
Project closeout tasks
3.2.3 Decommissioning Implementation
A high level implementation schedule that factors in ongoing and future application replacement projects will be prepared initially. The schedule, resource requirements and high level strategy may be modified based on the RFI and RFP responses. The project scope and schedule start and end dates will be frozen after the contract is awarded and all contractual negotiations and details are finalized. Details mentioned in section ‘3.2.2 – Resource Identification and Acquisition’ will be finalized and lead times for any
software, hardware, and seating requirements will be factored into the schedule to avoid downtimes. Implementation tasks may be reordered if necessary to account for any unavoidable glitches.
3.2.3.1
Implementation kickoff
The implementation teams will be introduced to the key stakeholders to formally start the implementation phase. The implementation teams will be given a week to perform
preliminary investigations and prepare a finalized schedule.
3.2.3.2
Initial Activities
Tasks that are not on the Critical Path are expected to be performed in parallel where possible. Initial technical installation and setup tasks are to be performed along with WMATA technical staff and knowledge transfer should be performed as necessary. These tasks can be done simultaneously with finalizing requirement details and other non technical tasks.
3.2.3.3
Data Mapping and Conversion analysis
Important: Reporting and usage needs of all stakeholders will drive data conversion and archival activities.
Data mapping tasks will need to be coordinated with WMATA functional and technical SMEs (Subject Matter Experts) to ensure that the converted data reflects the original business context and use of the historical data. A tool that is able to read COBOL copybooks (or other data definitions) may reduce data mapping time, however SMEs may be needed to explain business rules pertaining to the data.
Data cleansing issues, particularly those pertaining to data differences resulting from different time frames will need to be identified and solutions to overcome these need to be prepared.
Detailed documentation of data mapping, data cleansing, conversions and data transformations will be expected at this time to facilitate data dictionary preparation.
3.2.3.4
Data Cleansing and Conversion
Data cleansing and conversion activities will focus on ensuring that the original business context of the legacy data is reflected in the archived data. A tiered approach that uses an intermediate reporting unit will probably be used in the archival architecture, therefore data mapping and reporting will be done in this component which will also probably be the central unit of all conversion activities.
Data cleansing will be required if all historical data is consolidated or converted to a common format. Data cleansing will be done only if the original business context of the data is retained else a suitable alternate method will be used to ensure original business use.
Data dictionaries will also be prepared at this time. All metadata definitions need to be included in the data dictionary.
3.2.3.5
Data Archival
Assuming that a tiered data archival approach is used, data will be archived to permanent secondary storage from an intermediate reporting unit. Data that is moved to permanent storage will be purged based on a purging rule after it is archived.
Data retrieval procedures will restore data from secondary storage to the reporting unit to satisfy user requests for archived data.
Data archival will be performed using the following two steps:
1. Sample data reflecting all major conversions and transformations will be extracted and converted. Reports will be generated against this data and reviewed by SMEs and end users. Data retrieval from permanent storage will also be tested. Steps will be taken to rectify issues in a cyclical manner till all issues are resolved. 2. Data archival and retrieval activities will be performed for the full data set. Steps
will be taken to rectify issues as needed.
3.2.3.6
Production Environment Planning
Data volumes are expected to significant so sufficient attention should be paid to database sizing and other performance related parameters. Parameters pertaining to network performance will also need to be factored in. Stress and volume testing should also be performed to identify performance thresholds.
Performance metrics should be identified and matched against full scale usage. A risk management plan that identifies potential problems and suitable mitigation strategies and contingency plans should also be prepared to ensure smooth operation in production.
3.2.3.7
Testing and User Signoff
Testing will be performed by all stakeholders. Test cases and test plans will be prepared to cover different scenarios seen in the past. Test cases for anticipated scenarios will also be prepared and tested.
Suitable regression steps will be implemented to ensure that failed tests go through the appropriate life cycle stages.
All stakeholders will be required to sign off on the tests. Test results and user signoff documents will be stored in a suitable manner for future reference.
3.2.3.8
End User training
End users will be trained to try and minimize the need for assistance from the technical staff. Sufficient end user documentation will be prepared to the satisfaction of all end users.
documentation and procedure documents are prepared to ensure that WMATA technical staff can support data archival and retrieval of archived data. WMATA technical staff should also be trained to perform ongoing data archival and retrieval tasks for current data as they become candidates for data archival in future.
3.2.4 Project Closeout
Ensure all relevant documentation is completed. Hand over operations of the production system to WMATA technical staff over a 2-week period. Determine production support requirements and plan. Decommission mainframe after a period of parallel operation.
Appendix A – Legacy Hardware and Software platforms
Hardware: IBM Z890
MVS version: Z/OS 01.03.00 CICS version: CICS TS 1.3
COBOL version: VS COBOL II 1.4.0 IDEAL version: CA-IDEAL V2.2
Datacom version: CA-Datacom/DB V10.0 SP03
Appendix B – Legacy Application Descriptions
B.1 Replaced Applications
The following applications have already been replaced by other applications and are currently being used only to lookup historical data.
B.1.1
GEAC
GEAC is a mainframe system that encompasses GL, AP, AR, Billing/Order Processing, Purchasing, Budgetary Control, Common Components, Financial Controller and Data Communication Interface.
• Key software used: – CICS/COBOL • Mainframe data format:
– VSAM • Status:
– Replaced by PeopleSoft
– Historical data needs to be migrated
– Limited portions of data were migrated to PeopleSoft
B.1.1.1
GEAC General Ledger (GL)
The General Ledger and Budget module was used for planning, budget execution and to monitor and control financial resources. The key reports it produced are:
1. GL Journals
2. Income and Expenses 3. Trial balances
4. Transaction Account Analysis 5. Budget
6. Budget Variance
7. Consolidation and Consolidating data
GEAC General Ledger’s online capabilities were used to: 1. Inquire against actual and historical balances 2. Budgets
3. Allocated amounts
4. Reporting out of balance conditions 5. Maintain chart of accounts
B.1.1.2
GEAC Accounts Payable (AP)
The AP module was used for payables process from recording invoices to reconciling payments. It was used to collect information about banks, trade vendors and employees, and the accounting policies that were used to process documents. GEAC AP was used to:
1. Record Invoices 2. Employee Advances 3. Expenses
4. Credit and Debit memos
5. Automatically generate Payments
6. Accumulate amounts for end of year processing and 7. Prepare 1099 statement
B.1.1.3
GEAC Purchasing
GEAC Purchasing was used for: 1. Requisition processing 2. PO processing
3. Receipt processing 4. Invoice matching
The Purchasing and AP modules shared policy, vendor and item files that were
maintained in an integrated system. Purchase Orders were matched against AP invoices.
B.1.1.4
GEAC Financial Controller System
This is the integration component of the GEAC system. It integrates AP, Purchasing and GL.
B.1.1.5
Information Expert
This is GEAC’s information retrieval tool.
B.1.1.6
GEAC Accounts Receivable (AR)
GEAC Accounts Receivable was used to:
1. Record and maintain all contract bus service orders 2. Debit/Credit cash transactions
3. Receivable invoice transactions and 4. Mailing descriptions of each customer 5. Post weekly receivable transactions to GL
6. Furnish summary age of balance for outstanding accounts and 7. Produce monthly reports
B.1.1.7
GEAC Order Processing
GEAC Order Processing handled flow of order information for billing purposes and automatically invoice customers.
B.1.1.8
GEAC Interfaces
Prior to being replaced by PeopleSoft GEAC had interfaces with the following many of which have also been replaced by PeopleSoft.
• GEAC received budget information for the Operating Budget System (OBS). • OBS then sent budget information to COGNOS
• Invoice information came from Cost Management Information System (CMIS) and Cost Management Information System (CMIS)
• GEAC received vendor information from the Vendor Registration System (VRS). • GEAC received investment portfolio information from the Investment Portfolio
Management System (APS).
• GEAC received labor information for an in-house labor distribution system. • GEAC sent out files to CMIS and Procurement Information Management System
(PIMS) for aid in account/center validations.
• GEAC sent out payment information to PIMS and CMIS, thereafter, AP utilized electronic and paper version of payment.
• GEAC received PO accrual information from PIMS & MMS. GEAC fed
information to the data warehouse (COGNOS & INFORMATICA) for Web based reporting.
• GEAC was used to feed data to the Labor Reimbursement/CIP application. • GEAC fed vendor information to CMIS & MMS
B.1.2
GENESYS
GENESYS was a Payroll/Personnel system that was used primarily to generate and maintain personnel information for the WMATA workforce. The system was used to:
1. Calculate employee a. Regular pay
b. Other earnings like overtime, taxable and non-taxable allowances, imputed income from employer supplied life insurance, etc
c. Deductions like federal, state and local taxes, health insurance premiums, union dues, credit union deductions, etc
2. Generate reports for internal purposes and external users like a. Federal Reserve Bank for US Savings Bonds
c. Aetna Insurance for Life and Health Insurance d. First Union Bank for Direct Deposit
• Key software used: – CICS/COBOL • Mainframe data format:
– VSAM • Status:
– Replaced by PeopleSoft
– Historical data needs to be migrated
B.1.3
MARS
The Maintenance and Reliability System (MARS) main purpose is to: 1. Assist WMATA’s planning, scheduling and controlling of:
a. Rail cars b. Buses
c. Physical plant and structures d. Elevators and
e. Escalator maintenance operations
2. It is also used to support the enforcement of warranty terms and management of warranty fulfillment of assets related to buses, rail cars, and their components 3. MARS maintains detailed description of assets such as:
a. Buses b. Rail cars c. Stations d. Elevators e. Escalators
4. MARS maintains the actual and required configurations of all the above mentioned assets
5. It also detailed failures and repair history of serialized parts
6. Data about non-serialized parts are maintained in a limited and less resource intensive manner
7. The historical information in MARS is used to produce a wide variety of maintenance statistics along with detailed chronological histories
• Key software used:
– COBOL/CICS/Datacom • Status:
B.1.4
CMIS
Cost Management Information System (CMIS) – CMIS is an integrated cost management system, which captures funding, contract and cost information for all capital programs. Through its ‘work-breakdown’ structure, a very large capital program can be broken down into manageable units. CMIS was used to handle capital payments. CMIS consisted of 10 major subsystems, each of which was designed to capture data for related activities. For instance actions required to appraise, acquire, relocate, and manage real estate were captured in its Real Estate subsystem. Actions included in developing and preparing a program for approval were included in its Budgeting subsystem and the processing of Grant Applications and identification of specific grant/line items to fund individual elements were included in the Funding subsystem.
• Key software used: – CICS/COBOL • Mainframe data format: – CA-Datacom/DB • Status:
– Replaced by PeopleSoft
– Legacy data has been migrated to an Oracle database; No canned reports; Data retrieved by a SQL programmer as needed.
Only coordination with the replacement teams is required for these applications.
B.2 Ongoing Replacements
The following applications are currently in different stages of being replaced by other applications.
B.2.1 GOTRS
The General Order Track Rights (GOTRS) application has been developed in-house by WMATA staff. It processes over 900 work requests each week for access to the
WMATA right of way. The GOTRS system:
1. Supports RAIL’s Track Rights Bidding Process that: a. Generates general orders
b. Switching orders and c. Associated conflict reports 2. And handles
a. Requests for track rights b. Power outages
c. Escort services and
• Key software used:
– IDEAL/CICS/Datacom • Status:
– Replacement contract awarded
– New System is being developed and is fully funded
B.2.2 Bus System Maintenance
Bus mileage, oil and fluid management • Developed in House
• Key software used:
– CICS/IDEAL/Datacom • Status:
– Replaced by Fleetwatch – Fluid management system
B.3 Scheduled Replacements
The following applications are scheduled to be replaced in the near future.
B.3.1 Fixed Asset System (FAF)
FAF is an in-house developed asset management system that records and maintains all WMATA’s property assets. It is used to:
1. Support the physical inventory of all WMATA property assets every two years 2. Maintain a detailed description and location of each asset
3. Compute depreciation for each asset
4. Post the following entries to the General Ledger: a. Asset acquisition entries
b. Asset depreciation entries and c. Asset retirement entries
5. Furnish detailed schedule of rehabilitated and replacement assets and 6. Compute future replacement costs of assets
• Key software used:
– COBOL/IDEAL/Datacom • Status:
– In use (to be replaced by the PeopleSoft Asset Management Module) – Historical data needs to be migrated
B.3.2 OTRACS
1. Employee attendance including information regarding: a. Scheduled and unscheduled absences and b. Points associated with such absences 2. Violation information regarding:
a. Complaints against bus/rail employees received by the Office of Communications and station overruns and
b. Disciplinary actions c. Other complaints
3. OTRACS also records commendations received by employees
4. OTRACS integrates data from the payroll/personnel database with data entered by:
a. Training
b. Quality Assurance and c. Bus/Rail Operations
5. OTRACS has many forms to obtain a. Employee historical reports and b. Divisional absenteeism reports
6. Management uses current and historical OTRACS data to: a. Evaluate the performance of an employee or a division
b. Determine an employee’s qualifications and performance for awards and promotions
7. OTRACS data is electronically verified by bus and rail managers to insure the accuracy of records
• Key software used:
– COBOL/IDEAL/Datacom • Status:
– System currently being used by Operations
B.4 Replaced and migrated applications
The following application has been fully deployed and migrated.
B.4.1 Crime Index
Crime Index is the MTPD crime record management system and was used to assist the Transit Police in recording and maintaining all reportable activities occurring on WMATA property. These include:
1. Criminal offense information pertaining to: a. Personal injuries
b. Lost property and c. Other offences
2. The system furnishes the following information: a. Detailed crime statistical reports
b. Categorized crime analysis
c. Reported incidents by location and d. Manpower assignment
3. Reports are distributed to jurisdictional police departments and are incorporated into the FBI’s Incident Reporting System
• Key software used:
– COBOL/CICS/Datacom • Status:
– Replaced by CAD / RMS
– New system has been implemented
– Data migration is completed, ready for decommission once the final FBI reporting has been approved
