1. BECCM COI Meeting March 14, 2012 Dennis Wisnosky
DoD Business Mission Area Chief Technical Officer &
Chief Architect in the Office of the Deputy Chief Management Officer
Jack Ahuja
Director, Business Integration,
Office of the Deputy Chief Management Officer
For Official Use Only
Department of Defense

2. BECCM Mission Statement E2E Framework Enterprise Data Standards
Agenda
BECCM Mission Statement
E2E Framework
Enterprise Data Standards
One Voice
LOA Memo Update/Next Steps
Unit of Measure
HRM Ontology Overview
Open Action Items
For Official Use Only
Department of Defense

3. BECCM Mission Statement Strategic Outcomes
Address current operational DoD data challenges in order to enable cross-domain CBM interoperability at the Enterprise level
Ensure an enhanced DoD data strategy by leveraging current COTS investments and industry standards, enabling enterprise exchange data & Master Data Management, and supporting ERPs during system configuration by leveraging existing DoD Data Standards
Strategic Outcomes:
Coordination with ERPs and business system investment partners, including One Voice, Industry, IRBs, other forums in order to leverage COTS (FY10 NDAA BPR)
Improve BEA Content and data integration (information exchange) for Compliance
Improved Data Accuracy, reduced cycle times, referential integrity
Compliance with Federal and DoD Laws Policies and Regulations
Better Business Analytics for decision making
Reduced cost in integration, maintenance, testing, development, and customization/RICE work
For Official Use Only
Department of Defense

4. E2E Framework Randy Eckhardt
Business Integration / Investment Acquisition Management,
Office of the Deputy Chief Management Officer
For Official Use Only

5. Capabilities & E2Es in the BEA
Capabilities provide a complete view of the business required to support the mission for each functional area (aligned to the SMP to align capabilities to priorities) E2Es support the development of interoperable systems, through identification of process value chains that span the functional domains
Capabilities are defined by functional area and E2Es span functional areas. E2Es are not meant to represent an exhaustive list of BMA capabilities.
For Official Use Only
Department of Defense

6. E2Es and Capabilities in the BEA
Capabilities by Functional Domain
E2Es Spanning Functional Domains
Financial Management FM
Human Resources Management
HRM
Material Supply & Services Management
MSSM
Real Property & Installations Lifecycle Management
RPILM
Weapon System Lifecycle Management
WSLM
BEA Core Business Missions (CBMs)
For Official Use Only

7. About E2Es
Each E2E represents a set of integrated business functions that fulfill a need identified by the organization
E2E leverage common key data elements, which allow the organization to obtain a complete picture of E2E business event triggers (a.k.a. need) and all related business information anywhere in the E2E lifecycle
E2Es are primarily derived from mature business processes where COTS solutions are readily available in the marketplace
13 widely-used E2E’s in industry
2 unique to DOD – D2RR, our main function, and EL
E2Es are primarily transactional in nature – the full scope of both financial reporting and analytics, and master data management are not represented in E2Es
E2Es represent both industry and government leading practices for integrating common business processes across the enterprise
For Official Use Only

8. Proposed Definition: Complete Mapping Levels for Managing DoD Business
Management Framework
Cross Functional in nature
Aligned to Strategic Outcomes, not Ownership
Level 2
“What” – Defines the system-agnostic Enterprise DoD Activities
LRPs starts to Guide & Constrain- provides Implementable Business Rules that Define the Process Segment, E2E Business Processes
Enterprise Data Standards (Both Federal and DoD)
Standard Information Exchanges for interoperability
Level 3
“How” – SOPs
ERP Configuration Guides for specific roles
Business Process Reengineering (BPR)
Level 4
Systems – specific activities that are the business processes and blue print used by an organization in a given systems environment
Performance Measures
For Official Use Only

9. Solution Architecture Framework
Metrics
Strategic
Organizational
Program
System
Business Process
15 End-to-Ends
Business Applications
Transactional
Master Data
Business Intelligence
Technical Enablers
Services
Data Management
Infrastructure
Hardware
Software
Cloud
Information Assurance
Security
For Official Use Only

10. Enterprise Data Standards
Ray Bombac
Procure to Pay Co-Lead
Business Integration,
Office of the Deputy Chief Management Officer
For Official Use Only

