Overcoming barriers to force movement visibility: developing a unique DOD unit movement transportation tracking number.
--joint Pub 1: Joint Warfare of. the Armed Forces of the United States
LEARNING FROM INDUSTRY
The commercial distribution sector has had widespread success by adopting webbased, web-assigned tracking numbers. Their underlying motive is certainly the "bottom-line"' and to affect that "bottom-line," companies have sought to better serve their customer needs through the application of information technology. The assignment of unique life-cycle tracking numbers for customer visibility is a cornerstone strategy for corporate America. Today, nearly every successful enterprise uses some form of tracking number to manage their products and services.
Whether it is a mega-volume small package carrier such as FedEx, DHL, or UPS; a large retail chain such as Wal-Mart; an international ocean carrier such as APL, SeaLand, or Maersk; or even a fish and game wildlife environmentalist--everyone relies upon unique life-cycle tracking numbers to bold business information together as it passes through enterprise databases. They realize that by tightly integrating corporate data, they can provide quick, simple and understandable responses to any customer inquiry. In the end, satisfied customers breed more business opportunity, and more business opportunity breeds larger "bottom-lines."
In addition to the tangible customer benefits from this data integration strategy, there are internal corporate benefits as well. The strategy also allows these organizations to track critical corporate information across domain boundaries; eg, operations, finance, inventory/tracking, scheduling (planning), marketing, and resource management. Without a business focused integration strategy to share information, the business becomes fragmented, and critical business information becomes compartmentalized and eventually loses inherent value to the business as a whole. (1)
So, if this approach is being used so successfully by so many, why has the Department of Defense (DOD) not yet realized the value to be gained by the introduction of a unique tracking number for unit deployments? Over the past 20 years, the DOD's joint planning and execution community has continued to seek ways to compare actual execution detail with its associated planned movement. This has continually been identified as a major command and control goal--to accurately depict a "plan versus actual" view and make needed adjustments as real world events affect the plan. However, the fundamental pitfall of this goal has always been that the classified planning domain of Joint Operation Planning and Execution System (JOPES) and the unclassified execution domain of the Defense Transportation System (DTS) use significantly different data models with differing levels of detail. For that very reason, an accurate, detailed portrayal of "plan versus actual" has met with failure.
The United States Transportation Command (USTRANSCOM) and United States Joint Forces Command-sponsored Transportation Tracking Number (TTN) initiative finally addresses this issue.
EARLY EFFORTS TO TRACK UNIT MOVEMENTS
Subsequent to September 1 1, 2001, the high volume deployments supporting US operations in Afghanistan mandated better deployment data visibility. Early analysis revealed extensive variance in the accuracy and completeness of unit deployment data, and, over time, the reported operational picture of the unit deployment status was significantly distorted.
When viewing Unit Line Number (ULN) requirements in the JOPES, the corresponding scheduling and movement visibility was no better than 27 percent. When the same unit deployment data was researched in the Global Transportation Network (GTN) with the Unit Identification Code (UIC), 85 percent of the unit shipment data was visible.
Of significant interest was the magnitude of "key" data element errors across multiple systems and processes; eg, incorrectly constructed Transportation Control Numbers (TCNs), missing and/or incorrect Unit Line Numbers (ULNs). This early look into deployment data uncovered significant data breakdowns that regularly occur in the execution-planning cycle and provided fertile areas for attacking unit move visibility problems in order to develop a long-term solution.
Overall the study revealed that systems work as designed when provided all critical data at the beginning of the process. However, it also revealed that the lack of process discipline and continuous human intervention with the data created significant voids in the ability to maintain these critical data associations. New tools, new procedures, and a greater emphasis on data quality will be needed in the future to affect a long-term solution.
In the deployment planning and execution domains there are crucial pieces of information represented by data elements that must be understood. During contingencies, initial movement requirements are defined in an aggregated fashion in JOPES while the actual shipment detail during movement of these requirements is recorded in DTS systems.
To get a "planned versus actual" perspective, critical pieces of information from the plan and execution space must be held together from the very beginning of movement planning through closure at the end of movement. It is only by maintaining cross-domain linkages of these relationships that a user can ultimately understand the status of deployment and determine how real-world events are affecting that movement. The initial steps of our data analysis effort were to understand the realities of these critical data relationships during deployments to Afghanistan and Iraq.
To achieve quality in-transit visibility (ITV) for unit moves from the planned requirement through its execution and delivery, the relationship of these four critical data elements must be fully understood:
* OPLAN Identification (PID)
* Unit Line Number (ULN)
* Unit Identification Code (UIC)
* Transportation Control Number (TCN)
It is absolutely essential to hold these elements together in order to fully trace JOPES planned records with its DTS execution detail. Since the JOPES domain is limited to an aggregation of data in contrast to the DTS execution systems that contains item level detail, all critical data relationships must be maintained throughout the entire deployment planning and movement life cycle as the data passes from system to system.
Remembering that the planning data in JOPES differs significantly from the movement data in the DTS systems, these DTS systems must eventually roll the details up into aggregated data sets for JOPES. Once this aggregated data is in JOPES, the details of the deployment can no longer be understood,
The process can be likened to melting ten pennies into a copper mass. Once accomplished, one can no longer read details that were stamped on the coins; all independent detail is lost in the aggregation process. Additionally, if any critical data linkages for the cargo are lost, an accurate rollup is again impossible. With two disparate domains operating two independent databases any rollup picture is, at best, a very precarious one.
In spite of deployment doctrine and policy, data standardization, business rules and personnel training in deployment processes, this decentralized approach to manually generating critical data elements has opened the door for users to regularly introduce non-compliant and inconsistent data into deployment execution systems. Although the Defense Transportation Regulations (DTR) states that unit move TCNs must be unique, they are not, especially over relatively short timeframes and across OPLANs. Currently, there is no unique key created at the beginning of requirement identification process in JOPES that remains tightly associated with shipment data throughout the deployment process. Our current decentralized process is very cumbersome and labor intensive, such that enforcement of doctrine, policy, data standardization, and business rules is non-existent.
[FIGURE 1 OMITTED]
OPERATIONS ENDURING FREEDOM AND IRAQI FREEDOM
Deployment data quality was consistently monitored throughout the last five years of OEF/OIF. The first report, completed in October 2002, reflected that of the 123,730 unit move TCN shipment records, only 29 percent contained a ULN needed for possible return to JOPES. During the intervening period from October 2002 to January 2003, a software change was made to a DTS air manifesting system, improving the data quality to 46 percent. In February 2003, USTRANSCOM and the Army's Forces Command (FORSCOM) personnel reconfigured a data exchange between the COMPASS and GTN Systems to obtain a post-FORSCOM-edited data feed, vice the existing pre-edit feed, resulting in a significant improvement (61 percent) in Army data quality.
As far as real data quality is concerned, USTRANSCOM has begun to move from the art of guessing to the initial stages of applied scientific research to help identify and point to the resolution of data quality issues across the DTS. Even with these first steps, there is no real data quality visibility inside these segments of data. By January 2004, the level of data quality reached 77 percent, yet within a year that number had fallen to 65 percent and has remained representative.
OVERCOMING THE PROBLEM
To overcome the data integrity issues outlined above, USTRANSCOM, in partnership with JFCOM, has sponsored a FedEx-like tracking number concept for all DOD unit deployment cargo. This initiative is called the Transportation Tracking Number (TTN). The basic concept for the unit movement TTN has several critical characteristics that must be kept in focus. These characteristics are:
* each number is truly unique over a significant timeframe (upwards of ten years);
* each number is a data key that can cross classification boundary without comprising OPSEC;
* the number is assigned as early in the deployment planning process as possible; and
* this number remains associated with the shipment data in every system that processes and stores transportation data.
The TTN will ensure that all unit move requirements are reported back to JOPES for a fully-realized "plan versus actual" capability-based closure assessment.
TRANSPORTATION TRACKING NUMBER INITIATIVE
Fundamentally, the TTN concept has two parts. Account numbers are established in JOPES at the highest level and are subsequently used as a "seed" for creating individual tracking numbers for each shipment. At the outset of any new deployment requirement in JOPES, a system generated account number would be ascribed to each requirement. It would be based on an algorithm that represents a combination of JOPES PID and ULN data. It would not be a concatenation of these values, but would be a newly generated randomized customer TTN Account Number (TTAN).
Two key aspects of the number are: (1) it does not have innate intelligence in and of itself; and (2) it remains unique throughout its life-cycle to prevent reuse or duplication within the transportation domain.
The TTAN will be established sometime prior to, or during, the planning/sourcing process. This account number is established electronically in JOPES at the moment a requirement record (ULN) is created. As unit movement documentation is created, a sequential counter for each shipment is added to the TTAN to create a complete TTN. This TTN is collected in a service-owned deployment repository, as well as processed through all the other DTS systems and eventually collected in the TRANSCOM global ITV database. As the shipment is moved through the execution environment, the TTN serves as the "data key" for ensuring data reliability throughout the complete movement.
To gain visibility of actual movements, the TTNs are available on the unclassified systems for TTN Account Number queries. Additionally, at various points in the execution, the TTNs movement event updates would be reported to the C2 environment for the comprehensive planned versus actual assessments.
Within the Joint Staff's Operations Directorate (J3), its Command Systems Operations Division has taken the lead in having the Defense Information Systems Agency (DISA) engineer the TTN initiative and support services, thus setting the stage for the FY08 prototyping in preparation for future implementation. In this effort, DISA will be providing a range of Service Oriented Architecture (SOA) services and documentation for developers to use in their prototype and eventual implementation efforts. Figure 2 identifies a basic view of the systems and where various SOA services are envisioned.
[FIGURE 2 OMITTED]
REMOVING OLD BARRIERS
Since the TTN is designed for machine-to-machine data exchange, there is no human user involved in its creation, exchange, or processing; it remains guaranteed unique and traceable and unalterable. The TTAN provides JOPES the single unique data key that can be used to hold the entire life cycle of planning and execution data together.
Because there is no embedded intelligence in the creation of the basic TTAN in JOPES, it is not restricted from the classified-to-unclassified data flow ... thus removing the requirement for: (1) establishing an alias for the PID to be used on unclassified systems; and (2) maintaining the classified PID to unclassified "PID-alias" cross-reference table. Through the TTAN, the PID-ULN relationship can be freely exchanged across the classified boundary without violating operational security. The unalterable and unintelligent TTN removes any motivation for customer changes that traditionally destroy embedded intelligence in current TCN, such as changing sustainment TCNs into unit move TCNs to avoid HAZMAT restrictions or to avoid billing by moving on contingency missions.
Finally, the TTN removes the dependency on process enforcement for any success in achieving improved unit move data quality.
NEW CAPABILITIES ENABLED BY TTN
In the simplest terms, the TTN resolves many long-standing issues with deployment data quality, while at the same time fulfilling critical command and control objectives. Because the TTN initiative provides the linkages across JOPES and the unclassified transportation systems, it offers the opportunity to assemble an accurate "plan versus actual" picture at the item-level of detail. The essence of the "plan versus actual" picture is that it provides a true relationship of the plan requirements and all the detail about unit movements. The TTN enhances command and control of deployment from origin to destination, affording commanders better insight for posturing support, coordinating delivery, and conducting capability assessments.
The orchestration of this detail data enables the combatant commander and staff to better understand force capability and the synchronization and integration of that capability before, during, and after deployment of their forces. Strategic and theater replanning is empowered by the availability of accurate deployment planning and execution data that provides any aggregation needed by strategic, operational, and tactical stakeholders; eg, ULNs, UICs, Force Tracking Numbers (FTN), or even type equipment and the related capability. Significantly, the TTN allows unit equipment to be moved on any plane or ship without the loss of ITV, and more importantly, its OPLAN relationship. It is this final point that opens the potential to transform the financial process for billing and paying for lift. The TTN offers the opportunity to transform the world of deployment data.
In addition to the MITRE team mentioned above, the following agencies have made significant positive contributions to the advancement of the TTN initiative: Joint Staff J3-CSOD, DISA PEO-C2C, CENTCOM AJ3, TRANSCOM J5/4, and JFCOM J9 JDPO.
David Vail is a senior civilian in the Operations Integration Division, Operations & Plans Directorate, United States Transportation Command, Scott AFB, IL, overseeing the design and development of the Transportation Tracking Number (TTN) initiative. Significant contributions to the TTN effort and this article have been provided by Randall Heim, Jim Donovan, and Tom Black of MITRE.
By David A. Vail, CIV, USTRANSCOM (TCJ3-IR)
|Printer friendly Cite/link Email Feedback|
|Author:||Vail, David A.|
|Publication:||Defense Transportation Journal|
|Date:||Jun 1, 2008|
|Previous Article:||2008 SDDC Symposium NDTA expo Mccollister's photo album April 29-30, 2008, Orlando, FL.|