Defense Logistics Management Standards (DLMS) Implementation Strategy Guide

Transcription

1 Defense Logistics Management Standards (DLMS) Implementation Strategy Guide Version 1.10 Revised: June 23, 2015

2 [This Page Left Intentionally Blank]

3 FOREWORD The Defense Logistics Standard System (DLSS), also referred to as MILS, served the DOD well for over 50 years, but today s logisticians demand for information has grown exponentially to the point that the inflexible fixed length MILS transactional messages cannot satisfy that requirement. DOD issued policy to Kill MILS as early as 1998 and senior leadership reaffirmed that goal in Over time, a variety of circumstances and events impacted the ability of the Department of Defense to meet the DLMS mandate including; decreased funding, implementation of Enterprise Resource Planning (ERP), competing priorities and the never-ending quest to do more with less. Senior DOD logistics leadership continues to recognize the need to modernize its information exchange process and formally mandated the dissolution of MILS by 2019 in the Acquisition, Technology and Logistics Functional Business Strategy Document. The Defense Logistics Management Standards (DLMS) is the replacement; it is founded on the widely used, mature American National Standards Institute (ANSI) Accredited Standards Committee (ASC X12) and identified as one of the key enterprise standards in the DOD Business Enterprise Architecture. DLMS not only subsumed all the functional capabilities of the MILS, but has taken joint logistics to the next level by introducing new capabilities not previously possible. DOD Logistics highest priorities are dependent upon DLMS implementation; among them are Financial Improvement and Audit Readiness (FIAR) supported by the Standard Financial Information Structure (SFIS) and Standard Line of Accounting (SLOA), Strategic Network Optimization (SNO), Item Unique Identification (IUID), Government Furnished Property (GFP), and passive Radio Frequency Identification (prfid). Interest in eliminating MILS and implementing DLMS has risen considerably. The fiscal environment will be constrained for the foreseeable future making the choices among competing priorities for resources increasingly difficult. Components that have not yet implemented the DLMS must make doing so one of their top priorities to achieve efficiencies and compliance with DOD mandated initiatives and to enable certification of DLMS compliance and funding approval by the Investment Review Board (IRB). Interest in DLMS is at a peak and Components are asking lots of questions about format, business rules, implementation assistance, etc.. It is this ground swell of interest that compelled the Defense Logistics Management Standards Office to produce the DLMS Implementation Strategy Guide. The audience for this publication ranges from Senior Logistics leaders, to functional subject matter experts, and to technical system program office developers. This guide walks through the Ten Steps to Success providing a methodical approach for completing the transition. The guide provides enough detail to capture your interest and get you on your way to the next generation of logistics processing, constrained only by your imagination. The Defense Logistics Management Standards Office stands ready to support any and all Components in making the transition to DLMS a resounding success. DONALD C. PIPP Director DLA Logistics Management Standards Office

4 [This Page Left Intentionally Blank]

5 Revision History Version Revision Date Description Entered By 1.0 7/12/2013 Initial publication Heidi Daverede 1.1 8/2/2013 Administrative corrections Heidi Daverede 1.2 9/13/2013 Expanded POC information Larry Tanner 1.3 2/28/2014 Changed DoD R to DoDM Larry Tanner 1.4 7/17/2014 Updated DLMSO org chart Larry Tanner 1.5 9/2/2014 Updated DoDD reference, DLMS projections, and new paragraph to address DLMS compliance by /12/2015 Updated DoDD E references due to name change and publication. Larry Tanner Larry Tanner 1.7 4/27/2015 Updated ACART to IBF-DAP Larry Tanner 1.8 6/3/2015 Corrected a page number error (duplicate) Larry Tanner 1.9 6/17/2015 Administrative corrections throughout Larry Tanner /23/2015 Updated DLA TS POCs Larry Tanner

6 [This Page Left Intentionally Blank]

7 Table of Contents Section 1 - Introduction... 1 S1.1. General...1 S1.2. Definition...2 S1.3. Background...3 S1.4. Mission Requirements...3 S1.5. Interoperability Challenge...4 S1.6. DLMS Foundation Policies...4 S1.7. DLMS Compliance Legislative and DoD Policy Authority Chain...6 S1.8. DLMS Levels of Compliance:...7 S1.9. DLMS Compliance Oversight...9 S1.10. Where We Are and Where We Are Going...9 Section 2 - ANSI ASC X12 Standard is the Foundation for the DLMS S2.1. Breadth of Usage...11 S2.2. Key Building Blocks...11 S2.3. Data Element...11 S2.4. Data Segment...13 S2.5. EDI Field and Record Delimiter Characters S2.6. Data Segment Loops...15 S2.7. Transaction Set Detail...16 S2.8. Functional Group (GS/GE Segments)...17 S2.9. Interchange Control Header and Trailer (ISA/IEA Segments)...17 S2.10. Summary of X12 Structure...18 S2.11. XML Standards...19 S2.12. ANSI ASC 12 Governance and DLA Logistics Management Standards Office Participation...21 Section 3 - DLMS Use of Accredited Standards Committee X S3.1. Functionality Coverage...23 S3.2. Versions/Releases...23 S3.3. DLMS Implementation Conventions...24 S3.4. DLMS Implementation Convention Structure...24 S3.5. DLMS Notes...25

8 S3.6. Code Sources...26 S3.7. DLMS Logistics Qualifiers...26 Section 4 - Defense Logistics Management Standards Mapping S4.1. Data Mapping...29 S4.2. Data Transformation...29 S4.3. MILS-DLMS EDI Map Construct...29 S4.4. XML Mapping...31 S4.5. Using Maps...31 Section 5 - DLMS Change Management Process S5.1. General...33 S5.2. Submission of PDCs...33 S5.3. Staffing of DLMS Changes...33 Section 6 - The Journey MILS to DLMS S6.1. Getting Started...35 S6.2. Top Management Commitment...35 S6.3. Define the Task:...35 S6.4. Conduct an Inventory...36 S6.5. Develop High Level Generic Strategy...38 S6.6. Suggested Steps for a DLMS Implementation Project...39 Appendix 1 - Training Synopsis Appendix 2 - DLMS Change Process Steps Appendix 3-10 Steps to Success Appendix 4 - DLA Logistics Management Standards Office Support Appendix 5 - DLA Transaction Services Support Appendix 6 - Detailed Discussion of DLMS Migration Step Appendix 7 - Detailed Discussion of DLMS Migration Step Appendix 8 - Detailed Discussion of DLMS Migration Step Appendix 9 - Detailed Discussion of DLMS Migration Step Appendix 10 - Detailed Discussion of DLMS Migration Step

9 Section 1 - Introduction S1.1. General S The Department of Defense mandated the elimination of the Defense Logistics Standard Systems (DLSS)/Military Standard Systems (MILS) and the implementation of the Defense Logistics Management Standards (DLMS). DLMS capitalize on the evolving commercial and industry standards that enable transformation of the logistics business enterprise. S This implementation strategy provides the details on the objectives, responsibilities and approaches that will support and augment planned Component implementation and acceleration of DLMS. It also provides detailed planning documents and examples to aid in the conversion process for legacy systems and for the implementation of the DLMS in new systems. The DLMS will enable the improvement of key business processes that support the Warfighter mission. S DLMS Implementation Strategy Guide Content and Usage. This document is applicable to a broad audience including Component top and middle managers, program managers, functional subject matter experts, and technical system developers. Sections 2, 3 and 4 are highly technical in nature and geared more toward functional subject matter experts and technical system developers. To assist the reader a summary of the content and general applicability follows: S Section 1 is applicable to all readers and covers the mission need for the DLMS mission, legislative and DoD policy authorities for the DLMS, the DLMS change management process, and the governance processes to include the DoD Business Enterprise Architecture (BEA) and Investment Review Board (IRB). S Section 2 is geared toward the technical developers and functional subject matter experts that require an understanding of the disciplined architectural building block composition of the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 standard upon which the DLMS rely. The reader will gain an appreciation for how the rigid architecture delivers a flexibility to convey virtually unlimited information. S Section 3 explains how the DLMS build upon the underlying ANSI ASC standard and applies specific logistics business event context through coding, business rules and notes. S Section 4 explains how interoperability is accomplished allowing for an incremental transition to the DLMS through use of the translation/mapping capabilities of DLA Transaction Services. S Section 5 describes how changes to the DLMS are managed including the submission of proposed changes, their staffing, adjudication, approval, publication and syndication. Page 1

10 S Section 6 provides the reader with the key steps previously executed by successful implementers of the DLMS. S Appendices are referred to in the sections provide a more granular level of detail as applicable. S1.2. Definition S The DLMS is a broad base of business rules, to include uniform policies, procedures, time standards, transactions, and data management, designed to meet DoD requirements for global supply chain management system support. DLMS enables logistics operations to occur accurately and promote interoperability between DoD and external logistics activities at any level of the DoD organizational structure. The DLMS encompasses standardization of logistics processes including, but not limited to: Military Standard Billing System (MILSBILLS), Military Standard Transaction Reporting and Accountability Procedures (MILSTRAP), Military Standard Requisitioning and Issue Procedures (MILSTRIP), and Supply Discrepancy Reporting. Developed in collaboration with representatives from the Military Departments, Defense Agencies, and participating Federal Agencies, the DLMS accommodates the new Enterprise Resource Planning (ERP) system processes and implementation, while supporting legacy system data exchange requirements. S The DLMS include procedures, data standards, code lists, metrics, policies, and transaction formats. The two types of DLMS data transmission formats are: S Approximately 66 DLMS Electronic Data Interchange (EDI) Implementation Conventions (IC) based on American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 transaction sets consolidates the functionality of 500+ legacy MILS transaction formats S DLMS XML Schemas one for each DLMS IC S The DLMS maintain the capability to communicate legacy system information requirements while expanding to support emerging and evolving initiatives solely dependent on the implementation of the DLMS. Examples are: Item Unique Identification (IUID) Base Realignment And Closure (BRAC) Passive Radio Frequency Identification (prfid) Financial Improvement Audit Readiness (FIAR) Page 2

11 S1.3. Background S In 1962, the DoD established the MILS 1 to realize the advantages of advancing computer technology and ensure interoperability. After decades of successful use, the MILS information exchange formats are technically obsolete and an obstacle to satisfying the expanding DoD functional process needs. The migration to the new business information standard of the DLMS is an effort to implement modern, commercial transaction sets and eliminate the legacy 80 record position formats associated with MILSTRIP, MILSTRAP, MILSBILLS, etc. Transitioning to a modern, commercially accredited EDI standard, is key to enabling business transformation and continuous process improvements essential to current and future logistics operations. The migration to DLMS is a long-term process that requires a measured, phased implementation. S Industry has been using the ASC X12 standards (EDI) for more than 30 years, and equivalent XML schemas have been in use for 15 years. DLMS EDI and XML replaces DoD proprietary standards with commercially compatible ASC X12 standards. This will allow for the unification of the many diverse systems, organizations, procedures, and policies that comprise DoD logistics. The resulting unified architecture of both current and future systems will allow the management and exchange of logistics data as a corporate asset to achieve DoD goals. S1.4. Mission Requirements S The effective use of logistics data is critical to the success of business transformation, asset visibility, and other related initiatives. The current legacy 80 record position MILS systems cannot provide the needed data, but DLMS ANSI ASC X12 transactions or equivalent XML schemas can support any expanded or new data requirements and related initiatives. The adoption of DLMS standard transactions will provide improvements in the following areas: Additional data capabilities to support functional initiatives Reliance on existing commercial standards used by industry partners Support for Component technology goals 1 MILS were renamed the Defense Logistics Standard Systems (DLSS) Page 3

12 S Current MILS transactions do not support a number of data elements, most notably IUID, RFID, serial numbers, weapon system identification, discrete line of accounting information, etc. DoD s fixed-length standards are data saturated and no longer viable. The new DLMS EDI and XML formats meet current data requirements and have the flexibility to meet future requirements. S1.5. Interoperability Challenge S The DLMS are the backbone of interoperability among the automated information systems (AISs) that comprise the complex Defense Logistics and Global Supply Chain Management System. It is composed of hundreds of thousands of trading partners supported by many hundreds of AISs developed over many years independent of one another. Some of the AISs were developed up to 60 years ago employing the computer technology that existed at the time, while other more recent AIS are at the cutting edge of current information technology. The trading partner AISs support and were developed by DoD, non-government organizations (both commercial and nonprofit), Federal agencies other than DoD, State and Local Government entities, foreign national governments, and international government organizations. S In addition to the breadth of trading partners and mix of AISs, the breadth of business functions covered is also daunting. The logistics domain includes item cataloging and management, material acquisition from vendors, customer ordering, warehousing, repair operations, disposal, transportation, etc. Additionally, the collective AISs directly supporting the global supply chain must also interface with other business domains, such as financial management. If the forgoing weren t complexenough, DoD is constantly changing its business processes and enlarging its data requirements to achieve greater efficiencies and better support to the warfighter. S Given the size and complexity of the environment, it s virtually impossible to implement business process changes and new data requirements via a big bang approach. The key interoperability challenge is to enable all trading partner AISs to perform their respective functions, exchanging information among the interconnected and dependent body of systems. The DLMS managed by the Defense Logistics Management Standards Office and supported by the technical architecture of the DLA Transaction Services, are the underpinnings that allow daily interoperability to be achieved across the global supply chain. S1.6. DLMS Foundation Policies S Directives, instructions, and regulations are all issued at the DoD level. These policies define desired outcomes/goals (e.g., Components will keep track of inventory balances). The DLMS define the procedures to achieving the required outcomes, while Components develop the systems to implement the procedures. Figure 1 is a graphical representation of the DLMS governance process. Page 4

13 Figure 1 DLMS Governance Process S The DLMS governance process starts with a DoD directive, instruction, regulation or manual. This high level policy is the start of the process and each subsequent layer builds to support the required result. The follow references are the authorizing publications supporting DLMS: S DoD Directive E, Defense Logistics Management Standards provides policy and guidance to implement the DLMS. That Directive states DLMS is the DoD standard for electronic transactional information exchanges among the AISs that comprise assigned business processes of the global supply chain management system. The DLMS EDI and DLMS XML transactional interfaces are founded on the ANSI ASC X12 standard. The Directive requires Components uniformly implement the DLMS in all AISs performing business functions supporting the global supply chain management system and use the services of the DLMS global services providers. S DoD Instruction , DoD Supply Chain Materiel Management Policy. This policy states material management functions will be implemented with DoD standard systems. It also authorizes the publication of the DoDM and the family of DLM manuals. Page 5

