Defense Business Systems (DBS) Model

AAF  >  DBS  >  Solution Analysis Phase

Solution Analysis Phase

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DoDI 5000.75 Sect 4.2.b

 

The functional sponsor leads this phase with guidance from the appropriate CMO decision authority and support from the program manager and MDA. The objective of this phase is to determine the high-level business processes supporting the future capabilities to maximize use of existing business solutions and minimize creation of requirements that can only be satisfied by a business systemInformation systems that are operated by, for, or on behalf of the DoD, including: financial, contracting, logistics, planning and budgeting, installations management, human resources management, and training and readiness..

 

Phase Description:

  • Future capabilities are based on re-engineering the high-level future business processes that will deliver the capabilities. This includes selecting and tailoring commercial best practices to meet the needs of the end user community.
  • Definition of the future capabilities will include market analysis and research of other organizations with similar capabilities to identify processes that can be adopted.
  • The functional sponsorDoD or Component senior leader with business function responsibility seeking to improve mission performance, confirms the need for improved business operations, and represents the user community interests throughout the BCAC. must ensure funding is available to support the phase activities and must provide a plan for funding future phases, as appropriate.  The availability of funding must be validated by the appropriate resource official prior to the Functional Requirements ATP.

Reference Source: Based on DAG CH 6-3.5.3 content, Jan 2020

Business Process Reengineering (BPR)

Business process reengineering (BPR), as defined by the U.S. Government Accountability Office (GAO), is a systematic, disciplined improvement approach that critically examines, rethinks, and redesigns mission-delivery processes in order to achieve dramatic improvements in performance in areas important to customers and stakeholders.

BPR employs a logical methodology for assessing process weaknesses, identifying gaps, and implementing opportunities to streamline and improve the processes in business operations. The Department’s approach to BPR is an iterative process which begins with a focus on the business activities / work and the information used. Processes are then further refined and adapted as the Information Technology requirements are modeled. This approach aligns with the principles of Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities, and Policy (DOTMLPF-P) analysis. BPR is a companion activity to defense business system implementation, is a key tenet in the DoDI 5000.75, and should be practiced throughout the entire business systems lifecycle.

One of the most important reasons for performing sufficient BPR is to avoid modifying the core code of a commercial-off-the-shelf (COTS) product at all costs. In industry, customization is most often focused on processes that will give a company competitive advantage over or set them apart from other companies. Since the federal government is not profit-driven and is rather being mandated by Congress to not customize products, the push should be to utilize BPR and to adhere to the out of the box products as much as possible, which is an industry best practice. A 2015 report by Panorama Consulting found that of the 562 companies they surveyed:

  • The majority (66%) did little to no customization (defined as modifying one-quarter or less of the solution).
  • 34% did “significant” (22%), “extreme” (7%), or “complete” (5%) customization to their ERP implementation.

Ultimately, Functional Sponsors and Program Managers should try to find ways to modify existing business processes rather than customizing commercial software products to meet their needs. Discussions on common standards (Section 3.7) and requirements and configuration management (Section 3.5.5) are important to being successful in this area.

While it is possible to add code in the form of Reports (R), Interfaces (I), Conversions (C), Enhancements (E), Forms (F) and Workflows (W) (RICE-FW), this practice significantly increases program costs and should be minimized as much as possible through BPR. In many cases there will only be a few instances where BPR is not possible. For example, due to policy or law, it may be necessary to build or acquire needed reports, interfaces, conversions, and extensions. In these cases, adding to the product must be done under strong configuration control.

The Functional Sponsor, representing the needs of the user, leads the BPR effort. BPR may include eliminating non-value added processes, consolidating separate functional tasks into end-to-end cross-functional processes, and integrating business functions as much as possible to improve business operations and to achieve the desired outcome(s). BPR is a continuous process and requires a rethinking of why the “As-Is” process came to be and how it can be improved to achieve efficiencies.

Ideally BPR will begin prior to the start of the Acquisition process to understand the picture of “what good looks like”. However, BPR truly cannot be completed until a solution is selected to understand the underlying business processes of the product.

 

Major duties and responsibilities of BPR stakeholders:

  • The Functional Sponsor (or Sponsor), informed by input from the corresponding DoD Military Component, is responsible for BPR.
  • The PM is responsible for analyzing and considering the results of the BPR and using the goals of the reengineered process to shape the program.
  • Technical SMEs (including test and engineering), to understand the impact of process changes vs. technical changes
  • Cost SMEs, to understand the cost impacts of process changes vs. technical changes