## EXECUTIVE SUMMARY

In June 1997, the Federal Communications Commission (FCC) Office of
Inspector General (OIG) established a task order with TWM Associates,
Inc. to conduct a special review of the Commission's Collection System.
The objective of this review was to examine the current operational
system, examine on-going modifications, and recommend alternative
products. To accomplish these objectives, the review team conducted
interviews with Commission and contract support staff; evaluated
Collection System documentation and computer code; conducted research on
alternative software solutions; and conducted a benchmarking effort of
other government agencies.

During our assessment of the current Collection System, the review team
made one-hundred twenty-eight (128) observations in the areas of:
internal controls; audit trails; programming support; database support;
security; banking related matters; business process improvements;
policies and procedures, and systems development lifecycle issues. Of
the one hundred twenty-eight (128) observations, forty-six (46) are
considered high and medium exposure items that should be addressed
immediately. Significant high exposure observations are as follows:

-   As part of a data quality review initiated by the Wireless
    Telecommunications Bureau (WTB), the collection database was loaded
    with data from a paradox file containing modified data elements.
    This upload was performed without a proper audit trail, including
    evidence supporting individual changes, the deletion of individual
    transactions, and changes made to original source documents.

-   The collections system does not have functionality to allow for an
    audit trail when changes (including data element changes,
    insertions, and deletions) are made to the database. An audit trail
    is a core requirement of any financial accounting system.

-   The collection system does not record and track all
    collection-related transactions. Although some collection
    transaction information has been provided to contractor support
    personnel for loading into the collection database, at the time this
    review was completed, this information load had not yet been
    performed.

-   The Commission has not established separate operating environments
    for system development/maintenance work and production. In addition,
    contract support staff responsible for system enhancements and
    maintenance are also responsible for system operation.

In addition, the review team identified high exposure observations
related to systems development and systems security issues. A detailed
description of all one hundred twenty-eight (128) observations with
accompanying recommendations is included in Section E of this report.

During early discussions with management from the Wireless
Telecommunications Bureau (WTB) and the Office of Managing Director
(OMD), the OIG became aware of discussions about a parallel collection
system review effort being considered by these organizations. After
review of the proposed project, the OIG agreed to establish an
additional task under their existing task order with TWM. The objective
of the additional task was to assess the integrity of the data contained
in the Collection System for completeness, validity, accuracy, and
proper recording. To conduct this portion of the review, the OIG worked
with WTB and OMD staff to develop an appropriate statement of work to
conduct an \"Agreed Upon Procedures\" review. The OIG then requested
that TWM solicit bids from \"Big Six\" accounting firms to establish a
subcontract with TWM to perform the procedures. After discussion with
FCC management, Ernst & Young, L.L.P. (hereafter referred to as \"E&Y\")
was selected to complete the work.

On April 24, 1998, E&Y issued a report, entitled \"Collection System
Agreed Upon Procedures Report,\" summarizing the results of their
review. In this report, E&Y identified a multitude of data quality
issues within the Collection Database. Of the one thousand six-hundred
ninety-five (1695) transactions selected for review, E&Y identified the
following conditions:

-   Source documents were not provided for fifty-two (52) of the
    selected transactions.

-   Data contained in the collections database differed from source
    documents for seven-hundred eleven (711) items representing
    forty-two percent (711/1695 = 42%) of selected transactions.

-   Of the seven-hundred eleven (711) transactions, thirty-three (33)
    transactions, with a total dollar value of approximately \$39
    million, related to discrepancies in monetary amounts or instances
    where no check or wire slip could be located to substantiate the
    transaction. Of these, only one was an auction-related transaction.

Although E&Y successfully completed the engagement, the review team
experienced significant difficulties. The process of tying supporting
documents to data elements in the collections database proved to be time
consuming as extra analysis was required to determine how to tie the
items together. The results of the E&Y data integrity review are
discussed in summary in Section F of this document and the detailed
report is included as Appendix A. As part of the review process, E&Y
requested that FCC management prepare a representation memorandum for
the data integrity portion of the review. In this document, FCC
management made representations regarding the integrity of data in the
collection system, the conduct of the review, the condition of internal
controls, and compliance with laws and regulations. A copy of the
representation letter is included as Appendix B of this report.

On December 31, 1997, Chairman Kennard forwarded the FY 1997 Federal
Managers\' Financial Integrity Act (FMFIA) Annual Report for the Federal
Communications Commission to President Clinton. In the cover memorandum
forwarding that report, the Chairman recognized a material weakness and
material non-conformance dealing with the \"integration of the
Commission\'s billings and collections system with the central
accounting system.\" The Chairman went on to state that \"(b)ecause of
the material non-conformance of our automated system, we must rely more
on manual than automated processes\" but that \"we do not have evidence
at this time to believe that the [actual]{.underline} management
integrity of the Commission is materially weakened by reliance on manual
processing.\" It should be noted that the scope of this review [did
not]{.underline} included an assessment of the manual controls
associated with the Commission\'s collection process and that we are
not, therefore, expressing an opinion on the adequacy of those controls.
A copy of the cover memorandum is included as Appendix E in this report.

The Commission\'s Collection System is a financial application. As a
financial application, it should adhere to strong internal controls,
security controls, and management controls in accordance with OMB
circulars and FCC Security Directives. The one hundred twenty-eight
(128) observations and recommendations contained in this report would
indicate the Collection System is not in compliance with OMB, or the FCC
Security Directives. The Collection System as it exists at the time of
this review, does not evidence all payment transactions, does not
provide clear audit trails for changes made to payment transactions,
does not provide for an adequate level of logical internal controls,
does not reconcile to the General Ledger, and supports less than thirty
percent (30%) of desired functionality.

Our review further revealed that it would be cost prohibitive to bring
the current in-house developed Collection System to an acceptable level
of functionality in compliance with OMB and FCC Security Directives.
Therefore, it is our opinion that it is in the best interest of the
Commission that a COTS product should be evaluated, selected, and
implemented. The existing Collection System should be minimally
maintained during the period the COTS product is evaluated, selected,
and implemented. Once the COTS product is implemented, the existing
Collection System should be phased out.

On June 9, 1998, the OIG issued a draft report summarizing the results
of this review. On September 8, 1998, the OMD and WTB issued a joint
response to the draft report. In their response, they indicated
concurrence with one hundred twenty-six (126) and non-concurrence with
two (2) of the one hundred twenty-eight (128) observations and
recommendations. In addition, the response indicated concurrence with
the data integrity portion of the review conducted by E&Y and summarized
in Section F of this report. We have incorporated each OMD/WTB response
by observation into the body of this report. In those cases where it was
appropriate, we have provided comments to the OMD/WTB response. In
addition, we have attached a complete copy of the response as Appendix C
to the report.

**ACKNOWLEDGMENT**

The Review team acknowledges the contributions of all that were involved
with the Special Review of the Collection System. Their efforts were
highly professional and contributed to the successful completion of this
effort.

**NAME** **ORGANIZATION/COMPANY**

Mr. Tom Holleran FCC, FOD

Ms. Linda King Friedman FCC, FOD

Ms. Regina Dorsey FCC, BCB

Mr. Linwood Jenkins FCC, BCB

Mr. John Bopp FCC, Wireless

Mr. Andy Cox FCC, Wireless/OMD

Ms. Rachel Kazan FCC, Wireless

Mr. Bob Snow FCC, OMD ITC

Ms. Robbie Burroughs Computech, Inc.

Ms. Cathy Ganneck Computech, Inc.

Mr. Sam Orlando Computech, Inc.

TABLE OF CONTENTS

EXECUTIVE SUMMARY 1

ACKNOWLEDGMENT 5

A. CONCEPT OF OPERATIONS 7

1\. Introduction 7

2\. Systemic Functions 8

3\. Site Location 8

B. PURPOSE OF THE SPECIAL REVIEW 8

C. REVIEW TEAM 8

D. SPECIAL REVIEW APPROACH 9

1\. Phase I Collection System Evaluation 9

2\. Phase II Data Integrity Review 14

E. DETAILED RECOMMENDATIONS PHASE I 15

F. DETAILED RECOMMENDATIONS PHASE II 65

G. OVERALL CONCLUSIONS 66

> **Appendix A:** Ernst & Young L.L.P. Report entitled \"Collection
> System Agreed Upon Procedures Report,\" dated April 24, 1998
>
> **Appendix B:** Representation Letter from FCC Management to Ernst &
> Young L.L.P.
>
> **Appendix C:** Memorandum, dated September 8, 1998, from the Managing
> Director and Chief, Wireless Telecommunications Bureau entitled
> \"Responses to the Draft Special Review Report No. 97-21\"
>
> **Appendix D:** Selected Citations from Office of Management and
> Budget (OMB) Circulars and FCC Policies

######### Appendix E: Memorandum, dated December 31, 1997, from Chairman Kennard to President Clinton forwarding the FY 1997 FMFIA Annual Report for the Federal Communications Commission

**A. CONCEPT OF OPERATIONS**

The FCC was originally established by the Communications Act of 1934. In
February 1996, President Clinton signed into law the Telecommunications
Act of 1996 that contained the first major overhaul of the
telecommunications rules and regulations in over 60 years. The FCC is an
independent United States government agency, directly responsible to
Congress. The primary mission of the FCC is to promote competition among
the five lanes of the information super highway: broadcast, cable, wire,
wireless, and satellite. The FCC has Bureaus that represent each lane,
plus the Compliance and Information Bureau.

The Commission\'s Collection System began as a tracking system on a
Honeywell mainframe. The purpose of the system was to keep record of
application and regulatory fees paid into Commission bank accounts. The
manual processing that kept records of the regulatory fee payments was
converted into computer processes to keep records of the regulatory
fees. The Commission personnel were familiar with the mainframe
technology, the manual processes, and were successful in converting
those manual processes into computer processes.

On August 10, 1993, the Omnibus Budget Reconciliation Act of 1993 was
amended to add a new section 309(j) to the Communications Act of 1934.
This amendment gave the FCC express authority to employ competitive
bidding procedures to distribute licenses for spectrum services. In
order to track the payments as a result of winning bids, the FCC had to
develop systems to support the auction process. The FCC established a
reimbursable agreement with the Department of Justice (DOJ). Under this
agreement, the FCC contracted with DynCorp to modify the existing
collection system and convert from a mainframe to a client-server
operating environment. After much disappointment, the FCC then moved to
contract with Computech to build the Collection System. Since 1994, well
over \$4 million dollars have been spent on the development of the
Collection System.

1\. Introduction

a\. Purpose. The purpose of this special review was to assess the
existing and planned abilities of the Collection System to meet FCC
requirements and recommend alternate commercial-off-the-shelf (COTS)
solutions. The review was intended to be a quick study of the Collection
System to quickly provide feedback on areas where improvements can be
made.

b\. Requirements: The criteria used for this review were Office of
Management and Budget (OMB) Circulars and Commission policies. These
criteria included:

> Office of Management and Budget (OMB) Circular A-130, entitled
> \"Management of Federal Information Resources,\" as revised February
> 8, 1996.
>
> Office of Management and Budget (OMB) Circular A-123, entitled
> \"Management Accountability and Control,\" as revised June 21, 1995.
>
> Office of Management and Budget (OMB) Circular A-127, entitled
> \"Financial Management Systems,\" as revised July 23, 1993.
>
> Federal Communications Commission (FCC) Directive FCCINST 1479.1,
> entitled \"FCC Computer Security Program,\" dated November 30, 1995.

2\. Systemic Functions

The FCC\'s Collection System was the specific application focused on
during this special review.

3\. Site Location

Work on this special review was conducted primarily at the FCC's
headquarters facility located at 1919 M Street in Washington, D.C. For
the purpose of understanding the full collection cycle, interviews were
also held with fee collection personnel in Gettysburg, Pennsylvania and
with Mellon Bank staff in Pittsburgh, Pennsylvania.

> **B. PURPOSE OF THE SPECIAL REVIEW**

The purpose of the special review was to examine the current operational
collection system and assess its ability to meet requirements; assess on
going and planned system development/modification efforts and determine
their effect on system performance following implementation; and develop
recommended system performance solutions including
identification/assessment of commercially available products. In
addition, following discussions with FCC management, the review was
modified to include an assessment of the integrity of data contained
within the Collection System to ascertain whether recorded transactions
are complete, valid, accurate, properly classified, properly recorded,
and recorded in a timely fashion. The scope of this special review did
not extend to security, either physical or logical, outside of the
Collection System. Those are separate reviews to be conducted at another
time, outside the scope of this review.

> **C. REVIEW TEAM**

The Review Team included representatives from the FCC Office of
Inspector General (OIG) and TWM Associates, Inc. The following is a list
of individuals who participated in the review.

> Thomas Bennett, FCC, OIG Team Member
>
> Paul Brachfeld, FCC, OIG Team Member
>
> Thomas Housman, TWM Associates, Inc. Team Member
>
> Keith Meins, TWM Associates, Inc. Team Member
>
> Sanjay Shantaram, TWM Associates, Inc. Team Member
>
> Thomas Welch, TWM Associates, Inc. Team Member
>
> Bruce Wilkins, TWM Associates, Inc. Team Member
>
> Lisa Wilkins, TWM Associates, Inc. Team Member
>
> Nicole Williams, TWM Associates, Inc. Team Member
>
> **D. SPECIAL REVIEW APPROACH**

The Special Review Approach was based on a two-phased approach. Phase I
was the evaluation of the Collection System. Phase II was the data
integrity review performed by E&Y.

1\. Phase I Collection System Evaluation

The following provides an outline of the procedures performed in order
to accomplish the objectives of Phase I of the Collection System Review.
OMB and FCC guidance were used to assess the Collection System and to
develop observations and recommendations. The procedures performed
included a look at the Collection System Cycle, review of program coding
(shell scripts, stored procedures, etc.), review of the data elements,
review of program documents (i.e., contractor support Statement of Work,
Quality Assurance plans, Project plans, etc.), review of Sybase security
and other pertinent procedures.

######### OMB Circular Guidance

OMB Circulars A-123, A-127, and A-130 provide guidance to Federal
agencies as to how financial applications should be developed,
implemented, and maintained. Essentially, these Circulars establish that
development of financial applications should include: Effective internal
controls, proper System Development Life Cycle (SDLC) methodologies and
cost/benefit analysis, movement towards COTS, and maintenance of
adequate audit trails and transactional records to support the general
ledger. Several specific OMB Circular citations were used as guidance in
developing the detailed observations and recommendations during the
evaluation of the Collection System. The specific citations are included
in Appendix D. The detailed recommendations refer to OMB Guidance as a
whole and are not tied to specific citations. The OMB citations are
included in the appendix for ease of reference.