11. Enterprise Data Standards
An Enterprise Data Standard is a information exchange or information standard that crosses Functional Component boundaries, is codified in DoD Policy with a Steward and Authoritative Data Source, and has established maturity at the Enterprise with appropriate Governance and Configuration Management with Federal Partners, Military Services, and DoD Components
Enterprise Data Standards contain the following:
Business Rules, Data Definitions, Source, LRP mapping, Primary Steward, Metadata- Values, Length, xml tag, etc.
Provides description and attributes of necessary meta data
“Maturity” can be defined as follows:
Coordination with ERPs and business system investment partners, including One Voice, Industry, IRBs, other forums in order to leverage COTS (FY10 NDAA BPR)
Has implementable business rules and validation Process
Impact of implementing the standard has been analyzed and documented
Governance Process is established including staffing of changes to DoD Components
Appropriate level of detail and integration in the BEA (AV-2, DIV-2, OV-3, OV-6a)
Compliance requirements are defined in LPRs, Manuals, other documentation
For Official Use Only

12. Definitions
Business Rule: a statement that defines or constrains some aspect of the mission, operation, business, or architecture. Statements that govern a business event, and are intended to assert business structure or to control or influence the behavior of business
System Business Rule: configuration or implementation data structure or operational rule required for interoperability - may specify syntax, storage, usage, relationships, and derivation
Data Element Name: standard business term as identified in LRP
Data Element Definition: detailed and unambiguous meaning that summarizes its purpose and use
Data Element Values: when applicable, the domain values as published by an Authoritative Source (can be a Manual or a System), and instructions for how to locate the values
Data Element Source: web URL that provides an link to the LRP and values
Primary Steward: each data element should specify which organization is responsible for its required use and maintains its standard values
Sources: DoDAF v2.0, RuleSpeak®
For Official Use Only

13. Enterprise Resource Planning (ERP) One Voice Effort
Mr. Jack Woolum - HQE
Business Integration Directorate
OSD - ODCMO
For Official Use Only

14. ERP One Voice Mission
Mission: To provide a platform for:
Vendor communication of development efforts aimed at addressing common DoD specific ERP requirements, support updates and releases of new products.
Facilitate program exchanges of common objectives, share lessons learned, and to support early adoption of leading practices and innovative technologies, and
Establish the venue to support the reuse of RICE objects.
Department of Defense
For Official Use Only

15. ERP One Voice Objectives
One Voice Objectives: Communicate and coordinate with US DoD components and agencies to:
Collaborate on vendor development efforts aimed at addressing common DoD specific ERP requirements,
Partner with other nations’ defense department representatives to maximize / leverage of ERP solution investments,
Explore commonality with Industry and other US Public Sector solution users to capitalize on leading practices,
Support the development of DoD Implementation Accelerators ongoing pilots and programs to enable early adoption and exchange of innovative technologies with vendors,
Facilitate Design Reviews & Pre-Release Testing to support design, development and testing of new capabilities with vendors, and
Consolidate software license requirements across all services to leverage DoD’s buying power.
Department of Defense
For Official Use Only

16. U.S. DoD ERP Program Summary
U.S. DoD ERP Programs are Large and Complex:
They can support most of the functionality available in Oracle and SAP Products,
The programs are in various stages of development … investigation, planning, development, implementation and operation:
Army AESIP (SAP) provides Master Data Management - Live
Army eNova (SAP) provides Material Supply and Services - Live
Army GCSS-A (SAP) provides Logistics - Limited Deployment / Development
Army GFEBS (SAP) provides Financial Management - Live
Army HQAES (SAP) provides Environmental, Health & Safety - Development
Army LMP (SAP) provides Wholesale Supply - Live
Army SDDC (Oracle) provides Finance and Logistics - Live
Army TEWLS (SAP) provides Medical Logistics - Limited Deployment / Development
DAI (Oracle) provides Finance and Logistics - Live
DLA EBS (SAP) provides Wholesale Supply and Financial Management - Live
DSCA SCES (Software TBD) - Currently in Source Selection
Marines GCSS-MC (Oracle) provides Financial Management, Purchasing, Mobile Field Services and Supply Chain Planning - Limited Deployment / Development
Navy NEMAIS (SAP) provides Fleet Ship Maintenance - Live
Navy ERP (SAP) provides Finance, Logistics and Workforce Management - Live
Navy MSC (Oracle) provides Finance and Logistics - Live
Navy MWR (SAP) provides Financial Management and HR Management - Live
USAF DEAMS (Oracle) provides Financial Management - Limited Deployment / Development
USAF ECSS (Oracle) provides Logistics - Program is Temporarily Suspended
For Official Use Only

