Business Process

Reengineering
With Commercial Off-the-Shelf
Software
Cindy Shelton

Defense AT&L: September-October 2010 8

 Form Approved
Report Documentation Page OMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.

1. REPORT DATE 3. DATES COVERED

2. REPORT TYPE
OCT 2010 00-09-2010 to 00-10-2010
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Business Process Reengineering With Commercial Off-the-Shelf Software 5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION

REPORT NUMBER
Defense Acquisition University,Defense AT&L Journal,9820 Belvoir
Road ,Fort Belvoir,VA,22060
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT

NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE Same as 6
unclassified unclassified unclassified Report (SAR)

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std Z39-18
D

epartment of Defense acquisition prac-
tices are conceptually structured to de-
crease overhead costs while continuing to
improve capabilities and interoperability.
These practices mandate build versus buy
solutions, with more emphasis on buying
pre-built applications. Buying commercial
off-the-shelf software—COTS—can be
a very efficient and effective solution, if
the context of the life cycle is considered
in all customization decisions. If we are to
achieve the expected gains from purchas-
ing software versus building it ourselves,
then for the entire life cycle of the product,
we cannot allow any modifications. That is

Shelton is a program manager for the Air Force Services Agency, Headquarters. She is a certi-
fied Project Management Professional, an agile coach, and a Six Sigma master black belt.

9 Defense AT&L: September-October 2010

easily obtained in many small systems with a little disci- municate what needs to be tested, the cost to communicate
pline; however, large enterprise resource planning (ERP) so- what didn’t work the way it was tested, and so on.
lutions will encounter problems if not approached correctly
from its initial acquisition phase. This article discusses the When the total cost of ownership is considered, the cost of
issues around COTS and business process reengineering, a modified COTS can easily absorb any expected benefits
and improvements we can make to the acquisition process. or return on investment. In addition to the time (money)
First, let’s examine the reasons a COTS purchase is usually spent in modifying the software, the number of personnel
a good choice by taking a look at the total cost of ownership saved by applying consolidated functionality via an ERP sim-
and configuration control. ply translates into more technical resources to maintain the
software. Technical resources generally have higher costs
Total Cost of Ownership Advantage because of the need to analyze, modify, and manage the
The total cost of ownership begins with an estimate of all software architecture.
direct and indirect costs that might be associated with
the acquisition life cycle. That involves making some as- Configuration and Change Control
sumptions about the future and then simulating various The chief means for controlling the total cost of ownership is
scenarios to arrive at alternative cost estimates. The goal to minimize the number and degree of changes permitted to
of calculating the total cost of ownership is to support wise the baseline software. ERP packages are designed for a large
decisions about all the costs in the beginning and then audience of companies looking to achieve success by follow-
anticipate and manage those costs during the life cycle. ing a template of best business practices; however, software
Changing to look at software acquisitions from a tactical often fails to achieve its promise because of people’s reluc-
view of the upfront and direct project costs to a total cost of tance to change and their adherence to old processes. That
ownership is a significant paradigm shift for DoD. The de- leads to costly program modifications to replicate the old
partment must estimate the total cost of ownership against processes. That, in turn, can result in unnecessary manual
its strategic objectives—not from a budget concept. Many tasks and software maintenance issues, which neutralize
of the resources expended during a project are internal the original benefits of the software. Customization and
costs, so they are invisible in the budgeting process. The subsequent upgrades are costly, and the decision to hold
total cost of ownership for an unmodified ERP application the line should be made at the beginning of the acquisition
versus a homegrown variety for a complex organization and revisited only under the most extreme circumstances.
such as DoD is about 45 percent less than developing cus-
tom code. The greatest variances are in the time spent to According to Donald Burleson in his article “Selecting an
upgrade and test the new modifications, and much of this ERP system: Build or buy?” (<http://articles.techrepublic.
is done by the software company in an unmodified ERP com.com/5100-10878_11-1040167.html>), “If your orga-
system scenario. nization does not have a clear competitive advantage from
your ordinary business systems, an off-the-shelf solution
Each change, no matter how seemingly small, affects can offer the greatest benefit because a packaged solution
the ability to test and adapt future updates and software can be used right out of the box and requires very little IT
changes efficiently. Customizations are unique to the loca- overhead.”
tion. Quite often, this complicates the troubleshooting of a
real bug in the software, as it is time-consuming to separate Cost of Change: Return on Investment
the real bug from the custom code. There are processes
and procedures to address such a scenario, but they add
additional time and cost that should be factored into the
total cost of ownership. That’s one reason why ERP sys-
tems rarely meet their scheduled delivery dates and never
Exponential Cost of
meet their expected return-on-investment objectives. Production Negative
ROI
The figure “Cost of Change: Return on Investment” bal-
ances the number of features (software changes) against
Dollars

the anticipated return of that investment. As the number Returns from Product
of changes in code increases, the increase is exponential
and quickly erodes the return on investment. The cost of
changing software is not linear, but exponential. Frederick Positive
Brooks, author of The Mythical Man Month: Essays on Soft- ROI
ware Engineering, attributes the exponential rise in costs of
software changes to the cost of communication—costs to
understand the software to be changed, the cost to under-
stand what actually needs to be changed, the cost to com- Number of Features

