Dynamic Change Awareness (DCA) Final Project WorkshopNSRP Joint Panel MeetingOctober 25, 2016

John Walks, P.E., Greg Carithers, P.E. and Patrick David

2

2

Ingalls Overview

• Building four classes of ships simultaneously—ten ships now in production

• Seven Arleigh Burke-class destroyers in firm business

• Builder of record for LPD and LHA classes of amphibious assault ships

• Builder of largest multi-mission National Security Cutter for the U.S. Coast Guard

DDG 51 Surface CombatantsLPD 17 Class Amphibious Transport USCG National Security CutterLHA 6 Amphibious Assault Ship

3

Agenda

• Background of Dynamic Change Awareness

• Major Project Deliverables– Requirements Development– As-Is Process Development– To-Be Process Development– System Architecture

• Technology Transfer

• Project Benefits

4

4

Issue Description

Lack of real-time visibility and knowledge of forthcoming changes to design or planned work drives…

…increases in engineering labor, planning labor, and generates re-work for production.

5

Project Mission Statement

To create a methodology for transitioning larger and smaller shipyards from their current change implementation processes into new streamlined processes in order to reduce cycle time, rework, and waste.

Dynamic Change Awareness Agreement TIA No. 2015-405, Scope (page 27)

6

6

Project Objective

Dynamic Change Awareness is the ability for the entire value stream to have real-time visibility of the evolving design, planning, material and production baseline changes to enable intelligent management decisions that lowers program costs.

Kevin Jarvis – Ingalls Director

Model/Drawings

Requirements

Bill of Materials

Plan/ScheduleQualityCDRLs/SDRLs

ChangeManagement (CM) Process

7

Project Vision

7

ContractsRequirements

Plan/ ScheduleTest

CDRLS/SDRLS Bill of Materials

Quality

Model/ Drawings

8

Project Goals

• The problem: legacy methods for processing of changes increase the cost of change

• The project goals are to:– Review the current requirements for the process for transmittal of change data and

document the “as-is” process for all team member shipyards (Done!)– Develop a “to-be” process for all team member shipyards– Create a new process architecture for delivery of data regarding approved changes

from Engineering to the workforce and waterfront field changes and production details back to Engineering for incorporation into the As-Delivered design artifacts and 3D model.

9

Team Members

• Ingalls Shipbuilding – Project Lead– Greg Carithers, John Walks, Ray Campion, Steven Frees, Aaron Holland, Hal Todd, Kay

Jamison, April Martin, Will Janca, Mike Deutsch, Jamie Breakfield, Bill Baumhauer, Virgel Smith, Dale Humphrey

• Bollinger– Dennis Fanguy, Katie Dufrene

• Austal– Barbara Turrens, Elizar Chaney, Emily Skewes, John Lawrence

• SSI– Patrick Roberts, Patrick David, Darren Guillory, Ken Sanderson, Denis Morais, Bruno Franca,

Chris Emerson

• ATI– Frances Pearce, Project Manager

• Newport News– Mark Debbink, Program Technical Representative

10

Milestone Schedule – Phase I

Milestone Title Due Date1 Project Management Plan 9/18/20142 Kickoff Meeting Minutes 9/30/20143 Quarterly Report 12/18/20144 Quarterly Technical Review Minutes 1/13/20155 Requirements Report 3/20/20156 Quarterly Report 3/20/20157 Quarterly Technical Review Minutes 4/15/20158 Quarterly Report 6/20/20159 Quarterly Technical Review Minutes 7/15/201510 Shipyard Specific As-Is Process Models 9/20/2015

11

Milestone Schedule – Phase II

Milestone Title Due Date11 Quarterly Report 9/20/201512 Phase II Kickoff Meeting Minutes 9/30/201513 Quarterly Report 12/18/201514 Quarterly Technical Review Minutes 1/13/201615 To-Be Process Model 3/4/201616 Quarterly Report 3/20/201617 Quarterly Technical Review Minutes 4/15/201618 System Architecture Report 6/10/201619 Quarterly Report 6/20/201620 Quarterly Technical Review Minutes 7/15/201621 Final Project Report 10/25/201622 Final Project Workshop 10/31/2016

12

Team Member Roles

Ingalls Bollinger Austal SSIProject Initiation Lead Support Support SupportRequirements Development Lead Support Support SupportAs-is Process Development Support Support Support LeadTo-be Process Development Lead Support Support SupportDevelop System Architecture Support Support Support LeadFinal Report/Workshop Lead Support Support SupportProject Management Lead Support Support Support

13

DCA NSRP Project Overview

13

Requirements Development

As-Is Process Development

To-Be Process Development

System Architecture Development

Develop Final Report & Final Workshop

CompletedProject Initiation

14

Requirements Development

14

ReqNum

Requirement Statement Included in Process

Ingalls Future System

Austal Future System

Bollinger Future System

1. The DCA architecture should provide 2D drawings and 3D model Configuration Management within a single system.