17. Defense Interest Group (DEIG) Members
International DoD ERP Program Summary
The International DoD ERP Programs and Communities have also made progress:
They can support most of the functionality available in ERP products,
The programs are in various stages of development … investigation, planning, development, implementation and operation,
Defense Interest Group (DEIG) Members
Australia
Canada
Columbia
Denmark
Finland
Germany
Israel
Italy
The Netherlands
New Zealand
Norway
Portugal
Singapore
Slovak Republic
Slovenia
Sweden
Switzerland
Turkey
United States
DEIG Observer Status
NATO Maintenance and Supply Agency (NAMSA)
Countries who attended as observers or expressed interest in DEIG:
England
France
Hungary
Malaysia
Poland
Thailand
Spain
Ukraine
Shared Lessons Learned
The Canadians shared information on their deployed server and Mobile Engine experiences.
For Official Use Only

18. Other US Federal (non-DoD) ERP Programs
Other US Federal (non-DoD) ERP Programs and Communities have also made progress:
Department of Homeland Security (Customs & Border Protection),
Housing & Urban Development
Department of Interior
Internal Revenue Service
US Department of Agriculture
National Aeronautical Space Administration
US Postal Service
Shared Lessons Learned
DoD has collaborated with non-DoD Public Sector on FI and WFM requirements
For Official Use Only

19. Why We Are an Active Member of One Voice
Both SAP and Oracle are EACH investing over $1.5 billion a year in Research & Development.
The software vendors listen directly to DoD’s requirements through the One Voice forum to add DoD specific functionality.
In the past couple of years they have made major investments in DoD related functionality to support Acquisition and Government Contracting, Government Furnished Equipment, Standard Financial Information Structure, and Prompt Payment for Small and Disadvantaged Businesses.
For Official Use Only

20. One Voice Process Flow
Developing DoD’s ERP process flows provides for process confirmation, gap resolution, and hands-on familiarity with the software prior to internalizing
Process
Flows 1 2 3
User Requirements
1. System must plan
2. System must schedule
3. System must optimize
4. System must reorder
Define Process Need
Configure Process
Socialize GAPS at One Voice
Programs develop user requirements against DoD End to End process flows to maximize COTS adoption
Identify GAPS
Prepare for One Voice or Construct ER / DRQ
Review requirements internally
Present GAPS to One Voice
Allow for Consensus
Obtain a Final Vote 6 5 4 7
Collaborative Design
Ready for
Release and use
In DoD
Acceptance Test
Present on One Voice Call
Collaborative Design
Design Walkthrough
Build Status Reporting
Collaborative Testing
Testing of all processes, systems, data on DoD dedicated Instance
Present GAPS to Vendor
Allow for Consensus
Vendor Confirmation
For Official Use Only

21. Key Roles and Responsibilities
One Voice Coordinator:
Develop and maintain an effective and efficient process to analyze, prioritize, submit and track proposed Enhancement Requests (ERs) … also known as Development Requests (DRQs),
Schedule and coordinate One Voice meetings with vendors; prepare agendas, minutes, and track actions,
Maintain a calendar for key milestones, deadlines for ER or DRQ submissions,
Oversee; Methodology Integration, Risk Management, and Training and Continuous Education submissions,
Upkeep EI Toolkit repository with Enhancement Requests, Implementation Requirements and software releases,
Ensure One Voice is aligned with DoD business strategy and direction,
Show visible support for vendor collaboration efforts and there criticality to business,
Resolve obstacles which may impact the successful outcomes expected by programs.,
Approve Key Deliverables and enhancements carried out in the software to meet DoD’s requirements, and
Provide final approval for process requirement acceptance for wider use.
One Voice Member:
Knowledgeable on ERP products, their project business processes and identify requirements and gaps,
Accurately research and document proposed ERs / DRQs and coordinate them internally among their team,
Empowered to speak for their program regarding ER / DRQs prioritization, Methodology Risks, Improvements , etc,
Attend and participate in all One Voice meetings / calls, and recommend discussion topics and meeting agenda items,
Provide ER / DRQ status quarterly to the One Voice Community.
For Official Use Only

