See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220279047

ERP gap-fit analysis from a business process orientation

Article  in  International Journal of Services and Standards · January 2006

DOI: 10.1504/IJSS.2006.010468 · Source: DBLP

CITATIONS READS

17 462

1 author:

Thomas R. Gulledge
George Mason University
123 PUBLICATIONS   1,092 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Thomas R. Gulledge on 16 August 2017.

The user has requested enhancement of the downloaded file.

Int. J. Services and Standards, Vol. 2, No. 4, 2006 339

ERP gap-fit analysis from a business process

orientation

Thomas R. Gulledge
George Mason University,
Mail Stop 3C6, Fairfax,
Virginia 22030-4444, USA
E-mail: gulledge@gmu.edu

Abstract: The traditional approach to scoping an Enterprise Resource Planning

(ERP) project is based on a modular-oriented functional gap-fit analysis. This
means that the functionality of each ERP module is compared with some
definition of the functional requirements of the receiving organisation. In most
of these consulting engagements, architects are asked to provide an unbiased
analysis of standard software alignment with the business processes of the
implementing organisation. Modules are stovepipes, and a modular-based gap-
fit analysis compares functionality within stovepipes. Business processes1 flow
across the stovepipes; hence, they represent the output/capability delivery of
the implementing organisation. A gap-fit analysis from a business process
orientation provides an understanding of how the software would enable the
end-to-end business, as opposed to comparing static functions within
stovepipes. This paper presents an approach that has been used in several large
organisations to provide a Business Process Oriented Gap-Fit Analysis.

Keywords: architectural planning; business process; Enterprise Resource

Planning (ERP), gap-fit analysis; standard software.

Reference to this paper should be made as follows: Gulledge, T.R. (2006)

‘ERP Gap-Fit Analysis from a Business Process Orientation’, Int. J. Services
and Standards, Vol. 2, No. 4, pp.339–348.

Biographical notes: Thomas Gulledge is Professor of Public Policy and

Engineering at George Mason University and Director of the Policy Analysis
Center within the School of Public Policy. The Policy Analysis Center supports
an extensive research program Extended Enterprise Integration, with a special
emphasis on Back-Office Integration and Supply Chain Integration and
Management.

1 Introduction

Standard software2 defines a class of information systems that are modular (e.g.
Financials, Human Resources, Manufacturing, etc.), but when implemented as a
collection of modules, provides an integrated3 enterprise system. These systems are not
developed in-house, but they are developed by commercial software providers
(e.g. Oracle, Microsoft, SAP, etc.). Hence, the products are sometimes called ‘packaged
software’. The implementing organisation either accepts or rejects the business processes
that can be enabled by the packaged software product. This implies that an analysis is

Copyright © 2006 Inderscience Enterprises Ltd.

340 T.R. Gulledge

required. The business processes in the packaged software must be compared with the
target business processes in the receiving organisation, and an accept/reject decision is
required. A third option is to modify the standard software product, but this option should
be rejected. Modification degrades the benefits of standard software, including the
diminishment of upgrade possibilities, the invalidation of interface certifications, and
possible elimination of product warranties.
If the standard software solution is rejected, then the implementing organisation
searches for another product by a different provider, or a custom software design and
development project is initiated to meet the target business process requirements. If the
standard software solution is accepted, then an implementation project is defined, and the
software is implemented in accordance with a pre-defined implementation methodology.
While implementation methodologies are important in the general project
management literature, the topic has received limited scrutiny in the enterprise systems
literature. This is especially true in the research literature. This is surprising, because in
similar endeavors (e.g. selecting a numerically controlled manufacturing component), the
topic is seen as being critically important. Some of these issues are discussed by Davies
and Kochhar (2000).
This paper describes the high-level steps in a procedure that has been used with
success on a number of large-scale enterprise projects4. The value-added contribution of
our research and development team in this process is two-fold. First, the approach
leverages the most advanced tools, including automated toolsets that support the
methodology. Second, our team has business process representations of the major
standard software products. There is much omitted detail in this description, as gap-fit
analysis is a complex process with every analysis having some unique characteristics, and
this document was not intended to provide that detail. This paper only defines one
general representation of the steps that are required to execute a process-oriented gap-fit
analysis. Depending on the particular analysis at hand, some steps may be omitted or
tailored to align the gap-fit methodology with the particular product or problem that is
under study.

2 High-level steps in the business process oriented gap-fit methodology

