Supply Discrepancy Reporting

DoD Web Submission

Ellen Hilert

J673  Defense Logistics Management Standards Office

Overview
        - Background
        - Where we are now
        - Where we are headed

Defense Logistics Standard Systems
        - Beginning in 1962, the DLSS were established to provide uniform procedures for logistics operations within the DoD and to realize the advantages of advancing computer technology
        - One of the DLSS:                         Reporting of Supply Discrepancies,                     DLAI 4140.55, AR 735-11-2, SECNAVINST 4355.18A, AFJMAN 23-215

Beginning in 1962, the DLSS (also known as the MILS or Military Standard Systems) were established to provide uniform procedures for logistics operations within the DoD and to realize the advantages of advancing computer technology.

They provide procedures for:  communicating requirements; moving material; interfund billing; and performing the all the other tasks that ensure the continuing operation of DoD's logistics system.  This includes the reporting and resolution of supply discrepancies.  There were 13 standard systems which formed the DLSS.  I’m sure you are familiar with many of these:  MILSTRIP, MILSTRAP, MILSBILLS, DoDAAD and MAPAD.  Among these standard systems was the regulation which administered the Report of Discrepancy process now called SDR and which continues to be managed as a joint service publication.  Unfortunately, a standard transaction was not approved to replace the ROD form in the early years, as happened with most other logistics forms under the other DLSS.  The ROD submission remained largely manual evolving into Component unique formats as modern technology was infused into the process.  

Defense Logistics Management System
        - The DLMS is a broad base of business rules, to include uniform policies, procedures, time standards, transactions, and data management, designed to meet DoD’s requirements for total logistics support.
        - Founded upon American National Standard Institute (ANSI) Accredited Standards Committee (ASC) X12 Electronic Data Interchange (EDI).
        - Expanded to support emerging EB/EC capabilities such as:  data sharing, automated identification, web-based technology, electronic malls, etc.

For three decades, the DLSS enabled DoD logistics managers and consumers to communicate – electronically for the most part using standard 80 rp transactions. The functional procedures and supporting transactions have been the backbone of DoD's logistics system.  Used by over 70,000 customer activities, these standards have been implemented by the Military Services, Federal and DoD agencies, defense contractors, and allied governments.   Over time, the fixed length DLSS transactions reached the saturation point and it has become virtually impossible to satisfy the rapid growing logistics requirements.  

Recognizing that emerging technologies provide opportunities for performing the DoD logistics mission more efficiently and effectively, the Office of the Secretary of Defense (OSD) initiated a modernization effort which came to be called the DLMS.   The DLMS utilizes Electronics Data Interchange (EDI) logistics transactions which conform to national EDI standards established by the American National Standards Institute (ANSI) Accredited Standards Committee (ASC). These transactions handle all the information required for current DLSS processes and can support paper-based Supply and Product Quality Discrepancy Reporting formats as well as additional information required by newer initiatives such as serial number tracking and weapon system identification.  

More recently, the DLMS has evolved to support the newer emerging technologies.  Our intention is to provide a full spectrum of support to our customers and to accomplish this we are exploring data sharing, XML and web-based enabled processes.

Policy
        - DoDD 8190.1, DoD Logistics Use of Electronic Data Interchange (EDI) Standards, May 5, 2000
        - DoDD 8190.2, The DoD Electronic Business/Electronic Commerce (EB/EC) Program, June 23, 2000

There are some recent policy documents which have authorized this effort and will help insure it’s success.

DoD 8190.1, DoD Logistics Use of EDI Standards, signed May 5, 2000.  This is the document which supercedes DoD Reform Initiative #48, The DRID was issued in 1998 and impelled DoD forward toward best commercial practices in the area of electronic transaction exchange.  The policy supports use of ANSI ASC X12 EDI as one of three FIPS (Federal Information Processing Standards) standards, but recognizes and does not preclude other data interchange methods when appropriate.  My office, the Defense Logistics Management Standards Office, was established as the DoD Executive Agent for logistics data interchange.   One of our goals is to implement guidance in DoD Directive 8190.2.

