1. IS 788 10.11 IS 788 [Process] Change Management  Lecture: ERP as process redesign  Presentation and Discussion: The Trouble with Enterprise Software

2. IS 788 10.12 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.

3. IS 788 10.13 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

4. IS 788 10.14 How Modular Software Works

5. IS 788 10.15 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!

6. IS 788 10.16 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.

7. IS 788 10.17

8. 8

9. 9 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)

10. IS 788 10.110 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!

11. IS 788 10.111

12. IS 788 10.112 SAP process documentation  SAP does not use BPMN to document their processes but rather an IS modeling notation from German software engineering guru August- Wilhelm Scheer  Note the level of detail – required for IS development, but dysfunctional for communicating with business domain experts

13. IS 788 10.113 An AND decision An exclusive-or decision

14. IS 788 10.114 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

15. IS 788 10.115 The same car sales process in BPMN

16. IS 788 10.116 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

17. IS 788 10.117

18. IS 788 10.118 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.

19. IS 788 10.119 Treating ERP modules as Actors in a larger process

20. IS 788 10.120 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

21. IS 788 10.121 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.

22. IS 788 10.122 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. 

23. IS 788 10.123 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

24. IS 788 10.124 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

25. IS 788 10.125 SAP in detail ;-)  http://cra.coba.unr.edu/Default.htm http://cra.coba.unr.edu/Default.htm