department of defensefor official use only1 beccm coi meeting march 14, 2012 dennis wisnosky dod...

Department of Defense For Official Use Only 1

BECCM COI Meeting

March 14, 2012

Dennis WisnoskyDoD Business Mission Area Chief Technical Officer & Chief Architect in the Office of the Deputy Chief Management Officer

Jack AhujaDirector, Business Integration,Office of the Deputy Chief Management Officer


• BECCM Mission Statement • E2E Framework • Enterprise Data Standards • One Voice• LOA Memo Update/Next Steps • Unit of Measure • HRM Ontology Overview • Open Action Items

Agenda


• 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 1072 - 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

BECCM Mission StatementStrategic Outcomes


E2E Framework

Randy EckhardtBusiness Integration / Investment Acquisition Management,Office of the Deputy Chief Management Officer

Department of Defense

5

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 & E2Es in the BEA

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


6

E2Es and Capabilities in the BEA

Cap

ab

ilit

ies

by

Fu

ncti

on

al

Dom

ain

E2Es Spanning Functional Domains

Fin

an

cial

Man

ag

em

en

tFM

Hu

man

Reso

urc

es

Man

ag

em

en

t

HRM

Mate

rial

Su

pp

ly &

Serv

ices

Man

ag

em

en

t

MSSM

Real P

rop

ert

y &

In

stallati

on

s L

ifecy

cle

Man

ag

em

en

t

RPILM

Weap

on

Sys

tem

Lif

ecy

cle M

an

ag

em

en

t

WSLM

BEA Core Business Missions (CBMs)

For Official Use Only


7

• 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

About E2Es

E2Es represent both industry and government leading practices for integrating common business processes

across the enterpriseFor Official Use Only


8

Proposed Definition: Complete MappingLevels for Managing DoD Business

•Management Framework

•Cross Functional in nature

•Aligned to Strategic Outcomes, not Ownership

Level 1

•“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 2

•“How” – SOPs

•ERP Configuration Guides for specific roles

•Business Process Reengineering (BPR)

Level 3

•Systems – specific activities that are the business processes and blue print used by an organization in a given systems environment

Level 4


Perf

orm

ance

Mea

sure

s


Solution Architecture Framework

For Official Use Only 9

• Strategic• Organizational• Program• System

Metrics

• 15 End-to-EndsBusines

s Process • Transactional

• Master Data• Business Intelligence• Technical Enablers• Services

Business Application

s• Data ManagementData

Management• Hardware• Software• Cloud• Information Assurance• Security

Infrastructure


10For Official Use Only

Enterprise Data Standards

Ray BombacProcure to Pay Co-LeadBusiness Integration,Office of the Deputy Chief Management Officer


11

• 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 1072 - 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

Enterprise Data Standards



12

• 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®

Definitions



Enterprise Resource Planning (ERP) One Voice Effort

Mr. Jack Woolum - HQEBusiness Integration DirectorateOSD - ODCMO

ERP One Voice Mission

Mission: To provide a platform for:

1. Vendor communication of development efforts aimed at addressing common DoD specific ERP requirements, support updates and releases of new products.

2. Facilitate program exchanges of common objectives, share lessons learned, and to support early adoption of leading practices and innovative technologies, and

3. Establish the venue to support the reuse of RICE objects.

14Department of Defense For Official Use Only

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.

15Department of Defense For Official Use Only


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:


U.S. DoD ERP Program Summary

– 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


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,


International DoD ERP Program Summary

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

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

Shared Lessons Learned • The Canadians shared information on their deployed server and Mobile

Engine experiences.


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


Other US Federal (non-DoD) ERP Programs

Shared Lessons Learned • DoD has collaborated with non-DoD Public Sector on FI and WFM requirements


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.


One Voice Process Flow

4

7

Testing of all processes, systems, data on DoD dedicated Instance

1

Programs develop user requirements against DoD End to End process flows to maximize COTS adoption

Socialize GAPS at One Voice• Review requirements internally

• Present GAPS to One Voice

• Allow for Consensus• Obtain a Final Vote

2

Configure Process• Identify GAPS • Prepare for One