The steps are summarised below; followed by a general discussion of how the
methodology is applied. The 23 step process is referenced throughout the discussion that
immediately follows the summary
The general process is the following:
1 Review existing plans/vision – Standard software must be aligned with the value-
adding business processes of the implementing organisation. Planning objectives
define specific targets and time horizons for adding value. Hence, the business
processes should be linked to the objectives in the organisational plan. If a plan does
not exist, then one should be facilitated and documented.
2 Develop the initial scope and establish business process ownership – Determine, as a
first approximation and at a high level, the business processes that should be
included in the packaged software implementation and the managers who are the
responsible decision makers with respect to those business processes. Align the
business process owners with the enterprise governance structure.
 ERP Gap-Fit Analysis from a Business Process Orientation 341

3 Review performance measures and critical success factors – As mentioned in item 1,

planning objectives are ‘linked’ to functions in organisational business processes.
The ‘link’ between an objective and function is called a ‘performance measurement
link’. The target, as defined by the objective, is the success plateau. All performance
measurement links should be documented and managed in a solution architecture5.
4 Review policies, procedures, regulations and job descriptions – Policies, procedures
and regulations ‘bind’ business processes. Many are dated and obsolete and many are
self-imposed. The policies and procedures are revised in light of ‘leading practice’ as
presented in the standard software reference model or any model-based
representation of the business processes that are executable by the software.
5 Document the as-is6 organisational view using an object-integrated methodology
with a supporting automated toolset – Individuals and organisational units are
responsible for executing functions that are embedded in cross-functional7 business
processes. The organisational entities are also responsible for meeting planning
objectives. Hence, the organisational model must be completely documented using a
modern methodology and supporting toolset.8 This view is primarily of interest to
managers, but at lower levels, it is also used to document network topologies and
other landscapes that are of interest to technologists. While this is a critical view,
there is flexibility in the order that it can be developed; that is, relative to the other
as-is views.
6 Document the as-is function view using an object-integrated methodology with a
supporting automated toolset – Function views are important to managers and
technologists. The function tree is a hierarchical decomposition of the things that an
organisation does. While static, this view is essential to understanding the business
processes that an integrated system has to support; that is, if the functions in the
organisation are not supported by the executable functions in the information system,
then a ‘gap’ exists. Hence, the function view is critical for understanding the scope
of the project relative to the scope that is ‘covered’ by the standard software solution.
7 Document the as-is business process view using an object-integrated methodology
with a supporting automated toolset – This is the essential view for understanding
cross-functional business processes. This view documents the business processes,
and the business processes, if documented properly, express the executable business
rules of an organisation. A number of model types could be considered for this view,
but for the level of detail that is required, the event-driven process chain model type
is effective.
8 Link the as-is organisational view to the function view – The object linking formally
establishes function ownership. Since objectives are linked to functions, this link also
formally establishes responsibility for meeting organisational objectives. Critical
success factors and performance targets may also be added via this linkage.
9 Document the as-is data view (at the cluster level) using an object-integrated
methodology with a supporting automated toolset – This view describes, at the
highest level, the sources and destinations of data that enable functions. This view
forms the basis for dataflow modeling, and for specific situations, one may elect to
construct dataflow models for the as-is situation9.
342 T.R. Gulledge

10 Link the as-is data view to the function view – The data clusters are formally linked
to the function objects. This documents, at the highest level, the data requirements,
which demonstrate the integration power of standard software solutions. This can be
contrasted to legacy environments where infrastructures for data integration are often
lacking. Data in the legacy world are often distributed, redundant and incomplete.
11 Document the should-be business process view – This procedure repeats steps five
through ten for the business as described in the policies and procedures manual.
While not always true, it is often the case that the business processes that are
described in organisational documentation do not agree with the processes that are
actually executed in the organisation. This step may be optional for some, but it is
critical if one desires to update the policies and procedures manual to agree with the
solution that is implemented in the standard software.
12 Document the covert business processes10 using an object-integrated methodology
with a supporting automated toolset – Covert business processes are those work-
around processes that are not officially sanctioned by management. While unofficial,
they may be efficient; hence, they should be considered when creating the target
business process architecture.
13 Document the target11 function view using an object-integrated methodology with a
supporting automated toolset – This step documents the function view for the new
desired way of doing business. This view is hypothetical in the sense that non-
existent functions may be included. However, for packaged software, the target
function view is typically a representation of the relevant functions that are
supported by a standard software solution. For example, with mySAP, the target
functions are typically selected from an SAP Solution Map, the SAP Reference
Model, or other representations of the software.
14 Document the target business process view using an object-integrated methodology
with a supporting automated toolset – This step documents the business process view
for the new desired way of doing business. This view is hypothetical in the sense that
non-existent functions, events and other objects may be included. It typically
involves rearranging and organising the target function view into business processes
that address particular laws, regulations, policy or an organisational strategic plan.
15 Document the target data view (at the cluster level) using an object-integrated
methodology with a supporting automated toolset – This step documents the data
view for the new desired way of doing business. This view is hypothetical in the
sense that non-existent data objects may be included. For packaged software, this
step may not be required. If the relevant data is internal to the packaged software
data model, it usually not necessary to complete this step.
16 Link the target data view to target function view – This documents data sources and
destinations at the highest level for the target architecture. This step is conditioned
on the relevance of the previous step. As previously mentioned, this step
demonstrates the power of integration.
17 Link the organisational plans to target architecture—This linking in this step
establishes targets, time horizons and accountability for target business process
 ERP Gap-Fit Analysis from a Business Process Orientation 343

