1. Defense Logistics Management Standards
Creating/Reengineering DoD Logistics
(stand alone module)
This class will provide an introductory level instruction in EDI as applied under the Defense Logistics Management Standards (DLMS). The DLMS is a broad base of business rules supported by American National Standards institute (ANSI) Accredited Standards Committee (ASC) X12 commercial standards and is designed to meet DoD’s requirements for total logistics support.
The target audience for this class is function experts and system analysts requiring knowledge of the DLMS application of ASC X12.).
“The right item at the right place at the right time.”

2. DLMS Training Catalog Module 1 - Introduction to the DLMS
Module 2 - Electronic Data Interchange (EDI) Basics and ASC X12 EDI Definitions and Concepts
Module 3 - DLMS Functionality & Transaction Life-Cycle
Module 4 - DLMS Implementation Convention Content
Module 5 - IUID & RFID - Emerging Technologies
Module 6 - Creating/Reengineering DOD Logistics Business Processes
Module Enterprise Interoperability Tools
Module DoD Activity Address Directory (DoDAAD)
Module 9 - Supply Discrepancy Reporting (SDR)
Module 10 - DLMS Functional Financial Transaction (standalone)
Module 11 - Creating/Reengineering DoD Logistics (standalone)
This is the full Catalog of DLMS training Modules that are available as part of the DLMS Training. Each Module is a building block for those that follow it. The Catalog allows for course progress tracking. While it is recommended that the Modules be taken in sequence, it’s not mandatory.

3. Creating/Reengineering DoD Logistics
Module 11 – DLMS
Creating/Reengineering DoD Logistics
Background
Role of Process Review Committees (PRCs)
How to develop a DLMS change
- Next: Module Objects

4. Module 9 Objectives Students will gain a basic understanding of:
how the DLMS contribute to implementing business process improvements and maintaining interoperability
the DLMS Program Office mission and DLMS configuration management process
how proposed business process changes are prepared and processed.
Narrator: Let’s begin by reviewing the objectives for module 9. By the time you have finished this module you will have a basic understanding of:
how the DLMS contribute to implementing business process improvements and maintaining interoperability
the DLMS Program Office mission and the DLMS configuration management process, and
how proposed business process changes are prepared and processed.
MM Note: This should have the same structure and graphics as previous modules.

5. Creating/Reengineering DOD Logistics (Executive Overview)
Narrator: Module 9 is one of four standalone modules that comprise phase 2 of the DLMS training. This module provides an executive level overview of EDI as applied under the Defense Logistics Management Standards or DLMS.
The DLMS are a broad base of business rules supported by the Accredited Standards Committee (ASC), X12 commercial standards, and are designed to meet DOD’s requirements for total logistics support.
MM Notes: New screen graphics and narrative changes.
Creating/Reengineering DOD Logistics (Executive Overview)

6. What are the DLMS? The DLMS are:
Narrator: Now, let’s answer some basic questions that will help us better define the DLMS.
To begin with, what are the DLMS?
The DLMS are a body of standards that includes procedures, business rules, data standards, code lists, metrics, and transaction formats.
DLMS Note: I moved this information forward. It is more logical to answer the questions of who, what, where, why before diving into mission and purpose. Although mission and purpose coincide in some ways with the why.
The DLMS are:
a broad base of process rules, data standards and electronic business objects (information exchange formats)
designed to meet DOD’s requirements
used for total logistics support
MM Notes: This is a screen build. Use appropriate graphics to support.

7. Who is involved in the development?
Narrator: Next, who is involved in the development and implementation of the DLMS?
DLMS development is a collaborative effort between representatives from each of the Armed Services, DOD agencies, and participating Federal agencies, such as the General Services Administration, the Federal Aviation Administration, and the U.S. Coast Guard.
Collaboration is achieved through the use of the DLMS Process Review Committee collaboration model in which requests for change are discussed, negotiated, and agreed upon, prior to approval and implementation by the Components.
MM Notes: This is a screen build. Use appropriate graphics to support.
The DLMS:
are developed in collaboration with the Armed Services, DOD agencies, and participating Federal agencies
use the DLMS Process Review Committee collaboration model

8. Why do we need the DLMS? The DLMS:
Narrator: But the biggest question is why do we need the DLMS?
The DLMS are designed to support modern logistics systems, such as enterprise resource planning systems implemented by Military Services as well as Defense and Federal agencies. But they also enable outdated legacy logistics systems using MILS transaction formats, to continue to operate effectively at a basic level, to ensure there are no processing gaps during information exchanges. And the DLMS support business process improvements and maintain interoperability. 
MM Notes: This is a screen build. Use appropriate graphics to support.
The DLMS:
accommodate the new Enterprise Resource Planning (ERP) system processes and implementation, while supporting legacy system data (MILS) exchange requirements
support business process improvements and maintain interoperability

9. Narrator: The purpose and mission of the Defense Logistics Management Standards, known as the DLMS, is to support continual business improvements while maintaining interoperability across a diverse and complex group of organizations and their automated information systems.
DOD establishes new programs focusing on specific functions to improve how DOD conducts business. These programs, whether item unique identification, performance based logistics, process reengineering, or any of the other examples shown, are the constant pursuit by DOD to conduct business operations faster, better, and cheaper. The DLMS support these and other programs focused on process improvements, and most importantly, improved support to the Warfighter.
The DLMS transactions themselves exist solely to support the business processes. DOD alone has some 700 systems that support the Materiel Supply and Service Management business domain. Added to these are the additional 1,000-plus contractor systems, plus financial, transportation, acquisition, and procurement domain systems, constantly exchanging information.
The challenge is to continually improve how business is conducted in a large and complex environment, where organizations and systems do not all move at the same pace. This is the challenge of the DLMS - to maintain interoperability throughout the Government.
MM Notes: This is a screen build. Use appropriate graphics to support.

10. Interoperability of What?, continued
Functional Services Providers
Commodities
Transport USTRANSCOM
Intl. Logistics DSCA
As I previously mentioned, there are more than 700 systems that support the Materiel Supply and Service Management or MSSM business domain and the service oriented architecture that enables business interoperability among them.
Let’s explain this in more detail with a graphic representation.
The horizontal chains depict the various types of supply chains and the systems that support them. Here are a few things to remember about supply chains.
It is not uncommon that there are often multiple systems interacting within a single supply chain. Examples of commodity supply chains include ammunition, troop support, aviation, medical, energy, etc.
The Weapon Systems supply chains are tailored to logistics support of a weapon system like the F-35 Joint Strike Fighter. Many times these types of supply chains are supported thru interaction of contractor systems with Government systems.
There are also other supply chains such as those of the General Services Administration (GSA), Federal Aviation Administration (FAA), and U.S. Coast Guard that interact with DOD systems.
Next, let’s discuss Functional Services Providers. Here they are represented by the gears on the screen. These depict a set of organizations that have been established to provide common functional support services necessary to support the supply chains previously discussed. These functional services providers provide support services that otherwise would have to be inefficiently duplicated by the systems in the supply chains if they were not provided at the enterprise level. Each of these functional services providers makes use of one or more systems to perform their support missions across the life cycle supply chains. Let’s examine a few examples.
The Defense Logistics Agency, or DLA, provides warehousing and distribution services to the supply chains and utilizes the Distribution Standard System worldwide.
The U.S. Transportation Command provides the supply chains with transportation services by using multiple systems tailored to supporting and interfacing air and surface movement delivery methods available both organically and commercially.
The Defense Finance and Accounting Service uses several systems to provide financial services such as processing bills, making payments and interfacing with the Department of Treasury systems.
The Defense Security Cooperation Agency uses several systems that interface with the supply chain systems and allied Government logistics systems that have logistics support agreements with the United States.
The challenge of interoperability is how to integrate the supply chains with the functional services providers, so that they seamlessly operate in an efficient, effective manner at the lowest possible infrastructure cost.
The answer to the challenge is to introduce DLMS Global Services Providers. Three DLMS Global Services Providers; the DLMS Program Office, the Defense Automatic Addressing System, or DAAS, and Logistics Information Services, formerly known as DLIS, form the foundation or technical service oriented architecture that provides a type of connective tissue, to ensure interoperable business operations among the supply chain systems with the Functional Services Provider systems. It’s important to note that without these three distinct organizations and the support services they provide, all of these supply chains and functional services providers would have to replicate the capabilities hundreds of times, making the process of interoperability more difficult, expensive and time consuming.
The Defense Logistics Management Standards Program Office under the Enterprise Business Process Standards Office, manages the process for the development and syndication of standards that form the foundation of interoperability support to business systems. The standards are collaboratively developed to document standard business processes founded on standard business rules, business transactions and data. Adherence to the standards by systems developers is the underpinning of interoperability.
The Defense Automatic Addressing System, or DAAS hosts an extensive suite of hardware and software providing electronic connectivity and other interoperable value added services to the systems transacting business operations in the Material Supply Services Management, or MSSM domain. Services include transaction routing, validation, translation, archiving, testing, hosting of transaction related reference repositories, etc. There are 9 billion transactions annually supported by the DAAS.
Logistics Information Services, still known as DLIS, hosts and provides access to large master data reference repositories that are essential to the operations of the systems in the MSSM domain.
MM Note:
Throughout the entire eLearning lesson we are now using ‘Functional Services Providers’ instead of ‘Enterprise Services Providers’.
Note that throughout the entire eLearning tool we are now using ‘DLMS Global Services Providers’ instead of ‘Enterprise Services Enablers’.
DLMS DAAS DLIS
Finance DFAS
Weapon Systems
Acquisition DCMA
Supply Chains
DLA
Disposition Services
Others
DLA Distribution
DLMS Global Services Providers