######### Procedures Performed

[Cycle vs. System.]{.underline} It became evident early in the review
that not all users of the Collection System viewed the application in
the same manner. Most users and personnel interviewed viewed the
application as just a tracking mechanism. Others viewed the system as a
financial application. Through our discussions it became apparent that
the Collection System entailed more than just a tracking mechanism and
was actually supposed to be a part of a larger Collection Cycle vs. a
Collection System. The Collection Cycle consists of: gathering banking
information, application of banking transactions at both the accounting
sub-ledgers and general ledgers, collection on past due payments,
analysis of collection activities, bank account transaction recording in
the general ledger, reconciliation of general ledger accounts to bank
statements, and reconciliation of accounts receivable sub-ledger to the
general ledger accounts.

[Shell Scripts.]{.underline} Powerbuilder scripts, SQL, and C Programs
Review. Shells Scripts, SQL, Powerbuilder scripts, and C Programs are
used in conjunction with the Sybase Stored Procedures to schedule batch
jobs and perform other programming needs. The scripts and programs were
reviewed to determine completeness, standardization, and programming
quality.

[Stored Procedures.]{.underline} The Collection System is built using
Sybase System 11. Sybase System 11 uses Stored Procedures that allow for
business or application processing logic to be placed within Sybase and
be executed on the main computer. The stored procedures were reviewed to
identify and evaluate the programming standards used and the quality of
programming contained within the stored procedures.

[Log files.]{.underline} Logs within the Collection System environment
are used to keep records of programs that are started, completed, and
errors that occur during the process. Logs are only written to if the
program has been programmed to do so. The log files were reviewed to
determine if there was any indication of problems, significant amounts
of stops and restarts, and potential error trending.

[Data Elements.]{.underline} Data dictionaries contain the definitions
of all the data elements used in the database. Data dictionaries usually
contain a description of the field, the format of the field, and the
date last altered. The Data Dictionary was reviewed on line for complete
data elements, professional language describing the data elements, and
for completeness in the descriptions.

[Database Entities.]{.underline} Data entities contain the definitions
of all the data elements used in a given table or entity. Data entity
relationships usually contain a description of the entity, the fields
included in the entity, the primary key or field, and the date last
altered. The Data Entities were reviewed on line for complete
descriptions, professional language, and for normalization.

[Events Lists.]{.underline} Library Lists, and Database Fill. The Events
List is used as a basis for determining the modules to be created for
the application. The Events List was reviewed to determine the
automation of manual processes and inclusion of user requirements and
functionality. The Library List is the list of all production source
code for the Collection System. The Library List was reviewed to
determine extent of standard naming conventions and security access.
Data Fill consists of the placing of spaces or zeroes into a data record
for further input into the database at a later point in time. The Data
Fills were reviewed to determine the extent of use of such items.

[Narrative Descriptions.]{.underline} The developers of the Collection
System prepare narrative Descriptions. The Narratives describe the steps
and procedures utilized by various user groups to assist them in the
completion of the transactions. The Narratives were reviewed to
determine the completeness and the logical flow of the narratives made
sense to an unfamiliar user.

[User Manual.]{.underline} The user manual is usually indicative of how
the user maneuvers through an application. The Team performed a cursory
review of the User Manual to gain an understanding of the programmed
application from a user perspective.

[Project Plans and Status Updates.]{.underline} Project plans are
typically documents used to indicate the overall objective of the
project, define the project maintainability, use of security,
expandability, etc. Interviews were conducted and documents were
gathered and evaluated for completeness of content with respect to a
project plan. Status Reports are typically documents used to indicate
the individual tasks being worked on by the development team and agreed
to by the users for whom the development effort is being performed.
Status reports typically include a list of action items, who is
responsible for those items, the length of time for completing the
items, and a source or mapping to user requirements for items being
worked on. Status reports are usually the result of status meetings,
which are held on a periodic basis. These were reviewed to determine
completeness of content.

[Security.]{.underline} To review the security over the Collection
System application, several areas were considered. The first was the use
of the C or Unix scripts. Second, Sybase access control was reviewed.
Third, Collection System application tables access was reviewed. Fourth,
Sybase Stored Procedures (i.e., programs) were reviewed. There were no
reviews performed over the operating system security or manual controls
over spreadsheet applications or PCs.

[User Meetings.]{.underline} Meetings were held with various key
personnel involved in the historical development of the Collection
System or actively involved in the on-going development or operations of
the Collection System. The purpose of these meetings was to ascertain
the development environment, potential functional requirements, and to
develop an understanding of the development process used historically
and in the present time. Users were considered to be those in
development, database maintenance, Financial Operations Division (FOD),
Billing and Collections Branch (BCB), Wireless, Information Technology
Center (ITC), and Acquisitions.

[Bureau and Office Meetings.]{.underline} Meetings were held with other
Bureaus and Offices within the Commission who use the Collection System.
The purpose of these meetings was to ascertain the potential functional
requirements, and to develop an understanding of how the department
makes use of the information contained in the Collection System. Bureaus
and Offices included Gettysburg Fee Processing, International, Common
Carrier, and the Office of Engineering and Technology.

[Bank and Lockbox Processing.]{.underline} FCC primarily uses Mellon
Bank to receive its monies collected in terms of dollars. First Chicago
Bank is also used to collect monies, primarily for the Fines &
Forfeitures. Mellon Bank transmits banking information in an AFCC
specific layout on a daily basis and then overnights the payments
processed in hardcopy to the FCC. First Chicago does not transmit
electronically, but overnights the payments processed in hardcopy to the
FCC. Bank processing procedures were discussed with FCC personnel and
with Mellon Bank representatives. The Mellon Bank lockbox operations and
file layouts for bank transmission of bank account activity to FCC were
reviewed. Pricing information and procedures were compared to other
banks providing lockbox processing.

[Steering Committee.]{.underline} As part of the Collection System
Review, FCC Management requested that the OIG chair a Collection Systems
Steering Committee comprised of representatives from the Financial
Operations Division (FOD), the Auctions Division of the Wireless
Telecommunications Bureau (WTB), and the Information Technology Center
(ITC). In addition, the Contracting Officers Technical Representative
(COTR) for the existing collection systems development and maintenance
task orders was invited to participate in steering committee meetings.
The Steering Committee was established in August 1997. The Steering
Committee: prepared a mission statement which was reviewed and approved
by FCC Management; provided the working traits expected for personnel
working on the Collection System; prepared the Statement of Work for the
Big Six Data Integrity Review; recommended to FCC management the
selection of the Big Six firm; and assisted in Collection System Review
status presentations to FCC management. In addition, the Steering
Committee kept abreast of the status of the Data Integrity Review by E&Y
and reviewed the functionality requirements prepared as part of the
Collection System Review. The Steering Committee also prepared the
Position Description for the Project Manager to be hired for the
Collection System migration to COTS.

[Functional Requirements Analysis.]{.underline} The approach was to
establish a generic model (which could be used in any environment) and
then incorporate the FCC specific requirements into the model. This was
a preliminary review since, presumably, the incoming Project Manager
will perform a full functional requirement analysis. Interviews with
users and documentation they provided were used as the basis for the FCC
requirements or desired functions. Documentation was then obtained for
selected COTS packages. From the FCC requirements and COTS
documentation, the functionality matrix was built and indicated a 1 if
the function was present in the software (COTS or existing Collection
System) or a 0 if the function was not present in the software. Once the
model was established, the model was reviewed with the members of the
Steering Committee. Weighting of the functional requirements was based
on deemed importance to the users of the Collection System, which was
reviewed with Steering Committee members and adjusted accordingly. The
model was then used to compare the COTS packages to the existing
Collection System for percentage of functionality incorporated in the
packages.

[Benchmarking.]{.underline} In order to determine the trend of
accounting software application development within the government agency
environment, it was deemed necessary to talk with other government
agencies. The talks with other government agencies were to determine
what type of software is used for their core accounting applications.
The type of software refers to Commercial Off-The-Shelf (COTS) or
in-house Developed (IHD). Core accounting applications are deemed as
General Ledger, Budget, Funds Control, Accounts Payable, Accounts
Receivable, and Collections.

[COTS Packages.]{.underline} To determine what COTS packages should be
used for the functional requirement analysis, research was conducted to
determine the most complete and current COTS packages out in the
financial marketplace. Five COTS packages were selected that entailed
accounts receivable processes and that market the Federal Government and
are used by other Government Agencies. In addition, two Treasury
Workstation packages were also selected to be included in the evaluation
process since Treasury Workstations typically perform the front-end
processing of a Collection System process. Vendors for each COTS package
were contacted to obtain details about each product and pricing
information. A preliminary cost analysis was performed based on the
available information. The costs reflect ballpark figures for the
purpose of demonstrating costs of COTS packages relative to the existing
Collection System.

[System Development Methodology Analysis.]{.underline} The Team was
requested to review the existing Collection System Developers Quality
Assurance (QA) and System Development Plans. From those plans, the
Developers were queried as to how they adhered to their own QA and
System Development Plans, including milestones and deliverables.

2\. Phase II Data Integrity Review

This phase engaged E&Y as a subcontractor to TWM Associates, Inc. to
assist the FCC in testing certain elements in the collection database.
The testing was part of an effort to gauge next steps in implementing a
new system and assessing the data included in the existing database. The
procedures performed were outlined in the statement of work, and were
further discussed and refined in subsequent meetings between FCC
representatives, FCC OIG, TWM, and the Collection System Steering
Committee.

The testing requested consisted principally of utilizing
computer-assisted techniques to select a sample of transactions for
testing of information in the database extract provided against source
data.

For each transaction selected in the sample, E&Y agreed the data
included in the collection file to supporting documentation. This
included tracing transactions to:

-   

> Files containing Form 159 remittance documents or equivalent;

-   

> Spreadsheets used outside of the collection system to track up-front
> auction payments;

-   

> Bank statements to agree transactions to wire transfer evidence (wire
> slips);

-   

> Auction Installment Payment (AIP) report extracts to substantiate
> Automated Clearinghouse (ACH) evidence;

-   

> Refund spreadsheets to agree transactions netting to zero; and

-   

> Refund extracts from the National Finance Center (NFC) and the Federal
> Financial System (FFS).

Specific data elements included date payment received, payor name and
address, amount, FCC account number and fee control number, payment type
code, and payment method.

For certain types of transactions, including wire transfers between FCC
bank accounts, residual payments from successful auction bidders, and
transactions related to the Client Initiated Payment Program, E&Y agreed
a subset of data elements between the collection database and the
supporting documentation. In these cases, the remaining data elements
are not required on the documentation received. For example in their
Agreed-Upon-Procedures report, E&Y reported that:

-   

> For wire transfers between the lockbox provider and the FCC, they
> agreed the payor name and the amount from the wire slip to the
> collection database.

-   

> For residual payments from successful auction bidders, they agreed the
> FCC account code, the Payor name, address, and amount from the
> collection database to the appropriate Auction spreadsheet and agreed
> the spreadsheet total to the Lockbox Provider Bank Statement.

-   

> For the Client Initiated Payment Program, they agreed payment name and
> amount from the Lockbox Providers AIP report.

In addition, E&Y reviewed the document files for those transactions
selected and documented any refund activity noted in the files provided.
E&Y traced the refund activity to two data files provided by FCC Office
of Managing Director:(1) general ledger accounts payable extracts files
including refund activity for the related period; and (2) a paradox file
of all transactions reloaded into the collection system in April/May
1997.

Finally, during the review of the collection files, E&Y identified
ninety-two (92) Form 159 FCC Remittance Advise documents identifying
amounts greater than \$100,000 that were not directly traceable to the
sample. Additional procedures were identified and performed to determine
if the amounts represented valid transactions that should be included in
the collection database. These procedures included:

-   

> Tracing those items representing Auction upfront payments and refunds
> to the appropriate Auction Spreadsheet,

-   

> Agreeing transactions to supporting documentation that a name change
> had taken place and the item, under the new name, was represented
> within the sample, and

-   

> Agreeing the summarization of two (2) Form 159s to a summarized
> transaction within the sample.
>
> **E. DETAILED RECOMMENDATIONS PHASE I**

Following are the detailed observations noted during Phase I. The
observations are grouped by classification. The classifications assigned
were:

> A Audit trail controls issues.
>
> B Banking related matters to improve efficiency or costs.
>
> C Contracting matters.
>
> D Database issues.
>
> I Internal control issues affecting segregation of duties and
> compromise of controls.
>
> P Programming related matters.
>
> PI Process improvement matters.
>
> PO Policy and procedures issues.
>
> S Security issues.
>
> SDLC Life Cycle development issues.

If an observation represents more than one classification, it is shown
in the first occurrence of the classification only. Where applicable,
references to other classification categories are noted in parenthesis
at the end of the observation.

The individual observations and recommendations have also been assigned
an exposure rating of High, Medium, or Low. The rating of High is
assigned when it is perceived the segregation of duties is compromised
and/or the security risk is high enough to possibly cause on‑going
operational concerns or business disruptions. The rating of Medium is
assigned when it is perceived the segregation of duties may be
compromised and/or security risk is medium to cause on‑going operational
annoyances, but would not cause a business disruption in the event of an
occurrence. The rating of Low is assigned when it is perceived the
segregation of duties could be compromised and/or security risk is low
to cause on‑going operational efficiency issues, but does not cause a
business disruption in the event of an occurrence. The category of each
observation (i.e., high, medium, or low) is identified at the end of
each observation enclosed in brackets.

> *[Audit Trail Control Issues]{.underline}*

Audit trail controls determine the ability of the information being
processed to be traceable throughout the cycle of the data used. From
the introduction of the data through the recording of the data to the
reporting of the data, controls are present to ensure the data retains
its\' integrity. In addition, processes (manual or computerized) which
controls those data inputs, processing and outputs also affect the audit
trail controls. The lack of definitive and effective audit trail
controls may result in erroneous data, which may be contained in the
database, other applications which obtain data, reports to management,
and may result in decisions based on faulty or incorrect assumptions
based on the data provided.

**1. Observation:** As part of a data quality review, the Collection
Database was loaded with data from a Paradox file. The Paradox file was
not a direct feed from Mellon Bank. Though Mellon Bank information may
have been used as the basis for the Paradox file, many of the individual
data elements (i.e., transaction date, address, payor, amount, payment
type code, etc.) were changed. The Paradox file was loaded into the
Collection Database without: a proper audit trail, evidence supporting
the individual changes, evidence supporting the deletion of transactions
which netted to zero (i.e., upfront payments made and then refunded) or
changes made to the source documents originally supporting the
transactions. The Paradox file information also did not contain
references back to the original transactions being adjusted. (I, P, S)
**\[High\]**

