FY14_AEIS_-_Business_Process_Reengineering.docx

Business Process Reengineering (BPR) Assessment Form Version2 September 28, 2012

Department of Defense Page 1 of 25

DBS Assessed: AFSC Enterprise Information System (AEIS)

DITPR ID: 14998

PCA’s BPR POC Name:

Email:

Submission Date: 03 May 2013 Investment Information: BPR Assessment Submissions should address only the business processes that were reengineered.

BPR Assessment Submission Type: Development Investment Category: Dev/Mod Current Services Current Funds Certification Request ($M):

Dev/Mod Amount: 0.366M Current Services Amount: 1.025M Current Funds Certification Method: OEP ☐OOC Date of Current Funds Certification Request: 01 Oct 2013 Acquisition Information: If the question/sub-question cannot be answered based on the program's current Acquisition Lifecycle Phase/Business Capability Lifecycle, please state "BPR ACTIVITY NOT FULLY PERFORMED" with a justification and the anticipated date/timeframe when this activity will be fully performed.

Acquisition Lifecycle Phase: Execution - Full Deployment

Please answer all required questions based on the BPR Submission Type. When providing objective evidence for each response, please ensure that the materials are provided with this form and that it is readily apparent which part of the materials are relevant to which questions on this form. _____________________________________________________________________________ Q1. What business need are you trying to solve or sustain through this BPR submission?

Describe and document the current or existing need to be addressed. The business need shall:

1.1 Define the scope, magnitude and duration of the business need (e.g., issue, situation or opportunity).

The proposed development and modernization initiatives for AEIS include changes to the user interface, code and database. These changes support the functionality, usability, and interoperability of the AEIS system to help transform DoD/USAF business processes to be implemented by Air Force Sustainment Center (AFSC) and the Consolidated Sustainment Activity Group – Supply (CSAG-S) functions and organizations. FY14 AEIS efforts focus on the following 3 major modules within the AEIS Information System.

· MFT- Metrics Financial Tool (MFT) is used by financial analysts, managers and commanders across the 448 SCMW and beyond. MFT provides tracking of forecasts, actual execution results, budgets, funds distributions, and executable requirements in a user-friendly dashboard environment. The system also generates metrics and facilitates narrative collection and collaboration. The existing business need is to manage financial execution across a $5 billion materiel sustainment enterprise. The objectives enabled by this system include validating compliance with public law (propriety of funding/purpose/time/amount), managing materiel executions, managing overhead execution, managing compliance with targets and forecasts, collaborating and correcting discrepancies, and insuring 100% execution of available funding on valid requirements. This effort represents the critical functions of all Financial Management organizations and must be managed on an ongoing basis to the extent that funding is made available for materiel sustainment operations.

· MAT- Manpower Analysis Tool (MAT) is used by analysts, managers, resource advisors and resource managers across the 448 SCMW and beyond. The system is designed to facilitate collaboration of vacancy fill requests, validated system data, and automate a series of labor intensive manpower management tasks. The system generates mismatch reports and programmatically creates various personnel charts and tables. This system automated critical functions required to manage civilian personnel. These business processes will be required as long as civilian personnel management remains a part of DoD operations.

· MPST-Maintenance Engineering Project Sustainment Tool (MPST) is used by engineering stakeholders across the Air Force to approve, validate, prioritize, collaborate on, and document the requirements and execution of multi-billion dollar CSAG-S engineering and Test Program Set (TPS) projects. The supported business processes include the management of sustaining engineering for CSAG-S managed assets. This function supports the improvement in reliability and maintainability of Working Capital Fund (WCF) managed components and will remain an ongoing effort for the life of materiel sustainment operations.

1.2 State the product or service developed, delivered, or being maintained to support the business process involved.