Yes PLM PLM Matri-X

1.1 • Ability to scope change impacts and tie changes to associated drawing objects. Yes PLM PLM Matri-X1.2 • Include workflows that identify the appropriate organizational levels to support

reviews and approval of changes.Yes PLM BizFlow/

PLMMatri-X

1.3 • Capability to create drawing change objects and associate them to specific version of drawing objects.

Yes PLM PLM SC

1.4 • “Real-time” status of changes, including change status tracking. Yes PLM PLM Matri-X1.5 • Automatically provide and update 2D drawings from 3D model within a single

system.Yes SC SC SC

2. The DCA architecture should provide full associations of Planning production schedules (i.e., work orders and work packages) within a single system and tied to the 3D model/2D drawings.

Yes PLM PLM BERT

3. The DCA architecture should provide Bill-of-Materials (all parts) storage with relationships linked to CAD Model within a single system.

Yes PLM PLM BERT

4. The DCA architecture should provide storage and relationships of drawing objects with TDP (Technical Data Packages).

Yes PLM PLM MATRI-X

5. The DCA architecture should provide Requirements Management coupled with the 3D model.

Yes PLM PLM CaseSpec

* Based on Model Based Enterprise

15

Requirements Development

15

ReqNum

Requirement Statement Included in Process

Ingalls Future System

Austal Future System

Bollinger Future System

6. The DCA architecture should provide “real time” metrics and dashboards within a single system for Engineering Design, Planning, Material and Construction, organizations at a minimum.

Yes PLM PLM ---

7. The DCA architecture should provide Quality information tied to ship construction. Yes PLM PLM BCS8. The DCA architecture should provide a bi-directional interface with the ERP system. Yes PLM PLM BERT9. The DCA architecture should provide the ability to uniquely identify objects. Yes PLM PLM BERT10. The DCA architecture should provide the capability to maintain information object

relationships throughout a ship’s lifecycle (i.e., Ship and Hull Effectivity).Yes PLM PLM MATRI-X

11. The DCA architecture should provide the capability to uniquely identify discrete information (objects) data sources of record.

Yes PLM PLM MATRI-X

12. The DCA architecture should provide the capability to store Supplementary Data (Notes, Parameters, Non geometric data) to all objects in a single system.

Yes PLM PLM SC/ MATRI-X

13. The DCA architecture should provide the native 3D model to be directly imported to the appropriate CAM system and the code will be controlled within the PLM system.

Yes PLM PLM SC

14. The DCA architecture should provide a process for sending all Product Manufacturing Information (PMI) to manufacturing data products associated to a model.

Yes PLM PLM SC

15. The DCA architecture should provide external PLM access to native 3D CAD model, 3D lightweight viewable and eBOM. Access to native models, Neutral models, and metadata decided by the type of relationship with external design authority.

Yes PLM PLM NavisWorks

* Based on Model Based Enterprise

16

As-Is Process Development

16

IDEF0 CM Process• Activity – Action / Verb, noted by the block with a capital

letter & number, where a shadow notes a decomposition level that form a group of sub-activities

• Input – Something needed to perform the Activity

• Control – Anything that provides guidance for that Activity

• Mechanism – What helps to move the Activity into a completion phase

• Output – The Product of the Activity

17

Process Documentation

• All Engineering, Planning and Supply Chain Change Management in a single Product Lifecycle Management tool

• All Change Management Processes are connected to each other

• All Products are in a PLM and have relationships

– Model, Drawings, CDRLs, Requirements, TPRSOW, etc.

18

To-Be Process Development

18

19

Develop System Architecture

20

System Architecture (IDEF1X)

ERP ORACLE

SC PLM

PLM

PLM PLM

PLM

PLM

PLMPLM

PLM PLM

PLM

ERP ORACLE

ERP ORACLE

PAINT SCHED PRN LISTDEC COV SCHED COMPART SCHED

O&F SCHED LABEL PLATEEQUIP. LISTS REQ. MGMT.

LIBRARY PARTS LEXICON

21

ShipConstructor Enhancements for PLM

22

Technology Transfer

• Business Processes Panel at the NSRP All Panel Meeting in Charleston, SC on March 12, 2015

• NSRP Day at NAVSEA in Washington, DC on August 19, 2015

• ShipTech 2016 in Charleston, SC on March 1, 2016

• NSRP Planning, Production Processes and Facilities Panel Meeting in Portland, OR on April 22, 2016

• Joint Panel Meeting in Biloxi, MS on May 12, 2016

• NSRP Day at NAVSEA in Washington, DC on September 23, 2016

• SSI Americas Users Conference, Mobile, AL, on September 27-29, 2016

• NSRP Joint Panel Meeting in Orlando, FL on October 25 and 26, 2016

23

23

Benefits

This project will provide the following benefits:

• Engineering: Improvement in change process

• Central Planning: Reduction in process steps

• Supply Chain: Reducing duplication of efforts and reducing the errors in material ordering

• Operations: Reduction in rework