14 S DoDM , DoD Supply Chain Materiel Management Procedures. It requires DoD Components to support and maintain DLMS for all covered functions. DLMS is the primary system governing logistics functional business management standards and practices. It will use ASC X12 EDI transactional interfaces. DefenseLogistics Management Standards Office will provide change management control of DLMS. The MILS will be deactivated upon DoD-wide implementation of DLMS. S DLA Transaction Services operating the Defense Automatic Addressing System (DAAS), is designated as the corporate community service provider for DLMS. DLA Transaction Services maintains the logistics community s authoritative repository for end-to-end performance metrics and serves as the source for MILS-DLMS conversion services. S DoD Components will route all MILS/DLMS transactions to DAAS, use DAAS for MILS/DLMS conversion services, and uniformly implement the DLMS. S DLM Series of Manuals. The DLM series of manuals document the detailed business processes and rules, information exchange formats, and data standards and codes. S1.7. DLMS Compliance Legislative and DoD Policy Authority Chain S Title 10 United States Code Specifies requirements for investment review and certification of defense business systems before funds, whether appropriated or nonappropriated, can be obligated. S Requires establishment of a Department-wide Business Enterprise Architecture (BEA). BEA. S Requires Business Process Reengineering (BPR) and alignment to the S Requires the establishment of a single Investment Review Board (IRB) chaired by the DoD Deputy Chief Management Officer (DCMO) and an investment management process. S The Office of Deputy Chief Management Officer. The DCMO issues guidance governing the following: BEA development, maintenance and compliance IRB rules Annual delivery of the BEA for the DoD Business Mission Area (BMA) to help defense business system owners and program managers make informed decisions S The Defense Business Council/Investment Review Board (DBC/IRB). The DBC/IRB oversees the implementation of the DCMO guidance through: Page 6

15 S Review of business area Functional Strategies and approval of the Components Organizational Execution Plans (OEPs) to implement the functional strategies. S Definition of the Department's target business environment; and approval of the content for the DoD BEA. The BEA specifies the Enterprise Standards to which DoD business systems must adhere. S Review of business area Functional Strategies and approval of the Components OEPs to implement the functional strategies. Note: The target for DLMS full implementation and compliance is Based on the review of the current Component OEPs and data calls with the Services in early 2014 there is risk that some of the Components will not be DLMS compliant by Accordingly the Office of the Secretary of Defense functional proponent for the DLMS is recommending an Investment Decision Memorandum note to ensure the Services are planning/programming for the 2019 requirement. S Acquisition and Logistics Functional Strategy, FY Identifies the DLMS as an enterprise standard under Mission Area Requirement # 3 - Increase the level of data and process standardization. It sets the target for DLMS compliance by S DoD Component Chief Information Officers. They must annually assert the following items for automated information systems under their purview: BEA compliance of any business system with a total cost in excess of $1M over the period of the current future years defense program, regardless of type of funding or whether any development or modernization is planned Provide BEA certifications using the Integrated Business Framework-Data Alignment Portal (IBF-DAP) to provide an automated assessment of system compliance against the data standards, business rules, laws, regulations, and policies defined in the DoD BEA S1.8. DLMS Levels of Compliance: S Level 0: DLMS NON-COMPLIANCE. A system is declared DLMS Non- Compliant when it executes business processes covered by the DLM series of manuals, interfaces with other systems in the performance of those processes, but does not adhere to the DLMS standard processes, business rules, information exchange formats, or data standards, and there are no active efforts to implement the DLMS. Transaction based information exchanges must be executed in the applicable DLMS format including DLMS X12 EDI and DLMS XML. The DLMS are a broad-based body of logistics management, responsibilities, procedures, business rules, data and information exchange standards that are documented in the DLMS Manual and Approved DLMS Changes (ADCs) published and posted to the DLMSO Website. Page 7

16 S Level 1: BASIC DLMS COMPLIANCE. A system is declared Basic DLMS Compliant when it executes business processes covered by the DLM series of manuals, has the capability to interface with other systems using the standard DLMS transactions (either DLMS EDI or DLMS XML), and implements the DLMS basic business function rules and data standards. While the system has not fully implemented all of the applicable DLMS enhancements, it has begun doing so, and has detailed plans and actions ongoing to reach full DLMS compliance. It has implemented basic business process rules, formats and data conform to those prescribed by legacy MILSTRIP, MILSTRAP, and MILSBILLS. At a minimum, the system must be capable of communicating via DLMS transactions equivalent to the legacy 80 record position transactions, but may not have implemented all the applicable enhanced capabilities of the DLMS. These systems are characterized as Level 1 and are considered to have reached basic DLMS Compliance for BEA/IRB compliance certification purposes. S Level 2: ENHANCED DLMS COMPLIANCE. A system is declared Enhanced DLMS Compliant when it executes business processes covered by the DLM series of manuals, has the capability to interface with other systems using the standard DLMS transactions (either DLMS EDI or DLMS XML), implements DLMS basic business function rules, formats and data standards, and has implemented the preponderance of applicable DLMS enhancements. While the system has not fully implemented all of the applicable DLMS enhancements, it has detailed plans and actions ongoing to reach full DLMS compliance. Systems are characterized as Level 2 and are considered to have reached Enhanced DLMS Compliance for BEA/IRB compliance certification purposes. Page 8

17 S Level 3: FULL DLMS COMPLIANCE. A system is declared Fully DLMS Compliant when it executes business processes covered by the DLM series of manuals, has the capability to interface with other systems using the DLMS standard transactions (either DLMS EDI or DLMS XML), implements DLMS basic business function rules, formats and data standards, and has implemented all of the applicable DLMS enhancements. Systems meeting these criteria are characterized as Level 3 and are considered to have reached Full DLMS Compliance for BEA/IRB compliance certification purposes. S1.9. DLMS Compliance Oversight S The IRB will actively monitor Component IBF-DAP certifications of a system s level of DLMS Compliance. For those systems that are not at Level 3 Fully DLMS Compliant, the IRB will review Component plans and ongoing actions to ensure the appropriate resources and priority are being applied to enable the system to be declared Level 3 Fully DLMS Compliant. S As new DLMS enhancements are approved for implementation, Components must continually update the Component IBF-DAP certifications to ensure the system is remaining current with DLMS. It is possible for a system that was declared Level 3 Fully DLMS Compliant to revert to Level 2 if new DLMS enhancements have not been implemented. If this occurs, the Component must submit to the IRB detailed plans and demonstrate ongoing actions to implement the new DLMS enhancements. S The DLMS are one of the BEA designated enterprise standards that must be used to develop systems. Component CIOs must assert to DLMS compliance or risk IRB disapproval of system funding. S1.10. Where We Are and Where We Are Going S The DoD mandated the elimination of the 80 record position legacy MILS transactions and the implementation of DLMS back in the 1990 s and the policy to migrate to the DLMS was initially established in December Funding and other constraints impacted the speed of the deployment and by 2006 only 12 percent of the transactions processed by DLA Transaction Services were processed as DLMS. This was not acceptable. Many initiatives being mandated by DoD would be too costly and disruptive to implement in the legacy 80 record position format. Page 9

18 S OSD endorsed and promoted the DLMS migration initiative. To encourage Components to accelerate DLMS conversion through the DLMS Migration, in 2006 the Jump Start Program was created. OSD provided seed money funding for high priority transformation initiatives including complete material visibility throughout the supply chain. It also supported other important priorities and catalysts such as Item Unique Identification (IUID) and Radio Frequency Identification (RFID). The Jump Start program produced a dramatic increase in DLMS usage. As shown in Figure 2, in the two years of the Jump Start program, DLMS usage more than doubled, increasing from 15.7 percent to 33 percent. S The continued DLMS Training Classes and the deployment of the Component Enterprise Resource Planning Systems has resulted in the steady expansion of DLMS usage. As of July 2014, 53.3M transactions are DLMS accounting for nearly 60% percent of the monthly logistics transaction volume. The goal is to achieve 100 percent use of DLMS by Figure 1 DLMS Current and Projection Metrics 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 88% 12% 72% 28% 64% 68% 36% 32% 51% 49% 55% 49% 51% 45% 41% 46% 59% 54% 31% 69% 20% 80% 12% 88% 2% 7% 98% 93% MILS DLMS Page 10

19 Section 2 - ANSI ASC X12 Standard is the Foundation for the DLMS S2.1. Breadth of Usage S EDI is a method for transferring data between different computer systems or computer networks and is the foundation upon which DLMS is based. EDI provides the technical basis for supply systems to hold a "conversation" between two entities, either internal or external. It should be noted EDI constitutes the entire electronic data interchange paradigm, including the document format and software used to interpret the documents. EDI standards describe the rigorous format of electronic documents and are the basis for both commercial and DoD supply chains. S The Accredited Standards Committee X12 (ASC X12), chartered by the American National Standards Institute in 1979, develops and maintains the X12 EDI standards. The membership of ASC X12 includes technology and business process experts, encompassing health care, insurance, transportation, finance, government, supply chain and other industries. S2.2. Key Building Blocks S The ASC X12 standards define commonly used business transactions in a formal, structured manner called transaction sets. The structure of the transaction set comprises specific syntax rules for EDI constructs. The standard defines data elements, codes and segments within each transaction set. Most importantly, it also defines specific rules and formats for the content of data within data elements. The legacy MILS process is handicapped by the rigid positional based data structure. This made expansion of the MILS costly and difficult. EDI is based on building blocks of data. At the lowest level EDI has data elements. The data elements are specific values of data that need to be transmitted (e.g., a country code). The data elements are collected into a segment of related elements (e.g., an address) and these segments are wrapped together into a functional process called a transaction (e.g., 810L Logistics Bill). Using these building blocks to implement the DLMS process, enables greater flexibility in constructing and modifying the process to meet specific needs and goals. S2.2.2., The ASC X12 standard provides a hierarchical structure of headers and trailers to allow the data to be segregated logically for easy interpretation by the transmitter and receiver. This allows different types of transaction sets to be transmitted from one party to another in the same transmission. S2.3. Data Element The data element is the smallest named unit of information in the X12 standard. A simple data element is equivalent to a field in a data dictionary. It has a name, a data element number, a brief description, a data type, and a minimum and maximum field length. When a group of two or more simple data elements are linked together to form a single data element, they are referred to as a composite data structure. Page 11

20 S Data Element Types. Table 1 Data Element Types identifies six types of data elements typically used in the creation of the DLMS. Table 1 Data Element Types Data Element Type AN Alphanumeric String DT Date ID Identifier Nn Numeric Data Element Type Description Sequence of letters, numbers, spaces, and/or special characters. The contents are left-justified and trailing spaces should be suppressed. Used to express the standard date in (CC)YYMMDD format in which CC is the century, YY is the year, MM is the month (01 to 12), and DD is the day of the month (01 to 31). Contains a unique value from a predefined list of values maintained by ASC X12, the DoD, or other responsible organization referenced by the data element dictionary. All code lists employed under DLMS including those maintained by ASC X12 are available via the Logistics Data Resources Management System (LOGDRMS). The contents are left-justified and trailing spaces should be suppressed. Identifier type data elements are frequently used as qualifiers to identify by code the type of information contained in an associated data element. For example, the identifier type data element, Product/Service ID Qualifier, may be transmitted with a value of FS to indicate the value contained in the associated data element Product/Service ID is a national stock number. In this instance, the list of valid identifier codes is maintained by X12. The conventions normally specify which of these values are permissible for the specific use under DLMS. Represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data. The symbol for this data element type is Nn where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point. If no decimal positions are allowed, the symbol is written as N or N0. A leading minus sign (-) is used to express negative values. Absence of a sign indicates positive value. Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional minus sign. For example, where the numeric type is N2 (indicating an implied decimal placement two positions from the right), the value would be transmitted as The length of the value within the data stream is five. Page 12

21 Table 1 Data Element Types Data Element Type R Decimal Numeric TM Time Data Element Type Description Contains an explicit decimal point and is used for numeric values with a varying number of decimal positions. The decimal point is always carried in the transmission unless it occurs at the right end of the value. A leading minus sign (-) is used to express negative values. Absence of a sign indicates positive value. Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point should be suppressed unless used to express precision. Use of commas within the numeric value is prohibited. The length of a numeric type data element does not include the optional minus sign or the decimal point. For example, the numeric value would be transmitted as The length of this entry is five. Used to express the time in HHMMSSdd format in which HH is the hour for a 24-hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and dd is the decimal seconds. Seconds and decimal second are optional. Trailing zeros in decimal seconds should be suppressed unless necessary to satisfy a minimum length requirement or to indicate precision. S Data Element Length. Each data element is assigned a minimum and maximum length, which may be the same. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements. A data element is of variable length unless the minimum and maximum lengths are equal, in which case it is of fixed length. The length attribute of a data element is expressed as minimum length / maximum length, e.g., 2/30. S2.4. Data Segment The data segment is composed of simple data elements and/or composite data structure(s), as an intermediate unit of information in a transaction set. Each data segment has a unique segment ID and is used to convey a grouping of functionally related user information. S Condition Designator. The condition designator (or requirement designator) is used to define the circumstances under which a data element is required to be present or absent in a particular usage. These conditions are of three basic types: mandatory, optional, and conditional. Under DLMS, optional and conditional designations can be further defined as used or must use. Condition Designators are shown in Table 2, and are identified by the symbol specified in parentheses. Page 13