11. Interoperability Framework
The Office of the Secretary of Defense (OSD)
Narrator: We just finished discussing the need for interoperability. Now let’s take a look at the interoperability framework by talking about the key elements required that will ensure interoperability across the enterprise.
Interoperability starts at the top with policy issued by the Office of the Secretary of Defense, or OSD. Through policy issuances, OSD expresses its desired outcomes to the DOD enterprise on a particular topic. The articulation of policy is in the form of mandated business outcomes and is at a high level.
Let’s look at one example. The Office of the Secretary of Defense gives direction to DOD Components to ensure sound and complete property stewardship of assets purchased with American taxpayer dollars. They will convey the policy through the issuance of directives, instructions, or manuals.
MM Note:
This slide is derived from slide 36 of the Module 1 eLearning tool.
Desires a particular outcome
Issues business policy
Business Policy: A required outcome – Property stewardship

12. Interoperability Framework, continued
Laws, Regulations and Policies
Business Rules
Data Standards
Transaction Formats
Business
Process
Business Process
Definition: An assemblage of business rules that collectively form a process. Example: Physical Inventory Management
Narrator: Think of a three-legged stool. This is a good way to think of the interoperability framework. The business process, represented by the seat of the stool, is supported by three legs, depicted here as standard business rules, transactions, and data. This entire stool rests on Laws, Regulations and Policies. We’ll look at this concept in more detail.
To support the mandated business outcome, business processes must be built to support that outcome. A specific example of one of several property stewardship processes is physical inventory management. If DOD purchases materiel, physical inventory management means knowing its location so it can support customer requirements when needed. A detailed and uniform business process is established to accomplish that end.
There are other property stewardship processes, like shelf-life management to ensure the usability of the materiel over time. As in the case of property stewardship, there frequently are multiple business processes that are needed to support a policy directed outcome.
MM Notes:
This slide is derived from slide 37 of the Module 1 eLearning tool.

13. Interoperability Framework, continued
Business Rule Definition: States what must or must not be done. Example: Storage activities must report the ending on-hand inventory balance to the item owner for all items having any balance affecting business activity that day.
Business Object Definition: A collection of data in a specified format that launches a process or reports process results. Example: An order, inventory adjustment, request for payment, etc.
Business Metadata Definition: Characteristics of a data element. Example: Inventory Balance Date = 8 numeric characters (yyyymmdd)
Laws, Regulations and Policies
Business Rules
Data Standards
Transaction Formats
Business
Process
Narrator: To execute the business processes, explicit business rules and responsibilities must be outlined. The rules state what must be done or not done, including conditional statements or exceptions as applicable. The business process is formed through business rules executed in a prescribed order and supported by data standards and information exchange transaction standards that reflect business event initiation or status reporting. As long as all trading partners involved in the process adhere to the business rules, and the data and transaction standards, then interoperability is achieved, regardless of the character or number of trading partners involved.
The illustrative example of physical inventory management will be supported by business objects or transactions, like inventory adjustments and standard data contained within them, such as the date of last inventory or the date of the adjustment.
The metadata associated with a particular data element, such as inventory balance date, ensures proper interpretation of the value conveyed in the “date” data element.
The business process exists to support the OSD policy but each of the legs exists to support the process. If you are missing any one of the components of the stool, then the policy or business outcome will cannot be successfully implemented.
While the OSD establishes policy, everything below the policy as shown on the chart is a part of the DLMS documentation. A policy may be stated in a paragraph; a process to support it may be a hundred pages of DLMS documentation.
MM Notes:
This slide is derived from slide 38 of the Module 1 eLearning tool with slight changes in the layout of the text in graphic. .

14. Types of DLMS Support Support transitioning from the MILS to the DLMS
Replaces all of the MILS transaction formats/associated procedures
Examples: MILSTRIP, MILSTRAP, MILSBILLS
Narrator: Now let’s review the types of capabilities and processes that the DLMS support.
As discussed earlier, DLMS replaces the 80 record position transaction sets and associated procedures. These include MILSTRIP, MILSTRAP and MILSBILLS. Replacing these transactions with the DLMS allows both the business processes and the data content of the transactions to be greatly expanded.
Another great advantage of the DLMS is the capability to add new procedures and transactions where none previously existed. Some examples of these are:
Warehouse Service Advice and Response,
Passive Radio Frequency Identification visibility,
and Catalog Data Exchange and Item Unique Identification.
MM Notes:
This slide is derived from slide 27 of the Module 1 eLearning tool..
Support new processes/capabilities not previously associated with a MILS transaction
Publish the transaction format, add data elements to DLMS Dictionary, and prescribe the business rules/procedures
Examples: Warehouse Service Advice and Response, Passive RFID Visibility, Catalog Data Exchange, IUID

15. Types of DLMS Support, continued
Provide transaction formats for logistics processes that are not administered by the DLMS Program Office
Publish the transaction format/add data elements to DLMS Dictionary
Provide overview of process/references governing policy/process (no procedural detail)
Narrator: Lastly, the DLMS also provide support for some business processes that are managed and administered outside of the traditional DLMS Program Office domain. Examples include:
Stock Readiness (this includes Storage Quality Control Reporting and Stock Screening),
Product Quality Deficiency Reporting,
and Weapon Systems Data Changes.
In these cases, the functional sponsors or executive agents of those areas continue to maintain the detailed procedures and oversight, while the DLMS document the data and transaction standards, as well as a high-level overview of the processing with references to the functional sponsor’s policy documentation.
MM Notes:
This slide is derived from slide 28 of the Module 1 eLearning tool..
Examples: Stock Readiness (Storage Quality Control Report and Stock Screening), Product Quality Deficiency Report, Weapon Systems Data Change

16. DOD’s executive agent for logistics data interchange
Narrator: Now we’ll continue our discussion of the DLMS by exploring the office that overseas the development and maintenance of the DLMS, namely the Enterprise Business Process Standards Office, formerly known as the Defense Logistics Management Standards Office or DLMSO.
MM Notes: This is a screen build. Use appropriate graphics to support.
DOD’s executive agent for logistics data interchange