Defense AT&L: September-October 2010 10

In a keynote address in 2002 to the Third International Con-
ference on Extreme Programming, Jim Johnson, chief execu-
tive office of the Standish Group, quoted a DuPont study
Customization and
that showed only 25 percent of systems features were re-
ally needed. “On average, 45 percent of software features subsequent upgrades are
are never used, and only 20 percent of features are used
always or often,” he said, giving us a frank reminder that we costly, and the decision
need to ensure the requirement meets a strategic need and
doesn’t simply pave an existing cowpath in the organiza- to hold the line should be
tion’s processes.
made at the beginning of
ERP solutions are modular and flexible, and thus can be cus-
tomized to a certain degree; however, major modifications
are complex and extremely costly. Software packages—es-
the acquisition and revisited
pecially ERP software packages—have processes encoded
into their click trails and transactions that will never do ev-
only under the most extreme
erything a customer wants. It is important to remind the
integrated product team and those who are customizing circumstances.
software to modify the COTS package only where it is a
strategic advantage. With that in mind, DoD would make
very few customizations to an ERP system. ness process is one where the organization, process flow,
and the configuration of the COTS system are done concur-
The trap for program managers is easy to fall into, though. rently; and you can’t do that until you know what software
Software companies, sponsors, and implementation teams you are purchasing. V. Koch’s article, “BPR and ERP: realizing
are very willing to justify customization at what initially a vision of process with IT,” published in a 2001 edition of
seems like a very low price to pay in comparison with the the Journal of Computing and Information Technology, further
angst incurred when the program manager asks the orga- pressed the need to combine ERP implementations with
nization to change. Regardless, it is still imperative for the BPR:
organization to change its business processes to meet the
COTS-embedded processes rather than customize the The implementation delays and ERP product modifica-
COTS to meet the organization’s process. tions could result in exponential growth in both direct
and indirect costs. … It would always be better to com-
Business Process Reengineering plete the BPR project prior to information system mod-
According to a Feb. 12, 2010, memorandum from the Office eling and ERP system development. Since the imple-
of the Deputy Chief Management Officer and the Fiscal Year mentation of large information systems is not possible
2010 National Defense Authorization Act: “Section 1072 without first altering business processes, reengineering
does not allow funds to be obligated for a defense business is essential in order to extract maximum benefit out of
system modernization that will have a total cost in excess the ERP products. However, analysis of business prac-
of $1,000,000 unless appropriate BPR efforts have been tices shows a different approach. Initiating BPR projects
undertaken. The business process to be supported by the prior to ERP means that the companies must provide
defense business system modernization will be as stream- resources for two successive projects. The reason why
lined and efficient as practicable.” many companies chose to conduct ERP system devel-
opment was to attempt to solve all their organizational
A memorandum providing guidance on implementing the problems without reengineering business processes
2010 National Defense Authorization Act update to U.S. first. ERP applications integrate many best business
Code 222v4, “Implementation of Section 1072 of the Fis- practices and much knowledge that could be worth-
cal Year (FY) 2010 National Defense Authorization Act while if included as a part of BPR projects. By taking the
(NDAA)–Business Process Reengineering (BPR) Assertion,” best practices inherent in ERP applications, companies
specifically states the BPR will be done during the require- can change their processes simultaneously with tech-
ments generation, which for most software development nological change. As a result, many companies changed
and acquisition life cycles is before the request for proposal their business processes to fit the ERP system require-
is released. Implementing COTS business products, specifi- ments, and the possibilities of ERP systems have been
cally ERPs, significantly affects the organization’s culture, used to underpin BPR.
structure, and business processes in addition to its proce-
dures and rules. Documenting business processes that you Koch and the National Defense Authorization Act are accu-
know will need to be modified significantly in the near future rate in stipulating BPR, but it should only occur in conjunction
is not an effective use of one’s resources. An efficient busi- with the COTS implementation and not before it. If BPR is

11 Defense AT&L: September-October 2010

not approached in this manner, the new business processes processes while implementing enterprise solutions. Its soft-
will require rework and will erode the cost benefits expected ware engineering waterfall-esque approach to enterprise
from the initial BPR. software acquisition needs to include the tasks related to as-
sessing the organization and adapting the organization to the
Fine-Tuning the Program Strategy inherent software processes. Nor does the Defense Acquisition
Executive leadership must be visibly involved in executing Guidebook address the need for business process reengineer-
strategy, and software implementation is no exception. Only ing in parallel with COTS implementation.
leadership can quickly address the disagreements that arise
in the process of transforming through BPR and an ERP imple- Once implemented, the value of ERP initiatives becomes
mentation. embedded in processes that are difficult to quantify. COTS
business software has embedded processes; therefore, if
Rules need to be modified to take advantage of the evolu- we do business process reengineering before purchasing
tionary strategy an integrated BPR and COTS implementation software, we will have to redesign those processes to the
requires. While it is very difficult for an integrated product ones inherent in the software functionality, and that can
team of subject matter experts familiar with their own pro- easily negate any gains resulting from reengineering or
cesses to remain disassociated enough to effectively deter- a COTS purchase. Merging BPR with agile principles of
mine what needs to be changed, organizations can establish an iterative delivery and a trained team of technical and
rules to evaluate each change to ensure it meets a strategic business experts will result in a program that is truly per-
or competitive need. formance- and results-based.