22 Table 2 Condition Designators Condition Designator Mandatory (M) Optional (O) Conditional (X) Condition Designator Definition The designation of mandatory is absolute in the sense there is no dependency on other data elements within the segment or composite data structure. A mandatory data element must appear in the segment. The designation of optional means there is no syntactic requirement for the presence of the data element within the segment or composite data structure. Optional data elements may be included or omitted based upon instructions provided in the DLMS Implementation Conventions (ICs) or at the discretion of the transmitting activity (as applicable). A designation of conditional defines a special relationship between two or more data elements within a segment or composite data structure. Relational conditions are based upon the presence of one of those data elements. The specific relationship is defined in a syntax note. The first character of the syntax note identifies one of the following conditions: (1) Paired (P). If any specified data element is present, then all of the specified data elements must be present. (2) Required (R). At least one of the specified data elements must be present. S2.5. EDI Field and Record Delimiter Characters. The delimiter for a field and the delimiter for a record are set externally by the ISA Interchange Control Header segment. This means the EDI parser may not know what the delimiters will be until it has begun to parse the file. EDI handles this problem by making the ISA segment fixed length and defining the delimiters in the ISA segment of the EDI interchange. In an actual interchange, ASCII Hexadecimal characters are used, a graphic representation is used for print examples. Recommended delimiters are Hexadecimal 1c, 1d, 1f. Printable characters should not be used if there is a chance they can occur in the data. S Delimiters. The delimiters cannot appear as a value in the business transaction; otherwise the syntax rule will fail. In ASC X12 EDI interchanges there are three delimiters: S Data Element Separator. This defines the delimiter between each element (field) within the segment (record). S Component Element Separator. ASC X12 supports the use of subelements in transactions employing a Composite data element such as in the MEA Unit of Measure and REF Reference segments. The component element separator delimits the subelements. S Segment Terminator. Defines the end of each segment (record) within the transaction. Page 14

23 S EDI Interchange and Delimiter Example. Figure 3 Sample EDI Transaction, shows an example of the EDI data in an interchange. Figure 3 Sample EDI Transaction ISA*00* *00* *01* *01* *041201*1217*U*00403* *0*P*\*~ GS*CT* * * *1217*128*X*004030~ ST*831* ~ BGN*00* * ~ N9*BT* ~ TRN*1* ~ RCD*1*20*EA\2\1~ AMT*2* ~ QTY*46*1~ SE*8* ~ GE*1*128~ IEA*1* ~ Data Element Separator = * (Asterisk). Defined in the fourth position of the ISA Segment Component Element Separator = \ (Back slash). Defined in the 3 rd to last position of ISA segment Segment Terminator = ~ (Tilde). First occurrence defines the segment termination S2.6. Data Segment Loops Data Segment Loops are groups of two or more data segments that represent a block of related information in a Transaction Set. Different loops may be nested within each other and loops may repeat up to the maximum loop occurrences specified within the Transaction Set. In some cases it may be specified as having an unlimited number of occurrences (noted as >1 ). Loops can occur at different levels. S Nested Loops. A loop might be the repetition of a single segment or a group of segments (i.e., nested loops). Looking at the typical X12 file, it is very hard to see where loops (blocks of repeating data) occur within the file. Unlike XML, EDI does not have the concept of closing tags, so it is not obvious where one block ends and another begins. The X12 transaction set table diagram defines the loop structure and any nesting. Many commercially available software packages come with templates for EDI X12 transactions and show the looping structure of the transactions. These templates indicate looping by showing how blocks of segments nest in one another, usually in a tree structure. S Hierarchical Loops. The last (and most complex) looping levels are hierarchical level loops. This structure uses the lead segment the HL segment to identify the type of information contained in the loop and, if desired, create a dependency (also called a parent-child relationship) between each iteration of the loop. For example, the first iteration might represent general information about a shipment of materiel. Subordinate to the shipment loop might be a loop describing each of the items in the shipment. Finally, subordinate to each item, there may be another level of loops describing the components of each item. The HL segment uses pointers and counters to maintain the relationships between each iteration of the HL loop. S Within a level, loops can be Unbounded or Bounded as defined in the X12 Standard: Page 15

24 S Unbounded. An Unbounded loop starts with a specific segment and all of the other segments in the loop may be considered children of that segment. To establish the iteration of a loop, the first data segment in the loop must appear once and only once in each iteration. Loops may have a specified maximum number of repetitions. A specified sequence of segments is in the loop. Loops themselves are optional or mandatory. The requirement designator of the beginning segment of a loop indicates whether at least one occurrence of the loop is required. Each appearance of the beginning segment defines a new occurrence of the loop. The requirement designator of any segment within the loop after the beginning segment applies to that segment for each occurrence of the loop. If there is a mandatory requirement designator for any data segment within the loop after the beginning segment, that data segment is mandatory for each occurrence of the loop. If the loop is optional, the mandatory segment only occurs if the loop occurs. S Bounded. The characteristics of unbounded loops described previously also apply to bounded loops. In addition, bounded loops require an LS Loop Start Segment to appear before the first occurrence of the loop and an LE Loop End Segment to appear after the last occurrence of the loop. If the loop does not occur, the LS and LE segments are suppressed. S2.7. Transaction Set Detail A Transaction Set is a group of data segments, as defined by the X12 Standard, conveyed between trading partners. The information, in the form of a transaction set, is generally patterned after a conventional paper document, such as a requisition or invoice. S A Transaction Set consists of a number and name (e.g., 511 Requisition), purpose, Functional Group ID, table listing the included segments, their position numbers, requirement designation, maximum usage, and loop repeat counts. S The Transaction Set Detail comprises data elements and data segments specific to the business (e.g., requisition) transaction. Examples of data in the detail section are: identity of ordering activity, item ordered, quantity, order priority, delivery point, and who will pay. S Transaction Set Header and Trailer (ST/SE Segments). The Transaction Set Header and Trailer are used to uniquely identify the transaction set. The transaction set begins with an ST Transaction Set Header segment and ends with an SE Transaction Set Trailer segment. S Transaction Set Header. The ST01 Transaction Set Identifier Code is the first data element of the transaction set header segment. It is used by the translation routine of the interchange partners to select the appropriate transaction set definition (e.g., 511 selects the Requisition transaction set). The ST02 Transaction Set Control Number uniquely identifies an instance of the transaction set and is assigned by the originator of a transaction set. The control number in ST02 must match the control number in SE02. Some DLMS transactions use the ASC X12 version release 4030 that contains an additional data element in the ST Segment; the ST03 Implementation Convention Reference uniquely identifies the DLMS IC used in the transaction. Page 16

25 S Transaction Set Trailer. The purpose of the transaction set trailer is to indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning ST and ending SE segments). The number of the included segments identified in the SE01 is used to indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning ST and ending SE segments). The SE02 Transaction Control Number must match the one in the ST02 to ensure that the entire transaction set was received. S2.8. Functional Group (GS/GE Segments) A Functional Group is a group of one or more related Transaction Sets within an EDI transmission. Functional Groups start with a GS Functional Group Header segment and end with a GE Functional Group Trailer segment. The details in the Functional Group GS/GE envelope are often used to route the group's transaction sets to the target environment. Functional Group detail: contains a functional group ID (e.g., RN (511), MD (527)) contains transaction set counts and functional group control numbers contains a time/date stamp of when the group was generated, and provides version/release specifications of the transactions in the group. S2.9. Interchange Control Header and Trailer (ISA/IEA Segments) Interchange Control consists of one or more Functional Groups enclosed in an envelope defined by an ISA Interchange Control Header segment and ending with an IEA Interchange Control Trailer segment. Details of the envelope (Figure 4 diagrams the EDI Structure): contains the structured mailbox address of the sender and the receiver contains control numbers/counts of the different types of functional groups contains a time/date stamp specifies the format and version of the interchange envelopes, and specifies the characters used for delimiters and segment terminators. Page 17

26 Figure 4 EDI Structure S2.10. Summary of X12 Structure The ASC X12 structure can be related to how someone would construct a letter. They start with words to construct sentences and format those sentences into paragraphs. When the letter is completed, they place the letter into a folder. The folder is placed into an envelope for mailing. Figure 5 is a graphical depiction borrowed from the DLMS training (Module #2). Page 18

27 Figure 5 File Structure Compare S2.11. XML Standards DLMS use XML as an alternative to X12-formatted EDI for exchanging data between logistics trading partners. XML offers a flexible way to describe and tag content (data, word, phrase, etc.) in a structured way. The XML standard emphasizes simplicity and usability over the Internet. It is a textual data format with worldwide support. Though originally designed to focus on documents, it is widely used to represent data structures (e.g., DLMS) and is the foundation of web services. XML only refers to the data; the XML Schema (i.e. XSD file) is used to express the set of business rules to which the XML must conform to be considered valid. The schema is an abstract collection of metadata components. The XML instance document is validated against the schema (a process known as the assessment) prior to sending the transaction for processing. This validation ensures required fields are present, the elements are in the correct format and valid codes are used (when defined in the schema). S Well-Formed. The XML specification defines an XML document as text that is well-formed; for example, it satisfies a list of syntax rules provided in the specification. Some of the key criteria are: It contains only properly encoded legal Unicode characters. None of the special syntax characters such as "<" and "&" appear except when performing their markup-delineation roles. Page 19

28 The beginning, ending, and empty-element tags that delimit the elements are correctly nested, with none missing and none overlapping. The element tags are case-sensitive; the beginning and end tags match exactly. Tag names cannot contain any of the }~, nor a space character, and do not start with -,., or a numeric digit. These characters also should not appear in X12 transactions either, since it is possible that an X12 trading partner can exchange data with XML trading partners. There is a single "root" element that contains all the other elements. The XML instance document must adhere to all the rules of a well-formed file or it is not XML. An XML processor that encounters violation of the well-formed rules is required to report such errors and to cease normal processing. S In addition to being well-formed, DLMS XML must be valid. This means it contains a reference to a schema (XSD file) and its elements and attributes are declared in the schema and follow the grammatical rules for them that the schema specifies. S XML Tags. XML and EDI tags names are similar, but XML fields and records are handled differently than in EDI. In EDI, data is separated by delimiters. In XML, documents are comprised of markup code to delimited content. Markup and content are distinguished by syntactic rules. All strings that constitute markup begin with the character < and end with a >. These bracketed strings are called XML tags. Strings of characters that are not XML tags are content. S XML tags define the beginning and end of each section of the XML transaction. The start tag contains the field or record name. The end tag will use the same name, but will be preceded by a forward slash. Anything in between the two tags is content. For example, to define the value 1000 in the quantity field the XML might appear as <quantity>1000</quantity>. Figure 6 Sample Segment shows the hierarchy: Figure 6 Sample Segment <segment> <code>isa</code> <element>00</element> <element> </element> <element>00</element> <element> </element> <element>01</element>... </segment> <element> </element> Page 20

29 S XML is self-validating. Each DLMS XML transaction has an XSD (XML Schema Definition) file. The XSD defines the data types (e.g., string, numeric, binary) and detailed constraints (e.g., size, optional/required, enumeration value (lookup table), and format). The process of checking to see if an XML transaction conforms to a schema is called validation, which is separate from XML s core concept of being syntactically well formed. All XML transactions must be well formed or they cannot be parsed. The schema ensures the transaction conforms to the syntax rules. Validation of an instance transaction against a schema can be regarded as a conceptually separate operation from XML parsing. In practice, the schema validation is integrated within the XML parser. S2.12. ANSI ASC X12 Governance and Defense Logistics Management Standards Office Participation S The X12G Sub-Committee designs, develops, and supports any new or existing X12 EDI transactions (including ANSI ASC X12, XML, and other emerging electronic data exchange technologies) that are solely to meet government requirements, whether or not a government entity is the principal user of that transaction set. This includes technical reports, guidelines, interpretations, and other associated documents. S DLMSO is a longstanding member of ASC X12. DLMSO advises and comments to other standing subcommittees and working groups of ASC X12 on any electronic data exchange issues that impact X12G s business areas. As a memberdlmso has the ability to influence the direction and details of the ASC X12 processes and requirements. Page 21

30 [This Page Left Intentionally Blank] Page 22

31 Section 3 - DLMS Use of Accredited Standards Committee X12 S3.1. Functionality Coverage S The DLMS provide standard procedures and data formats to link the various component organizational elements of the Defense Logistics community including: inventory control points (ICPs), distribution depots, maintenance depots, transportation nodes, and end users in posts, camps, stations, ships, and deployed units. The DLMS address the different functional processes of logistics and provides standards to exchange data across the Military Services, Defense Agencies, other Federal Agencies, foreign national governments, international government organizations, and nongovernment participants. As other electronic business (EB) methods emerge, DLMS will incorporate these new capabilities into the DoD logistics business processes as appropriate. S When the DLMS ICs are completely incorporated into the DoD logistics business processes, some of the data currently contained in the legacy 80 record position transactions will be unnecessary. We are moving in that direction, but years away from reaching that goal. Currently, the data and process baseline is legacy 80 record position format transactions. This DoD fixed-length standard is data saturated and no longer viable. The legacy formats do not support many data elements needed to meet DoD policy changes such as Unique Item Identification (UII), RFID, serial numbers, discrete line of accounting information, and weapon system identification. DLMS EDI and XML formats meet current data requirements and have the flexibility to meet future requirements. The DLMS procedures and the supporting DLMS ICs identify these new data requirements as DLMS enhancements. S3.2. Versions/Releases S X12 publishes a new version/release of its standards each year, with version/release 6050 published in January Currently, the majority of DLMS are based on X12 version/releases 4010 and It is highly unlikely the DLMS will migrate to a higher version/release because of cost factors and both the 4010 and 4030 versions generally meet DoD requirements. Additionally, the level of effort required across DoD to migrate to a new version/release of X12 is so significant no migration has occurred since most of the DLMS ICs were initially published in version/release When faced with new business requirements (such as the need for a new code) that might have been resolved by migrating to a new version/release, work-around procedures are developed to implement the needed functionality in the DLMS ICs. To mitigate any potential issues with new X12 code requirements, beyond those originally published in version 4010 and 4030, the DLMSO is working aggressively with the relevant ASC X12 subcommittees to have a method of using codes added by higher versions. We see the same pattern in the commercial environment where the 6050 is the most recent version of ANSI ASC X12 but 84 percent of EDI transactions processed by all X12 trading partners use S ASC X12 version/release 4010, published in 1997, required the use of 8- character dates (CCYYMMDD) in X12 EDI. The new date format s ability to avoid any issues related to the Y2K Bug provided a strong functional business requirement for many users to Page 23