22. ROI - What Do We Get? Lowers Development and Maintenance Costs:
Opportunity to feed functional requirements to ERP vendors for development at their expense,
Incorporation of these DoD requirements can reduce the Government cost to develop and maintain the functionality by reducing the need for customization and interfacing,
Aligning our short term customization with vendor’s strategic plan can also reduce cost and simplify future upgrades,
Aligns our efforts, eliminates duplication within DoD and creates an opportunity to leverage other nations’ “Best Defense Practices”.
Improves Product Performance by Influencing Development:
Primarily leveraging Industry today … “Out of the Box”,
Reduces cost of training, deployment and operations.
Improves Product Knowledge – Knowledge Transfer Between Components / Software:
Reduces cost to develop and operate,
Provides an opportunity to develop productive relationships with:
ERP vendor developers ,
Other US Federal (non-DoD) ERP Practioneers, and
International Defense Practioneers worldwide,
Not limited or biased by System Integrator’s interpretation of the product.
For Official Use Only

23. What we need from you Be a change leader ...
Organizational commitment to make effective use of the medium,
Volunteer to facilitate process based requirements discussion,
Identify One Voice members for each of your programs,
Ensure members are able to participate with One Voice meetings / calls, and are empowered to speak for the program,
Provide a list of required future enhancements the program needs,
Review and comment on the revised process based ER / DRQ template ,
Vote on the top 5 issues the One Voice forum should create IPTs to address,
Provide Return on Investment and Metrics to Measure Success,
Communicate One Voice activities and status to your peers and subordinates, and
Own the success of this One Voice Initiative!!
Be a change leader ...
“Make COTS meet DoD needs”
For Official Use Only

24. LOA Memo Update Ray Bombac Procure to Pay Co-Lead
Business Integration,
Office of the Deputy Chief Management Officer
For Official Use Only

25. Enterprise LOA/Accounting Classification Overall Problems:
Currently we use several different LOA methods depending on the Service and/or the Functional Area. This impedes interoperability.
- One system having several different financial configurations for multiple functions is commonplace
- Given the Interim and Target systems that use SFIS, LOAs methods are all different.
- Legacy systems, being used for audit readiness goals/business feeder requirements need to interoperate with the target environment
- Manual entry is required by receiving systems, as a result of receiving systems not being able to accept data from other systems, because of differences in LOA structures
- Component driven configuration requirements, different from other Components/Functional areas
- Stove-piped Systems
Examples of Problems:
DAI uses several LOAs
The MDA lines appear to have about 30 different formats (Source: DPAP)
DCMA and DFAS (so far) has identified and mapped about three dozen LOA formats that were common enough to be worth the investment in time. About a dozen of those maps are in production. There are an unknown, and possibly unknowable number of other formats. (Source: DPAP)
Intra-Governmental Transactions (IGTs) need to have buyer side and seller side information
Today, LMP does not receive the seller side information (Source: SFIS Validation).
“Trading Partner Entity Code” is a concatenation of Main Account and Limit of trading partner
DDRS cannot do the IGT Elimination and cannot receive a clean audit opinion
Not one WCF system can properly collect IGT data to send to DDRS for IGT Eliminations
This is an operational challenge in multiple ERPs and we need to figure out how to solve the IGT problem for the department moving forward as more and more transactions are processed
For Official Use Only

26. Enterprise LOA/Accounting Classification Overall Solve:
A Standard LOA will cut across Components and Functional Communities
Immediate: An Enterprise LOA will standardize the use of data elements to increase interoperability amongst systems.
Example 1: Data by Object Class Code, i.e., 251 Contract Advisory Services, would be able to be linked and tracked from Budget to Execution
Example 2: DPAP and P/B will be able to access Transparency and Efficiencies data within the Enterprise LOA (clearly identify location of data elements)
Example 3: DCAS will be able to build edits on the Enterprise LOA. If a LOA comes in from a feeder system, it can do edits on specific elements within the LOA
Long-term: Will reduce costs associated with updating & testing multiple LOA interfaces w/multiple systems; more accurate data exchanged, posted, and reported
Useful for managing a contract; matching obligations to the LOA
Will reduce Unmatched Disbursements (UMDs) and Negative Unliquidated Obligations (NULOs)
Increase accuracy for eliminations in Buyer/Seller transactions (DDRS level)
For TBO/TFO the entire LOA is needed until adequate pre-validation capabilities
Will reduce Un-reconciled Differences
For Official Use Only

