Navy ERP Navy Enterprise Resource Planning Program Navy

Navy ERP Navy Enterprise Resource Planning Program (Navy ERP) Is The Department Of The Navy Financial System Of Record, Built On SAP, Providing Financial, Acquisition, And Supply Management Functionality To The Navy’s Major Commands, Which Provides Reliable Financial Information For Leadership To Keep Our Navy Moving Forward. DISTRIBUTION A. Approved for public release: Distribution unlimited (9 October 2019) Executive Overview and Lessons Learned 13 August, 2020 Shannon Seay Former – PMW 220 PM

Executive Summary The Navy Enterprise Resource Planning (ERP) "tech refresh" completed Aug. 19, 2019 10 months ahead of the projected completion date — the Navy’s largest system migration to the cloud. Nearly $70 billion flows into the U. S. economy annually through Navy ERP, which manages more than half the Navy’s finances. “The magnitude of this accomplishment is incredible, ” said Secretary of the Navy Richard V. Spencer. “The Navy ERP tech refresh is our largest system cloud migration to date and will enhance the performance of our force. Thomas Harker, Assistant Secretary of the Navy for Financial Management and Comptroller (ASN [FM&C]), stressed its significance to the simplification and modernization of the department’s financial reporting process. “The Navy ERP tech refresh is a major milestone toward consolidating all Department of the Navy financial systems into a single general ledger, which is essential to the department’s ability to produce accurate financial information, obtain a clean audit opinion and improve our data analytic capability. ” Navy Completes Its Largest Cloud Migration to Date, Story Number: NNS 190823 -10 Release Date: 8/23/2019 4: 23: 00 PM. https: //www. navy. mil/submit/display. asp? story_id=110670 2

Why Navy ERP Needed Tech Refresh? • To protect Navy’s investment – – Drive Sustainment Efficiencies Decommission Custom Code Archive Data to Eliminate Mass Volumes and Excessive Run Times Leverage SAP’s Innovations (Note: Mainstream maintenance for current suite of SAP products ends Dec 2025) • To address top Navy priorities – Auditability/Compliance/Cyber ØShift commodity responsibilities to provider and leverage cloud-based security capabilities for more effectiveness – Availability and Reliability – Extend the solution to other Commands – Improve User Experience, Performance, Ease of Use, Data Quality, and Data Accessibility • To position Navy ERP to achieve future operational improvements – – Real-time Decision Making and Analytics Movement to the Cloud Support Business Process Reengineering Ability to Establish a Single Financial Universe of Transactions 3

Technical Refresh and Cloud Migration Navy ERP become an entirely cloud-based system that leverages significantly faster in-memory data storage and processing. Current On-premise System Suite on HANA/ Cloud SAP Application Layer (Version 6. 0, SP 7) Code Inspector Customization Oracle Customization HANA *SWPM HW – Amazon HW – Solaris Export Import * SAP Software Provisioning Manager 4

Migration Challenges • We were under a backdrop of rapidly emerging Do. D and Navy cloud policies. • We had the need for partners including a Navy Cloud Broker (NAVAIR), NMCI to Cloud network transport (PMW 205), DISA for CAP capability, industry cloud service provider (AWS), and an expert contractor workforce SAP NS 2 and IBM. • Sustain the existing on premise environment simultaneously • Sheer size – on premises footprint of >700 servers and data storage footprint in the PBs. • Database migration sizes too large to push across the wire with the SAP enterprise core component pushing 32 TB alone. • Contractor workforce already resource constrained • Directive of maximum four day outage window • Not just a lift and shift to Cloud but a platform change to a new database (HANA) and operating system (Linux) • Schedule accelerated by 50% • RMF IATT (45 d vs 4 -6 m) and ATO (7 m vs 12 -18 m) timelines • Transport inefficiencies required rapid funding, engineering, and deployment of MPLS L 3 VPN’s from core sites (SDNI, NRFK, PAXR) to DISA BCAP. 5

Acquisition Lessons Learned CATEGORY Acquisition Lessons Learned • Establish stakeholder network, vision, and communicate • Engage your staff early; Contracts; Engineering, Cyber, Logistics, Service Providers – transition from sustainment mindset. • Aggressive contracting strategy from concept to award towards service providers with access to the OEM resources - 48 days from contract approval. • Acquired internally key government, direct support contractors and academics personnel in skill gap areas • Have contract management vehicles early for key middleware and technical emergency needs • Check, double check and challenge your build sheet. Your environment build sheet sized too small. 6