**Recommendation:** Do not allow updates to the Collection Database
without the proper supporting records and audit trails.

**OMD/WTB Response:** Concur, all updates to the system shall be
supported by proper source documents and provide complete audit trails.

**2. Observation:** The Collection System does not have the
functionality in place to allow for the proper traceability of changes
to a transaction (i.e., change of name, address, amount, etc.) as
required for an accounting system under OMB guidance. (P) **\[High\]**

**Recommendation:** Whether the Collection System is enhanced or another
system is put in its place, ensure there is proper functionality and
audit trails for making changes, updates, insertions, and deletions to
the transactional database.

> **OMD/WTB Response:** Concur, efforts are underway to ensure that the
> current system properly provide the necessary functionality and audit
> trails for making changes, updates, insertions, and deletions to the
> transactional database. Required coding changes to ensure that the
> current system corrects this finding are due to be placed into
> production on December 31, 1998.

A mandatory requirement will be included in the RAMIS RFP to assure that
audit trails are maintained for all transactions including changes to
table entries. (Second Quarter FY 1999)

**3. Observation:** Not all collection related transactions are loaded
and recorded in the Collection Database (e.g., Auction 11 refunds,
upfront payments, unsupported transactions, installment payments, credit
card transactions in 1995, or AIPs). While some of the information may
have been provided to contractor support to load into the database, the
programming to provide the load did not occur. (D, I, P) **\[High\]**

**Recommendation:** Revise procedures to ensure all transactions are
properly recorded in the Collection System.

**OMD/WTB Response:** Concur, procedures shall be revised to ensure that
all transactions are properly recorded in the Collection System.
Revision to procedures due last quarter FY 1998. All transactions will
be recorded in RAMIS.

**4. Observation:** Edit controls to ensure the transmissions received
from Mellon Bank are valid, complete, accurate, and for the proper date
do not seem to be in place and/or functioning properly. (B, I)
**\[Medium\]**

**Recommendation:** Implement the proper automated edit controls to
ensure file transmissions received are valid (summary and detail
transaction records), complete (using the 01 and 99 BAI record
identifiers in the file transmission), accurate (file count and testing
through the adding of details and comparing to the summary record), and
for the proper date (date requested is the date received).

**OMD/WTB Response:** Concur, the lockbox nightly load process has been
modified to include proper automated edit controls to ensure file
transmissions received are valid (summary and detail transaction
records), complete (using the 01 and 99 BAI record identifiers in the
file transmission), accurate (file count and testing through the adding
of details and comparing to the summary record), and for the proper date
(date requested is the date received). Due to be placed into production
September 30, 1998.

The lock box service bank file transmission will need to be reevaluated
and changed depending on the COTS package selected as the basis for the
new system (RAMIS). Recommendation #4 will be incorporated in the design
of the file transmission. (Implementation FY 2000)

**5. Observation:** When requesting a refund through the Collection
System, the person inputting the request can change the payor name. (I)
**\[Medium\]**

**Recommendation:** Alter the system to disallow the changing of the
payor name unless there is manager approval for such a change and the
change is documented in the Collection system along with the reason for
the change.

> **OMD/WTB Response:** Concur, the Collection system will be modified
> to require manager approval for payor name changes by adjusting
> permission grants. Review of the current system design will be
> performed in September 1998, with required modifications due first
> quarter 1999. RAMIS implementation will include Recommendation 5.
> (RAMIS implementation FY 2000).

**6. Observation:** Wire transfers into FCC bank accounts are not always
accompanied by Form 159s. In addition, Mellon Bank does not always
prepare the Form 159s for those transfers. However, only the information
keyed in Mellon Bank is transmitted to FCC for the Collection System
data population. Use of the specialized Form 159 keying procedures and
transmission of information increases the chances for information to be
lost or mis-keyed, causing improper recording or untimely recording of
payment information. (B, PI, SDLC) **\[Low\]**

> **Recommendation:** For any type of electronic payment or non‑check
> payment, Mellon Bank should not key in the information. This
> information should be transmitted electronically to the Commission
> through standard BAI formats, not through a specialized FCC format
> (i.e., Form 159).

**OMD/WTB Response:** Concur, this recommendation shall be explored
during the design of RAMIS. The lock box service bank file transmission
will need to be reevaluated and changed depending on the package
selected as the basis for the new system. Recommendation #6 will be
incorporated in the design of the file transmission. (Implementation FY
2000)

**7. Observation:** Refunds of upfront payments typically exceed \$1
million. Due to Treasury limitations, BCB breaks refunds in excess of
that amount into smaller payments. Without permission from Treasury,
this is an internal control that is compromised. (PI) **\[Low\]**

> **Recommendation:** Work with Treasury to adjust the limitations in
> light of the business need for refunding auction payments in excess of
> \$1 million.
>
> **OMD/WTB Response:** Non-Concur, this recommendation has been
> overcome by events. In February 1996 Congress gave the FCC authority
> to establish an interest bearing account for deposit of incoming
> auction upfront money. Since that time, all upfront refunds have been
> disbursed from the account via Mellon\'s Telecash System(). The system
> allows the FCC to process wire transfers without dollar limitation.
>
> In addition, there will be a mandatory requirement that the new system
> accommodate \$999B dollar values. Treasury guidelines concerning the
> maximum value of refund transactions shall be addressed through the
> FFS interface. The use of Mellon Telecash wire transfers significantly
> mitigates the impact of this issue on the Collections System.

**8. Observation:** Credit card transactions were not all authorized
prior to granting the license or purchased service. (I) **\[High\]**

**Recommendation:** Ensure strict authorization procedures are
documented for manual and automated processing of credit card
transactions.

**OMD/WTB Response:** Concur, OMD/WTB addressed this issue over a year
ago. Only authorized credit card transactions are passed to the
Commission via the nightly load. All non-authorized credit card
transactions are returned to the applicant within 24 hours. The FCC is
coordinating its automated credit card program with the U.S. Treasury
and is in compliance with all Treasury rules, regulations, and policies
concerning the automated use of credit cards by a federal agency.

**9. Observation:** Payments made into Mellon Bank without sufficient
information to identify the payor results in undocumented manual
procedures that are performed by a programmer. (C, I) **\[High\]**

**Recommendation:** Document the processes for matching payments to the
information received from the bank.

**OMD/WTB Response:** Concur, this un-documented procedure is no longer
being performed. This observation has already been corrected and the
process replaced by a more efficient procedure. On March 16, 1998, the
FCC implemented new procedures for reporting the customer initiated
payments to the Birmingham site.

The transmission file which has now been superseded did not have
sufficient information to allow for recording and posting the payments.
The new transmission file which contains sufficient information for
posting the payments, thus eliminating the need for programmer
intervention.

There will be a mandatory requirement in the new system that corrections
to batch files be made on-line with adequate security. Use of database
reference table edits will reduce the need for intervention and manual
correction.

**10. Observation:** Sybase contractors are responsible for placing
production code into the production environment. The process for
ensuring the production code program changes are authorized, tested, and
approved are informal. (D, I, P) **\[High\]**

**Recommendation:** Implement formal change control procedures to ensure
all program changes are authorized, tested, and approved, prior to
placing the code into the production environment.

**OMD/WTB Response:** Concur, this recommendation has already been
placed into practice. All program changes are authorized, tested, and
approved, prior to placing the code into the production environment. The
Collections team has separated development, test, and production into
separate regions. Test plans, and approval procedures are in place to
control any future software releases into production.

The RAMIS Project manager has proposed that separate regions be
dedicated to the new system for training, interface development,
conversion and acceptance/system testing, production staging and
production.

The COTS contractor will be required to maintain full configuration
management under the terms of the contract during system modification,
data conversion and roll out. RAMIS maintenance procedures will
incorporate Recommendation \# 10 as a part of the maintenance contract
or will need to be absorbed by FCC using commercial configuration
management software.

**11. Observation:** There are no formal security administration
procedures at the database level (though some user level controls have
been implemented at the application level). There are five-hundred
fifty-seven (557) active userids on the Collection System, and of those,
four-hundred seventy-three (473) have no user information supporting the
userids, or authorization for those userids to exist on the Collection
System. (I, S) **\[High\]**

**Recommendation:** Implement formal security administration procedures
to ensure only authorized users have access to necessary information,
database elements, and stored procedures. Implement a periodic review to
ensure only the necessary number of users have access to the Collection
System and that they are properly authorized for such access to the
Collection System.

**OMD/WTB Response:** Concur, a review of the Sybase and application
security administration is underway. Furthermore periodic reviews shall
be conducted to ensure that only necessary users have access to the
Collection System. The number of system users shall be determined by the
needs of the users. The review which is currently underway will be
concluded by July 31, 1998.

Security issues will be addressed as a part of the implementation phase
of the RAMIS project. Both operating system security and application
security will be documented and implemented. (Implementation FY 2000)

**12. Observation:** There are no separate testing and production
environments. Without a proper testing and user acceptance environment,
daily operations can become unnecessarily affected by programming bugs
and other unknowns that may have been corrected in a test environment
(as evidenced during the six week down time of the Collection System).
(D, I) **\[High\]**

**Recommendation:** Implement a formal testing and user acceptance
environment separate from the live production environment for the
Collection System.

**OMD/WTB Response:** Concur, OMD/WTB has already responded to this
problem by ensuring that a formal testing and user acceptance
environment exist separate from the live production environment of the
Collection System. This change was made several months ago.

The RAMIS Project Manager has proposed that separate regions be
dedicated to the new system for training, interface development,
conversion and acceptance/system testing, production staging and
production.

**13. Observation:** Due to the Collection System development effort
longevity, daily Billing and Collections Bureau (BCB) operations make
use of spreadsheets to track incoming monies, at least for the upfront
auction payments, withdrawal payments, refunds, and cash balances. (I)
**\[Medium\]**

**Recommendation:** During the testing and implementation of the full
Collection System (i.e. existing or future COTS), ensure proper access
controls and segregation of duties are in place for the existing manual
procedures surrounding the maintenance of the spreadsheet used for
tracking bank transactions.

**OMD/WTB Response:** Concur, over the past year proper access controls
and segregation of duties were put in place for the procedures used to
tracking bank transactions. Missed schedules and lags in the development
effort forced the Billings and Collections Branch (BCB) to create tools
(spreadsheets, etc) for recording, tracking, and reporting transactions.
Further, a task on the RAMIS project plan is to evaluate current
processes and procedure to identify those that should be re-engineered
to assure maximum functionality from the selected COTS core package.

(3rd Quarter FY 1999)

**14. Observation:** The audit log is not used in the Sybase database
for the Collection System. (D, I) **\[High\]**

**Recommendation:** Turn the audit log on for sensitive procedures,
sensitive accesses, and sensitive write commands. Implement audit log
review procedures to ensure logged events are authorized and not
indicative of unauthorized activities. Audit log events also ensure
accountability of transactional changes.

**OMD/WTB Response:** Concur. The use of the system-level audit
capability has several technical issues, including space and performance
considerations, that must be researched and resolved before steps could
be taken toward implementation of system-level auditing. Action will be
taken to resolve these issues and activate system-level auditing by
September 30, 1998.

**15. Observation:** The Shell scripts used to load Mellon bank data
into the Collection Database did not contain the necessary edit checks
to ensure valid date and file completeness. File completeness checks
usually include a test to add the detail transaction records together to
determine if they match the contents contained in the bank transmitted
balance records. However, if standard BAI Code file layouts are not used
for the bank transmission of information, this becomes much more
difficult. (B, D) **\[Medium\]**

**Recommendation:** Adjust the scripts to include checks to ensure the
transaction data included in the Mellon bank transmission is for the
expected transaction date. In addition, file completeness edits should
be included (counting the number of headers and trailers does not ensure
file completeness for bank transaction transmissions).

**OMD/WTB Response:** Concur, The Collections Team will adjust the
nightly load Unix and SQL scripts to ensure that necessary edits are in
place to check inclusiveness of transaction data for the expected
transaction date and file completeness. These scripts, which identify
specific steps to be taken in a specific order, process the data files
sent from Mellon on a nightly basis. Review necessary adjustments - due
September 30, 1998.

The lockbox service bank file transmission will need to be reevaluated
and changed depending on the package selected as the basis for the new
system. Recommendation #15 will be incorporated in the design of the
file transmission. (Implementation FY 2000)

**16. Observation:** Changes to modules are not currently under a formal
configuration management process (CM). It is left up to the programmer.
(I, P) **\[Medium\]**

**Recommendation:** Create a Configuration Management group that manages
the configuration. This group should not include programmers or managers
of programmers.

**OMD/WTB Response:** Concur, Configuration Management is informal and
should be made more formal. However, Configuration Management should be
controlled by the Project Manager and the COTR.

The ITC accepts this recommendation. The FCC is pursuing improvement on
several paths. The first is by defining and implementing an FCC SDLC.
The second is through the ITC providing increased support to programming
task staff for the management of software configuration changes/upgrades
etc. In support of this effort ITC recently purchased the CAST
Workbench. PVCS, PowerSite and other products that can support this
effort are under evaluation. Thirdly, ITC is establishing a more defined
and controlled process through which releases/version are moved from
development to test/acceptance and implementation under the control of
FCC staff.

The COTS contractor, selected for RAMIS, will be required to maintain
full configuration management under the terms of the contract during
system modification, data conversion and roll out. RAMIS maintenance
procedures will incorporate Recommendation \# 10 and 16 as a part of the
maintenance contract or will need to be absorbed by FCC (probably ITC
contractors) using commercial configuration management software.

**OIG Comment:** The intent of this recommendation was to ensure that
programmers are not responsible for configuration management. We were
not attempting in our recommendation to dictate the structure of the
configuration management group except to recommend that it not be
comprised of programmers or managers with programming responsibilities.
A project configuration management group comprised of the COTR and
project manager is entirely appropriate as long as the project manager
does not also have programming responsibilities.

**17. Observation:** The programming standards identified are incomplete
for a development program. The compliance to existing standards during
the review process could not be verified. (I, P) **\[Medium\]**

**Recommendation:** Develop programming standards that all programmers
must follow and institute a formal review process that includes the
verification that the developed software conforms to the programming
standards.

**OMD/WTB Response:** Concur. Changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by Programming Services Contract (PSC) staff
verified.