17. DLMS Program Office Purpose and Mission
Business Process Transformation and Interoperability
To facilitate enterprise integration and continuous process improvements to logistics management and operations while maintaining interoperability by:
Developing business rules that implement DOD policy
Developing and managing the DOD logistics information exchange infrastructure
Publishing detailed procedures that identify who does what, when, and how along the DOD logistics chain
Narrator: The mission and purpose of the Enterprise Business Process Standards Office, also referred to as the DLMS Program Office, is to facilitate and maintain interoperability and continuous process improvements to logistics management and operations. It accomplishes this mission by managing a collaborative process that results in the publication of standard business processes implementing DOD supply policy based on documented business rules, data, and information exchange transactions that implement DOD supply management policy.
The DLMS Program Office also collaborates in managing the information exchange infrastructure and works closely with the Defense Automatic Addressing System known as DAAS, in the delivery of the technical suite of services.
This one point can’t be stressed enough - the transactions along with the business rules and data standards exist to support the business processes that support the execution of laws, regulations and policy.
MM Notes:
This slide is derived from slide 44 of the Module 1 eLearning tool..
Laws, Regulations and Policies
Business Rules
Data Standards
Transaction Formats
Business
Process

18. DOD Consensus Builder The DLMS Program Office administers DOD-wide:
Defense Logistics Management Standards (DLMS)
DOD Physical Inventory Control Program
DLMS Data Management Plan
Military Standards (MILS)
The DLMS Program Office chairs:
DLMS Process Review Committees (PRCs)
Pipeline Measurement Process Review Committee (PM PRC)
DOD Supply Discrepancy Reporting Committee
Joint Physical Inventory Working Group
DoDAAD / MAPAD Committees
Narrator: The DOD has assigned several specific programs to the Enterprise Business Process Standards Office to administer for the DOD enterprise. They are:
the Defense Logistics Management Standards or DLMS
DOD Physical Inventory Program,
the DLMS Data Management Plan,
and the Military Standards or MILS.
The DLMS Program Office is also responsible to chair and administer several committees and groups to carry out its assigned mission to develop and publish standards that support continuous process improvements while maintaining interoperability across the complex supply chain enterprise.
Those groups include:
the DLMS Process Review Committees
the Pipeline Measurement Process Review Committee
the DOD Supply Discrepancy Reporting Committee
the Joint Physical Inventory Working Group
and the DOD Activity Addressing Directory and Military Assistance Program Address Directory process review committees.
The Enterprise Business Process Standards Office is a consensus builder by leading and steering the committees and groups it chairs toward common agreement on exactly how all the trading partners involved in a particular process agree to conduct business with one another.
MM Notes:
This slide is derived from slide 45 of the Module 1 eLearning tool..

19. DLMS Process Review Committees (PRC)
The DLMS Program Office chairs the following:
Supply PRC
Finance PRC
Pipeline Measurement PRC
DoDAAD, MAPAD, SDR, JPIWG and others
Composed of representatives from the DOD components, the U.S. Coast Guard, and participating Federal agencies
Responsibilities include:
Develop and recommend revised policy, procedures, or process improvements
Develop, evaluate, and coordinate proposed DLMS changes
Help resolve problems, violations, and deviations that arise during system operations
Narrator: The DLMS process review committees work hard daily to maintain and administer the DLMS standards. Every organization with a vested interest in a process is invited to participate in the process review committees. These organizations include all DOD components, the U.S. Coast Guard and numerous Federal agencies.
The DLMS committees and groups develop, evaluate, and coordinate proposed DLMS changes, and they help resolve problems, violations, and deviations that arise during system operations.
MM Notes:
This slide is derived from slide 46 of the Module 1 eLearning tool with some changes in the narration.

20. DLMS Governance Process
Business Rules
Data Standards
Transaction Formats
Business
Process
DLMS Configuration Management Process,
DLM Series of Manuals
Systems Development:
- Business Enterprise Architecture (BEA)
- Acquisition & Logistics Functional Strategy &
Component Organization Execution Plans
- Supply Chain Executive Steering Committee (SCESC) System/ADC Tracking
Systems Execution:
DAAS applied syntax & semantic validations
OSD Policy Direction
DoDD E
DoDI
DoDM
BEA & DISR
Directives
Instructions
Regulations
& Manuals
Laws, Regulations & Policies
The DLMS governance process can be depicted by a pyramid. The apex of the pyramid, contains the governing DOD policies. DOD policies cover the entire workings of DOD; those most applicable to the DLMS are the policies that deal with the conduct of business operations and information technology standards and investments. An overview of the key policies impacting the DLMS is at the end of this Module.
Dropping down to the next pyramid tier is where the DOD policies get translated into succinct business processes, the how of the policy execution through the implementation of standard processes, again note the stool graphic. The documentation of the business processes, through application of standard the rules, data, and business event transaction formats is syndicated via the Defense Logistics Manuals. These are the DLM series of manuals. When systems and organizations adhere to the standards contained in the manuals, interoperability is achieved.
Compliance with the DLMS is assured by the base of the pyramid during systems development and during the day-to-day operations. The United States Congress mandated by Law that DOD develop and maintain an overarching business enterprise architecture (BEA) and a process to ensure systems developers comply with that architecture. Compliance with the BEA is enforced by the DOD Component certification in the Integrated Business Framework-Data Alignment Portal (IBF-DAP). The Defense Business Council (DBC) through its Investment Review Board (IRB) uses the Component’s compliancy accretions made within IBF-DAP and its review of the Component Organization Execution Plans (OEPs) for adherence to the DOD Acquisition & Logistics Functional Strategy business goals to determine the funding level of a particular Component’s systems portfolio. So funding is the leverage point to ensure design and implementation compliance. Note that earlier it was stated that one of the Acquisition & Logistics Functional Strategy business goals is the full implementation of the DLMS by 2019.
Lastly minute-to-minute compliance with the DLMS standards is also enforced by DAAS through the implementation of selected validation and business rules that have been programed within the Defense Automatic Addressing System (DAAS) suite of software. Since Transactions Services operates the logistics hub that all DLMS transactions pass through, non-compliance is easily determined; transactions that violate the standards are automatically rejected back to the sending system for correction.
MM Notes:
This slide is derived from slide 29 of the Module 6 storyboard.
Standards Syndication
Compliance
Oversight

21. DLMS Process Review Committees
Narrator: As the screen says, It all starts with an idea for change.
The Enterprise Business Process Standards Office follows a structured but collaborative process model to develop, manage, and maintain the DLMS via process review committees. Ideas and suggestions for improvements are received thru several avenues. Let’s look at this on the next screen.
MM Notes:
This slide is derived from slide 47 of the Module 1 eLearning tool.
It all starts with an idea for change

22. DLMS Process Review Committees, continued
OMB or OSD Policy Guidance Changes
Service or Agency Requirements
DAAS Technical Expertise
Proposed DLMS Changes (PDCs)
Narrator:
A proposed DLMS change, called a PDC, can be initiated due to a new or revised policy;
Or through a recommendation from one or more of the committee representatives to create a new capability, modify an existing process, or to provide a remedy to an observed operational problem.
Finally, DAAS’ technical expertise may uncover necessary changes based on the flow of business transactions in and out of DAAS.
MM Notes:
This slide is derived from slide 48 of the Module 1 eLearning tool.

23. DLMS Process Review Committees, continued
Narrator: The participants in the DLMS committee process are all subject matter or technical experts on the functional business process being worked.
All these proposed changes are received into a collaboration hub, generally via . This is where the magic of artful negotiation and problem solving takes place. The resolution of differences of opinion and approach is a challenge given the number of different players and perspectives, and differing priorities. It is rare that at first pass there is total agreement. However, the knowledge and experience of the committee chairs and willingness of the members to support improved processes allows for a common standard to be achieved almost every time. When agreement cannot be reached, the issue is resolved by the functional proponent at the Office of the Secretary of Defense level. The need to seek resolution at that level is a rarity.
The committees meet formally only periodically, but collaboration is a continuous and daily process via teleconference and . The Enterprise Business Process Standards Office averages five teleconferences per day.
MM Notes:
This slide is derived from slide 49 and its sub charts of the Module 1 eLearning tool.