Operational Lessons Learned CATEGORY Lessons Learned • HANA "Fedramp" approved hardware may not have capacity for large production data systems. Data reduction and archiving efforts should be Operational defined and implemented well in advance of 'delivery' schedule for HANA transformation. • Controlled Unclassified Information (CUI) & PII data (IL rating relevant) requires a data cleansing strategy that does not affect functional testing of target systems in cloud, during RMF IATT until receiving full ATO. • Engage software vendors early. Not all licenses will convert to cloud/virtual licenses. Funding and lead time should be built into schedules for procurement and conversion. • Endian conversion (Sparc -> x 86) will add engineering complexities and reduce available tools for data transfer. Recommend converting beforehand. • web. Methods (middle ware) vendor engineering services were required to correct My web. Methods failures present in the cloud due to dissimilar operating and software versions. • Citrix custom code remediation required vendor engineering services to address Single Sign On (SSO) portal failures. • Onboarding and access provisioning for new personnel should occur before start of project, so individuals are ‘production’ ready on day one. 7

Data Extraction and Cutover Lessons Learned CATEGORY Lessons Learned Data Extraction • SAP Pre-conversion checks should be started well in advance of data export start. Large clustered and pooled tables (=>6 B rows) resulted in >100 day completion times • AWS Snowball device failure rates required an aggressive strategy for maintaining backup devices on-prem for quick replacement and evaluation of the Value Stream to find slack or poor process • Longer than expected copy times from source to snowball devices required parallel snowball connections to reach acceptable copy times • Splitting of large tables via Software Provisioning Manager (SWPM) greatly reduced export times from week/days to hours • All split tables require SAP SMIGR (system copy tool) reports to be collected at time of split to capture DDL (Data Definition Language) or import at target may fail to reconstruct tables Cutover • Initial AWS snowball only cutover strategy could not meet 4 day cutover requirement. • Some of your interfaces don’t have a test environments, what is your backup plan? • SAP Near Zero Downtime (NZDT) in conjunction with AWS snowball was required to meet 4 day cutover requirement. NZDT allows for initial data copy outside of cutover window. • Existing network bandwidth and availability limitations necessitated procurement of Multi-protocol label switching (MPLS; Layer 3 VPN). • Even after load testing we discovered key middleware devices were incorrectly sized. 8

Transport Lessons Learned CATEGORY Lessons Learned Transport • Early identification of network ingress/egress points, ports and protocols is needed to address boundary changes, IA approvals, and alternate transport methods. Printing, External Data Reporting, unique business processes need to be tracked at each level. • Existing network path to AWS Gov. Cloud found to be unacceptable to meet production bandwidth and availability requirements. • Network and client requirements on existing on-prem and Cloud environments need to be defined and measurable. • Congratulations you have gone live in the cloud, what is next? Your resource sponsor, users, team must all understand where you are in the roadmap, stabilization and tuning are still ahead. 9

Accomplishments • • • Received IATT in 45 days Refined AWS Snowball Mass Storage Device export process using parallelism to greatly reduce time to load and ship data Reduced cutover window from weeks to days with SAP Near Zero Down Time (NZDT) solution Overcame transport inefficiencies by funding engineering and deployment of MPLS L 3 VPN’s from core sites (SDNI, NRFK, PAXR) to DISA BCAP Received NAO endorsement of DISA BCAP as trusted NMCI boundary, allowing for DIACAP processing and continued engineering Development and funding of disbursed network testing to capture client experience metrics from as-is and to-be environments First in Navy to develop in dual AWS Gov. Cloud regions (AWS Gov. Cloud USEast/AWS Gov. Cloud US-West) for regional disaster recovery Leveraged AWS Gov. Cloud (US) to meet compliance standards for DOD sensitive data requirements Rapid execution of support services contracts to remediate coding and configuration issues found in multiple vendor products migrated to cloud Architecture and design of shared services leveraged at portfolio level Navy ERP became an entirely cloud-based system that leverages significantly faster in-memory data storage and processing. 10

Navy ERP Cloud Migration Success Factors • Most importantly, for PMW 220’s success can be contributed to the fact that we had leadership commitment across the enterprise • We sought out Gov/Ind experts in the technologies • We studied our Value Stream Analysis at every activity, we challenged not how we could transfer the risk externally, but what could we do better or faster to shorten our reviews and approvals • We established a drumbeat across the vast team. Everyone was committed to frequent, short daily meetings that enabled us to identify and elevate issues to highest levels quickly. 11

Navy ERP Migration to the Cloud - Current SAP Discovery Workshop - 2017 Infrastructure (Cloud) • Improve flexibility in infrastructure capacity • Faster adoption of newer technologies • Cost stability via Managed Services (Iaa. S, Paa. S) Platform • Faster computing speeds across large sets of data in memory column format of HANA platform • Large number of accelerated/ optimized transactions • Real-time reporting through SAP HANA Data Management • Data available immediately for real time processing, reporting and analytics • Significant reduction in database volume/ size with HANA transaction • Data quality and data governance with MDG Process Improvement & User Experience • Simplified Launchpad with role based entry • Self-service reporting and analysis in flexible & visually intuitive formats • Customizable screens to accelerate transactions 12

Questions 13