IS 788
[Process] Change Management
 Lecture: ERP as process redesign
 Presentation and Discussion: The
Trouble with Enterprise Software
IS 788 10.1
1
ERP:
Its origins in modular software
 Software, structured as independent but
cooperating modules to handle common
business functions, has been available since
the late 1960’s.
 By the 1980’s a number of very
sophisticated modular systems were
available incorporating dozens of modules,
from Payroll to Equipment Tracking
 Most of the current ERP vendors, SAP,
PeopleSoft (now Oracle), etc. began at this
time.
IS 788 10.1
2
Where did they go?
 Most of the dozens of modular systems ran
on minicomputers and did not survive the
introduction of the PC.
 In the early 1990’s, integrated enterprise
wide systems began to be touted as the
“next big thing”.
 Surviving modular software companies
began to re-label their product line as ERP
systems
IS 788 10.1
3
How Modular Software Works
IS 788 10.1
4
So….
 Where does ERP fit in a business process
class?
 It is arguably the most common cause of
process redesign in business today.
 But – the thinking is inverted. Instead of
designing a process and building the
support structure – including IT – you start
with the software and modify your
processes to fit.
 Or else!
IS 788 10.1
5
From modules to processes
 ERP vendors heard the academic and
market buzz about “business processes”
and realized that they could cluster related
modules into integrated “processes”
 One of the best at repackaging modules is
SAP.
 With other ERP vendors they claim to have
“enterprise solutions” for entire application
domains.
IS 788 10.1
6
IS 788 10.1
7
IS 788 10.1
8
Best practices
 Leveraging the credibility of multiple
Fortune 1000 installations, they began to
call the processes embodied in their
software “best processes” enacting the
“best practices” of an industry.
 Harmon points out that “. . . of course,
these modules represent “average
processes”.”
 See also Porter’s discussion of excessive
focus on operational effectiveness (Harmon,
Ch. 2)
IS 788 10.1
9
How good is ‘best’?
 If an application (module or process)
represents no strategic advantage for your
organization, then “best practices” are
likely good enough.
 However, not only are the modules
commodities in the truest sense, they are
frequently identical across “industry
solutions”. Compare the SAP insurance
“process map” with the earlier one for
“telecommunications.” Same modules!
IS 788 10.1
10
IS 788 10.1
11
SAP process documentation
 SAP does not use BPMN to document
their processes but rather an IS
modeling notation from German
software engineering guru AugustWilhelm Scheer
 Note the level of detail – required for
IS development, but dysfunctional for
communicating with business domain
experts
IS 788 10.1
12
An AND
decision
An
exclusive-or
decision
IS 788 10.1
13
ARIS vs. BPMN
 Some other BPMN strong points
missing in ARIS notation
 Customer focus
 Difficulty determining which
sequences of actions is performed by
each functional group
IS 788 10.1
14
The same car sales process in BPMN
IS 788 10.1
15
The C-map
 Another SAP process notation is the
‘C-map’
 It does define Actors or Roles, but
lacks flow detail
 Strong points:
 Business benefits column
 Value potential column
IS 788 10.1
16
IS 788 10.1
17
Implementing SAP
 Recall, the logic is inverted
 You start with a well defined process
 Then, clearly define the AS-IS process.
(Many companies have tried to skip this
step, and most have failed dramatically; cf.
HP, ‘Failed’, etc.)
 For best results – to communicate the
changes required to staff – the ARIS
diagrams should be converted to BPMN or
equivalent.
IS 788 10.1
18
Treating ERP modules as Actors in a larger process
IS 788 10.1
19
Some problems
 SAP has incorporated into every
module every “bell and whistle” a
customer has asked for since the
1980’s
 The number of fields for most data
records is staggering
 No company uses all of them and
they are “configured” for each
installation
IS 788 10.1
20
Configuration
 The configuration is accomplished via
integral logic tables so no
programming is required
 However, the program options and
different fields interrelate in an
overwhelming array of possibilities
 Extensive and expensive consulting is
ALWAYS required.
IS 788 10.1
21
Configuration (2)
 Another issue: until the system is
‘configured’ you can’t really model
the process and compare it to your
AS-IS process. Many options will
“disappear” under various
configurations.

IS 788 10.1
22
Program modifications
 If you must tinker, realize that:
 Most core processes are written in an
OO-COBOL variant called ABAP.
 Modifications are time consuming and
costly
 Modifications limit your ability to
upgrade to new versions without
propagating the modifications
IS 788 10.1
23
An ERP success: NESTLE
 18 months just to standardize data
names
 Originally had an impossible deadline
but wisely backed away
 Realized that ERP installation is more
a training and cultural issue than an
technical issue
IS 788 10.1
24
SAP in detail ;-)
 http://cra.coba.unr.edu/Default.htm
IS 788 10.1
25