ERP systems and implementation teams are experienced in Bring in Lean

delivering software all at once versus an incremental deliv- In his book Design for Six Sigma, Subir Chowdhury states
ery; however, BPR and ERP can be delivered incrementally, that changing a design after a product launch and not
prioritizing process and technical improvements by need, during the development state can cost a company a
value, or other criteria. Such thousand times more. Ex-
agile principles applied to an tending this understand-
integrated BPR and ERP yield ing that systems design in-
significant and early results. cludes human factors and
We need to add Lean Six processes, it is clear that
So while we can decrease our teams need the neces-
our long-term sustainment Sigma certification to the sary skills to design these
costs through the use of processes in their BPR ef-
COTS purchases, we can do current Defense Acquisition forts and major defense
so only if we modify our pro- acquisition programs to be
cesses to match those inher-
ent in the software system.
Workforce Improvement effective. One of the op-
tional continuing education
If we intend to do our part
to decrease the deficient,
Act certifications for courses offered by DAU is
Lean Manufacturing (CLB
our acquisition strategy and 007). The course touches
program management plan information technology and on Six Sigma and provides
must incorporate that ap- familiarity with the terms.
proach from initiation to bet- program management. For more in-depth training,
ter prepare the end users for DoD has adopted Lean Six
the paradigm shift they will Sigma green and black belt
encounter. Furthermore, we certification programs. We
need to market organiza- need to add Lean Six Sigma
tional change for the posi- certification to the current
tive it is—the embracing of Defense Acquisition Work-
the software’s processes and force Improvement Act
the resultant significant sav- certifications for informa-
ing in sustainment costs. To do so, we need to close the gaps tion technology and program management.
in our acquisition skill sets—specifically our skills in process
engineering. DoD 50000.01 requires acquisition teams to adopt inno-
vative practices to reduce time, assuming that the teams
Incorporate DFSS into the Guidebook have the skill sets in process improvement and transfor-
The Defense Acquisition University Defense Acquisition Guide- mation. It also drives program managers to reduce tech-
book does not currently address the need to modify business nology risk and states that the “acquisition of software

Defense AT&L: September-October 2010 12

intensive systems shall use process improvement and per-

Program Managers
formance measures.” But how many program managers
and integrated product teams have the skills to frame their
programs to maximize the benefits of adopting iterative
delivery practices and process reengineering?

Sponsors, program managers, and the integrated product

team members must be able to assess the technological
and business process issues involved with specific ERP
https://pmtoolkit.dau.mil/
applications. It must be stressed that failing to match
business processes with a company’s ERP system can The Program Managers e-Tool Kit provides
derail even the best-run organizations. Managers and the program management resources of the
employees must be able to assess the technological and popular print Program Managers Tool Kit in
business process issues involved with specific ERP ap- a dynamic Web-based format. It covers
plications. acquisition management across all functional
areas and provides leadership and problem-
The military services’ Lean Six Sigma initiatives are per- solving tools.
fectly aligned to be merged with our acquisition frame-
work, with a few subtle tweaks. These initiatives embrace
the classic DMAIC process—or define, measure, analyze, The e-Tool Kit features:
implement, and control phases—typically applied to con- 4 Continual content updates
tinuous improvement. This view attacks root causes of 4 Live policy links
existing processes. Design for Six Sigma (DFSS) attacks 4 Links to informative ACQuipedia articles
a company’s problems during the product and process and related communities of practice
development state. While the tools and order used in
Six Sigma require a process to be in place and function-
ing, DFSS has the objective of determining the needs of
customers and business, and driving those needs into
the product solution so created. DFSS is relevant to the
complex system/product development phase, especially
in the context of a new system. It is process generation
in contrast with process improvement. DFSS strives to
generate a new process where none existed or where an
existing process is deemed to be inadequate and in need of
replacement. DFSS aims to create a process with the end
in mind of optimally building the efficiencies of Six Sigma
methodology into the process before implementation; tra-
ditional Six Sigma seeks for continuous improvement after
a process already exists.

In conclusion, DoD 5000.01 and the Fiscal Year 2010

National Defense Authorization Act require process im-
provement and performance measures in concert with
industry best practices, but stop short of delivering the
value envisioned as they require business processes to
be reengineered prior to the selection and purchase of
a COTS business solution. The COTS technical solution
will have built-in processes that will be expensive if not
impossible to change. We must build business processes Visit
around the capabilities of the technology and not modify https://pmtoolkit.dau.mil/
the technology. We must also train our program managers today to explore this convenient tool!
in Lean Six Sigma practices so they can effectively lead the
team to achieve the most efficient and effective balance
to execute our agency of tax payer dollars.

The author welcomes comments and questions and can be

contacted at cindy.shelton.1@us.af.mil.

13 Defense AT&L: September-October 2010