27. Enterprise LOA/Accounting Classification Actions to do:
Target date for interface compliance/updates is July 2012
Components and Organizations, such as DPAP, Logistics, and DFAS will update their LOA or system interface agreements/crosswalks to order data elements as presented in Attachment A, adhering to SFIS format rules.
Interim and Target Systems will ensure all applicable accounting classification data is present in the Enterprise LOA.
Legacy business feeder systems used for audit readiness goals must establish: crosswalks to SFIS/Interface to DDRS and the SLOA
Enterprise systems will upgrade to handle the Enterprise LOA
Notes for Implementation:
Not all elements will be used in all transactions. It depends on what the transaction is. Data elements not used will be left blank in between “^”s
Wrapping of the LOA length must be configured for and accounted for in all systems
The requirement will be a part of the SFIS requirements and systems will be required to include this as part of their overall SFIS Implementation Plan
For Official Use Only

28. Enterprise LOA/Accounting Classification History:
Most recently (FY2011) a DCFO-sponsored ERP Top Issues WG was formed to evaluate “pain points” experienced during ERP operability. The top pain point was interoperability. The WG proposed a standard line of accounting as a way to improve interoperability. Members included all Services, DAI, DFAS, DCMO, and BEIS
This Enterprise LOA leverages the Financial Data in Procurement (FDIP) Concept and address many of the implementation issues as it relates to the LOA and ultimately transaction sets
This Enterprise LOA has been implemented for Travel/DTS
Policy, Laws, Regulations: DoD FMR referencing the SFIS Resources webpage; OMB Circular No. A-127, Financial Management Systems; The Federal Financial Management Improvement Act (FFMIA) of 1996; CFO Act of 1990; The Secretary of Defense memo on Audit Readiness, dated Oct 13, 2011; BEA will be updated to reflect this Enterprise LOA
For Official Use Only

29. Enterprise LOA/Accounting Classification Format Review and Notes:
LOA/Accounting Classification Data Element Name (Length)
Department Regular (3): A1 in SFIS; Examples: 021 Army, 017 Navy, 057 Air Force; 097 ODOs
Department Transfer (3): A2 in SFIS; Example: A transfer of obligation authority from DOE
Main Account (4): A3 in SFIS; Synonymous with Basic Symbol, Appropriation Symbol
Sub Account (3): A4 in SFIS; Indicates the relationship to the Main Acccount
Sub Class (2): A7 in SFIS; Grouping of a transaction type
Availability Type (1): A24 in SFIS; Examples: A = Annual, M = Multi-year, X = No year
Business Event Type Codei (8); T20 in SFIS; Replaces Transaction Codes
Beginning Period of Availability Fiscal Year Date (4); A27 in SFIS
Ending Period of Availability Fiscal Year Date (4); A28 in SFIS
Limit (4); Not in SFIS; however, most systems account for sub-allocations via Limit
Reimbursable Flag (1); A9 in SFIS; Examples: Direct, Reimbursabe Code
Budget Line Item (16); B4 in SFIS; Further sub-divides the Treasury Account Fund Symbol below subactivity
Object Class (6); B6 in SFIS; Will initially be implemented at the three-digit level as in SFIS with room to expand to six
FMS Customer Code (2); T21 in SFIS; Foreign Military Sales (FMS); The country receiving the product/service
FMS Case Identifier (3); T22 in SFIS; Identifies the FMS contractual sales agreement between countries
FMS Case Line Item Identifier (3); T23 in SFIS; Identifies a detailed line-item requirement
Agency Disbursing Identifier Code (8); 02 in SFIS; Synonymous with Treasury DSSN definitions for each disbursing office
Cost Object 1 (16); CA in SFIS; Reserved for Component use
Cost Object 2 (16); CA in SFIS; Reserved for Component use
Cost Object 3 (16); CA in SFIS; Reserved for Component use
Cost Object 4 (25); CA in SFIS; Reserved for Component use
Agency Accounting Identifier (6); O3 in SFIS; Fiscal Station Number; Comptroller defined; Identifies the accounting system responsible for the accounting event
iThis is GTAS 2014 requirements not currently required
For Official Use Only

