FUNCTIONAL EVALUATION OF MANAGEMENT SCIENCE AMERICA SOFTWARE

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP90-00191R000100080020-3
• Release Decision: RIPPUB
• Original Classification: K
• Document Page Count: 39
• Document Creation Date: December 23, 2016
• Document Release Date: August 5, 2013
• Sequence Number: 20
• Publication Date: September 8, 1986
• Content Type: REPORT

Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTIONAL EVALUATION
OF
MANAGEMENT SCIENCE AMERICA SOFTWARE
Prepared By The
COMMERICAL 'LOGISTICS APPLICATION SYSTEM
(CLAS) PROGRAM TEAM
8 September 1986
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
SUBJECT
PAGE
OVERVIEW
1
CATALOGING
3
REQUISITIONING
INVENTORY SYSTEM
8
RECEIVING
10
DISTRIBUTION
12
POLICY HE IRARCHY
14
PREAWARD
18
PREPARATION OF PROCUREMENT DOCUMENTATION
21
POST AWARD
25
VENDOR PAYMENT
27
MANAGEMENT INFORMATION
32
APPROVALS
33
POSSIBLE/PROBABLE MODIFICATIONS
35
TERMINALS
37
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
OVERVIEW
CAPABILITIES:
The MSA system was matched loosely with the functional
processes represented by existing CONIF and ICS systems and
manual procedures and regulations currently in effect. The
system was also measured against the approved LIMS Objectives
and Requirements dating from 1983.
The MSA system appears to support those requirements
represented by the materiel system. That is, it will handle
supply requisitions (Form 88) and fixed price procurement. The
materiel system, as defined, represents approximately 701 of the
transactions flowing through the Logistics system.
In support of the materiel system, the MSA software provides
the following capabilities:
Electronic requisitioning. The customer has access to the
catalog database, can enter multi-line item requisitions
complete with special handling and remarks, and transmit items
to the appropriate item manager or buying activity.
Procurement support. The buyer has access on screen to all
requisition data, to item purchase history, vendor history, and
quotation analysis. The system sets up and prints RFQ/RFP and
purchase documents.
Receiving. Tile receiving inspector has on-screen access to
the purchase document and, if needed, the requisition document.
Depot Processing. MSA reports capabilities can generate
depot movement documentation which can serve to track material
through the depot and be used as a packing list.
Vendor Payment. MSA provides for on-line ma.tching of
purchase, receipt, and invoice data and on-line certification
for payment.
Inventory Control. The system generates daily reports of
re-order point penetrations, demand analysis reporting, and
on-line replenishment requisitions. The system supports a
variety of inventory count cycles. If desired, the system can
be used to track recurring demand.
MODIFICATIONS:
To accomplish the above, some modifications will be required
to enable the purchasing system to handle all requisitions
(stock issues, direct procurement, and service requests) and to
structure data collection for requisition header information and
procurement management information.
-1-
nprdaccified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTIONAL LIMITATIONS:
No effort has been made to assess the capabilities of the
MSA system to support financial transactions or interfaces,
primarily because of uncertainty regarding how Agency financial
systems will be configured. The technical evaluation concluded
that interfacing between MSA systems and the Cullinet General
Ledger system are practical and simple.
The system does not support other than simple approvals.
For practical purposes, approvals must be obtained off-line.
It is not immediately clear that the MSA system can handle
complex cost type contracts. Further investigations are
underway, more will be required, and custom development to meet
contract requirements is a possibility.
Concern has been expressed regarding limitations in the MSA
system's handling of multiple vendor addresses and multiple
addresses used by Agency procurement organizations. One of the
modifications being investigated would alleviate the problem
with procurement addresses.
CONCERNS:
The team still has concerns regarding the ability and
willingness of the Logistics organization to adapt to MSA system
constraints, or to adopt the work efficiencies proposed by the
LIMS program.
System security has not been examined closely. Users can be
restricted to specific-screens, but all data can be viewed from
that screen --- there is no segregation of the data base by
users.
RECOMMENDATIONS:
1. Permit review of the evaluation by Logistics
organizations external to the CLAS Program and solicit guidance
regarding directions for further development.
2. Barring major reservations by Logistics organizations,
endorse the use of MSA software to the D/OIT.
3. Assuming OL and OIT agreement to proceed with MSA, seek
commitment from the Office of Finance on implementation of the
Accounts Payable (Vendor Payment) package and establish ground
rules for exploring interfaces to the General Ledger and
Budgetary systems.
4. With concurrence to proceed with CLAS, initiate
acquisition of "production" versions of MSA software:
Manufacturing 6.4, Purchasing 2.0, and Accounts Payable 5.0.
These versions are either no cost, or full credit is granted for
current versions.
-2-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: CATALOGING
1. DESCRIPTION OF THE MSA SYSTEM
MSA Cataloging Functions are accomplished with the ITEM
MASTER file in the manufacturing system and the ITEM DEFINITION
file of the purchasing system. The ITEM MASTER file contains
the items definitions (stock number, description, unit of issue,
acquisition cost, issue price, stock levels, safety levels,
reorder points, substitute stock number, and the item manager)
for stocked items. The ITEM DEFINITION file contains the "as
purchased" description of items that are stocked, standard items
not stocked (recurring), and GENERIC. Generic descriptions
permit actual customer descriptions to be captured for one-time
purchases. The system provides a number of user defined fields
suitable for data capture; there is no processing logic
associated with these fields.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
A. The MSA data element for STOCK NUMBER has fifteen
characters versus thirteen for the Inventory Control System
(ICS). Each stock number in the current system is managed
by location, sterility, allocation, and condition (LSAC) and
the MSA system does not support this requirement. A
non-data processing solution to this would be to replace the
stock number as the key field with the model/part number
coupled with the LSAC (EX: PRT 250 914 1 00 A, DESKMDLA 903
0 00 1 B). This approach requires conversion of all
existing stock numbers and treats each LSAC as an entirely
different item. We have not explored the possibility of
adding new data elements and program logic to support our
present management system.
B. The MSA catalog function has virtually unlimited free
text capability for recording item descriptions. ICS
provides 306 characters. Most MSA standard reports reflect
only 20 characters.
C. The SHORT NAME LOOKUP feature permits researchers to
cross-reference up to eleven multiple noun
names/stock/part/model numbers for each stock number.
-3-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
3, PROCEDURAL IMPACT
A. Workload
Aside from initial conversion efforts, we se6_no
significant changes in the effort required to create or
update a catalog entry for stock items. Use of the GENERIC
description feature may diminish the ability to track
recurring demand, but would simplify and reduce data entry
and memory requirements.
B. Policy/Responsibilities
Catalog entries may be made by cognizant offices for
stocked items, and by originating offices for repetitive
direct procurement requests.
. COMMENTS
The MSA system has a BILL OF MATERIALS feature that links
component parts with end items. Although not investigated yet,
we see potential here for technical offices to manage equipment
systems.
-4-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: REQUISITIONS
1. DESCRIPTION OF THE MSA SYSTEM
A. MSA has requisition functions in both the manufacturing
and purchasing packages. It is proposed that an interface
be developed between the two packages to permit all customer
requests to be entered in the purchasing package.
B. Requisitions for stock issues, directs or services
are input via menu. When the requisition process is
complete, the requisition is immediately available for
procurement action or depot issue.
C. Requisitions for stock replenishments are not input on
the requisition menu but on an inventory menu. When the
item manager enters the information on this menu, the system
automatically creates a requisition record for procurement
action.
D. Query menus are available for tracking requisitions or
obtaining status information based on a single element such
as requisition number, customer name or office, stock number
or on a combination of these elements.
E. Once the requisition has been entered, only certain data
elements such as the buyer, item description and the
information in the requisition comments menu (special
instructions, consignee, extended item description) can be
amended before procurement action is initiated. After
procurement action has been initiated, no requisition data
can be amended except the information in the requisition
comments menu. The requisition quantity, price, item number
and required date can not be amended. Requisition data that
can not be amended or data that must be changed after
procurement action has been initiated must be cancelled and
re-entered.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
A. The MSA requisition number field is 10 characters. This
satisfies our service requests. However, requisition
requests for material use a 12 digit number. This problem
may be solved by modifying our requisition number to 10
digits as follows:
CUSTOMER FISCAL JULIAN SEQUENCE
NUMBER YEAR DATE NUMBER
-- -7 6 365 01
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
B. Our present system uses numerous transaction codes to
process specific financial/inventory adjustments. Although
the MSA system does have transaction codes, there are a
number of transactions in our present system (sale to other
government -agency) that are not directly supported by MSA.
C. The MSA requisition requires the customer (originator)
to identify and input the appropriate purchasing
organization for each line item. Our present system does
not require that the customer make this determination.
D. The MSA system provides each requisition with a one step
approval process that is performed on-line. Our present
approval process is 3 steps (approving officer, tech
approval, budget approval) and is handwritten on the Form 88.
3. PROCEDURAL IMPACT
A. Workload:
The MSA system encourages all requisition requests
(direct purchases, stock issues, services, replenishments)
be input by the customer since all requisitj.on information
is available on-line and actton requirements are sent
electronically. This would virtually eliminate the
requirement to type, reproduce and file hard copy
requisitions. There would be no requirement to submit the
hard copy requisitions for subsequent input bySMB which
would provide.SMB with more time to manage stock items and
analyze direct buys for repetitive purchases. The CONIF
workload would also decrease because the requisition data
would not have to be re-entered into the CONIF system. This
would provide CONIF personnel with more time to manage the
contracting data and create reports.
B. Policy/Responsibilities:
The concept of electronic requisitions is supported by
MSA. Implicit in that concept is the shift of
responsibiltty from SMB to requisitioning officers to
research and input data and to ensure the accuracy of the
data. The short name look up feature provides the customer
with an extensive research tool for making this
determination. It is anticipated that the originator (a
Logistics careerist or someone under the supervision of a
Logistics careerist) will make the original assignment to
the appropriate purchasing activity.
Ma.
npriaccifiari in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
4. COMMENTS
A. If the incorrect purchasing oranization is used by the
customer, the requisition must be cancelled and re-input.
We are exploring two solutions (modification to allow
changes to the buying entity code or use of the buyer code
in lieu of the buying entity code) to allow reassignment of
purchase actions.
B. A system modification is needed to link the purchasing
requisition functions with the manufacturing inventory
functions. However, it is not certain at this time what
type of change this will require.
C. There are two proposals for including additional
information (extended consignee, special instructions) on
the requisition:
To utilize the requisition comments menu which is
designed for the customer to input notes regarding
the requisition. However, this menu appears as a
page of blank lines and has no structured format to
separate the special information (procurement
instructions, shipping instructions etc.)
0 To create a new formatted menu for the customers
special information.
D. Because the MSA system provides only a one step approval
process, our current method of approval would have to change
to comply with MSA or the MSA system would have to be
modified to allow more than one approval.
E. The MSA system provides the customer with easy methods
for inputting, recording and querying a requisition. If
customers are permitted to enter their requests, the
response time for direct requisitions would improve because
the system passes the requisition immediately to procurement
and the processing time would improve for all requisitions
because they would no longer be mailed to SMB.
F. We have not explored access to and use of the system
history files.
-7-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: INVENTORY SYSTEM
1. DESCRIPTION OF THE MSA SYSTEM:
The MSA Inventory System provides each stock item with a
unique Inventory Records which lists:
o Multiple Warehouse locations and the Quantities available
at each location.
O Total Quantity On-hand for each item
O Total Quantity Due-in
O Total Quantity Due-out
O Item description
O Inventory Control settings (reorder point)
O Item Manager
MSA provides the choice of conducting inventories annually,
by predefined time cycle or by Warehouse Area.
All stock replenishments are input via Menu by the item
Manager. When the Menu is entered the System uses this
information combined with the information from the Item Master
to automatically create a requisition for Procurement action.
All Inventory maintenance (adjustments, returns, item
transfers) is processed on specific Inventory Menus. Some of
the standard query Menus are:
o Inventory By Stock Item (Lists Inventory Locations and
Quantity On Hand by Stock item.)
o Inventory by Warehouse (Lists all the stock items
stored in a particuliar warehouse).
o Stock Status by Stock item (Very similiar to the
present Stock Status Report in ICS).
-8-
npclassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
All stock issues are placed in-process using a separate
allocation Menu which is recorded in a Batch mode. This
includes manually allocating a substitute stock item when the
primary stock has been depleted and all back order releases
when the stock item has been received. Our present stock
issues are placed in-process the moment the requisition is
input or when receiving has been input.
Much of the Information required by an Item Manager is
available using the standard query Menus.
The MSA query Menus can provide a list of all warehouse
locations for each stock item and the quantity stored in each
of these warehouse locations. The ICS does not provide this
breakdown of quantities in each location but only a combined
total quantity on-hand per item.
3. PROCEDURAL IMPACT
A. Workload
The Inventory Managers workload would change as follows:
1. A decrease would occur because all the requisitions
will be input by the customers. Their workload-would also
become easier to process and maintain since all replenishments
can be input directly on-line instead of using the form 1245.
2. An Increase would occur because all stock issues would
have to be manually allocated. We anticipate a system
modification to automate the allocation process.
B. Policy/Responsibilities
The MSA System permits and encourages the on-line
initiation of replenishment requisitions by the Items Manager.
This may result-in individual cognizant offices absorbing this
work.
4. COMMENTS
Since the Purchasing Requisition function will be used for
ordering stock items from Inventory, it is unknown how the
purchasing requisition files will ffect the Inventory files
because there is no direct link currently available between
these two files.
(a.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: RECEIVING
1. DESCRIPTION OF THE MSA SYSTEM
A. The MSA receiving process encourages a paperless
environment while maintaining receipts integrity. Receipt
controls (late or early delivery, wrong delivery point,
variance in quantity) established within the Purchasing
Hierarchy monitor receipts and vendor performance and
provide appropriate warnings or exceptions reports.
B. Receiving clerks access the appropriate purchase order
electronically and input receiving data directly on line.
Purchase order status is updated and receipt information
recorded. Receipts for stock replenishments require a
separate transaction to update inventory records
C. The system provides search capabilities for vendor
name, vendor numbers, part number and purchase order
number for unidentified receipts. Discrepant receipts are
placed on hold pending final resolution. An authorization
code, controlled by system security, permits only
authorized individuals to override system exceptions such
as overages. All exceptions authorized are reported to
the corresponding procurement official.
D. Returns to Vendors and receipt amendment capabilities
are also provided.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
The present receiving process is totally dependent on hard
copy documentation (form 88, purchase order, amendments) while
the MSA process supports a paperless environment. Receiving
procedures presently consist of a receipt verification on the
loading dock and an additional administrative review within the
receiving office. Documentation is consolidated into a package
for depot processing and returned to the receiving dock for
movement. The MSA system provides an electronic copy of the
purchase order on line. Normal receivings only require that the
purchase order be displayed and receipt information recorded in
menu format. Copies of requisitions are also available
electronically if required.
-10-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
3. PROCEDURAL IMPACT
A. Workload
The maintenance of the Supply Action Files will be
reduced significantly and the time and effort required to
process a receipt will be reduced. The matching of
hardcopy requisitions to the purchase orders will no
longer be required nor will the copies of these documents
be required for distribution.. Individuals will be
available for other more productive work assignments
related to the receiving process.
B. Policy/responsibilities
The responsibility for physical inspection and any
required preparation/matching of documentation could be
directed to one responsible individual. The preparation,
matching, reproduction, filing and administrative review
of receipt documentation should be reduced significantly
thus providing the receipt clerk the opportunity to focus
on the actual receipt verificationeThe MSA system
encourages and supports a one-stop paperless receiving
process while providing electronic copies of documents for
review if required.
4. COMMENTS
A. The primary source of receipt verification will be the
purchase document. Receipt are matched/verified in
accordance with the vendors packing list and the
descriptive data provided on the electronically displayed
purchase document.
B. Purchase orders prepared for incorrect material will
not be detected within the receiving process. The
potential exists that a customer could receive an
incorrect item if the requester's item description is
erroneously changed or modified by the procurement
official. This potential is extremely limited but
possible. Initially, receiving clerks could review the
original description as entered by the customer until a
degree of confidence is developed.
C. The normal receipt process could be reduced from
several days to minutes. The on-line accessibility of the
purchase order will provide a more efficient method of
recording receipt information and subsequent system
updates.
-11-
npclassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: DISTRIBUTION
1. DESCRIPTION OF MSA SYSTEM
A. The MSA system provides the capabilities to accomplish
the following warehouse operational type functions.
B. Pre-definition of item inspection requirements of
stocked items, to facilitate proper routing at the time of
receipt from the vendor.
C. Recording inspection activities.
D. Generation of a issue/movement document for items to
be pulled from stock. This document can be grouped by
requisition or by warehouse location sequence.
E. Recording the shipment of stocked items.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
A. The MSA system does not provide hard copy
documentation for the movement of non-stocked material
through the warehouse and the document it
provides for stocked items does not
provide some critical information that is
necessary for processing. It is planned
to create a movement document for both
types of items. The planned document, to
be provided by MSA, will consolidate all
the necessary processing information (DCN,
complete item descriptions, quantity,
special instructions, addresses, etc.)
onto one document versus today's
multi-document moltement package (receiving
report, original requisition, requisition
amendmentsldepot issue notice).
B. Does not directly provide for tracking non-stocked
items pas_t the point of receipt inspection.
3. PROCEDURAL IMPACT
A. Workload
SMB and Depot reproduction, tracking and filing
requirements would be sharply reduced since the
information (special instructions, addresses, complete
item descriptions, receiving data) not stored in the
inventory control system will be online in MSA's system.
For the Depot, the need to assemble packets of receiving
reports and requisitions is eliminated.
-12-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Storekeepers would record the pulling of items from
stock. This supportsAnhanced depot tracking.
The receipt transaction for stock replenishments does
not automatically add the items to stock. An additional
transaction would be required to update the inventory.
When storing stock, the storekeeper will have to record
the quantity being stored in each location, not just the
total quantity.
B. Policy/Responsibilities
4. COMMENTS
A. Recording of some of the Depot tracking activities is
not directly provided for. .1%2%, inspection data for items
pulled from stock, packing data, shipment data for
non-stocked items. It is intended that this data will be
stored in the requisition file, utilizing either the
requisition comments screen ox a new screen.
B. Although the MSA system does provide a transaction to
record the shipment of stock items, it does not accommodate
non-stocked items. A system modification to- cover both
types of items is needed, and should be addressed as part of
the Depot tracking capability.
C. MSA's system provides the capability to capture the
date, quantity and warehouse location of the material issued
from stock. This feature provides customers and managers
with an improved method of requisition tracking, reporting
and expediting as well as providing significant time saving
improvements in our current inventory, procedures.
D. Provides Depot management with the ability to better
manage space utilization by providing visibility of empty or
under utilized storage locations.
E. At this point we have not addressed how the present or
future bar coding functions will interface with MSA
software. It should be noted that there are two companies
who are presently working with MSA on bar coding.
F. The handling of lot storage, shipping purposes only,
property turn-in and repair and return activities have not
yet been fully explored.
-13-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: POLICY HIERACHY
1. DESCRIPTION OF THE MSA SYSTEM
The MSA System's Policy Hierachy is a default hierachy
matrix of standardized procurement terms and controls. Policy
data does not have to be rekeyed for each requisition, request
for quotation, and procurement instrument and the matrix tells
the system how to handle each action during the procurement
cycle. The buyer has the option to override the data defined in
the matrix at the quotation and procurement instrument levels.
Through the decision tree the terms and controls are specified
for the following:
A. All activities within a specific procurement unit.
(highest level)
B. A single buyer within a procurement unit.
C. A single vendor.
D. A single item within the item master.
E. A vendor quotation terms.
F. A single item on a vendor quotation.
G. A single procurement instrument.
H. A single order line of a procurement instrument.
(lowest level)
When processing, the system will use information from ?the
lowest available level. If data is not available at the detail
level, the system will default toward the highest level. Data
entered at a lower level will always override data entered at
any higher level. ?
The MSA System has twenty seven (27) screens for the initial
input of data to define:
A. Procurement organizational structure.
B. Terms and controls for ordering and receiving
goods/services.
C. Codes and descriptive processing information which are
used by the system.
-14-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Also there are thirteen (13) screens for inquiring about
policies, buyers, requesters, and codes.
A buying entity is an organizational unit responsible for
the procurement of goods and/or services. (i.e. Procurement
Division, General Procurement Branch, or ORD Contracting Team)
Each buying entity has a set of policies and procedures which
controls the ordering and receipt of goods and services. The
policies and procedures include defining:
A. Numeric ranges for automatic numbering of documents
associated with a buying entity for requisitions, request
for quotations, and purchase orders.
B. The authorized buyers for the buying entity. This is
the place where a maximum amount the buyer is authorized to
issue on a single order can be set.
C. The authorized requesters (customers) for the buying
entity are established with dollar amount limit per line.
Customers will have to be related to a number of specific
buying entities because of the Agency's procurement
organizational arrangement.
D. The receiving controls are initially entered at the
buying entity level but can be entered at any of the lower
detail levels which will override data entered at a higher
level, as specified above. These controls include:
1) % tolerance over/under the quantity ordered.
2) Delivery point.
3) Accept early/late delivery and if applicable
number of days early/late allowed.
E. If a receipt does not meet .control specifications,
additional controls indicate how the discrepancies are to
be handled:
1) Warning message which will allow processing to
continue.
2) Exception which must be authorized before
processing can continue.
3) The system keeps track of and reports all warnin
and exception on a Receipt of Exception Report.
-15-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
The vendor is assigned to the paying entitylthat is the
organizational unit responsible for paying the vendor's
invoices. (i.e. ACD and ADL) Also the weights established
for the paying entity are used for calculating a vendor's
performance statistics. The vendor's performance statistic
consist of an overall rating as well as a rating for ,the
quality, delivery, and price of goods/services received. The
weights established for the paying entity apply to all vendors
assigned to the paying entity. The terms and controls that can
be entered at the vendor level are:
A. Ship-to location.
B. Method of shipment.
C. F.O.B.
D. Receiving controls.
The current methodology for assigning vendor numbers and
groups will be continued.
The system maintains item his,tory that:
A. Defines vendors from whom an item has been bought.
B. Comp
es statistics related to this purchase.
2. MAJOR DIFFERERCES FROM CURRENT SYSTEM
Today's system is a combination of CONIF's online storage
and retrieval of vendor data and WANG word processing for the
production of associated documents. CONIF's design allows for
multi-address for vendors and is contract oriented tracking
system. The MSA System is a single address design and line
item tracking system.
3. PROCEDURAL IMPACT
A. Workload
Currently it is not clear as to what the workload
impact will be for those individuals involved in the
procurement cycle.
B. Policy/Responsibilities
Currently it is uncertain what agency pdlicies will
have to be changed to implement the MSA System. . The
resolutions to the concerns listed below may have an impact
on the current procurement policies and procedures.
-16-
nprdascified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
4. CONCERNS
A. The MSA System provides for a single address per each
buying entity and each vendor. The address data contained
in these records are printed in the heading of RFQ's and
procurement instruments. The Agency is required by public
law to maintain data on the facility where a vendor
performs the actual work. Yet, because of the requirement
to protect sources and methods of the procurement of
goods/services to protect the fact that the Agency is
delving into a particular technical field or to eliminate
potential traceability of an item which may ultimately be
shipped to and used in an activity that would be damaging
if U.S. involvement was identified.
For this reason, vendors and buying entities must have
different addresses for the purpose of communication and
still have traceability through the maze of actual
participants. Also the vendors accounting records may be
kept at another location. Therefore, the MSA System should
be augmented with the capability of storing multi-addresses
for each vendor and each buying entity.
B. System appears to lack traceability of vendors former
name(s), facility location, and corporate relationships to
other vendors; commencing with the time they become a
member of the agency's vendor stable. A possible solution
would be the addition of a field to cross reference the
former vendor number and the new vendor number.
-17-
neclassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
FUNCTION: PREAWARD
1. DESCRIPTION OF THE MSA SYSTEM
A. Receipt of Requisition for Buyer Action:
The completed requisition is electronically placed in the
inbox of the Chief of the Buying Entity for assignment of a
buyer or another buying entity. If the requester knows
which buyer will actually process the requisition the buyer
can be assigned up front by the requesters.
The buyer will review the inbox for requisition to be
processed. If the buyer cannot process the requisition for
some reason the requisition can be assigned to another
buyer or another buying entity.
The buyer can request that the customer submit additional
information such as sole source justification. The data
will be submitted to the buyer's inbox.
B. Vendor Selection:
The MSA System assists with sourcing decisions in multiple
ways:
Vendor performance statistics.
Vendor product history and statistics.
Vendor quotations.
Item history.
The buyer selects the best vendor as the source for
the item or service when competition is not required.
C. Soliciting Vendor Quotations:
The MSA System provides a means of developing and printing
RFQs and posting and evaluating quotations.
The buyer has the option of creating a vendor's quotation
without first creating a Request for Quotation. When
policy requires that a quotation be solicited, you need not
enter the quotation number until you create the purchase
order. Furthermore, an RFQ does not have to result from a
requisition.
-18-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Information entered into the system at any point can be
referenced and carried forward to subsequent screens and
documents. The data contained in comment screens for the
RFQ and vendor responses cannot be carried forward to
subsequent screens and documents.
Once you record quotations, the system displays detailed
information to help you evaluate the options. Four screens
are used for inquiring about quotes.
1) Order quantity and pricing information.
2) Summary of basic information such as type, status,
important dates, least time, and associated RFQ
number, if any.
3) List shipping instructions and payment terms.
Also list receiving controls.
4) List vendor performance. Also lists total number
and monetary value of purchase order lines placed
against the quote data. The buyer retains the
authority to analyze the. terms offered and select the
best source of supply.
The Buyer's Action Report is a hard copy means of
tracking the status of RFQs and vendor's response.
There are six online inquiry screens pertaining to the
RFQ. The system uses three screens for the input of
RFQ data and three screens for posting vendor's
response.
In those RFQs requiring CSAD preaward audit the data
could be entered in the comment screen.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
A. The current system is a manual system with the WANG
producing the documentation. There is no database for the
storage and retrieval of the RFQ or quotation data. In
those RFQs requiring CSADs preaward audit functions, the
data is currently input into a VM file.
B. The MSA System is realtime online and provides an
efficient means for tracking and collecting quotation data,
vendor performance and item history for the non-complex
RFQs.
-19-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 CIA-RDP90-00191R000100080020-3
3. PROCEDURAL IMPACT
A. Workload
A. The input of RFQ and quotation information is time
consuming on the part of the negotiator. Time consuming
means ?that the MSA System allows the input of only One item
quote per vendor at a time. This means that when you are
on the phone with a vendor who is giving you a quotation
for even as few as five (5) line items, you must access two
screens for each individual line item and for each
individual vendor.
B. Policy:
B. The MSA System is not designed to handle the
lengthy text required by the Government for RFQs.
Therefore we may have to use preprinted boiler plates
containing the clauses required for the RFQs. However,
there is a means of using the comment screen for the input
of the clauses but it is not as efficient as the WANG word
processor is today.
4. COMMENTS
A. The MSA System needs, a means of collecting,
storing, and data manipulation for tracking and reporting
requirements for CSAD proposal audits. When the content is
classified, the buyer needs to know that OL/SS has approved
the plant facility and the classification levels authorized
for technical and administrative material to be received
and/or retained by the vendor. Also if the proposed
contractual agreement will require Government Furnished
Property/Equipment, the buyer needs to know if the vendor
has approved property accounting procedures.
The above data is a sample of the types of data
currently available in the CONIF System. This data is used
in the procurement process by negotiators, OL/SS, OF/CSAD,
IG/Audit Staff and OL/PMS just to name a few of the offices
using the data.
B. Use of the MSA comment screens as a means of
collecting, storing, and retrieval of data not defined in
the MSA dictionaries is a concern because the screens are
free text and optional input for the user. We anticipate
modifying the package with a new screen with new data
elements to facilitate data capture.
C. The MSA System dots not allow a buying entity to
be Changed. This capability is required because many:
requisitions are reassigned to other buying entities as a
result of workloads, experience, and sensitivity of the
goods/services to be _purchased.
-20-
npriaccifiari in Part - Sanitized Copy Approved for Release 2013/08/05 CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
FUNCTION: PREPARATION OF DOCUMENTATION (PROCUREMENT INSTRUMENT)
1. DESCRIPTION OF THE MSA SYSTEM
The creating and issuing of a procurement instrument is
accomplished through a series of six (6) screens. The system
provides a requisition to purchase order processing that
carries data forward from related records and the standardized
procurement terms and controls, therefore data does not have to
be rekeyed. The buyer always has the option to:
A. Default to information previously entered; or
B. Override hierachy common policies with data for the
specific order.
C. Write comments, specifications, and instructions for a
procurement instrument line or entire order.
The system keeps track of order quantities, and closes a
requisition line once orders for ,the total quantity requested
have been printed.
A requisition line can be split or divided up to five times
so that different quantities of the total quanti-ties requested
are allocated to different vendors. A requisition line cannot
be split or divided between different buyers. The lines of a
requisition cannot be split between different buying entities,
which is a major limitation of the system.
A procurement instrument is created from a requisition by
selecting a requisition line or a split using from one to three
screens.
Once a purchase order is ready to be printed the following
activity can be performed:
A. Balance the order.
B. Change information.
C. Procurement instrument can be reviewed on line before
printing.
D. Printing a procurement instrument is released by
authorized contracting officers.
-21-
npriaccifiari in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
E. Monitor status.
F. Receiving can be made against procurement instrument
line. If receiving is made against a procure-ment
instrument before it is printed, an original copy cannot
be printed.
G. Cancel or delete procurement instrument line.
The system provides ten (10) inquiry screens for reviewing
the overall procurement instrument and line detail:
A. Indicate line and receipt status.
B. Summary of order information.
C. Line receipt and invoice controls.*
D. Comparison of order/receipt/invoice information.*
E. Financial information per line.*
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM:
The preparation of documentation function is currently a
manual process with the use of the WANG word processor. The
contract information is entered into the CONIF database after
the fact for the collection, storage, and manipulation of data
to meet reporting requirements which includes Federal Data
System reporting specifications. The CONIF data validates the
present commitment and creates a decommitment and obligation
record that is transferred daily to the Agency's General
Accounting System (GAS) in a batch process. If commitment has
been transferred to CONIF from GAS the CONIF System creates a
decommitment and obligation record that is placed in suspense
until a commitment is transferred from the current General
Accounting System. CONIF contains data for tracking purposes
and views information from the vendor. The payment of vendors
is accomplished based on verifying and matching data in CONIF
and/or by physically matching purchase instruments, receiving
reports, and invoices. CONIF produces the required financial
vouchers, schedules, remittance advices and EFT data to effect
payment for the Office of Finance.
* Available only if integrated with AP(Accounts Payable).
-22-
.40
npriassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
MSA is a realtime online system that assists in producing
data for procurement instruments. The system automates the
administrative work and reduces paperwork. Its goal is to
reduce dependence on paper, eliminate duplicate record
keeping. The contract data retained by the MSA System is basic
to commercial procurement activities.
As requisitions, RFQs and procurement instruments are
processed, the hierachy matrix insures that the majority of
purchasing activities which Vs-in accord with the general
policy are handled automatically by the system. The buyer can
concentrate on resolving actions that are complex and/or
exceptions to the general rule.
3. PROCEDURAL IMPACT
A. Workload
There will be no need to input data into CONIF, ICS,
or WANG. The buyer will be required to input the data
into the MSA System.
B. Policy/Responsibilities
The responsibilities for the negotiati6n process will
not change except the buyer will be responsible for the
input of the data into the system.
The MSA System has a procedure for recording standard
phrases that are printed regularly on request for
quotations and procurement instruments. The phrases are
limited to ten (10) lines of fifty-five (55) characters
each. This procedure provides a phrase table that allows
the development of logical groups or sequences of standard
phrases. The table is limited to 15 phrases. The phrases
cannot be edited for a specific procurement instrument.
The MSA System is not designed to handle the lengthy
text required for Government contracts, therefore we may
have to use the preprinted boiler plates containing the
clauses required for contracts. There is a means of using
the item master for the one time keying of clauses,
pulling forward data to the comment screen and making any
additions and/or changes necessary for a specific
procurement instrument. This would be manipulating the
MSA System to be a word processor which is a function that
it was not designed to perform.
-23-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
4. COMMENTS
A. The MSA procurement instrument number contains 10
digits. If we implement the decision to use the AF
Contract Numbering system, we will require a larger
field. This is a key field and the impact of the MSA
System is unknown.
B. The lack of a real word processing capability for the
production of documentation.
C. The ability to track cost type actions is unknown at
this time.
-24-
CD
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 CIA-RDP90-00191R000100080020-3
FUNCTION: POST AWARD
1. DESCRIPTION OF THE MSA SYSTEM
MSA System tracks the procurement instrument line status
for the receipt of goods or services. The procurement
instrument line is closed when DTS (dock-to-stock) activity for
a line is finalized and either the total quantity against the
procurement instrument line equals the order quantity, the total
received falls within the + or - % tolerance3or the line has
been cancelled. When all lines are closed the procurement
instrument is closed.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
A. The current CONIF System tracks the contract from the
history of the procurement instrument through the
amendment data, payment, CSAD data, COTR inspection
reports, and in settlement processes. The fixed price
(FFP) contracts are settled pnce both the final receiving
and payment process has been completed. The settlement of
cost type contracts is a multi-step process requiring the
completion of a number of documents such as certificate of
completion, Final Patent and Royalty Report-, Cumulative
Claim and Reconciliation Report, Final Property Report,
and Disposition of GFP/GFE Report just to name a few of
the documents required to settle a contract.
B. MSA keeps track of the number of times the target
delivery date is changed and stores only the current
target date. System also stores only the current amount
of the contract. MSA closes the contract when the receipt
of all goods or services has been received regardless of
the type of contract.
3. PROCEDURAL _IMPACT
A. The weakest point of the MSA System is the post
award/administration part of the procurement cycle.
B. The inability to capture amendment data for individual
amendments that have been written to modify an existing
procurement instrument. This data represents a history of
all changes that have occurred to the original procurement
instrument.
-25-
npriaccifiari in Part - Sanitized Copy Approved for Release 2013/08/05 CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
C. The inability to capture the_ following data:
1) COTR s inspection data.
2) CSAD data.
3) Closing/settlement data.
4) Archiving data.
Currently the only way this data can be input to the MSA
System is to use the comment screen. The comment screen is
optional and free text, thus the user will have to be very
disciplined in the data requirements.
-26
neclassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: VENDOR PAYMENT
Note:
The initial CLAS proposal was based on using an
integrated version of Purchasing (2.0) and
Accounts Payable (AP 5.0). Un-integrated
versions (Purchasing 1.2 and AP 4.2) were used in
the current evaluation. The evaluation report
emphasizes AP 4.2, but includes an overview of AP
5.0. AP 5.0 comments are based on reviews of
user documentation, product demonstrations? and
formal instruction on implementing AP 5.0.
Although it is presently available on the market,
AP 5.0 in an integrated and IDMS version will not
be available until April-June 1987.
1. DESCRIPTION OF THE MSA SYSTEM (4.2)
The 4.2 release of the accounts payable package is
basically a batch system with some on-line capabilities. It is
not interfaced with any of the other packages but does provide
the capability for extracting general ledger data to be passed
to a general ledger package. The only file that can be created
on-line is the vendor file. The ,batch transactions may be
created on-line but are updated in batch. These include:
1. Policy
2. Invoices
3. Payments
4. Reports
All invoice data collection and payment transactions are
processed through batch jobs.
The system permits on-line inquiries against the policy,
vendor and data collection files. It also allows for on-line
inquiry of invoice status and cumulative payment data. The
system consists of forty menus which are comprised as follows:
Policy Inquiry 18
Vendor Inquiry 6
Item Inquiry 6
Data Collection 9
Data Collection Inquiry 2
-27-
npclassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Of the nine data collection menus, one is used as a
transaction header, six are used for the payment of invoices,
one is utilized for establishing and modifying vendors and the
remaining one is used for cycle control. Pay entities and their
attendant policies. They are input via a free form 80 column
format which is both cumbersome to use as well as possessing a
high potential for error.
The system processes consist mainly of establishment of
paying entities, policies regarding each entity, vendors within
the entity, and invoices against the vendors. The rules (or
policies) are established at the various levels - policy,
vendor, invoice, etc. - and the system operates on a default
basis to the next highest level beginning with the data input at
the lowest level. For example, discount policy may be
established at the paying entity level or at the vendor level
however discount information input on the invoice will override
the higher levels.
System processes consist of inputting invoices against
specific vendors with minimum data such as vendor number,
invoice number, amount, payment date, and accounting date.
Optional data such as discounts, accounting distribution, etc.
may also be entered at this time. When the payments are
triggered by the input of payment cycle cards, the system then
checks higher level policy and schedules payments based on rules
established at either invoice, vendor or policy level.
The outputs of the accounts payable system are checks - or
treasury tapes to produce checks or EFT - remittance advises,
and data to update the appropriate general ledger accounts.
2. MAJOR DIFFERENCES FROM CURRENT SYSTEM
The collection and retrieval of data in the accounts payable
package is at the policy, vendor, and invoice level rather than
at the purchase instrument level as in CONIF.
3. PROCEDURAL IMPACT
A. Workload
Audit and Certification Division (MCD)
The workload in MCD would increase if release 4.2 is
implemented. Because of the need to maintain duplicate
'vendor files and to prepare remittance advice notices.
Unless modifications are effected to accommodate cost
' type transactions, implementation of either release would
seriously impede the MCD effort.
-28-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
Commercial Systems Audit Division (CSAD)
The CSAD function would be impeded by the implementation
of either release, predicated on the fact that CSAD is
dependent on the current system to collect and extract the
data necessary for auditing cost type contracts.
Assistant Director for Liaison (ADL)
If release 4.2 were used, an extract of OGA requisition
and receiving reports would have to be passed to ADL, or ADL
would be forced into a cumbersome and time-consuming manual
matching effort.
The implementation of release 5.0 would result in some
savings of time and effort due to the automated matching
feature.
4. MSA ACCOUNTS PAYABLE 5.0
The basic concepts of accounts payable releases 4.2 and 5.0
remain the same, but the following changes have been made. In
order to convey their impact they are broken down into
categories of major, significant, and minor.
Major Changes:
o Integration with Purchasing
- Shared Vendor File
- Automated Matching
o Enhanced Reporting
- This release utilizes the Information Expert (I.E.)
facility which allows for ad-hoc report generation.
O Improved Menu Capability
New menus for establishing and maintaining policy
Less cumbersome, more user friendly
Invoice Worksheets
Increased flexibility and ease of use
Significant Changes:
o On-Line Invoice Approval
- Individual or group authority
- Dollar limitations
-29-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
o Invoice Modelling
- Used for frequently paid invoices, such as utility
payments
o Improved duplicate invoice verification
o General Ledger Interface Menu
- Allows integration of accounts payable with non-MSA
General Ledger
o Links company/account/center to purchase order
- If automated matching is employed, the general ledger
distribution can be linked to the purchase order
(This is more in line with the current philosophy of
linking to the purchase instrument rather than the
vendor)
O Capability to effect partial payment
- CONIF allows partial payment of suspensions. Release
4.2 could not accommodate this
Major Enhancements:
o Edit on general ledger posting date
- Under release 4.2, an erroneous posting date could be
input. E.g. a posting date of 1986 could be recorded as
1996, thus causing general ledger data to be incorrect
Use of decimals in amount field
- 4.2 would not accept decimals thus was less user
friendly
O Canned messages
- Preformatted reason codes and remittance messages
- Can be easily referenced on invoice
o Ability to inquire and return to invoice
- This release provides capability to exit the invoice
to make inquiries on company terms and vendor policies
and return to invoice worksheet.
? Capability to delete and restore lines on invoice
-30-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
Summary:
The overall evaluation of this release is that it possesses
much more functionality than the one that was evaluated at the
offsite facility. It has alleviated many of the negatives
associated with that release - notably those dealing with the
cumbersome processes, the retrieval capabilities, integration
with purchasing, release of suspensions and some of the missing
edits.
5. COMMENTS
Release 4.2 does not meet the needs and requirements of the
Agency and should not be considered for implementation.
Release 5.0, along with purchasing release 2.0, will
accommodate the processing of firm fixed price contracts. It
will fully meet the requirements of ADL and will satisfy a
substantial portion of those in MCD.
Neither release will satisfy the requirements associated
with the cost type contracts, and, therefore, would not fulfill
any of CSAD's requirements nor AKD's to the extent they impact
on the cost type contracts. Although these transactions
represent the smallest percentage of contract activity, they
constitute the highest dollar volume.
The purchasing and accounts payable packages must be
integrated in order to fully realize their functionality.
Even though some modifications are necessary, the use of
package software will result in changes being made to current
operations and policies. This will require management decisions
at all levels.
-31-
Vb.
npriassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
FUNCTION: MANAGEMENT INFORMATION:
1. MSA SYSTEMS
The MSA software design anticipates the majority of
information required by managers and users. Menu-driven on-line
queries and reports and batch reports are available throughout
the system. Many menus are linked with logically related
.transactions, but any query menu can be readily accessed from
any point in the functional process. Access to query menus is
controlled by system security. Each selected menu allows the
user to define search and sort criteria. For example, an item
manager may search by stock number; description; word, partial
word, or phrase within a description, cognizant office; value;
commodity class; or warehouse location. Criteria may be used
-alone or in conjunction with each other.
The MSA software is designed around a product called
INFORMATION EXPERT, or IE. IE is a menu-driven reports writer
that allows the user to design a custom report in a ten-step
sequence. Custom designs may be "canned" for repetitive use.
Reports may be created and viewed on-screen rear-time. Hard
copy reports are in batch mode. Although the team has observed
IE in demonstrations and classes, there has been limited
hands-on experience to date.
The Purchasing portion of the software is IE driven. IE
versions of Inventory and Payment functions will be acquired in
the April 1987 time frame. Until that time, the purchasing
system will ,be used to explore reporting on requisition,
procurement; and receiving functions:
2. CULLINET DATABASE (IDMS/R) PRODUCTS
Although the functional evaluation team has not attempted to
use them, OIT's technical team has done exploratory work on
Cullinat's-CULPRIT reports writer and ON-LINE QUERY (OLQ)
system. Both of these products can be used in lieu of or'in
conjunction with MSA products. As an ad hoc. query tool, OLQ
seems cumbersome to a casual user. However, the syntax required
for a frequent query can be recorded and assigned a QUERY NAME,
and the question posed by any user by calling the QUERY NAME.
-32-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
STAT
STAT
FUNCTION: APPROVALS
The approvals capability of the MSA system is rudimentary.
Authorizing menus are provided, and their use required, to
release requisitions, purchase documents, and invoices for
payments to vendors. Access to authorizing menus is controlled
by system security; the purchase and payment authority may be
further restricted by dollar levels. It appears that the
authorization screens are intended primarily for supervisory
reviews.
REQUISITIONING;
Each line item of a requisition must be approved before
further processing of the complete requisition takes place. The
system provides for automatic approval (completed requisitions
are immediately released), semi-automatic approval (dollar
thresholds require manual approval), or manual approval
(authorized approving officer must release each line item).
Prior to that approval, all data on the requisition may be
changed. Once approved, line items may not be added nor
line-item data amended.
A proposed scenario for requisitions would have originators
construct requisitions on-line, without the necessity of Form 88
or 2420. A completed requisition is printed in the originator's
office--that hard copy document would be used to obtain any
needed coordinations and approvals, and retained for audit
purposes. The approval/release screen is used by or under the
supervision of the component logistics/administrative officer,
who is responsible for ensuring that necessary signatures are
present for each requisition being approved/released. This
method ? ent with regulations currently being Dublished
However, it may be contrary to
w ic states that OL will check to see if approval
s gna ures are present. OL does not authenticate signatures.
To facilitate monitoring for compliance with approval and
coordinating requirements, periodic (daily?) reports recapping
activity would be sent to each originating office and to any
-coordinating offices for which reports search criteria can be
identified. It is incumbent on recipients of those reports to
actively monitor requisitions, to challenge questionable ones,
and to request that further processing of unapproved/
uncoordinated requisitions be suspended. Disputes on
coordinations are between the originator (whose approval
certifies that necessary coordinations were obtained) and the
coordinating component.
-33-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
PURCHASE DOCUMENTS:
The authorization/release screen is used after a purchase
document is set up (all information relative to the purchaser is
assembled) and prior to printing of the document. While access
to the authorizing screen is controlled by system security, and
use of the screen is required, the screen seems best suited to
providing on-screen editorial review of a completed document.
Actual control of purchasing, and the authority for releasing a
purchase document, rests with the hard copy document being
reviewed and signed within the bounds of existing delegations of
authority. Information on the Determination and Finding/
Contract Review Record can be recorded in the comment portion of
the on-line purchase document using maintenance menus, or a
separate screen with data elements can be developed.
VENDOR PAYMENT:
The approval screen in the payment module may be restricted
by several criteria, primarily dollar amounts. The screen may
be used for supervisory review or for certification, depending
on Office of Finance desires.
-34-
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
POSSIBLE/PROBABLE MODIFICATIONS
1. Provide additional interface between the Manufacturing and
Purchasing Systems to provide a single requisitioning format
for stock issues, direct material purchases, and service
requests. A uniform format will simplify user involvement,
provide uniform data entry and query, and provide a single
data stream from which to interdict budget and financial
processes.
Estimated Cost $60,000
2. Provide structured input screens for data capture; no logic
is associated with the data elements, although simple edits
are possible.
Requisitioning: header information identifying
originators, shipping addresses, and special
handling/remarks/transportation.
Depot Tracking:
Purchasing: Contract management information
not present in the contract that is
currently input to CONIF.
15 000
15,000
15,000
Payment: Payment information relating to cost
type contracts and progress payments. 15,000
3. Special reports/forms utilizing data extracts and
standard forms generator.
Purchase document: conform to USG standard. 10,000
Depot Instruction Notice: Stand-alone document
to move material into stock and to
transportation.
Requisition document: hard copy auditable
document, printed, approved, and retained
by the originator.
Business Justification/Contract Reviews. 10,000
4. Modify Purchasing Maintenance Screen to include
data elements recording Date Contract Mailed and
DATE BI-LATERAL CONTRACTS ARE RETURNED.
-35-
10,000
10,000
10,000
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
?
S. Provide multiple Buying Entity Codes on single
requisition, and allow multiple Buying Entity
Codes between Manufacturing and Purchasing.
6. Provide capability to change Buying Entity
Codes without cancelling/re-creating
requisition data.
7. Provide for automatic allocation on requisitions
for stock items, retain manual process for
substitutions.
40,000
15.000
15,000
8. Modify requisition approval program to allow
approval at the requisition (vice line item) level. 15,000
9. Interface with Agency budget system. 100,000
10. Alter system security, per OIT/SEG. 100,000
$455,000
(say $500,000)
-36-,
npriassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3
Declassified in Part - Sanitized Copy Approved for Release 2013/08/05 : CIA-RDP90-00191R000100080020-3
?
FUNCTION: TERMINALS
1. There is a concern regarding the terminals that will be used
to support CLAS. The MSA system was intended for use with the
IBM 3270 family of color terminals. Four different colors
differentiate between system generated datir(menus), 'required
and optional data, and error messages. The team found these
colors to be very helpful.
2. Although the IBM 3270 family has been selected as the
standard terminal replacing Delta Data, the selection of a
procurement source is not expected until September 1987.
Terminals may be purchased prior to that date at 6-7K per work
station. In any event, none of the outbuildings (including
Page) are wired to handle the 3270 protocol, and there are no
firm plans/funds to do so. The Headquarters Building will
support 3270-protocols late FY-86 . The New Headquarters
Building, and possibly the Reston Complex, will provide 3270 -
connectivity.
3. OIT has installed an ADESSA emulator that allows Delta Data
terminals to use the 3270 protocol. The emulator adds SO% -
100% to terminal response time and does not provide color
capabilities.
-37-
neclassified in Part - Sanitized Copy Approved for Release 2013/08/05: CIA-RDP90-00191R000100080020-3