24. DLMS Process Review Committees, continued
Approved DLMS Changes (ADCs)
Narrator: From these collaborative efforts are derived the results - documented agreements that are published as approved DLMS changes, known as ADCs. This is where the basic rules are written down and stated: the changes in procedures, definitions of new business objects, changes to or new data elements, and other metadata requirements.
MM Notes:
This slide is derived from slide 50 of the Module 1 eLearning tool.
Business Rules
Business Objects
Meta Data
Functional Requirements
DAAS & Components Implement

25. DLMS Process Review Committees
INPUTS
OUTPUTS
A Structured Collaboration Model
OMB/OSD Policy Guidance
Service/Agency Requirements
DAAS Technical Expertise
Narrator: An ADC is essentially a contract among trading partners; a documented negotiated agreement on how all the trading partners have agreed to do business with one another. This becomes the standard that ultimately will be included in the DLMS manual.
MM Notes:
This slide is derived from slide 51 of the Module 1 eLearning tool.
Business Rules
Business Objects
Meta Data
Functional Requirements
MANAGED
TRANSFORMATION
PROCESS
DAAS & Components Implement
Artful Negotiation & Consensus Building
Proposed DLMS
Changes (PDCs)
Approved DLMS
Changes (ADCs)

26. Additional Details Follow
DLMS Change Lifecycle
Component
DLMS PRC
Component(s)
PDC Process Prior to Submission:
Issue Identification: A determination of the problem, process gap or process improvement that is desired.
Socialization within the Component SMEs of the issue and postulation of alternative solutions.
Initial heads-up contact with Component PRC representative and Defense Logistics Management Standards PRC chairperson.
Follow DLM instructions for drafting Proposed DLMS Change (PDC)
Provide unofficial draft copy to Defense Logistics Management Standards PRC chairperson
Internal Component staffing, review, finalization.
Submit PDC to Defense Logistics Management standards through the Component PRC Representative.
Defense Logistics Management Standards Process Review Committee
Structured Collaboration Model
Defense Logistics Management Standards Managed Transformation Process
Artful Negotiation & Consensus Building
ADC Process:
Review ADC and determine affected Component Organizations and systems
Distribute ADC to affected organizations
Prepare system change requests for system developers/integrators
Receive ROM estimates of resources and schedules
Submit to system configuration management board for prioritization, resourcing and scheduling
Perform system lifecycle release management tasks of documentation, coding, testing, and release.
Make necessary change to Component publications
Conduct necessary training
On this chart you see the Life-Cycle of a DLMS change? DLMS changes begin with a component, as you see here on the left, and they end with a component, as you see here on the right. In the middle is the DLMS PRC. When a DLMS change proposal is being drafted for coordination, what is the component doing? They are identifying, what's the issue? What's the problem? What's the gap? What's the procedure or process being supported? You don’t want to just say, I want a new data element. Having a new data element has no context. You always need to put it into the context of a business process. Going back to the earlier stool graphic, start with the process and identify the issue or gap in that process that this PDC will correct. Include a detailed description of new data elements or changes to existing data elements that are required, as well as transaction formats.
The DLMS Program Office requires the component provide a PDC that is a component position. The expectation is that the proposal has been fully socialized and agreed to within the submitting component. The DLMS Program Office will assist in negotiating consensus among the components but not within a component; it's the component PRC lead's responsibility to socialize the proposed change within the component and then present to the DLMS Program Office a single, unified component position.
If the proposed change is complex the submitting Components PRC lead may want to give the DLMS Program Office an early informal heads up. The DLMS Program Office may even solicit Transaction Services technical views in the early draft stage if warranted. Early discussions and brainstorming can often shorten the overall process and ensure success.
The template and instructions for submitting a PDC are in the DLMS Manual, Volume 1, and on the DLMS Program Office web site. The instructions are at the end of the template, and we’ll go through them shortly in this module.
After the internal component staffing is completed and an informal draft has been agreed upon by the component, the Component PRC representative will formally submit the PDC to the DLMS Program Office on behalf of their component. The bottom-line regarding PDC development and submission is that anybody can draft a PDC; however, the DLMS Program Office will only accept PDCs from the designated Component PRC representative.
For now, we’re going to skip over the PRC actions and responsibilities that occur in the center of the chart after the PDC is formally submitted. Those actions and responsibilities will be covered on the next chart. So we’ll jump ahead to the right hand column of actions and responsibilities which are all executed by the Components after the PDC has been signed and becomes and approved DLMS change (ADC).
When that approved DLMS change has been signed and distributed, the component has to go back to work to actually implement the approved changes.
The component has got to go to the configuration management process for each of the systems impacted by the change. The major steps for receipt of the ADC through implementation of the change are as follows:
Review ADC and determine affected Component Organizations and systems
Distribute ADC to affected organizations for impacting.
Prepare system change requests for system developers/integrators
Receive rough order of magnitude estimates of resources and schedules
Submit to system configuration management board for prioritization, resourcing and scheduling
Perform system lifecycle release management tasks of documentation, coding, testing, and software release.
Make necessary changes to Component publications
Conduct necessary training
Now we’re going to back up one step and look at what happens in the process review committee portion of the DLMS change life-cycle.
Additional Details Follow