execution. This is a crucial step, because functions that are not linked to objectives
are candidates for outsourcing or elimination.
18 Align revised policies, procedures and regulations with the target views—The
policies, procedures and regulations must be revised so they enable the new business
processes. If policies, procedures and regulations cannot be revised, then the target
business processes are inefficiently constrained.
19 Document the reference architecture from standard software using an object-
integrated methodology with a supporting automated toolset—This step requires
documenting the business processes, functions, data clusters or other required views
that are implied by the standard software. This is more difficult for some vendors
than others. For example, SAP publishes its business processes. Other vendors may
not; hence, the business processes must be constructed. This may require a reverse
engineering of the standard software data models. Kirchmer (1999) is one reference
for this procedure.
20 Perform gap analysis—Compare the target views with the reference views from the
standard software systems. Document and analyse the differences. Unfortunately,
there is no way to automate this process. It requires manual intervention and is
usually executed by experts, or it is completed in small workshops that are
comprised of software solution experts and domain subject matter experts. The key
to success in this step is understand the capabilities of the software product and being
able to relate these capabilities to executable business processes.
21 Align the standard software with target business processes—Document the software
alignment with the target business processes. Analyse the differences. Once again,
this process cannot be automated. The gaps must be identified and documented in the
solution architecture.
22 Accept/reject standard software.
x if accept, go to step 23
x if reject, develop custom solution or best-of-breed solution (which could
eventually become a reference model).
23 Execute implementation procedural model. This is the detailed project execution
model in the form of an extended event-driven process chain.
Many software providers have developed ‘rapid’ implementation models12 to help
consultants reduce implementation cycle times. Examples are such methodologies as
Accelerated SAP (ASAP) and Oracle Fast Forward. The discussion would not be
complete without noting that rapid implementation procedures typically ignore the
possibility that internal business processes may not agree with the processes that are
implied by the standard software13. A critical lesson learned from these rapid approaches
is that an acceptable solution cannot be obtained by configuration alone. A rapid
implementation may be achieved, but total costs are higher, since the standard software
must eventually be aligned with the business processes during the maintenance phase or
during the first reinstall phase. Booker (2000) and Anonymous (2000) address some of
the problems associated with not completing the necessary up-front analysis prior to
implementation and taking shortcuts during the analytical phase.
344 T.R. Gulledge

3 Discussion

Gap-fit analysis is a formal part of most ERP implementation methodologies. Two key
capabilities are essential for executing an effective gap-fit analysis:
x a detailed understanding of certain characteristics and components of the target
organisation
x a detailed understanding of the capabilities of the software products that are
candidates for implementation.
In short, a comparison must be made. The standard software either ‘fits’ the target
organisation, or it does not. If it ‘fits’, then the product may be selected for
implementation. If it does not ‘fit’, then a decision must be made. The software product
could be modified (i.e. enhanced) to fill a gap (not recommended), or the product could
be rejected in favour or a product that provides a better fit. This leads to the most
important question: What is the basis for comparison in an enterprise gap analysis? As
the steps above indicate, the comparison is multi-dimensional, but for the reasons
discussed below, the business process comparison is dominant.
Modern ERP systems execute business processes. In addition, service-oriented
proprietary developed systems are also designed and developed from a business process
orientation. Given this new direction in information system design and development, the
business process view must be considered as the critical view for aligning enterprise
software with target organisations. The business processes of the target organisation must
be enabled by the candidate software solution, or required capabilities or other outputs
cannot be delivered. A conceptual view of the comparison is presented in Figure 1.