32 migrate to the new standard. The only other ground-swell business need occurred when Congress mandated healthcare providers use version Release 5010 for Health Insurance Portability and Accountability (HIPAA) transactions beginning in January For the most part, usage of all other version/releases is below 1 percent, so it is unlikely DLMS will migrate off its current standard anytime soon. S DLMS may support multiple ICs based on different versions/releases of the X12 standard dependent upon trading partner requirements. In addition, DLMS may support multiple standards of DLMS ICs within each ANSI ASC X12 version/release. Currently some transactions such as the DLMS 947I support multiple standards; the newer (4030) version/release is used for new implementations, while enabling existing implementations to remain at an older version/release (4010), until they can be modified to the newer version/release. Older version/release DLMS ICs may not have all the functionality of the newer one, so Component AISs should plan to modernize to the newer version release (4030). Once all Component AISs have modernized to the newer version release, DLMSO will cancel the old DLMS IC via a formally staffed DLMS change. S3.3. DLMS Implementation Conventions The DLMS Implementation Conventions (ICs) represent a combination of ASC X12 standards and implementation guidance specific to the DLMS. The main objective is to provide standards to facilitate electronic interchange of general business transactions. DLMS ICs identify and define the segments, data elements, and codes that DLMS trading partners use in each IC. Most importantly, ICs specify rules and formats for the content within the data elements. DLMS ICs address how the standards are implemented. One X12 standard transaction set may be used in several different functional areas or repeated within the same functional area. Each separate interpretation of the standards according to a specific usage is called an application. DLMS ICs are found on the DLMSO Website: The use of XML will be addressed later in this document, but it is worth noting here that DLMS XML is EDI based. This means the segments, elements, looping structure of the EDI transaction are exactly the same in XML as they are in EDI. S3.4. DLMS Implementation Convention Structure Each DLMS IC consists of a cover page, X12 transaction set table diagram, segment hierarchy and notes. S Cover page. The cover pages includes the transaction designation (e.g., 527R, Material Due-In and Receipt), the purpose of the transaction (brief narrative description of how the transaction is used), notes (a more detailed description of the transaction within the scope of the Supply Chain), and a change history (a list of ADCs and a short description of the enhancement). S X12 Transaction Set Table Diagram. The information here contains an outline of the X12 standard transaction set. There may be semantic notes, but only high level information is contained within this section. Page 24

33 S Segment Hierarchy. The segment hierarchy includes a data element summary with information pertaining to each data element in the segment. In general, information printed in normal typeface is extracted from ASC X12 standards and information printed in italics prefaced by DLMS Note relates to the DLMS implementation of the standard. S Instructions on Use of the ASC X12 Standard. In many instances, exact equivalents are not available to map the DoD information requirements to the ASC X12 standard. Specific instructions on how a particular portion of the standard is used under DLMS ICs are provided in the form of DLMS notes. The DLMS notes explain what and where data may be carried. The DLMS notes are printed in italics in a gray box. Notes may be applicable to a transaction set, segment, data element, or a specific code value. S3.5. DLMS Notes S DLMS notes are guidance to describe procedures for a specific aspect of EDI. At the beginning of the EDI transaction or IC, there are traditional notes about the transactions overall use and purpose. It is in these initial DLMS notes where specific enhancements (ADCs) are annotated. However notes can occur at any level of the IC. DLMS Notes found in segments are often detailed business rules, specifying conditions of use for optional data or transition guidance governing operation in a mixed MILS/DLMS environment. Even data elements can contain notes. Element notes are often used to further refine the uses of a code table or designate a format not radially apparent based solely on the elements usage. All DLMS notes are important, because this is where most of the DLMS business rules are located. S Importance of DLMS Notes. The information provided in DLMS notes are critical to understanding the IC. At times, the ASC X12 data element or code value name has little similarity to the commonly used DoD name for a piece of information. Additionally, an ASC X12 data element or code value may be used as a migration code or local code to carry DLMS required data not otherwise provided for by the standard. The DLMS notes explain these circumstances. S Syntax and Semantic Notes. The terms syntax and semantic, when used in the context of EDI implementations, refer to the structure and meaning of X12-formatted information respectively: S Syntax is the structure of the data. This includes establishing the method of encoding a piece of data by its attributes and identifying data in the transfer. It also includes defining minimum and maximum field lengths of a data element or the designation of a relevant code list. S Semantic relates to the meaning of the data transferred. For example, a semantic note might indicate the relationships in the meaning of one or more data elements in an instance of the segment. Page 25

34 S3.6. Code Sources S Deriving Code Values. Code values associated with data elements may be derived from several locations. Many of the applicable code values for DLMS data elements are listed in the DLMS ICs. S Conversion Guides. DLMS will continue to support other legacy code structures used in the MILS. Three data elements; transportation mode/method code (transportation method/type code), unit of issue (unit or basis for measurement code), and type pack code (packaging code) use conversion guides to convert the DoD legacy fixed-position code structure to the ASC X12 code structure. Special processing at the sending node provides conversion from a DoD code value to an ASC X12 code value for transmission of the transaction set. The sender and the receiver employ the conversion guide so users see only the familiar DoD code values. DLMS Cross Reference/Conversion Guides are available from the DLMSO Website S Migration Code. A migration code is a code from a higher ASC X12 version/release (e.g., 5030) used in a lower version/release (e.g., 4010). The semantic meaning and syntax are consistent with the higher version/release. Use of a migration code refers to establishing agreement among all trading partners to use a valid X12 code from a higher version/release with its approved X12 definition at a lower version/release of X12. Manual intervention may be needed for some commercial ANSI X12 parsers to accept the higher version/release code. S Local Code. A local code is a code value not in the current version/release, and has not been established at a higher ASC X12 version/release. A data maintenance action with ASC X12 is in process to establish the code in a higher version/release. Once approved by ASC X12, the local code becomes a migration code. Manual intervention may be needed for some commercial applications to accept the local code. S Borrowed Code. Use of a borrowed code refers to establishing an agreement among all trading partners to use a valid X12 code at the correct version by altering the code s semantic meaning (i.e., the code is used because it conforms to syntax rules, even though its intended meaning is different from its use in the identified context). The borrowed value must be a value otherwise unused by the trading partners allowing its definition to be mutually changed. When a borrowed code is identified for DLMS use, DLMSO will submit an ASC X12 data maintenance (DM) action to establish a new qualifier to be approved for use in a higher (future) ASC X12 version/release. The borrowed code may be used indefinitely until DoD migrates to a higher version of ASC X12; however, it is more likely to be permanent, since migration to higher versions are very rare. S3.7. DLMS Logistics Qualifiers S DLMS logistics qualifiers are ASC X12 Data Element 1270 Codes that identify a DoD code list. X12 Data Element 1271 (Industry Code) is the actual code from the code list identified in X12 Data Element DLMS Logistics Qualifiers are available from Page 26

35 S Qualifier values are selected from codes approved for use by ASC X12 in the version/release applicable to the DLMS IC. At times, there is no suitable qualifier available within the X12 dictionary and an alternative code must be used to identify and pass the data associated with the business process (migration or borrowed code). Page 27

36 [This Page Left Intentionally Blank] Page 28

37 Section 4 - Defense Logistics Management Standards Mapping S4.1. Data Mapping S Data mapping identifies the data content and location within the MILS and correlating DLMS formats. S The DLMS maps are created and maintained by DLA Transaction Services and support translation of data both from MILS to DLMS and DLMS to MILS. Because DLMS transactions have the capacity to convey more data than the MILS, the mapping also highlights the data/process gaps between the DLMS and MILS translation processes (e.g., information may be lost when translating a DLMS transaction to a MILS transaction because only values existing in both formats can be translated). S4.2. Data Transformation S Mapping is a step in a larger process known as data transformation. Data transformation is the process of converting information from one format to another. MILS is based on 80-card column images developed in the 1960s and was the sole DoD transaction format for decades. The records are fixed length and fields are based on a column position within the record. S DLMS currently supports two industry standard formats: X12 EDI and extensible Markup Language (XML). To make data mapping easier between the multiple formats, DLMS XML uses the EDI X12 element names for the markup tags. For example, if the EDI element name is Reference Identification, <E_Reference_Identification> and </E_Reference_Identification> will be used as the beginning and end tags within XML. S DLA Transaction Service s transformation process involves the use of executable programs to convert transactional data from one format to another. S4.3. MILS-DLMS EDI Map Construct S The MILS-DLMS maps comprise two sections: MILS section and DLMS section. S MILS Section. The MILS section of the map comprises three parts: field name, record position and conditions for translation (if required). S Field name is the data element name within the data structure. S Record position defines the beginning and ending position of the data value within the data structure. S The translation describes the conditions for mapping the data between the legacy 80 record position and DLMS formats. Page 29

38 S DLMS EDI Section. The DLMS section of the data map comprises three parts: DLMS Data Element, Table and Update information. The DLMS data element relates back to the MILS field name and its MILS record position. In many cases the MILS record position will be none because the DLMS transaction is an expanded/enhanced version of the legacy 80 record position MILS transaction. DLMS are designed to support new elements and features, that do not exist in the MILS version of the transactions. The table column (next to last column in Table 3 below) is an EDI concept and exists to distinguish the header from the detail segments of the X12 transaction. DLMS data elements in X12 Table 1 (header segments) contain the transaction information, receiving location and routing information. DLMS data elements in X12 Table 2 (detail segments) contain the values to be used for processing the transaction. Field Name Table 3 Partial Example of the DLMS 527R Material Due In and Receipt Map 527 MATERIAL DUE-IN AND RECEIPT (D4,D6,DZK,BAY,D6T,Z6T,Z4S, Z6S,BG1,BG2) Record Position Conditions DLMS Data Element Table Updated (DLSS) None None ST01=527 1 Transaction Set Identifier Code Transaction Set Control Number Beginning Segment None If RP1=D or BAY If RP1=E Unit of used Ind Ext Data If RP1-2=D4, D6, and RP1-2=Z4, Z6, or BAY If RP1-3=DZK and RP54-55=D4 or D6 None None ST02= Serial Number 1 Receiving Location If RP1-3 BAY or RP1-2=Z4 or Z6 BR01=00 BR01=77 BR01=ZZ BR02=D4 BR03=()CCYYMMDD BR06=W1 BR09=()HHMM N101=RC N103=M4 N104=RP N106=FR Receiving Location If RP1-3=BAY N101=RC N103=M4 N104=RP N106=FR Routing Identifier IF RP1-3=BG1 or BG2 N101=RC N103=M4 N104=RP72-74 N106=FR Local Stock Number 8-20 DLA Navy BRAC-Ext Data National Stock None DLA Navy BRAC-Ext Number Data (LIN02=SW) Local Stock Number None DLA Marine BRAC Ext Data Materiel Control Tracking Tag 8-20 DLA Navy BRAC-Ext Data LIN02=SW LIN03=LSN LIN04=FS LIN05=NSN LIN04=SW LIN05=LSN LIN02=ZR LIN03=MCT Tag Nbr 1 ADC381 8/10/ /1/ /1/04 1 ADC 261 4/25/08 2 ADC 381 8/10/10 2 ADC 381 8/10/10 2 ADC 381A110/ 19/10 2 ADC 381 8/10/10 Page 30

39 Table 3 Partial Example of the DLMS 527R Material Due In and Receipt Map 527 MATERIAL DUE-IN AND RECEIPT (D4,D6,DZK,BAY,D6T,Z6T,Z4S, Z6S,BG1,BG2) Field Name Record Position Conditions DLMS Data Element Table Updated (DLSS) Number Funds Appropriation None DLA RBI - Extended Data FA201=18 FA202=Appropriation 2 PDC 434 7/6/11 Number Of Included None None SE01=Total Number Of 2 Segments Segments Serial Number None Must Equal ST02 SE02=Serial Number 2 Legend: MILS Conditions DLMS S4.4. XML Mapping There are no MILS to XML maps. DLMS XML is EDI based. This means the segments, elements, looping structure of the EDI transaction are exactly the same in XML as they are in EDI. For example, if the routing identifier code (RIC) is stored in the N104 element in EDI, XML will use N104 as the XML tag name when conveying the RIC value in XML (e.g., <N104>S2B</N104>). S4.5. Using Maps S DLA Transaction Services business rules define the routing of transactions and type of transactions used by each communication system (e.g. EDI, XML, MILS). The DLMS maps are used when the data needs to be transformed between MILS and EDI/XML. S DLA Transaction Services use DLMS maps to translate the input file from a source system (MILS or DLMS) to the destination system (MILS or DLMS). Along with the translation from one format to another, DLA Transaction Services validates the data in accordance with business rules established by the DLM series of manuals and additional business rules established by individual Services/Agencies. Missing data types, values outside the parameters and many other reasons can cause the transaction to reject. If the transaction is rejected, DLA Transaction Services sends a notification back to the source system so the transaction can be corrected and resubmitted. The methodology used to return these rejects is something established as part of the customer profile. Page 31

40 S Components migrating to the DLMS will need to locate the MILS format within the DLSS/DLMS cross reference table located at The cross reference will indicate the correct DLMS transaction for a given MILS transaction. Components should compare the MILS format to any existing Service unique formats and document any differences. The DLMS transactions can be updated in response to changing business needs. If the Component has a unique requirement, a Proposed DLMS Change (PDC) can be submitted to have the specific transaction enhanced (see Volume 1, Chapter 3 of the DLM ) Page 32

41 Section 5 - DLMS Change Management Process S5.1. General S The change management process ensures proper documentation of all proposed or approved changes to the DLMS. The process uses a structured collaboration model as a managed transformation process. On the input side, the PDC process factors in relevant DoD level policy guidance, DoD Component business requirements, relevant subject matter experts and DLA Transaction Services functional and technical expertise. The output side of the structured collaboration model, the Approved DLMS Change (ADC) provides new or revised business rules, business objects, metadata and functional requirements to guide Component implementation of the ADC. S New and Revised Requirements. A new requirement, design modification, system deficiency, change in DoD logistics policy, information exchange, or an operational emergency can all trigger a PDC. Examples of significant changes include those that create substantial life cycle cost savings, correct deficiencies, or make significant effectiveness change(s) in operational or logistics support requirements. Proposal submission requires inclusion of detailed procedures and the text of revisions for the DLM series manuals. Other changes include, but are not limited to: revisions to formats, codes, procedures; or changes requiring interface with other systems, retail level systems, or Federal Agencies. For all DLMS changes, two key elements are defining the problem, process gap or process improvement desired, and socializing the proposed change within the Component subject matter experts, and putting forward a recommendation from of a set of alternative solutions. S DLMSO will maintain the status of DLMS changes. The report will show the title and change number, associated dates, and current status for each DoD Component. The status review is updated continuously and is available at 6/dlmso/eLibrary/changes/processchanges.asp. S5.2. Submission of PDCs PDCs will be submitted to DLMSO through the applicable DoD Component Process Review Committee (PRC) member. S5.3. Staffing of DLMS Changes The DLMS Change Process Flow Chart illustrates the process to submit a PDC. In summary, processing a change, waiver, or deviation to DLMS involves the following steps. Appendix 2 is a narrative form of Figure 7. Page 33