AEIS is a web-based set of collaboration capabilities that were designed to support key non-logistics functions to include, but are not limited to, financial management, personnel management, and engineering. These capabilities directly support the Consolidated Sustainment Activity Group Supply Division (CSAG-S) for the Supply Chain Management Community and its customers (e.g., MAJCOMs, FMS, other services). Primary capabilities include the Metrics Financial tool (MFT) which uses data from legacy financial systems to distribute, budget, forecast, track and execute CSAG-S dollars; Manpower Analysis Tool (MAT) which supports vacancy fill requests, human resource decisions, and the appraisal process; MSD/GSD Engineering Project Sustainment Tool which records and reports on all aspects of Engineering and Test Program Set projects from initiation of a program or project through computation of Return on Investment and subsequent funding execution across the AFSC enterprise. Benefits to the mission include continuous process improvement in support of Net Centric operations as well as the Global Base Support strategic plan of the 5-Center Construct. AEIS provides a stakeholder dashboard environment used to generate and manipulate information used to track, approve, validate, prioritize, collaborate, and document non-logistics specific requirements and execution. Generates metrics stoplights, facilitates collection and collaboration, generates reports and programmatically creates various information required to meet the AF Sustainment Center strategy.

1.3 Identify the customer of the product or service, and describe the expected standard of quality.

AEIS is currently organized under AFSC; however its user base expands across all MAJCOMs, Air Logistics Complexes, HQ AFMC, AFLCMC, and Depot Maintenance organizations. Users include but are not limited to Financial Managers, Commodity Program Managers, Funds Holders, Item, Equipment Specialists, Resource Control Officers, Engineers, Financial Analysts, Resource Managers and Supervisory Personnel. AEIS configuration and development meets DoD and Air Force required standard of quality. Quality expectations include non-quantifiable elements of usability and intuitive design as well as quantifiable measures of uncompromised data accuracy and reliability. The overall expectation for financial data is 100% accuracy based on transaction level data reflected in legacy financial systems with automated discrepancy notification to trigger resolution.

1.4 Describe the current operating environment and performance level of the product or the service provided.

AEIS modules today are performing at a high level of service and quality. FY14 enhancements will only increase the performance level further as processes continued to be refined and improved. Program Management is conducting an analysis of performance measurement and load balancing software to potentially measure the AEIS system performance based on work time availability and user performance.

· MFT Module – Operates consistent with 1.1 and 1.2 above. Functions are satisfactory to support financial management operation for the current user-base to include budgets, forecasts, financial execution, re-allocations, unfunded requests, etc. In addition, the system supports the management of item level execution for the materiel buy program enabling the linking of item level buy requirements to financial execution.

· MAT Module – Operates consistent with 1.1 and 1.2 above. Functions are satisfactory to support administrative manpower requirements for the existing user base to include validation of manpower data, automation of appraisals, automation of periodic reviews, etc.

· MPST Module - Operates consistent with 1.1 and 1.2 above. Functions are satisfactory to support sustaining engineering administration and management for MSD/GSD operations in addition to TPS management.

1.5 Describe the problem, issue, situation or opportunity as a quantifiable gap between current performance and customer expectations.

Customer expectation based gap analysis has been conducted on an ongoing basis throughout the life of each application. The following describes current performance enhancements anticipated to resolve unmet customer expectations as well as to exploit opportunities inherent in the current system construct:

· MFT Module – Problem: scalability to support additional users based on additional demand for support in addition to flexibility in data displayed to correspond to perspective of additional users. Opportunity: Development to include expansion of datasets to incorporate more organizational levels across the AFSC scope of operations to include datasets outside traditional AFSC AOR to increase customer base and user visibility. In addition, development to expand metrics/charts automation to include ad-hoc/custom generation as well as predetermined baseline sets. In addition, systematic upgrades and core program restructuring are required to align with current code standards following a .Net infrastructure and enhanced Object Oriented Programing.

· MAT Module – Problem: scalability to support additional users based on additional demand for support in addition to flexibility in data displayed to correspond to perspective of additional users. Opportunity: Development to include both expansions of datasets to support a broader user base as well as enhanced metrics reporting similar in scope to requirements within the MFT module. In addition, systematic upgrades and core programming restructuring are required to align with current code standards following a .Net infrastructure and enhanced Object Oriented Programing.

· MPST Module – Minimal functional development is anticipated at this time. Design changes to adapt to unanticipated user requirements will be strictly limited.

1.6 Describe why the status quo is a challenge (or opportunity) to the organization’s mission.