27. PRC Process Component DLMSO 1 2 3 4 5 6 Solution Documented
ADC Published
Requirement Identified
PDC Prepared
Component
DLMSO
PDC Reviewed for Methodology, Compliance, Completeness
PDC Staffing
Inter- Component Coordination
On this slide we’re going to take a look at the actions that occur in that middle block we skipped over previously. We’ll describe each of the six major steps that occur in what we call the DLMS collaboration and artful negotiation model.
Step 1 in the upper left, starts when the component PRC representative formally submits its draft PDC to the DLMS Program Office. The DLMS Program Office will first review the PDC for completeness to make sure it contains all the necessary information. First and foremost it needs to be clear and understandable to virtually anyone. It must stand on its own providing as much detailed information as is available. The DLMS Program Office will make sure that the processes are identified, any sub processes that are affected are identified; who are the players, entities and their respective roles in the process. The DLMS Program Office will review the proposed procedures to compare them to current guidance and policy to assess full impact of the proposed change and ensure all impacts are fully documented in the change proposal. Data elements and information exchange requirements will be reviewed to ensure that all required modifications and/or additions are fully documented and compliant with DLMS standards. The DLMS Program Office will review the impacts to other organizations and proposed timelines for implementation to ensure that all impacted stakeholders are clearly identified. While timelines are not binding at this stage of the PDC development process, it does provide valuable information to help understand the urgency of the change, especially if system changes are required by components, other than the submitting component. Timelines must be realistic, however. If your proposed change impacts several systems throughout the DOD, you need to allow sufficient time for each of those systems to go through the same system configuration management process that you are, as well as identify the required funding for execution. There will likely be a back and forth dialog with the requester, asking questions, getting answers and refining the PDC information, until the PDC is fully documented. When the PDC is suitable for signing and distribution, the formal staffing process with the PRC begins.
(Step 2) Step 2 begins with the formal acceptance of the PDC by the DLMS Program Office. Within this step, one of the most important reviews occurs by the DLMS Program Office team, and that is to ensure that the proposed DLMS change will ensure interoperability amongst all the supply chain stakeholders, while simultaneously implementing the change from the Component that submitted the PDC. The DLMS Program Office will also ensure that the procedures comply with DOD policy; if there is a conflict, then the DLMS Program Office will pre-coordinate with the appropriate DOD office to determine if the change should proceed ahead, based on either a future modification of DOD policy or a waiver to existing policy. Additionally, the PDC will be fully documented with all the necessary changes to the DLMS manuals and the DLMS Implementation Conventions are drafted. The end of this step is when the PDC is sent to the DLMS Program Office for signature.
(Step 3) Step 3 begins at the point where there is a signed the PDC. The DLMS Program Office then formally distributes the PDC to the designated Component process review committee members. The Component process review committee members review and staff the PDC within their Component soliciting comments and concurrence. The Component process review committee’s members review the comments from their constituency, resolve internal issues and provide a single component response indicating a concurrence or nonconcurrence. If they don’t concur, they must document why and recommend the changes required to the PDC that would enable them to concur. Component representatives can also concur with comment. In this situation, the Component agrees with the intent of the PDC, but is seeking clarification on a couple of issues. All the non-concurrences and the comments will be addressed and adjudicated by the DLMS Program Office staff. This is where the artful negotiation is applied and issues are mitigated. The results of this collaboration and artful negotiation are documented in the resulting approved DLMS change, also known as an ADC. The DLMS Program Office will not publish an ADC until there is full concurrence. That's a firm rule. If the DLMS Program Office can't get the PRC membership concurrence, the issue is raised the applicable office of the secretary of defense for resolution. It’s rare that OSD intervention is required.
(Step 4) Moving to step 4 is where the PDC, modified in accordance with the negotiations of step 3, is redrafted in the form of an approved DLMS change. Color coding, highlighting and underlining conventions are used to ensure that all the changes that occurred during the proposal process are clearly identified within the ADC. This is also the step where all the supporting files are finalized prior to posting to the DLMS Program Office web site. These supporting files may be new DLMS implementation conventions, EDI standard exchange files, or DLMS manual chapters and appendices containing code and procedural changes. When all the foregoing actions of step 4 are complete the ADC is signed.
(Step 5) Once the ADC gets signed, the DLMS Program Office distributes it to the PRC component committee representatives. Each component committee representative is responsible for distributing it within their respective components to everyone that's impacted. This is the point when the component configuration management processes discussed on the right hand side of the previous slide begins. During this step, all files associated with the ADC are posted to the DLMS Program Office web site.
(Step 6) While this step is rarely needed, if for some reason there's a change that impacts the X12 standard, the DLMS Program Office as a voting member of ANSI ASC X12 will follow the protocols to have the standard changed to meet the DOD needs. Changes to the standard are applied to future X12 version releases; however, there are acceptable techniques to implement within the current version release that DOD is using. In those situations, it will be clearly documented in the ADC how to proceed.
DLMS PMO
Draft changes to MILS/DLMS Manuals
DLMS PMO
Concur / Non-Concur with changes
Components
Identification & Evaluation of :
Draft changes to DLMS ICs
Identify procedural gaps
Business Process & Sub Processes
Identify whether solution already exists
Service or Agency impact
Actors, Entities & Roles
Identify interoperability impact
Service or Agency implementation timeframes
Procedures & Business Rules
Data Elements
Identify DOD impact
Barriers to implementation
Information Exchanges
Identify changes to external business policies
Organizational Impact & Timelines
Optimize solution for reuse, effectiveness & efficiency
Existing DOD policy 1
Identify procedural gaps 2 3
OSD Pre-Coordination (as needed)
ADC Staffing
ADC Distribution
Submit to National and International Standards Bodies
DLMS PMO
DLMS PMO
Formalize changes to MILS/DLMS Manuals
DLMS PMO
Publish MILS/DLMS Manuals
Submit Data Maintenance (DM) for change
Formalize changes to DLMS ICs
Publish DLMS ICs
Propose solution for DM
Manage and coordinate Component issues & concerns
Publish SEF Files
Build consensus for solution
Consolidate changes to MILS/DLMS Manuals
Publish XSD Files
Champion solution throughout development & voting
OSD Post-Coordination (as needed) 4 5 6
Build SEF Files
Build XSD Files

28. Next: How to create a PDC & Where to find examples
The following section of this module deals with how to create a PDC, where the instructions for doing so are located, as well as where to find examples of published PDCs and ADCs on the DLMS Program Office web site.

29. Template & Instructions for Change Proposal Submissions
So where do you find the format and instructions for the preparation of a proposed DLMS change. You start by going to the home page of the DLMS Program Office web site and click on “Process Changes” under the tab “eLibrary”. There you will find an active link under “Change Proposal Template”, which opens a WORD document that contains the proposal template to be followed with the instructions of what to enter into each section of the template.

30. DLMS Change Proposal Form
Instructions for completing the form are at the end of the file.
This is the DLMS proposal template which can be downloaded, saved, and used to create a proposed DLMS change. On the succeeding slides we’ll go through each of the template sections and the instructions on what information each section should contain.

31. Preparing a Good PDC GENERAL INSTRUCTIONS
All fields are mandatory unless noted otherwise
The more detail, the better
Pay particular attention to describing the supported business process
Use active voice
Spell out acronyms the first time they are used
Provide full POC contact information; PII will be removed when the PDC is published
Delete instruction pages when done
Submit draft PDC to Component PRC representative
Before we begin going through each of the sections of the proposal template, there are some general instructions that we need to discuss. Following these general guidelines will aid in producing a quality document and speed the overall lifecycle of the DLMS change.”
These are the guidelines that should be followed:
All sections are considered mandatory, unless otherwise notated. If a section is not mandatory it will be specifically noted as optional.
The more detail, the better. We’ve all been trained that written material should be as brief and concise as possible; that’s not the rule for drafting a good PDC. The reason for providing as much detail as possible is the PDC gets a very broad staffing, and most who read it will not have the intimate subject matter knowledge that the drafter of the PDC has. Most reviewers will not have the knowledge to read between the lines, so fill it is incumbent on the writer to fill in those lines.
Pay particular attention to describing the supported business process. You need to put your proposal into the context of the business process that is being changed, so readers can visualize and understand what you're trying to do.
Provide full point of contact information; PII will be removed when the PDC is formally staffed and published. The POC information is critical to getting questions answered in a timely fashion. There are always some questions and clarifications in the early stages of PDC development.
Delete instruction pages when done. The instructions are at the end of the template. Once your draft is done, delete the instruction pages; they don’t need to be included when submitting the PDC to the DLMS Program Office.
Submit draft PDC to Component PRC representative. Remember a PDC can be drafted by anyone, but the DLMS Program Office only accepts formal PDC submissions from the designated Component PRC representative. This rule ensures that the PDC represents the position of the submitting Component.
On the next series of slides we’ll cover the instructions for each section of the proposal template. After completing the instructions for a section, bad and good examples will be provided. As you read each of the bad examples think back to this chart and answer to yourself which of the guidelines has not been followed. Then read the good example to see how it corrects the shortcomings of the bad example.

32. Originating Service/Agency and POC Information
INSTRUCTIONS
ORIGINATING SERVICE/AGENCY AND POC INFORMATION: Identify the person who can discuss the concepts, needs, and the rationale underlying the proposed change. Include the name, organization and office symbol, DSN and commercial telephone number, and electronic mail address.
Technical POC: Technical Point of Contact responsible for this change.
Functional POC: Functional Point of Contact responsible for this change.
ORIGINATING SERVICE/AGENCY AND POC INFORMATION:
Technical POC: John
Functional POC: None
ORIGINATING SERVICE/AGENCY AND POC INFORMATION:
Technical POC: Jane Doe, Defense Logistics Management Standards, J633DD, (703) ,
Functional POC: John Trans, United States Transportation Command, TCJ6, (618) ,
In sections 1a and 1b, identify the person who can discuss the concepts, needs, and the rationale underlying the proposed change. Include the name, organization and office symbol, DSN and commercial telephone number, and electronic mail address. Prior to formal staffing with the PRC, the DLMS Program Office will remove the personal identifying information (PII); however, it will be needed to get answers to questions and refine the PDC while in draft form.