42 Figure 7 DLMS Change Process Flow Chart Begin Initiator Submits Change Proposal to Component PRC Representative Yes Component PRC representative coordinates with Component Component PRC representative submits to appropriate PRC Chair Issues? PRC Chair reviews for methodology, compliance, and completeness No PRC Chair consolidates coordination comments and submits proposal package to director, Defense Logistics Management Standards for signature Signed change proposal package approved and submitted to component PRC members to evaluate and comment No PRC representative provides concurrence/non-concurrence to PRC Chair Comments received by PRC Chair PRC Chair reviews/evaluates comments, coordinates comments with PRC as required, and completes change proposal package All concurrences? PRC Chair submits change proposal package for approval Yes Defense Logistics Management Standards forward unresolved disagreements to ASD(L&MR/ SCI) for resolution Defense Logistics Management Standards determine impact and forward change request to ASC X12 through appropriate channels Yes Approved? Yes No Notification of disapproval PRC Chair No PRC Chair to coordinate change to ADC Change Approved by ASC X12? Does change need ASC X12 approval? No PRC S/A Member Defense Logistics Management Standards decide if the approved change should be adopted by DoD prior to ASC X12 approval Yes Component and DLA Transaction Services implement change Components provide implementation status updates to PRC Chair Initiator End Page 34

43 Section 6 - The Journey from MILS to DLMS S6.1. Getting Started S Like any other journey there are four major steps required. Step 1. Identify the need or desire to make the journey. Step 2. Define the starting point. Step 3. Define the destination. Step 4. Plan and execute the route to get from the starting point to the final destination and the following sections identify essential elements to getting a DLMS migration project launched. S6.2. Top Management Commitment S Regardless of the starting point, resources will be needed, and consequently some reprioritization of existing resources and new resources will likely be required to successfully implement the DLMS. The highest levels of DoD have mandated DLMS implementation with a target completion date of S Regardless of the Legislative and DoD mandate, individual Component top management must be supportive and engaged in the journey to implement DLMS from the very beginning.. Therefore it is imperative any DLMS implementation program begin by attaining top management support and keeping them informed of progress and impediments through each major milestone as the implementation progresses. S6.3. Define the Task: S New System Development. The development of a new system, such as the implementation of a Commercial Off the Shelf (COTS) based system or a newly government developed system has some unique challenges. Challenges such as ensuring the front door application, i.e., the point at which business transactions entering the system from external systems and where the system constructs outbound business transaction to other systems, must be designed from the outset to the DLMS with conversion mapping and data parsing to the internal file/database/messaging format native to the system. In the case of a new system, large logical functional chunks of the system will have to be implemented at a single time according to the overall system release plan. Therefore the DLMS implementation portion (i.e., transactions within an implementation increment) will be driven by the overall system implementation and deployment schedule. S Legacy Migration. A legacy system using 80 record position transactions will also need to develop the front door capability to read, use, and parse incoming DLMS business transactions and to format outgoing DLMS Transactions. The biggest difference here, is an extant system already performs business functions with an existing front door accepting and Page 35

44 transmiting MILS formatted transactions. A legacy system migration is, in many respects, simpler than implementation of a new system. The existing system already communicates with external systems using the MILS. The challenge is to convert it to communicate using the DLMS formatted transactions. In this case the best implementation strategy is make the front door bilingual i.e., capable of reading and writing either MILS or DLMS transactions. This approach provides significant flexibility not limited to the chunks of functionality supported. There will be additional discussion of the bilingual approach under the section Implementation Strategy - Successful Generic Approach below. S A Mix of New and Legacy Systems. A Component may be faced with a mix of legacy systems requiring migration to the DLMS and the implementation of one or more new systems that must be developed to the DLMS transactional interfaces. There are instances where new systems are replacing many but not all MILS dependent legacy systems. In this case an overarching Component Plan will need to be developed showing the key milestone dependencies among the systems moving to the DLMS environment, both the new systems replacing legacy MILS systems and the remaining MILS based systems that will need to migrate to the DLMS. S6.4. Conduct an Inventory S The journey starts from the system s current capabilities, so whether it s a single system or a Component portfolio of systems, an accurate baseline needs to be established. The baseline must consider what business functions are in the scope of the plan, the systems that interface with other systems within the business scope and an accurate accounting of which applicable ADCs have been implemented and which have not. S Scope of Business Functions. The plan needs to determine the breadth of the functional scope that it covers. That will determine which systems supporting that functionality are within the scope of the effort. The determination of what transactions support those business function is a critical step, the DLA Logistics Management Standards Office website contains the full set of MILS transactions and the map to the equivalent DLMS Transaction that replaces it. The mapping, at the transaction level, Defense Logistics Standard Systems (DLSS)/Defense Logistics Management Standards (DLMS) Cross-Reference Tables can be found at The cross reference allows the user to choose a table arrayed by MILS Document Identifier Code (DIC) to the equivalent DLMS Transaction or via versa. Figure 8 shows an image of the Cross Reference Report arrayed by DLMS Transaction type and cross referenced to the MILS transaction DIC it replaces. Page 36

45 Figure 8 MILS To DLMS Cross Reference Report S Interfacing Systems. Having determined the systems within the functional scope, a system by system inventory of interfaces must be made with identification of the type of interface, i.e., MILS or DLMS or Component unique transactional interface transaction sent or received by each interfacing system. If Component unique transactions exist, they need to be carefully assessed to determine if they are within the business scope supported by the DLMS and if so they will need to be compared to existing DLMS transactional data content and functional capabilities. Often the DLMS can support Component unique transactions. In other instances an existing DLMS transaction can be modified to accommodate the Component unique transaction/data. Components should submit Proposed DLMS Changes to modify the DLMS to satisfy Component unique requirements. S Enhanced DLMS data capabilities are those new data elements associated business processing rules over and above those data elements/rules within the MILS legacy transaction data environment. S Efforts and resource expenditures to accommodate enhanced data capabilities need to consider whether the data is available from or useful to interfacing systems. Resources should only be expended if the interfacing system(s) can provide DLMS enhanced data or use DLMS enhanced data. Scheduling DLMS enhanced data capabilities must consider the schedules of interfacing systems for their ability to supply or consume the enhanced data. Page 37

46 S While the goal of migrating to the DLMS is to capitalize on its enhanced data capabilities, initially it is prudent to either not include any enhancements or to severely limit the enhancements in the initial implementation. Doing so limits the coding workload and number of variables considered when developing and applying test cases to the systems new code. Enhancements can be included at any time, but the initial effort should focus on making the system communicate using a new DLMS messaging format. The enhanced capabilities in each DLMS transaction that do not exist in the equivalent MILS format can be found at The enhancements available for each DLMS transaction type can be found by opening the Word document link under the column DLMS Enhancements. S Current Approved DLMS Change (ADC) Baseline Each system migrating to the DLMS needs to establish a baseline of current functionality based on which ADCs (MILSTRIP, MILSTRAP, MILSBILLS, etc.) have been implemented within the System. All ADCs issued by DLMSO are available on the DLMS Website 6/dlmso/eLibrary/Changes/approved1100.asp. ADCs beginning with ADC 1 and continuing through the current 1000 series of ADCs are shown. The user can determine which ADCs have yet to be included in the Defense Logistics Manuals by checking the Change History log at the beginning of each DLM Volume. Doing so will enable the user to identify which ADCs have yet to be included in the most current issuance of the DLM. It is important to note only the Component can actually determine what ADCs through time have been included in the computer code of the system being migrated to the DLMS. Establishing a baseline of ADCs implemented within the system is also useful for scheduling future releases of the migrated system. The ADCs need to be examined as to whether there was a prior mandatory implementation date, the applicability to the Component system being migrated and functional value of the change to the Component processes. All the foregoing will aid in prioritizing ADCs for implementation. Some may be essential for the first upcoming DLMS release, while others may be scheduled for releases beyond the initial baseline DLMS capability. S6.5. Develop High Level Generic Strategy S The foregoing established a baseline to identify the starting and ending point in the journey. The next task is to plot the route from the beginning to the destination. The key to success is to not be too ambitious in tackling the task. Whether implementing a new system or migrating a legacy system, the road to success is best served by not trying to do too much the first time out of the gate. There are many ways to break down the journey into manageable pieces. S Successful implementations all began with implementation of the DLMS transactions focusing on transmission of the same data content currently contained within the MILS Transactions. This is called the DLMS Data Baseline. This approach limits the number of variables. Whether replacing an existing system or migrating a legacy system, limiting the initial DLMS implementation release to the data content contained within the 80 record position transaction formats, allows for simpler testing against the known outcomes from the same data in a different message format. Page 38

47 S New systems begin with DLMS and end with DLMS, but the sequence of which DLMS transactions are implemented first is driven by the overall functional development and deployment schedule. Some development efforts are based on an organizational alignment strategy. For example, DLA s Enterprise Business System (EBS) was implemented based on the inventory control point serviced and therefore by types of items managed. Subsequent to the support of its inventory control points, DLA then expanded EBS to support its DLA Disposition Services mission and is currently in the process of implementing its mission to provide the DoD and other government agencies with energy support. The Army has taken a similar organizational development/deployment approach in implementing its Logistics Modernization Program (LMP), an ERP replacing its legacy Commodity Command Standard System for wholesale materiel management and its legacy retail systems replacement Global Combat Support System (GCSS-Army). S Legacy System Migration to the DLMS provides far more ability to take smaller steps in the journey. First and foremost there is a complete functioning system in existence and a workforce trained in its use. Legacy systems enjoy the advantage of MILS transactions migrated initially and in subsequent releases can be as few or as many as the program office chooses. Smaller numbers are best to begin with to gain experience and confidence and limit testing complexity. S6.6. Suggested Steps for a DLMS Implementation Project See Appendix 3 for an abbreviated synopsis of the 10 Steps to Success. The following descriptions provide a more detailed explanation of the set of steps used by several successful implementers. Additional details associated with the below steps are provided in the referenced appendices. S Step 1 - Assemble Core Functional and Technical Team. The sooner key functional and technical personnel can be identified and assembled the better. The exact organization of the team is up to the program manager, but a pairing of functional personnel who know the business processes with technical personnel who are familiar with the systems coding, inputs, outputs, data base/file structures is ideal. Technical personnel with experience in using the ANSI ASC X12 standard are desirable, if available, but not essential. S Step 2 - Schedule DLMS Introduction Course. This DLMS Implementation Strategy Guide provides useful information and makes use of selective DLMS Introductory Training slides, but should not be considered a replacement for the formal training. DLMS training should be scheduled early in the process, but not before the core functional/technical team has been assembled. Contact DLMSO early so scheduling of training can be accomplished. The Catalog of the DLMS Introductory Training Modules can be found in Appendix 1. The scheduling should ensure the entire team can be trained on the same day. The training is intense and will take one full day. A class training agenda and materials for the student books will be tailored to the particular project team needs and provided to the team in advance of the class. Page 39

48 S Step 3 - Initiate Contact Points with DLMSO and DLA Transaction Services. Establish a single program office point of contact with both organizations through whom all requests for information will flow to ensure responsive support and to eliminate duplicate requests. The initiation of contact with DLA Transaction Services will facilitate effective communications throughout the program and set the stage for some of the actions such as initiating necessary agreements and accesses, establishing technical consultation contacts, acquiring DAAS MILS/DLMS maps, setting up test schedules, etc. The key points of contact and services provided by DLMSO and DLA Transaction Services are in Appendices 4 and 5 respectively. Make maximum use of the services provided to implementers. Most of this document describes the key actions the Component and its System s DLMS Migration program office need to perform. However, it is also important to know what actions and services are available to the program office so they don t waste resources on things already provided at the enterprise level. S Step 4 - Initiate an Agreement with DLA Transaction Services. DLA Transaction Services requires a formal agreement. There are four potential types of agreements depending on the situation: Memorandum of Agreement (MOA). A memorandum that defines general areas of conditional agreement between two or more parties within DLA. Performance Based Agreement (PBA). A memorandum that defines general areas of conditional agreement between two or more parties outside of DLA (usually the Military Services). Interservice/Interdepartmental/Agency Support Agreement (ISA). An agreement to provide recurring support to another DoD or non-dod Federal activity. ISAs define the support to be provided by one supplier to one or more receivers, specify the basis for calculating reimbursement charges for each service, establish the billing and reimbursement process, and specify other terms and conditions of the agreement. ISAs are recorded on DD Form Interface Requirements Document (IRD) and Interface Control Agreement (ICA). An IRD and ICA are generally subordinate documents to a PBA or MOA which outline in detail the specific measures to accomplish the agreement objective, and usually associated with a Contractor. An Authority To Operate (ATO) or equivalent will have to be on file before the applicable agreement will be accepted and routed for coordination. In lieu of an ATO, DLA Transaction Services will accept one of the following documents: Interim Authority To Operate (IATO) System Security Plan (SSP) Page 40