Status Quo of the current capabilities often represents manual processes that are both time consuming and unreliable as it relates to the required data. AEIS not only speeds the business process and decreases cost, but also delivers a more secure and agile service with an enhanced quality of process. AEIS has transformed business process from the inefficient batch process flow into a synchronized near real-time flow providing quicker access to accurate and near real-time information through streamlined data routing, thereby increasing the quality of decision making. The business processes are more visible, so the process and its operational quality are more transparent, better measured and better managed. While offering the return on investment of an integrated single system, multi-modules (MFT, MAT, and MPST) allows AEIS to adopt business processes for each module without impacting any of the processes of other modules. Return on investment is extended to that of simpler operations, better support, and easier maintenance. Applying this methodology of standardization across the different modules provides benchmarking data that can be used to compare processes. Standard interfaces and open standards are built to make it easier to integrate processes. AEIS allows an accurate and centralized consolidation of information gathered from various sources. Following standard practices and abiding to industry standard processes and application development helps create a better integrated environment. This reduces the need for custom code, but also allows the use of software generic templates and interfaces with only minor configuration changes. An integrated system provides the most effective data and information storage, and thereby, improves the efficiency and reliability of business processes.

Q2. Which of the 15 BEA End-to-End Processes does the business need support or sustain?

http://dcmo.defense.gov/products-and-services/business-enterprise-architecture/10.0/classic/index.htm

Identify the primary and any secondary E2E process (es) relating to the involved business need. The submission shall:

2.1 Identify the E2E business process flows aligning to the business need. (E2E/BEA assertions made in ACART may be used as objective evidence. Please use the ACART Comprehensive Assessment Report) AEIS Modules address the following End to End Processes: Budget to Report (MFT), Concept to Product (MPST), and Service to Satisfaction (MAT) Hire-to-Retire (MAT).

2.2 Identify the Operational Activities (OV-5) aligning to the business need (whether they are connected to E2Es or not). (E2E/BEA assertions made in ACART may be used as objective evidence. Please use the ACART Comprehensive Assessment Report) An export of the Comprehensive Assessment Report from ACART identifies all Operational Activities for AEIS.

2.3 Identify all standards associated with operational activity (ies) aligning to the business need. (e.g. Operational activities with associated Standard Financial Information Structure (SFIS) identified within the BEA) An export of the Comprehensive Assessment Report from ACART identifies all Operational Activities for AEIS.

2.4 Identify all redundant functional capabilities across the business processes to include secondary E2E processes in order to leverage existing solutions internal and external to the organization.

Projected FY14 development does not duplicate existing functionality within known AFMC systems. Each requirement is managed by the AFMC A4 IT Governance Requirements Management process and an analysis of alternatives (AoA) is conducted prior to submission and during review and vetting by stakeholders across AFMC and ALCs Q3. Have you completed an “As-Is” map of the current process that illustrates the specific business need that requires change?

Document an “As-Is” process map of the current-state business process relevant to the business process being reengineered. The process map shall:

3.1 Identify process start and stop point(s) in the business process that encompass the full scope of the business need.

Please reference As Is maps provided for each major AEIS module that is affected in this BPR. “As Is” maps of each module have been provided to include start and stop points, visually identifiable business process flows and constraints.

3.2 Fully document the current state of the business process, with sufficient detail to visually analyze rework loops, errors, duplication of effort, and process constraints.

See above paragraph. Refer to maps provided.

3.3 Identify the applicable laws, regulations and policies mandated for compliance.

AEIS complies with all Information Assurance laws and regulations, specifically FISMA, DIACAP, Section 508 compliance, Privacy Act, NDAA, Records Management, etc.

Q4. What are the operational process metrics (e.g. time, defects, production, and cost savings/avoidance) for the baseline “As-Is” process?

Based on the business need in Q1, identify the baseline/current performance and source of data. The submission shall:

4.1 Identify and describe the operational process metrics for the baseline/current performance.

· MFT Module – The Metrics Financial Tool is a complete module dedicated to measuring the health and wellness of CSAG-S, Work Authority, Cost Authority, and Central Procurement Funds supporting materiel buy and repair as well as overhead operations. The metrics track funding from initial distribution to 100% execution. In addition, stoplight charts and summary metrics apply established algorithms to determine “color” from a simplified “dashboard” perspective. Unfunded requirements are measured and reported against excess funding reports to maximize positive impact of limited resources. All measures focus on a successful fiscal year end closeout and 100% execution of limited resources.