30. Enterprise LOA/Accounting Classification Concerns/Questions:
What does implementation timeline mean?
What are the Cost Objects used for?
Does this apply to legacy systems? Entitlement Systems? Contract Writing Systems? Cash Management? Reporting?
Too many elements/characters in LOA that will result in information wrapping on a contract.
Why only a subset of financial data instead of all of the SFIS elements?
What if I have segregated data? Do I need to use the ^’s?
What problems does this solve?
How / why is the LOA proposed by the draft memo different from the agreed upon SFIS data elements?
Are we expecting a person in the field to know the details and construct of an LOA when all he/she wants to do is order something?
How does this apply to transaction sets such as DLMS that use short keys such as fund code?
How does this relate back to the Procurement Data Standard (PDS)?
For Official Use Only

31. Enterprise LOA/Accounting Classification Positive Feedback:
Helps with:
cross disbursements/supplemental data
intra-governmental eliminations/provides proper trading partner information
reconciliations
UMDs, NULOS, Intransits
moving away from stove-piped/non-standard data exchanges
auditability in general
Cost Objects are essential for exchanging accounting information between systems
Essential for GWA/GTAS reporting requirements
Achievable goal for daily reporting of interfund to Treasury
With one standard LOA, easier to identify location of data elements
Easier to ensure proper data is present (edits)
For Official Use Only

32. Unit of Measure Ray Bombac Procure to Pay Co-Lead
Business Integration,
Office of the Deputy Chief Management Officer
For Official Use Only

33. Unit of Measure Problem
DoD Business Mission Area (BMA) needs to establish one Authoritative Master Reference Data repository for both Functional(s) and Systems Integrators
Currently, translation tables and data is maintained by various Functional communities (Logistics, Procurement, Finance, Real Property, WSLM, HRM)
Current BEA Reference Data:
Nearly all ERP programs building interface to WAWF and DFAS Entitlement systems have expressed invoice challenges at Entitlement for UoM
Approximately 31% of suspended invoices from WAWF to IAPS are due to a Unit of Issue problem
Lack of Enterprise-wide mediation strategy or roadmap to reduce mapping to Legacy DoD data codes
There are currently 55 unit of issue codes that have a conflict between the DoD code and the X12 code
For Official Use Only
Department of Defense

34. Unit of Measure Solution
Establish BEA web site as DoD Reference Master Data
Document requirement in BEA Content Refinement (CR)
Establish Publish/Subscribe at DLA Master Data Capability (system to system), or FLIS Portfolio Data Warehouse (FPDW)
DCMO and DLA to take Technical Lead to ensure implementation is planned and programmed
Work with ERPs, WAWF, and Entitlement systems to ensure system changes are in place to be compliant to BEA and DLMS
Recommend migrating X12-based mediation to latest version of UoM code set to eliminate "borrowed" codes currently used to support prior versions of the standard
Requires X12 trading partners to use migration codes as designated in the Enterprise Mediation Table
Establish Enterprise Mediation at GEX, in the interim environment until all systems can migrate to the PDS or 2AN ASC X12 code
Similar challenge for systems to migrate to ISO 3166 Country Code 2AN
For Official Use Only
Department of Defense

35. Unit of Measure Action Items
NLT 28 March 2012:
Ensure all DoD Components have reviewed the BEA Unit of Measure Values as published in BEA 9.0 (Enterprise Standards view)
Incorporate any final comments and publish in BEA for Compliance - Document requirement in BEA Content Refinement (CR)
March – June 2012:
Establish Publish/Subscribe at DLA Master Data Capability (system to system)
MDC/FPDW already publishes Authoritative Data for Item, Vendor, Customer using web-services, web application, and business intelligence reporting
Coordinate with ERPs, WAWF, and Entitlement systems to ensure system changes are in place to be compliant to BEA UoM Domain Values
Coordinate with DLA J6, GEX PMO to establish Enterprise Mediation, in the interim environment until all systems can migrate to the 2AN ASC X12 code
Similar challenge for systems to migrate to ISO 3166 Country Code 2AN
For Official Use Only
Department of Defense

36. Action Item POCs Organization POC email OSD DCMO John Garbarino
Ray Bombac
DLA J6 GEX
Richard Campagna
DLA J6 WAWF
Adarryl Roberts
DFAS
Anita Hiss
Jeffrey Hayden
Patricia Rodgers
Elizabeth Wehe
Nancy Shacklock
DLA DLIS
Charlene Woodman
DLA J6 DLMSO
Ellen Hilert
Larry Tanner
OSD AT&L DPAP
Bruce Propert
For Official Use Only
Department of Defense