49 The applicable agreement, ATO or equivalent, and System Access Request (SAR) must all be approved before any testing or production activities can commence. The SAR will not be approved until the applicable agreement is finalized and signed by the Director, DLA Transaction Services, and the customer's approving authority and returned to DLA Transaction Services. This process can take several months to complete, so its importance cannot be overlooked. Interactive testing with DLA Transaction Services is dependent on having approved documents on file. Do not delay the submission of these documents, submit requests early within the migration plan. This task should be monitored by the program office weekly until complete. The agreement templates are available from DLA Transaction Services. Any questions on completing these templates can be directed to and The instructions for obtaining a SAR are at S Step 5 - Acquire the DAAS Maps from the DLA Transaction Services. The DAAS maps were discussed earlier and an example of the 527R map was provided. The current versions of the DAAS maps are only available from DLA Transaction Services. There is a DAAS map for each DLMS transaction type, and the map provides the ability to see exactly where in the DLMS transaction the MILS data elements exist for the DICs it is replacing. These maps are very useful, particularly for the members of the migration team that have a high competency in the MILS transaction environment. Early familiarization with the map constructs is very helpful; however, the current DAAS Map should be requested at the time actual work on a specific MILS DIC migration begins, as discussed in the detailed discussion in Step 8 entitled Start with one existing MILS transaction. S Step 6 - Decide on the DLMS Messaging Format DLMS X12 EDI or DLMS XML. Both the DLMS ICs and the corresponding DLMS XML schemas are available at They can be found under the column heading DLMS IC. For each DLMS Transaction identified in the first column the most current DLMS IC will be the first document (the PDF document) in the fourth column. The most current corresponding DLMS XML schema/xml Schema Definition (XSD) will be the last document in the fourth column for that DLMS transaction type. The XML XSD will be preceded by the icon. The far right hand column identifies the correlating MILS DICs formats. The program office will need to decide early on how to proceed. The factors to consider are discussed in greater detail in Appendix 6. S Step 7 - Work at the System Front Door and Establish DLMS Baseline Capability. Broaden the application front door code to allow the system to be bilingual i.e., capable of transacting business in both MILS and DLMS formats. All systems have applications where transactions enter the system, are identified, validated, archived, transformed into the systems native transaction/messaging format and passed to the appropriate applications within the system. Likewise, applications pass information to the front door to exit transactions from the native transaction form to the standard enterprise format. This is the area where work should begin as discussed in greater detail in Appendix 7. Whether implementing a new system or migrating a legacy system the road to success is best served by not trying to do too much the first time. All successful implementations have begun with implementation of the DLMS transactions focusing on transmission of the same data content currently contained within the legacy MILS Transactions, called the DLMS Data Baseline. This approach limits the number of variables. Page 41

50 Whether it s a new replacement system or a migrating legacy system, holding the initial DLMS implementation release to the data content contained within the MILS transactions allows for simpler testing against the known outcomes from the same data in a different message format. Additional detail regarding work at the system s front door to establish a DLMS baseline is provided in Appendix 7. S Step 8 - Start with one existing MILS Transaction. Pick a MILS DIC and add code to the front door to allow the system to recognize the equivalent DLMS transaction, then edit and parse the data in the DLMS transaction into the native database/file format such the resulting edits and data population of the system s native database/file structure mirror the result of the equivalent MILS transaction. Acquire the DLA Transaction Services Map for the transaction that will be the enable the migration team to see where each data element in the MILS transaction is identified and located in the replacing DLMS transaction. Pick an initial transaction with a lot of reusability; that is, where there are multiple MILS transactions that perform a similar function with the primary difference among them being the DIC. Additional detail is provided in Appendix 8. S Step 9 - Implement a MILS/DLMS Switching Table. This concept is discussed in greater detail in Appendix 9. Note, building the switching table into the customer s migration plan strategy provides a great deal of control and flexibility. It also significantly reduces risk. Its implementation enables early experience and success to build upon. S Step 10 - Plan future incremental releases of Enhanced Capabilities. Develop a plan to include the enhanced process and data capabilities that are available in the DLMS environment. The ability to capitalize on the enhanced capabilities is the primary reason for migrating to the DLMS; therefore, consideration and planning of what comes after the baseline DLMS capability needs to be a part of the initial planning, resourcing and scheduling. Additional detail is provided in Appendix 10. S Step 11 - Develop and Execute Incremental Test Plan and deployment schedule. This DLMS migration strategy is fundamentally one of coding a little, testing a little, deploying a little and repeating the process until all DLMS have been migrated and all relevant desired and/or mandated DLMS enhancements have been included in the system. Page 42

51 Appendix 1 Appendix 1 - Training Synopsis Course Description. This training provides basic awareness and broad-spectrum knowledge of Defense Logistics Management Standards (DLMS). DLMS are a broad base of business rules designed to meet DoD's requirements for logistics support. The DLMS are developed in collaboration with the Military Departments, Defense Agencies, and participating Federal Agencies to accommodate the old DoD-unique logistics data exchange standards and processes commonly referred to as the "MILS" (Military Standard), plus new information exchange requirements supporting modernization. DLMS transactional exchanges are founded in American National Standards Institute (ANSI) chartered Accredited Standards Committee (ASC) X12 commercial standards and support other emerging electronic business (EB) technologies, such as extensible Markup Language (XML). The training provides an introduction to electronic data interchange (EDI) as applied under the DLMS and includes an introduction to commercial EDI, DLMS background and concept, DLMS implementation strategy/planning, and an overview of understanding of DLMS-specific EDI. This training is of particular value to functional and technical subject matter experts involved with the migration from the legacy 80 record position formats supporting MILSTRIP, MILSTRAP, MILSBILLS business processes. Key Course Objectives Understand the background and current applications of commercial EDI, DLMS and Federal and DoD Electronic Commerce/EDI, DLMS policy Understand basic commercial EDI, DLMS standards and mapping process Understand the additional capabilities provided by EDI, DLMS Understand the overall DLMS, DLMS operating concept and implementation strategy Understand the DLMS change management process Understand the DLMS Implementation Conventions (ICs) Understand how DLMS addresses new DoD requirements for Unique Item Identification (UID) and Passive Radio Frequency Identification (RFID) Understand the options for employing XML, DLMS under the EDI, DLMS DLMS Training Course Overview. The DLMS training Catalog consists of nine training modules. A summary of each is provided below. With few exceptions each Module builds on the preceeding Modules in terms of increasing the student s depth of DLMS understanding. Classes are typically one day in length and usually consist of Modules 1, 2, 3, 4, 5, 6, & 7. Classes are generally composed of a mix of students, some having a functional background and others having a systems technical background. The class is designed principally to aid program management offices that are implementing DLMS within one or more Component automated information systems. The class is applicable regardless of whether it is a new start system, such as a new Enterprise Resource Program (ERP), or the migration of a legacy system from the legacy MILS transaction environment to the DLMS. Classes can be customized by inserting or deleting Modules as applicable to the customer needs. For example Module 4F DLMS Functional Financial Transaction Life-Cycle can either supplement or replace Module 4 if the focus of the class is finance rather than the usual broader logistics focus. Likewise Module 6A Page 43

52 Appendix 1 DLMS Configuration Management (stand-alone) is designed as a short two hour presentation on how changes to the DLMS are initiated, reviewed, staffed, approved, and published. Modules 7, 8, and 9 all deal with Enterprise Interoperability Tools; Module 7 is an overview of the available tools, while Module 8 DoD Activity Address Directory (DoDAAD) and Module 9 Supply Discrepancy Reporting (SDR) Training provide more detailed training on those respective tools. Modules 7, 8, and 9 can be included (in part or in total) in the full days curriculum depending of the class need/desires or they, as well as Module 6A, can be provided as stand-alone training. Module 1 - Introduction to the DLMS. This module sets the stage for the remainder of the Modules. In this Module the students learn that the DLMS are a set of carefully managed standards essential to interoperability of the Global Supply System. The students learn business processes and process improvements supporting DoD logistics policy is the thrust of the DLMS. The DLMS document the approved standard business rules, information exchange formats, and data implemented uniformly within information systems across the enterprise of trading partners participating in the logistics processes supported by the DLMS. Students learn how DoD policy is translated through the DLMS into system actionable standards and how those standards are developed, managed and syndicated. This module covers how electronic interchange (EDI) fits into the DLMS and they learn about the organizations that provide enterprise-wide support services that facilitate uniform implementation. The students are presented with the top down chain of policies that specify the authority and governance structure of the DLMS. The Module ends with a high level discussion of how to implement the DLMS, current implementation metrics and the ten steps that prior implementers have followed in successfully implementing the DLMS. Module 2 - Electronic Data Interchange (EDI) Basics and ASC X12 EDI Definitions and Concepts. This module builds on Module 1 by concentrating on the commercial transactional information interchange standard that underpins the transaction exchanges of business event information among systems involved in a particular business process. The focus is on learning the fundamentals of the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12. The Module presents students with the hierarchical construct of the standard beginning with the definition of a data element, how related data elements are grouped into transaction segments, how segments are grouped to form a transaction set and how transactions are grouped/enveloped for transmission. The students learn how and why the standard is technically rigid while enabling virtually unlimited functional flexibility. At the end of the Module the students are able to identify how legacy MILS data is presented in a DLMS Transaction and are able to relate the data in a MILS requisition to its construct and location in the equivalent DLMS 511R Requisition. The architectural framework of the ANSI ASC X12 Standard presented in this Module is an essential pre-requisite to Module 3 and particularly to Module 4. Page 44

53 Appendix 1 Module 3 - DLMS Functionality & Transaction Life-Cycle. This Module builds upon the knowledge of the preceding Modules by showing the relationship of the DLMS and Legacy MILS data formats. The Module depicts the transaction flows and relationships of both legacy MILS and the equivalent DLMS among trading partner systems to support the requisition, wholesale stock replenishment, and physical inventory process life-cycle of business events. The module also introduces the breadth of added data and process improvement capabilities supported in the DLMS processing environment that the legacy MILS environment is unable to support for the process life-cycles illustrated. The Module also identifies the breadth of functionality covered by the DLMS but whose transaction life-cycles are not illustrated in the Module. The DLMS transactions are identified and grouped by business function supported. This Module ends with screen shots or a live demonstration, when possible, of the DLMS Website showing how to navigate and find the various resources necessary to implement and maintain the DLMS. Module 4 - DLMS Transaction Supplement Content. This Module builds upon the knowledge gained in the preceding Modules and dives into the detail of a DLMS Implementation Convention (IC). Using the knowledge gained in Module 2 of the rigorous architecture of the ANSI ASC X12 broad standards, this Module applies a specific DoD Logistics business context to the standard in the form of DLMS ICs that support the business process event life-cycles introduced and illustrated in Module 3. This module covers the purpose and content of DLMS ICs, how they are used to support a systems implementation of the DLMS and the absolute criticality of DLMS notes contained in the DLMS ICs including the types and applicability of the notes. The Module also covers the DLA Transaction Services maps used to translate 80 record position legacy transactions from MILS-based systems to DLMS transactions destined for systems transacting business using the DLMS. The MILS and DLMS mapping exercise is very helpful to class members having a high familiarity with MILS transactions but limited knowledge of the DLMS. This module ends with an in-depth class participation walk through of the DLMS 511R Requisition. At the end of this module, students will be comfortable in reading, interpreting, understanding and utilizing any of the DLMS transaction implementation conventions. Module 4F - DLMS Functional Financial Transaction Life-Cycle. This Module is normally only presented to classes whose sole interest is the financial transactions associated with the support of MILSBILLS interfund billing. The module covers the same types of materiel covered in Module 4, but the transaction used for in-depth class participation implementation convention walk through is the DLMS 810L Logistics Bill. Module 5 - IUID and RFID - Emerging Technologies. This Module builds upon the knowledge of Modules 1 through 4 by showing the power and the flexibility of the DLMS to incorporate new data and processes to integrate new concepts and technology in to business processes using Radio Frequency Identification (RFID) Tags and 2D data matrix bar codes supporting unique item identification to improve pipeline visibility, streamline business event processing, improve data capture accuracy, improve pipeline visibility and support improved item life-cycle management. The module allows the student to see the practical application and benefits that DLMS implementation allows the Component systems to capitalize on. Page 45