· MAT Module – The manpower metrics are focused on timely coordination of personnel action processing and approval in addition to validating source information through automated comparison across multiple source systems. Metrics are designed to flag data inconsistencies as well as measure process flow times and completion rates. Metrics are also designed to reduce supervisor administrative time and improve accuracy and reliability of necessary documentation.

· MPST Module – Measures are developed and tracked to determine engineering input accuracy (reduced rework) and timeliness (all projects submitted on or before suspense date). The module also measures the execution of funding with a target to have 100% of funds obligated against validated requirements or de-obligated and reallocated for re-prioritization. Returns on Investment (ROI) measures are included throughout the life cycle of an engineering project to insure correct prioritization and set the baseline for measuring a financially successful engineering initiative within the Working Capital Fund solvency requirements.

4.2 Identify and document operational process metrics that include no less than: Operational definitions, thresholds, scope, and calculations. ☐Included?

Functionality is the capability of the system to provide functions meeting stated and implied needs when it is used under specified conditions. It is evaluated by ensuring the adequacy level of the system to the user requirements, accuracy level of the output of the system, interoperability level of the system. This is accomplished through a documented Customer Acceptance Testing and sign-off on Field Readiness Review documentation. Is the system functionality adequate?

Accuracy represents the capability of the system to maintain a specified level of performance outputs when used under specified conditions. Process ensures reliable data is used direct from approved source of record. Data will obtain through automated data from source of record documented within Interface Control Documentation within the Corporate Data Repository System (CDRS). This is accomplished through quarterly survey to each Function Advocate. Is the system accurate?

Efficiency is the capability of the system to provide appropriate performance, relative to the amount of used resources, under stated conditions. Business processes are shared across modules/capabilities fostering efficiency. The use of standardized business processes is documented and used in multiple module/capabilities. This is accomplished through quarterly survey to each Functional Advocate. Is the system efficient?

Effectiveness is the capability of the system to enable users to achieve specified goals with accuracy and completeness in a specified context of use. Data output is sufficient to perform the mission objectives. System outputs are available in multiple formats that ensure business process executions are effective. This is accomplished through custom reports measure performance against established standards and pre-defined business rules to easily allow the user to see the health of their respective program. Is the system effective?

4.3 A data collection plan, including data sources, collection method (e.g., manual, system-generated), and required data fields. ☐ Included?

AEIS currently collects all data using manual processes and organic or contractor personnel. All AEIS data sources and interfaces are documented in the AFMC A4 identified process tools, EITDR and CDRS, as required. If additional data sources are required they are identified in each CSRD submitted through the AFMC A4 IT Governance process within the ISMT system. Current FY13 “As-Is” initiatives established a CSRD to provide a system generated/automated interface with the AF GCSS-DS. This automation will be complete prior to FY14 Dev/Mod initiatives. Where ever possible AEIS reviews data collection automation to obtain cost savings and/or cost avoidance.

Q5. Root Cause Analysis - What are the root causes of the business need identified above?

Conduct Root Cause Analysis (RCA) on the specified suboptimal situations/conditions described in the business need. The submission shall:

5.1 Document the method used to identify each root cause.

The “5-Whys” analysis method was used for all root cause analysis.

5.2 Document root cause(s) in the order of determined impact to the problem, issue, situation or opportunity.

See summary below by AEIS module.

5.3 Document specific efforts to involve affected stakeholders directly impacted by specific root causes in the analysis.

Root cause analysis was conducted over time with input from all affected stakeholders and functional review boards. The RCA was the basis for the stakeholders deciding to improve their processes by adopting web-based solutions.

5.4 Analyze and document environmental impacts on the root cause(s), including laws, regulations, directives, policies, governance, personnel to include senior level, training or lack thereof, oversight, facilities, etc.

The root causes for the variety of limitations and related opportunities seen across all functional activities are as follows: Microsoft Office applications are not robust enough to adequately support the mission. Personnel are very capable of using these applications, but these tools were not designed to support the complexities of the mission including the in-depth financial measures inherent to Working Capital Fund management. Joint use of these applications using share drives is an option, but requires Enterprise Information Technology Data Repository (EITDR) registration, certification & accreditation and significant documentation that far exceed the benefit that could be derived. Further, Microsoft Office applications were not designed to manage the numerous data sets and millions of records required to adequately support the mission. Legacy systems are difficult and expensive to modify. Many of the Air Force legacy systems are designed on old programming standards and infrastructures that are not easily adapted to the ever changing supply chain processes. These systems cannot be modified to add-on new web capabilities without redesign of the entire system which is cost prohibitive. Recent manpower constraints have further exacerbated the problem because individuals are covering multiple desks and it is progressively more difficult to keep up with processes that are manual intensive. Further, many of the Excel spreadsheets and Access databases that have been locally generated are housed on the network drives, but are not properly registered as a system in EITDR. This has occurred because Microsoft Office applications are not robust enough to fully support the mission and legacy systems are too difficult and expensive to modify.