The RAMIS Project manager will work with ITC to assure that all
standards adopted by the FCC are adhered to during the project.

**18. Observation:** Unit (development or enhancements) folders that
were provided by contract identified were not organized and did not
contain sufficient information for evaluation. (I, P) **\[Medium\]**

**Recommendation:** Develop a standard for what is required in a unit
folder. Then initiate a review of all Unit folders for compliance with
the standard.

**OMD/WTB Response:** Concur, the RAMIS Project manager will work with
ITC to assure that all standards adopted by the FCC are adhered to
during the project.

**19. Observation:** Upfront payments prior to an auction and upfront
payments refunded, after the auction is concluded, are not recorded in
the general ledger. (I) **\[Medium\]**

**Recommendation:** All transactions should be included in the general
ledger, even if they are custodial in nature.

**OMD/WTB Response:** Concur, as part of the development of RAMIS all
transactions shall be included in the general ledger, even those
identified as custodial in nature. The transaction shall be included in
the new revenue system, and be reported to the appropriate standard
general ledger (SGL) account.

**20. Observation:** Upfront payment activities are maintained on an
Excel Spreadsheet in BCB. The spreadsheet contains no references to
dates payments were posted to the bank accounts. Manual controls over
the integrity of the spreadsheet have not been reviewed. (I)
**\[Medium\]**

**Recommendation:** If the spreadsheet is to be used as a source of
management information, the date the money was posted to the bank
account should be included. In addition, the controls surrounding the
accuracy of the spreadsheet should be reviewed in order to ensure the
integrity of the numbers being provided for management information
reporting.

**OMD/WTB Response:** Concur, all manually created spreadsheets shall
include the date the money/transaction was posted to the bank account.

**21. Observation:** Verification and Validation was not performed. (I,
P, SDLC) **\[Medium\]**

**Recommendation:** The project should implement a tracing of
requirements to functionality. This traceability should allow the
government to determine the magnitude of efforts that were proposed
versus the cost of the as built. In addition, the process should be
conducted or monitored by subject area experts.

**OMD/WTB Response:** Concur. The FCC is pursuing via contract the
development of an appropriate SDLC for adoption throughout the
Commission. This SDLC is expected to define the development and tracking
of initial requirements and to establish a mechanism for maintaining
requirements definitions throughout the life cycle.

The RAMIS Project Manager will propose that the FCC hire or task an IV&V
contractor to perform tests against modifications and interfaces and,
depending on the documented track record of the package selected,
production.

**22. Observation:** Contractor staff do not produce minutes or agendas
for project meetings. In addition, only five months of status reports
were provided for a project that has been on going for several years.
(C, I) **\[Low\]**

**Recommendation:** All meetings that are paid for by the government
should be formally recorded and should, at a minimum include an agenda,
any action items, and minutes.

**OMD/WTB Response:** Concur, this practice is already in place for all
OMD/WTB funded contracts.

The RAMIS Project Manager and the contractors will issue regular
bi-weekly project status reports that address issues, concerns, and
status on ongoing tasks and identify completed tasks. All meetings will
be documented.

**23. Observation:** The developer is not following their proposed
Quality Assurance (QA) plan. In addition, of the few documents produced,
content can be significantly strengthened. (C, I, SDLC) **\[Low\]**

**Recommendation:** The developer should be required to follow the QA
plan they proposed.

**OMD/WTB Response:** Concur, as a part of the SOW, peer reviews will be
required as part of the quality assurance function.

**24. Observation:** The developer should have meeting minutes that
documents their perspective of events that occurred in the meeting. For
the period February 1997 through March 7, 1997 weekly status reports
were provided, but for no period prior to or after. (C, I, SDLC)
**\[Low\]**

**Recommendation:** The developer should record all events that occur in
meetings that affect schedules, programming efforts, enhancement
efforts, or contractual requirements.

**OMD/WTB Response:** Concur, this practice is already in place for all
OMD/WTB funded contracts. As part of the RAMIS SOW, contractors will be
required to submit comments on meetings, etc.

**25. Observation:** Due to the lack of userid documentation (i.e., the
FCC personnel name, location, job responsibility, reason for access,
title, etc.), it is not feasible to associate the userids with the
groups defined in Sybase to determine if the group and associated user
access is reasonable. (I, S) **\[Medium\]**

**Recommendation:** A full review of the Sybase access control structure
should be performed to fully document the structure, ensure it is
reasonable based on the program structure, determine if the userids are
current or should be deleted, and then determine their reasonableness of
access.

**OMD/WTB Response:** Concur, as stated previously a review of the
Sybase access control structure is underway. This review is schedule to
be completed and document by July 31, 1998.

Additionally, security issues will be addressed as a part of the
implementation phase of the RAMIS project. Both operating system
security and application security will be documented and implemented.

**26. Observation:** The Sybase groups defined with access to stored
procedures and database objects does not seem reasonable and does not
seem to acknowledge a logical internal control system. In addition,
there seems to be references to userids which no longer exist (i.e.,
develop). (I, PO) **\[High\]**

**Recommendation:** Review and correct group definitions as well as
individual user accesses to ensure access is considered reasonable based
on job responsibilities and based on a sense of logical internal
controls in accordance with OMB. In addition, security access structures
should be reflective of the current environments. As the user base
changes, there needs to be processes in place to ensure that userids are
added, changed, and deleted accordingly.

**OMD/WTB Response:** Concur, the Collection\'s Team is in the process
of reviewing group definitions as well as individual user accesses to
ensure that access is based on job responsibility and that logical
internal control exist.

Security issues will be addressed as a part of RAMIS\'s implementation
phase. Both operating system security and application security will be
documented and implemented.

**27. Observation:** The Sybase access control reports showed defined
accesses to stored procedures which did not seem to exist as they were
not found in the extract of stored procedures provided. (I, S)
**\[Medium\]**

**Recommendation:** Administrative procedures must be put in place to
ensure that once stored procedures are added or deleted, the appropriate
access control changes are also made.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been instituting administrative procedures to ensure that all stored
procedures added or deleted to the Collections System are tracked to
ensure that the appropriate access control changes are also made and
documented. Under RAMIS, security issues will be addressed as a part of
the implementation phase of the project. Both operating system security
and application security will be documented and implemented.

**28. Observation:** The Project Manager userid is aliased (i.e.,
defined) to the dbo, which has full permissions on all objects in the
database owned by the dbo. (I, S) **\[High\]**

**Recommendation:** In order to effect an appropriate logical internal
control function, no single person should have access to the entire
system. The Project Manager and developer personnel should be restricted
to the development area only and should not have access to production or
operational environments.

**OMD/WTB Response:** Concur, security is of great concern and has been
reviewed by OMD/WTB to ensure that the appropriate individuals have
access only regions which meet their specific needs. The Data Base Owner
(DBO) alias does not imply full permissions to all objects. Permissions
are subset of those possessed by the DBA; the Project Manager and DBA
are trustees of the system. We caution reliance on this observation,
since the position of DBO is essential to database maintenance.

OMD is currently working to implement a system development and
management life cycle plan to ensure that no one person will have or be
able to access the entire system.

Security and access issues will be addressed as a part of the
implementation phase of the RAMIS project. Both operating system
security and application security will be documented and implemented.

**29. Observation:** The Sybase Configuration file shows many default
settings, which may or may not be appropriate for the Collection System.
Particularly, the lack of enforced system‑wide password changes, the use
of allowing remote access, and the number of allowed remote logins and
remote sites. (I) **\[Medium\]**

**Recommendation:** The Configuration File options should be reviewed
for their appropriate settings in the Collection System.

**OMD/WTB Response:** Concur, over the past year the Collections Systems
Database Administrator, COTR, and TPOC have reviewed all settings and
established a management control policy and review system to ensure
appropriate settings are maintained.

Security issues will be addressed as a part of the implementation phase
of the RAMIS project. Both operating system security and application
security will be documented and implemented.

**30. Observation:** Non‑standard naming conventions
(J:\\magoo\\dave\\\*\*\*) are used for storing production source code.
(P) **\[Low\]**

**Recommendation:** Use standard naming conventions.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been reviewing naming conventions and, where possible and feasible,
been standardizing all naming conventions. Under RAMIS standard naming
conventions shall be employed.

**31. Observation:** Weekly Status Reports and/or Problem logs did not
contain certain critical elements in order to be effective management
tools. Critical elements include: What is the issue or discussion item;
how did it become an issue (i.e., what caused the problem or who
requested); who is responsible for resolving the issue; how was the
issues resolved; when was it resolved. (P) **\[Low\]**

**Recommendation:** Rework the status reports to include the critical
elements.

**OMD/WTB Response:** Concur, over the past year the Collections Team,
COTR, and TPOC have reviewed and restructured all status reports. Under
RAMIS the status reports will be reviewed and restructured based upon
the needs of the FCC and the limitations of the selected COTS package.

**32. Observation:** Because of the way in which bank information and
auction information is processed within the Collection System, there is
no subsidiary ledger for the Accounts Receivable in the General Ledger.
(I) **\[Medium\]**

**Recommendation:** Modifying the existing Collection System to create a
subsidiary ledger is cost prohibitive. Move towards a different
programming solution, considering COTS, and ensure the subsidiary ledger
is a requirement of the system.

**OMD/WTB Response:** Concur, the new system will function as a
subsidiary ledger for all revenue, collection, and accounts receivable.
Loan activity will be carried in a separate subsidiary ledger and will
be summarized into the new system and then include in the summary
reporting to FFS. (Implementation FY 2000)

**33. Observation:** Review of the Stored Procedures indicated the
intermingling of stored procedures labeled as test or temp. (I, P)
**\[Medium\]**

**Recommendation:** Test procedures should not be intermingled within
the production stored procedures. Separate and distinct test and
production environments should exist to assure only authorized changes
to production code and data occur.

**OMD/WTB Response:** Concur, this recommendation has already been
satisfied, separate and distinct test and production environments are
utilized. Additionally, RAMIS development and testing will be kept in
separate environments from production.

**34. Observation:** Execution of the extended fieldwork procedures
highlighted the need for further documentation in the files in the event
of bidder defaults and declining to participate in the auction after
their Form 159s have been sent in and received by the FCC. (PI)
**\[Low\]**

**Recommendation:** Document in the files of the bidders when they have
defaulted or declined to participate in an auction event if they have
sent in a Form 159.

**OMD/WTB Response:** Concur, source documents without dollars (FCC Form
159) shall be annotated by BCB to indicate non-participation in the
auction event.

**35. Observation:** During the Ernst & Young Data Integrity Review, it
became readily apparent that same FCC Account Numbers are used to
represent several companies. Although there may be valid reasons for
this condition (e.g., companies are affiliated, company names have
changed), it becomes very difficult to ascertain payment and refund
trails. (I, PI) **\[High\]**

**Recommendation:** Manual or automated procedures should be implemented
to ensure a company name is associated with only one FCC Account Number
within the Collections Database to ensure data integrity.

**OMD/WTB Response:** Concur, over the past year the Collections Team,
COTR, and TPOC have been addressing this issue. We are currently testing
several approaches for an automated process for one name per account in
order to ensure system data integrity. The new nightly load, which is
due in production on September 30, 1998, will fulfill this requirement
by allowing the update and association of the company name with the
appropriate \"FCC Account Number\".

Relational systems will not allow duplicate keys. The TIN as the primary
key may present operational problems. A unique key must be established
and used by all interfaced systems.

**36. Observation:** During the Data Integrity Review Procedures, there
were several instances in which items in the database did not behave
properly. Records that were shown on the screen as reversed were still
in the database with payment amounts (e.g., Jennifer Plant wire
reversal). Items which should have been included in the database extract
provided to Ernst & Young were not included (e.g., Omnipoint).
Transactions that should have been in the database were placed in the
database through a Paradox upload vs. a Mellon Bank transmission (e.g.,
Southeast Telephone LP). And a few transactions for \$1.3 billion showed
only as .3 billion (e.g., AT&T Wireless PCS Inc.) and \$1.6 billion
showed as .6 billion due to field limitations in the database (through
the details totaled the proper \$1.3 billion on the Payment Transactions
Detail Report). (D, I, P) **\[High\]**

**Recommendation:** Ensure that the selected COTS package incorporates
edits to detect these types of exceptions.

**OMD/WTB Response:** Concur, the RAMIS SOW will identify the need for
data quality checks and data integrity.

**37. Observation:** Initially, Auction 11 transactions were recorded
for using manual spreadsheets. After auction completion, net
transactions were keyed into the Collection Database. Keying errors were
identified in Auction 11 transactions when these manual records were
keyed into the collections database (e.g., Fee Control Number
9703068850904016). (D, I, PI) **\[Low\]**

**Recommendation:** All transactions, including upfront payments,
refunds, and withdrawal payments, should be recorded directly into the
Collections Database.

**OMD/WTB Response:** Concur, all transactions will be captured in the
current and new system as original entries.

**38. Observation:** A significant percentage of the dates recorded in
the Collection Database as Date Received were different from the
supporting documents by one to three days, and in the case of auction
payments, by months. For one check (Fee Control Number
9409098835469001), there were two dates noted where FCC asked Mellon to
hold the check until the regulatory fee window opened a few months
later. The integrity of the transaction recorded is compromised without
proper date information. (D, P) **\[Medium\]**

**Recommendation:** Transactions entered into the Collection Database
should reflect the proper date received, date paid, etc.

**OMD/WTB Response:** Concur, transactions entered into the Collection
Database shall reflect the proper date received, date paid, etc.

**39. Observation:** While reviewing files supporting auction payments,
many Form 159s were identified which did not have corresponding
transactions in the database. Subsequent research had to be performed to
identify if the forms were duplicates or if the payor was in default or
elected not to participate. (D, I, PI) **\[Low\]**

**Recommendation:** Notations should be made on the Form 159s, which are
not supporting valid transactions.

**OMD/WTB Response:** Concur, annotation shall be made on the Form 159s,
which are not supporting valid transactions, i.e., no money was
received, or duplicate copy.

**40. Observation:** Once auction events are completed, the monies are
moved from the FCC Interest Bearing account into the Treasury bank
account. These movements are recorded in the Collection Database. In
addition to the movements of the net auction amounts are also recorded
in the database. The money movements between bank accounts are
subsequently reversed, but the payment amount field of the reversal is a
positive number while the detail amount field is a negative number. This
creates difficulties in obtaining reports from the Collection Database
unless all fields are properly obtained. (D, I) **\[Low\]**