33. Functional Area INSTRUCTIONS FUNCTIONAL AREA:
Primary/Secondary Functional Area: Identify the primary/secondary functional area whose systems, policies, and procedures are most affected by the change (e.g.: Supply, Finance, Pipeline Measurement, Contract Administration, etc.
Primary/Secondary Functional Process: Identify the primary/secondary functional process(es) most affected by the change in procedure or process (e.g.: Distribution, Sustainment, Disposal, Material Return Program, Depot Maintenance, Inventory Adjustment, etc.)
FUNCTIONAL AREA:
Primary/Secondary Functional Area: N/A
Primary/Secondary Functional Process: None
FUNCTIONAL AREA:
Primary/Secondary Functional Area: DoDAAD
Primary/Secondary Functional Process: Reference Data Maintenance
“n section 2a, identify the primary/secondary functional area; that is, identify the primary/secondary functional area whose systems, policies, and procedures are most affected by the change (e.g.: Supply, Finance, Pipeline Measurement, Contract Administration, etc.”
“In section 2b identify Primary/Secondary Functional Process; that is, identify the primary/secondary functional process(es) most affected by the change in procedure or process (e.g.: Distribution, Sustainment, Disposal, Material Return Program, Depot Maintenance, Inventory Adjustment).

34. References INSTRUCTIONS
REFERENCES: List any applicable references (e.g., DLM , Defense Logistics Management Standards (DLMS), Volume 2, Supply Standards and Procedures, Chapter 2). All references should be cited in the order that they appear in the DLMS change to make cross referencing easier.
REFERENCES: To Be Determined
REFERENCES: DLM , Defense Logistics Management Standards (DLMS), Volume 6, Chapter 2, Department of Defense Activity Address Directory
In section 3, list any applicable references (e.g., DLM , Defense Logistics Management Standards (DLMS), Volume 2, Supply Standards and Procedures, Chapter 2). If there are web links to any of the references, include the links.

35. Requested Change(s) – Brief Overview
INSTRUCTIONS
REQUESTED CHANGE(S):
Brief Overview of Change: Provide high-level description of what this change entails.
REQUESTED CHANGE(S):
Brief Overview of Change: Fix the loading of the BLOC data in the DoDAAD.
REQUESTED CHANGE(S):
Brief Overview of Change: This change documents the procedures that are applicable to the Bill of Lading Code (BLOC) in the DoDAAD, and changes the source of input from the DoDAAD Administrators to the Authoritative BLOC information source, USTRANSCOM Reference Data Management (TRDM). This will improve timeliness and accuracy of the BLOC data.
“n the Brief Overview of Change, section 4a, include a high level synopsis of the change being proposed. This should be just a few sentences.

36. Requested Change(s) – Background
INSTRUCTIONS
REQUESTED CHANGE(S):
Background: Provide context for submission of this change. Include procedures, transactions, data elements, processing details in use today.
REQUESTED CHANGE(S):
Background: Bill of Lading Office Code (BLOC) data incorrect in DoDAAD
REQUESTED CHANGE(S):
Background: The rules for how the Bill of Lading Office Code (BLOC) is used are documented in the Defense Transportation Regulation (DTR). The primary user of BLOC information in the DoDAAD is the DLA Distribution Standard System (DSS). The BLOC data in the DoDAAD is currently entered by the DoDAAD Administrators and it is unreliable. Of the 29,000 DoDAACs that contain BLOC information, all but 4 are set incorrectly.
In the Background, section 4b, provide context for submission of this change. Include procedures, transactions, data elements, processing details in use today. Identify where the gaps are that will be addressed by this PDC and the significance and impact of those gaps.

37. Requested Change(s) - Requested Change in Detail
Requested Change in Detail: Load BLOC from TMDS data.
INSTRUCTIONS
REQUESTED CHANGE(S):
Requested Change in Detail: This is a detailed explanation of the changes identified in the overview above. Provide a description of the proposed changes including applicable data elements, transactions, and processes/procedures. The more detail provided here, the easier it will be for those reviewing this change to understand the desired outcome and impact.
REQUESTED CHANGE(S):
Requested Change in Detail: The following procedures will correct the BLOC information in the DoDAAD:
Remove BLOC field from the DoDAAD web updated page and from Army and Air Force input systems.
Clear the existing BLOC information from the DoDAAD database.
Re-populate the BLOC information in the DoDAAD from TRDM.
DAAS establish a link to import BLOC data updates from TRDM on a recurring basis.
In the Describe Requested Change in Detail, section 4c, provide a detailed explanation of the changes identified in the overview above. Provide a description of the proposed changes including applicable data elements, transactions, and processes/procedures. The more detail provided here, the easier it will be for those reviewing this change to understand the desired outcome and impact.

38. Requested Change(s) - Revisions to DLM 4000.25 Manuals
INSTRUCTIONS
REQUESTED CHANGE(S):
Revisions to DLM Manuals: Identify required changes to Defense Logistics Standard Systems (DLSS) and DLMS publications to support this change and provide the specific wording for the changes. Include references to chapter and volume and document all changes to the MILS/DLMS manual procedural text, legacy transaction formats or DLMS ICs, data elements, code values, and any other relevant information. If necessary, this information can be provided as a separate document when the form is submitted. Write the procedural text for the manuals in active voice (e.g., “the storage activity will send the receipt transaction to the owner”, rather than “the receipt transaction is sent to the owner”).
REQUESTED CHANGE(S):
Revisions to DLM Manuals: No change.
REQUESTED CHANGE(S):
Revisions to DLM Manuals: This change will impact the DoDAAD User Guide maintained by Transaction Services.
C Civilian government organizations (e.g., local government agencies or police department), contact the appropriate General Services Administration (GSA) DoDAAC Service Point to have a DoDAAC assigned.
Special Programs. Non-DOD and non-federal programs requiring DoDAACs are controlled under unique series DoDAACs beginning with numeric followed by alpha characters in the first two positions. Among others, the programs include programs authorized by Congress for state and local entities to purchase material from Federal sources. DOD/Federal Agency sponsors of these programs are designated as DoDAAC monitors. Contact DLMSO for guidance on establishing a DoDAAC series for a new special program.
In the Revisions to DLM Manuals, section 4d, identify required changes to Defense Logistics Standard Systems (legacy MILS processes and transactions) and DLMS publications to support this change and provide the specific wording for the changes. Include references to chapter and volume and document all changes to the MILS/DLMS manual procedural text, legacy transaction formats or DLMS Implementation Conventions, data elements, code values, and any other relevant information. If necessary, this information can be provided as a separate document when the form is submitted.

39. Requested Change(s) - Proposed Transaction Flow
INSTRUCTIONS
REQUESTED CHANGE(S):
Proposed Transaction Flow: Illustrate for clarification where new transactions or revised routing rules are applicable.
REQUESTED CHANGE(S):
Proposed Transaction Flow: TRDM to DoDAAD.
REQUESTED CHANGE(S):
Proposed Transaction Flow: DAAS and USTRANSCOM will establish an automated interface between TRDM and DoDAAD to electronically transmit the initial update of the BLOC data field in the DoDAAD. After the initial load, any updates to the BLOC data in TRDM will be automatically pushed to the DoDAAD.
In section 4e describe or provide a drawing of the proposed transaction flow; illustrate for clarification where new transactions or revised routing rules are applicable. Processes are frequently easier to understand when a graphic depiction is provided.

40. Requested Change(s) - Alternatives
INSTRUCTIONS
REQUESTED CHANGE(S):
Alternatives: Identify and discuss known alternate approaches to resolve the problem or issue.
REQUESTED CHANGE(S):
Alternatives: None.
REQUESTED CHANGE(S):
Alternatives: Continuing to rely on manual data entry of this information by the CSP will further perpetuate the unreliability of the BLOC data, both in data quality and timeliness, since the CSPs are not the authoritative source for BLOC data as it relates to transportation office DoDAACs.
In section 4f describe the alternatives that were considered. Identify and discuss known alternate approaches to resolve the problem or issue. A discussion of the alternatives considered and the reasons for discounting them such as too labor intensive, to costly, or sub-optimal aid reviewers in understanding why the proposed approach was selected.

41. Reason for Change INSTRUCTIONS
REASON FOR CHANGE: Provide a description of why this change is being made.
REASON FOR CHANGE: Bad data.
REASON FOR CHANGE: BLOC data in DoDAAD is currently unreliable, both in data quality and timeliness of updates.
In section 5 provide a description of why this change is being made. This could be as simple as stating that the change is necessary to implement a new policy or a revision to existing policy. If the change isn’t policy driven; this section is where you provide available facts, figures and anecdotal information that will shed additional light on the issue or gap that this proposed change will correct.

42. Advantages and Disadvantages
INSTRUCTIONS
ADVANTAGES AND DISADVANTAGES:
Advantages: Identify both tangible and intangible benefits expected from adoption of the change. Include benefits both within and beyond the primary functional area of the MILS/DLMS, especially benefits accruing to DOD. Address what happens if nothing is done. Quantify both tangible and intangible benefits and advantages. Show computation of dollar values where appropriate. Demonstrate why the proposed solution is more advantageous than the alternatives.
Disadvantages: Indicate known or potential problems and costs associated with the proposal. Consider disadvantages both within and beyond the primary functional area of the MILS/DLMS. Quantify both tangible and intangible costs and disadvantages. Show computation of dollar values where appropriate.
ADVANTAGES AND DISADVANTAGES:
Advantages: Better BLOC data.
Disadvantages:
ADVANTAGES AND DISADVANTAGES:
Advantages: The change will ensure that BLOC data is maintained in a current and accurate condition from the authoritative data source.
Disadvantages: None noted.
For the advantages, identify both tangible and intangible benefits expected from adoption of the change. Include benefits both within and beyond the primary functional area of the MILS/DLMS, especially benefits accruing to DOD. Address what happens if nothing is done. Quantify both tangible and intangible benefits and advantages. Show computation of dollar values where appropriate. Demonstrate why the proposed solution is more advantageous than the alternatives.
For the disadvantages indicate known or potential problems and costs associated with the proposal. Consider disadvantages both within and beyond the primary functional area of the MILS/DLMS. Quantify both tangible and intangible costs and disadvantages. Show computation of dollar values where appropriate.

43. Assumptions/Additional Comments/ Additional Functional Requirements
INSTRUCTIONS
ASSUMPTIONS USED OR WILL BE USED IN THE CHANGE OR NEW DEVELOPMENT: (OPTIONAL) Indicate any assumption about the existing environment that may impact the development or implementation of the proposed change.
INSTRUCTIONS
8. ADDITIONAL COMMENTS TO CONSIDER: (OPTIONAL) Indicate any additional comments to consider not previously described.
INSTRUCTIONS
9. ADDITIONAL FUNCTIONAL REQUIREMENTS: (OPTIONAL) Indicate additional functional requirements not documented elsewhere.
Sections 7, 8, and 9 are optional sections but should not be dismissed for expediency.
Section 7 is where you document any assumptions that were used in the development of the PDC. Indicate any assumption about the existing environment to include personnel, organizational, equipment, or technology that may impact the development or implementation of the proposed change.
Section 8 is where you can enter any additional comments that should be considered during the review of the PDC but didn’t seem to fit appropriately in other sections of the PDC.
Section 9 provides an opportunity to indicate any additional functional requirements that didn’t seem to fit or were not documented elsewhere.

44. Estimated Time Line/Implementation Target
INSTRUCTIONS
ESTIMATED TIME LINE/IMPLEMENTATION TARGET: (Required) Indicate desired/proposed implementation timeline. If this change is associated with a Component-mandated change, provide the planned implementation date.
ESTIMATED TIME LINE/IMPLEMENTATION TARGET: Unknown.
ESTIMATED TIME LINE/IMPLEMENTATION TARGET: The changes will be implemented into TRDM and DoDAAD on November 1, 2012.
The estimated time line and/or implementation time line or implementation target date should be entered in section 10. If this change is associated with a Department-wide policy or Component-mandated change, provide the planned implementation date. Be sure to choose target dates that are realistic, especially if other Component systems have to make changes. Not all system program offices are on the same configuration management release cycles.

45. Estimated Savings/Cost Avoidance
INSTRUCTIONS
11. ESTIMATED SAVINGS/COST AVOIDANCE ASSOCIATED WITH IMPLEMENTATION OF THIS CHANGE: If known, indicate estimated savings or cost avoidance associated with this change.
ESTIMATED SAVINGS/COST AVOIDANCE ASSOCIATED WITH IMPLEMENTATION OF THIS CHANGE:
11. ESTIMATED SAVINGS/COST AVOIDANCE ASSOCIATED WITH IMPLEMENTATION OF THIS CHANGE: None noted.
In section 11 enter the estimated savings and or cost avoidance associated with the implementation of this change. Put forth your best effort to provide tangible or intangible savings or cost avoidances associated with this change. Time savings, orders of magnitude and extrapolations from previous studies, analyses or audit findings can be used. The more information that can be provided with regard to value, the more likely that resources to implement will be provided.

46. Impact – New DLMS Data Elements
INSTRUCTIONS
IMPACT: Any additions or changes to data elements will be inserted by DLMS Program Office (Example: Data Content/Procedures: Identify additional specific information requirements that will be added, revised, or deleted as a result of this change.)
New DLMS Data Elements: Example: This PDC/ADC adds the following new DLMS Data Elements; they are not included in any previous DLMS transactions. Provide the data element name with the definition and data characteristics.
IMPACT:
New DLMS Data Elements: N/A
IMPACT:
New DLMS Data Elements: There are no new DLMS data elements introduced by this change.
IMPACT: Any additions or changes to data elements will be inserted by DLMS Program Office. (Example: Data Content/Procedures: Identify additional specific information requirements that will be added, revised, or deleted as a result of this change.)
New DLMS Data Elements: Example: This PDC/ADC adds the following new DLMS Data Elements; they are not included in any previous DLMS transactions. Provide the data element name with the definition and data characteristics.

47. Impact – Changes to DLMS Data Elements
INSTRUCTIONS
IMPACT:
b. Changes to DLMS Data Elements: Example: This PDC/ADC changes the usage of the following existing DLMS Data Elements. Provide the data element name (or revised data element name) with the revised definition and/or revised data characteristics.
IMPACT:
Changes to DLMS Data Elements: N/A
IMPACT:
Changes to DLMS Data Elements: There are no changes to existing DLMS data elements introduced by this change.
Changes to DLMS Data Elements: Example: This PDC/ADC changes the usage of the following existing DLMS Data Elements. Provide the data element name (or revised data element name) with the revised definition and/or revised data characteristics.

48. Impact – Automated Information Systems
INSTRUCTIONS
IMPACT:
Automated Information Systems (AIS): Identify specific AIS impacted by this change.
IMPACT:
Automated Information Systems (AIS): Unknown
IMPACT:
Automated Information Systems (AIS):
There are no changes required to Service/Agency Automated Information Systems
USTRANSCOM TRDM to establish automated update capability with DoDAAD for BLOC data.
Under the heading Automated Information Systems (AIS), identify any specific AISs impacted by this change. If you know the names of the AIS that need to implement this change, it is extremely important to list them here; this will assist the Component PRC representatives in staffing the PDC with the right offices to assess impacts in their PDC response. If there are impacts to enterprise visibility systems, such as United States Transportation Command’s Integrated Data Environment – Global Transportation Network Convergence, also known as IGC, or Transaction Services Web Visual Logistics Information Processing System, more commonly called WebVLIPS, be sure to call those impacts out.

49. Impact – Transaction Services
INSTRUCTIONS
IMPACT:
Defense Automatic Addressing System (DAAS): Identify impact to DAAS or DAAS maps for MILS-DLMS or other transaction format conversion.
IMPACT:
Transaction Services: N/A
IMPACT:
Transaction Services: Transaction Services will work with USTRANSCOM to setup an automated data feed of BLOC data from TRDM and update the DoDAAD whenever the BLOC data is changed in TRDM.
Under the heading DAAS, identify any impact to DAAS processing or DAAS maps for MILS-DLMS or other transaction format conversions.

50. Impact – Non-DLM 4000.25 Series Publications
INSTRUCTIONS
IMPACT:
e. Non-DLM Series Publications: List any non-DLMS/MILS publications that would be affected by this change (e.g., if the change affects instructions published in an AFMAN, the specific AFMAN should be listed here).
IMPACT:
Non-DLM Series Publications: Unknown
IMPACT:
Non-DLM Series Publications:
AFI , Chapter 2
NC , Chapter 4
Under the heading Non-DLM Manual Publications, list any non-DLMS/MILS publications that would be affected by this change (e.g., if the change affects instructions published in an Air Force manual, the specific manual should be listed here). Same holds true, if a change is required to DOD policy and OSD has agreed to it, identify the DOD issuance that is impacted along with the required change.

51. DLMS Process Review Committees
INPUTS
OUTPUTS
A Structured Collaboration Model
OMB/OSD Policy Guidance
Service/Agency Requirements
DAAS Technical Expertise
Business Rules
Business Objects
Meta Data
Functional Requirements
MANAGED
TRANSFORMATION
PROCESS
OSD Policy Guidance
Trading Partner Requirements & SMEs
DLMS PMO SMEs & Technical Expertise
Transaction Services Technical Expertise
DAAS & Components Implement
Artful Negotiation & Consensus Building
We’ve talked about the entire life-cycle of a DLMS change from the point of issue identification through the artful negotiation and staffing to the point it is issued as an approved DLMS change.”
You can see on this slide we’re on the right side and it’s now up to the components to implement it within their systems. You saw earlier that there’s still a great deal of effort necessary to implement.
On the next series of charts we’re going to look at where you find approved DLMS changes on the DLMS Program Office web site and how ADCs get incorporated into the DLMS Manual.
Proposed DLMS
Changes (PDCs)
Approved DLMS
Changes (ADCs)

52. Where do I find a list of Approved DLMS Changes (ADC)?
If you’re looking to find an ADC, once again you start on the DLMS Program Office home page and select the quick link entitled ADCs.” Doing so will bring up the page shown on the next slide.

53. Most recent ADCs appear first
Most recent ADCs appear first. Older changes can be selected from the “More approved changes” links.
This works the same way as the PDCs page you saw earlier. The most recent ADCs will appear first. Older changes can be selected from the approved changes ADC number range links at the top of the page, which will help narrow the search.
Let’s assume we’re looking for ADC We’ll pick ADC number range 1000 – That will bring up all the ADCs whose number falls in that range. Then, we can select ADC 1082.

54. Example of a completed ADC.
Here you see the first page of the attachment to ADC At this point you can download the file or print it.

55. This example of an ADC includes changes to a DLMS IC.
If this ADC caused a change to any of the DLMS implementation conventions you’ll see a table like this one that will identify the implementation conventions that were changed, where in that implementation the change occurred and exactly what has changed.
We introduced these types of tables in Module 2, and discussed how to use them.
Looking at item 2. In this table we see that the implementation convention for the 830D had a change to the LM segment located in position 3900 of Table 2 of the IC. The change was made to state that for this transaction, the LM segment must be used.

56. DLMS Manual Formal Changes
Each ADC that caused a change is listed in the Formal Change Letter.
Two or three times a year, all the ADCs that have been signed since the last time the DLMS Manual was updated are incorporated into the manual as a DLMS Manual Formal Change. The Manual is maintained and updated by individual volume.
This slide shows the cover letter of a DLMS Manual Formal Change to Volume 2. Periodically, after there have be a lot of change letters issued to a particular Volume, the entire Volume will be reissued. The reissuance of a Volume establishes a new baseline; therefore, the change letters after reissuance begin again with change 1.
Note that all the ADCs that are incorporated in the change are listed in the change letter.

57. Formal Change Letter identifies all files replaced since last change.
The change letter also identifies all the files that have been updated, removed or added as a result of this change issuance.

58. The DLMS manual documents the changes made since the previous published change.
“his slide shows the change history that is applicable to the Volume. Each time a formal change letter is published, it will be added to the change history. Each Volume of the DLMS Manual has its own change history which is located after the Foreword for that Volume.”
On this slide you see the four columns of the change history log.
The first column identifies the ADC number
The second column contains the date the ADC was signed.
The third column contains a short description of what was contained in the ADC and the portions of the volume that were impacted by the change.
And finally, the fourth column identifies the DLMS Manual Volume change number which incorporated the ADC into that Volume of the Manual.

59. The DLMS manual lists the ADCs applied since the last publication change.
Note that the first column of the change history identifies the ADC number of the changes that have been included in this Volume of the DLMS Manual.

60. Common PDC Questions & Answers
Where are the instructions for filling out a Proposed DLMS Change?
DLMS Web site under “eLibrary”/”Process Changes“
Who can prepare and submit a Proposed DLMS Change?
Anyone, but it must be submitted to DLMS via the Component designated representative to the applicable DLMS Process Review Committee.
Who assigns the PDC Number and what is it used for?
The DLMS Program Office assigns a PDC Number to each proposed DLMS change submitted and the PDC # is used as a configuration management tool.
Question 1 is where do you find the template and instructions for filling out a Proposed DLMS Change? The answer is you can find them in DLM , Volume 1, Chapter 3, and on DLMS Web site under “eLibrary”/”Process Changes”.
Question 2 is who can prepare and submit a Proposed DLMS Change? The answer is anyone, but it must be submitted to the DLMS Program Office via the Component designated representative to the applicable DLMS Process Review Committee.
Question 3 is who assigns the PDC Number and what is it used for? The answer is that the DLMS Program Office assigns a PDC Number to each proposed DLMS change submitted and the PDC number is used as a configuration management tool.

61. Common PDC Questions & Answers
Why are there gaps in the ADC numbers published on the DLMS Program Office web site.
Not all ADCs complete the DLMS change lifecycle in the same amount of time.
Not all PDCs become ADCs.
Some PDCs may be combined into a single ADC, if they are closely tied together.
How long does the PDC/ADC cycle take?
Depends on complexity, priority of the change and how well PDC(s) are developed. Could be as little as 30 days for administrative changes or simple code value additions or could take longer for complex new business processes.
Question 4, why are there gaps in the ADC numbers published on the DLMS Program Office web site?
Not all ADCs complete the DLMS change lifecycle in the same amount of time. Some DLMS changes may be completed quickly, while others may take a long time, especially if there are significant comments and/or non-concurrences that need to be adjudicated.
Not all PDCs become ADCs. Occasionally a PDC may be withdrawn when it is deemed that the requirement is no longer valid or has been overcome by events.
Some PDCs may be combined into a single ADC, if they are closely tied together.
Question 5 is how long does the PDC/ADC cycle take?
The answer depends on the complexity, priority of the change and how well the initial draft of PDC is developed. They can take as little as 30 days for administrative changes or a simple code value additions, or it could take several months to a year for highly complex changes or new business processes with impacts to many systems. In these cases, the challenge is to ensure that interoperability is maintained with those legacy systems that are unable to implement the change.

62. Summary
The DLMS are a broad base of DOD-approved business rules, standards, objects and processes designed for total logistics support.
The DLMS Program Office employs a time proven structured collaboration model to ensure support of needed business process improvements while maintaining interoperability across the enterprise.
Anyone can submit a proposed DLMS change (PDC) through their designated DLMS Process Review Committee (PRC) representative.
Instructions are contained in the DLMS Manual, DLM , Volume 1, & the DLMS Program Office web site
The DLMS Program Office chairs the DLMS PRCs which review, staff and revise PDCs until they, in most cases, become and are published as approved DLMS changes (ADCs).
The following summarizes the key points we’ve covered in this module.
DLMS is a broad base of DOD-approved business rules, standards, objects and processes designed for total logistics support.
Defense Logistics Management Standards Office employs a time proven structured collaboration model to ensure support of needed business process improvements while maintaining interoperability across the enterprise.
Anyone can submit a proposed DLMS change (PDC) through their designated DLMS Process Review Committee (PRC) representative.
Instructions are contained in the DLMS Manual, DLM M, Volume 1, Appendix 1 & the Defense Logistics Management Standards Office Web site
Defense Logistics Management Standards Office chairs the DLMS PRCs which review, staff and revise PDCs until they, in most cases, become and are published as approved DLMS changes (ADCs).

63. Module 11 Quiz
Question 1: Where can the instructions be found for preparation of a proposed DLMS change (PDC)?
a) The DOD Directive
b) DODM
c) DLMS Program Office Web site
Question 2: Who can draft a proposed DLMS change and who must submit PDCs to Defense Logistics Management Standards Office?
a) Component PRC Representative
b) Anyone
c) Flag level Officer
Question 3: Where are Approved DLMS changes published?
a) DOD Directive
b) DLMS Program Office Web site
c) Yellow Pages

64. End of Module 11