· MFT Module – Metrics Financial Tool: the Consolidated Sustainment Activity Group – Supply (CSAG-S) Working Capital Funds have historically been managed using Microsoft Office applications and processes that are manual intensive. Considerable manpower is spent extracting financial data from multiple legacy systems, summarizing the results and reporting progress to management officials. Manual transcription errors are common. Further, there are numerous financial data calls throughout the year (e.g., critical unfunded) that require significant resources to collect data, summarize the result, and brief management. Measuring financial goals and execution against those goals is all accomplished manually. Financial management processes are non-standardized across the enterprise. This has occurred because each location has its own way of doing business

· MAT Module – Manpower Tool: manpower data critical to personnel lists and supervisors to adequately do their mission are scattered between large legacy systems and locally developed Excel spreadsheets. Individuals spend more time collecting data and populating spreadsheets than they do analyzing their manpower resources and making decisions on how to better manage the limited human resources. The annual appraisal and feedback process is largely manual and dependent on cumbersome spreadsheets to accumulate and disburse information. Reorganization to more virtual organizations is complicated because employee AF Form 971 folders are not located at the same location as the first line supervisor. In some cases, individuals are maintaining their own 971 folder. Many of these problems have occurred because Microsoft Office applications are not robust enough for our mission and large legacy systems are too difficult and expensive to modify.

· MPST Module – Engineering Project Management: this process has historically been managed using Access databases and manual spreadsheets which is filled with versioning problems because many different people are contributing to the databases and there is confusion on which is the most current version. The database is manually populated by manually transcribing data from multiple legacy systems which takes considerable time and introduces human transcription error. Significant manual effort is required to prioritize the projects for funding and for tracking the execution of the funds.

Q6. What non-material solutions (e.g., process, organizational, or training changes) are you implementing across the full spectrum of operations to address the business need? Why are non-material solutions alone insufficient to solve the business need?

Document how each step of the DOTMLPF-P Analysis is applied to each root cause identified by Root Cause Analysis. The submission shall:

6.1 Document how each step of the DOTMLPF-P Analysis is applied to each root cause identified by Root Cause Analysis.

See table below for each module.

6.2 Identify non-material solution(s) utilized in an attempt to address the business need.

Non-materiel solutions for AEIS development have historically relied completely upon human perceptions to identify trends that point to failure or weakness within a particular business process.

6.3 Document if/how the identified non-material solution(s) will impact existing DOTMLPF-P.

Table 1: Metrics Financial Tool Module (MFT)

Table 2: Manpower Analysis Tool Module (MAT)

Table 3: MSD/GST Maintenance Project Sustainment Tool Module (MPST)

Q7. What other existing material solutions (internal and external to DoD) did you consider to meet your business need? Why were these solutions unable to meet the business need?

Identify existing material solutions across the business missions that can potentially satisfy the business requirements. The submission shall:

7.1 Document the method used to evaluate /consider existing material solutions within DoD, and Commercial Off-the-Shelf /Government Off-the-Shelf (COTS/GOTS) solutions, including resources used, decision making criteria, and efforts to ensure sufficient analysis.

COTS and GOTS products are always considered during the AoA. Microsoft Office applications are not robust enough to adequately support the mission. Personnel are very capable of using these applications, but these tools were not designed to support the complex mission. Joint use of these applications using share drives is an option, but requires EITDR registration, certification & accreditation and significant documentation that far exceed the benefit that could be derived. Further, Microsoft Office applications were not designed to manage the numerous data sets and millions of records required to adequately support the mission.