This is the policy document which codifies DepSecDef and CIO guidance,  establishing the DoD Joint EB/EC Program and the organization and mission of the Joint Electronic Commerce Program Office (JECPO).    It clearly defines DoD policy to foster and promote integration of EB/EC technologies into reengineered or improved business process.  Another goal is to develop and apply Department-wide services and processes to minimize duplication and ensure interoperability.

Implementation
        - Adoption of Commercial EDI Standards for DoD Logistics Phased Implementation Plan
        - Pilot Projects:  Web SDR

To move the Department to modern commercial standards is daunting task.  Using an IPT chaired by JECPO, the Components successfully developed a corporate level phased implementation plan and supported several pilot projects which adopted use of ANSI EDI.    One additional project was addressed by DLMSO as a modernization effort designed to integrate several supporting technologies.  Working with the Component SDR focal points we developed an informal requirements document.  This was turned over to the Defense Automatic Addressing Systems Center (DAASC) whose expert knowledge base and programming skill has resulted in a beta version of the program which is undergoing preliminary testing.  

Web SDR Goals
        - Single Point of Entry for Manual SDRs
        - DoD Components
        - Foreign Military Sales customers * 
        - Government Furnished Material

* FMS interface for DoD Web SDR application TBD.

Here what we are trying to accomplish with this effort.

We would like to have a single point of entry for manual SDRs  (this process does not currently address automated SDRs prepared as a result of receipt processing).  Submitters will include

DoD Components

Even participating contractors receiving Government Furnished Material

Foreign Military Sales customers (interface with DSCA sponsored program being explored)

Web SDR Goals
        - Customer-friendly Web Process
        - Auto-fill feature reduces customer input 

Determination of appropriate action activity

Original requisition information retrieved from DAAS history

Shipment information retrieved from DAAS history

Address, associated, calculated information 
        - Data requirements keyed to type of discrepancy
        - Immediate verification of questionable input
        - Automated help

What we’re hoping to achieve is a Customer-friendly Web Process

The system has an auto-fill feature designed to reduce customer input and errors. 

Determination of appropriate action activity is automatic. That is, selection of the activity to which the SDR is forwarded is pre-filled on the screen based upon several factors such as the ICP (using Service or Agency rules), the type of shipment (DVD or DoD) and the shipping depot if DLA.

Original requisition information resident at DAASC (using the LOTs database) is used to pre-fill information such as the material identification and original requisition quantity.

Shipment information is used to provide such things as the transportation control numbers and quantity shipped. 

Information can be pulled directly from the DAASC DoDAAC table and the Federal Logistics Information System to record or verify the various addresses involved and material nomenclature and price.

Data requirements can be linked to the type of discrepancy.  For example, if the discrepancy code indicates the incorrect item was received the system provides an additional window for the customer to describe the wrong item.

Suspect information, possibly a miskeyed requisition number or even a discrepancy attributed to an shipment outside timeframe parameters, can be questioned for accuracy although outright rejection is rare.

And the system provides help in the form of definitions and expected data content for each field of data.

Web SDR Goals
        - Improved Data Content Control
        - SF 364, ROD, data blocks

Remove obsolete data

Clarify existing data blocks 

Add new data elements
        - Drop down code lists

Expanded / current
        - Supporting documentation

Photographs

Scanned image of documents

Using a web design we have much greater flexibility over the data content of the SDR.  Obsolete information carried on the SF 364 can be eliminated, easily misunderstood information requirements can be clarified, and new data requirements can be added.  For example, we can allow for a secondary discrepancy code or provide specific data blocks for information originally carried in multi-purpose or narrative blocks.

We rely heavily on drop down code lists making data entry easier and ensuring correct code information is provided.  The official code lists for the type of discrepancy and the requested action were expanded in 1999.  However the SF 364 reflects only a portion of the authorized values.  The web list is complete and current giving greater options to the customer and paving the way for more flexible and detailed automated information retrieval down the road.