54 Appendix 1 Module 6 - Creating/Reengineering DoD Logistics Business Processes. 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 (PRCs) 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, and implementing Approved DLMS Changes (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. Module 6A - DLMS Configuration Management (stand-alone Module). This module is designed to be given as a single Module to a class that is solely interested in how the DLMS change process is managed and how they can initiate and participate in DLMS changes. The Module draws from information in Modules 1, 3, and 6. Module 7 - Enterprise Interoperability Tools. This Module covers the key interoperability tools/applications/databases that are integral to the DLMS. Each of the following is introduced to the class stressing its purpose, usage, and relationship to the DLMS in support of the enterprise supply system. For each topic the students are provided contact points and reference links to manuals and other reference material that will allow them to gain deeper understanding of each, as applicable. The following are the topics covered in the Module: DoD Activity Address Directory (DoDAAD ), Military Assistance Program Address Directory (MAPAD), Web Supply Discrepancy Reporting (WebSDR), Uniform Material Movement Issue Priority System (UMMIPS) Reports, Fund Code Tables, Logistics Metrics Analysis Reporting System (LMARS), Materiel Receipt Acknowledgement (MRA) Reports, and Project Codes. Module 8 - DoD Activity Address Directory (DoDAAD). This Module provides an indepth understanding of the DoDAAD. This is the database where DoD Activity Address Codes (DoDAACs) and all the related pedigree data associate with each resides. DoDAACs are essential elements of virtually all business events, business rules and business transactions. DoDAACs permeate the processes of acquisition, all facets of logistics, and transportation. This Module covers the DoDAAD and DoDAAC definitions, users, content, structure, governance process, architecture, and the method of maintenance, syndication and query. Module 9 - Supply Discrepancy Reporting (SDR) Training. Module 9 is a stand-alone training Module that provides user instructions for the DoD Internet-based Tool for submission and processing of SDRs. The module provides a general overview of the SDR process and tool; how to obtain access to the tool; how to initially submit an SDR; special business rules for transhipper SDRs; the action activity roles and activities in providing SDR responses; how to submit and process SDR follow on actions (delinquent responses, corrections, requests for reconsideration, and cancellations), and how to make queries to obtain routine canned and ad hoc special reports. Page 46

55 Appendix 2 Appendix 2 - DLMS Change Process Steps Step 1. The PDC sponsor submits a PDC (or waiver or deviation request) in the format available at to the DLMSO Director, or appropriate PRC chair. The instructions are included at the end of the change proposal template. When more than one committee is involved (i.e., supply, finance, or pipeline measurement), the PRC chairs involved will determine the lead PRC and coordination required. Step 2. Within 10 calendar days of receipt of proposal, the PRC chair evaluates the proposal and determines appropriate action, (e.g., return for additional information, work with PDC sponsor to clarify/amend, accept for staffing). The PRC Chair will verify the submitter adequately addresses the following items in the PDC: Identify impact to current business processes Identify organizations and systems and respective roles Identify new business procedures and associated business rules Define new DLMS data elements and/or changes to existing ones Define new information exchanges and/or changes to existing ones Identify the required implementation timelines by impacted systems Identify any impact to existing DoD policy. Step 3. If the proposal is accepted for staffing, the PRC chair assigns a PDC number and updates the draft PDC to ensure the following items are included, as applicable: Insert required changes to DLM series of manuals Insert required changes to DLMS ICs Assess interoperability impact to DoD global supply chain Identify any additional DoD impacts Identify and coordinate with OSD on possible DoD policy impacts Optimize solution for reuse, effectiveness and efficiency. Step 4. Once the submitting organization and the DLMS PRC chair are in agreement with the PDC content, the PDC will be released to the DoD Component PRC members for coordination. The PRC chair also determines if submission to external standards bodies such as ANSI ASC X12 is required. If the PDC includes a change to a DLMS IC that requires review and approval by the external standards bodies, the PRC chair will forward the IC change(s) and/or related data maintenance request(s) to those groups/committees for processing after the proposal is approved or in conjunction with staffing, as appropriate. Step 5. The PRC members provide the PRC chair a fully coordinated DoD Component or participating Agency response, including a proposed implementation strategy including the desired/required implementation timeline when available, by the due date provided in the proposal, normally within 30 days of the date on the PDC. If the Component/Agency response is Page 47

56 Appendix 2 a non-concur, it is incumbent on the PRC representative to explain the issue and provide a proposed resolution to the DLMS PRC Chair. Step 6. The PRC chair may initiate a follow up for non-response within 5 calendar days of the due date. Additional follow up may be elevated as appropriate. Step 7. The PRC chair will evaluate all comments on the PDC within 10 calendar days from receipt of all outstanding comments or in conjunction with the next scheduled PRC meeting. If necessary, the PRC will resolve comments and/or disagreement and establish an implementation date. If the Component comments cannot be resolved by the PRC membership or policy issues exist, unresolved issues may be elevated to the applicable OSD proponent for resolution. If the PRC approves the PDC, the PRC chair will establish an implementation date based on consensus. If the PDC is disapproved by the PRC, the sponsor is notified of the disapproval. Step 8. Based on PDC responses, and the interface requirements associated with the specific change, the PRC chair will establish a joint implementation date, or when appropriate, either authorize DoD Components and participating organizations to implement on a staggered schedule or authorize a limited implementation by impacted Components. This information will be included in the ADC. PDCs that begin with the 1000 number series will retain that same number in the ADCs. Implementation Date. When an implementation date is not known/provided as part of the PDC adjudication process, the PRC chair will include in the ADC a requirement for the DoD Components and participating organizations to actively monitor for implementation of the ADC and provide implementation dates when they become available. Extended Implementation. When one Component provides an extended implementation date, which would delay implementation by the other Components, the PRC Chair will attempt to resolve the issue with the appropriate Component or seek a methodology that will permit a phased or staggered implementation. When a satisfactory implementation date cannot be jointly agreed upon, the PRC chair may refer the matter to the applicable OSD proponent for resolution. Step 9. The DLMS PRC chair will prepare the ADC by updating the PDC content based on adjudication of Component responses to the PDC. This includes the following: Formalize changes to DLM series of manuals Formalize changes to DLMS ICs Create SEF and XSD files in support of DLMS IC changes. Step 10. When approved, all approved DLMS changes (ADCs) are formally incorporated into the DLMS Manual and posted on the DLMS Website Approved DLMS changes are also posted with the appropriate DLMS IC at Page 48

57 Appendix 3 Appendix 3-10 Steps to Success 10 Steps to Success: There are 10 steps to implement the DLMS in a new system or to migrate a legacy system from DLSS (MILS) to a DLMS EDI or XML compliant system. The following is a quick reference of the steps required, more details are provided at Appendix C (DLMS Implementation Plan) and Appendix H (Lessons Learned). 1) Assemble Team of functional and technical experts on the system 2) Initiate early contact with DLA Transaction Services and other trading partners such as DFAS, MOCAS, IRAPT, Military Services, etc. The DLA Transaction Services point of contact is Joanne Norman, commercial or DSN , [email protected]. a. Develop an applicable agreement and Authority to Operated (ATO) or equivalent with DLA Transaction Services. Submit the agreement, ATO, and System Access Request (SAR) as soon as possible, so all actions can be completed in a timely manner. The agreement, ATO, and SAR must be approved and on file before DLA Transaction Services can provide testing or production support. This process can take several months to complete therefore, the importance cannot be over emphasized. Testing and production support with DLA Transaction Services is dependent on having the final agreement approved and signed by DLA Transaction Services and the customer. This task should be monitored by the program office weekly until complete. The instructions for obtaining a SAR are at b. Acquire DLA Transaction Services MILS to DLMS X12 data maps for the transactions being migrated. These maps are invaluable for both legacy migration and new development. c. Establish communications mechanisms with DLA Transaction Services and determine what transfer protocol will be used with DAAS. 3) Schedule DLMS training with DLMSO and acquire training. Training courses can be requested by contacting Heidi Daverede, , DSN , [email protected]. 4) Select, acquire or develop an EDI or XML translator/parser: a) This software decodes the syntax associated with the inbound transactions, enabling the parsing of the individual data fields in the transaction and provides for the appropriate assemblage of data fields with correct syntax formatting for outbound transactions. b) There are a number of COTS products available that support this process. c) The Distribution Standard System (DSS) development team that successfully migrated DSS from the MILS to the DLMS determined that the appropriate course of action for them was to develop their own decoding/parsing and formatting code and integrate it with the DSS application itself. 5) Develop phased migration plan/schedule: Page 49

58 Appendix 3 a) Phase I. Establish DLMS X12 EDI or XML baseline, determining the MILS transactions that enter and exit the system (implement the data content of the MILS using DLMS X12 EDI or XML). Examine all transactions carefully for non-standard Component unique data. If a Proposed DLMS Change (PDC) is required to accommodate non-standard data, submit a PDC as soon as requirements have been established. Processing the PDC takes time, so the earlier it can be submitted the better. PDC submission instructions can be found at b) Phase II: Identify initial DLMS X12 EDI or XML enhanced data functionality to be implemented c) Phase III: Determine, plan and schedule DLMS X12 EDI or XML enhanced data content for incorporation into system processing 6) Pick a simple transaction to work first and do one at a time, reusing as much as possible for the next transaction. a. Note the MILS are composed of families of transactions, such as the DD_ series of MILS Document Identifier Code transactions that migrate to a DLMS DS 527D. Once having developed the computer code to migrate a MILS DDM to a DS 527, much of the code will be reusable for the other MILS documents in the DD_ series. b. New development also will benefit from developing the first transaction completely before moving on. Format and syntax are shared across the transactions. Once one is develop, much of the code can be reused. 7) Use EDI or XML translation software and DLA Transaction Services logical data maps to map/parse data for incoming/outgoing DLMS transactions. 8) Establish table driven MILS or DLMS on/off switching mechanism to establish control, allow for phasing and fail safe fall back. a. A variation on this theme for new development is the use of transformation templates for checking in and checking out versions of the EDI transactions. For example, moving from a 4010 version to the ) Test, Test, Test a. Establish loopback testing arrangement with DLA Transaction Services where legacy system sends MILS to DLA Transaction Services and DLA Transaction Services returns equivalent DLMS X12 for validation/verification of correctness. b. Conduct unit code testing on each transaction (test all conditions) c. Conduct system testing d. Schedule and conduct integration testing with DLA Transaction Services e. Obtain trading partners, if needed, to exchange data 10) Schedule cut over in increments, implementing few transactions at a time coordinating closely with DLA Transaction Services. Page 50