Figure 1 Conceptual view of business process oriented gap analysis

Of course, the detail that is required is more extensive than the picture suggests. Business
processes across the organisation must be compared with business processes that can be
enabled by the software, and most importantly, it must happen rapidly. Long and drawn
out modeling initiatives are not tolerable. This requirement means that the organisation
that is executing the gap-fit analysis must understand the business processes that are
enabled by the software. This requires a detailed understanding of the appropriate
 ERP Gap-Fit Analysis from a Business Process Orientation 345

reference models; for example the SAP Business Process Reference Model, Oracle
Business Models, etc. The target architecture must be rapidly constructed, and the gap-fit
analysis must be quickly executed. In our experience, for large and complex projects the
complete process should be completed in 90–120 days.
Another view of the gap-fit analysis is presented in Figure 2. Figure 2 provides some
indication of the detail from an SAP gap-fit analysis. While the figure is conceptual, it
does provide insight into the gap-fit process. In this case the to-be (i.e. target) processes
are modeled using an object-integrated tool, which in this case is the ARIS14 Business
Process Architect. A comparison process is constructed based on the analysts
understanding of the mySAP Business Suite. Objects are pulled from any available
content source, including the SAP Reference Model, SAP Solution Maps, the SAP
Solution Manager Business Process Repository, etc. The assignment of appropriate
consultants to this process is critical, since the task cannot be completed unless the
consultants have a good understanding of the business processes that are supportable by
the mySAP Business Suite. In the next step, the comparison is executed. Gaps are clearly
documented, and unnecessary business process overlaps are flagged for non-
consideration. The architecture repository is updated to document these findings for the
business process view, and all related static views (organisation, function, data, etc.) are
updated in accordance with these findings.

Figure 2 A detailed view of business process oriented gap-fit analysis

As the analysis converges to reveal a complete picture of the ‘coverage’ relative to the
‘gaps’, reports of different types can be prepared for presentation to senior executives or
other decision authorities. A sample report from an SAP gap-fit analysis on a US Army
program is presented in Figure 3. The business process domain that is being analysed is
transportation and distribution planning, which in the as-is world is enabled by a system
346 T.R. Gulledge

known as the Transportation Coordinators’ Automated Information for Movements

System II (TC-AIMS II).
While this is only one possible view of the data, Figure 3 provides critical
information to a senior executive project owner. The project executive can see that
approximately 66% of the business processes may be executed through configuration of
SAP components. Another 12% of the processes are covered through reports that may be
generated through the SAP structure, while 8% of the processes are enabled by
interfacing to non-SAP components. The final 14% of the business processes must be
enabled by custom development work. In this case, experience reveals that this coverage
is quite good for the SAP suite when applied to quite specialised processes, and the
recommendation was to replace the legacy environment with the SAP Business Suite.
Given the different views that are prepared during the 23 step process, it is clear that
many additional reports and graphics could be provided, and not just for planning
purposes. The same Solution Architecture structure could be used for monitoring and
controlling implementation progress throughout the development lifecycle.

Figure 3 Gap-fit analysis summary for an example program

4 Summary and conclusions

Earlier research has argued for the appropriateness of standard software to support
business process improvements (Gulledge and Sommer, 2003; Gulledge et al., 2005). The
consensus remains that ERP is the best alternative for enabling enterprise business
processes, but implementation problems continue to permeate the literature. Our assertion
is that almost none of the problems are caused by the software, but almost all are caused
 ERP Gap-Fit Analysis from a Business Process Orientation 347

by not following good implementation practices. Koch (2002) provides a good summary
of the problems that are caused by poor consultant and implementation management
practices.
It has often been said that an implementation methodology cannot guarantee success,
but you are more likely to succeed while following a methodology than by not following
a methodology. We cannot provide a firm test of that hypothesis, but our practical
experience is that the data supports the assertion. The methodology used in this paper has
been used with success on large and complex projects, and while the steps may vary
somewhat from project to project, the general methodology is logical, and every step in
the process can be tested using data from real projects. Our research program in
enterprise system implementation continues to test each step on each additional project
that we support, and we continue to revise our methodological components based on the
only true form of feedback – working on large and complex projects.