7.2 Document a detailed justification if the existing material solution that is unable to meet the business need is currently identified in a Functional Strategy as a Mandatory / Enterprise Solution or System As AEIS prepares to migrate to the AFNET, program management is consistently reviewing modernization from the migration perspective and potential duplicity of other enterprise solutions. Current development does not duplicate existing functionality within those systems. Legacy systems are difficult and expensive to modify. Many of the Air Force legacy systems are designed on old programming standards and infrastructures that are not easily adapted to the ever changing supply chain processes. These systems cannot be modified to add-on new web capabilities without redesign of the entire system which is cost prohibitive.

7.3 Document the Analysis of Alternatives conducted to demonstrate why the existing material solutions and/or COTS/GOTS solutions may not be sufficient to address the problem, issue, situation or opportunity.

Each AEIS CSRD submitted through the AFMC A4 IT Governance process for development/modernization documents an analysis of alternatives of existing AFMC capabilities to demonstrate whether there is an existing materiel solution.

Q8. Which industry best practices/ benchmarks were leveraged to develop and evaluate potential “To-Be” processes and solutions? For example, did you consult with industry leaders, use the Supply Chain Operations Reference (SCOR) Model or an equivalent, incorporate written government best practices, incorporate industry leading performance metrics, etc.?

Describe benchmarking conducted and best practices adopted in developing and/or evaluating the proposed “To- Be" processes and RCA solutions identified. The submission shall:

8.1 Describe benchmarking conducted and best practices adopted in developing and/or evaluating the proposed “To- Be" processes and RCA solutions identified.

AEIS incorporates industry and DoD best practices when it comes to development and sustainment of the information system. AEIS leverages written government best practices, incorporates industry leading performance measures, and lean development capabilities for RAD (Rapid Application Development). AEIS showcases Agile development framework, employs clearing house functions for code already developed, implements source control and maintains separate development and production environments. AEIS is fully compliant with FISMA and DIACAP requirements. AEIS servers are hardened using the DoD Information Assurance Support Environment (IASE) Security Technical Implementation Guides (STIG).

8.2 Document the method used for benchmarking and incorporation of best practices.

Process benchmarking was the method used throughout development. Specifically, studies focused on observation and investigation of logistics, supply chain and financial management processes with a goal of identifying and observing the best practices from the various Air Force installations. This is an effective approach because processes are redundant at different operating locations and many innovative solutions have been developed over time that is non-standard in nature. The Materiel Squadrons are constantly running Rapid Improvement Events (RIEs) to evaluate the different process methods and determine which best practices for implementation are across all locations. AEIS capabilities were mostly developed at one location and then adopted across the enterprise as a best practice following a RIE.

8.3 Document how benchmarking and best practices enhance the “To-Be” process and address the problem, issue, situation or opportunity OR describe how the “To-Be” process was enhanced and the problem, issue, situation or opportunity was addressed without using best practices and bench marking.

To-be processes were designed around the process benchmarking methods described above taking into account the problems identified in RCA and Standardization/Streamlining events.

Q9. Have you completed a “To-Be” map of the target process that illustrates the improvements to the “As-Is” process that this effort will generate?

Document a “To-Be” process (map) describing the future state of operations, indicating improvements, and efficiencies that will meet the business need. The “To-Be” process map shall:

9.1 Identify start and stop point(s) that encompass the full scope of the future state business process.

A “To Be” process map has been provided for each major module that is affected by FY14 development and process improvements. Each map identifies start and stop points for the future state business process.

9.2 Fully document the future state of the business process with sufficient detail to visually analyze rework loops, errors, non-value added steps, potentials for duplication of effort, and process constraints.

“As Is” and “To Be” maps reflect minimal if any changes to each process as the minor development that is occurring to each module does not impact the larger picture of the business process already being addressed with in each major module. Areas that are affected by current process changes are highlighted in yellow for each major module.

9.3 Identify and document resolutions for each root cause identified in the RCA as well as the efforts taken to ensure that effective resolution of the identified root cause will inhibit recurrence of the problem, issue, or situation.

RCA demonstrated deficiencies in scalability and data views necessary to support an increasing user base. Resolution includes the integration of expanded data sets consistent with current data loads but inclusive of a broader level of transactional data. Adaptation to reflect the broader base of data will support additional users without change the overall construct and features of the system. Extensive analysis of source code for data manipulation has been conducted to insure integration of expanded datasets is consistent with current code. In addition, based on analyzing existing chart-decks, expansion of existing data-view functionality will increase customization and support location specific perspectives without compromising current data-views.

