Your SlideShare is downloading. ×
AIP - 08 - Joint Distribution
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

AIP - 08 - Joint Distribution


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • I am Pat Kielbasa I am here to present the status of USTRANSCOM’s Class V DISTRIBUTION architecture development efforts This is an information brief only
  • I am going to deviate from the briefing sequence provided for this working group. Here is the sequence of topics I will cover. The J6-A, with assistance from Class V SMEs, Service representatives and JMC, developed a Class V distribution architecture for both the As-Is and To-Be distribution processes for Class V. The results include the mapping of E2E distribution activities and information exchanges. All of the information is captured in a queriable Class V data repository at USTRANSCOM. This briefing will introduce the process that was used to build the architecture, and touch on the results. I will briefly mention the efforts of the technical group analyzing the IT gaps defined by the CBAT and some of their high-level IT recommendations for Class V system capability. We believe the answer to the last bullet is significant.
  • There is a difference between AIP Task 8 in the AA&E Implementation Plan task (top bullet) and the Class V distribution architecture tasks (the bottom two bullets) Please take a moment to read these statements. I think you can agree that a significant difference exists in the two tasks. However, there is a belief that Class V distribution architecture results can contribute significantly to the goals of AIP 8
  • This slide follows the standard format and is likely to get me into trouble This key participant list and roles associated with the list is presented from the perspective of the distribution process owner. I’d like to continue with the briefing by describing the process used to create the Class V architecture as it exists today. I’d like to begin with the Supply-Chain Operations Reference-Model
  • Could I see a show of hands of those people who are familiar with the Supply- Chain Operations Reference-Model (SCOR)? We used SCOR because distribution is significant in the overall supply chain and directions contained in DOD 4140.1R SCOR is more of a framework that provides a common understanding across business entities inside a supply chain. The SCOR model has three levels (which we will discuss next) so it is relatively easy to understand. It can be difficult to interpret, however, without applying some supply-chain background and experience. The SCOR model (or SCOR) was used as the basis for developing the Class V architecture This isn’t exactly true- TELLTHE STORY The SCOR model helped USTRANSCOM architecture developers think beyond the confines of its familiar transportation paradigm that existed in USTRANSCOM before it was tasked to become the DPO.
  • This is a depiction of the SCOR model. You have already seen the SCOR process Level 1 depiction on previous slide and it is repeated here. Level two displays the configuration or core processes of the business entity or company. The configuration allows them implement their operations strategy Level three decomposes the processes into elements For example: on this slide the elements of plan core process are P1.1 Identify, Prioritize and Aggregate Supply-Chain Requirements P1.2 Identify, Prioritize and Aggregate Supply-Chain Resources P1.3 Balance Production Resources with Supply-Chain Requirements P1.4 Establish and Communicate Supply-Chain Plans Level 4 companies implement specific Supply Chain management practices You will notice on this presentation that Level 4 is out of scope for SCOR. In the commercial world this is where companies define practices to achieve competitive advantage and adapt to changing business conditions.
  • Shown here are some of the reasons that SCOR was used to develop the Joint Distribution Architecture It provided a framework for creating a Joint Distribution Architecture and the architecture for Class V and allowed architects to maintain a linkage between SCOR, and the JDA and Class V architectures. Shown here is a SCOR Model level three process element of the core process of Deliver that will be used to illustrate how SCOR decomposition was used to reach level 4 and level 5 JDA and Class V activities.
  • Distribution and Class V architectures were created by decomposing the SCOR model level 3 activities. Walk through the decomposition.
  • This chart illustrates the relationship and linkage between SCOR and the JDA, and more specifically Class V at a SCOR equivalent level 3 First it shows only those SCOR process elements associated with the DPO. The distribution process does not cover all of the processes defined by the supply chain model, for example manufacturing Next it defines the functions within the scope of the distribution process owner, for example distribution sites, and what activities that function performs across the distribution chain This is not a strict interpretation of SCOR as a functional swimlane was added to better describe the financial activities of the distribution process The yellow boxes are those process elements of the distribution process that are linked to the Class V distribution chain The next chart I am going to show does two things, it shows a decomposition of the level three process elements to level 4 activities and only shows those minimum activities required to complete the process. What we call the prime thread.
  • This presentation is looks different from the previous slide because it is decomposed down on level, to level 4 and only contains Class V Prime Thread activities for stocked items only. The activities on this map start in the upper Left Corner with the customer generating a net demand and end with an invoice and the collection and disbursing of funds on the lower right. Again these activities are the minimum activities needed to complete the distribution of stocked Class V materials. This depiction represents work-in-progress. In a minute I am going to show the entire set of To-Be activities associated with Class V, but it is important to understand when we say that we have a distribution architecture for Class V, and what that really means.
  • So far we have talked about SCOR and the decomposition of SCOR level 3 activities and how that was used to create JDA level 4 and Class V level 4 activities through decomposition. In some cases this decomposition was completed down to level five (a decomposition of Level 4 activities). This slide attempts to and relate decoposition to an activity and information exchange level. Its purpose is to demonstrate the level of granularity that we have achieved in describing architecture data for Class V and that this architecture describes in detail what is happening within the Class V activities and between Class V activities across the distribution chain. EXPLANATION of items on the slide In the To-Be architecture for Class V there are 385 unique activities, 209 unique products (information exchanges) that create the over 1300 information exchange requirements (IERs) that occur in the distribution process. Now I want you to get your 3-D glasses out because I am about to show a picture of the entire set of Class V To-Be activities and IERs that make up the distribution process as described by the SMEs and captured in the data repository.
  • This is not only a picture it results from data stored in the repository and an application NetViz. The point is that Class V architecture data can be analyzed as as data or depicted as a picture by activity, groups of activities, function, SCOR phase, etc. Did any one see Wonder Woman and her magic Rope?
  • Visibility – JTAV and ITV are key issues identified by the CBAT as necessary functionality for future Class V systems. For example: a web-enabled, single log-in that would allow access to munitions management and transportation decisions worldwide Collaboration – The ability to collaborate via voice and data during planning and execution between site managers, distribution managers, shippers, etc. These actions should be conducted in a shared environment
  • No system currently exists to convert a ULN into a requisition or movement at the point of execution Requires the transition of a classified ULN to an unclassified document
  • The CBAT team identified 41 systems that supported Class V distribution That Number was reduced to 24 for example because they were legacy The technical analysis team analyzed system capabilities to determine which systems filled the gaps identified by the CBAT. The analysis showed that many of the desired capabilities to fill the gaps already exist in current systems Technical team will develop recommended alternatives for meeting desired capabilities for Class V distribution
  • This matrix shows the relationship between systems and system functionality identified by the CBAT. This is an preliminary effort that needs to be defined further into an SV-5, the Operational Activity to Systems Function Traceability matrix.
  • This is a representation of a potential systems architecture that incorporates the functionality of current systems and shows how the flow of data to existing systems and a future system, IF DEVELOPED, could meet the gaps, the yellow starbursts, identified by the CBAT.
  • This slide shows a sequence of envisioned planning steps associated with a way ahead for developing future IT architecture for Class V distribution. As you can see, the first step has not been completed, so this is a preliminary and draft depiction that is likely to change.
  • Transcript

    • 1. AIP 8 Update Joint Distribution & Class V Architectures January 25, 2005 Mr. Pat Kielbasa USTRANSCOM J6-A [email_address]
    • 2. Overview
      • AA&E Distribution Task and Participants
      • Supply-Chain Operations Reference-Model (SCOR) and the Joint Distribution Architecture (JDA)
      • Future Architecture Development
      • Capabilities-Based Assessment Team (CBAT) IT Focus Areas
      • Class V Automated Information Systems (AIS)
      • Class V IT Architecture – Proposal
      • How do USTRANSCOM Architecture efforts fit into the goals of the AA&E Implementation Plan?
    • 3. Tasks – AA&E / Distribution
      • Transform DoD’s AA&E management, business processes and technology investments from an individual segment view to an end-to-end logistics chain view.
      • Develop a Class V distribution architecture that complies with the DOD Business Enterprise Architecture and DODAF.
      • Use the architecture to expedite steps to identify Class V system functionality improvements applied to the ultimate Class V AIS distribution solution.
    • 4. Key Participants
        • OSD (AT&L) - facilitate Service, COCOM and DLA staff participation during Class V enterprise architecture development.
        • USTRANSCOM - lead Class V distribution enterprise architecture development efforts as the DPO. Identify distribution system functionality for AA&E within the context of distribution portfolio management and the BEA Log
        • The Military Services - assist in building Class V distribution enterprise architecture and defining current and future-state Class V system functionality.
        • DLA – review Class V architecture for consistency with BEA Log architecture
        • The Joint Munitions Command (JMC) – lead definition and validation of Class V architecture and enabling system functionality as the DoD Single Manager for Conventional Munitions.
    • 5. Supply Chain Operations Reference – model (SCOR)
      • DOD 4140.1R, Supply Chain Material Management Regulation
        • C1.4.1.1. The DoD Components shall use the supply chain operational reference processes of Plan, Source, Maintain/Make, Deliver, and Return as a framework for developing, improving, and conducting materiel management activities to satisfy customer support requirements developed collaboratively with the support providers
      Supply-Chain Operations Reference-Model (SCOR) Return Make Deliver Plan Return Source
    • 6. Level Description Schematic Comments Top Level (Process Types) Level 1 defines the scope and content for the Supply chain Operations Reference-model. Here basis of competition performance targets are set. Source Make Deliver Plan 1 # Configuration Level (Process Categories) A company’s supply chain can be “configured-to-order” at Level 2 from core “process categories.” Companies implement their operations strategy through the configuration they choose for their supply chain. 2 Process Element Level (Decompose Processes)
      • Level 3 defines a company’s ability to compete successfully in its chosen markets, and consists of:
      • Process element definitions
      • Process element information inputs, and outputs
      • Process performance metrics
      • Best practices, where applicable
      • System capabilities required to support best practices
      • Systems/tools
      • Companies “fine tune” their Operations Strategy at Level 3.
      3 P1.1 Identify, Prioritize, and Aggregate Supply-Chain Requirements P1.2 Identify, Assess, and Aggregate Supply-Chain Requirements P1.3 Balance Production Resources with Supply-Chain Requirements P1.4 Establish and Communicate Supply-Chain Plans Companies implement specific supply-chain management practices at this level. Level 4 defines practices to achieve competitive advantage and to adapt to changing business conditions. Implementation Level (Decompose Process Elements) 4 Not in Scope Supply-Chain Operations Reference-model SCOR Levels of Process Return Return
    • 7. JDA Decomposition Methodology
      • Use of SCOR Directed by DoD
      • Guides lower level development (what activities to consider)
      • Consistent levels of detail
      • Automatic linkage to SCOR through Baseline
      • Allows groupings of like activities of different architectures for comparison
      SCOR Level 3 Activity Example D1.10 Load vehicle, generate ship docs, verify credit, & ship product SCOR JDA Baseline Class of Supply
    • 8. SCOR Level 4 – JDA – Baseline Example SCOR Level 5 – ASP (Distribution Site) Example D1.10.7 Process shipment at intermediate/transit points D1.10.7.8 Schedule movements D1.10.7.7 Generate all shipping documentation and identification devices D1.10.7.6 Load Sea vans, commercial containers, And 463L pallets D1.10.7.5 Reconfigure shipments into destination and conveyance based loads D1.10.7.4 Provide temporary storage D1.10.7.3 Inspect shipment D1.10.7.2 Offload conveyance D1.10.7.1 Review/Inspect documentation D1.10.7.9 Load conveyance D1.10 Load vehicle, generate ship docs & ship product D1.10.8 Move shipment to final delivery point D1.10.7 Process shipment at intermediate/transit points D1.10.6 Move shipment to intermediate/transit points D1.10.5 Schedule movements D1.10.4 Generate all shipping documentation and identification devices D1.10.3 Load Sea vans, commercial containers, 463L pallets and vehicles D1.10.2 Consolidate orders into destination and conveyance based loads D1.10.1 Inspect vehicle prior to loading D1.10.9 Provide Command and Control over movements in the DTS SCOR Level 4– ASP (Distribution Site) Example
    • 9. Distribution Architecture SCOR Level 3 to Class 5
    • 10. Prime Thread
    • 11. Relationship of Architecture Views and Data
      • To Be Architecture
      • 385 Activities
      • 209 Products
      • 1338 Relationships
    • 12. Class-V Interim “To-Be”
    • 13. Future Architecture Development Activities
      • JDA Level 4 – Potentially the right level for developing an operational architecture for the DPO
        • Class V activities decomposed to level 4 as a minimum
        • System development will require operational activity decomposition to Level 5 and below to enable operational activities
      • Continue associating systems with operational views for Class V
        • Relationship between the operational activities and system functions (SV-5)
    • 14. CBAT Recommended IT Improvement Focus
      • Key Functionality:
        • Visibility—you can only optimize what you can see
        • Collaboration—each Service capable in and of itself, but no shared environment
        • Automation—key data objects need to flow from planning to execution without reentry
    • 15. CBAT Defined Key Data Objects
      • Class V Architecture has to be able to support 4 key data formats with as much automated interface as possible:
        • Requisitions
        • Transportation Control Numbers (TCN)
        • Transportation Control and Movement Documents (TCMD)-to include ATCMDs
        • Unit Line Numbers (ULN)
    • 16.
      • Identified automated systems that support class V distribution
        • Original list of 41 narrowed to ~24
        • Reviewed 24 systems to ascertain what capabilities currently exist to fill gaps
        • Many of the capabilities desired by CBAT exist in current systems
    • 17. Class V System Functionality Matrix
    • 19. Possible Way Ahead For Class V IT Analysis Analysis of Alternatives Report Development 3 Nov – 31 Jan $ $ 1-28 Feb
      • ROM costs
      • Designation of Executive Agents
      • Recommended Approval Decision Brief
      • Integration of Functional and Technical Analysis results
      1 June – 31 July 1 Mar – 31 May 3 Alternatives
      • Detailed Tech Solution
      • Business Case development by module
      Sub- Portfolio Manager System Implementation approval Implementation / Spiral Development
    • 20. AIP 8 Takeaway
      • Completed Class V As-Is and To-Be Operational Architectures Using:
        • DPO context
        • SCOR Model v.6.1
        • DOD Architecture Framework
      • Examined Existing Class V Systems Capabilities:
        • Identified Key Data Objects
        • Developing system architecture alternatives