References
Anonymous (2000) Getting Value from Enterprise Initiatives: A Survey of Executives, Boston
Consulting Group, March.
Booker, E. (2000) ‘Enterprise software projects rarely satisfy’, Internet Week, March 28.
[http://www.internetwk.com/story/INW20000328S0004].
Clemmons, S. and Simon, S.J. (2001) ‘Control and coordination in global ERP configuration’,
Business Process Management Journal, Vol. 7, pp.205–215.
Davies, A.J. and Kochhar, A.K. (2000) ‘A Framework for the selection of best practices’,
International Journal of Production and Operations Management, Vol. 20, pp.1203–1217.
Ferguson, R.B. and McCright, J.S. (2000) ‘Enterprise vendors rev fast-rollout efforts’, e-Week,
August 24, Available at: http://www.zdnet.com/eweek/stories/general/
0,11011,2807751,00.html
Gulledge, T.R. (2006) ‘What is integration?’ Industrial Management & Data Systems, Vol. 106,
pp. 5–20
Gulledge, T.R. and Sommer, R.A. (1999) ‘Process coupling in business process engineering’,
Knowledge and Process Management, Vol. 6, pp.158–165.
Gulledge, T.R. and Sommer, R.A. (2003) ‘Public sector enterprise resource planning’, Industrial
Management and Data Systems, Vol. 103, pp.471–483.
Gulledge, T.R., Sommer, R.A., and Vincent, J.P. (2005) ‘An introduction to basic enterprise
resource planning concepts’, International Journal of Management & Enterprise
Development, Vol. 2, pp.204–218.
Ho, C.F., Wu, W.H. and Tai, Y.M. (2004) ‘Strategies for the adaptation of ERP systems’,
Industrial Management & Data Systems, Vol. 104, pp.234–251.
Kangeshige, T. (2001) ‘Oracle fast forwards’, Line56: The Business of e-Business, November 27,
Available at: http://www.line56.com/articles/default.asp?newsid=3170
Kirchmer, M. (1999) Business Process Oriented Implementation of Standard Software, Berlin:
Springer-Verlag.
Koch, C. (2002) ‘It’s time to take control’, CIO Magazine, July 15.
Scheer, A-W (1999a) Architecture of Integrated Information Systems: Business Process Modeling.
Berlin: Springer-Verlag.
Scheer, A-W. (1999b) Architecture of Integrated Information Systems: Business Process
Frameworks. Berlin: Springer-Verlag.
 348 T.R. Gulledge

Notes
1
These business processes are sometimes called End-to-End (E2E) Scenarios or Cross-functional
Business Processes.
2
In the trade literature, standard software solutions are often called Enterprise Resource Planning
(ERP) solutions.
3
Integration is an elusive word with many definitions. Several forms of the definition can be
applied within the context of enterprise software. The definition is not the main subject of this
paper, so the reader is directed to Gulledge et al. (2005) for an analysis of the meaning of
‘integration’.
4
Our most recent implementation of the methodology is for the USAF, as they were deciding on an
ERP vendor to support their logistics business processes.
5
There are many types of architectures for example, policy, descriptive, software, solution, etc.
Solution architectures document how a particular software solution is implemented in a target
organisation.
6
As-is relates the current organisational state i.e. the current way of doing business.
7
An alternative term for cross-functional process is end-to-end process. These are business
processes that flow end-to-end across a particular implementation domain. This flow is across the
modules contained in the standard software as well as systems (legacy and otherwise) that fall
outside of the boundaries of the standard software.
8
We use the Architecture of Integrated Information Systems (ARIS) [Scheer (1999a,b)], since this
method supports all packaged software solutions. The ARIS methodology is supported by the
ARIS Toolset. The ARIS Toolset is rated as the number 1 implementation guidance tool by the
Gartner Group.
9
In general, we advocate a lean approach to as-is modeling. Develop a sufficient as-is
understanding to produce a to-be understanding. While the balance is difficult, one should
produce no more or no less than the minimum required.
10
The existence of covert processes is in most cases a reality, and the problems that can result from
this situation are discussed by Gulledge and Sommer (1999).
11
The target architecture documents the to-be organisational configuration. The idea is to eventually
“migrate” from the as-is to the to-be configuration.
12
See Ferguson and McCright (2000) and Kangeshige (2001) for a discussion about rapid
implementation models.
13
A discussion of some of the organisational and management issues associated with these types of
misalignments is provided by Clemmons and Simon (2001). Additional misalignment issues are
presented by Ho et al. (2004).
14
ARIS is the Architecture of Integrated Information Systems. See Scheer (1999a, b).

View publication stats