Voice or Construct ER / DRQ

3

• Collaborative Design

• Design Walkthrough• Build Status Reporting

• Collaborative Testing

5

Acceptance Test

6

Developing DoD’s ERP process flows provides for process confirmation, gap resolution, and hands-on familiarity with the software prior to internalizing

Ready for Release and use

In DoD

Process

FlowsUser Requirements

1. System must plan

2. System must

schedule

3. System must

optimize

4. System must

reorder

Define Process Need

Collaborative Design

Present on One Voice Call• Present GAPS to Vendor • Allow for Consensus• Vendor Confirmation


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.


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.


What we need from you

• 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”


LOA Memo Update



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:1. DAI uses several LOAs

– The MDA lines appear to have about 30 different formats (Source: DPAP)2. 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)

3. 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

Enterprise LOA/Accounting ClassificationOverall Problems:



26

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

Enterprise LOA/Accounting ClassificationOverall Solve:



• 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 LOANotes 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

Enterprise LOA/Accounting ClassificationActions to do:



• 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

Enterprise LOA/Accounting ClassificationHistory:



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 eventiThis is GTAS 2014 requirements not currently required

Enterprise LOA/Accounting ClassificationFormat Review and Notes:



• 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)?

Enterprise LOA/Accounting ClassificationConcerns/Questions:



• 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)

Enterprise LOA/Accounting ClassificationPositive Feedback:



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: http://ruby.nit.disa.mil/bmr/UoMHtml4/P2P_html.html

• 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

Unit of Measure Problem

http://ruby.nit.disa.mil/bmr/UoMHtml4/P2P_html.html


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– DCMO and DLA to take Technical Lead to ensure implementation is planned

and programmed

– 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

Unit of Measure Solution


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)– http://ruby.nit.disa.mil/bmr/UoMHtml4/P2P_html.html

– 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

Unit of Measure Action Items

http://ruby.nit.disa.mil/bmr/UoMHtml4/P2P_html.html


Action Item POCs

Organization POC email

OSD DCMO John Garbarino [email protected]

OSD DCMO Ray Bombac [email protected]

DLA J6 GEX Richard Campagna [email protected]

DLA J6 WAWF Adarryl Roberts [email protected]

DFAS Anita Hiss [email protected]

DFAS Jeffrey Hayden [email protected]

DFAS Patricia Rodgers [email protected]

DFAS Elizabeth Wehe [email protected]

DFAS Nancy Shacklock [email protected]

DLA DLIS Charlene Woodman [email protected]

DLA J6 DLMSO Ellen Hilert [email protected]

DLA J6 DLMSO Larry Tanner [email protected]

OSD AT&L DPAP Bruce Propert [email protected]

mailto:[email protected]














HRM Ontology

Johnny LopezHRM CBM LeadOSD P&R


• Slides forthcoming

HRM Ontology


Open Action Items

Department of Defense 40For Official Use Only

http://dcmo.defense.gov


Backup Slides


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.

Bu

sin

ess

Pro

cess

R

een

gin

eeri

ngBusiness

EnterpriseArchitecture

Strengthen and

Right-size the DoD

Total Workforc

e

Strengthen DoD

Financial Managem

ent

Build Agile and

Secure Informati

on Technolo

gy Capabilit

ies

Increase the

Buying Power of the DoD

Increase Operational and Installat

ion 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 PerformanceImprovement

Enterprise Transition PlanRoadmap for BEA Implementation

Includes planned milestones and measures

• Lean Six Sigma• Business Process Reengineering

Report on Defense Business OperationsUpdates 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 Operation

s that Support

Contingency

MissionsStrategic Alignment

Performance Measures

Strategic Management PlanBusiness Priorities / Outcomes / Goals / Measures / Key Initiatives


• 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

43

Significant Progress - SAP


Department of Defense 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”.



• 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

45

Summary to date



Action Items

department of defensefor official use only1 beccm coi meeting march 14, 2012 dennis wisnosky dod...

Documents

related business information

enhanced dod data strategy

mature business processes

functional domaine2es

organization e2e

functional areas

department of defenseeach

common key data elements