59 Appendix 4 - DLA Logistics Management Standards Office Support Management POCs: Name Phone D.C. Pipp (Director) (703) /DSN [email protected] CDR Jason Morris (703) /DSN [email protected] Functional Support POCs: Name PRC Phone Ellen Hilert MILSTRIP, SDR (703) DSN Mary Jane Johnson MILSTRAP (703) DSN Bob Hammond MILSBILLS (703) DSN Tad Delaney DoDAAD (703) DSN Heidi Daverede MILSTRIP, (703) TRANSPORTATION, DSN DLMS Training Ken Deans LMARS (703) DSN Samantha Khuon MAPAD (703) DSN Rafael Gonzalez Physical Inventory (717) Control, JPIWG DSN Ben Breen SDR (614) Sylvia Williams MILSTRIP, DLMS Training DSN (703) DSN Technical Transaction Support POCs: Name Area Phone [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Frank Napoli ANSI ASC X12 (703) [email protected] DSN Dale Yeakel Implementation (703) [email protected] DSN Larry Tanner Implementation (Alternate) (614) [email protected] Page 51

60 Technical Metadata Support POCs: Name Area Phone Paul Macias Data Dictionary (703) DSN Support Services Offered to Implementers: Functional and technical consultation Providing X12 implementation conventions and XML schemas Arranging, facilitating, coordinating trading partner meetings/teleconferences Providing assistance during testing Modifying and maintaining constant configuration management of DLM business rules, transaction formats, and metadata and representing DoD logistics interests to internal and external standards bodies Keeping the DLMS Website current with support tools available 24/7 Providing DLMS Training materials and classes Page 52

61 Appendix 5 Appendix 5 - DLA Transaction Services Support DLMS ebusiness Program Management POCs: Gary Wooddell (937) /DSN , [email protected] Performance Based Agreement/Memorandum of Agreement POC: Audrey Lavoie, (937) , [email protected] Logistics Functional Support POCs: Army/GSA: ([email protected]): - Allen Coleman (937) /DSN Air Force: ([email protected]): - Bernace Collier (937) /DSN Navy/Marines/Coast Guard : ([email protected]): - Edward Nolan Davis (937) /DSN DLA: ([email protected]): - George "Scott" Amburgey (937) /DSN Mapping Support POCs: Doug Mummert (937) , [email protected] Bill Strickler (937) , [email protected] Testing POC: Julie Kampman (937) /DSN [email protected] Ronald Woolley (937) /DSN [email protected] ebusiness Group (account set-up): [email protected] Page 53

62 Appendix 5 Support Services Offered to Implementers: Acting as a single trading partner with whom the system will interact Functional and Technical and Functional consultation Assisting in establishing a Performance Based Agreement (PBA) Providing the DAAS maps upon request Establishing a system profile and accounts Supporting Loop-back testing Establishing a unique Switching Table on the DAAS side for the system Providing a developmental test environment within DAAS Providing Loop Back Testing utilizing the DAAS MAPs Test problem diagnosis/resolution assistance Page 54

63 Appendix 6 Appendix 6 - Detailed Discussion of DLMS Migration Step 6 Decision on EDI or XML. The migration team will need to make an early decision on the transaction DLMS message form for the migration effort. The choice is up to the developer; both can be used if there is a need. From a purely functional data content stand point there is no difference, both will ultimately convey the same data element content values. Bandwidth Considerations. The following may be relevant in making the decision, with bandwidth and development complexity the primary considerations. EDI is a variable length record that only contains data, with a single delimiter character separating data elements and a single terminator character separating data segments. XML contains verbose human readable tag names in front of and following each and every data element value. The XML tag names make XML human readable but they also make an XML transaction up to 100 times larger than its EDI counterpart. The inherent XLM bandwidth issue is further exacerbated by the fact that the DLMS XML carries the additional X12 EDI segment/data element construct overhead. Interoperability Imperative. While deriving the XML schemas from the X12 EDI is necessary to ensure interoperability between DLMS X12 EDI and DLMS XML using systems, it causes messages to be much larger. It also means that a developer using DLMS XML must be conversant in both X12 EDI as well as XML. The X12 EDI standard has a larger commercial following for transaction based processes and is designed as a machine to machine interface. XML was designed for human/machine interfaces and is a good fit for Web presentation and internet web-sites. This does make it less band width efficient for supply chain processes that are based on predefined process flow between computers without human intervention. XML adds a layer of complexity that is not required. XML EDI transactions are more complex to process, although they are much easier to format for web presentation. Since the XML will not be used for web presentation, the added complexity adds no benefit. Both DLMS X12 EDI and DLMS XML Are In Use. The forgoing sounds like the choice is obvious but the DLMS have both an X12 EDI capability and XML. The DLMS X12 EDI has the far bigger usage; however, both are currently being used successfully. As stated previously, it is possible to migrate some MILS transactions to DLMS X12 EDI and others to DLMS XML. There have been no migrations to date that have done so; however, the DLA Transaction Services mapping capabilities and the MILS/DLMS Switching Table (discussed in Appendix 9) allows a bilingual migration from MILS to the DLMS X12 EDI or DLMS XML or a mix of both types of DLMS. The program office will need to acquire or develop an ANSI ASC X12 parsing tool that incorporated the ASC X12 standards and will be used to parse the data in the incoming transactions and prepare properly formatted outgoing transactions. There are a wide range of products readily available. Talk to DLA Transaction Services or other systems implementers. The acquisition or development of a parsing tool will need to be resourced and scheduled early in the program plan. The bottom line is the program office will need to decide whether DLMS X12 EDI or DLMS XML or a mix will be the migration end state based on careful analyses of requirements. Page 55

64 [This Page Left Intentionally Blank] Page 56

65 Appendix 7 Appendix 7 - Detailed Discussion of DLMS Migration Step 7 Establish DLMS Baseline. This appendix describes the successful approach taken by system program offices migrating a system that currently interfaces with other systems using the MILS to change that interface to use DLMS Transactions. The result of the accomplishment of the Phase 1 Migration is the ability to: (1) Assert Level 1: BASIC DLMS COMPLIANCE to the IRB and (2) lay the foundation for Phase 2 of the migration, incorporating enhanced DLMS data/capabilities and attaining Levels 2 and 3 working toward FULL DLMS COMPLIANCE. Generic System Construct. The graphic in Figure 8 depicts a typical business system construct. The pink area in the center of the graphic depicts the systems database (which may be singular or not) where current information is stored and retrieved within the system. The yellow blocks surrounding the database depict functional business applications within the system that perform specific functions, interact with the database and may pass data between the individual applications in an internal system native messaging format. Work at the System Front Door. While four applications are depicted in the graphic, a large system may have hundreds of sub-process applications. The black arrows depict data information flows within the system among the applications and the database(s). Surrounding the yellow applications is a light blue area, which for purposes of this document, is identified as the system s front door. This front door is a group of applications that are the doorway to the world outside the system. This front door is where the system s computer code through which transactions enter and exit the system and its business applications exist. This doorway contains the logic and rules to identify each specific type of transaction, screens out duplicates or incomplete transactions, applies the appropriate data validations, rejects invalid transactions, maintains a transaction log/archive, transforms the incoming MILS to the internal native system messaging format and/or parses data to the database, and determines where within the system valid transactions should be processed. Making the System Bilingual. For a system that has been designed to recognize and process incoming MILS transactions, this front door is where the initial work of transforming a system to be DLMS compliant starts Phase 1. Remember this system already accepts and processes transactions in the MILS format. The goal of Phase 1 is to incrementally make the system bilingual, so it can process either a MILS or a DLMS transaction. In Phase 1, there are no internal messages and no new data elements are added to the databases. Black arrows depict data information flows within the system among the applications and the database(s). Limiting Phase 1 to only change the incoming and outgong message forms from MILS to DLMS speeds implementation due to simplified testing and lowers risks since the system continues to only accommodate the MILS transaction data no DLMS enhanced data. Page 57

66 Appendix 7 Completing Front Door DLMS Migration. The front door code needs to be broadened, adding code that recognizes the incoming DLMS transaction by type, applies appropriate edits, rejects bad DLMS transactions, parses and transforms the data content of the incoming DLMS into the system native message format and/or populates the database. Likewise on the outbound side, new code must be added to construct DLMS transaction formats, once again making the system bilingual for outbound transactions. At the end of the migration, when all MILS inbound and outbound transactions have successfully been converted to the DLMS and the system is exclusively receiving and sending only DLMS, the front door can be purged of the legacy MILS code such that the system is no longer bilingual but communicates exclusively in DLMS. Figure Appendix 7-1 Typical Business System Construct Standard Base Supply System Migration to DLMS. While Appendix Figure 7.1 is a generic depiction of a system construct, Appendix Figure 7.2 (provided by the Air Force) depicts the construct used to modernize their Standard Base Supply System (SBSS). The SBSS was initially developed in the 1960 s to provide basic inventory ordering, storing and issuing capabilities, and has been continuously improved over the years to provide a full range of inventory management capabilities. Although robust and comprehensive in terms of inventory management capabilities, the SBSS has no world view and was constrained by MILS transaction data content. That is, each Air Force base operates against a local database. The Enterprise Solution Supply (ES-S) component was developed to supplement the SBSS in a way that enables the required enterprise management capabilities. Together, the SBSS and ES-S components comprise the Integrated Logistics System Supply (ILS-S) application. The ES-S portion of ILS-S serves as the front door to SBSS and is where the work of migrating from the MILS to the DLMS was performed. Page 58

67 Appendix 7 Construct of SBSS Legacy System Modernization. As illustrated below in Appendix Figure 7.2 the SBSS and ES-S components of ILS-S work together via integrated user views to provide a full suite of enterprise inventory management functionality. The ES-S component is a Service Oriented Architecture (SOA) that enables communication and work sharing between data systems. The ES-S SOA implementation provides a number of important services. First, ES-S provides enterprise logistics managers with the ability to view and execute inventory management transactions across all the SBSS local databases. Secondly, the ES-S component enables the easy acquisition and presentation of wholesale asset and order status data, as well as asset movement information from external Air Force and DoD logistics systems. Finally, ES-S provides a modern platform for the development and implementation of additional enterprise logistics management capabilities beyond those provided via the SBSS component. While this Appendix deals with establishing the initial DLMS Phase I baseline capability, this architecture readily lends itself to and has allowed the Air Force to implement applicable DLMS enhancements beyond the Phase I DLMS baseline. The incorporation of DLMS enhancements DLMS Phase II is discussed in Appendix 9. Figure Appendix 7-2 Construct of the SBSS Legacy System Modernization Defense Automated Addressing Wholesale Leveling Wholesale Requireme Base Maintenanc Cargo Mgt Operations ~ 60 other Wholesale and Retail ILS-S Global Transportat Integrated Data Enterprise Data Stock Control ( Page 59

68 [This Page Left Intentionally Blank] Page 60

69 Appendix 8 Appendix 8 - Detailed Discussion of DLMS Migration Step 8 Start with one transaction. Initially the number of transactions that need to be migrated from the MILS to the DLMS appears to be daunting task, with well over 500 separate MILS DICs. However, most systems will only have a need for a portion of the transactions, and there is a high degree of commonality among large numbers of DICs allowing for a significant level of code reusability after an initial DIC migration to DLMS has been accomplished for one transaction member of a MILS transaction family. MILS DIC Relationship to DLMS Transactions. Figure 9 depicts a DLMS Receipt transaction (a DLMS 527R) in the left column and in the right column are all the MILS DICs that report receipts and are replaced by the DLMS 527R. The color coding of the 33 MILS DIC column depits the five families of MILS reciepts (D4_, D6_, DR_, DX_ and the DZK). All six of the D4_ are Materiel Receipts from a Procurement Source and all have the same data format. All nineteen of the D6_ are receipts and share a common format data set as well; however, they report receipts from an non-procurement source. The MILS formats can be found in the Word documents in the far right hand column at the link: by scrolling down to the 527R. This commonality of formats within a family grouping means that after developing the coding in the front door application to read an incoming or format an outgoing D6A into the DLMS message format the same code is reusable for the other eighteen D6_. So while on the surface there appears to be a requirement to code for 33 different receipts, in reality there are only five. Figure Appendix 8-1 DLMS 527R Receipt & Equivalent MILS DICs & Family Groups Acquire DAAS Maps. When the program office decides on the order of MILS transaction migration, acquire the current copy of that transaction s DAAS Map from DLA Transaction Services. If for example the D6A is the first MILS DIC that will be migrated, this is the time to acquire the 527R DAAS Map. Page 61

70 Appendix 8 Utilize Loop-Back Testing. Utilize Loop-Back Test with DLA Transaction Services to test each transaction. Loop-Back testing is a technique to verify that the new front door DLMS code is correct. The technique consists of sending DLA Transaction Services a MILS transaction. DLA Transaction Services will run the MILS transaction through routing and send the transaction to the translator to be delivered in the DLMS format. The program office can then compare the returned DLMS transaction that the bilingual front door generated or received prior to developing the new DLMS code. If the transaction returned from DLA Transaction Services matches exactly, then the new code is correct. If not, the data element differences will need to be researched, the code modified to resolve the issue and the transaction will have to undergo another loop-back test. It s recommended that every three character legacy DIC be loop-back tested as the DLMS notes in the DLMS implementation conventions may differ based on DIC. Page 62

71 Appendix 9 Appendix 9 - Detailed Discussion of DLMS Migration Step 9 Implement a MILS/DLMS Switching Table. The approach is to initially allow the system to become bilingual and communicate in either the legacy MILS transaction format or in the DLMS format. For the exchange of DLMS transactions, DLA Transaction Services and the customer must establish a new interface. DLMS transactions will be processed by a different DAAS entry point from that used as the entry for MILS transactions. The purpose of the switching table is to provide a mechanism that allows a controlled, flexible, phased migration that significantly reduces program management and technical risks. Account for both Inbound and Outbound transactions. In actuality there are two switching tables for the system migrating from the MILS to the DLMS; an inbound to the system switching table and an outbound from the system switching table. The values in the switching tables are controlled by the systems program office. The switching table identifies every MILS DIC used by the system to the three character level, as per the examples given in Appendix 8 D6A, D6B, etc.). The first column of the switching table contains a table row for each MILS DIC and the equivalent DLMS transaction in the second column of the table. The number of the remaining columns is dependent upon whether or not the system has multiple deployment sites and whether or not the deployment will occur at all sites simultaneously or will be phased in at the various sites. If there is only one instance of the system or if deployment across sites will be simultaneous then there are only three columns to the switching table one that identifies the DIC, a second identifying the equivalent DLMS transaction and a third that contains either an M for MILS or D DLMS. The M or D tracks at the DIC level which format is being used. If there are multiple instances of the system and the deployment rollout is to be phased across them, than each deployment location instance should have a column in the table and that column will have either an M value of a D value. One system with both transaction types supported. As the migration effort front door code for a MILS DIC is developed and tested to read or write that business transaction in DLMS the program office will decide when they want to transition from an M to a D for each transaction inbound to the system and each outbound transaction. While the system for that MILS DIC is now bilingual, the table determines which of the two will actually be activated in the production environment. Remember there is the ability to control down to the three characters DIC and system instance level. The goal at the end of the migration is to have all the DICs that the system sends and receives identified as D s, that is, reading and writing DLMS at its front door. Constant communication and coordination is required between the system program migration office and the DLA Transaction Services as the table changes are enacted. The advantages of this approach are that small increments can be coded, tested and deployed at the pace the program office desires. Page 63

72 Appendix 9 Activating DLMS. Presumably the new code has been thoroughly tested prior to activating it for a transaction; however, another advantage of the table is that by closely coordinating with DLA Transaction Services, change of a DIC from M to D can be made for a specified period of time, monitor the traffic, and if code problems (failures of transactions) are detected, the switch can be reset back to M while the new code issues are resolved. This has proven very valuable and allows the current copy of the software to stay online. When all the transactions the system uses have been migrated to the DLMS both the switching table and the dead MILS front door processing code can be removed and the system becomes totally DLMS conversant and no longer has a requirement to be bilingual. Figure Appendix 9-1 Switching Table Illustration used by DSS Page 64

73 Appendix 9 Switching Table Illustration used to Migrate SBSS. Figure 10 is another example of a switching table that was used by the Air Force to migrate the front door of their Single Base Supply System (SBSS) to the DLMS as discussed in Appendix 7. While the format is different the concept is the same. In this case the target DLMS transaction type is to the left of the screen and the corresponding MILS DICs are identified to the right with check marks indicating that the particular MILS DIC is now turned off and the business event recorded by that transaction is now processing using the equivalent DLMS transaction. Figure Appendix 9-2 Switching Table Illustration used by SBSS Page 65

74 Appendix 9 Additional Management Controls. There are many controls that the program office will want to put in place during the migration, some of which will continue on after the migration effort is complete and remain for the life of the system. The following screen shot is an example of a control table that the Air Force maintains as a result of their SBSS front door migration to the DLMS. SBSS migrated from the MILS to the DLMS XML messaging form. The system maintainers use the first tool (below screen shot) Figure 10 to keep track of the current XML Schema (XSD) in use by SBSS. For a system that migrated to the DLMS X12 EDI form this control mechanism would keep track of the current DLMS X12 EDI IC Supplement release control number. Both the DLMS XML XSD files and the DLMS X12 EDI IC supplements are constantly changing; however, as stated previously, DLA Transactions Services maintains a system profile that includes the specific XSD or IC supplements version in use by that particular system by DLMS transaction type and DLA Transaction Services will not change versions for that system unless directed to do so by the system program manager. Figure Appendix 9-3 Table to Configuration Manage XSDs used by SBSS Page 66

75 Appendix 10 Appendix 10 - Detailed Discussion of DLMS Migration Step 10 Supporting Enhanced DLMS Capability. As a result of completing Phase I of the legacy system migration to DLMS, only a basic capability to read and write DLMS transactions using prior MILS transaction data content and business capabilities was achieved. In this phase, the system s code, internal messages, databases, output screens and reports, etc. will modified to capitalize on the new data and functional business capabilities that are available for a DLMS based system that were not possible within a MILS based system. As discussed in Appendix 7, the graphic below depicts a typical business system construct. As before, the pink area in the center of the graphic depicts the systems database (which may be singular or not) where current information is stored and retrieved within the system. The yellow blocks surrounding the database depict functional business applications within the system that perform specific functions, interact with the database and may pass data between the individual applications in an internal system native messaging format. While four applications are depicted in the graphic, a large system may have hundreds of sub-process applications. Adding Enhanced DLMS Capabilities. The major difference is in Phase II is that code will need to be developed at the front door and code will have to be developed within and between the core applications. The front door application code will need to be modified to recognize, edit and distribute new data content that was not in the original incoming MILS transaction nor was the new data accommodated during Phase I of the migration. Likewise, the front door application will require modification to any outgoing DLMS transactions to accommodate data content that was not in the previous equivalent MILS transaction or the Phase I baseline migration. Prioritize & Schedule DLMS Enhanced Capabilities. Unlike Phase 1, in Phase II the system will need code changes to use new data and associated business rules preform new or enhanced business functionality using the data and business rules that were previously identified in one or more DLMS ADCs. Doing so will almost certainly necessitate changes to include the new data in internal messages (the dashed orange arrows depicting data information flows within the system among the applications and the database(s), new data added to the database(s), additional business rules and changes to output reports/screens and likely outgoing transactions. The functional members of the migration team will need to examine the ADCs that are applicable to the business processes the system performs and determine the priorities for their implementation and schedule them into system releases. Not all ADCs are applicable to every system and not all ADCs that are applicable are equal in benefit to the business processes the system performs. In addition to weighing Component value of improved processes, the program management staff will need to consider OSD policy mandates, such as changes to improve property accountability, applies better controls over Government Finished Property, and others when prioritizing and scheduling those DLMS enhanced capabilities to be added to the system. Page 67

76 Appendix 10 Concurrent Phase I and Phase II Work. It should be noted that all transactions don t have to complete Phase I prior to initiating Phase II activities. For example, if all the MILS DICs for receiving (527R) have completed Phase I and have been released into production, Phase II enhanced capabilities can begin for the receiving process implementing new data/capabilities such as the capturing and use of the Unique Item Identifier (UII) while simultaneously beginning to migrate another set of MILS DICs to the basic capability of the DLMS under Phase I migration. Again Phase I addresses, from an IRB compliance stand point, the ability to assert to BASIC DLMS COMPLIANCE, while Phase II activities set the system on the road to incorporating enhanced DLMS data/capabilities and attaining FULL DLMS COMPLIANCE. Figure Appendix 10.1 Migration to DLMS Page 68