**Recommendation:** Traditionally, bank account to bank account
movements are recorded only in the cash accounts of the general ledger.
Only customer payments coming into a bank account should be recorded in
the Collection Database. The Collection Database should be corrected to
accurately reflect the payment amounts as negative numbers in the
Payment Amount field for reversals to ensure reports properly reflect
the underlying detail transactions.

**OMD/WTB Response:** Concur, recommendations presumes to change
requirements and functionality; data must be accessed completely, and in
the proper manner, in order to obtain complete results; finding is the
result of improper data access. This will be included in the Collections
Contractor tasking for FY 1999.

A mandatory requirement will be included in the RAMIS RFP to assure that
all transactions are recorded properly and that reversals reflect
underlying detail.

**41. Observation:** During the data integrity portion of the review,
the Commission was unable to provide supporting documentation for
selected transactions in a timely manner. This condition is indicative
of business process issues, audit trail issues, and record‑keeping
issues. (I, PI) **\[Medium\]**

**Recommendation:** Business processes for recording incoming money,
refunds, and other payment should be improved to ensure that proper data
elements are being recorded in the Collection Database. Changes to any
data elements should be recorded with an adequate audit trail to allow
for determination of who made the change, the reason for the change, and
details concerning the specific change. This should exist whether the
change was to an automated or manual record (i.e., documents maintained
in the folders supporting the transaction.

**OMD/WTB Response:** Concur, the new nightly load which is scheduled to
go into production on September 30, 1998, will correct this finding. The
RAMIS SOW will specify that the capability to retain notes with any
transaction is highly desirable.

Although the recommendation is based on an observation with which we do
not totally agree, we will continue to improve our business processes to
the maximum extent feasible.

**OIG Comment:** This observation was based upon work conducted by E&Y
as part of the data integrity portion of the review. The results of the
E&Y data integrity review are discussed in summary in Section F of this
document and the detailed report is included as Appendix A to this
report.

Management has stated that they \"do not totally agree\" with the
observation on which this recommendation is based. However, they do not
provide any details, either here or in their response to Section F,
indicating why they believe that the observation is not factually
accurate.

**42. Observation:** The Paradox Upload performed in May 1997 was
supposed to follow programmatic guidelines and rules for \"updating\"
records in the Collection Database. Throughout the Data Integrity Review
Procedures, database oddities appeared though the transactions all had
supporting documentation showing money coming into the FCC bank account.
Upon further investigation, it was learned that the Paradox Upload
didn\'t function as intended, resulting in many oddities within the
database transactional records. (D, I, P) **\[High\]**

**Recommendation:** Do not perform any \"uploads\" to the collection
Database that are not Bank originated transmissions. Any changes to be
made to bank transactions should be made through an auditable process
with proper audit trails and supporting documents of the items changed.
Each of the transactions with the PDX initials (indicating the record
was generated or changed as a result of the Paradox Upload) should be
reviewed and tied to supporting documents. If the record is not
supportable, it should be removed.

**OMD/WTB Response:** Concur, over the past year the Collections Team,
COTR, TPOC, and Mellon Bank have been developing a new \"nightly load\"
process. The nightly load is generated from Mellon Bank and sent
directly to the FCC\'s Collections System. All changes to be made to
Mellon\'s transmission bank transactions follow a totally auditable
process through the Billings and Collections Branch (BCB). Prior to
migrating to RAMIS, the historical data maintained in the collections
database will be reviewed, validated, and verified to determine if
migration is recommended.

*[Banking Related Matters to Improve Efficiency or Costs]{.underline}*

Banking related matters concern those processes contained at the bank or
at the Commission which involve the handling of banking information.
When identifying areas for process improvement, the ideal basis is to
concentrate on single sources for information, input, and processing in
lieu of redundancy.

**43. Observation:** Mellon Bank is using primarily manual processes for
processing lockbox payment information including handwritten fee tables;
if‑then type procedures; manual adding of payment amounts; copying of
documents; matching of payments to 159 forms; preparation of 159 forms
if there are none; and creation of zero amount records. There is no use
of available technology to make the process more efficient at the Bank
or at the FCC. This leaves a significant room for mis‑keying and
mis‑matching of payments to supporting documents. (PI) **\[Low\]**

**Recommendation:** Perform a lockbox bank processing analysis and
review of FCC payment processing procedures to make use of more current
computer technology for processing the high volume of small dollar
payments.

**OMD/WTB Response:** Concur, the RAMIS Project Manager will work with
the servicing banks to streamline processes and improve data integrity.
Since the \"feed\" will have to be entirely rewritten to accommodate any
system that is put in place, this will be an ideal opportunity to
improve our processes.

**44. Observation:** The electronic interface between the Collection
System and Mellon Bank is using non‑standard transmission formats. Use
of the non‑standard transmission formats ignores currently available
technology and causes the need for more maintenance at both Mellon Bank
and at the FCC. (PI) **\[Low\]**

**Recommendation:** Use the banking standard BAI format to allow for
identification of all payment types (i.e., check, wire transfer, ACH,
etc.) and for descriptive detail (i.e., payor name, payor address,
nature of the payment, etc.) to be transmitted for potential matching in
the Collection System.

**OMD/WTB Response:** Concur, the new system will use the BAI
terminology and formats to the extent feasible.

**45. Observation:** FCC does not receive full summary and detail
transaction records from Mellon Bank in the existing electronic
transmission. (PI) **\[Low\]**

**Recommendation:** Direct Mellon Bank to furnish full summary, detail,
and returned item records from Mellon Bank in order to properly populate
the Collection System database.

**OMD/WTB Response:** Concur, the Commission shall request the lockbox
provide full summary, detail and return item records to allow for the
proper population of the Collection System database. The request shall
be submitted to the lockbox bank on or before July 31, 1998.

The RAMIS system will be the control point for all servicing banks
transactions.

**46. Observation:** FCC issues approximately 700 wire transfers per
year at a cost of \$10‑12 per wire transfer. (PI) **\[Low\]**

**Recommendation:** Use ACH payments instead of wire transfers. ACH
rates are typically less (could be pennies per transactions or at most
\$1‑2 dollars) and can be issued with one‑day settlement instructions.
This will result in bank fee savings for the FCC.

**OMD/WTB Response:** Non-Concur, the use of wire transfer for returning
auction upfront money to non-winners is preferred by the customer and
has proven to be very efficient. This is the only refund processing
application which utilizes wires, all other refunds utilize ACH or
check, including credit card refunds. There is no charge to the FCC for
this service.

The new system must be able to support a wide range of receipt
mechanisms as well as payment (refund) options.

**OIG Comment:** In their response, OMD/WTB have indicated their
decision to use wire transfers for customer convenience and because it
has proven to be very efficient. The response also states that \"(t)here
is not charge to the FCC for this service.\"

Certainly it is appropriate for management to take into consideration
such elements as customer convenience and efficiency during the
selection of a refund payment process. The intent of our recommendation
was to point out a lower cost alternative. It is also worth noting that,
although the Commission is not charged for wire transfers, it is likely
that the Department of the Treasury incurs charges for this service.

**47. Observation:** Multiple receipt files are sent from Mellon Bank to
the Collection System, and the FFS General Ledger System. This means
that there must be multiple input file validation checks on the same
banking data sent to several different locations. (PI) **\[Low\]**

**Recommendation:** A central group should be used for obtaining the
banking information and then disbursing the information to the other
systems for processing. This central group can then ensure the banking
information is complete and for the correct date, and it can be done
once and only once instead of the repetitive procedures in the multiple
sites.

**OMD/WTB Response:** Concur, all transactions will be included in the
RAMIS database and will be transmitted in summary to FFS for the general
ledger and to other users to update their databases. (Implementation FY
2000)

**48. Observation:** Wire transfers and ACH electronic payments are paid
into bank accounts monitored by the lockbox processing area of Mellon
Bank. Traditionally, electronic payments (wire or ACH) are paid into
separate bank accounts not monitored or handled by the lockbox
processing area. This is done to ensure the immediate availability that
comes when those types of electronic payments are realized. If these
type of payments come into a lockbox account after the lockbox cutoff
time, the agency may not get the immediate availability until the next
business day, thus losing use of funds for that time period. (PI)
**\[Low\]**

**Recommendation:** The Commission should explore the feasibility of
establishing separate accounts outside the lockbox processing area for
electronic payments.

**OMD/WTB Response:** Concur, as a part of the business re-engineering
process, the RAMIS team will evaluate banking processes and recommend
changes depending on the COTS system chosen.

*[Contracting Matters]{.underline}*

During the contracting process, attempts are made to place guidelines,
standards, and units of measure for how the contract support should
perform in order to carry out the Commission objectives. Without
adherence to those units of measure by the Contractor Support teams and
without enforcement by Commission representatives, development efforts
take on their own path without the success of the Commission as the
goal. This path may or may not incorporate the appropriate controls
required in financial applications. As a result, many of the controls
are left out or are compromised during the development process. The end
result can be applications that do not meet the desired functionality of
the Commission, do not support the proper internal control structures
for adherence to OMB requirements. A lack of measurable performance
units may limit recourse against systems development contractors by the
Commission.

**49. Observation:** Computech and Sybase contractors perform
operational functions for the FCC as part of the daily Collection System
process. In addition, these same contractors are responsible for the
development of the Collection System. (I) **\[High\]**

**Recommendation:** Remove the contractors who develop the Collection
System from the operational aspects of the FCC Collection process. A
clear division of labor should exist between Operations and Development.
Developers, DBA, and programmers should not be allowed to perform live
production or operational activities as it compromises the segregation
of duties required by OMB.

**OMD/WTB Response:** Concur, over the past year the Collections Team,
COTR, and TPOC have separated the Collections Team development and
production duties and responsibilities. Currently, there is a separate
and distinct development team, testing environment, and production team
to support the FCC\'s Collections System. Under RAMIS this
recommendation will be fully complied with and adopted.

**50. Observation:** The Commission has not established an adequate
process to measure and evaluate Collection System contractor
performance. Our review indicates that minimal task order status
reports, designed to ensure adherence to existing contracts and
statements of work, have been provided. Those status reports that were
obtained and evaluated were determined to be repetitive (i.e., reporting
the same events from month to month) or found by FCC contract personnel
to be non‑compliant. Without the accountability and enforcement of
measuring contractor performance, funds become quickly expended and the
FCC has not received reasonable services or deliverables for their
money. (I) **\[Low\]**

**Recommendation:** Accountability for contractor performance on
contracts and adherence to Statements of Work must be enforced within
the FCC contract monitoring structure.

**OMD/WTB Response:** Concur, the respective Project Managers will work
closely with Contracts to assure that a statement of work is developed
that will assure performance-based compliance. The project will be
monitored using tools such as, but not limited to Microsoft Project,
with tasks identified at the lowest level possible to assure control.

**51. Observation:** The Development Contractors did not possess
appropriate financial expertise to develop the Collection System that we
have defined as a financial system. (SDLC) **\[Low\]**

**Recommendation:** When developing financial systems, require the
contractors to supply personnel with financial application development
expertise to ensure financial requirements are being properly
interpreted from the users and programmed into the application.

**OMD/WTB Response:** Concur, over the past year Computech has hired
Collections Team programmers who have stronger programming and financial
experience more in line with the requirements to support the Collections
System. Under RAMIS personnel with financial application development
expertise will be utilized to ensure that the financial requirements are
properly interpreted from the users and programmed into the COTS
application.

**52. Observation:** The most experienced programmer assigned to the
project (i.e., Senior Developer) had no experience in developing
financial applications. Others interviewed have little or no experience
in developing financial applications. (P, SDLC) **\[Low\]**

**Recommendation:** The criteria for replacement of individuals should
include that a majority of the individuals be experienced in the
development of financial applications.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been restructured and, through attrition, replacements have been
brought on the team with stronger programming and financial experience
more in line with the requirements to support the Collections System.

**53. Observation:** The deviations from the Project Plan were never
formalized. Instead informal correspondence was used to document changes
in priorities and tasks. (SDLC) **\[Low\]**

**Recommendation:** All changes to tasking and requirements should be
coordinated through the contracting officer. In addition, the contractor
should not accept contractual relief from the COTR.

**OMD/WTB Response:** Concur, this no longer occurs.

**54. Observation:** There was no Quality Assurance on this project. (I,
SDLC) **\[Low\]**

**Recommendation:** The FCC should require the contractor to implement
their proposed quality assurance plan for this project.

**OMD/WTB Response:** Concur, over the past year the Contractor has
implemented procedures to ensure compliance with their Quality Assurance
(QA). The COTR and TPOC regularly meet with the Contractor\'s Program
Manager to review deliverables under this project. Under RAMIS the COTS
contractor will be required to propose and then maintain rigorous
quality assurance, an engineering approach to any modifications, and
meet the test plan requirements set out by the FCC.

The ITC also accepts this recommendation. Information is now being
assembled defining each contractors QA plans and COTRs will use this
information to review their contractors project management efforts and
evaluate performance.

**55. Observation:** Buzz words and multiple‑meaning words (e.g.
\"completed\") are used in the Status Reports, which would cause the
reader to make an incorrect assumption. For example, it has been
indicated in the Status Reports that all auction payment processing has
been completed. In fact, up‑front auction payments had not been
processed and loaded into the Collection Database. (P) **\[Low\]**

**Recommendation:** The Commission should direct Collection System
contractor\'s to revise the wording of the status reports so that
persons reading the documents who are not close to the project are able
to make the correct assumptions and not be mislead or misinterpret the
status of the project tasks.

**OMD/WTB Response:** Concur, future status report wording will include
adequate text in order to avoid misinterpretation of the status of the
project. The respective Project Managers and the contractors will issue
regular bi-weekly project status reports that address issues, concerns,
and status on ongoing tasks and identify completed tasks.

**56. Observation:** Stored Procedures exist without appropriate header
comments. Without header comments there is no place for describing the
Stored Procedure, identifying the developer, and recording the changes
to the Stored Procedure. Good programming standards, such as header
comments, are essential in support of change management. (I, P)
**\[Low\]**

**Recommendation:** Develop a coding standards manual mandating that all
Stored Procedures contain header comments. Update all Stored Procedures
to comply with the coding standards manual. Ensure that the program code
review procedures include steps to verify compliance with the coding
standards manual.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been developing a coding standards manual which includes a
requirement that all stored procedures contain header comments and that
all updates comply with the coding standards manual. As part of the
development of the manual a quarterly program review requirement is
being instituted to ensure that the Collections System program code
review procedures include steps to verify compliance with the coding
standards manual.

*[Database Issues]{.underline}*

Database issues are similar to the audit trail control issues in that
they affect the integrity of the data in the Collection System. The
database specific issues can be more technical in nature than the
general audit trail control issues, and thus have been segregated out
from those. Without the proper controls built into the database
structures, database security, and database procedures, the entire
application can be compromised and the desired internal controls
structures can also be more easily compromised. If database controls are
not properly implemented and adhered to, inconsistent handling of the
data can result in erroneous and/or missing data in the Collection
System. The Collection System can also become more costly for the
Commission to maintain in the long run without adherence to proper
database maintenance standards.

**57. Observation:** The tracking of operational problem resolution is
not formal and does not document what the problem is, what caused the
problem, how it was resolved, and by whom with an appropriate tracking
number. (P, PI) **\[Low\]**

**Recommendation:** Implement a formal problem resolution tracking
system to ensure that operational problems are resolved in a timely and
maintainable manner.

**OMD/WTB Response:** Concur, this practice is in place within the
current management structure of the Collection System. A formal process
is in place to track operational problems within the database.

**58. Observation:** Historical collection data is maintained on the
Altos Computer. The Altos computer has modem connections used to dial
out to the bank. Altos Computer security has not been reviewed.
**\[Low\]**

**Recommendation:** A comprehensive security review should be performed
on the Altos computer to ensure the data is controlled in a secure
environment.

**OMD/WTB Response:** Concur, the data previously housed and maintained
on the Altos has been transferred to a stand-alone database that can be
accessed by the Collections System. The waiver application still resides
on the ALTOS. Programming efforts to include the waiver application
software in the current Collection System is expected to implemented in
the first quarter FY 1999. Additionally, waiver tracking will be a
requirement of RAMIS.

**59. Observation:** Historical data has not been converted off of the
Altos computer to the new Collection System database. (P) **\[Low\]**

**Recommendation:** Study, plan, design and implement the conversion of
the data from the Altos computer to the new Collection System database.

**OMD/WTB Response:** Concur, the data has been transferred to a
stand-alone database that can be accessed by the Collections System.

**60. Observation:** Sybase contractors are not performing typical DBA
activities such as: documentation of the Unix and Sybase environments,
monitoring and optimizing the database performance, optimizing indices,
preparing and testing contingency plans and scripts, documenting and
preparing DBA workbooks, etc. Instead, Sybase DBAs are \[add typical
functions\]. (I) **\[High\]**

**Recommendation:** Refocus the Sybase contractor efforts onto DBA
activities instead of operational activities.

**OMD/WTB Response:** Concur, this recommendation has already been
implemented.

**61. Observation:** The Collection System is comprised of two separate
databases (one in Gettysburg, PA and one in Washington, DC). Maintenance
of procedures and databases for two separate but similar databases is
costly and inefficient. (PI) **\[Low\]**

**Recommendation:** Consolidate the two separate databases into one
database.

**OMD/WTB Response:** Concur, the task to consolidate the two databases
is under consideration.

**62. Observation:** Operating system, network application, database
application, and program application changes are made to the production
environment without proper testing of the underlying applications to
ensure proper operation and functionality after the change. In one case,
changes were made to the version of Sybase being used. This change
results in a significant negative impact on collection system
performance. (P, PI) **\[High\]**

**Recommendation:** Implement formal procedures to ensure all underlying
critical applications are tested with the new software prior to the new
software being placed into the production environment.

**OMD/WTB Response:** Concur, the Collections Team has already adopted
this recommendation.

**63. Observation:** The Collection System shares its server with other
non‑critical applications. (P) **\[Medium\]**

**Recommendation:** Due to the criticality of the accuracy of the
information processed by the Collection System, develop an
infrastructure which can ensure proper security and controlled
environmental changes to the programs being run (such as a separate
enclave).

**OMD/WTB Response:** Concur, the Collection System now has three
separate environments (development, testing and production) as an
infrastructure to assure security and a controlled environment for
change. It is anticipated that RAMIS will be supported on a dedicated
server.

**64. Observation:** Data fill is used in the form of zeroes on
Collection System database records in order to attain the fixed length
defined for the record set. The system is thus storing unnecessary
zeroes. (P) **\[Low\]**

**Recommendation:** Evaluate the system design and tools used to
determine if this is the most efficient manner for obtaining and storing
database records. Storing of unnecessary information places undue burden
on the database optimization.

**OMD/WTB Response:** Concur, the Collections Team has already evaluated
the system design and the available tools used to determine the
efficiency of the Collections System. Based upon this review the COTR
procured additional software tools for tracking and deleting unnecessary
information as well as authorizing modifications to existing system
modules to optimize performance.

**65. Observation:** Review of the log files displayed many lines of
errors (i.e., file not found, command aborted, cannot open input file).
These types of errors may be indicative of loose ends in the program
code. (P) **\[Low\]**

**Recommendation:** Each and every error in the log files should be
fully explored to determine the cause, and how the error should be fixed
for operational purposes and for programming purposes.

**OMD/WTB Response:** Concur, the log is reviewed at least daily by the
DBA, problems are promptly followed up on.

**66. Observation:** The SQL file cc_match.sql has extensive programming
contained within the file. (P) **\[Low\]**

**Recommendation:** The cc_match.sql programming should be rewritten
into a stored procedure which falls under the normal Sybase access
control protection and maintains programming consistency.

**OMD/WTB Response:** Concur, the new nightly load which will be place
into production by October 1, 1998, will satisfy this recommendation.

**67. Observation:** A Shell script (holdload.sh) contains code that
obtains information from a Data Fill file (WFEETAB5.FIL). The Data Fill
file has to be changed each day in order for the information to be
valid. (P) **\[Low\]**

**Recommendation:** Adjust the script to make use of more automated
checks. For example, date validation checks, BAI end of file checks,
Summarized transactions in comparison to balance records checks, etc.

**OMD/WTB Response:** Concur, the new nightly load which will be place
into production by October 1, 1998, will satisfy this recommendation. In
addition, all future upgrades, enhancements and changes will comply with
this requirement.

**68. Observation:** The Data Dictionary documentation of the date last
altered does not seem to be working properly. A Data Dictionary copy was
obtained from the Billings and Collection Branch and from the
Developers. The contents of the BCB document were empty as of 11/8/96,
but the \"date last altered\" shows 9/16/96 on the Developers copy. If
the date last altered does not function correctly, this may present
serious documentation issues as it will not be known if the most current
version is being worked with. (P, PO) **\[Low\]**

**Recommendation:** Review the settings for the date last altered to
ensure it is properly functioning.

**OMD/WTB Response:** Concur, the Collections Team has been tasked to
review the settings for the date last altered to ensure it is properly
functioning. Review to be performed by July 31, 1998.

**69. Observation:** The Data Dictionary and Data Entities Listing
contained many loose ends. Sources were not shown on diagrams, elements
were not used, and much of the individual element documentation was not
considered complete. (P, PO, SDLC) **\[Low\]**

**Recommendation:** The Data Dictionary and Data Entities Listing should
be reviewed and cleaned up to reflect the system as it exists, delete
obsolete elements, and ensure elements are fully documented.

**OMD/WTB Response:** Concur, the Data Dictionary and Data Entities
Listing are dynamic documents which over the past year the Collections
Team has been updating to reflect the current system. Additionally, when
a software update has been successfully tested and accepted by BCB these
documents are updated to reflect the additions, changes, and/or
modifications.

**70. Observation**: The Data Dictionary and Data Entities Listing are
not normalized. Our review identified several instances in which the
exact same field element was presented numerous times. (P, SDLC)
**\[Low\]**

**Recommendation:** Conduct an analysis to determine if data elements
and data entities can be further reduced.

**OMD/WTB Response:** Concur, a feasibility study will be conducted in
the FY 1999 to reduce data elements and data entities.

**71. Observation:** The Auction Application passes along a significant
amount of information to the Collection System. In some cases, the same
information is stored on both the Auction Application Database and the
Collection System Database, resulting in redundant amounts of data. (PI)
**\[Low\]**

**Recommendation:** Review the interfacing between the Auction
Application and the Collection System to streamline the dataflows and
only store the necessary information in one system.

**OMD/WTB Response:** Concur, a review shall be conducted in order to
streamline the dataflows and only store the necessary information in one
system. The review shall be completed by September 30, 1998. We hope to
minimize data redundancy to the maximum extent within security
constraints. So long as we can communicate with feeder systems, the
revenue/collection system should hold as little unnecessary data as
possible.

*[Internal Control Issues Affecting Segregation of Duties And Compromise
of Controls]{.underline}*

Segregation of Duties internal controls help to ensure that no one
person has the ability to facilitate or process in all aspects of a
system. This helps to ensure that only authorized activities happen in
an application or a system. The compromise of the segregation of duty
controls can allow for exposure to unauthorized activities that may be
at the detriment of the Commission in a financial or regulatory manner.

**72. Observation:** BCB personnel responsible for the daily collection
activities may also initiate refunds related to those same activities.
While there is a formal review and approve process in place, the
reviewers and approvers are also performing daily collection activities
and are responsible for reviewing those daily activities. **\[High\]**

**Recommendation:** Define a Business Process that segregates the refund
function from the BCB personnel.

**OMD/WTB Response:** Concur, since all checks, credit card
transactions, and wire transfers are handled through the lockbox
facility, we believe that the processing of properly authorized refunds
is adequate. Under RAMIS the workflow analysis and the subsequent
business process re-engineering will address separation of duties.

**73. Observation:** Credit card numbers of customers paying for fees
and other matters with their credit cards are maintained on the Server
with no encryption in place. FMS allows the use of credit cards as long
as the credit card numbers are not maintained in a database. (S)
**\[High\]**

**Recommendation:** Remove the credit card numbers from the Collection
Database or work with FMS to determine if FCC can instead encrypt the
credit card numbers in the database.

**OMD/WTB Response:** Concur, the Collections Team is actively working
with the U.S. Treasury and Mellon Bank to develop a credit card system
for the FCC. All credit card numbers, those already in the Collections
System as well as those to be in-put into the system, will be protected
following U.S. Treasury rules, policies, and guidelines. This credit
card program will migrate to RAMIS.

**74. Observation:** Segregation of duties between refund of auction
payments, daily cash application, and daily reconciliation of
Certificates of Deposit has room for improvement. **\[Medium\]**

**Recommendation:** Define a business process that segregates the
reconciliation of the Certificates of Deposit, the refund execution of
auction payments, the cash application process, and the reconciliation
of Bank Statements.

**OMD/WTB Response:** Concur, the RAMIS workflow analysis and the
subsequent business process re-engineering will address separation of
duties. (3rd Quarter 1999)

**75. Observation:** Programming standards do not exist for the
programmers of the Collection System. (P, PO) **\[Medium\]**

**Recommendation:** Implement and enforce the use of standard
programming procedures from the existing Developers Company guidelines
or other acceptable guidance.

**OMD/WTB Response:** Concur, over the past year the COTR and TPOC have
implemented and enforced the use of standard programming procedures by
the Collections Team programmers.

**76. Observation:** Customers credit card numbers are stored in the
Collection System Database. (S) **\[High\]**

**Recommendation:** Credit card numbers should be secured in the
tightest manner possible, which would include strong encryption and
strong access controls. Implement the strong encryption techniques and
access controls to help prevent unauthorized access and/or use of
customer credit card numbers.

**OMD/WTB Response:** Concur, the Collections Team is actively working
with the U.S. Treasury and Mellon Bank to develop a credit card system
for the FCC. All credit card numbers, those already in the Collections
System as well as those to be in-put into the system, will be protected
following U.S. Treasury rules, policies, and guidelines. This credit
card program will migrate to RAMIS.

**77. Observation:** Data Entity labeled CONFIDENTIAL_PAYMENT could be
indicative of surreptitious activities. It is not a normal financial
application feature. (S) **\[High\]**

**Recommendation:** Delete this data entity.

**OMD/WTB Response:** Concur, we will review the labelling, and if it is
appropriate we will delete this data entity. The review will be
accomplished by July 31, 1998.

**78. Observation:** Sybase roles and responsibilities have an excessive
number of userids assigned to the sa_role (13), sso_role (10),
sybase_ts_support role (4). (S) **\[Medium\]**

**Recommendation:** Implement a periodic review procedure to determine
whether the userids assigned these more powerful Sybase functions are
still necessary and that the access is appropriately authorized.

**OMD/WTB Response:** Concur, over the past year the Collections Team
DBA has met with the COTR and TPOC on a quarterly basis to determine
whether the userids assigned to the Sybase functions are still necessary
and that the access is appropriately authorized. New userids must go
through the TPOC and COTR for authorization.

**79. Observation:** Until recently, software peer reviews had not been
used in the development of the software. The establishment of these
reviews occurred such a short time ago that the effectiveness is
unknown. (P, SDLC) **\[Low\]**

**Recommendation:** The Commission should periodically review the
results of the software peer review process to ensure that it been
effectively implemented.

**OMD/WTB Response:** Concur, as a part of the RAMIS SOW, peer reviews
will be required as part of the quality assurance function. (2nd Quarter
FY 1999)

**80. Observation:** Some of the developers on the project are following
informal programming standards. (P, SDLC) **\[Medium\]**

**Recommendation:** The Commission should ensure that Collection System
contractors implement either a government provided programming standard
or their corporate programming standards.

**OMD/WTB Response:** Concur, The ITC\'s emphasis is being placed on the
development of FCC programming standards for each language. Changes in
ITC contracts for Sybase, PowerBuilder and web support staff now being
made will permit these contractors to work with FCC staff to develop
programming standards for the basic languages in use at the FCC. These
standards will be promulgated and their use by PSC staff verified.

FCC published standards or COTS Contractor standards will be used for
RAMIS.

**81. Observation:** The project did not have a problem report with the
associated documentation that would indicate a formal change management
process. (I, P, SDLC) **\[Medium\]**

**Recommendation:** The project needs to implement a change control
process that is formalized with documentation and approval processes.

**OMD/WTB Response:** Concur, the COTR and TPOC, in coordination with
the Contractor\'s Program Manager, have implemented a formalized change
control process. This process requires a \"Change Request\" document be
initiated by the Requestor and be submitted to the COTR for approval by
the COTR and TPOC before the programmers make any changes.

The FCC is pursuing improvement to the management of all ADP development
projects on several paths. The first is by defining and implementing an
FCC SDLC. The second is through the ITC providing increased support to
programming task staff for the management of requirements definition,
changes to requirements, system releases, hardware and software
configuration changes/upgrades etc. In support of this effort ITC
recently purchased the CAST Workbench. PVCS, PowerSite and other
products that can support this effort are under evaluation. Thirdly, ITC
is establishing a more defined and controlled process through which
releases/version are moved from development to test/acceptance and
implementation under the control of FCC staff.

**82. Observation:** The project could not show any evidence of a
cohesive project plan. (P, SDLC) **\[Low\]**

**Recommendation:** The project manager for this program should either
be trained or relieved. In either case, a cohesive project plan should
be developed to address the activities that are projected during the
course of the effort.

**OMD/WTB Response:** Concur, the Collections Team has been reorganized
and the current Project Manager is a fully qualified Sybase and
Powerbuilder programmer. In addition, there has been a staff transition
within the Collection Team which has added qualified Powerbuilder 5.0
programmers and a management analyst which strengthen the credentials of
the team. OMD/WTB has worked with the Collections Team Project Manager
to develop a cohesive project plan which address activities that are
projected during the course of the effort. Specifically, these
activities focus on the production modules which must be maintained for
daily operations, the remaining modules will be addressed by RAMIS.

**83. Observation:** A Test Plan does not exist. (SDLC) **\[Low\]**

**Recommendation:** The project should formalize the testing process. It
should address, at the minimum, unit testing, integration testing,
performance testing, and government acceptance testing.

**OMD/WTB Response:** Concur, the Collections Team has already
instituted a segregated test environment with formalized testing
procedures and \"push-pull\" approval requirements. In addition, the
Collections Team maintains a library of all test plans.

**84. Observation:** Unprofessional naming conventions were identified
in the review of the Sybase Stored procedures which make reference to
\"junk\" or individual programmers names. (P) **\[Low\]**

**Recommendation:** Standard naming conventions with professional naming
should be used for labeling of all stored procedures. Meaning of the
stored procedure should be entailed within the naming convention used.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been utilizing standard naming conventions with professional naming
for labeling of all stored procedures to include a definition of the
stored procedure.

**85. Observation:** Review of the stored procedures yielded several
procedures which would seem to be obsolete since the coding of the
stored procedure did not cause an action of any kind to occur on a
Collection System Table. (P) **\[Low\]**

**Recommendation:** Standard change control procedures help to prevent
retention of obsolete code and should be employed. Additional controls
in the form of periodic reviews for obsolete code and scrubbing of the
system are also encouraged.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been utilizing standard change control procedures in order to
prevent retention of obsolete code. In addition, the Collections Team
has been tasked to review and delete obsolete code within the
Collections System program modules. The review of existing code will be
completed by December 31, 1998.

In addition, the Collections Team has instituted a quarterly code review
to maintain a configuration management system for the Collections System
program code.

**86. Observation:** Stored Procedures variables are being declared
without an appropriate comment. Variables need to be defined and
identified with a comment to assist the maintainer of the Stored
Procedure in understanding the value and relationship of the variable.
Ensure that the program code review procedures include steps to verify
compliance with the coding standards manual. (P) **\[Low\]**

**Recommendation:** Develop a coding standards manual mandating that all
variables within Stored Procedures contain comments that describe the
purpose of the variable. Update all Stored Procedures to comply with the
coding standards manual. Ensure that the program code review procedures
include steps to verify compliance with the coding standards manual.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been utilizing standard naming conventions with professional naming
for labeling of all stored procedures to include a definition of the
stored procedure. The Collections Team has been tasked to develop a
coding standards manual with a requirement to update all Stored
Procedures to comply with the coding standards manual.

**87. Observation:** The underlying behavior of a Stored Procedure is
not being expressed in plain language. Maintainers should find, within
the header comments of Stored Procedures, plain language that describes
the function and flow of the Stored Procedure. (P) **\[Low\]**

**Recommendation:** Develop a coding standards manual mandating that all
Stored Procedures contain, within the header comments, plain language
that expresses the behavior of the Stored Procedure. Update all Stored
Procedures to comply with the coding standards manual. Ensure that the
program code review procedures include steps to verify compliance with
the coding standards manual.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been utilizing standard naming conventions with professional naming
for labeling of all stored procedures to include a definition of the
stored procedure. The Collections Team is developing a coding standards
manual which includes procedures to ensure that all Stored Procedures
contain, within the header comments, plain language that expresses the
behavior of the Stored Procedure. The completed manual is due by March
31, 1999.

**88. Observation:** Some Stored Procedures do not contain comments in
code to help in the understanding of the code. Comments within the body
of the Stored Procedure need to exist for identify logic flow and
function to assist maintainers in the change. (P) **\[Low\]**

**Recommendation:** Develop a coding standards manual mandating that all
Stored Procedures contain comments in code to facilitate understanding
the algorithm reflected in the software. Update all Stored Procedures to
comply with the coding standards manual. Ensure that the program code
review procedures include steps to verify compliance with the coding
standards manual.

**OMD/WTB Response:** Concur, the Collections Team will develop a coding
standards manual mandating that all Stored Procedures contain comments
in code to facilitate understanding the algorithm reflected in the
software. Updates to all Stored Procedures will comply with the coding
standards manual. The completed manual is due by March 31, 1999.

**89. Observation:** A standard layout format for Stored Procedures
could not be identified. (P) **\[Low\]**

**Recommendation:** Develop a coding standards manual mandating that all
Stored Procedures conform to a standard layout format and ensure that
the program code review procedures include steps to verify that Stored
Procedures conform to the standard layout format in the coding standards
manual.

**OMD/WTB Response:** Concur, the Collections Team will develop a coding
standards manual mandating that all Stored Procedures conform to a
standard layout format and ensure that the program code review
procedures include steps to verify that Stored Procedures conform to the
standard layout format in the coding standards manual. The completed
manual is due by March 31, 1999.

**90. Observation:** A consistent naming convention for Stored
Procedures could not be identified. (P) **\[Low\]**

**Recommendation:** Develop a coding standards manual mandating that all
Stored Procedures conform to a standard naming convention. Ensure that
the program code review procedures include steps to verify that Stored
Procedures conform to a standard naming convention as specified in the
coding standards manual.

**OMD/WTB Response:** Concur, the Collections Team will develop a coding
standards manual mandating that all Stored Procedures conform to a
standard naming convention. Ensure that the program code review
procedures include steps to verify that Stored Procedures conform to a
standard naming convention as specified in the coding standards manual.
The completed manual is due by March 31, 1999.

**91. Observation:** The Collection System Payments Narrative Processes
Breakdown documentation has numerous clerical errors, and lists many
processes that were missing or unaccounted for. (P) **\[Low\]**

**Recommendation:** The Commission should direct the contractor\'s
developing the Collection System to complete the documentation of the
existing processes listed in the Payment Process breakdown and make them
available to all users.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been documenting the entire Collections System\'s modules and
processes, including the Payment Process breakdown. The completed manual
will be available for all users in the second quarter of FY 1999.

**92. Observation:** The Collection System Payment Processes do not use
a standard format, and do not have clear cut step by step procedures. In
addition, insufficient information is provided within the content of the
process described. (P) **\[Low\]**

**Recommendation:** Establish a standard format that all processes will
be drafted by. Include in each process the objective of the process, why
the process is being done, who is responsible for the completion of the
process, when it is to be done, step by step procedures on how the
process is to be done, how the process is verified and validated, and
what the user does with the completed transaction.

**OMD/WTB Response:** Concur, the Collections Team, COTR and TPOC have
been establishing a standard format for all Collections System
processes. This includes the objective of the process, why the process
is being done, who is responsible for the completion of the process,
when it is to be done, step by step procedures on how the process is to
be done, how the process is verified and validated, and what the user
does with the completed transaction.

**93. Observation:** Non standard banking terminology was used in the
drafting of the processes, which could be misinterpreted. (P)
**\[Low\]**

**Recommendation:** Use standard banking terminology in the drafting of
all Collection System Payment Processes.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been using standard banking terminology in the drafting of all
Collection System Payment Processes.

**94. Observation:** Numerous processes have been drafted containing
little or no information at all. (P) **\[Low\]**

**Recommendation:** Establish a standard format that all processes will
be drafted by. Include in each process all information required to
complete that process.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has been working with the COTR and TPOC to establish a standard format
for drafting all processes.

*[Programming Related Matters]{.underline}*

Programming issues are systematic of not having or adhering to a System
Development Life Cycle (SDLC) methodology. Without the proper controls
built into the programming methods, programming code, and programming
processes, the entire application can be compromised and the desired
internal controls structures can also be more easily compromised. This
leads to more costs for the Commission to maintain the Collection System
in the long run without adherence to proper programming standards. New
releases of software can also make the maintainability of the Collection
System more difficult as the application may have to be re‑written each
time a new operating system or database software release is implemented
due to the way in which the program code has been effected and
documented. This could result in tremendous costs to the Commission.

**95. Observation:** The Data Dictionary contained several instances of
non‑professional language. (PO, SDLC) **\[Low\]**

**Recommendation:** Enforce good programming standards to ensure
professional language is used throughout the Data Dictionary.

**OMD/WTB Response:** Concur, over the past year the Collections Team
has followed good programming standards to ensure professional language
is used throughout the Data Dictionary. The Data Dictionary will be
updated on a quarterly basis until convergence to RAMIS.

The ITC also accepts this recommendation. Instructions to contractor
project managers will be promulgated and task COTRs will be shown how to
verify compliance.

**96. Observation:** The draft user manual dated 7/3/97 was given a
perfunctory review. There are several areas noted in which improvements
could be made: Cohesiveness of the document; Glossary of Terms;
Reflection of the actual functionality in the working environment;
Reflection of the modules in actual use; Financial Terminology. These
comments are in addition to the Collection System Users Guide Review
Report provided by the Billing and Collections Branch to the system
developers which states that the application is not in compliance with
OMB Circular A‑127. **\[Low\]**

**Recommendation:** A re‑write of the user manual should be performed,
if the application is to be retained to take into account the above
items.

**OMD/WTB Response:** New manuals and training guides will be prepared
for the new System.

**97. Observation:** All contract programming staff interviewed were new
( 3 months) to the Collections System project. This lack of corporate
history can be overcome through effective management of the project.
**\[Low\]**

**Recommendation:** The Commission take steps (e.g., establish key
personnel classifications) to ensure that changes to the staff be in
small increments allowing for the transfer of corporate knowledge.

**OMD/WTB Response:** Concur, the ITC accepts this recommendation and
will pursue with Acquisitions staff the development of appropriate
contract language to encourage the contractor firm to work towards this
goal.

Employee retention will be an issue for the new system as well,
particularly since only Civil Service temporary appointments are
available.

**98. Observation:** The schedules that were identified for enhancements
or development did not reflect any reviews or acceptance testing. (SDLC)
**\[Low\]**

**Recommendation:** Schedules should be developed to include
developmental lifecycle concepts of formal reviews.

**OMD/WTB Response:** Concur, current and future tasks will include
schedules to include developmental lifecycle concepts of formal reviews.

The SDLC under development will provide for and define the needed review
phases and efforts. Responsibilities for directing and participating in
these efforts will also be defined.

**99. Observation:** Formal acceptance criteria could not be identified.
(SDLC) **\[Low\]**

**Recommendation:** Formal acceptance criteria should be developed for
each task. Without formal acceptance criteria the developer has little
or no direction as it relates to the end product.

**OMD/WTB Response:** Concur, over the past year the Collection Team has
implemented formal acceptance criteria and procedures for software
in-products. Under the current Collection System and RAMIS, acceptance
testing criteria will be included in the Project Test Plan.

The ITC is examining alternatives that might improve the acceptance
process by employing a separate contractor to develop acceptance
criteria, develop test data and test plans, and to participate along
with FCC staff in the acceptance testing process.

**100. Observation:** Of the weekly and monthly status reports provided,
there does not seem to be a logical progression and resolution of tasks
as they are assigned or discussed. Items which are scheduled for the
next reporting period are not always addressed as to their status in the
next reporting period. (PI) **\[Low\]**

**Recommendation:** In presenting the status reports, The contractor
should be directed to indicate the resolution of the items indicated as
planned to be worked on during the reporting period at hand.

**OMD/WTB Response:** Concur, over the past year the status reports,
provided to the COTR include resolution of the items indicated as
planned to be worked on during the reporting period at hand.

The ITC also accepts this recommendation. This subject will be discussed
at the monthly COTR meetings and task COTRs will be encouraged to
require their contractors to comply.

**101. Observation:** Vague narrative was contained in a monthly status
report wherein the Projected Completion Date was stated as indefinite.
**\[Low\]**

**Recommendation:** The Commission should direct Collection System
contractor\'s to include only specific language in official documents.

**OMD/WTB Response:** Concur, the ITC accepts this recommendation as it
applies to all PSC work. This subject will be discussed at the monthly
COTR meetings and task COTRs will be encouraged to require their
contractors to comply.

**102. Observation:** There is no standardized header format and no
overall standardized format for all C programs and shell scripts
reviewed. **\[Low\]**

**Recommendation:** Establish a standardized header format for all C
programs and shell scripts.

**OMD/WTB Response:** Concur, Changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**103. Observation:** There are no comments written within the code for
C programs and shell scripts. Functions are not identified or expressed
in plain language. **\[Low\]**

**Recommendation:** Include comments in the code that identify the
individual functions in plain language, and comments that describe what
function the code is executing.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**104. Observation:** There are no comments in the header to describe
the code nor identify for C programs and shell scripts modifications to
the code as to who made the modification and when. **\[Low\]**

**Recommendation:** Develop and implement a standardized header format
for C programs and shell scripts that will include comments in the
header to describe the code, and identify modifications to the code as
to who made the modification and when.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**105. Observation:** Functions have no headers, no comments, or
underlying behavior statements to assist in the maintenance of the code
for C programs and shell scripts. **\[Low\]**

**Recommendation:** Develop and implement a standardized header format
that will include headers, comments in the header, and underlying
behavior statements to assist in the maintenance of the code.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**106. Observation:** There are no variable or constant declaration
statements in the C programs or shell scripts. **\[Low\]**

**Recommendation:** All programs contain sufficient statements and/or
comments as to how variables and constants are being used throughout the
code for Powerbuilder programs.

**OMD/WTB Response:** Concur, the ITC accepts this recommendation.
Changes in ITC contracts for Sybase, PowerBuilder and web support staff
now being made will permit these contractors to work with FCC staff to
develop programming standards for the basic languages in use at the FCC.
These standards will be promulgated and their use by PSC staff verified.

**107. Observation:** A standardized naming convention is undefined for
C programs and shell scripts. **\[Low\]**

**Recommendation:** Establish a standard naming convention that all C
programs and shell scripts will be drafted by.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**108. Observation:** There is no standardized header format and no
overall standardized format for all Powerbuilder programs and scripts
reviewed. **\[Low\]**

**Recommendation:** Develop and implement one overall standard format
and a standardized header format and create all Powerbuilder programs
and scripts in accordance with the agreed upon formats.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**109. Observation:** There are no comments in the header to describe
the code and identify modifications to the code as to who made the
modification and when for the Powerbuilder programs. **\[Low\]**

**Recommendation**: Develop and implement a standardized header format
that will include comments in the header to describe the code, and
identify modifications to the code as to who made the modification and
when for the Powerbuilder programs.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**110. Observation:** There are no comments written within the code for
Powerbuilder programs. Functions are not identified or expressed in
plain language. **\[Low\]**

**Recommendation:** Include comments in the code that identify the
individual functions in plain language, and comments that describe what
function the code is executing for Powerbuilder programs.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**111. Observation:** Functions have no header, no comments, or
underlying behavior statements to assist in the maintenance of the code
for Powerbuilder programs. **\[Low\]**

**Recommendation:** Develop and implement a standardized header format
that will include headers, comments in the header, and underlying
behavior statements to assist in the maintenance of the code for
Powerbuilder programs.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

**112. Observation:** There are no variable or constant declaration
statements in the programs or scripts for Powerbuilder. **\[Low\]**

**Recommendation:** All Powerbuilder programs contain sufficient
statements and/or comments as to how variables and constants are being
used throughout the code.

**OMD/WTB Response:** Concur, the ITC accepts this recommendation.
Changes in ITC contracts for Sybase, PowerBuilder and web support staff
now being made will permit these contractors to work with FCC staff to
develop programming standards for the basic languages in use at the FCC.
These standards will be promulgated and their use by PSC staff verified.

**113. Observation:** A standardized naming convention for Powerbuilder
programs is undefined. **\[Low\]**

**Recommendation:** Establish a standard naming convention that all
Powerbuilder programs and scripts will be drafted by. Include the
identification of the naming convention in the Powerbuilder program or
script.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified. RAMIS will establish a
standard naming convention that all Powerbuilder programs and scripts
will be drafted by. Include the identification of the naming convention
in the Powerbuilder program or script.

**114. Observation:** Blocks of code exist that contain no comments as
to their function, no headers, no naming convention, no declaration
statements, or statements that assist in the maintenance of the code for
Powerbuilder programs. **\[Low\]**

**Recommendation:** Develop and implement one overall standard format
and a standardized header format and create all Powerbuilder programs
and scripts in accordance with the agreed upon formats. Include comments
in the code that identify the individual functions in plain language,
and comments that describe what function the code is executing.
Establish a standard naming convention that all programs and scripts
will be drafted by. Include the identification of the naming convention
in the program or script.

**OMD/WTB Response:** Concur, changes in ITC contracts for Sybase,
PowerBuilder and web support staff now being made will permit these
contractors to work with FCC staff to develop programming standards for
the basic languages in use at the FCC. These standards will be
promulgated and their use by PSC staff verified.

*[Process Improvement Matters]{.underline}*

During the review, several areas were noted in which the processes, if
engineered in a different manner, could result in more efficient and
less costly operations for the Commission. When identifying areas for
process improvement, the ideal basis is to concentrate on single sources
of information, singles sources of input, and single sources of
processing. So as not to cause redundancy, inefficiency, and result in
more costs to the entities involved.

**115. Observation:** During the review of functionality requirements
and system requirements, it was evident that not all users of the
Collection System information had been involved during the design of the
Collection System. In order to design effective accounting and
management information systems, it is imperative that all users have
input into the process in order for the system to become a functional
system used throughout the Commission. (SDLC) **\[Low\]**

**Recommendation:** Revise development procedures to ensure the
opportunity for all users communities to be involved in the design and
testing of the application.

**OMD/WTB Response:** Concur, RAMIS will revise development procedures
to ensure the opportunity for all users communities to be involved in
the design and testing of the application. The Project Plan will include
tasks for workflow analyses, data and reporting needs, and focus groups
about the new system. The steering committees should consist of
representatives from all of the Bureaus and Offices who are
stakeholders.

**116. Observation:** While significant volumes of information on user
requirements exist, there is no one cohesive user requirement document
or formal procedures for tracking to ensure implementation or
disposition of a user requirement. In addition, the user requirements
were never turned into functional requirements and placed into more
programmable requirements, resulting in the achievement of only 30% of
the intended functionality. Without the documented user requirements and
functional requirements, the business process improvements are never
programmed and therefore the automation does not help make the processes
more efficient. (SDLC) **\[Low\]**

**Recommendation:** When undertaking development efforts, a full user
requirements and functional requirements analysis should be performed in
order to prepare the requirements analysis document from which the
program plan maybe generated. In addition, a formal method for tracking
the user requirements through to implementation or disposition should be
implemented.

**OMD/WTB Response:** Concur, the Project Manager recommends that, to
the extent possible, all procedures and processes be changed to use the
capabilities of the COTS package selected. The requirements analyses
will provide the basis for developing the RFP, identifying BPR areas,
developing the OCD tests, and developing the evaluation criteria.

**117. Observation:** The Collection System Wireless department users
have a need for intraday information from Mellon Bank during auction
programs. The requirements as defined require the use of another form
(Form 159) to be input as wires and checks are received instead of using
currently available technology. **\[Low\]**

**Recommendation:** Require electronic intraday bank reporting be used
with any Collection System put in place at the FCC.

**OMD/WTB Response:** Concur, a requirement will be included in the RFP
that either unique data records be imported while the system is in
production or that remote entry be available.

**118. Observation:** At the time our review was completed, plans were
being considered in which three separate data feeds would be required
from Mellon bank. **\[Low\]**

**Recommendation:** The Commission should recognize the risks associated
with duplicate data feeds and consider eliminating this practice.

**OMD/WTB Response:** Concur, this will be considered under the RAMIS
\"Requirements Analysis\". Further, Nortridge (or other loan management
system data) will be treated as a subsidiary ledger with daily, weekly
and monthly updates to the central revenue system.

**119. Observation:** The Collection System requirements did not
automate the information for returned checks (also known in the banking
industry as returned items). **\[Low\]**

**Recommendation:** Returned items information should be returned
electronically from Mellon Bank in order to automatically populate the
Collection System and take the automated appropriate actions as a result
of the returned items.

**OMD/WTB Response:** Concur, the new system will require that returned
check data be included in the electronic feed from the servicing bank.

**120. Observation:** FCC has no common data dictionary for programming
efforts. (PO) **\[Low\]**

**Recommendation:** Develop a Commission‑wide common data dictionary,
which will allow for more efficient programming efforts and sharing on
information among applications. This common data dictionary should also
make use of standardized data elements, data fill, and data
interoperability.

**OMD/WTB Response:** Concur, RAMIS will develop a Commission-wide
common data dictionary, which will allow for more efficient programming
efforts and sharing on information among applications. This common data
dictionary will also make use of standardized data elements, data fill,
and data interoperability.

**121. Observation:** The developer has not adopted an engineering
approach to developing software. (SDLC) **\[Low\]**

**Recommendation:** The contractor should be directed to implement
software development standards. In addition the contractor should train
their developers on how to professionally develop software.

**OMD/WTB Response:** Concur, over the past year the Collections Team
programmers have implemented and followed software development
standards. The programmers have been professionally developing software
for the Collections System.

**122. Observation:** The contractor is not engineering this system.
This results in the project having no characteristics of an engineering
effort. The project has separated from the requirements and is moving
forward reacting to the current issues. **\[Low\]**

**Recommendation:** No new work requirements should be developed until
an appropriate or formalized engineering structure is established.

**OMD/WTB Response:** Concur, under RAMIS new work requirements will be
developed following an established or formalized engineering structure.

**123. Observation:** The costs of the existing Collection System are
far greater than the costs of a COTS package implementation. In
addition, the existing Collection System contains less than 30% of the
desired functionality whereas the COTS packages contain 80% to 90% of
the desired functionality. (SDLC) **\[High\]**

**Recommendation:** Abandon the in‑house developed Collection System
solution and migrate towards a COTS package.

**OMD/WTB Response:** Concur, however, the current system must be
maintained until a COTS solution is identified, tested and implemented.

*[Policy and Procedures Issues]{.underline}*

These comments relate to specific instances in which adherence to a
specific policy was not followed or in which a specific manual process
is followed for which no formal documented policy exists.

**124. Observation:** Adherence to a System Development Life Cycle
(SDLC) methodology from system design to system implementation was not
apparent. Documents expected through the adherence to any type of SDLC
were neither prepared nor readily available. Use of a SDLC methodology
will help ensure the system is properly designed (whether Commercial Off
the Shelf (COTS) or in-house developed (IHD)), documented, programmed,
implemented, and users are properly trained. This also helps to ensure
the system is maintainable with the minimum amount of resources.
**\[Low\]**

**Recommendation:** Whether contractor support or FCC personnel, use of
a SDLC should be mandatory and measured to ensure a SDLC is being used.

**OMD/WTB Response:** Concur, an FCC SDLC will be developed.

**125. Observation:** During the data integrity review, many
transactions with payment type code \>ZZZ= or \>ZZZZ= were noted. No
formal procedures for reclassifying these transactions to their
appropriate payment type code exist. Without the proper payment type
code classification, the correct service type has not been identified.
**\[Low\]**

**Recommendation:** Establish formal processing procedures for
reclassifying AZZZ= and \>ZZZZ= transactions to their appropriate
payment type code.

**OMD/WTB Response:** Concur, formal processing standards shall be
developed by, or before, October 31, 1998.

**126. Observation:** The transmission between the FCC and Mellon Bank
is over open and clear telephone lines without any encryption.
**\[High\]**

**Recommendation:** Implement encryption technology for the Mellon Bank
transmission.

**OMD/WTB Response:** Concur, the implement of encryption technology for
the servicing bank transmission will be reviewed as part of RAMIS.

*[SDLC - Life Cycle Development Issues]{.underline}*

OMB Guidance specifically recommends adherence to a System Development
Life Cycle methodology, whether for newly developed or for the
enhancements of existing applications. Specific comments regarding the
adherence to any SDLC methodology are indicated to emphasize the
importance of the need for adherence to a SDLC. Without the use of and
adherence to a SDLC methodology, the end application may result in
pieces which are not easily maintainable, are costly to maintain, and
which do not function as desired by the

**127. Observation:** Throughout the evolution of the Collection System
and the processes used by Mellon Bank, the Commission has failed to
fully explore commercially available options. In addition, a feasibility
analysis of available options has not been performed. **\[Low\]**

**Recommendation:** A documented feasibility analysis should be
performed any time a new system or application is being considered. The
Commission should ensure that any methodology used to develop Commission
information systems includes a requirement for conducting a feasibility
analysis.

**OMD/WTB Response:** Concur, the FCC has already decided to develop and
implement a new system based upon a COTS package. Future information
system enhancements will follow a SDLC which includes feasibility
analyses.

**128. Observation:** The User Manual reads like an automated paper
process. The Collection System did not automate or make more efficient
the business processes, but instead placed those manual processes on the
computer. **\[Low\]**

**Recommendation:** The business processes for Money Collection should
be reviewed and streamlined in order to make the process less time
consuming, more accurate, and more efficient. Moving towards a more
COTS‑oriented package will not prove beneficial unless the business
processes themselves are evaluated and improved.

**OMD/WTB Response:** Concur, OMD will review the business processes for
Money Collection. This review will be conducted in unison with the
development of the new system.

**F. DETAILED RECOMMENDATIONS PHASE II**

The Ernst & Young results of the Phase II portion of the review are
encompassed in this detailed recommendations section. Ernst & Young\'s
complete report is included in its entirety as Appendix A of this
report.

In summary, the E&Y report noted the FCC did not provide source data for
fifty-two (52) of the one-thousand six-hundred ninety-five (1695)
transactions selected. There were seven-hundred eleven (711) instances
in which the data contained in the collections system differed from the
source documents provided, most of which related to discrepancies in
non-monetary fields. The differences include discrepancies in dates of
payment receipt, payor names and addresses, amounts, FCC fee control
numbers, FCC account numbers, payment type codes and payment methods. Of
the seven-hundred eleven (711) instances noted, thirty-three (33)
instances were sample items totaling approximately \$39 million related
to discrepancies in monetary amounts or instances where no check or wire
slip could be located to substantiate the transaction. One (1) item
represented an auction-related transaction where the discrepancy between
the bank wire and the Collection System extract totaled \$87,435.

In addition, the collections system allows transaction information to be
updated without necessarily creating and retaining an audit trail. E&Y
also noted a need to reconcile information included in the data extract
with amounts reflected in the FCC general ledger, and to reconcile the
total deposits and disbursements in FCC cash accounts to such amounts as
well.

What isn\'t stated in the E&Y report is the elongated duration of time
incurred to obtain documents to support the transactions. In addition,
there is not a mention of the significant analysis time spent to
determine how to agree documents, once obtained, to the transactions
they are supposed to represent. Both of these represent the need for
extensive improvement in the areas of record keeping and audit trails
for transactions recorded in the Collection System.

Appendix A contains the detailed E&Y report as well as the schedules
supporting their report. E&Y also included, at the request of FCC
Management, recommendations on observations they made during the course
of the Agree-Upon Procedures. These are also included in Appendix A.

**OMD/WTB Response:** Concur, a monthly proof of cash has been
implemented to assure that dollars are reconciled.

We agree to make improvements in record keeping and audit trails.

**G. OVERALL CONCLUSIONS**

The Commission\'s Collection System application does not meet OMB
guidance as it relates to segregation of duties, accountability within
the application, adequacy of preparedness for contingency planning, and
overall access controls. In addition, after over five years of
development effort the Collection System provides less than 30% of
desired functionality. The data contained in the Collection System is
not fully supported for dates of the transaction, payor, addresses,
payment type codes, or other related fields. Amounts are supported,
except for the ten thousand (10,000+) plus duplicated transactions
contained in the database.

Based on the above, the Team recommends an abandonment of the existing
Collection System development effort. Funds to be used for development
should be moved towards the selection and implementation of a COTS
package for processing incoming payments to the FCC.

Concurrent with abandonment of the existing system, overall controls
should be strengthened while moving towards the new system. The
Commission should: formalize the Systems Development Life Cycle (SDLC)
process; implement proper logical and physical segregation of duties;
implement proper security administration of userids; establish formal
roles and responsibilities; establish logical segregation of developers
from security and application functions; and formalize the change
management process.