9.4 Demonstrate where processes were improved on the “To-Be” map or separate document to include at a minimum:

Areas that are affected by current process changes and improvements are highlighted in yellow for each major module.

9.4.1 Hand-off(s) between individuals or organizations are eliminated;

Areas that are affected by current process changes and improvements are highlighted in yellow for each major module.

9.4.2 Reduced resource requirements in achieving outcomes.

Areas that are affected by current process changes and improvements are highlighted in yellow for each major module.

9.4.3 Reduced time in achieving outcomes.

Areas that are affected by current process changes and improvements are highlighted in yellow for each major module.

9.4.4 Impact of laws/regulations/policies constraining the “To-Be” process.

Areas that are affected by current process changes and improvements are highlighted in yellow for each major module. No impact of laws/regulations/policies which constrain the To Be process have been identified.

9.5 Identify standard enterprise data exchanges for all interfaces that are planned to remain as part of the target processes (e.g. the Standard Line of Accounting/Accounting Classification (SLOA)).

All AEIS data sources and interfaces are documented in EITDR and CDRS as required. Data sources are also identified in each requirement submitted through the AFMC A4 IT Governance process within the ISMT system.

Q10. How have you eliminated or reduced the need for unique requirements, processes, or Reports, Interfaces, Conversions, or Extensions (RICE) objects? How many RICE objects are planned as part of this development/modernization?

Identify and itemize the business need for unique requirements and/or unique interfaces by using the RICE approach. Detail and furnish justification for the involved RICE objects. The submission shall:

10.1 Evaluate and document Non-value added (NVA) activities.

Through business process mapping and extensive critical path analysis, NVA activities have been identified and eliminated. Over the course of years, the processes for managing the key functionalities have been refined and streamlined to reduce inefficiencies and to document specific objectives, inclusions, and exclusions from the final product.

10.2 Identify and describe RICE related to the business need.

COTS and GOTS solutions were not conducive to the unique business environment created within the Air Force Working Capital Fund, sustainment engineering programs, or the complex nature of the civilian appraisal/civilian manpower environments. The development of custom functionality was necessitated by the unique features of these business practices. Going forward with 2014 development new RICE requirements include:

· MFT Module – Minimal additional anticipated input RICE requirements. Investigating interface options between MFT and an undefined contracting database to capture contract execution data to complement existing financial data from CRIS.

· MAT Module – No additional anticipated input RICE requirements

· MPST Module – No additional anticipated input RICE requirements

10.3 Documented RICE analysis at a minimum should include:

· MFT Module – Currently determining source data and interface requirements to incorporate contracting data into requirements execution functionality. Source data analysis will determine the extent or applicability of RICE object creation. RICE will be minimized through establishment of a single data feed capturing the extent of necessary data from contracting. This is currently in the in pre-development as data sources are being evaluated.

· MAT Module – See 10.2 above

· MPST Module – See 10.2 above

10.3.1 Assessment of existing RICE.

Existing RICE objects have been minimized through exhaustive process analysis. In addition, under the AEIS system structure, each unique functional module shares necessary RICE objects to eliminate redundancy.

· MFT Module – Utilizes single system feeds from each source system with data fields limited to elements critical to the financial management process. Single feed from CRIS, J025, and D043.

· MAT Module – Utilizes single system feeds from each source system with data fields limited to elements critical to the manpower management process. Linked to previously established single data feed within AEIS for Business Objects and MPES.

· MPST Module – Utilizes single system feeds from each source system with data fields limited to elements critical to the engineering management process. Linked to previously established single data feed within AEIS for CRIS and D043.

10.3.2 Assessment of existing RICE for reuse opportunities.

Integrated structure within AEIS enables broad reuse of existing RICE objects. FY2014 development within MFT is intended to expand visibility into contract execution data not currently available within the confines of existing RICE. Existing RICE has been scrutinized for opportunities to link to existing data sets vs. develop new interfaces.

10.3.3 Assessment of opportunities to leverage COTS/ GOTS vice new RICE development.

See 10.2 above

10.4 Detailed justification for proposed RICE, tying need and purpose to business need, customer requirements and/or process performance expectation.