37. HRM Ontology
Johnny Lopez
HRM CBM Lead
OSD P&R
For Official Use Only

38. HRM Ontology
Slides forthcoming
For Official Use Only

39. Open Action Items
For Official Use Only

40.
For Official Use Only

41. Backup Slides
For Official Use Only

42. Strategic Alignment and Defense Business System Oversight
Strategic and Operational Goals shape the business processes that support their achievement and are enabled through End-to-End Processes. Business processes must be continuously analyzed to enable greater efficiency and effectiveness.
Business systems should be fielded to support and enable these reengineered business processes.
Business Process Reengineering
Business
Enterprise
Architecture
Strengthen and Right-size the DoD Total Workforce
Strengthen DoD Financial Management
Build Agile and Secure Information Technology Capabilities
Increase the Buying Power of the DoD
Increase Operational and Installation Energy Efficiency
BEA: Activities, Data Standards, Information Exchanges, Business Rules, System Functions, System Data Exchanges, Terms, and Linkages to Laws, Regulations, and Policies
Aligns to and supports End-to-End (E2E) DoD Business Processes: and performance measures that apply to DoD Performance Budget
Continuous
Performance
Improvement
Enterprise Transition Plan
Roadmap for BEA Implementation
Includes planned milestones and measures
Lean Six Sigma
Business Process
Reengineering
Report on Defense Business Operations
Updates Congress annually on progress made Includes actual milestones and measures
Component Execution
Performance Results
Re-engineer / Use End-to-End Business Processes
Create Agile Business Operations that Support Contingency Missions
Strategic Alignment
Performance Measures
Strategic Management Plan Business Priorities / Outcomes / Goals / Measures / Key Initiatives
For Official Use Only

43. Significant Progress - SAP
Major functional gains driven by US Programs
Supply (Safety Stock Planning with Maintenance and Repair, Readiness Based Sparing, Interchangeability &Substitutability)
IUID
Financial (FM Deriver, Prior Year Rates, Cost Pro-ration, Commitment Override, Retained Earnings Override, Commitment of funds and subcontracting)
Maintenance (BOM/PVS, Change Control of Work Orders, Maintenance Event Builder WBS at Order Location, Permits at Work Order Level)
Work Force Management (OJT, Nested Qualifications)
Major functional gains driven by International Partners
Mobile Defense Solution – Enhancement Framework, Interface to on-board maintenance management systems, Flight order creation, Purchase requisition for Services
Force Templates
Personal and Functional Goods Issue processes for defense
Foreign Military Sales – Case Mgt, Procure, Receipt Inventory, Issue, Pay
For Official Use Only

44. US DoD SAP One Voice - Leadership Continuum
ESG and US DoD have always chartered and sponsored One Voice
BTA will now directly lead the effort
Change of leadership provides a juncture to reassess and determine how to optimally move forward
NDAA 2010 directs elimination of customization and BPR to optimize our investment in COTS
NDAA 2010 and BPR
“appropriate business process reengineering efforts have been undertaken to ensure that—the business process to be supported by the defense business system modernization will be as streamlined and efficient as practicable”
“the need to tailor commercial-off-the-shelf systems to meet unique requirements or incorporate unique interfaces has been eliminated or reduced to the maximum extent practicable”
Mr. Fisher to March ESG: “Anything that minimizes SV-1 interfaces and permits the shrinking to 8 ½ by 11 sheet that is readable is objective evidence of BPR”.
For Official Use Only

45. Summary to date Successfully Maturing the Solution
Addressed gaps by identifying the deficiency, documenting the requirement, and supporting testing of functionality delivered including Supply (APO, I&S), IUID, Finance, Maintenance, Work Force Management, and Project Systems
Delivering Knowledge Transfer Opportunities
Many Webinars/Workshops/Testing activities
Sharing lessons learned
New Zealand sharing Aircraft Logbook info with Army
Canadian info shared on deployed server and Mobile Engine
Canadian development of the SOA Maintenance Services Collaboration Prototype
Collaboration with Public Sector on FI and WFM requirements
Collaboration with SUGAIR and ASUG A&D on I&S and PBL/CLS functionality
For Official Use Only

46. Action Items
For Official Use Only
Department of Defense

47. Action Items
For Official Use Only