1. Defense Logistics Management Standards (DLMS) Introductory Training
This Module builds upon the previous modules by describing in detail how changes to the DLMS are managed. The preceding Modules stress the great flexibility of the DLMS business process rules and the transactions supporting the introduction of improvements to business processes and integration of new technologies. This Module addresses the role of the DLMS Process Review Committees in managing the DLMS change management process and the roles and responsibilities of the Components in generating proposed DLMS changes (PDCs), reviewing and commenting on proposed changes, approving DLMS changes (ADCs) and implementing ADCs in their automated implementation systems, procedures and training programs. The Module walks the class through the process of filling out the PDC template to submit a Proposed DLMS Change.
Creating/Reengineering
DOD Logistics Business Processes

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 where Module 6 fits into the DLMS Introductory Training catalog.

3. Module 6 – Creating / Changing DOD Logistics Business Processes
Role of Process Review Committees (PRCs)
How to develop a DLMS change
This Module will cover:
The role of a Process Review Committee (PRC).
Describe how to develop a DLMS change.

4. Module Objectives Students will gain basic understanding of:
Explain the role of a Process Review Committee (PRC).
Describe/explain the life cycle of a DLMS change.
Describe the key components of a Proposed DLMS change.
The objectives for this module are:
Explain the role of a Process Review Committee (PRC).
Describe/explain the life cycle of a DLMS change.
Describe the key components of a Proposed DLMS change.

5. 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
Standards Syndication
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.
Compliance
Oversight

6. 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
This graphic portrays the DLMS process review committee (PRC) methodology. The DLMS PMO Chairs follow a structured collaborative process model to develop, manage, and maintain the DLMS processes. Most of DLMS Training Module 6 is devoted to detailing the proposal of DLMS changes, staffing of the change, and the issuing of approved changes and maintenance of the DLMS manuals and supporting documentation.
There are several means of inputs to the DLMS PRCs. A proposed DLMSs change (PDC) can be initiated due to a new or revised policy; a recommendation from one or more of the committee representatives to create a new capability or modify and existing process or to provide remedy to an observed operational problem can be submitted. Lastly, DAAS technical expertise may uncover necessary changes based on the flow of business transactions in and out of DAAS. The participants in the DLMS committee process are all subject matter or technical experts on the functional business process being worked.
All these inputs are received into a collaboration hub. This is where the magic of artful negotiations and problem solving takes place. The resolution of differences of opinion and approach are a challenge given the number of different players, different 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 achieve 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 periodically, but the work of, for example, the Supply PRC, goes on every single day via teleconference and . DLMS PMO averages two teleconferences per day; collaboration, is a continuous every day process.
Out of this collaboration hub come the results and deliverables, a documented agreement that is published as an approved DLMS change (ADC). This is where the basic rules get written down and stated: what are the changes in procedures, definition of new business objects, changes or new data elements, and other metadata requirements. The output, the 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 agreed to standard which ultimately will be included in the DLMS manual.
DAAS & Components Implement
Artful Negotiation & Consensus Building
Proposed DLMS
Changes (PDCs)
Approved DLMS
Changes (ADCs)

7. 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

8. 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

9. 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.

10. 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.

11. DLMS Change Proposal Form
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.
Instructions for completing the form are at the end of the file.

12. 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.

13. 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.

14. 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
“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).
FUNCTIONAL AREA:
Primary/Secondary Functional Area: DoDAAD
Primary/Secondary Functional Process: Reference Data Maintenance

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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:
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.
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.

24. 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.
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.
INSTRUCTIONS
9. ADDITIONAL FUNCTIONAL REQUIREMENTS: (OPTIONAL) Indicate additional functional requirements not documented elsewhere.

25. 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.
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.
ESTIMATED TIME LINE/IMPLEMENTATION TARGET: The changes will be implemented into TRDM and DoDAAD on November 1, 2012.

26. 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:
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.
11. ESTIMATED SAVINGS/COST AVOIDANCE ASSOCIATED WITH IMPLEMENTATION OF THIS CHANGE: None noted.

27. 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: 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: There are no new DLMS data elements introduced by this change.

28. 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
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: There are no changes to existing DLMS data elements introduced by this change.

29. Impact – Automated Information Systems
INSTRUCTIONS
IMPACT:
Automated Information Systems (AIS): Identify specific AIS impacted by this change.
IMPACT:
Automated Information Systems (AIS): Unknown
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.
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.

30. 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.

31. 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
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.
IMPACT:
Non-DLM Series Publications:
AFI , Chapter 2
NC , Chapter 4

32. 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
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.
DAAS & Components Implement
Artful Negotiation & Consensus Building
Proposed DLMS
Changes (PDCs)
Approved DLMS
Changes (ADCs)

33. 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.
Where do I find a list of Approved DLMS Changes (ADC)?

34. 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.

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. 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.

42. 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.

43. 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).

44. Module 6 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

45. End of Module 6