Existing business needs entail tying requirements from D200A/ABCS for both materiel buys and materiel repair (contract) to final execution as expressed in CRIS. Data necessary to manage execution from a financial perspective is only available by interfacing with contracting. Going forward, the systematic initiative includes automating the data feed as developed within the contracting agency for use within the financial environment. The specifics of the contracting system are currently being researched to identify single feed requirements into MFT. The business requirement being met includes visibility of the execution process beyond the obligation of funding. Currently financial visibility is limited to the specific elements of accounting (commitments, obligations, and expenses) as managed within financial systems. The clear deficiency in this level of visibility is the complete lack of item level detail. Financial systems exclusively managed execution based on purchase request while the requirement is developed and must be managed at NIIN level. Tying PR to NIIN can only be achieved through inclusion of contracting data. This interface, when achieved, will tie together the process from final production of item level requirements from D200A/ABCS through execution within contracting as managed by the supply chain management community to final disposition as reflected in applicable accounting systems. This initiative reflects new capabilities that will dramatically improve management of materiel execution.

Q11. What are the operational process metrics (e.g., time, defects, production, and cost savings/avoidance) used for the targeted outcome "To-Be" process?

For each metric in Q4, identify the target performance and source of data. The submission shall:

11.1 Identify and describe the operational process metrics used to measure the targeted outcome.

FY14 modernization will introduce and improve process metrics associated personnel records management and human resource management (MAT), execution of engineering projects (MPST), and repair requirements execution and unfunded requirements measures (MFT).

11.2 Identify and document operational process metrics that include no less than: Operational definitions, thresholds, scope, and calculations.

The definitions, thresholds, scope and calculations are the same as those already identified in Question 4.

Q12. How have you engaged key stakeholders in your BPR process to ensure they are willing to change their processes/operations as needed?

Document how key stakeholders were/are engaged in the BPR process to ensure buy-in. The submission shall:

12.1 Document quantifiable method(s) used to identify and assess the impact on stakeholders including people, groups of people, or institutions on the success of the business project.

Informal time studies are the primary method used to assess the impact business projects have on stakeholders. These benefits (time savings) are first estimated in the CR/CSRD process and later authenticated by the FRBs. Key stakeholders have been engaged at all levels through the use of local functional review boards (FRB), organizational Technical Review Board (TRB), Wing level Configuration Control Boards (CCB), AFSC Executive Review Board (ERB) and the AFMC A4 Logistics Information Technology Management Board (LIT-MB). Each module of AEIS has identified a Functional Owner and key stakeholder user representatives. Functional owners and users identify a business need and submit baseline change requests to AEIS system administrators. AEIS submits all changes requests to the 748SCMG Technical Review Board (TRB) that reviews and approves changes requests using SharePoint Workflow capabilities. AEIS is under the A4 Requirement Management (A4 RM) process and submits all change requests through the CSRD process identified and required by the AFMC A4 Logistics Information Technology Management Board (LIT-MB).

12.2 Describe specific stakeholder interests in the BPR effort.

12.2.1 Project’s benefit(s) to stakeholder(s).

As stated above key stakeholders are engaged at all levels through multiple review and approval boards. This is the organizations best practice as to avoid unforeseen obstacles, conflicts and/or negative responses to any project. By documenting the process through the TRB and other approval boards’ obstacles and conflict are reduced and more easily avoided.

12.2.2 Changes that the project might require the stakeholder to make.

· MFT Module – stakeholder responsibility will not change with the incorporation of additional execution data into the MFT construct. Process changes will be limited to utilizing a single source system for execution data vs. continual manual interfaces with contracting to track and confirm execution progress.

· MAT Module – no change to stakeholder responsibility or processes anticipated with FY2014 development.

· MPST Module – no change to stakeholder responsibility or processes anticipated with FY2014 development.

12.2.3 Project activities that may cause conflict for the stakeholder.

· MFT Module – stakeholder input has been sought and integrated into development. No conflict with stakeholders is anticipated due to FY2014 development.

· MAT Module – stakeholder input has been sought and integrated into development. No conflict with stakeholders is anticipated due to FY2014 development.

· MPST Module – No conflict with stakeholders is anticipated due to FY2014 development.

12.2.4 The importance of a stakeholder's interests to the success of the proposed project.

· MFT Module – stakeholder input has been sought and integrated in development. FY2014 development is a direct result of input from stakeholders.

· MAT Module – stakeholder…