The customer will also have the option of electronically transmitting supporting information.

Web SDR Goals
        - Quicker Response/Less Effort
        - Reduces delays resulting from misrouted SDRs or mailed documents
        - Electronic interface eliminates data entry at action activity

We hope the Web SDR process will increase our efficiency in dealing with discrepant shipments.  The information will get to the right action activity and with no delays for mailed documents.  The action activity should never need to rekey information provided by the user.

Web SDR Goals
        - Security Assistance Product Quality Deficiencies 
        - Expanded management information to support appropriate resolution

Encourages narrative details

Circumstances Prior to Difficulty

Description of Difficulty

Suspected Cause

Action Taken

Recommendations

One of the original planned enhancements was the handling of SDRs from Security Assistance customers which are related to product quality deficiencies.  Working with Duane Rice, former DoD PQDR Administrator, we have agreed to incorporate an additional data entry window when one of these PQDR-type discrepancies are identified.  This is the first of two slides which list the specific information we will now request.  We will provide additional narrative blocks for each of these specific areas. 

	Circumstances Prior to Difficulty

Description of Difficulty

Suspected Cause

Action Taken

Recommendations

Web SDR Goals
        - Security Assistance Product Quality Deficiencies
        - Expanded management information (continued)

Addition POC information

Location of Deficient Material

Category I or II

Quantity in Stock

Item New or Repaired/Overhauled

Item Under Warranty

End Item and Next Higher Assembly

Date Deficiency Discovered

We will also ask the customer to provide each of these additional pieces of information.

Web SDR Goals
        - Customized Interface with Legacy Systems
        - Flexible design for file transfer
        - Conversion to email where requested
        - ANSI X12 EDI 
        - Available when Component modernization programs implemented

One of the best features of this program is the flexible output product.  We have asked the Components to tell us just what format they expect for the output transmission.  We will accommodate any user defined file format suitable for existing system interface. Although clearly a less efficient approach, we are prepared forward the SDR using e-mail as well.

Our hope is that the modernization efforts among the Components will eventually standardize electronic SDR transmission using the ANSI X12 EDI format which has been Federally approved, but not implemented as yet.

Web SDR Long Range
        - DoD-wide Management Information
        - Phase-out/Reduce Component-unique Web Submission Programs
        - Interactive Point of Contact Directory  (future release)
        - Phase II Web-enabled Response

Our longer range goals are fairly obvious ones.  We would like to be able to extract DoD-wide management information from the data base established at DAASC.

We would like to eliminate the proliferation of Component unique web programs as well as multiple (not always current sources) of Point of Contact information.  From a DoD perspective it is wasteful to maintain many individual web SDR entry programs.  We would like to drive down the update responsibility to the ICP/depot SDR processing points of contact so that personnel changes and such can be identified quickly.

And we would hope to expand the program to include responses to the customer.  

Web SDR

https://day2k1.daas.dla.mil/websdr/demo_files/demo.htm. 

We are still in a testing phase.  Not all the screens or interfaces are completely programmed as yet. Images of all input screens are posted at URL address at the top of this slide.   In addition, a test version has been made available to interested DoD Component representatives.   To obtain access to the test version, use the contact information provided on the final slide.

Web SDR

I selected this screen to show you - where the customer first identifies the type of discrepancy being reported.  The drop-down box allows the customer to quickly scroll through the many possible codes to select the most appropriate.  Here you can see the expanded list for PQDR-type discrepancies as approved in January 1999.

Web SDR
        - To Do List
        - Working with Component-provided formats for direct interface with internal SDR applications
        - Refine data requirements
        - Testing

Initial testing underway

Interface testing delayed
        - Phased Implementation

@  1 October 2003
        - Phase II planning now underway

Web SDR

The End

Ellen Hilert

DoD SDR System AdministratorDoD Supply Process Review Committee Chairellen.hilert@dla.milhttp://www.dla.mil/j-6/dlmso/