Industrial Software Applications: A Master's Course for Engineers 9783110370997, 9783110370980

Citation preview

Rainer Geisler Industrial Software Applications De Gruyter Graduate

Rainer Geisler

Industrial Software Applications | A Master’s Course for Engineers

Author Prof. Dr. Rainer Geisler University of Applied Science Kiel Faculty of Mechanical Engineering Grenzstr. 3 24149 Kiel, Germany [email protected]

ISBN 978-3-11-037098-0 e-ISBN (PDF) 978-3-11-037099-7 e-ISBN (EPUB) 978-3-11-039678-2 Library of Congress Cataloging-in-Publication Data A CIP catalogue record for this book has been applied for at the Library of Congress. Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available on the Internet at http://dnb.dnb.de. © 2015 Walter de Gruyter GmbH, Berlin/Munich/Boston Typesetting: le-tex publishing services, Leipzig Printing and binding: CPI books GmbH, Leck Cover picture: Vladimir Glazkov / iStock / Thinkstock ♾ Printed on acid-free paper Printed in Germany www.degruyter.com

| This work is dedicated to Diane J. Woytek (†) and the Woyteks, my American family.

Microsoft®, Dynamics®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of the Microsoft Corporation. IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390® and OS/400® are registered trademarks of the IBM Corporation. ORACLE® is a registered trademark of the ORACLE Corporation. UNIX®, X/Open®, OSF/1® and Motif® are registered trademarks of the Open Group. HTML, DHTML, XML, XHTML are registered trademarks of the W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under licensed technology developed and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com and other mentioned SAP products and services and their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. MarketSet and Enterprise Buyer are joint trademarks of SAP Markets and Commerce One. All SAP screenshots: © copyright 2014 SAP AG. All Rights reserved. Registered names, trademarks, designations etc. used in this book, even when not specifically marked as such, are not to be considered unprotected by law.

Foreword Welcome. This book and course tries to fill two gaps. First: Due to the globalization of the educative system, there are many master programs in English now in Europe and other non-speaking countries around the world. They are in need of good English modules/ classes for their programs, especially elective courses. This course you are about to experience is a ready-to-use course that has a workload of 5 ECTS (European Credit Transfer System, one Credit worth 30 net hours of work). This book and the additional materials (please check the website) are all you and your instructor should need to organize a class worth 5 ECTS. Second: In teaching Information Technology to students of mechanical engineering, I found most of the books offered not perfectly fit for the target group of my engineers: either they are explicitly focused on software engineers or they turn to a broader audience and strongly emphasize consumer-relevant aspects especially E-commerce. I want to teach mechanical, electrical and other engineers how to cope with being a customer to IT-staff and IT-vendors. In this book, the examples and application are tightly focused on technical personal, especially production engineers. According to my goals above, I am targeting two groups with this book: Master students of Industrial Engineering and Economic Engineering that want to know how the application, management and implementation of modern industrial software applications (should) work. The second group is any kind of working engineer who wants to know how to optimize his or her involvement in industrial software applications, be it as a customer of IT doing requirements engineering or be it applying production planning systems. In order to use this book efficiently, please consider the following preliminaries and requirements: This course runs on a master level, which means you will be required to do some research yourself – not only on the web, but maybe also reading some additional literature. It will be easier for you, if you are familiar with production logistics and organisation, financials, project management and have some base knowledge in using professional industrial software other than office applications on a bachelor level. If you do not have this, you just have to read the according chapters more carefully and research the topics more closely yourself. However, it will not inhibit you from using this book to increase your knowledge efficiently. Read carefully through the chapters, take some notes and then do the quizzes. The quizzes cannot be answered well without having read all text of the according chapter. You will find the solutions in the last chapter. After having successfully

VIII | Foreword

answered the review questions, please fulfil the assignments and deliver them to your instructor as demanded by him or her. Supplementary materials for both student readers and lecturers including an excel file, powerpoint slides, and hints for solutions are available at: www.degruyter.com/books/9783110370980 I would like to thank my wife, Nina, and my daughters, Lena and Marie, for accepting the answer “soon!” to their weekly question “When is your book finished?” for so long. I will join them on the beach now more often. Special thanks to Maria Costa Woytek M.A. for proofreading at a rapid speed and with very professional communication. I am solely responsible for all remaining errors in the text.

Content 1 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.5.1 1.1.5.2 1.1.5.3 1.2 1.2.1 1.2.2 1.2.3 1.2.3.1 1.2.3.2 1.2.3.3 1.3 1.3.1 1.3.2 1.3.3 1.4 1.5 1.6 1.7 1.8 1.8.1 1.8.2 1.8.3

Introduction and Types of Information Systems (IS) | 1 Significance of Information Systems (IS) | 1 Scope of View: What is an Information System and IS-Management? | 1 Environmental Influences | 4 Role of IS: Influence on Operations | 7 Role of IS: Influence on Strategy | 9 Significance of IS: Financial View | 10 Empirical Evidence | 10 The Concept of Total Cost of Ownership (TCO) | 14 IS Impact on the Return of Capital Employed (ROCE) | 16 Types of IT-Systems | 19 The Overall View on Information Systems | 19 Operative Transaction Processing Systems (TPS) | 22 Different Management Information Systems | 26 Management Information Systems (MIS) | 28 Decision Support Systems (DSS) | 29 Executive Support Systems (ESS) | 30 Processes as Dominant Objects of IS | 31 What is a Process? | 33 Definition and Documentation of Processes | 35 Computerization of Processes with Workflows and Workflow Management Systems (WFM) | 40 The Value Chain of IT-Companies | 43 Summary of Chapter 1 | 45 Literature for Chapter 1 | 45 Review Questions for Chapter 1 | 46 Suggestions for Written Exercise or Groupwork for Chapter 1 | 53 Total Cost of Ownership Concept | 53 Operative and Strategic Impact of Information Systems | 54 Research Success and Failure Stories | 54

2 Focus on Production Planning Systems (PPS) | 55 2.1 PPS at the Core of Industrial Manufacturing | 55 2.1.1 Manufacturing Process and Materials Management | 55 2.1.2 Functions of a PPS | 57 2.2 Important Master Data in a PPS | 60 2.2.1 Materials | 60 2.2.1.1 Bill of Materials (BoM) | 63

X | Content

2.2.1.2 2.2.1.3 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.4 2.4.1 2.4.2 2.4.2.1 2.4.2.2 2.4.3 2.4.4 2.5 2.6 2.7 2.8 2.8.1 2.8.2

Categories and Types of BoM’s | 65 How Bills of Material are Used in Production Planning | 69 Work Center | 70 Work Plan (in SAP Called “Routing”) | 72 Production Planning | 74 Quantity Planning | 75 Scheduling of Production | 77 Capacity Planning and Capacity Leveling | 78 Production Control | 82 The Production Order (PO) | 83 Timing of Production Order | 88 Availability Check | 89 Releasing the Production Order | 90 Production Order Control via Manufacturing Execution Systems (MES) | 91 Work Order Completion Message in the ERP-System | 94 Summary of Chapter 2 | 94 Literature for Chapter 2 | 95 Review Questions for Chapter 2 | 95 Suggestions for Written Exercise or Groupwork for Chapter 2 | 104 Exploding BoM and scheduling | 104 MES and Below | 105

3 Integration of Information Systems: Forms, Methods and Concepts | 107 3.1 Introduction: Integration of Information Systems | 107 3.1.1 Direction, Methods and Automation of Integration | 108 3.1.2 Benefits and Risks of Integration | 109 3.1.3 Vertical Integration via Programs in Functional Silos | 111 3.1.4 Horizontal Integration via Programs | 113 3.2 Vertical Integration via Data Warehousing (DWH) | 114 3.2.1 Extract, Transform, Load Data into the Data Warehouse | 117 3.2.1.1 Extraction of Data from Operative Systems | 118 3.2.1.2 Transformation of Data | 119 3.2.1.3 Load and Storage of Data into a Persistent Database | 120 3.2.2 DWH Output: OLAP to Answer Known Information Needs | 121 3.2.3 DWH Output: Data Mining to Find Unknown Patterns and Correlations | 125 3.3 Horizontal Integration of Design and Production | 128 3.3.1 Knowledge Based Systems in (Mechanical) Design | 130 3.3.2 Product Data Management (PDM) and Product Data Lifecycle Management (PDL) | 131

Content | XI

3.3.3 3.3.3.1 3.3.3.2 3.3.3.3 3.4 3.4.1 3.4.1.1 3.4.1.2 3.4.1.3 3.4.1.4 3.4.2 3.4.3 3.4.4 3.5 3.5.1 3.5.2 3.5.3 3.6 3.7 3.8 3.9 3.9.1 3.9.2

Reasons for Implementing PDM | 133 Various Time Reductions by the Use of PDM | 134 Cost Reduction | 135 Quality Improvement | 135 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 135 “Traditional” Means of Enterprise Application Integration Especially Middleware | 137 Database Middleware | 137 Remote Procedure Call (RPC) | 138 Object-Request-Broker (ORB) | 139 Message-Oriented Middleware (MOM) | 139 The Concept of Web-Services | 141 Extending Web-Service Standards for Business Needs | 143 IS-Integration: Towards a Real SOA | 145 Intercompany Integration via Exchange Standards | 147 Electronic Document Exchange Standards (EDI) | 149 Catalogue Exchange Standards | 149 Material Classifications Standards | 150 Summary of Chapter 3 | 150 Literature for Chapter 3 | 151 Review Questions for Chapter 3 | 151 Suggestions for Written Exercise or Groupwork for Chapter 3 | 160 Data Defects and OLAP | 160 CIM and Industry 4.0 | 160

4 ERP Systems: Basic Concepts and the Example SAP | 161 4.1 System Integration via ERP System | 161 4.1.1 Integration of Master Data | 162 4.1.2 Integration of Processes | 164 4.1.3 ERP Architecture | 168 4.1.3.1 History of IT Architecture for ERP Applications | 168 4.1.3.2 The “Classical” Three Tier Client-Server Approach of ERP Systems Architecture | 170 4.1.3.3 Current Developments in ERP Systems | 173 4.2 ERP Systems in the Market | 173 4.2.1 Current ERP Market | 173 4.2.2 Success of ERP Systems Implementation | 178 4.2.2.1 Success of Introduction Projects | 178 4.2.2.2 Success of Use | 180

XII | Content

4.2.3 4.2.3.1 4.2.3.2 4.2.3.3 4.3 4.3.1 4.3.2 4.3.3 4.4 4.4.1 4.4.2 4.4.3 4.5 4.6 4.7 4.8 4.8.1 4.8.2

ERP Components Exemplified by SAP | 183 The SAP Module PP and its Sub-Modules | 184 The SAP Sub-Sub-Module PP-BD-BOM | 185 Modules and Company Functions | 186 Detailed View on Structure of Objects in SAP Modules | 189 Enterprise Structure in Materials Management and Production Planning | 189 Enterprise Structure in Financial Accounting and Controlling | 193 Enterprise Structure in Sales | 197 Using an ERP system by the example of SAP | 199 Basic Look and Feel of the ERP System and Individual Settings | 199 System Roles and Transactions | 201 Access to the Training System | 203 Summary of Chapter 4 | 206 Literature for Chapter 4 | 207 Review Questions for Chapter 4 | 208 Suggestions for Written Exercise or Groupwork | 216 ERP Case Study | 216 Differences Between SAP and Competitors | 216

5 IT-Management | 217 5.1 The Big Figure: IT Service Management (ITSM) | 217 5.1.1 IT Governance | 220 5.1.2 IT Compliance | 222 5.2 IT Strategy and Business Alignment | 224 5.2.1 Basic Business Strategies and Tools – Used for IS strategy | 225 5.2.2 The Relationship Between Business and IT | 227 5.2.3 The Process and Results of an IS Strategy | 229 5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 234 5.3.1 The Macro View and Logic of the ITIL Framework | 234 5.3.1.1 Service Orientation | 235 5.3.1.2 Focus on Processes | 237 5.3.1.3 Benefits and Challenges Using ITIL Processes | 238 5.3.1.4 Structure of the ITIL Framework | 239 5.3.2 Zoom in on Processes in the Stage of Service Transition | 248 5.3.2.1 Transition Process: Transition Planning and Support | 249 5.3.2.2 Transition Process: Release and Deployment Management | 250 5.3.2.3 Transition Process: Service Validation and Testing | 250 5.3.2.4 Transition Process: Evaluation | 251 5.3.2.5 Transition Process: Knowledge Management | 252 5.3.2.6 Transition Process: Service Assets and Configuration Management (SACM) | 252

Content | XIII

5.3.3 5.3.3.1 5.3.3.2 5.3.3.3 5.3.3.4 5.4 5.4.1 5.4.2 5.4.2.1 5.4.2.2 5.4.2.3 5.4.2.4 5.4.2.5 5.5 5.6 5.7 5.8 5.8.1 5.8.2

Zooming in on the ITIL Service Process of Change Management (CM) in the Stage of Service Transition | 253 Processes of Change Management | 255 Roles and Institutions of Change Management | 260 Tools and Concepts of Change Management | 262 Interfaces of Change Management | 266 Other Frameworks and Approaches | 269 Cobit as a Framework for ITSM and IS Compliance | 269 IT-Controlling and Budgeting | 271 Functions and Processes of IT-Controlling | 271 Tools of IT-Controlling | 272 Portfolios as a Tool of Strategic Controlling | 273 Key Performance Indicators (KPIs) as Tool of Operative IT-Controlling | 274 Management Accounting and Transfer Pricing for IT Services | 276 Summary of Chapter 5 | 281 Literature for Chapter 5 | 282 Review Questions for Chapter 5 | 282 Suggestions for Written Exercise or Groupwork for Chapter 5 | 297 ITIL Process of Problem Management | 297 IS Governance and Strategy | 297

6 Planning and Preparing IS Development | 299 6.1 The Software Development Cycle | 299 6.1.1 Basic Cycle of Software Development | 301 6.1.2 A Broad Model of IS-Development | 303 6.1.3 “Classical” Approaches of Structuring Software Development | 305 6.1.3.1 The Waterfall Model | 306 6.1.3.2 Spiral Model and Prototyping | 308 6.1.3.3 Rational Unified Process (RUP) | 309 6.1.4 Agile Concepts | 311 6.1.4.1 Criticism Against Traditional Process Models and the Agile Manifesto | 312 6.1.4.2 Use of Agile Methods in Business Today | 313 6.1.4.3 The Dominant Agile Process Model: Scrum | 318 6.2 Business Plan and Outsourcing Decision | 321 6.2.1 The Business Plan – is it Worth it? | 321 6.2.1.1 Converting Technical and Organizational Impact into Financials | 324 6.2.1.2 Determining Feasibility and Data Sources of Alternatives | 329 6.2.1.3 Writing the Business Case and Using Evaluation Tools | 331

XIV | Content

6.2.2 6.2.2.1 6.2.2.2 6.2.2.3 6.3 6.3.1 6.3.1.1 6.3.1.2 6.3.2 6.3.2.1 6.3.2.2 6.3.2.3 6.3.3 6.3.3.1 6.3.3.2 6.4 6.4.1 6.4.2 6.4.3 6.5 6.6 6.7 6.8 6.8.1 6.8.2 6.8.3 6.8.4

A Basic Decision in the Strategy Phase: Outsourcing | 338 Goals and Forms of IT-Outsourcing | 338 Evaluating the Outsourcing Decision and Preparation | 344 Service Level Agreements as a Frame of Managing Outsourcing Relationships | 349 Requirements Engineering (RE) | 353 Preparation and Management of Requirements Engineering | 354 Goals and Scope of Requirements Engineering | 355 Stakeholders’ Interest as Base of Requirements Engineering | 356 Organizing and Executing Requirements Engineering | 358 The Requirements Engineering Process | 358 Creating Information for Requirements Engineering | 359 Requirement Workshop | 360 Types, Documentation and Management of Requirements | 362 Types of Requirements in a Specification Document | 362 Writing a Specification Document | 364 Selecting and Contracting Vendors | 368 Preparation and Preselection | 369 Scoring Model | 373 The Bid, Contract and Legal Matters | 377 Summary of Chapter 6 | 378 Literature for Chapter 6 | 379 Review Questions for Chapter 6 | 379 Suggestions for Written Exercise or Groupwork for Chapter 6 | 393 Scoring Model for Vendor Selection | 393 Software Creation Process Models | 394 Create a “Software Requirement Specification” for a PPS System | 394 Write a Business Case | 394

7 Creating and Introducing IS | 395 7.1 Systems Modelling, Design and Programming | 395 7.1.1 Modelling Systems and Architecture | 396 7.1.1.1 Behaviour Models and Diagrams | 398 7.1.1.2 Structure Diagrams | 400 7.1.1.3 Systems Architecture | 403 7.1.2 Programming and Customizing | 407 7.1.2.1 Software Programming | 407 7.1.2.2 Customizing Standard Software like ERP Systems | 407 7.1.3 Special Aspects of Project Management for Creating IS | 410 7.1.3.1 Project Planning and Estimation Techniques | 410

Content | XV

7.1.3.2 7.1.3.3 7.1.3.4 7.2 7.2.1 7.2.1.1 7.2.1.2 7.2.1.3 7.2.2 7.2.2.1 7.2.2.2 7.2.2.3 7.2.3 7.2.3.1 7.2.3.2 7.2.3.3 7.2.3.4 7.3 7.3.1 7.3.1.1 7.3.1.2 7.3.2 7.3.2.1 7.3.2.2 7.3.3 7.3.3.1 7.3.3.2 7.3.3.3 7.4 7.5 7.6 7.7 7.7.1 7.7.2 8 8.1 8.2 8.3 8.4 8.5

COCOMO as a Model of Parametric Estimation | 412 Project Organization and Team Members | 416 Controlling and Risk Control in Software Projects | 418 Testing and Quality Assurance | 423 Quality Management as a Frame for Testing | 423 Defining Software Quality | 424 Quality Systems | 424 Capability Maturity Model (CMM) | 426 Different Areas and Levels of Tests | 428 Unit Testing | 430 Systems Testing | 433 Release and Acceptance Testing | 435 Processes and Tools for Testing | 438 Organizing and Planning Tests | 438 Creating and Administrating Test Cases | 441 Managing the Bug Life Cycle | 443 Reporting of Test Advancement | 445 Preparing the Organization for Introduction | 446 Planning, Executing and Guiding Organizational Change | 447 Business Process Reengineering and Management | 448 Managing Organizational Change | 451 Training for New Information Systems | 453 Designing the Training Plan | 453 Measuring Training Success | 455 Introducing New or Improved Information Systems | 457 Go Live Readiness for Implementation | 457 Conversion Strategies for Implementation | 459 Stabilization and Early Live Support | 460 Summary of chapter 7 | 463 Literature for chapter 7 | 464 Review Questions for Chapter 7 | 464 Suggestions for Written Exercise or Groupwork for chapter 7 | 480 Creating a Test Case | 480 IT Project-Success | 480 Solutions for Review Questions | 481 Review Questions for Chapter 1 | 481 Review Questions for Chapter 2 | 481 Review Questions for Chapter 3 | 482 Review Questions for Chapter 4 | 482 Review Questions for Chapter 5 | 483

XVI | Content

8.6 8.7

Review Questions for Chapter 6 | 483 Review Questions for Chapter 7 | 484

List of Figures | 487 List of Tables | 495 Index | 499

1 Introduction and Types of Information Systems (IS) This chapter aims to show the significance of Information Systems in modern industrial companies, both organizationally and financially. The vast number of existing IS are categorized into certain types of IS. Finally, an overview of the nature of processes and ways of documenting them is given, since processes are the main object of IS. After reading this chapter, you should be able to … – … explain the advantages and risks of IS on the company and industry levels. – … describe the IT-productivity paradox and its possible reasons. – … use basic concepts of strategic analysis in the context of IS. – … apply the TCO concept on a simple scale. – … structure operative IS according to company function and level. – … distinguish different management systems. – … name the characteristics of processes with practical examples. – … spot the right notational model for drawing processes if you see a process drawn in a certain style. – Explain the nature, functions and automation levels of workflows.

1.1 Significance of Information Systems (IS) 1.1.1 Scope of View: What is an Information System and IS-Management? Before focusing deeply into the topic of Information Systems or Information Technology, we should step back for a moment and create a common understanding of our subject matter subject matter (so as not to end sentence with preposition). The following statements can be read in many basic works about information technology. There also might be some authors who disagree. However, this does not matter since a definition is never “true or false”; the only thing you can expect is that a definition is logical, consistent and accepted in the context used. So let’s agree on the following things: Information Systems are not identical with computers. Paper, Pencil and an agreed way of writing 1 down cash in, cash out, accounts receivables and so on for a medieval merchant might also be called an “information system”. Of course, the power and ease of use of computers make them the most obvious choice for processing information (digital). However, Technology must clearly be subordinate to a) the “real thing” (merchant sales and trade) and b) the concept of his documentation (here: bookkeeping).

2 | 1 Introduction and Types of Information Systems (IS)

Information systems always include or affect organizations (people), management (planning, controlling and motivating the organization) and an applications system. An application system consists of enterprise processes (e. g. like sales), data (e. g. like customer data), and an IT-infrastructure (e. g. desktop computers and servers) and application software. Application software (like an office package) finally is colloquially called “software”. Keep in mind this hierarchy of terms: Application software is part of an application system which is part of an information system (IS).

Information System Organisation

Management

Applications System Operative tasks/processes Application Software

Data

IT-Infrastructure

Fig. 1.1: The Relationship Between Information System and Applications System (Based on Laudon/Schoder (2012) p. 18)

The application system consists of operative tasks and processes that will support the IT-infrastructure, the applications software, and the data which it needs to complete its tasks. An information system additionally includes the organization and management issues and is individually specified to the company in which it is applied. If we zoom in on the applications system it always has some common features, no matter who provides it or how its architecture is set: somehow there must be the possibility for data-input, secondly something will be done with the data (like being computed), and finally, there will be a way to get the results out of the machine onto a screen, a printer or for further processing in another application system. All of this basic process is not happening in an isolated manner, but has close connections to the environment. Input might come from, and output might go to, suppliers, customers, regulatory agencies and so on.

1.1 Significance of Information Systems (IS) | 3

Organisation Suppliers

Customers Environment

Input

Process Classify Arrange Calculate

Output

Feedback

Regulatory agencies

Stockholder

Competitors

Fig. 1.2: Features of an Application System (Based on Laudon/Schoder (2012) p. 18)

An application system contains information about a company and its surrounding environment. Three basic activities – input, processing and output – produce the information organizations need. Feedback returns the output to appropriate people or activities in the organization to evaluate and refine the input. Environmental actors, such as customers, suppliers, competitors, stockholders and regulatory agencies, interact with the organization and its information systems. This book will focus on different, selected aspects selected from all three steps; necessarily there will be some omissions left for further investigation on your own. If you would like another separation of the lectures, you may separate them by using IS (1–4) and managing IS (5–7). Now that the hierarchy of terms has been made explicitly clear, please be prepared that the use of 1 the terms will be a little more relaxed. Most of the time we will be talking about an application system, but it might be called IS or IT and sometimes software. However, the topic of discussion will be very clear from the context.

4 | 1 Introduction and Types of Information Systems (IS)

1.1.2 Environmental Influences The fact that digital IS (software on computers) has been growing during the last 50 years is obvious. The growth might even be considered exponential. It depends, of course, on how you would go about measuring it. Every growth has two drivers: technology to satisfy a market need and a need to improve business or life. The improvement of the technology can, for example, be viewed by “Moore’s law” (please research on your own). Your Smartphone in the year 2014 has many times more computing power than the computers of the Apollo Mission. However, this lecture wants to follow a strict market-driven view. So these are the four changing business conditions that make the use of IS more likely and more intense: Table 1.1: Four Changing Business Conditions (Based on Laudon/Schoder (2012) p. 8) Globalization  Management and control in a global market  Competition in the world market  Global working groups  Global supply systems

Increasing significance of the information economy  Knowledge- and information-based market economy  Knowledge-intensive products and services  Knowledge will be the essential productive and strategic resource  Information-intensive variant management of products  High demand of qualification of the employees

Changing of organization structures  Less hierarchy, more even organization structures  Decentralization  Higher flexibility  Independent of location  Low cost of transaction and coordination  Delegating responsibilities to operators  Cross-company cooperation and teamwork Development of the cross-linked company 

  

Electronic communication, media supported relationship with customers, suppliers and employees Processing of important processes through electronic networks Electronic administration of important items of company property Fast detection and reaction to changes in the company environment

These are some factors that foster the growth and use of IS in organizations. On the company level, the influence is mutual. The growing use and volume of IS has also shown a growing impact on organizations and their management.

1.1 Significance of Information Systems (IS) | 5

1.

2.

Information Systems

3.

Information Systems

4.

Information Systems

Technical changes

Control options of executives

Core activities of the company

Time

1960

1980

1950

1970

1990

Information Systems

Suppliers, customers outside of the company

2000

2005

Fig. 1.3: IS in Organizations (Close to Laudon/Schoder (2012) p. 32)

The figure above shows the history of IS: 1. The first systems were simply machinery like others. They had to be maintained replaced and so on, which was also quite easy to do without influencing the rest of the company. 2. In the 1970s, the use of IS changed the possibilities and the behaviour for management. Planning and controlling via IS became a new option. 3. In the 1980s and 1990s, the core processes of companies were heavily supported by IS. For some companies, it is hard to imagine to even venture operations without IS, e. g. telecommunication enterprises like Vodafone, etc. 4. The current state of affairs in many companies is the interconnected enterprise. In all functions and with suppliers, customers and partners, the web has enabled permanent “Real-Time” connections. The interconnectedness of a company shows in its internal organization and its relationships to business partners outside the company, as the following figure visualizes.

6 | 1 Introduction and Types of Information Systems (IS)

Factories • Just-in-time Production • Continuous replenishment • Production planning

• • • •

E-Business

Distant offices and working groups Coordination of plans and guidelines Support of groupworking processes Electronic communication Material planning

Business associate • Common design • External procurement

• • • • •

Customers Online-marketing Online-sales Customized products Customer service Automated sales processes

E- COMMERCE

Suppliers • Procurement • Supply chain management

Fig. 1.4: IS The Cross-Linked Company (Close to Laudon/Schoder (2012) p. 37)

The phenomena shown above are widely known from everyday professional and business experience. 1 Summary: IS are not just tools that may be arbitrarily used or not. They have established and entangled themselves into business and business relations. For most of us, it is not even an option to ignore the possible implications of IS.

1.1 Significance of Information Systems (IS) | 7

1.1.3 Role of IS: Influence on Operations So far, there has been talk of “growing influence” of IS. This is highly plausible but needs to be logically explained, and of course, some empirical evidence shown as well. The more precisely stated question must be: 1. What influence does IS have on the strategic position and the operative everyday business in terms of real changes (e. g. the possibility to look up customer data more easily) 2. How do these influences translate into a change of real world Key Performance Indicators (KPIs) 3. And bottom line: How does the change of real world KPIs translate into improvement of financials? A good way to find out all influences is to exercise the three steps above for every part of the company’s value chain. This is the necessary overall view, needed to evaluate decisions on IS in everyday life. Of course, new or better IS are not “magic bullets” that will singlehandedly improve every aspect of societies and companies alone and without any cost. The following figure shows just a few potential benefits and risks of IS on the macro-level of societies and economies: Table 1.2: Positive and negative impacts of IS on general and society level (Close to Laudon/Schoder (2012) p. 45) Advantages of information systems  Information systems are faster at calculations and paper work than humans  Information systems can help companies to gain more knowledge about preferences and buying habits of their customers  Information systems provide new abilities through services like cash points, telephone systems and computer-controlled aircraft and terminals  Information systems have enabled progress in surgery, radiology and patient monitoring  Information is distributed immediately to millions of users in the whole world through the internet

Disadvantages of information systems  Information systems could cause reduction of jobs because of the automation of tasks which previously were executed by humans  Information systems could enable companies to collect personal data and therefore to violate the data privacy  Information systems are used in so many areas of everyday commodities, that system failures could cause traffic congestions and closings of business, which could bring whole urban districts and communities to a standstill  Information systems could cause stress and other health issues for intensive users  It is difficult to enforce copyrights for digital media, e. g. software, books, articles or other intellectual property on the internet.

8 | 1 Introduction and Types of Information Systems (IS)

On the level of single companies, there are numerous possible advantages of the use of IS. There are many different companies in different situations and many types of IS. When combining these parameters, there might be a broad number of cost and benefit categories, so we will only be able to name a few of them without a more individual analysis. Most dominantly claimed are the following advantages/hopes laid in IS by companies: + Higher productivity and efficiency: Doing more business with only marginal more cost + Faster operations: Doing the same processes (like manufacturing or sales) in less time. + Better quality: Fewer mistakes in administration and manufacturing leading to higher employee and customer satisfaction and motivation + More management transparency: More and better information for planning, organizing and controlling and a better “grip” on operations + More flexibility in sales, marketing and manufacturing On the other hand, some downsides of the use of IS are claimed frequently in literature and practical experience: – Dependency on technology – Inflexibility due to fixed technology: IS dominate the real business – IS are costly and hard to manage – Errors in IS often cause immediate large scale damage due to speed and automation of processes. The sources cited in this book provide many more examples and real-life success and failure stories. In books and real life-stories, some points are cited as advantages and disadvantages at the same time, which seems paradoxical. The simple explanation lies within the following premise that must be kept in mind at all times: 3 IS are just tools. Any tool correctly applied might cause strategic and operational advantage. A tool incorrectly used will do damage. As American folk wisdom goes: “A fool with a tool is still a fool”.

Most problems with IS should therefore be attributed to the faulty introduction and use of IS. Ultimately, all problems with IS can be traced back to management faults. Management is in command of using these awesome tools the right (or wrong) way. It is impossible and not efficient to try to group all of these advantages and risks in an abstract way. A more practical and structured way would be performing these two steps: 1. Choose a (broad) measurement system like a Balanced Scorecard (BSC) or a scheme like Return on capital employed (ROCE – see below).

1.1 Significance of Information Systems (IS) | 9

2.

Check all parameters of these systems on how they are affected by introducing or changing an information system

This is exactly what we will do in chapter 1.1.5.3.

1.1.4 Role of IS: Influence on Strategy This chapter refers to models and terms of strategic management that should be known to you from 1 previous classes or programs. If not, they can easily be retrieved in any introduction to strategic management or on the web.

Between the macro view of society or economies and the micro view of company level, there is the industry level, in which strategic decisions of companies are made. Strategy theory specifically offers two classical tools for assessing the influence and significance of IS (or any other technology or development) for an industry and its players. Both were first introduced by Michel S. Porter and have grown into common knowledge about IS. The “Five Forces Model” gives a checklist for assessing the attractiveness of an industry. Additionally, it is used to assess the impact of any given new development (like IS) on a certain industry. So, by definition, it hardly makes sense to paint a figure of the influences of all the economy in general; you would have to choose your specific industry or business to assess the impact of IS. The following link shows the use of the five forces model to assess the influence of computerization of the auto repair shop “industry”: http://www.toriangroup.com/Default.aspx?tabid=321 The computerization of an industry and the surrounding partners mostly changes the power equilibrium of the players involved. One possible conclusion of such analysis could be that this industry is becoming generally less attractive. The company manages to excel compared to its competitors, or escapes this hardening environment by restructuring itself, or the conclusion might be: Get out of that business! This was the answer for several travel agencies that were not able to provide value-added services compared to the new online competitors like expedia.com. One level below the business portfolio that shows businesses of a large company as dots in the portfolios like the Boston Consulting Group Portfolio (remember: Cash cows, poor dogs …), there lies the single strategic business units (SBU’s), which are represented by one dot in the portfolio. Inside the SBU’s, when IS influence the so-called generic strategies, a company should choose: Cost-leader, differentiation or niche strategy (see 5.2.1).

10 | 1 Introduction and Types of Information Systems (IS)

Please be aware that these “classical” generic strategies (again first introduced by Michael S. Porter) are amended by recent research and theory in strategic research. In the first place, it is the strategy of outpacing via a coordinated sequence of gaining cost-advantages and differentiation advantages talking turn. Secondly internationalization has extended the niche theory by the model of the “HiddenChampion”: small niche players, however dominating that niche globally. No matter what strategy an SBU is following: IS has a deep influence on any kind of strategy. For example, the so called “outpacing strategy” (please research this term) is often maintained by superior manufacturing techniques and logistics enabled by IS. On the other hand, IS have to be in line with the chosen generic strategy. Imagine the different IS of a food-discounter (= cost-leader strategy) and an exclusive, very refined shop with a catering service (= differentiation strategy). Their businesses do have very different needs and so their IS will have to satisfy those exact needs. Cost advantages and differentiation advantages can be found in every part of the value chain. And every part of the value chain is affected and supported by IS as you see in chapter 1.2.2.

1.1.5 Significance of IS: Financial View The influence of IS seems very plausible by everyday experience; however it is also measurable. Ultimately all real influences in a business will somewhere show up in the financials. This chapter explores some empirical evidence of the significance of IS and discuss issues of measuring financial impact on IS decisions.

1.1.5.1 Empirical Evidence The following figure shows the rise of investments in assets (Machinery, buildings, information technology) of companies. The rise of IS investment along the rise of all assets is accompanied by a growth in share. While in 1980, 32 % of all investments were IS related, in 2007 that number was 51 %. Of course, these overall numbers must be looked at in more detail: in this survey, “Information Technology” is used in the broadest sense and the numbers might vary considerably among different industries like manufacturing or financial services. However, the rise is undisputable and it is also remarkable, in that IS investments are not always need driven and strictly logic. Please note the peak in the “new economy” craze and the slowdown in 2002 and 2003.

1.1 Significance of Information Systems (IS) | 11

1200 1000

Investment (billions) Total Investment

800 52% 600 400 IT Investment 200 30 % 0 1975

1980

1985

1990

1995

2000

2005

2010

Fig. 1.5: Rise of Investments in Assets (Based on Laudon/Laudon (2012), p. 8.)

Of course, every investment is expected to pay off somehow. As described in chapter 1.1.3 one of the main improvements expected from IS-investment is an increase in productivity. This is especially true in the service sector like financial services or generally in administration since IS is the main form of technical support. Looking at those numbers at the end of the last century, researchers and managers alike pointed to an alarming phenomenon: the relation of productivity and IS investment is neither fixed nor clear. In the following figure, many companies (represented as single dots in the matrix) with low IS investment and high productivity and others with high IS investment and low productivity prove a strict correlation wrong.

12 | 1 Introduction and Types of Information Systems (IS)

4.0

2.0 Productivity (relative to industry average)

1.0

0.5

0.25

0.12

0.25

1.0

4.0

8.0

IT Stock (relative to industry average)

Fig. 1.6: Relation of Productivity and IS Investment (Based on Brynjolfson/Hitt (1998), p. 52)

Besides this weak financial correlation, the paradox also raised questions from a technological point of view: why has the exponential rise in computational power (please research the term “Moore’s Law” for detailed information) not led to an equal rise in productivity? In fact, why is the relation not even close? This question has been discussed by the name of the “IT-productivity paradox” and begged for explanation. With empirical data and some plausible speculation, researchers came up with four answers (Brynjolfsson/Hitt 1998, pp. 51–54) to why computers haven’t measurably improved productivity: 1. Measurement error: Outputs (and inputs) of information-using industries are not being properly measured by conventional approaches. 2. Lags: Time lags in the pay-offs to IT make analysis of current costs versus current benefits misleading. 3. Redistribution: Information technology is especially likely to be used in redistributive activities among firms, making it privately (that means in single companies) beneficial without adding to total output of an industry. 4. Mismanagement: The lack of explicit measures of the value of information makes it particularly vulnerable to misallocation and overconsumption by managers.

1.1 Significance of Information Systems (IS) | 13

The interesting details of this discussion would lead us off the path, but of course, point 4 is of great importance for us and supports the statement made in the beginning: IS are not magic bullets that will solve all problems by themselves, they are merely a tool. It demands full management attention and organizational integration in order to reap the productivity advantages companies desire. Research on the IS-paradox was focused mainly on investments in IS. Of course, IS not the only cause investment that shows up in the balance sheet, but also a lot of expenditure that will show up in many different lines of the profit and loss statement According to the Gartner Group (2011) IS uses up 1 % to 6 % of the total revenue of company, depending on the industry they are operating in.

Database Average

4,2%

Banking & Finance

6,7%

Professional Services

5,8%

Health & Care

4,8%

Telecommunications

4,6%

Insurance

4,5%

Information Technologies

4,3%

Media

4,2%

Education

4,1%

Transportation

3,7%

Hospitality & Travel

3,3%

Pharmaceuticals

3,0%

Electronics

2,4%

Utilities

2,3%

Consumer Products

2,3%

Manufactoring Retail Chemicals Food & Beverage Processing Energy Construction & Engineering Metals & Natural Resources

2,2% 1,8% 1,7% 1,6% 1,5% 1,5% 1,2%

Fig. 1.7: Percentage of Revenue Spent on IS in Various Industries (Based on Gartner (2011), p. 22)

14 | 1 Introduction and Types of Information Systems (IS)

Of course, there are several measurement problems which are discussed in the annual Gartner Report “Gartner IT Key Metrics Data”, which can be obtained by Gartner but is also sometimes available on the web as a summary.

1.1.5.2 The Concept of Total Cost of Ownership (TCO) The TCO concept was developed by Gartner Group 1987, on behalf of Microsoft, in order to show that seemingly “free” open source software is not free of cost at all. This marketing-driven research has led to interesting insights for anyone concerned with the cost of IS. Focusing on the price aspect, companies are easily misled by the illusion that investment in software and hardware or the direct cost of software and hardware licenses are all there is to IS cost. The main conclusion from the TCO view might be summarized like this: the price of software and hardware and the direct cost for maintenance and upgrades are but a small part of the real total cost of ownership of an IS! The reason for so much cost that is hidden from first sight lies within the structure of accounting, which is the base of all cost documentation. All numbers for calculating investments and controlling cost ultimately stem from the accounting books where all bills are documented. However, accounting just stores information about bills like “personnel expenditure”, “Consulting fees”, “Software licenses” as is stated on bills. It does not know necessarily what these consulting fees or personnel expenditures are for. So in order to find out the real TCO of software, a company controller might need to explore and revise all accounting positions, since there is no standard reporting coming out of accounting giving her the desired information about the TCO of software. Research for the following graph has done exactly that, and points to the conclusion: only 16 % of all IT-related investment and only about 30 % of the running cost are visible at first sight.

1.1 Significance of Information Systems (IS) | 15

Distribution of annual projects costs

Distribution of annual running

(investments) in IS

operating costs for IS

Facility

Hard-

2%

ware

Soft-

7%

ware

Transfer 2%

9%

External

Further

Services

Hard-

16%

ware

Software 10%

17%

Staff

Server

(inter-

13% Staff external 31%

nal) 28%

Staff internal

Facility

External

33%

2%

Services

Transfer

16%

Staff external 11%

2%

Fig. 1.8: Investments and Running Costs (Based on Pfüller (2005), p. 19)

So how can management or controlling structure find out the TCO for a certain business unit, or a specific IS, that needs to be evaluated? The TCO researchers from Gartner suggest the structure in the next figure. It seems especially difficult to assess the indirect cost on the right side of the figure, especially so-called opportunity cost. A popular phenomenon in hidden ITcost is the “hey Joe” effect as part of the “self-help”-cost: Example: E.g. employee Jane has a problem with her software and does not want to call the regular support. Instead she asks her colleague Joe who is good at fixing and explaining IS, even though that is not his real job: “Hey Joe, could you please help me with the system?” Time and price of Joe’s loss in productivity is quite difficult to calculate, but undoubtedly is there.

16 | 1 Introduction and Types of Information Systems (IS)

Total Cost of Ownership (TCO) Direct Costs

Hard- and Software

Indirect Costs End User Activities

Operations

Administration

Technical Support

Administrative and financial business

Software for User processes

Planning- and Processmanagement

Training of IT-department staff

Outside help

Hardware for IT department

Database management

Training of end user

Data Administration

Hardware for User processes

Software for IT Department

Helpdesk

Non-work related use Self-help

Down Times

planned down times unplanned down times

Customisation of Software Training measures

Fig. 1.9: Total Cost of Ownership

This structure was also used to develop calculation tools for the TCO, which are freely available for everybody who needs it. One example is http://www.tcotool.org/ Modern cost-accounting systems which employ the construct of “cost centers” make it easier to catch even exotic IS-cost by attributing every bill to a cost center, like “IS”. Having gathered this information in the first place, they allow filtering cost-positions for the one with an “IS” marker on it. Opportunity cost, however, remains a non-automatable task to discover. 1 Summary: Whenever evaluating an IS-, consider as much of the TCO possible to paint an accurate figure.

1.1.5.3 IS Impact on the Return of Capital Employed (ROCE) It was demonstrated that IS has a wider influence on cost than it seems at first (naïve) sight. The net benefit of an IS can be expressed by the simple formula “Improvement of non-financial KPIs minus TCO”

1.1 Significance of Information Systems (IS) | 17

Ultimately, there has to be an approach that translates all influence and TCO considerations into a unified financial view on which management decisions can be based. From the perspective of chief executives, the question of whether an IS is “good” or “bad” for the company is easily answered, however difficult to calculate: If the Return on Capital Employed (ROCE) will improve (rise) by an IS investment the IS is good for the company; if not, it is bad. It is a typical problem of IS specialists to focus only on real-life advantages of an IS like “quick access” or “integrated system” and not going all the way to explain the real world KPIs and, ultimately the financial KPIs that are improving. Management will ask “So what?” until they reach the realm of financial KPIs. After all: what use is a quick access if not for serving customers better, so they will spend more money on our company? The ROCE is a widely used financial Top-KPI that can systematically and mathematically be broken down in its single components until it reaches real life parameters. By the way: ROCE is also on top of the Balanced Scorecard, which allows for translating real-world changes into top-financial KPIs. The following figure shows the mathematical breakdown of ROCE. If you are not familiar with the term “Return on Capital Employed (ROCE)” please research yourself! 5 It is a very important performance measurement in companies.

18 | 1 Introduction and Types of Information Systems (IS)

Sales Price

Profit

ROCE 10 %

Turnover

x

-

Quantity of sales Purchase price

Costs Variable costs -

x

+

Taxes

Fixed costs

Purchase volume

÷ Invested capital Fixed capital

+ Net Working

Inventory

+

Accounts receivable trade

+ Liquid assets

-

Accounts payable trade

Fig. 1.10: Performance Evaluation with Return on Capital Employed

Apply any IS introduction and its impact to the different levers of the ROCE scheme above and see whether ROCE will ultimately rise or fall. Some practitioners in the IS business often talk about the “RoI” of an investment in IS. This basically is the same concept we just discussed: the overall payoff of IS. Please refer to a book about controlling or corporate finance to see the precise differences between the two terms. Of course, ROCE does not cover two important areas: strategic KPIs like market share and customer satisfaction are not integrated. Secondly, there are reasons for using IT that do not translate into a ROCE calculation, e. g. a new federal law about traceability of raw materials might lead to a non-negotiable necessity for a new system. Without it, the company no longer would be able to operate legally. 1 Summary: ROCE-thinking helps to assess the total financial impact of an IS and ties IS to the dominating overall goals of a company.

1.2 Types of IT-Systems | 19

1.2 Types of IT-Systems This chapter serves two purposes: A) It gives a systematic approach to classify the huge variety of IS employed in companies B) It shortly describes some important IS for business. Especially systems that will not be detailed in further lectures will get a little more space here. All these systems are focused on business IS from a business view. There are more IS like e. g. the CNC programming of milling machine tools and the transmission technology of wireless devices. These systems and hardware are just briefly mentioned and can be detailed in further study offline in order not to overburden this chapter.

1.2.1 The Overall View on Information Systems The classification of IS is usually illustrated by a pyramid which corresponds somehow to company hierarchy. On every level there are different needs for information and related IS support. Since IS are just tools to satisfy these needs, they will be classified according to their users.

20 | 1 Introduction and Types of Information Systems (IS)

System on Strategic level

Systems on management level

Sales management Sales area analysis

Systems on operative level

5-year 5-year Personal Profit turnover business planning planning forecast plan

Order Management

Sales and Marketing

Inventory analysis Production planning

Materials administration

Annual budget planning

Executive support systems (ESS)

Training costs monitoring

Productivity analysis

Personal accounting and accounts payable

Manufacturing Finance and and Production Accounting Functional areas

Management Information Systems (MIS)

Decision Contract support Costs analysis systems (DSS)

Personal Operative administration systems (TPS) Human Resources

Fig. 1.11: Classification of IS (Close to Laudon/Schoder (2012), p. 435)

The first layer is the “real business” of sales, production, accounting, Human Resources and so on. IS support them by processing their transactions (sales, production lots and so on) “better” than they can be done by hand, paper and pencil. The users are office or shop-floor staff. Those systems are also called TPS. On the next level, there is management of operative units (the real business). Their job is to manage, which means planning, controlling, deciding and so on. Top management finally manages on a strategic level more expressed in financials terms but also involving information about market trends and competitors. There are several reasons the top of the pyramid is drawn narrower than the base: – There are fewer top management than middle and lower management and those again are fewer than operative staff that operates the real transactions. – The farther up the pyramid the more uniform the code of information becomes: On a base level, the real transactions all have very different real information (like customer addresses, a bill of materials or a structure of accounts in finan-

1.2 Types of IT-Systems | 21

–

cial accounting). Middle management mainly uses numbers which are more easily compatible. Finally, top management considers matters mainly in financials, like cost and revenue, which arise everywhere in the pyramid and are made comparable by a single monetary unit like Dollars or Euros, so the coding of information is not as diverse. Finally, the information is more aggregated towards the top, e. g. operative staff works on single orders, middle management is planning the numbers of orders to plan capacity to fulfil them, while top management considers the revenues extracted from these orders over a longer period of time.

The following table shows another example of the different purposes and scopes of those different layers: Table 1.3: Examples of IS on Different Levels (Based on Laudon/Schoder (2012), p. 442) System

Description

Organizational level

Order processing

Used for entry, processing and tracking of orders.

Operational

Price analysis

Used for setting prices for products and services.

Management

Turnover trend forecast

Used for 5-year-sales forecast

Strategic

Not all software used in companies fits into this scheme. Some IS might be called neutral or cross-functional. An office tool like MS-Excel or email is used at all levels in all functions. However, these are of minor importance to our focus. In this overview chapter, some important IS are not detailed, because they do fit better in other parts of this book or will be discussed in other classes or are simply out of scope here: – Customer Relationship Management (CRM) Systems which supports Sales and Marketing may be considered a vast topic on its own. Please refer to the according chapters in the literature that is cited and provided with this book. – Manufacturing Execution Systems (MES) are placed logically below PPSSystems, which we focus on in chapter 2. They gather and analyse data directly from the manufacturing machinery on the shop floor. However, since they are of growing importance for an automated manufacturing process there will be a chapter on them in chapter 2. – Supply Chain Management (SCM) Software, which integrates the planning of your enterprise with its suppliers, will be mentioned shortly in chapter 3 on integration.

22 | 1 Introduction and Types of Information Systems (IS) –

–

Computer Numeric Control (CNC) software and machines that e. g. control how deep a machine will cut or what pressure will be applied in shaping metal is beyond our scope. Finally many of the operative transaction processing systems are today part of an integrated Enterprise Resource System (ERP) that will be the subject of detailed discussion in chapter 3.

1.2.2 Operative Transaction Processing Systems (TPS) TPS’s can be found everywhere in the companies’ functions, in what we call base level in the pyramid. There are many concepts by which to describe a company and divide it into its functions. We will use a way of structuring the company called the “value chain” by Michael M. Porter. Basically, it divides company functions in primary activities that create value to the customers, and supporting activities that are necessary to run the company, but do not create value for customers directly. Administration and Management: TPS: Electronic scheduling and messaging systems Support Activities

Human Resources: TPS: Workforce planning systems Technology: TPS: Workforce planning systems Procurement: TPS: Computerized ordering systems

Primary Activities

Firm Value Chain

Inbound Logistics

Operations

Sales and Marketing

Service

Outbound Logistics

TPS:

TPS:

TPS:

TPS:

TPS:

Automated Warehousing systems

Computercontrolled machining systems

Computerized ordering systems

Equipment Maintenance systems

Automated shipment scheduling systems Customer Relationship Management Systems

Sourcing and Procurement Systems Suppliers’ Suppliers

Suppliers

Firm Industry Value Chain

Fig. 1.12: Industry Value Chain (Based on Laudon/Laudon (2010), p. 103)

Distributors

Customers

1.2 Types of IT-Systems | 23

TPS support everyday work in the value chain and their characteristics will be discussed further below in this chapter. The following figure shows some of those value chain components, what their purpose in creating value is and what systems are commonly used to support it. Table 1.4: Functions of TPS Systems (Based on Laudon/Schoder (2012), p. 437)

Major functions of System

Major application Systems

Sales/ marketing Systems

Manufacturing production systems

Finance/ accounting systems

Human resources systems

Other types (e. g., university)

Customer service Sales management Promotion Tracking Price Changes Dealer communications Sales order information system Sales commission system Sales support system

Scheduling Purchasing Shipping/ receiving Operations

General ledger Billing Cost accounting

Personal records Benefits Compen sation Labor relations Training

Admissions Grade records Course records Alumni records

Machine control systems Purchase order systems Quality control systems

General ledger Payroll Accounts receivable/ payable Funds management systems

Employee records Benefit systems Employee skills inventory

Registration system Student transcript system Curriculum class control systems Alumni benefactor system

Each of these IS support certain processes in a specific company function, which of course differs considerably from other functions. In order to do so, they will employ different components and routines. The following figure shows an important administrative function: A payroll accounting information system.

24 | 1 Introduction and Types of Information Systems (IS)

Employee data ( various departments)

Payroll Masterfile

To general ledger: wages and salaries

Payroll system

Management reports

Data elements in payroll master file

Goverment documents

Employee • Number • Name • Address • Department • Occupation • Pay rate • Vacation time • Gross pay • Earnings Withholdings • Federal income tax • State tax • FICA • Other

Employee checks

Online queries: earnings

Employee number

Employee name

Gross pay

46848

Stoker, K.

2000.00

Federal tax

State tax

FICA

Earnings (year to date)

400

50

140

6000

Payroll

Fig. 1.13: Payroll Accounting Information System (Based on Laudon/Laudon (2010), p. 46)

The figure above reads as follows: – Employee Data from various departments and their systems is gathered and structured in the payroll system – The data is stored in the payroll master file, that contains all data, that will be used in the various outputs later on – The payroll system allows to export and report data to different recipients, like bookkeeping, management, government and the bank for transferring salaries to employees – Online queries allow customized reports outside regular management reporting. In the function of materials management there is another important task called materials requirement planning (MRP), that tells production, according to BOMs and workplans, when to produce or source which material. IS that can execute these extensive calculations are called PPS and will be the main focus of the next chapter.

1.2 Types of IT-Systems | 25

To manufacturing- and production-systems

Delivery- and order -data

Material requirements planning

Stock database

Management reports

Data elements of stock database: • Item number • Item description • Items on stock • Ordered units • Recording limit

Online requests

Stock report, Date: 14.09.2014

Item number

Description

Items on stock

Ordered units

6361

Drive belts

10211

0

4466

Power cord

55710

88660

9313

Capacitor

663

10200

Fig. 1.14: Materials Requirement Planning (MRP) (Based on Laudon/Schoder (2012), p. 444)

After these examples we focus more technically on the question how these TPS are realized by technology. The technical principle of TPS with its dialog systems and a database, that records every transaction instantly (not in batch mode over unlike in former times) is called OLTP. Operative Transaction Processing Systems (TPS) are realized by the principle of Online Transaction Processing (OLTP). Maybe a TPS could be realized without OLTP, but mostly they are realized with OLTP and that is why the two terms are often confused. The OLTP principle can be described by the following characteristics: – OLTP is designed for supporting operative everyday work; they work in TPS because they do fit exactly into them. – They contains current data, that can be changed easily, e. g. to correct the wrong entry of a delivery address. – They contain data for their separate, confined function in the company like accounting. It uses and needs data and data structures that would be useless for another function like materials handling. – OLTP systems contain many different data needed to support real processes, e. g. technical information and description of materials purchased and stored in warehouses.

26 | 1 Introduction and Types of Information Systems (IS) –

The data is accessed set by set and each access will contain only a little amount of data. E. g. there will be one order after another worked on by one person.

These characteristics clearly distinguish it from other principles of data handling and storage, e. g. in a data warehouse that is used to support management information systems. We will come back to data warehouses as a means of data integration in chapter 3.

1.2.3 Different Management Information Systems Basically three types of management systems can be distinguished: – Executive Decision Systems (ESS), – Decision Support Systems (DSS) and – Management Information Systems (MIS). Sometimes authors like to link them directly to the hierarchy of management. That is true for an Executive Decision Systems (ESS) which, by its very nature, is suited for strategic decisions of top management. Also the MIS is basically suited for middle management. However, DSS might be used on different levels of management and are tightly focused to help solve a specific problem, e. g. “how often should I order per year to achieve the overall lowest cost of procurement by minimizing cost of material + cost of ordering + working capital for inventory?” The data of all those management applications is ultimately derived from operative TPS’s and maybe some external data for the ESS. DSS and ESS often rely heavily on the basic MIS themselves. The technical integration and the data operations in an MIS to achieve the desired information described below, will be the subject of chapter 1.2 .

Executive Support Systems (ESS) Management Information Systems (MIS)

DecisionSupport Systems (DSS) Transaction Processing Systems (TPS)

Fig. 1.15: Management Information Systems (Based on Laudon/Schoder (2012), p. 474)

1.2 Types of IT-Systems | 27

At the beginning of this century, there has been some hype about “knowledge management” and attempts to introduce another level between MIS and TPS. One part of this attempt was the introduction of “Expert-Systems” into the pyramid you know from the previous chapter. However, this structure did not prove to be very consistent. Today, “Expert Systems” are simply systems which a knowledge worker, like an engineer designing machinery is using, e. g. a CAD system. However sophisticated they are, they belong to operative level. They just might lack some characteristics of TPS and are therefore not carried out with OLTP algorithms. We will have a short look at those systems in chapter 3. The objective of all management systems is to help management in solving problems of planning and decision making. So it might be worthwhile to have quick look at those objects to plan and decide on. Table 1.5: Object of Management Systems Management level

Problem Structure

Operative Management

Tactical Management

Strategic Management

Structured

Optimized Stock-keeping

Purchasing of new machines

Introduction of new product lines

Semistructured

Production Control

Employment of staff

Business acquisition

Supplier selection

Advertising measures

Business reorganization

Unstructured

Management on every level has to cope with problems that are more or less structured. However, there is a clear tendency moving from operative to strategic management level: The number of good structured problems decrease and the unstructured ones increase. So there is no strict law as to which problem is “allowed” to be solved by which system; it is just a matter how suited a system might be to solve it. The following table summarizes how to describe the different management systems.

28 | 1 Introduction and Types of Information Systems (IS)

Table 1.6: Management Systems (Based on Laudon/Schoder 2012, p. 436)

System

Input of Information

Presentation

Output of Information

User

ESS

Selected aggregate data from external and internal sources

Graphics, simulations, interactive word

Forecasts, responses to requests

Top management

DSS

Low amount of data or comprehensive databases optimized for analytical models and analysis tools

Simulations, interactive work, analysis

Special reports, decisions analysis, responses to requests

Domain experts, staff managers

MIS

Transaction data from various transaction systems and simple models

Standard reports, simple models, simple analysis

Summaries and data analysis drill down and roll up options

Middle Management

The following chapters will illustrate the different types of management systems a little more closely. Please keep in mind that this separation is somewhat idealized. Software vendors seldom call their products DSS or ESS. They might bundle and integrate them and give them catchier names like “business intelligence” etc.

1.2.3.1 Management Information Systems (MIS) MIS support structured decisions at the level of operations and operative management. However, they are also useful for planning purposes of senior management staff. MIS are generally pointed towards controlling and reporting numbers and calculating some KPIs. They are designed and attached to a stable environment of existing operations and might, in this respect, be called inflexible. E. g. reporting the total revenue of all items sold of a certain product only makes sense if this product is already known. The system cannot directly help estimating the sales of a completely new product. Consequently, MIS use existing corporate data flows and aggregate them. Also their potential for analytical work is limited, since they mostly support decision making using past and present internal data. In a basic MIS, external data like market forecasts are not regularly incorporated.

1.2 Types of IT-Systems | 29

Table 1.7: Consolidated Consumer Products Corporation Sales (Based on Laudon/Laudon (2010), p. 48)

PRODUCT CODE

4469

5674

PRODUCT DESCRIPTION

Carpet Cleaner Carpet Cleaner Carpet Cleaner Carpet Cleaner Carpet Cleaner Room Freshener Room Freshener Room Freshener Room Freshener Room Freshener

SALES REGION

Northeast South Midwest West TOTAL Northeast South Midwest West TOTAL

ACTUAL SALES

4,066,700 3,778,112 4,867,001 4,003,440 16,715,253 3,676,700 5,608,112 4,711,001 4,563,440 18,559,253

PLANNED

4,800,000 3,750,000 4,600,000 4,400,000 17,550,000 3,900,000 4,700,000 4,200,000 4,900,000 17,700,000

ACTUAL versus PLANNED

0.85 1,01 1.06 0.91 0.95 0.94 1.19 1.12 0.93 1.05

1.2.3.2 Decision Support Systems (DSS) DSS are used in middle management. They combine available data, maybe from a MIS, with refined analytic models to support solving optimization tasks. These problems cannot be expressed in simple math, in which the answer just has to be calculated. Sometimes they are just semi-structured and several good solutions exist. Key success factors of DSS are flexibility of use, ability to be adjusted to individual needs, and a quick response to data entry to drive simulations easily. It can be used without the assistance of professional programmers.

30 | 1 Introduction and Types of Information Systems (IS)

Ship file (e.g., Speed capacity)

Port distance restrictions file

Fuel consumption cost file

Analytical models database

Ship charter hire History cost file

Port expensive file

Fig. 1.16: DSS Example (Based on Laudon/Laudon (2010), p. 49)

In the figure above, a logistics manager needs to choose the optimum routing of marine shipments. He uses a Decision Support System for detailed information. 1. The DSS is fed with very different information, like cost of fuel or port expenses that will in a complex way determine optimal solutions. 2. The analytical model’s database contains formulas and procedures that will use this various data to make suggestions for an optimum routing. 3. The logistics manager will start an online query to evaluate the suggestions and simulate different routings on how they will affect overall cost. There will be no single and simple mathematical solution, so the system depends on human interaction.

1.2.3.3 Executive Support Systems (ESS) ESSs are used at strategic level supporting semi- or even unstructured decision problems. This difficult task is enabled by advanced graphics, dialogs and menus. The following figure shows the technical layout of an ESS:

1.3 Processes as Dominant Objects of IS | 31

ESSWorkstation • • • •

ESSWorkstation

Internal Data • • • •

• • • •

DĞŶƵƐ 'ƌĂƉŚŝĐƐ ŽŵŵƵŶŝĐĂƚŝŽŶƐ ŝŐŝƚĂů ĚĂƐŚďŽĂƌĚƐ

TPS/MIS Data Financial Data Office Systems Modelling/ analysis

DĞŶƵƐ 'ƌĂƉŚŝĐƐ ŽŵŵƵŶŝĐĂƚŝŽŶƐ ŝŐŝƚĂů ĚĂƐŚďŽĂƌĚƐ

External Data • • •

ESSWorkstation

Dow Jones Internet news feeds Standard & Poor´s

• • • •

DĞŶƵƐ 'ƌĂƉŚŝĐƐ ŽŵŵƵŶŝĐĂƚŝŽŶƐ ŝŐŝƚĂů ĚĂƐŚďŽĂƌĚƐ

Fig. 1.17: Executive Support System (Based on Laudon/Laudon (2010), p. 52)

This Executive Support System pools data from several internal and external sources and makes them available to executives in an easy-to-use form with example menus, graphics, communications and digital dashboards. Generally, the success of ESS has been limited in the past. The reason for this lies in the very nature of the questions that they are designed to answer: these are unstructured problems and therefore very difficult to translate into algorithms. However the development of new KPI frameworks like the Balanced Score Card (BSC) or the ROCE-scheme finally gives ESS a management-logic to support. Sometimes IS support for the BSC is cited as the typical ESS (see Laudon 2010).

1.3 Processes as Dominant Objects of IS A CEO or a strategy consultant will place actual IS way down in the logical hierarchy of managing business. They usually first worry about general strategy, then real life processes and these real life processes are finally (maybe) controlled and organized by workflow management systems. Finally, dependent on these steps, IS are designed and used in order to support the processes. So before IS are optimized, processes first need to be discussed.

32 | 1 Introduction and Types of Information Systems (IS)

Strategy development

Strategic level

Process management Process definition

Process modelling

Process control

Technical and conceptional level

Workflow Management Workflow modelling

Application System design

Workflow execution

Process monitoring

Operational level

Organization design

Fig. 1.18: Integrated Business Process- and Workflow Management (Based on Gadatsch (2012), p. 2)

Whether or not processes are managed via workflow management is to be decided by management; not all processes might be fit to be managed by WMS. However, the other parts of this sequence are essential in professional IS management. The figure above shows the way it should be, but this is of course not followed by all organizations. Organizations might use or even design IS without knowing about processes; this however, will not yield the maximum return possible. Example: If a consumer is using his/her smartphone to look up a public transportation connection, the app he or she is using will, of course, be based on a defined process: his or her process of looking up the schedule.

In the industrial world, this becomes very obvious when introducing an ERP system like SAP ©. More than half of the time prior to the final introduction of the system will be dedicated to defining and documenting real world processes (like the purchasing process) before they are finally customized into the ERP system. This chapter focuses on the mapping, documentation and automation of processes. IS exist only for supporting the processes of an organization, representing the real business.

1.3 Processes as Dominant Objects of IS | 33

1.3.1 What is a Process? We have used the term process so far without precisely defining it. The professional definition of a “process” resembles vaguely the colloquial use of the word, but contains more and stricter characteristics: 

A process is a well-defined, by division of labour carried-out sequence of steps with a clearly 1 defined beginning and end point. So “monitoring customer satisfaction” is not really a process, but doing a regular market survey might be.



Its goal is always the creation of a service or something of value for an internal or external customer. So procurement processes serve the need of its customers, which is production on the shop floor.



By consumption of resources, the object or service process gains (hopefully) value. This is called value-adding activities. If a process only creates value for an internal customer, like HR for production, it is sometimes called a “non-value adding process”; however this is not completely true, since it is valuable for other departments. If a process does not add any value to anybody -- internal and external -- at all it should simply be eliminated.



A process is structured and proceeded in a certain timeframe, with certain resource access and adhering to certain rules; e. g. in a workplan. Of course, the actual execution of a process might fail or break some rules, but at least the design should be logically sound.



Processes are recurring. Something that has all the features listed above but is unique and non-recurring would rather be called a project.



Processes do not care about company departments, functions or even company boundaries. Processes pursue objectives and goals of customers, not of departments. You can tell suboptimal processes, e. g. if your request leads to many different people and departments in a company you have to talk to and who obviously are not completely informed about your contact with other departments. Processes are mostly cross functional as the figure shows.

34 | 1 Introduction and Types of Information Systems (IS)

Typical departments in the industry (functions)

Purchasing

Inventory

Production

Sales

Shipping department

Department objectives

Department objectives

Department objectives

Department objectives

Department objectives

Z1 … Zn

Z1 … Zn

Z1 … Zn

Z1 … Zn

Typical Z1 business … processes Zn

Customer

Process Objective Z1,…,Zn

Product development process

Process Results E1,…,En

Process Objective Z1,…,Zn

Order processing process

Process Results E1,…,En

Process Objective Z1,…,Zn

Complaints and service process

Process Results E1,…,En

Department Results E1 … En

Department Results E1 … En

Department Results E1 … En

Department Results E1 … En

Customer

Department Results E1 … En

Fig. 1.19: Process Versus Function (Based on Gadatsch (2012), p. 13)

Especially crossing of department-boundaries by processes makes a very strong case for data integration: e. g. should master data be gathered in several departments in the overall company processes, crossing many department boundaries? 3 The definition of what a “real” process looks like should not lead into an essentialist argument: The company reality is what it is and does not care whether you call some sequences a process. However, if you plan to document, manage and computerize processes, it is important that the above criteria are met. To call the event of having a Christmas office party a “process” and try to computerize it does not make any sense.

1.3 Processes as Dominant Objects of IS | 35

Processes are not only used to map the organization for IS support. There are two equally important purposes of process thinking and documentation completely independent from IS: 

Process optimization and management is a very mighty tool to enhance efficiency, customer satisfaction and resource consumption in a company, even if they are not supported by IS.



The main tasks for quality management and ISO certification is to define and document company processes.

1.3.2 Definition and Documentation of Processes The base of all process management, quality management system efforts and preparation for IS support is the documentation of processes. Since IS and process management is by definition a quantitative, structural task, there have to be firm rules for documentation. Drawing and documenting processes is called process mapping. The need for proper formalized process mapping seems so important in company practice that at least five “standards” for graphic modelling of processes have evolved. The following table shows those different methods and their characteristics: Table 1.8: Different Documentation Methods and Their Characteristics (Based on Gadatsch (2012), p. 102) Method

Main target group

Modelling depth

Standardized

Used where

Tools

Complexity

Training requirements

WKD

Management

Simple models

No

International

Yes

Very low

minimal

eEPK

IT/business department

Detailed models

No

DACH countries

Yes

High

High

Swimlane

IT/business department

Simple models

No

International

Yes

Very low

minimal

BPMN

IT/business department

Detailed models

OMG

International

Yes

Very high

Very high

UML Activity Diagram

IT

Detailed models

OMG

International

Yes

High

medium

A survey of German companies asked what methods the organization used for process mapping. The results (Gadatsch 2012, p. 65) might add up to more than 100 % since multiple answers were allowed:

36 | 1 Introduction and Types of Information Systems (IS) – – – –

eEPK (43.1 %), Swimlane (38.8 %), UML (21.6 %), BPMN (16.4 %).

An in depth discussion of those methods could be subject to a book about process management and optimization or quality management and is also well documented in the literature cited in this chapter. Here we just want to have a closer look at the two most frequently used methods. EPK or = Event driven Process Chains (EPC) are very common in Germany and also have made their way internationally. They are mainly focused on documenting and preparing the processes of an organization to be supported by an IS. E. g. if we plan to support materials management with an IS, one of the key processes will be to add a new material and its parameters to the materials database. Before this process will be represented in an IS, the according process needs to be mapped. EPK focuses mainly on the tasks, not on the actor of the process step or object.

1.3 Processes as Dominant Objects of IS | 37

The following EPK maps the process of checking customer credit limit: Financing requirements determined

Request Data

Placing credit application

Mr. X

Request submitted Customer dossier

Checking Credit application

Letter of confirmation

Bank

Credit Department

Schufa Decision Support System

X Credit rating good

Withdrawal slip

Pay out Credit amount

Rejected

Bank

Cash desk

Financing ensured

Fig. 1.20: EPK Example for Giving out a Credit (Based on Gadatsch (2012), p. 80)

The notation used above is the basic notation of EPK. More information about objects (e. g. where the “customer base” is stored and who is responsible for it) can be added by attaching additional data objects. For the sake of clarity, this is not shown instantly in an EPK drawing, but can easily be retrieved, e. g. by double-clicking on it in a process drawing software. The flowing figure shows the notation of elements for drawing an EPK.

38 | 1 Introduction and Types of Information Systems (IS)

Symbol

XOR

Name

Meaning

Event

Description of a state reached that will influence the further flow of the process

Function

Description of the transformation from an input-state to an output-state

Logic Operator: Exclusive OR Logic Operator: OR

Logical Operators describe the logical connection of Events and Functions

Logic Operator: AND

Organisational Unit

Description which organization within the company´s structure is responsible for a specific function

Information Object

Description of real world Objects

Flow of control

Logical sequence of Events and Functions

Flow of Data

Description whether a Function will be read, written or changed

Assignment

Assignments of resources or Organisational Units

Process pointer

Horizontal connections of Processes

Fig. 1.21: EPK Notation of Elements (Based on Gadatsch (2012), p. 78)

There are many programs that enable easy drawing of processes, some of them free. Here are just three suggestions to try: – A free version of the classic “ARIS” toolset: http://www.ariscommunity.com/aris-express – A program by Microsoft suited for technical drawing: http://office.microsoft.com/en-us/visio/ – Another option also prepared for BPMN (see lesson 3): http://www.bizagi.com As described above, EPK’s are focused on mapping the process, not the actors and are targeted on preparing IS support. A similar method with similar notation is the so called swim-lane diagram. It explicitly shows the actors involved and places the events in the “swim lane” of the according actor. These methods of process mapping are used for optimizing organization of processes. If a process in a swim lane covers

1.3 Processes as Dominant Objects of IS | 39

a very wide area and looks entangled like a pile of spaghetti, it is a clear sign that there might be potential for improving the process by streamlining it. Improving or optimizing processes organization is a different topic not covered here. Information about this is available by searching for the key word: Business Process Optimization (BPO) or Business Process Management (BPM). The following graph shows order processing in a swim lane diagram where the departments involved are explicitly drawn as swim lanes.

Customer

Sales

Order Products

Processing order

Goods available ?

Deliver goods

Inventory

Accounting invoice

Accounting

Supplier

Generate invoice

Monitoring incoming payments

Deliver goods in addition

Fig. 1.22: Swim Lane Diagram (Based on Gadatsch (2012), p. 85–86)

The two methods are not all that different and the notation is very similar; the difference is just a matter of purpose: In preparing the organization to be supported by IS, EPK’s are preferred. Also common to both methods is the fact that they cannot be transferred directly into programming an IS. They describe a logical sequence that might be later read by humans and then programmed into an IS. BPMN is a different method that tries to bridge that gap: Processes drawn in BPMN can be used to actually act as programs orchestrating processes. It is therefore a powerful tool for integration processes across functions and isolated IS, and is discussed in some more detail in chapter 3.

40 | 1 Introduction and Types of Information Systems (IS)

1.3.3 Computerization of Processes with Workflows and Workflow Management Systems (WFM) The definition and documentation of processes are both a base for process optimization and the support of the processes by IS. E.g. a company has defined a “good” process to carry out the materials requirement planning (MRP) and the standard scheme of the ERP-System is customized to fit the process the company has defined. However, there is an influence the other way round as well: software is not only used to support the process the employees have chosen to carry out. IS are also used to manage the execution of the process by the users. E.g. the way the MRP process was implemented into ERP Systems forces the users to obey certain rules. Maybe the ERP System will not allow an MRP run if the user has not properly filled out some header information for this MRP run, that the systems asks her to fill out (like the field “reasons for MRP”). Also entering a new material might require completing some mandatory fields; otherwise the new record will not be saved, and so on. This enforcement of a process on a step-by-step level is called a “workflow”. Sometimes it is difficult to distinguish a workflow from a process. Usually a workflow it is more detailed and is defining almost every single step and click within a process. The following figure shows a typical process crossing the boundaries of company functions in order to satisfy a customer need: confirming an order.

Task operator

Operator A Checking, if goods available,

Process steps

Application systems

Warehouse management system,

Process control system

Operator B

Operator C

automatically

Operator D

Calculation, offer

Enter sales order

Planning Production order

Confirming order

Sales Processing

Production-, Planningand Controlling Systems (PPS)

Confirming order

Sales Processing

Workflow-Management-System

Fig. 1.23: The Process of Confirming an Order (Based on Gadatsch (2012), p. 229)

1.3 Processes as Dominant Objects of IS | 41

The process of confirming an order starts with operator A checking if goods are available. She uses the warehouse management system. Then operator B calculates the offer. Operator C enters the sales order and automatically the production order is planned with the production-, planning- and controlling system. Operator D finally confirms the order. In order for these steps to start at the right time and order and to coordinate incoming and outgoing data in each step, a WMS might be used to control the process across departments. Not all workflows are equally well-defined and structured. There are maybe highly standardized workflows like travel expense accounting, holiday request processing or customer order processing. Some workflows on the other hand need to be highly specified according to the object or the customers involved, like credit processing at banks, processing of claims at insurance companies, processing of complaints, hiring of staff (see Gadatsch 2012, p. 45). There are also so called “ad hoc” workflows which will not be pursued in this book, since they lack some characteristics of a process at all. The following example shows a general workflow: an application for leave (taken from Gadatsch 2012, p. 48): “The applicant fills out an electronic application form and signs it with his private key (electronic signature). A document-management-system checks the digital signature and archives the application for leave in an electronic form. A workflow-management-system transfers the application for leave to the responsible human resources manager. The human resources manager receives the application and the digital signature, which confirms the authenticity of the application. She checks the application and either releases or rejects it. She confirms the checking result with her digital signature. The workflow-management-system informs the applicant about the result and transfers the application to human resources department. The application will be processed there and ‘signed’ by another digital signature.”

If the workflow is carried out across functions with isolated IS, it needs to be somehow coordinated or “orchestrated”, as it is sometimes called. Data has to be passed along as well as signals as to whether the single steps were carried out “OK” or not. So a workflow management system might be called a means of integration on process level. If those single IS are already integrated into an ERP-system (see chapter 4), the workflow management system might easily be part of the ERP-system. The market leader SAP, for example, offers a “workflow generator” as a standard feature of its ERP-system. The following figure shows the functions of a workflow management system, regardless of whether it is part of an ERP System or a stand-alone IS to integrate processes.

42 | 1 Introduction and Types of Information Systems (IS)

Function of WFMS

Modelling and simulation of workflows

Instantiation and execution of workflows

Monitoring of current operations and analysis of executed operations

Modelling of organizational structure (organizational modelling)

Instantiation of operations from workflow models

Provision of status information of current operations

Modelling of organizational processes (workflow modelling)

Role resolution for determination of activity holders

Provision of resource utilization (personal, applications)

Modelling of application integration (application modelling)

Information of activity holders (Worklist)

Monitoring of process resubmission (time based trigger)

Modelling of data integration (data modelling)

Synchronization of activity holders

Provision of deviations between workflow models and execution

Simulation and analysis of workflow models

Request and parameterization of applications Administration of workflow data Creation of protocol data

Fig. 1.24: Functions of a Workflow Management System (Based on Gadatsch (2012), p. 234)

Since workflow management systems are a very special part of IS, deeper discussion and research is left up to you. We will come back to the questions of process integration in chapter 3 by the quite recent requirement of orchestrating processes across company boundaries on the Internet. Steering and controlling a workflow with the help of IS is a valid goal in itself, but it holds another promise: if a workflow is controlled by a WFM – why not automate the execution of the process altogether? So WFM automation does to administrative processes what process control software does to manufacturing. Of course, the decision is not simply “to automate or not to automate”. There are rather several levels of automation starting with pure manual execution and leading up to a full automation with no human interaction at all.

1.4 The Value Chain of IT-Companies | 43

Table 1.9: Levels of Integration and Automation (Based on Gadatsch (2012), p. 248) Level of Integration

Description

Example

Level 0 Manual executing

Workflows are executed without application support

Determination of the responsible person for a customer request

Level 1 Manual executing with application option

Workflows are executed with optional application support

Offer review. The operator could use proposed tool.

Level 2 Application request

Workflows are executed computer assisted. The WFMS chooses the suitable application and starts it. The operator executes further steps.

Reply. The WFMS request the operator to create a reply and starts the text processor program.

Level 3 Application parameterization

Workflows are executed computer assisted. The WFMS chooses the suitable application, starts it and delivers parameters. The operator executes further steps

Creating of a customer order. The WFMS opens the transaction and delivers the relevant data (e. g. customer number).

Level 4 Application automation

Workflows are executed automatically without operator interaction.

After creation of delivery note the WFMS starts the workflow “invoice creation”.

1.4 The Value Chain of IT-Companies So far, we have talked about IS and of application software from the view of companies buying and using software. However, it is important for a company to know from which market it is sourcing its IS solutions. Actually, there is no such uniform thing as the “software market”. To get a better understanding, we have to take a closer look into the value chain of IS-companies to understand different business provided by software vendors. We focus on software here and leave out hardware vendors. A value chain shows the functions and steps of creating value for which a customer might be willing to pay (see again 1.2.2). A company can deliver one or more steps of this value chain. If it decides to integrate another step (for example downstream by so-called forward integration), it might be able to get more money from the customer. If it decides not to deliver a certain value step like documentation any more, it leaves this field to other companies and might have to reduce the price for its products since some value (documentation) now is missing from their product in the view of the customer.

44 | 1 Introduction and Types of Information Systems (IS)

Product Research

Component Procurement

Implementation

Product Development

Training and Certification

User Documentation

Maintenance and Support

Production and Packaging

Operations

Marketing

Replacement

Fig. 1.25: Value Chain of the Information System Industry (Based on Pussep et al. 2011, p. 6)

– – –

–

–

– – – – – –

Product research is the R&D of the software industry which delivers a product vision and fundamental research. Component procurement sources for necessary components of Software, like libraries sub routines, interfaces, report generators and so on. Product development is the creation and programming of software with the sub-activities requirements: engineering, software design, software development, code documentation, verification, and validation (see also chapter 6 and 7). Documentation is a value creation of its own which can clearly be seen in the book market: If you search for literature about SAP in Amazon, most books will not be published by SAP itself, but by third party authors. The packaging and bundling of software is a separate value-creating activity. It is frequently outsourced and not necessarily a core activity of a software company. In recent times, it has been strongly influenced by internet bandwidth: less and less software is distributed via CDs. Payment systems for purchasing the software might be placed in this segment as well. Marketing activities are the same in the software business as in other industries. The implementation activity entails the installation, configuration, and adaptation of the software product. There is a whole industry or set of firms that will just offer training for IS other than the software companies that actually manufacture the software. Maintenance and support is a “minor twin” of the product development activity providing bug fixes and enhancements. Operations to keep software just running from day to day is a value creation of its own which moves steadily into the “cloud” or to external service providers. The replacement activity seems a little bit peculiar, but also has its specialists: It deals with shutting down old systems and migrating data and functions to new ones.

1.6 Literature for Chapter 1 | 45

Please note that in each value step there is actual operative work to be done. It needs to be managed and it might also be supported by consultants bringing in external manpower or knowledge. The big players like SAP and Microsoft cover several fields, while some specialists cover just one. In any case: “Product development” is not the only value a company using IS has to source from the software market. We will come back to the vendors and players in the IS in chapter 7.

1.5 Summary of Chapter 1 IS play a dominant role in modern economy in almost every industry and company. It does affect strategy as well as operative profitability. IS can be categorized in many different ways, and in order to describe them clearly they have to be placed in a overall scheme which is mostly visualized as the IS-pyramid. Operative TLP systems and management IS serve entirely different purposes and are therefore designed very differently. However, an IS is of no use in itself; it has to serve the real business at all times. The “real business” is formalized primarily by business processes. The design, optimization and documentation of processes is a necessary precursor for all IS activities. Many tools and concepts offer support for process management and there even exists a type of IS, that is entirely devoted to process control: workflow management systems.

1.6 Literature for Chapter 1 Gartner Inc: IT Metrics: IT Spending and Staffing Report 2011, Stamford CT 2011. Laudon K.; Laudon J.: Management Information Systems (11th edition), Prentice Hall 2010 Laudon K.; Laudon J.: Management Information Systems (12th edition), Prentice Hall 2012 Laudon K.; Laudon J.; Schoder, D.: Wirtschaftsinformatik (2nd edition), Pearson Studium 2010 Gadatsch, A: Grundkurs Geschäftsprozess-Management (7th edition), Springer 2012 Pussep, A.; Schief, M.; Widjaja, T.; Buxmann, P.; Wolf, C.: The Software Value Chain as an Analytical Framework for the Software Industry and Its Exemplary Application for Vertical Integration Measurement., AMCIS 2011 Proceedings, Paper 387. http://aisel.aisnet.org/amcis2011_submissions/387 Pfüller, G: Akzeptanz, Perspektiven und TCO Betrachtungen von IT Sourcing Alternativen – Ergebnisse des Horvath & Partner CIO Panels, Stuttgart 2005. Source: http://www.competencesite.de/downloads/62/98/i_file_4407/IT_Sourcing_Alternativen_Horvath.pdf Brynjolfsson, E.; Hitt, L.: Beyond the Productivity Paradox, in: Communications of the ACM, August 1998, Vol. 41(8): pp. 49–55. Source: Available via Google Scholar. Motiwalla, L.; Thompson, J.: Enterprise Systems for Management (2nd edition), Prentice Hall 2011.

46 | 1 Introduction and Types of Information Systems (IS)

1.7 Review Questions for Chapter 1 In the “Close” questions please assign a letter for the right answer according to their position in the square brackets separated by commas [a,b,c,d, etc.] to close the sentence correctly So if a question reads like This book you are reading right now deals with [Biology, Information Systems, Chemistry] and has approximately [500, 50, 5] pages. … you will find in chapter 8 containing the solutions the answer: 1-b-a, since the correct answer is “Information Systems” and “500”. Simple choice or true/false questions will just name the correct sentences, e. g. 1,3,6, or direct connections like 1-a, 2-c, etc. So it is best to write the number of the question down and the solutions, so it will look like: 1.7.19: 1-a, 2-c, 3-b. This is the format of the solutions chapter which makes for easy comparison.

1.7.1 Choose: Elements of an Application System An application system consists of the following parts (name all appropriate): 1) Operative tasks/processes 2)

Application Software

3)

Organization

4)

Data

5)

IT-Infrastructure

6)

Management

1.7.2 Choose: Advantages of IS Please check all advantages that can be attributed to IS. 1) Higher productivity and efficiency: doing more business with only marginal more cost 2)

Faster operations: Doing the same processes (like manufacturing or sales) in less time.

3)

Independence from technology

4)

Cheapness: IS are cheap and easy to manage

5)

Better quality: Fewer mistakes in administration and manufacturing leading to a higher employee and customer satisfaction and motivation

6)

Easy reaction: Errors in IS cause only cause small scale damage with enough time to react easily.

1.7 Review Questions for Chapter 1 | 47

7)

More management transparency: more and better information for planning, organizing and controlling and a better “grip” on operations

8)

More flexibility in sales, marketing and manufacturing

1.7.3 Close: Reasons for Problems with IS For each gap, please choose the correct word to complete the sentence: Most problems with IS should be attributed to the faulty [Choice and introduction, description, labelling, comparison] and use of IS. Ultimately all problems with IS can be traced back to [staff, stakeholder, hardware, management, software] faults. Management is in command of using these awesome tools the right (or wrong) way.

1.7.4 Close: Share of Information Technology in the overall Number of Investments Please choose one approximate number: The rise of IS investment along the rise of all assets is accompanied by a growth in share. While in 1980 [21 %, 32 %, 43 %] of all investments were in a very broad sense IS related, it was, in the same calculation method, some [39 %, 51 %, 62 %] in 2007.

1.7.5 Choose: Relation between IT-Stock/Assets and Productivity Which answer is correct according to the Research of Bryjolfson et al.? 1)

There is a strong positive correlation between IT-stock/Assets and productivity in a company

2)

There is a weak but visible positive correlation between IT-stock/assets and productivity in a company

3)

There is no visible correlation between IT-stock/assets and productivity in a company

4)

There is a weak but visible negative correlation between IT-stock/assets and productivity in a company.

1.7.6 Close: Spending on Information Technologies Place the following industries in the figure below to show what percentage of their revenue they spend in IS.

48 | 1 Introduction and Types of Information Systems (IS)

a)

6,7%

Professional Services

5,8%

Health & Care

4,8%

b)

4,6%

Insurance

4,5%

Information Technologies

4,3%

Media

4,2%

Pharmaceuticals

3,0%

Electronics

2,4%

Utilities

2,3%

Consumer Products

2,3%

c)

2,2%

Retail

1,8%

Chemicals

1,7%

Food & Beverage Processing

1,6%

d)

1,5%

Construction & Engeneering Metals & Natural Resources

1,5% 1,2%

1)

Telecommunications

2)

Energy

3)

Banking and Financial Services

4)

Industrial manufacturing

1.7.7 Close: Distribution of IS and Running Cost in a TCO View For each gap, please choose the correct word to complete the sentence: Only about [9 %, 16 %, 21 %] of annual IS project costs/investments are spent on hardware and software, while only [5 %, 13 %, 21 %] of annual running/operating cost are spent on further hardware and software. In both cases, the highest share of cost can be attributed to [facility, internal personnel expenditure, external personnel cost, other external services].

1.7.8 Choose: Types of Cost according to TCO Please connect the following cost position to one of the three types of cost according to TCO: a) Direct Cost according to TCO

1.7 Review Questions for Chapter 1 | 49

b) Indirect Cost according to TCO c) Not items of a TCO calculation

1)

Slower reporting to management due to IS use

2)

Planning- and process management of IS

3)

Administrative and financial business of IS

4)

Non-work related use of software

5)

Wrong forecast by management due to IS problems

6)

Training of IT-department staff

7)

Help Desk assistance

8)

Self-help and stealing colleagues’ time for support

9)

Planned down times

10) Customer dissatisfaction in case of IS problem

1.7.9 Choose: The Ultimate Goal of IS What is the ultimate goal of all use of IS in a commercial organization? Choose one. 1)

Increasing market share

2)

Increase EBIT and profit

3)

Become more efficient by speeding up processes

4)

Increase long-term Return on Capital Employed (ROCE)

5)

Increase revenue

6)

Increase employee satisfaction

1.7.10 Close: Classification of IS Please choose the right position of the tasks performed by the systems in the according functions:

50 | 1 Introduction and Types of Information Systems (IS)

Type of System

Sales and Marketing

Executive support system (ESS) Management information Systems (MIS) Decisions support Systems (DSS) Operative Systems (TPS)

Manufacturing and production

Finance and accounting

Human resources

a)

b)

c)

d)

f)

g)

h)

i)

j)

k)

l)

m)

n)

o)

p)

q)

1)

5-year turnover forecast

2)

Inventory analysis of finished goods

3)

Training cost monitoring

4)

Production planning

5)

Sales order management

6)

Accounting and accounts payable

1.7.11 Close: Different IS Applications Please choose the right system: 1)

[ERP, SCM, CRM, MES, CNC]: System supports Sales and Marketing by gathering Information about customers, which is not contained in accounting and is preor extra-contractual. E.g. collecting and documenting complaints raised by certain customers and coordinating their acquisition by sales.

2)

[ERP, SCM, CRM, MES, CNC]: Systems gather and analyze data directly from the manufacturing machinery on the shop floor and helps in managing and optimizing the actual manufacturing tasks

3)

[ERP, SCM, CRM, MES, CNC]: Software integrates the planning of your enterprise with the planning of its suppliers in order to ensure a smooth cooperation. Exchanges logistic, financial and planning data.

4)

[ERP, SCM, CRM, MES, CNC]: Software used to run machines e. g. by controlling how deep a machine will cut into a material or what pressure will be applied in shaping metal.

5)

[ERP, SCM, CRM, MES, CNC]: Integrates horizontally several business applications, especially accounting and production planning system via a common Database and cross-functional process models.

1.7 Review Questions for Chapter 1 | 51

1.7.12 Close: Functions of TPS Systems Please choose the right position of the tasks performed by the systems in the according functions:

Major functions of System Major application System

Sales/ marketing Systems

Manufacturing/ production systems

Finance/ accounting systems

Human resources system

Other types (e. g., university)

a)

b)

c)

d)

f)

g)

h)

i)

j)

k)

1)

Scheduling, Purchasing, Shipping/receiving, Operations

2)

General ledger, Billing, Cost accounting

3)

Sales order information system, Sales commission system, Sales support system

4)

Machine control systems, Purchase order systems, Quality control systems

1.7.13 Close: Management Systems Please choose the right position of the words below to complete the table: Input of Information

Presentation

Output of Information

User

ESS

a)

Graphics, simulations, interactive word

c)

Top management

DSS

Low amount of data or comprehensive databases optimized for analytical models and analysis tools

Simulations, interactive work, analysis

g)

h)

MIS

i)

j)

k)

Middle Management

System

1)

Forecasts, responses to requests

2)

Summaries and data analysis drill down and roll up options

3)

Transaction data from various transaction systems and simple models

4)

Special reports, decisions analysis, responses to requests

5)

Domain experts, staff managers

6)

Selected aggregate data from external and internal sources

7)

Standard reports, simple models, simple analysis

52 | 1 Introduction and Types of Information Systems (IS)

1.7.14 True/False: Characteristics of a Process Please check all sentences about processes that are TRUE. 1)

A process is a well-defined, by division of labor carried out sequence of steps with a clearly defined beginning and end point. So “monitoring customer satisfaction” is not really a process, but doing a regular market survey might be.

2)

The goal of a business process is always the creation of a service or something of value for the personnel that is executing the process, regardless of customer demands.

3)

A process is not always structured and proceeded in a certain timeframe, with certain resource access and adhering to certain rules; e. g. in a work plan. There is no stable recurrent design and a process may change by itself in the way of being executed.

4)

By consumption of resources the object or service process gains (hopefully) value. This is called value-adding activities. If a process only creates value for an internal customer like HR for production, it is sometimes called a “nonvalue-adding process”, however this is not completely true, since it is valuable for other departments. If a process does not add any value to anybody internal and external at all it should simply be eliminated.

5)

Processes do not need to be recurring; also one-time events might be processes.

6)

Processes do not care about company departments, functions or even company boundaries. Processes pursue objectives and goals of customers, not of departments. You can tell suboptimal processes, e. g. if your request leads to many different people and departments in a company you have to talk to and who obviously are not completely informed about your contact with other departments. Processes are mostly cross-functional, as the figure shows.

1.7.15 Close: Notation Systems for Processes What notational standard is described here? 1)

Targeted on IT and on business department offering detailed models that are focused on the process and functions. Quite high complexity and training requirements. Undisputed standard in German speaking countries: [Swimlane, BPMN, EPK]

2)

Enables IT and especially business departments to draw simple models that focus on process steps and the persons/instances that execute the process step in a two-dimensional matrix. Very popular by reorganization consultants due to very low complexity and minimal training necessity: [EPK, Swimlane, BPMN]

1.8 Suggestions for Written Exercise or Groupwork for Chapter 1 | 53

3)

Most recent notational standard targeted on IT and on business departments. Offers detailed models and is standardized internationally by the OMG. Although it offers high complexity, it can be used with medium training. Tools can be used to translate these drawings directly into programming code: [BPMN, EPK, Swimlane]

1.7.16 Choose: Automation Levels of a Workflow System Please choose the right position of the words below to complete the table: Level of Integration

Description

Level 0 Manual executing

a)

Level 1 Manual executing with application option

b)

Level 2 Application request

c)

Level 3 Application parameterization

d)

Level 4 Application automation

e)

Example Determination of the responsible person to a customer request Offer review. The operator could use proposed tool. Reply. The WFMS request the operator to create a reply and starts the text processor program. Creation of a customer order. The WFMS opens the transaction and delivers the relevant data (e. g. customer number). After creation of delivery note the WFMS starts the workflow  “invoice creation”.

1)

Workflows are executed computer assisted. The WFMS chooses the suitable application and starts it. The operator executes further steps.

2)

Workflows are executed automatically without operator interaction.

3)

Workflows are executed computer assisted. The WFMS chooses the suitable application, starts it and delivers parameters. The operator executes further steps.

4)

Workflows are executed without application support

5)

Workflows are executed with optional application support

1.8 Suggestions for Written Exercise or Groupwork for Chapter 1 1.8.1 Total Cost of Ownership Concept Open Source Programs (like open source CAD programs) seem to come for “free” or free of cost. Please compare with fictitious numbers or in words the TCO of an open source and a “regular CAD System” (like Solid Works).

54 | 1 Introduction and Types of Information Systems (IS)

The numbers/values are not important, but the positions of a TCO calculation should be filled with practical examples of what causes these cost. Your result should be delivered as a spreadsheet file e. g. MS Excel.

1.8.2 Operative and Strategic Impact of Information Systems Mailorder Specialist “Industry Supplies LTD” (Cost Leader) sells all kinds of MRO materials, especially standard handheld-tools via dealers and e-procurement solutions with direct connection to few key accounts. It now wants to expand to direct sales via a web shop. You are asked to give 10 examples (5 each) of a) strategic and b) operative and financial impacts (use fictitious numbers!) this new IS might have on the company. Note: Of course there are positive AND negative impacts on both levels! Hint: For measuring operative impact, use ROCE or RoI. For strategic impact, use M.E. Porter’s Five Forces model or the value chain model. Discuss 10 examples in depth; do NOT try to gather all impacts superficially.

1.8.3 Research Success and Failure Stories Please research in the press two recent success stories in which IS has given a company measurable financial or strategic advantage. Please also research two failure stories in which the opposite happened. Research yourself and do NOT take a readymade example from a textbook.

2 Focus on Production Planning Systems (PPS) This chapter focuses on Production Planning Systems (PPS), which represent the core application for manufacturing companies. After this chapter, you should be able to …  … sketch the basic functions of a PPS system and the MRP II concept.  … describe the three main master data needed for production planning.  … explode a BoM.  … schedule the start of production steps.  … explain the necessity of capacity leveling.  … know the functions of a production order.  … tell the difference and the relationship between PPS-systems and sub-ERP systems like MES and below.

2.1 PPS at the Core of Industrial Manufacturing 2.1.1 Manufacturing Process and Materials Management Manufacturing is a core-process of industrial companies; however, this does not mean the process is always executed by the company itself. Manufacturing might be completely outsourced. Manufacturing processes differ in length, complexity and the span of variation greatly, so we might as well pick any kind of manufacturing process to illustrate it. The following figure shows the manufacturing of a drill pipe. Although it seems quite simple, it has two important characteristics of an industrial process: there are stages or work orders in which material is transformed and stages in which components are assembled from different parts.

56 | 2 Focus on Production Planning Systems (PPS)

Fig. 2.1: Manufacturing Drill Pipe (Based on http://www.nov.com/Drilling/Drilling_Tubulars/Drill_Pipe/ Drill_Pipe_Manufacturing_Process.aspx)

2.1 PPS at the Core of Industrial Manufacturing | 57

The example above depicts a serial production of a single material product, a steel drill pipe. Other ways of manufacturing include:  Process industries like petrochemical, refineries and pharmaceuticals  Serial production of complex products, like automotive  Made-to-order production of products and plant construction  … and there is another different universe outside manufacturing: the service sector, especially financial services where “production” of a service like a credit is the process itself. However, modern ERP systems easily cover this different kind of production, as well. This chapter will confine itself to industrial serial and made-to-order production, which in itself occurs in great variety among companies. However different a manufacturing process might be, it is still a process: a series of single steps, with defined beginning and end that use resources, which are either worked into the final product or used for transformation of materials. This process has to be planned, executed and controlled. The operative IS used for this purpose is called a Production Planning System (PPS).

2.1.2 Functions of a PPS PPS originated from a fairly simple idea called MRP (Material Requirements Planning). MRP suggests computerizing the rather tedious calculation of exploding bills of material and calculating net requirements. In so called “extended MRP I” it also helps schedule the optimal date of production steps with limited capacity. These calculations are well known from purchasing – since net requirement calculations is the source from which purchase requests com. MRP I was extended circa 1980 in two directions:  Upstream: Manufacturing planning was additionally connected to planning of sales and marketing and even production strategy. Since a company produces for the market and for no one else, all data for desired manufacturing ultimately must come from there.  Downstream: Execution and control of the above planning proved to be vital to the efficiency of the overall planning. E. g. if a work order for manufacturing, for example, is delayed or not carried out at all, it must be fed back into planning to achieve the overall goal: satisfying planned demand.

58 | 2 Focus on Production Planning Systems (PPS)

The extended model is called MRP II and is still the concept that a good PPS will cover and that we will refer to below. Two further extensions are integrating purchasing (in ERP Systems) and integrating the planning systems of a manufacturer and its suppliers (Supply Chain Management). 3 To be clear on the different terms: MRPII is a business concept. It will be realized by software, which is called a PPS. If this PPS is combined with other programs like a program for accounting and sales distribution, this integrated system is called an Enterprise Resource Planning (ERP) System. Prominent vendors of ERP Software are, among others, SAP and Microsoft.

The following figure shows the areas of manufacturing management covered by the MRP II concept. Functional groups

Subdivisions

Production Program planning

Production planning

Quantity Planning

Functions • • • • •

Forecasting Rough planning Delivery date determination Customer order management Lead time control

• Determination of requirements • Inventory record keeping • Procurement calculation

Data management

Production ordersn

Production control

Scheduling and capacity planning

Order release

Order monitoring

Purchase ordersn

• Lead time scheduling • Capacity requirements • Determination and coordination • Sequence planning • Production document preparation • Production order release • Work distribution

• Purchase order release • Purchase order preparation

• Capacity groups • Customer order monitoring • Production order monitoring

• Purchase order monitoring

Fig. 2.2: Areas of Manufacturing Management Covered by MRP (Based on Hackstein 1989, p. 5)

2.1 PPS at the Core of Industrial Manufacturing | 59

Production program planning summarizes existing customer orders and creates a production program that defines which final product in which quantity at which date needs to be produced. Besides, this way a first rough planning is performed by checking whether available capacities are sufficient. The task of material planning is to determine the type, quantity, manufacturing date and quality of material needed to realize the production quantities from the production program planning. For this task, there are consumption-based and deterministic requirements planning models available. This chapter will focus on the deterministic model. Calculations for net requirements consider information about products, components and parts still in stock. For demand, that will not be ready when needed, planned work orders or purchase requests will be created. Job order planning creates the required production orders to cover the production program. The production orders will be scheduled, the required resources will be checked for availability, and the working documents prepared. Capacity planning determines required capacity and available capacity for production orders. In the case of overlap or shortfall, action for capacity coordination will be taken. The result will be an exact sequence of orders and its operations at the work places. Within order monitoring actual times and actual quantities of production will be reported. This delivers an up-to-date overview about the state of production orders and customer orders, as well as usage of capacities. In order to fulfil these functions and execute those tasks, the system must store and manage the master data with all relevant parameters/fields, which are fed into the algorithms of those functions. Such master data includes:  Materials  Bill of materials (BoMs)  Suppliers  Purchasing info records that show the specific price for a material offered by a specific supplier  Work centers  … Some of this master data will be detailed in chapter 2.2. Since many companies rely on an integrated supply chain, it is hard to draw a sharp line for where the production planning ends and purchasing/supplying starts. In this chapter, we will tightly focus on planning and executing production processes while purchasing is simply an extension out of a company that is triggered by production planning. Modern ERP systems like SAP, of course, tightly connect the two modules of “production” and “purchasing”, as you shall see in chapter 3, and might experience in the software case study in chapter 5. In this chapter, any step of

60 | 2 Focus on Production Planning Systems (PPS)

a work plan or a branch of a BoM might lead into a further operation: manufacturing the desired component or purchase the material needed. Screenshots and examples in this chapter are all taken from the SAP PPS module called “Materials Management”. There are other PPS Systems whose look will be different, while the basic concepts will be similar. There are still some isolated PPS applications in the market; however, most vendors will offer them as integrated into their ERP System.

2.2 Important Master Data in a PPS All transaction data, like a work order, an actual purchase and all functions of a PPS are ultimately dependent on the proper definition of master data. In this chapter, only the most important master data used in MRP will be explored; there are, of course, many others also depending on the brand and type of PPS.

2.2.1 Materials Materials are objects that are used, transformed and manufactured in a company. Different types of materials will, of course, have different parameters and different functions. In SAP, everything used, transformed and created during manufacturing process is called material, e. g.  the car (final product),  the engine (self-manufactured),  the windows (bought from supplier),  steel (raw material)  and even the electrical power used during production steps (pipeline material). The material master record contains descriptive data such as the size, dimension, and weight of material, and control data, such as material type and industry sector. In addition to this user-maintained data, material master records also contain data that is updated by the system automatically, such as stock levels. All of these materials have different characteristics and fields to be filled that depend on their very nature. A finished good – unlike a raw material – will not have a purchasing price, since the company is manufacturing it. A raw material – unlike a finished good – will be connected to a BoM, since it is not constructed. A pipeline material like electrical power – unlike a finished good – will never have a sales price since we are using pipeline materials and not selling them. So by the initial decision of what type of material is created in the system, the possible characteristics that can be entered for this good are fixed: You will not be able to enter a sales price for a raw material.

2.2 Important Master Data in a PPS | 61

Fig. 2.3: Material Types in an PPS (Based on SAP “Standard Material Types” 2013)

Spare parts are used to replace defective parts. They may be kept in stock. A material master record of this material type can contain purchasing data, but no sales data. Finished products are produced in-house. Since they cannot be ordered by purchasing, a material master record of this material type does not contain purchasing data, like a price. Production resources/tools are procured externally and used in production or plant maintenance. A material master record of this material type can contain purchasing data, but not sales data. It is managed on a quantity basis – not monetary values (€, $). Examples of production resources/tools include jigs and fixtures, and measuring and test equipment. Semi-finished products can be procured externally and manufactured inhouse. They are further processed by the company. A material master record of this material type can contain both purchasing and work scheduling data and even might be sold. Operating supplies are procured externally and required for manufacturing other products. A material master record of this type can contain purchasing data, but not sales data. Maintenance assemblies are not individual objects, but logical elements to separate technical objects into more clearly defined units in plant maintenance. For example, an automobile can be a technical object and the engine, gearbox, chassis,

62 | 2 Focus on Production Planning Systems (PPS)

and others are maintenance assemblies. A material master record of this material type can contain basic data and classification data. Intra materials exist only temporarily between two processing steps. A material master record of this material type contains neither purchasing nor sales data. Configurable materials are materials that can have different variants. For example, an automobile can have different types of paintwork, trim, and engine. So the difference between variants is not set by creating many individual materials but rather one material master with varying attributes. This helps keeping the numbers of material maser records down. A material master record of this material type contains sales data, but not purchasing data. Empties are a type of returnable transport packaging generally subject to a deposit. They can consist of several components grouped together in a bill of material (BoM) that is assigned to a full product. For example, an empty crate and empty bottles are assigned to the full product beer. Each of the components in the BoM has a separate material master record. Nonstock materials are not held in stock because they are consumed immediately. They include materials such as oil, power, or water that flow into the production process directly from a pipeline, line, or other type of conduit. Since pipeline materials are always available, they are not planned, just used as needed and the usage is documented. Raw materials are always procured externally and then processed. A material master record of this type contains purchasing data, but not sales data since they usually are not sold in an manufacturing company. Nonvaluated materials are managed on a quantity basis, but not by value, since they are not depreciated and also do not go into a final product directly. So they do not cause material cost for a product directly. Packaging materials are used to transport goods and come with the goods free of charge. A material master record of this material type is managed on both a quantity basis and value basis. Additionals are assigned to a material to be sold to ensure its effective presentation to customers. Examples include clothes hangers, care labels, and services such as pressing clothing for display or arranging it on hangers. Advertising Media are means of presentation used in advertising that group advertising messages about a number of materials. Examples include printed mailorder catalogues, computer catalogues on CD-ROM, and promotional fliers. Since every material has a lot of characteristics stored in fields, they need to be structured somehow; mostly they are put together in registers. This will be detailed in chapter 3. Just as a quick example: a screen of a semi-finished good (metal housing for a pump) with the registers basic data 1, basic data 2, classification and sales org. 1. This might be somehow surprising since semi-finished goods are usually not

2.2 Important Master Data in a PPS | 63

sold. But since some companies use and sell their semi-finished goods, e. g. as spare parts for customer maintenance, the definition of semi-finished goods in SAP allows for entering a sales price and information about the sales organization.

Fig. 2.4: Semi-finished Goods in SAP

2.2.1.1 Bill of Materials (BoM) BoMs can be found anywhere that single parts and input materials are assembled or fused to form a more complex product or component. In the pharmaceutical indus-

64 | 2 Focus on Production Planning Systems (PPS)

try, a BoM might be called a recipe. This document is central for all tasks of production planning. BoMs are originally created in mechanical design by a CAD program. They may be imported from CAD to PPS by interfaces; some still even enter the BoMs manually into their PPS if they do not have an import routine. Modern approaches like PDM (see chapter 3) integrate CAD and PPS more tightly to allow simultaneous access and a live update on changes in the design, and consequently, in BoMs. The typical graphical representation of a BoM is a tree with the finished good on top and going down (that means back in the sequence of production), the modules, and finally, single parts, as the following simple BoM shows. Level Men´s racing bicycle MRB 01

Pre-assembled Frame and forks FRAME 01

Chrome Forks

Blue frame

FORKS

MF01

Handlebar Assembly HBA

Handlebar

Derailleur Gear system GEARS

Handlebar Grip

Gears Cassette

Grip

GCASS

HBAR

…

1

Rear arm RARM

…

2

Fig. 2.5: Graphical Representation of a BoM (Based on SAP “BoMs” 2001, S. 15)

The representation as a tree is just for visualization and makes sense only on the first levels. The usual form of representation is a spreadsheet. Every BoM has a header with general information, and secondly, the actual items in it. Also, there are issues of who is authorized to change what data and for what area and time the BoM is valid.

2.2 Important Master Data in a PPS | 65

For details, please look up SAP help or any base literature for design and production containing information about BoMs. In this chapter, we will focus on the different types of BoMs and how they 3 are used in the production planning process.

2.2.1.2 Categories and Types of BoMs In PPS like SAP, there are basically three categories of BoMs; material BoMs, equipment BoMs and document BoMs, as seen in the following figure. Also work breakdown structures of projects can be represented in a BoM. Material Master Record

Material BoM

Material

Equipment Master Record

0

Equipment BoM

Oil

Document Info Record

Document BoM

Fig. 2.6: Categories of BoM’s (Based on SAP “BoMs” 2001, S. 26)

Material BoMs mainly are used to represent the structure of products manufactured within the 1 company. Both materials and documents as components of this BoM may be entered. A document info record must exist in the SAP system for each document entered. Equipment BoM: The system also allows for maintaining BoMs for equipment that includes technical objects for plant maintenance. These Equipment BoMs (for example, for a milling machine) are used to describe the structure of equipment and to assign spare parts to equipment for maintenance purposes.

66 | 2 Focus on Production Planning Systems (PPS)

Document BoM: A complex document may be made up of several documents, such as a program, technical drawings, papers, and photographs. These related information and documentation objects are grouped together as a unit using a document structure – a BoM for a document. In effect, a BoM for a document info record is created. This “BoM” is known as a document structure and it resembles the table of content for a thesis.

For further explanation of the different types of BoMs and the forms of representation (list/table), we will focus on the most relevant category for our purposes: the material BoM. The basic information of a material BoM represented in a list consists of the single items in rows and their characteristics in columns. The most important characteristics are:  Production stage: When will this item be used?  Position: A unique identifier for the item within its list  An overall unique object ID of the item/material that is known to all other modules of the ERP-System  Description Text: What is it?  How much is needed and in what unit is it measured?  … much more information, that can be retrieved by reading the SAP documentation about BoMs cited in this chapter. These fields are relevant for every type of BoM. Since BoMs are used for different purposes there are different types of BoMs that satisfy different information needs. The first type is a so-called multilevel BoM. It contains all parts of the product, sometimes even several times: if a part, like a bolt, is needed in several levels of manufacturing, it will be listed several times with the according level in which the bolts are used.

Fig. 2.7: Multilevel BoM

2.2 Important Master Data in a PPS | 67

The second type is a single level BoM. As the name states, a product is just split into modules once – but not further. These modules are split in other sub-modules by another single level BoM. Consequently, there is no need for determining the level, since there is only one level per BoM.

Fig. 2.8: Single Level BoM

Another type of BoM is the quantity BoM. It adds up the quantities of a single material wherever it is needed in the production process, so there is no information about levels needed. This BoM rather tells how much is needed to manufacture the product. This is the same kind of list a worker in the warehouse uses to pick parts for a certain manufacturing process or a shipment to a customer (pick-list).

68 | 2 Focus on Production Planning Systems (PPS)

Fig. 2.9: Quantity BoM

Another transformation used in practice is the variation of BoMs. Modern manufacturers are confronted with much differentiated market demands, which find their way into production by requests to manufacture many variants of a product. The variety of products to manufacture, and the resulting complexity, is one of the most prominent problems of material management. Materials management always seeks to standardize and create uniform processes to gain economies of scale and scope and complexity is preventing this issue. Modern ERP systems are aware of this dilemma, and help companies by creating variants while still trying to standardize: a maximum BoM is created that envelops all parts for all variants of the product. The actual variant produced uses a socalled configured BoM that is a smaller, stripped down version of the all-covering maximum BoM, as the following figure visualizes.

2.2 Important Master Data in a PPS | 69

Maximum BoM

Configured BoM

Fig. 2.10: Maximum BoM and Configured BoM

2.2.1.3 How Bills of Material are Used in Production Planning Data stored in BoMs play a vital role in production planning and serves as a basis for the following activities:  A design department working with CAD can base its work on previous BoMs stored in a PDM (see chapter 3). A BoM can also be created in the SAP System from a CAD program, via the SAP-CAD interface.  Material requirements planning (MRP) explodes BoMs to calculate cost-effective order quantities for materials.  Work scheduling uses BoMs for operation planning and production control.  Production order management uses BoMs to plan provisioning of materials.  Sales create and maintain a BoM specifically for a sales order (variant configuration).  Product costing uses BoMs to calculate cost of materials required for a specific product (Taken from SAP “BoMs” 2001, S. 14).

70 | 2 Focus on Production Planning Systems (PPS)

2.2.2 Work Center Manufacturing operations are carried out at work centers. In PPS, work centers are logical units or business objects that may represent real life work centers, for example:  Machines, machine groups  Production lines  Assembly work centers  Employees, groups of employees The object “work center” (see SAP 2001, Work-Centers) is used for several purposes:  Scheduling operating times and formulas for calculating operation duration in the work center are maintained in the object work-center.  Formulas for calculating the order and production cost are entered in the work center. Also, work centers are assigned to a cost center, which is relieved by order confirmation – it then passes on the cost onto the object.  For capacity planning, among other things, the available capacity and formulas for calculation of the capacity demand of an operation are stored in a workcenter.  For job order planning, several default values (e. g. standard text or control keys) for the operation in the order are maintained in a work-center.

2.2 Important Master Data in a PPS | 71

The following figure visualizes some of these purposes:

Work Center

Default Values

Task lists

Costing data

Costing 2724.00 1200.00 124.00

Scheduling data And available capacity

Lead time scheduling Capacity planning

4048.00

Fig. 2.11: Work Center (Based on SAP “Work-Centers” 2001, S, p. 9)

The following figure shows master data for capacity of a work center. This information will be used later in capacity planning and balancing (see chapter 2.3.3).

72 | 2 Focus on Production Planning Systems (PPS)

Fig. 2.12: Capacity of a Work Center

2.2.3 Work Plan (in SAP Called “Routing”) A work plan is the second essential description for manufacturing a product next to the BoM. It describes the “do how” of manufacturing a good as described by its BoM. A good explanation of work plans (= routings) can be found directly at the SAP online help: “A routing is a description of which operations (process steps) have to be carried out and in which order to produce a material (product). In addition to information about the operations and the order in which they are carried out, a routing also contains details about the workcenters at which they are carried out, as well as the required production resources and tools (includes jigs and fixtures). Standard values for the execution of individual operations are also saved in routings.” (http://help.sap.com/saphelp_46c/helpdata/en/03/bb1d0ca6e811d189010000e8323492/ content.htm)

2.2 Important Master Data in a PPS | 73

A routing consists of a header with general information and operations (individual process steps or tasks) carried out during production. For each individual step in the process, the following information is held in the work-plan:  ... tasks to do in that step as basis for calculating dates, capacity requirements and cost calculation,  ... materials used in that step  ... work places and works centers involved in executing this step,  ...criteria for a quality check for this step that determine whether this step will be viewed as successfully executed.

Fig. 2.13: Work Plan

Just like for BoMs, it is possible to create a maximum routing (sometimes also called “super task list”) and then derive actual variants from this maximum routing.

74 | 2 Focus on Production Planning Systems (PPS)

Maximum Work Plan

Configured Work Plan

Fig. 2.14: Maximum Work Plan and Configured Work Plan

2.3 Production Planning The successful execution of production planning with the help of a PPS depends critically on the proper definition of master data described above. Production Planning can be split into three major tasks:  Quantity planning and net requirements planning: how much to manufacture (and purchase) of a part according to sales planning, the BoMs and current inventories in stock?  Scheduling: When to manufacture what, according to capacity and working plan (=routing)?  Capacity planning: How much capacity do we need and how is the utilization of existing capacity optimized? In the following chapters production planning will be explained for so-called deterministic planning only. Deterministic planning works like this: by knowing the demand from sales and the BoMs, it is possible to calculate the exact amount of all materials needed at any specific time. 1 There are some materials which do not have a BoM and are not sold (like grease or electrical power) and are, therefore, simply forecasted by looking at the consumption in the past. This is called stochastic forecast/planning and is also supported by modern ERP systems if the right parameters are checked. However, this is nothing specific to PPS and can be looked up in literature about operation research, market research or in math books, if you would like to refresh your knowledge about forecasting.

2.3 Production Planning | 75

2.3.1 Quantity Planning Quantity planning starts, of course, with the demand (in time and quantity) of finished goods reported from sales, which is taken as given here. With this information, the BoMs are exploded: the parts on a lower level that make up a higher level are derived from the demand for the unit on the level above. This calculation is done step-by-step starting from the top level of finished goods, which is called “independent requirement” since it depends not on production, but is driven by sales. The calculation further down and in detail is simply done by multiplying the demand for the upper level object with the required amount on the lower level according to the BoM. This demand for the lower level part is documented in a “planned work order” (PWO), which might either lead to more “planned work orders” farther down the hierarchy if we manufacture the part ourselves, or lead to a purchase request later on. This step is repeated “down” the BoM until the BoM hits the bottom, which means that none of the parts and components there can be manufactured in the company, but are all sourced from outside. All demands below the top level of “independent requirement” are called “dependent requirement”, regardless of what level. Most companies do not entirely operate on a just-in-time base; they keep materials in stock. If materials will be in stock and available to us at the estimated time of production, those amounts have to be subtracted from the demand calculated by BoM explosion. The following figure shows the concept of deterministic disposition in a very simple multilevel BoM. Customer order/ Planned independent requirements Planned order 1 unit Dependent requirements 1 unit Component C1 1 unit Raw material R1

1 unit Raw material R2

2 unit Component C2 1 kg Raw material R3

Planned order

Dependent requirements Planned order

Fig. 2.15: Deterministic Disposition

The company has some of the objects in this BoM in stock in the following quantities:

76 | 2 Focus on Production Planning Systems (PPS)

Final product Component C1 Component C2 Raw material R1 Raw material R2 Raw material R3

50 units 30 units 40 units 100 kg 10 units 15 kg

1.

The calculation starts with sales demanding 100 units of finished goods: 100 is the independent requirement. 2. This independent requirement is compared with the finished goods still in stock (50). The missing demand of 50 units is converted into a planned work order (PWO 1) to be manufactured. 3. Dependent demand for component C1 equals 50 units of the finished good times 1. This demand of 50 C1 is partly met by 30 C1 being in stock. The rest (20 C1) is converted into PWO 2 to be produced. 4. Dependent demand for component C2 equals 50 units finished goods times 2 according to the BoM. This demand of 100 C2 is partly met by 40 C2 being in stock. The rest (60 C2) is converted into PWO 3 to be produced. 5. To execute PWO 2, 20 kg of raw material R1 is needed. Since this demand is fully met by the 100kg in stock, no further PWO needs to be created for R1. 6. Different issue with raw material R2: to execute PWO 1, we need 20 units of raw material 2. Since this demand is not met by the 10 units in stock, PWO 4 for additional 10 units is created. 7. To execute PWO 3 for 60 units of component C2 60 kg of raw material R3 is needed. Since this demand is not met by the 15 kg in stock PWO 5 for additional 45 kg is created. So exploding the BoM above and considering materials in stock will result in 5 PWOs: PWO 1 = 50 units of finished good PWO 2 = 20 units of component 1 PWO 3 = 60 units of component 2 PWO 4 = 20 units of raw material R2 PWO 5 = 45 kg raw material R3 Before manufacturing execution, these PWOs will be converted: PWO 1–3 will result in an actual work order. PWO4 and 5 will lead to a purchase request. During MRP calculations, ERP-Systems do not care whether a work order will be executed internally (manufacturing) or externally (purchasing). This simple example shows how complex and extensive these calculations will get in reality with more complex BoMs, and are therefore naturally object to IS support by PPS.

2.3 Production Planning | 77

2.3.2 Scheduling of Production Knowing the quantity of parts to manufacture (or purchase) needs to be extended by the dimension of time: WHEN do we need the parts and components to ensure the PWOs are being executed in a timely manner? Scheduling of production basically is calculated and planned by the PWOs created from BoM explosion and the information in routing to fulfill those PWOs. The following graph shows how the scheduling of PWOs is accomplished: We know from work plans (=routings) of our two components and from replenishing lead time for our raw materials how long the PWOs are going to take. From the very structure of the BoM, we know that PWO 2 (assembly of component C1) can only start after PWO 4 (purchase raw material 2 and get it delivered). PWO 1 (final assembly of finished product) can only start after PWO 2 and PWO 3 are finished, and so on. The following figure shows how the total time of production can be calculated from sequence and length of the single PWOs. In a backward calculation (from the time the finished good is needed), the start of every PWO and purchase can be calculated. The time between when a finished product or component is needed and the time its subcomponents need to be ready is called lead time offset.

Finished Product

PWO P1

Component C1

PWO P2

Component C2

Raw Material R1

PWO P3

PWO P4

Raw Material R2

PWO P5 Time

Requirement Date

Fig. 2.16: Lead Time Offset

The following lead times are assumed:  PWO P1: 3 days,  PWO P2: 3 days,  PWO P3: 2 days,  PWO P4: 2 days,  PWO P5: 2 days  and the finished product is needed on the 30th of April.

78 | 2 Focus on Production Planning Systems (PPS)

So the start of the first PWO (PWO 4!) would need to be the 30th (delivery date) minus 3 days for PWO 1, minus 3 days for PWO2, and minus 2 days for PWO 3. PWO 5 does not need to be considered since it is not the bottleneck. The sum of the lead time offset is 8 days, so the order to purchase R2 should be issued on the 22nd of April to arrange everything in time. PO 1 determines the socalled “basic start” and “basic end date” of production. This way of calculating the schedule is quite similar to calculating project time in project planning by using the sequence and length of single work packages. Since many people may enter various master data (e. g. if a BoM is changed), the planning cannot permanently be live updated, but must rather be run as a discrete, conscious act. This calculation is called the MRP (Materials Requirement Planning) run. Of course, there are also other forms of scheduling, but the way described above is the standard for an optimized deterministic planning.

2.3.3 Capacity Planning and Capacity Leveling Capacity planning checks whether the PWOs defined in quantity and time above can be realized with existing human resources and machinery. There are three distinct steps to ensure capacity for production is available: 1. Determining the capacity offered by existing information about work centers. 2. Calculating the capacity needed by existing production plans 3. Capacity leveling (also: capacity alignment) to balance offered and needed capacity The following figure shows the interaction of these three steps and tasks.

2.3 Production Planning | 79

Input from production planning and control, Maintenance, project management, etc.

Master data Material

Bill of Material 10

20

30

40

50

Scheduling Routing Capacity requirements

Calendar Capacity levelling

Workcenter Available capacity

Fig. 2.17: Capacity Planning and Capacity Leveling

Capacity is ultimately offered by existing work centers in the company. There are different “capacities” e. g. for regular production and some reserved for very urgent orders. Also two main types can be distinguished: Capacity of machinery and of human resources. 100 % of the full 24/7 potential (standard capacity) of machines is not available. There are many limitations like unplanned downtimes, maintenance, holidays and so on. In the following figure, the standard capacity is called “work time” and the really available capacity, “productive work time”.

80 | 2 Focus on Production Planning Systems (PPS)

Break times

No. of hours

Time

Technical and organizational malfunctions

Work time

Data in Work start Break workplace Work finish duration

Work time minus breaks

Productive work time

Operating Rate of capa- Operating time per shift city utilization time

Fig. 2.18: Capacity Planning (Based on SAP “Capacity Planning” 2001, p. 10)

The accumulation of capacity over all workplaces and workplace groups is another difficult mathematical task that will be accomplished by a PPS. Work orders generate capacity requirements, and thus, a load on the resources that are to process them. The following sources of orders are relevant (see SAP “Capacity Planning” 2001, p. 12):  Production orders in shop floor control (SFC)  Planned orders in material requirements planning (MRP)  Master production scheduling  Long-term planning  Repetitive manufacturing  Sales and operations planning for quantities in rough-cut planning  Maintenance orders in plant maintenance  Sales orders, assembly orders or networks in sales and distribution Capacity requirements are, therefore, mainly a result of the calculations described above. Allotting capacity to PWOs and their operations is not a matter of simple division. Setup, retooling time and tearing down time have to be considered, also

2.3 Production Planning | 81

there is the fact that the capacity of some workstations cannot be divided infinitely. Thus, complex formulae are applied in order to calculate realistic capacity requirements. The last task in production planning pays tribute to the fact that there is more than one good solution to allot the capacity of the workplaces to PWOs. This is generally too complex and volatile to be calculated by computer programs alone. Here, the system merely supports the production planner in order to meet his overall goal: profit maximizing load optimization. One important support in this creative process is reporting the load of work places as can be seen in the following figure.

Work Center Type of Capacity

Paint shop Capacity of machinery

Week

Demand

Supply

Load

Free capacity

33.2012

12,97

35,00

37 %

22,03

h

34.2012

25,25

35,00

72 %

9,75

h

35.2012

17,83

35,00

51 %

17,17

h

36.2012

15,69

35,00

45 %

19,31

h

37.2012

2,28

35,00

7%

32,72

h

Total

74,02

175,00

42 %

100,98

h

Work Center Type of Capacity

Unit

Paint shop Human resource capacity

Week

Demand

Supply

Load

33.2012

50,47

35,00

144 %

34.2012

29,42

35,00

35.2012

17,83

36.2012

Free capacity

Unit

- 15,47

h

84 %

5,58

h

35,00

51 %

17,17

h

56,52

35,00

162 %

- 21,52

h

37.2012

19,78

35,00

57 %

15,22

h

Total

174,02

175,00

99 %

0,98

h

Fig. 2.19: Reporting the Load of Work Places

The report in this figure above shows the workplace as unbalanced: while the machinery is underutilized, there is a serious overrun in HR-capacity in weeks 33 and 36, which must be solved by rescheduling or expanding the capacity.

82 | 2 Focus on Production Planning Systems (PPS)

2.4 Production Control Everything that was calculated and planned in chapter 2.3 took place before starting the real production with transforming materials, consuming energy and so on. So far, it is just a plan. In the MRP II concept, the IS support does not stop with planning; it also informs and controls during manufacturing execution. This is called production control and its central data object is the (actual) work order (WO), which is mostly derived from a planned work order (PWO). The following figure shows the process of production control. Steps 1 to 4 sound just like production planning above – however, it goes one level deeper and cares about the actual micro planning for when to turn on what workplace. Steps 5 to 8 are the core of manufacturing execution – getting the material ready and transforming it in work centers on the shop floor. In ERP Systems, the execution of production orders triggers the actual manufacturing and transformation and has many implications. From a material view: raw material might leave storage and (semi)finished goods might go into storage after production. From an accounting view: expenditure for goods leaving storage go into the books and semi (finished) goods entering storage will book a rise in inventory in the balance sheet. These actions are triggered in steps 9 to 11.

1. Order creation Order header

2. Availability check

11. Order settlement

10. Goods receipt

3. Scheduling Order header

9. Feedback

4. Capacity planning

Material components

Production resources/tools Costs Manufacturing Execution System (MES)

– Plan - Actual

5. Order release

6. Order printing 7. Material provision 8. Order execution

Fig. 2.20: Overview Production Control

2.4 Production Control | 83

Here is a description of the cycle sketched above: 1. The actual work order is created, perhaps from a planned work order or from scratch; 2. The available capacity will be checked for whether it is sufficient for the production. This includes material, capacity of machines and staff, production resources and tools; 3. Production orders are scheduled; 4. Capacity planning is performed and, if necessary, capacity leveling is triggered; 5. The production order is released for processing; 6. Necessary documents are created for processing the production order; 7. Provision of necessary materials at the work centers is organized; 8. Actual manufacturing takes place, perhaps supported by CNC machines, but generally not directly controlled by the PPS system, and perhaps by a MES (see chapter 2.4.3). 9. Actual data (times, quantities) is fed back into the PPS after processing of the production order; 10. Finished parts will be booked as addition to stocks; 11. The cost of the work order is calculated for accounting: It adds cost to the product calculation in management accounting and value is added to the (semi)finished product that will go on stock as inventory asset in the balance sheet. The single most important data object in production control is, therefore, the actual production order (PO) with its particular characteristics/fields.

2.4.1 The Production Order (PO) The actual production order is a data object that carries and triggers all important information in the production control process. The following figure shows its basic components. A PO will carry out one step of a routing/work plan for an object.

84 | 2 Focus on Production Planning Systems (PPS)

PO header

Operation

Materials

Tools and Production Resources Cost

- Actual - Planned

Fig. 2.21: Production Order – Important Elements

Basically, a PO looks almost identical to a PWO described above and contains similar basic components. The header contains basic data, like the suggested timing, the material to be manufactured, assigned BoM, and more administrative data. The vast amount of information is grouped in tabs like “general”, “assignment”, “goods receipt”, “control data”, and so on.

2.4 Production Control | 85

Fig. 2.22: Production Order Information

Besides the header and its information, the PO contains two essential lists: components and single work steps. Of course, components stem from the BoM and the production steps stem from the routing. The operation overview shows single work steps for a PO. The activities are derived from routing of a certain component; here it is the “Pump PRECISION 100”.

86 | 2 Focus on Production Planning Systems (PPS)

Fig. 2.23: Operation Overview

The list of components needed for this PO is derived from the BoM of the product that is assigned to it.

Fig. 2.24: Component Overview

An integral part of a PO in an ERP system is cost calculation. Every PO will consume material and worker time, and after the PO is carried out, the product being worked on will have gained value. This must be documented for management-, financialand tax accounting: time and material that goes into working on a product will be an “expenditure” in the profit and loss statement, and will add value to the inventory of semi-finished goods/work in progress that will be documented.

2.4 Production Control | 87

Fig. 2.25: Display Material Cost Estimate with Quantity Structure

So for every PO, there will be a “monetary shadow” of resources consumed and value added. The values are called estimates because they simply multiply planned prices with the planned quantity of resource consumption. This might change after the actual information of PO execution is fed back into the PPS. There are many reasons for deviations between planed values and actual values (see chapter 2.4.4). Actual POs can originate from two sources:  A PO can be created from scratch by entering the information manually or being copied from previous PO in the system.  A planned work order PWO is converted into an actual PO with all the information of the PWO being copied into the actual PO.

88 | 2 Focus on Production Planning Systems (PPS)

2.4.2 Timing of Production Order So far, we have explored the contents of the PO, but not when the PO will be launched. While the timing in chapter 2.3.2 above was focused on final dates for certain customer orders to be finished, the timing of production orders fine-tunes, and maybe optimizes, the actual start of POs, including such details as setup times, waiting times, retooling and so on for every single process step. The following figure shows a PO and its single process steps, in which process step 0040 is detailed.

Cycle time of order

PRS 0010

Waiting time

PRS 0020

PRS 0030

Set-up time

PRS 0040

Processing time

PRS 0099

…

Clearing time

Execution time for process step

Safety time

Idle period

Quality check and storage

Transport time

Transitional period

Fig. 2.26: PO Single Process Steps

This will give a clear figure of the detailed length of every step. However, it still does not give the absolute starting time of the first process step. There are two main ways of calculating the start and scheduling process steps:  Backwards Scheduling: The basic way to calculate production: the day the finished good is needed by sales is known, and all steps are calculated backwards.  Forward Scheduling: A given day (like today) is set for start, and all other dates will be calculated. 3 For more details, consult literature for your ERP system, or “Production Orders” SAP 2001, p. 93, or other literature about planning.

In order to optimize production and balance the capacity, it might be necessary to shorten cycle times. There are basically three methods of shortening cycle times: splitting, overlap and lot division. These methods are described in literature about production organization and do not need to be repeated here.

2.4 Production Control | 89

2.4.2.1 Availability Check In a perfect world, there would be no need for an availability check. Exploding the BoMs would produce PWOs for semi-finished goods and purchase orders for raw material, and they would be accessible at the time of actual manufacturing. However, there are some more influences between the MRP and actual production that will lead to a gap between plan and reality: e. g. procurement might want to aggregate purchasing orders to get better prices or optimize logistics for a bigger lot. There might be unplanned scrap or downtimes in previous production steps. A shipment might be delayed by customs or weather conditions and so on. So in manufacturing reality, before starting real production and transformation of materials, there must be an availability check to determine whether all required resources will be really accessible. A dynamic availability check is carried out by the so called ATP (available to promise) method. ATP is closely connected to sales distribution and the concept of supply chain management. With this method of calculation the system checks whether, at a planned point of production, the required quantities of materials really will be accessible. It uses all information available from internal systems like in-transit inventories, inventory forecast and also additional information from suppliers. If the availability cannot be guaranteed for the start of production order, it will determine the time when all material will be available in order to reschedule the PO to fit availability. The fewer inventories in stock – an important target in modern production – the more sophisticated the calculations must get. In the inefficient case of very high inventories, the necessity for availability checks becomes less important. Consider the following example of three components from a BoM of product scheduled to be produced. Required quantity

ATP quantity

Confirmed quantity

Component 1

100

200 (OK)

100

Component 2

100

50

50

Component 3

100

300 (OK)

100

Commitment Factor 50%!

Fig. 2.27: ATP Example

In case one or more components of the PO are below desired level (here: component 2), the maximum amount of all materials in this PO will be reduced pro rata to the level of the material being least available (here: component 2). Since there will be only 50 % of the desired amount of component 2 available, the complete output of this PO will be reduced by 50 % and all other (available) components will be reduced accordingly. This factor is called commitment factor, in this case it is 0,5 (= 50 %).

90 | 2 Focus on Production Planning Systems (PPS)

Table 2.1: Commitment Factor

Component 1 Component 2 Component 3

Required quantity

ATP-quantity (Confirmation factor 50 %!)

Confirmed quantity

100 100 100

200 50 300

100 × 0,5 = 50 100 × 0,5 = 50 100 × 0,5 = 50

With this calculation, some of components 1 and 3 are freed to be used in another PO and the PO calculated above only claims amounts of material it will actually need.

2.4.2.2 Releasing the Production Order After everything is ready for production, meaning the capacity of work stations and the materials are checked to be available, the PO is actually released. This release may come in different flavours:  If a single PO is released, the PO itself with all its steps will be authorized and started.  Also more than one PO can be realized. For this purpose, the PPS will provide an overview over POs which can be filtered by various criteria. So there might be a batch release in the system, which makes work easier.  It is also possible to start certain steps of the PO without releasing the entire PO. Since the steps of a PO form a logical sequence according to the underlying routing, only those steps may be released whose predecessors are also released or are already executed. Releasing a PO one way or the other has several consequences:  Orders are given to get the material out of stock and onto the shop floor.  The decrease in inventories used for realizing the PO is entered into the books of financial and management accounting.  There might be direct orders to workers on the shop floor about what to do now.  In a highly automated environment, machines involved in actual transforming of materials might actually be activated. In other words: The release of a PO is the actual transition from the world of planning into the world of materials and real doing. This step is also a kind of handover from PPS (or ERP if the PPS is part of it) into the shop floor and its systems.

2.4 Production Control | 91

Between releasing the PO and confirmation of the PO by the shop floor, manufacturing happens in a black box, a kind of “elsewhere” for the PPS. Only when the PO is confirmed to be executed does the PPS pick up control again. Most of the actual technical control over material transformation is not monitored in the PPS, but in systems called MES (Manufacturing Executive Systems). Of course, there are ways to integrate MES with PPS; however, they do constitute an own world “below” the ERP/PPS world and will, therefore, be explained in a separate chapter (4.3).

2.4.3 Production Order Control via Manufacturing Execution Systems (MES) On the shop floor, another system takes control of the execution of production order: the MES. The following figure shows such a system. The blocks on the screen represent single workstations and machines. The system informs the production executive about the state of machines and their functions. The standard reference model for the IS on the shop floor with four “levels” can be seen in the figure below. During manufacturing, the progress of production is monitored by MES (Level 3), which sends information (via manual entry or automated) to the level above, the PPS module within an ERP (level 4). Such information includes material withdrawal, quantities of yield, scrap and reworking produced, uptime and downtime of machinery and so on. Important functions in level 3 are the steering of the production flow and reaction to unexpected events like downtimes. MES is the software running on production control centers.

92 | 2 Focus on Production Planning Systems (PPS)

Level 4

Business Planning and Logistics

Level 3

Manufacturing Operations Management

Level 2 Batch control

Continuous Control

Level 1 Level 0

CNC Machinery

Establishing the basic plant schedule – production, material use, delivery and shipping determining inventory levels

Managing the work flow to produce the desired end products. Maintaining records and optimizing the production process

Discrete control

Monitoring, supervisory control and automatic control of the production process Sensing and manipulating the production process Production process

Fig. 2.28: Standard Reference Model for IS in Manufacturing (Based on ZVEI 2001, p. 9)

One level deeper than MES, there is shop floor data collection (level 2). These systems are also known by the name SCADA (supervisory control and data acquisition). On level 1, sensors and manipulators for steering the manufacturing flow are employed. These include cameras, scanners, control of transfer line speed and track switching. The base level 0 is the actual material transformation by machine tools like CNC turning and CNC milling.

2.4 Production Control | 93

The following figure visualizes which IS types and according hardware is used on those four levels.

ERP,APO, Logistics Systems

>ĞǀĞůϰ

Business Process Information Network

MES,LIMS,WMS CMM Systems

>ĞǀĞůϯ

Operations Information Network HMI, SCADA Batch Systems

>ĞǀĞůϮ Automation Network

PLC,DCS, Packaged Systems Discrete & Process Device Communication Network >ĞǀĞůϭ

I/O Devices, Sensors Material Production

>ĞǀĞůϬ

CNC Machines

Fig. 2.29: IS Types and Hardware (Based on Brandl/Owen 2003, p. 27)

These four levels may be connected in a purely logic sense with paper being produced by one level and entered into the next one. On the other extreme of the scale of automation, there would be full digital integration: after many automatic steps and calculations, a customer order (level 4) would cause a CNC machine (Level 0) to start milling according to customer specification. The flow of information that was generated in the PPS in Level 4 and was handed down into the deeper levels will flow back during the manufacturing process until it finally re-enters the PPS as “production confirmation” in the form of an order completion message. At this step, the PPS regains control of further processing and logistics until the finished good is delivered to the customer.

94 | 2 Focus on Production Planning Systems (PPS)

2.4.4 Work Order Completion Message in the ERP-System An order completion message from the shop floor via manual entry or via automated import is necessary to get the following information:  How much yield, scrap and need to rework was produced in the PO?  At what workstation was the PO actually carried out? It might have been possible to switch machines on short notice due to a failure in the planned machine.  How much human resources and machine capacity was actually taken to carry out the PO – there might have been deviances from the original plan.  Finally, what person was issuing the order completion message? 4 Please note: In SAP, the name of the order completion message is “production order confirmation”. However, this term is also used in sales – that's why it is avoided here.

An order completion being entered and accepted in the system is then processed and triggers several important further processes and events automatically in the background:  All data of the original customer or sales order (see chapter 2.3 ) are updated to actual dates, quantities, services rendered, resources consumed (for cost calculation) and status of the output (fine, scrap, rework). In the cascade of POs that finally make up a finished good, all information is dynamically updated in real time.  If the use of unplanned additional material during production was fed back into the PPS, it has to be booked in accounting now.  If the produced semi-finished or finished product is planned to go in stock, rise of inventory hast to be booked in monetary terms and in quantity.  The actual load/capacity use of a workplace will be documented.  Cumulated cost of production will be updated according to the data reported by the confirmation note.  Data will be transferred automatically to HR for piece-work compensation or other performance-based pay. With the PO confirmation, the information cycle of PPS for manufacturing is closed.

2.5 Summary of Chapter 2 Operative PPS Systems represent the core IS support of modern production management. They are often part of a larger ERP-System like SAP. Functions and modules of PPS Systems are derived from the MRP II concept. The key master data are materials (and their numerous characteristics), Bills Of Materials (BoMs) and work plans (routings).

2.7 Review Questions for Chapter 2 | 95

Correct execution of actual production planning is highly dependent on correct master data and consists of the three steps of quantity planning (from BoMs and desired production of finished goods), scheduling of production steps (derived from routings), and harmonizing capacity needed according to the plan and capacity being really readily available. Once the production plan is executed and real physical production takes place, the PPS supports production control employing the Production Order as the central data object. However, the PPS usually does not extend into control of the shop floor and the machines. This is the world of MES and other systems, which might get data from the PPS and close the cycle of production planning and real production by issuing work order completion messages for the PPS module in the ERP system.

2.6 Literature for Chapter 2 Brandl, D.; Owen, P.: Manufacturing Operations Management, University of Cambridge – Institute for Manufacturing 2003, http://www.brlconsulting.com/Files/2003-09 IEE Cambridge-V03.ppt Hackstein, R.: Produktionsplanung und -steuerung (PPS) – Ein Handbuch für die Betriebspraxis, VDI-Verlag Düsseldorf 1989. SAP: BoMs (PP-BD-BoM), SAP online help 2001, http://help.sap.com/printdocu/core/print46c/en/data/pdf/PPBDBoM/PPBDBoM.pdf SAP: Capacity Planning (PP-CRP), SAP online help 2001, http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PPCRP/PPCRP.pdf SAP: Production Orders (PP-SFC), SAP online help 2001, http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PPSFC/PPSFC.pdf SAP: Standard Material Types, SAP online help. http://help.sap.com/saphelp_45b/helpdata/en/ff/515afd49d811d182b80000e829fbfe/ content.htm SAP: Work-Centers, SAP online help 2001, http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PPBDWKC/PPBDWKC.pdf ZVEI: Manufacturing Execution Systems (MES), Frankfurt a. M. 2011, http://www.zvei.org/Verband/Publikationen/Seiten/Manufacturing-Execution-SystemsMES.aspx

2.7 Review Questions for Chapter 2 2.7.1 True/False: Elements of MRP Please check all tasks that are NEW in the MRP II concept and NOT contained in earlier concepts like MRP and Extended MRP I. 1)

Prepare execution of work orders and feedback shop floor results

2)

Explode BoMs

96 | 2 Focus on Production Planning Systems (PPS)

3)

Calculate net requirements of material

4)

Translate sales planning into production planning

5)

Calculate Date of Production

6)

Optimize load of limited machine capacity

2.7.2 Close: Functions of MRP II – Steps Please assign the term to the right position in the figure.

Subdivisions

Functional groups

Production control

Data management

Production planning

Functions

Production Program planning

a)

Quantity Planning

b) Production ordersn

Scheduling and capacity planning

c)

Order release

d)

Order monitoring

e)

Purchase ordersn

1)

Lead time scheduling, Capacity requirements, Determination and coordination, Sequence planning

2)

Production document preparation, Production order release, Work distribution

3)

Forecasting, Rough planning, Delivery date determination, Customer order management, Lead time control

4)

Capacity groups, Customer order monitoring, Production order monitoring

5)

Determination of requirements, inventory record keeping, Procurement calculation

2.7.3 Close: Elements in MRP II Explained For each gap, please choose the correct word to complete the sentence: 1)

The task of [Production program planning, Material planning, Net requirements, Job order planning, Capacity planning, Order monitoring] is to determine the type, quantity, manufacturing date and quality of material needed to realize the production quantities from the production program planning. For

2.7 Review Questions for Chapter 2 | 97

this task, there are consumption-based and deterministic requirements planning models available. 2)

[Production program planning, Material planning, Net requirements, Job order planning, Capacity planning, Order monitoring] summarizes existing customer orders and creates a production program that defines which final product in which quantity at which date needs to be produced. Besides this way, a first rough planning is performed checking whether available capacities are sufficient.

3)

Within [Production program planning, Material planning, Net requirements, Job order planning, Capacity planning, Order monitoring] actual times and actual quantities of production will be reported. This delivers an up-to-date overview about the state of production orders and customer orders, as well as usage of capacities.

4)

Calculations for [Production program planning, Material planning, Net requirements, Job order planning, Capacity planning, Order monitoring] consider information about products, components and parts still in stock. For unmet demand planned, work orders or purchase requests will be created.

5)

[Production program planning, Material planning, Net requirements, Job order planning, Capacity planning, Order monitoring] creates the required production orders to cover the production program. The production orders will be scheduled, the required resources will be checked for availability, and the working documents prepared.

6)

[Production program planning, Material planning, Net requirements, Job order planning, Capacity planning, Order monitoring] determines required capacity and available capacity for production orders. In the case of overlap or shortfall, action for capacity coordination will be taken. The result will be an exact sequence of orders and their operations at the work places.

2.7.4 Close: Different Material Types For each gap, please choose the correct word to complete the sentence: 1)

[Spare parts, Finished products, Production resources/tools, Semi finished products, Raw materials] are procured externally and used in production or plant maintenance. A material master record of this material type can contain purchasing data, but not sales data. Examples include jigs and fixtures, and measuring and test equipment.

2)

[Spare parts, Finished products, Production resources/tools, Semi finished products, Raw materials] are produced in-house to be sold later by the compa-

98 | 2 Focus on Production Planning Systems (PPS)

ny. Since they cannot be ordered by purchasing, a material master record of this material type does not contain purchasing data, like a price. 3)

[Spare parts, Finished products, Production resources/tools, Semi finished products, Raw materials] are used to replace defective parts. They may be kept in stock. A material master record of this material type can contain purchasing data, but not sales data.

4)

[Spare parts, Finished products, Production resources/tools, Semi finished products, Raw materials] can be procured externally and manufactured inhouse. They are further processed by the company. A material master record of this material type can contain both purchasing and work scheduling data and even might be sold.

5)

[Spare parts, Finished products, Production resources/tools, Semi finished products, Raw materials] are always procured externally and then processed. A material master record of this type contains purchasing data, but not sales data since they usually are not sold by a manufacturing company.

2.7.5 Choose: Categories of BoMs What three categories of BoMs are frequently used in PPS? 1)

Material BoMs

2)

Customer BoMs

3)

Equipment BoMs

4)

Document BoMs

5)

Raw Material BoMs

6)

Purchasing BoMs

2.7.6 Close: Types of BoM’s For each gap, please choose the correct word to complete the sentence: 1)

A so-called [multilevel BoM, single level BoM, quantity BoM] contains all parts of the product, sometimes even several times: if a part like a bolt is needed in several levels of manufacturing, it will be listed several times with the according level in which the bolt(s) are used.

2)

In a [multilevel BoM, single level BoM, quantity BoM], a product is just split into modules once, but not further. These modules are split in other submodules by another [multilevel BoM, single level BoM, quantity BoM]. Consequently, there is no need for determining the level.

2.7 Review Questions for Chapter 2 | 99

3)

A [quantity BoM, multilevel BoM, single level BoM] adds up the amounts of a single material wherever it is needed in the production process, so there is no information about levels needed. This BoM rather tells how much is needed to manufacture the product. This is the same kind of list a worker in the warehouse uses to pick part for a certain manufacturing process or a shipment to a customer (pick-list).

2.7.7 Choose: Purposes of a Work Center Check all purposes of a work center: 1)

Scheduling operating times and formulas for calculating operation duration in the work center are maintained in the object work-center.

2)

Organize workers in the most effective way according to their skills.

3)

Formulae for calculating the order and production cost are entered in the work center. Also, work centers are assigned to a cost center, which is relieved by order confirmation – it then passes on the cost onto the object.

4)

For capacity planning, among other things, the available capacity and formulas for calculation of the capacity demand of an operation are stored in a workcenter.

5)

Optimizing the design of a product in order to reach overall lowest cost and improved quality.

2.7.8 Choose: Purposes of a Work Plan (Routing) Check the 5 items of information contained in the data object “work plan”: 1)

List of steps to fulfill the objectives of this work plan

2)

Tasks to do in a single step as basis for calculating dates, capacity requirements and cost calculation

3)

All elements of a product in an ordered hierarchy and with overall quantities

4)

Materials used in a single work step

5)

Lead time, scheduling data and available capacity

6)

Costing data for human resources and associated machinery

7)

Work places and works centers involved in executing a work step

8)

Criteria for a quality check for a workstep that determine whether this step will be viewed as successfully executed

100 | 2 Focus on Production Planning Systems (PPS)

2.7.9 Calculation: Exploding a BoM for Calculating Needed Quantities In order to produce 10 units of the finished product/independent requirement, calculate the amounts (units or kg) needed for R1, R2 and R3. There is no material in stock. 1 unit

3 unit Component C1 1 unit Raw material R1

2 unit Component C2

1 unit Raw material R2

4kg Raw material R3

1)

R1:

2)

R2:

3)

R3:

4)

New information: There are still 15 units of component C2 on stock. So the need for R3 is:

2.7.10 Calculation: Calculating Lead Time and Start of Production For the production plan below, the following lead times are assumed for the planned work orders (PWO): PWO P1: 3 days, PWO P2: 3 days, PWO P3: 2 days, PWO P4: 2 days, PWO P5: 2 days

PWO P1

Finished Product

Component C1

PWO P2

Component C2

Raw Material R1 Raw Material R2

PWO P3

PWO P4 PWO P5 Time

Requirement Date

If sales needs the finished product by April 30th – when does PWO 4 need to start?

2.7 Review Questions for Chapter 2 | 101

2.7.11 Close: Capacity Offered For each gap, please choose the correct word to complete the sentence: Capacity is ultimately offered by existing [work centers, bill of materials, work plans, machines] in the company. There are different “capacities”, e. g. for regular production and some reserved for [building machinery, very urgent orders, retooling, tear down time]. Also, two main types can be distinguished: capacity of [financial resources, machinery, space, purchasing] and of [energy, human resources, management, work breaks]. [100 %, 90 %, Not 100 %, 50 %] of the full 24/7 potential (standard capacity) of machines is available. There are many limitations, like unplanned downtimes, maintenance, holidays and so on.

2.7.12 Close: The Cycle of Production Control Please assign these steps to the figure.

1. Order creation Order header

2. Availability check

11. Order settlement

d)

a) Order header

9. Feedback

4. Capacity planning

Material components

b)

Production resources/tools Costs Manufactoring Execution System (MES)

– Plan - Actual

6. Order printing 7. Material provision c)

1)

Order Release

2)

Goods receipt

3)

Order execution

4)

Scheduling

102 | 2 Focus on Production Planning Systems (PPS)

2.7.13 Choose: Production Order A Production Order (PO) looks almost identical to a: 1)

Customer Order

2)

Purchasing Order

3)

Planned Work Order

4)

Sales order

2.7.14 Choose: PO Single Process Steps Assign the right elements to the figure. Cycle time of order PRS 0010

PRS 0020

Waiting time

PRS 0030

a)

PRS 0040

PRS 0099

…

b)

e)

Idle period

c)

1)

Transitional period

2)

Processing time

3)

Clearing time

4)

Set-up Time

5)

Execution time for processing step

Quality check and storage

Safety time

Transport time d)

2.7.15 Calculation: Availability Check Calculate the confirmed quantity according to ATP. Component 1 Component 2 Component 3

Required quantity 80 100 100

ATP-quantity 200 60 300

Confirmed quantity a) b) c)

2.7 Review Questions for Chapter 2 | 103

2.7.16 Choose: Releasing the Production Order Please check four events that result immediately in releasing a production order: 1)

Orders are given to get the material out of stock and onto the shop floor to be worked on.

2)

The decrease in inventories used for realizing the PO is entered into the books of financial and management accounting.

3)

All data of the original customer or sales order are updated to actual dates, quantities, services rendered, resources consumed (for cost calculation) and status of the output (fine, scrap, rework).

4)

There might be direct orders to workers on the shop floor about what to do now.

5)

If the produced semi-finished or finished product is planned to go in stock, rise of inventory has to be booked in monetary terms and in quantity.

6)

The actual load/capacity used of a workplace will be documented.

7)

In a highly automated environment, machines involved in actual transforming of materials might actually be activated.

8)

Cumulated cost of production will be updated according to the data reported.

2.7.17 Close: Standard Reference Model for Manufacturing Related IS Please choose the right words for the concepts and their place in the standard reference model: 1)

On level [1,2,3,4] of the standard reference model for manufacturing IS Monitoring, supervisory control and automatic control of the production process is realized by [Business planning and logistics, Manufacturing operations management, Batch/continuous/discrete control].

2)

On level [1,2,3,4] of the standard reference model for manufacturing IS establishing the basic plant schedule, like production material use, delivery and shipping, and determining inventory level is realized by [Business planning and logistics, Manufacturing operations management, Batch/continuous/ discrete control].

3)

On level [1,2,3,4] of the standard reference model for manufacturing IS Sensing and manipulating the production process is realized by [Business planning and logistics, Manufacturing operations management, Batch/continuous/discrete control].

4)

On level [1,2,3,4] of the standard reference model for manufacturing IS Managing the work flow to produce the desired products, maintaining records and optimizing the production process is realized by [Business planning and logistics, Manufacturing operations management, Batch/continuous/discrete control].

104 | 2 Focus on Production Planning Systems (PPS)

2.7.18 Choose: Information Contained in a Work Order Completion Message Please check 4 items that are directly contained in the work order completion message of a released and executed production order: 1)

How much yield, scrap and reworking was produced in the production order.

2)

Updated cost calculation of the product.

3)

Budget deviation analysis of all workplaces involved.

4)

At what workstation was the PO actually carried out. It might have been possible to switch machines on short notice due to a failure in the planned machine.

5)

Sensor and maintenance data of machinery involved.

6)

How much human resources and machine capacity was actually taken to carry out the PO  there might have been deviances from the original plan.

7)

Warning of cost or budget overrun.

8)

Person who was issuing the order completion message.

2.8 Suggestions for Written Exercise or Groupwork for Chapter 2 2.8.1 Exploding BoM and scheduling You are given the following a BoM, material in stock, and lead times:

PWO P1

Finished Product

1 unit Component C1

PWO P2

Component C2

3 unit Component C1

Raw Material R1

1 unit Raw material R1

PWO P3

2 unit Component C2

1 unit Raw material R2

4kg Raw material R3

Raw Material R2

PWO P4 PWO P5 Time

Element

In Stock

Lead time for manufacturing/replenishment

Final product

50 units

PWO 1: 2 days

Component C1

30 units

PWO 2: 1 day

Component C2

40 units

PWO 3: 2 days

Raw material R1

300 kg

Enough in stock: No PWO necessary/created

Raw material R2

10 units

PWO 4: 4 days

Raw material R3

15 kg

PWO 5: 5 days

Requirement Date

2.8 Suggestions for Written Exercise or Groupwork for Chapter 2 | 105

Since PWO 4 and 5 are actually purchase orders, their length means simply replenishment time from order to accessibility in production. The customer demands 100 units of the finished good on the 30th of July. How much and when do you need to order raw material R2? Please calculate explicitly how you get the number.

2.8.2 MES and Below For a highly computerized manufacturer of standard plastic parts, please explain how computers help his production in level 4, 3 and 2 as described in 2.4.3. Please stick to the example here – no generic rephrasing from literature or the examples in this chapter, please.

3 Integration of Information Systems: Forms, Methods and Concepts There are information systems and applications for almost every department on every level. These applications need to work together to support company processes. This chapter gives an overview of how this is achieved and what forms, methods and concepts of integration enable the cooperation of applications. After this chapter, you should be able to …  … distinguish objects, directions and range of integration with real-life examples.  … evaluate the optimal level of integration according to its advantages and disadvantages.  … describe the business needs for Product Data Management.  … sketch the basic structure and processes of a Data Warehouse.  … execute a simple OLAP Analysis with a pivot table.  … recognize traditional technologies for integrating applications and data when given real-life examples.  … evaluate the standard components of a web-service and the needs and steps for improving the web service technology stack.  … describe the advantages of using intercompany standards in the three areas of standardization needed. In total, this Chapter requires 14 hours of your time. This includes reading the chapter and additional literature, answering reviewing questions, and writing an exercise.

3.1 Introduction: Integration of Information Systems Chapter 2 strongly focused on a single application and rightly did so: the processes and needs of different functions in a company make their supporting IS very different. However, it is also obvious that these IS need to operate “together”. There has to be some form of integration or coordination between them. This is especially true from a company process perspective: processes do not care about company organization and functions. So, several single IS have to be integrated in order to support a whole business process. Please note: This does not necessarily lead to integration in one monolithic system, like an omni- 3 present ERP, as the word “integration” is sometimes misunderstood.

108 | 3 Integration of Information Systems: Forms, Methods and Concepts

There are many aspects/dimensions to the term “integration” and many solutions to the call for integration, which will be explored in this chapter.

3.1.1 Direction, Methods and Automation of Integration Integration is action being taken (“we are integrating our system”) and a final state (“our systems are now integrated”). However, this does not tell us what integration looks like. To describe an integration that is planned or required, at least five questions have to be answered: what is the object, the direction, the scope, the level of automation and the time of integration? The following figure structures these different aspects of integration:

Integration of Information processing

Object of Integration

Direction of Integration

Data

Horizontal

Functions

Vertical

Objects Processes

Range of Integration Area extensive Functional area- and process comprehensive

Degree of automation Full automation

Date of Integration Batches Real-time

Partial automation

Methods Internal

Programs

Intercompany

Fig. 3.1: Integration of Information Processing (Based on Laudon/Schoder (2012), p. 466)

Probably the most difficult decision is the method of integration that means what should be integrated:  Product data via a common database like in a PDM (see chapter 3.3.2)?  Functions that are used in more than one program like “address entry” used in different functional silos?  Processes like a sales order that might use many different programs below it, and the business process being orchestrated by a workflow management system (see chapter 1) and realized by a SOA (see chapter 3.4.4)?  Programs for different departments like accounting and production planning in an ERP-IS?

3.1 Introduction: Integration of Information Systems | 109

Talking about integration, designing a concept for integration or forging an integration strategy requires us to think about all aspects of the term described in the figure above.

3.1.2 Benefits and Risks of Integration So is “system integration” inevitable and should it be pursued by every company to its maximum extend? Maybe some software vendors will make a strong case for the advantages of integration. However, integration is not a magic bullet with all advantages and no downside at all. The pros and cons of integration of formerly isolated IS have been debated for at least 30 years now. These are some results of this discussion: – Integration overcomes artificial boundaries of departments, functional areas and processes. As described in chapter 1, the needs of internal and external customers do not care about boundaries a company has created to organize itself. – The point above can be extended to boundaries between companies: modern concepts of collaboration like Supply Chain Management (SCM) in technical companies or Efficient Consumer Response (ECR) in trade are based on data integration. – Transferring data from one medium onto another, e. g. by retyping, occupies resources and reduces quality since every entry bears the risk of data mutation and might lead to errors. – Integrated IS enable a tighter control of processes and enable automation. – Integration reduces unwanted redundancy and avoids unnecessary data storage and documentation. It also reduces expenditure for data management and makes inconsistency of data more unlikely. – Multiple users might recognize errors in data more quickly and make individual manipulation harder. – Without system integration, integrated models of planning, forecasting and optimization are difficult to facilitate. As mentioned above, integration does not come free of cost. Some of the downsides might be:  There is a greater risk of chain reaction in case of errors. The tighter a system is integrated, the more elements are affected by the problems of other elements.  Integration might lead to inflexibility, since special needs and exceptions of the once-isolated functions cannot be imposed on the whole system.  The complexity of an integrated system requires more testing and maintenance.  Building the architecture of integration is costly and intellectually challenging. Personnel to achieve this might not always be available or may be very costly.

110 | 3 Integration of Information Systems: Forms, Methods and Concepts  External software components might be more difficult to add to a closely integrated system.  Decisions for integration usually cause high investment, which cannot easily be revised.  Customizing of integrated standard software proves to be costly and requires more training and other adaption effort.  In many cases, companies need to adjust their processes according to the software, and not the other way round. So, integration surely has its benefit and its cost. Also, it is not a binary decision: either integrated or not. Integration is, rather, a continuum between no integration of IS at all up to “total integration” of all IS into one. The following graph shows cost and benefit as two competing values with a kind of optimum degree of integration at I opt.

Cost/benefit of integration

Integration benefit through increase in efficiency Integration costs

I opt

Degree of integration

Fig. 3.2: Optimum Degree of Integration (Based on Laudon/Schoder (2012), p. 472)

So, ultimately choosing the optimal level and way of integration is a management issue. In the following chapters, we will explore some examples of vertical (operative + management) and horizontal integration (different operative company functions).

3.1 Introduction: Integration of Information Systems | 111

3.1.3 Vertical Integration via Programs in Functional Silos Let’s start with a seemingly simple solution to the issue of vertical integration. The IS pyramid you know from chapter 1 shows isolated areas where IS might be used. For each function like finance and accounting, there is a need for operative support, but also for support of middle management and even strategic decision.

System on Strategic level

Systems on management level

Sales management Sales area analysis

Systems on operative level

5-year 5-year Personal Profit turnover business planning planning forecast plan

Order Management

Sales and Marketing

Inventory analysis Production planning

Materials administration

Annual budget planning

Executive support systems (ESS)

Training costs monitoring

Productivity analysis

Personal accounting and accounts payable

Manufacturing Finance and and Production Accounting Functional areas

Management Information Systems (MIS)

Decision Contract support Costs analysis systems (DSS)

Operative Personal administration systems (TPS) Human Resources

Fig. 3.3: IS Pyramid (Based on Laudon/Schoder, (2012), p. 433)

The following table describes some systems and specifies their horizontal and vertical position in the pyramid.

112 | 3 Integration of Information Systems: Forms, Methods and Concepts

Table 3.1: Organizational Position of Real Systems in the IS-Pyramid (Based on Laudon/Schoder (2012), p. 443445) System

Description

Organizational position

Order processing

Used for entry, processing and tracking of orders. Used for setting prices for products and services. Used for 5-year-sales forecast.

Sales and Marketing Operational Sales and Marketing Management Sales and Marketing Strategically

Machine control system Production planning Choice of production location

Serves to control machines and equipment Supports decisions for determination of dates and quantities of production Supports decisions for choosing of locations for new production facilities

Manufacturing and production Operational Manufacturing and production Management Manufacturing and production Strategically

Debtors Budgeting

Serves for monitoring of outstandings/accounts receivables Serves for monitoring of current budgets

Profit planning

Serves for long-term planning of profits

Financial accounting Operational Financial accounting Management Financial accounting Strategically

HR accounting

Enables HR staff or systems to transfer salary to the correct bank account of customer Compares staff needed for current operations and staff available Compares the fit of the profiles and competencies of employees now and projected with the needs of future development of the market

Price analysis Turnover trend forecast

HR planning Strategic HR planning

Human Resources Operational Human Resources Management Human Resources Strategically

So, one way actually chosen by vendors and customers of IS is vertical integration within single company functions. E. g. a finance and accounting system started out simply by supporting keeping the books of a company (operative). Later, there were some fields added to enter planned values and to do a detailed deviation analysis at the end of the year (management). Finally, a module was added that calculates sophisticated financial key performance indicators (KPIs), like ROCE (see chapter 1) or liquidity ratios. If their actuals are compared to planned values and the system keeps a track record of historical data and threshold values for a warning, the IS is delivering a strategic warning system. The term “functional silos” means exactly this: IS staying in one company function, but serving all three “floors”: operative, middle management and strategic management. This seems like an effective thing to do, since data generated in everyday bookkeeping is always the base of financial KPIs; so why should there be two or three different programs for operative data and financial KPIs?

3.1 Introduction: Integration of Information Systems | 113

However, modern middle, and especially strategic, management is not satisfied with isolated information. Many companies, therefore, seek a vertical integration that incorporates information from more than one functional silo. This vertical integration of operative financial, marketing, production and sales data is facilitated by data warehouses (see chapter 3.2).

3.1.4 Horizontal Integration via Programs The other direction, horizontal integration, equally makes sense: a simple example is integration of accounting and sales, since both functions partially have a common interest in the same data. For example, sales wants to know whether a customer is a “quick payer”, information it needs for its regular customer evaluation. Also, both functions need basic master data about the customer, like name, address, and so on. The idea to use one common customer database for the addresses in sales and accounting comes very naturally. Within the company, such a horizontal integration often is realized by enterprise resource planning (ERP), an IS that offers fitting modules for several company functions like accounting, materials management, sales, and so on. Since ERP systems have gained such a dominant role in the modern IS landscape, this book dedicates an entire chapter on it (4); so there is no need to detail ERP systems here. However, in an ever-closely connected business world, horizontal integration does not stop at company borders. Formerly, ERP systems were not up to the task of closely integrating suppliers or customer data. The most important reason is the fact that, at heart, ERPs are focused on accounting, manufacturing and materials management. For an accounting system, only data that actually needs to go down in the books is relevant: a sale, a purchase, depreciation, creating provisions, and so on. However, integrating a company’s planning with the planning of its suppliers goes beyond purchasing, and includes special logistics data that has been of little interest to ERP systems in the past. Similarly, a full view of the customer requires not only sales data (recorded in accounting), but also information about future customers and communication with existing customers outside sales, like for example, in after-sales contacts. Specifically, two kinds of systems have established themselves in the market for horizontal integration: supply chain management (SCM) systems and customer relationship management (CRM) systems reach out to suppliers and customers. Of course, large ERP vendors like SAP and Microsoft Dynamics have reacted to that development and are now offering SCM and CRM programs/modules that can be closely connected to their core ERP systems. Some companies also have chosen to support SCM and CRM processes by using existing IS and connecting them via EAI (see chapter 3.4).

114 | 3 Integration of Information Systems: Forms, Methods and Concepts

Suppliers, Business Partners

Customers, Distributors

Processes Enterprise Systems Supply Chain

Processes

Customer Relationship Management Systems

Management Systems Processes

Sales and Marketing

Manufacturing and Production

Finance and Accounting

Human Resources

Functional areas

Fig. 3.4: Horizontal Integration (Based on Laudon/Schoder (2012), p. 478)

3.2 Vertical Integration via Data Warehousing (DWH) The integration in vertical silos (see chapter 3.1.3) has one severe setback: the upper level modules (management + strategy) can only use the operative data produced in their own silo. Data from other silos, or even external data, cannot be used directly, which contradicts the very meaning of the term “strategic information”. Since there are many different IS in functional areas of a company, this restriction limits the use for upper-level decisions. The solution is to take operative data from more than one source or function. However, this will not be as easy as integrating in a vertical silo, since the data in particular functional IS varies considerably in structure and content. The solution to this challenge is to consolidate and store data in one common IS, called data warehouse, as described in the following figure.

3.2 Vertical Integration via Data Warehousing (DWH) | 115

Operational Data

Internal Data Sources

Customer Data Manufacturing Data

Extract and Transform

Data Warehouse

Historical Data External Data Sources

External Data

Information Directory

Data Access and Analysis • Queries and reports • OLAP • Data mining

Fig. 3.5: Data Warehouse (Based on Laudon/Schoder (2012), p. 307)

Today, many enterprises use an ERP, which integrates several functional operative data sources like accounting, sales and production. However, there are still, and always will be, IS outside the ERP, so the problem is only partly solved and the value of a DWH still relevant. Recent developments are, for example, the use of huge amounts of data created by web servers in order to use them for data mining and offer cross-selling to customers. Table 3.2 shows the difference between operative systems (here in the typical form of an ERP) and Data Warehouses. A DWH is often the single most important source of information for MIS, DSS and ESS introduced in chapter 1. Please be aware that software vendors will find newer and catchier names for their DWH products. 3 In the last ten years especially, the terms “business analytics” and “business intelligence” were used. They all were built on and rely heavily on Basic DWH functionality. Whatever the names are, all of these solutions will need to tackle the issues in this chapter and use the methods described.

The following figure shows how SAP sees their business analytic solutions work together. It is a good example of how seemingly well-established terms are used very differently, especially in the practice of software vendors. SAP sees data warehousing as one aspect of business analytics. Other vendors and theories about IS would clearly argue that what SAP calls “Business Analytics” is really Data Warehousing and provides a base for all management applications shown in the figure.

116 | 3 Integration of Information Systems: Forms, Methods and Concepts

Table 3.2: Difference Between Operative Systems and Data Warehouses (Partly based on Gadatsch (2012), p. 286) Criteria Objective

ERP Systems Operational execution of business processes (e. g. sales processing)

Data Warehouse Provision of relevant information for decision from different data sources

Information content

Detailed information of business transactions for relatively short periods

Less detailed data. Compressed information for long-term periods

Data structure

Process- and/or function-oriented

Orientation at the facts and key issues for which a need for information exists for the decision makers

Requests

Structured standard requests

Performance at analyses

Poor, because of access to operational data

Structured standard reports Ad hoc requests Good, because of access to dedicated data base

History of data

No, on range at best.

Data is continuously updated and supplemented. Data will be marked with timestamps (date or period). With that, time series analyses are possible.

User

Person responsible Decision-making preparers

Top-management and controlling Middle management Decision-making preparers

Standardization

Data is standardized only within the system; however not standardized between different TLP systems.

Data taken from the source systems will be homogenously structured and formatted. Inconsistencies must be revised in advance.

3.2 Vertical Integration via Data Warehousing (DWH) | 117

Fig. 3.6: Business Analytics from SAP (Source: SAP 2011)

We will explore the issues at the core of vertical data integration, which is called business analytics in the figure from SAP. Data and methods might then be used for the applications shown above, and even newer ones. In the following chapters, we will describe how data comes into a data warehouse and how it is used to produce output.

3.2.1 Extract, Transform, Load Data into the Data Warehouse The way data from miscellaneous sources is coming into the DWH can be described by three tasks and is known by the abbreviation of ETL: Extracting the data from operative systems, transforming the data into a correct, uniform structure, and finally, loading it into the databases of the DWH. The following figure shows the context of these tasks:

118 | 3 Integration of Information Systems: Forms, Methods and Concepts

Data Warehouse – Database

Customers

Turnovers

Products

…

Loading programs Transformation programs

Staging Area

Extraction programs

Sales

Finance

Staff

Ext. Databases

Company internally

Internet

Company externally Data sources

Fig. 3.7: Extract, Transform Load (ETL)

3.2.1.1 Extraction of Data from Operative Systems Extraction means the selection of internal and external operative data and saving it to the so-called staging area. Since there will be quite some transformation necessary to convert the data to the desired structure, it does not make sense to load them directly into the databases and change them there. The staging area serves as a separate “workbench” residing in the RAM (Memory) that is prepared for transformation operation, quick saving and reading – virtues for which the final database is not well suited. The time for extraction can be set by different rules:  Regular intervals, e. g. every week  At request with a manual trigger, maybe when enhanced timeliness of data is required  Event based, for example, when the annual financial statement is published or when an external data source is signalling that it has been actualized The second question is: in which format and by what protocol should the data be transported? For example, a data dump from the ERP system in a CSV format (comma separated values) is sent to a FTP address and is, from there, accessed by loading procedures and transferred to the staging area.

3.2 Vertical Integration via Data Warehousing (DWH) | 119

3.2.1.2 Transformation of Data The transformation of data in the staging area is the core action of a DWH. Data to be suited for any analysis and outputs as described in chapters 3.2.2 and 3.2.3 needs to be cleaned up and reshaped into uniformity. Let’s start with the cleanup. Typical flaws in the data of operative systems are:  Simply wrong data (wrong addresses, typos)  Conflicting data (same address – different ZIP code?)  Redundant data (same address from several sources for the same person)  Outdated Data (old address)  Irrelevant data (fields with private notes of salespersons)  … and more … The amount of data processed in a DWH commands that as many of these corrections as possible be done automatically; otherwise it would be too costly. Three “classes” of errors or problems can be identified according to whether they are detected and corrected either manually or automatically. Table 3.3: Three “Classes” of Errors Error Type Detection Correction Syntactic (format) issues Example Solution

Semantic (content) issues Example Solution

Class 1 error automatic automatic Format adjustment necessary (known) “Euro” will always be changed into “€” Empty fields/ missing values Actual “reject rate” for 2010 is missing and will be filled with 2009 actuals or planned values 2010

Class 2 error automatic manual Format incompatible

Class 3 error manual manual (no such errors)

An entry “xyhV23,12E-1” should be changed into whatever is the right format Correction of obvious outliers by a defined variance threshold 100; 105; 1.02 ;103 1.02 is considered an erroneous outlier and replaced so the data will be 100; 105; 102; 110

(no such errors)

Undetected errors – simply wrong entry Customer A.J. Woytek classified as “reseller” is really “consumer”

120 | 3 Integration of Information Systems: Forms, Methods and Concepts

The second task after correcting errors is to alter the data structure while preserving the meaning. Several forms of transformation might be necessary here. Harmonizing: Different formats and coding from source data is set to a defined standard. For example, different entries in the field that defines gender in the tables of different sources like M/F, O/1, male/female, y/x are all converted to m/f for the DWH. Likewise, different metrics like US inches and European centimeters might all be transformed into millimeters. Aggregation of data might be necessary to reduce the amount of data. For example, the number of users accessing a website might be counted by the second, but maybe we want an hourly average only. Likewise, we do not need the numbers of employees for each workstation, but for the whole plant. Data once aggregated and sent to the DWH can never be split back again, so the level of aggregation should be determined carefully by the data granularity needed for later analysis. Enrichment might create new and previously nonexistent values from the data available in the operational systems. For example, values for a new column, “gross margin”, might be calculated by subtracting “cost of goods sold” from “revenue”. 1 The rise in computational power has enabled new concepts in data warehousing that are still being discussed. Specifically, “Big Data” seeks to enable real time access to volatile and huge amounts of data. Please research the term yourself to learn more about this current topic.

3.2.1.3 Load and Storage of Data into a Persistent Database After completing transformation operations in the staging area, clean and standardized data is loaded into the permanent databases of the DWH. After the initial filling, there is another optimization issue to be solved: what is the best way to keep the data up-to-date? Three basic methods exist and can be combined into a “loading strategy” for the DWH:  complete copy like at the initial filling: slow but secure  delta copies between regular complete copies of a bigger interval  incremental copies without any full copies after initial filling: quick but require good meta-data organization Another decision to be made is to choose the right “normalization” or “level of purity” in which the data is finally stored. There are two extremes with inverse advantages and disadvantages.  A high level of normalization or “purity” of data without any redundancies: every dimension (= column name) of a table is only stored once. This uses very little space and is thus a very efficient manner of storage. However, to extract readable tables for analysis described in the next chapter, the tables have to be joined together to make them readable again for OLAP reports or data mining.

3.2 Vertical Integration via Data Warehousing (DWH) | 121

 A less normalized storage keeps the tables at a more readable plain format, pretty much like a flat sheet in excel. This, of course, comes at the price of carrying redundant data, thus expanding the need for storage. Discussing those strategies in detail is beyond our scope and is well documented under the name snowflake (the pure, normalized) vs. star (the more readable with redundancy) scheme in data warehousing.

3.2.2 DWH Output: OLAP to Answer Known Information Needs Once the data is stored and available in a standardized way, it can be analyzed or, to be more precise: desired parts of data can be displayed in a desired structure and aggregation. This display of data is called online analytical processing, (OLAP). In order to do OLAP, users need to know of what they want to be informed. A starting example would be the analysis of downtime of machine tools in the factories of a company. In the data warehouse, every single downtime is recorded (maybe loaded from a Manufacturing Execution System, see chapter 2) with important facts: machine ID, time, start, length and reason of downtime which are stored in one flat table like an excel sheet (that means: not normalized), for easy readability. Table 3.4: Example Data Warehouse Base Table A 1 2 3

B

C

D

Machine ID

date of downtime

reason for downtime

230 240

21.10.2013 09:23 21.10.2013 09:57

maintenance failure

230

21.10.2013 10:31

retooling

4

240

21.10.2013 11:05

failure

5

230

21.10.2013 11:39

unknown

6

380

21.10.2013 12:13

retooling

7

240

21.10.2013 12:47

failure

8

380

21.10.2013 13:21

retooling

9

230

21.10.2013 13:54

maintenance

10

240

21.10.2013 14:28

unknown

11

380

21.10.2013 15:02

failure

12

…

…

…

122 | 3 Integration of Information Systems: Forms, Methods and Concepts

There are three basic terms in OLAP that will be illustrated with this example: Dimension: A dimension is the headline of the “columns”. In our table, that would be machine ID, date of downtime and reason for downtime. Dimensions can be aggregated and disaggregated in an orderly way. For example, the dimension “time” is recorded by the second. Seconds can be aggregated to minutes, minutes to hours, hours to days and so on. The structure of possible steps of aggregation and disaggregation is called a classification. The real content, the values inside the cells, is called a fact. “230”, “21.10.2013”, “09:23” and “maintenance” are facts of the first item in the list above. The example above shows a three dimensional table – of course, the number of dimensions is limited only by its usefulness; there are usually many more than three. Maybe our MES (see chapter 2) is delivering more information like “reported by whom”, “solution”, “restarted by”, and so on. However, since more than three dimensions cannot be displayed in a sensible way, OLAP is usually sketched as a cube for illustration; however, there are many more dimensions in most DWH tables. The following cube shows data from outlet sales of a company. The base table must, of course, record the lowest level of each dimension  that means the finest granularity of data. A row in the table must hold the facts, e. g. sales from one day in one outlet for one article. The following figure uses a cube to visualize these mechanisms.

Fact/ Key figure (e.g. sales)

Dimension 2 “Article”

Dimension 3 “Geography”

hammer nail

Point (x,y,z) Time.April, Product. Screwdriver, Geography. Kiel One Dimension.Elementname

screwdriver cable drum curtain paint brush

Hamburg one Luebeck one Kiel Two Kiel One

paint Jan Feb Mar Apr

Dimension 1 “Time”

Fig. 3.8: Data Cube

Let us assume that during the first four months of the current business year, a company made sales in several branch stores, selling different products. This results in one or more key figures, in this case the key figure “sales”, and three dimensions.

3.2 Vertical Integration via Data Warehousing (DWH) | 123

The cube’s cells contain the key figures’ values. The cube’s edges are defined by the dimensions. The number of edges, thus, equals the dimensionality of the cube. Every cell represents an incident that occurred, e. g. “The product screwdriver was sold in the month of April in KIEL ONE”. Every cell is unequivocally specified by its coordinates, e. g. (x,y,z), in the case of a three-dimensional room. Every single coordinate value here represents a specific characteristic of a dimension. This cell can, therefore, be defined by the coordinates: (Time.April, Product.Screwdriver, Geography.KIEL ONE). In this context, Dimension.Elementname represents a specific characteristic, i. e. a particular element of the given dimension. Let us now add additional details to the structure of such cubes. The following cube shows that each dimension is structured according to a classification hierarchy according to a certain classification scheme. The base table must, of course, record all items on the lowest level of classification in each dimension, e. g. sales of one day, in one branch for one article. The hierarchy of these dimensions may be subject to summations or divisions. Expanding details of a dimension according to its hierarchy is called “drill down” collapsing dimension is called “roll up”. Fact/ Key figure (e.g. sales) Category Group Article

Dimension “Geography”

Dimension “Product”

Day Classifi- Month cation Quarter scheme Year

Classification hierarchy Dimension “Time”

Fig. 3.9: Hierarchy of Dimensions in a Data Cube

124 | 3 Integration of Information Systems: Forms, Methods and Concepts

This cube now can be subject to “slicing and dicing” according to the needs of the user. One user might ask: give me the sum of all “handheld screwing tools” sales in KIEL ONE in the month of July 2013. Other managers might want to know different things. A product manager would rather know only yearly sales of specific screwdrivers, but is not interested in a separation of outlets or months at all. Users can “slice or dice” the arranged data in the hypercube with the provided dimensions to get an insight from different perspectives, as the following figure shows.

View of a regional branch manager

View of a product manager

hammer

View of a financial manager

nail screwdriv er cable drum curtain paint brush paint

Hamburg one Luebeck one Kiel Two Kiel One Jan Feb Mar Apr

Ad hocview

Fig. 3.10: OLAP operations Slicing and Dicing

Changing from much detail (day, single product, single outlet) to summed up less detail (years, category, countries) is called “roll up”. The other way around is called “drill down”, which illustrates quite well digging deeper into data.  Roll-Up = Aggregation of data = zooming out  Drill-Down = Splitting of data = zooming in The following figure shows a drill down of the dimension “time” from years to quarters to months.

3.2 Vertical Integration via Data Warehousing (DWH) | 125

Fig. 3.11: OLAP Operations Drill Down and Roll Up

You probably already have an OLAP tool on your computer: the pivot table function in Microsoft 1 Excel ®. It reads standardized, uniform tables (and only those!) in the way an OLAP cube does. Drilling down and rolling up is achieved by simply clicking on the dimensions.

3.2.3 DWH Output: Data Mining to Find Unknown Patterns and Correlations Using the same base data, but taking a very different approach is the concept of data mining. Here, the manager or analyst does not yet exactly know what she wants to know. She looks for patterns or correlations in data without knowing if and where they are there at all. Examples for possible situations in different industries and organizations are:  Are there any usable patterns in the downtime of your wind turbines? Is it maybe some hidden combination of weather conditions and previous downtimes?  In a series of burglaries spread across town – what do the victims have in common?  What is the typical situation where and when credit card fraud is likely to happen?  Our customer base increased and diversified so much: we cannot treat everybody the same and need to specify different sets of measures to different groups. Where are those groups and what do they look like? This is an analytical approach to “market segmentation” that will be efficiently targeted by a certain marketing mix.

126 | 3 Integration of Information Systems: Forms, Methods and Concepts

The figure shows the whole process of data mining. Some authors argue that formulating hypotheses and selecting data also belong to data mining. Instead, we stick to the narrow definition of the statistical process that will deliver these results. Data-Mining-System user

user

Setting Hypotheses

Selecting Data base

user

Analyzing Data base

Identifying interesting patterns

Interpreting results

DM in a narrow sense DM in a broader sense Fig. 3.12: Process of Data Mining

There are several methods to identify patterns, which all have a root in math and descriptive statistics. They are called multivariate analysis, which means there are more than two variables being analyzed and worked on. Such methods include:  Association: Characteristics attributed to a single event Example: What do typical downtime events look like?  Sequences: Connecting events over time Example: What are typical events at wind turbines before a downtime occurs?  Classification: Finding the right group in which an item/event belongs to by comparing it to other items that were already classified into a group: Example: What “kind” of downtime was the one that occurred last night?  Clustering: Creating groups of individuals in order to reduce complexity Example: Are there any distinguishable groups of downtimes for which we would create a standard procedure? Here is an example of an analysis using associating: we try to explain the reasons for our seemingly random downtimes of wind turbines. We need a structured uniform table from our DWH that holds all points of measurement from all turbines. This information then will be transformed into a binary code in order to enable statistical analysis. Here it is an association analysis that will render some results on which we might base maintenance decisions. The formula for association analysis is just illustrating the statistics happening there, not the actual formula. More

3.2 Vertical Integration via Data Warehousing (DWH) | 127

information on the methods above can be found in any book about multivariate statistics.

Geisler

Possible Results (figurative)

All downtime records 1. Wind turbine

Windspeed

Temp erature

Last in- Down or specion up?

4711

65

4

2 weeks

UP

4711

50

1

4 weeks

UP

4711

30

20

8 weeks

DOWN

2. 80% of downtimes happen beyond 7 weeks of inspection -> “cut inspection intervals to 6 weeks!”

transformation

interpretation

Records analysed

Wind turb.

wind < 40

wind < 60

wind > 60

Temp >5

4711

0

0

1

0

4711 4711

0

4711

0

4711

1

4711

0 1

0

1 0

1 0

1

0 0

0 0

0 1

0

Associations

Temp 5

60% of downtimes do occur in relatively calm whether conditions -> “it’s not the weather!”

0

1 0

0 1

0 1

Fig. 3.13: Data Mining: Example of Association

Another quite simple, but efficient, way is the quick filtering of mass data. If you search and find the phrase or book “The data warehouse toolkit” on Amazon and click on it, Amazon’s online data mining is activated and immediately recommends books that were bought in the same online shopping session and other purchases by customers who bought this book. This is calculated by a statistic method called “collaborative filtering”, that is closely connected to the methods described above.

128 | 3 Integration of Information Systems: Forms, Methods and Concepts

Fig. 3.14: Collaborative Filtering at Amazon (Source: Amazon.com)

It is safe to say that data mining techniques first used in consumer markets have not yet reached their full potential in technical industries, especially in the area of quality management and maintenance. Intensifying their use might be a source of competitive advantage for a technology-driven company.

3.3 Horizontal Integration of Design and Production Another important integration that has been intensely discussed for some 30 years now is the close connection between the two major areas of mechanical engineering: design and production, and IS that might facilitate integration. According concepts and IS-products are found by the name Product Data Life Cycle (PDL) and Product Data Management (PDM). Two core ISs that are involved are PPS (see chapter 2) and systems of design and development like CAD, which we left out in the first chapter and shall explore here briefly. PDM so prominently discussed today is actually realization of an “old” vision of the 1980s: computer integrated manufacturing (CIM). The historic context of developing a CIM vision in the 1980s was quite intriguing: since all functions in mechanical design, production planning, and production execution on CNC machines and materials management got more and more computerized – why not let them work together automatically? The connection was to be realized by standards and intelligent connection software. However, the task proved to be too complex, especially since the IS were not powerful enough at that time, nor were standards and interfaces up to the task. Billions of $ were spent, but the results were not seen as sufficiently profitable.

3.3 Horizontal Integration of Design and Production | 129

However, the vision and basic idea was good, as its selective realization today shows. The figure shows the original CIM vision. CAQ Computer Aided Quality CAE Computer Aided Engineering CAD Computer Aided Design CAP Computer Aided Planning CAM Computer Aided Manufacturing Product-related, Technical Information flow

Marketing Service

Product planning

Development (CAE) Construction (CAD)

Sales

Purchasing

Work preparation Production preparation Work planning Work controlling Production Production planning planning (CAP) and –control (PPS)

Quality assurance (CAQ)

Order-related, Dispositive Information flow

Production control Raw Materials SemiFinished Products Purchased parts

Stock Test field

Manufacture Of components

Maintenance Shipping

Assembly Transport

Products

Manufacturing (CAM)

Fig. 3.15: Original CIM Vision (Based on Gausemaier (2008))

Now in 2014 the vision of CIM is in closer reach and already implemented in some companies. The success factors that made it right this time were probably:  30 years after “CIM 1.0” IS and standards (e. g. internet standards) are much more capable and widespread.  The integration starts at the original core of the CIM vision: integration of PPS and CAD without overstretching the idea by trying to integrate “everything”.

130 | 3 Integration of Information Systems: Forms, Methods and Concepts

Maybe because it was such a disappointment in the first wave, the name CIM is no longer used by software vendors. The integrating products mainly go by the name of Product Data Management (PDM) today, and the revived CIM Vision is now called “Industry 4.0” or “Digital factory”.

3.3.1 Knowledge Based Systems in (Mechanical) Design As cited in the first chapter, but not detailed at that point, there is a class of operative systems that differ considerably from the TLP-IS in sales, materials management and accounting: the IS of product design and product development. Every engineer knows Computer Aided Design (CAD) and dominant players like AutoCAD, Solid Works, Inventor and so on. There are other areas of development that are computer aided besides design. This family of software products is called CAx, with x being the placeholder for engineering, quality, planning, robotics, and so on. In case you need to refresh your knowledge on CAx technologies – this can easily be done on the web. Here is just a very quick reminder of how these technologies would be involved in the development of e. g. a new engine:  CAD helps in the drawing of the engine, most likely in a three dimensional model  CAE (CA engineering) simulates running the engine and measures probable real life results in material deformation, noise, and vibrations, and helps in optimizing the design  CAP (CA planning) generates workplans (see chapter 2) that will be processed in actually manufacturing the product  CAQ (CA quality assurance) helps in setting the standards and measuring the outputs to ensure the quality desired is produced directly in design. So, CAx technologies cover one important branch of mechanical engineering: design and creation of the product. The other important branch of mechanical engineering is production engineering; the actual transformation of material and the assembly of parts and components to form a final product. This area is covered by PPS systems (see chapter 2), which are sometimes integrated as a part of an ERP (see chapter 4). Those two areas and their according IS were traditionally separated. It was common to print out a BoM created by a CAD system and then rebuild it by hand or via a semiautomatic import into the PPS. To overcome this obvious gap was the core of the original CIM vision of the 80s; however, it took some 25 years to implement this vision profitably.

3.3 Horizontal Integration of Design and Production | 131

3.3.2 Product Data Management (PDM) and Product Data Lifecycle Management (PDL) Every IS and every form of integration is merely a tool to reach overall objectives, like reducing cost and improving quality. So, this chapter will need to explain the advantages of integrating PPS and CAx technologies. Why does integration of these two streams of IS support benefit the technical company? The reasons for integrating CAD and PPS are driven by three dynamics:  Most companies are pressed by market forces and – consequently – marketing to offer many variants of the same product. So there are not just a few transitions between CAD and PPS, but many. If mechanical designers cannot access existing designs, they will create them anew, which leads to double work, cluttered master data and fragmentation in materials management.  Companies are forced to act quickly on the market since the lifecycle of products is ever shortening. One of the most successful German cars, the Volkswagen-Golf, started out in the 70s being produced for nine years. The lifespan of its successors shortened by a year at every release. Golf VI was succeeded by Golf VII after only four years. Renewing a product without quick access to previous versions of design documents like BoMs and routings might be too slow and too costly.  Not only the introduction of new products, but the complete documentation of its lifecycle, including all changes in design, materials used, components sourced from suppliers, and so on have to be documented at all times for legal reasons, quick problem response and spare part management. This lifecycle documentation is, by definition, a joint effort of design and production. The solution for these requirements is called product data management (PDM). There are many producers of PDM software, like big ERP vendors, CAD vendors and also many stand-alone products. They all have similar functions and structures in common: PDM systems have a database, in which all documents like CAD drawings, BoMs, workplans in all variants are stored in an orderly manner, and can be accessed by CAD programs and PPS alike. All new items and changes on existing items are controlled there in an efficient way, and their (re)usage is also managed by the system. A very important prerequisite for this is a common product classification system (see chapter 3.5) and a factory model with a company’s workplaces and processes. The figure shows how the production supported by PPS and design supported by CAx technologies work together and how they are integrated by PDM.

132 | 3 Integration of Information Systems: Forms, Methods and Concepts

Production program planning

Material requirements planning

Capacity planning

Production Manufacture order control CAM, assembly CAQ

PPS-System CAP Data Exchange or integration

PDM • Document management • Product structure- and configuration management • Classification • Process management • Project management

Distribution

Work planning

Prototype construction and testing

Data exchange or integration

CAE

Product Design

CAD

Product Data

CAX Process management

Product planning

Technical product development process

Fig. 3.16: Product Data Management (Based on Krause (2008), p. 14)

The model above suggests that access and control of data is limited to the time of actual manufacturing. Soon this model was amended by the dimension of time: management of product data is not just an issue of manufacturing, but is necessary at every point of a products lifecycle. To name just a few:  Sales may need detailed information about components and the final product (including assembly)  During use of the product by customers, maintenance and spare part management rely on this information  Finally, at the end of the lifecycle, strict laws in many western countries require information about the materials used and the way of manufacturing. This information is needed to take apart the product safely and for the greatest economic and ecologic benefit. The following figure shows information for each stage of the lifecycle, which might be retrieved via PDM integration.

3.3 Horizontal Integration of Design and Production | 133

Product lifecycle Product planning

Product development

Product manufacturing

Product sales

Product usage

Product disposal

Product data management Data management

Process management

Product and Process information

Fig. 3.17: Product Lifecycle (Based on Krause (2008), p. 12)

Every stage of the Product Lifecycle may profit from the PDM system that can deliver valuable information:  Product Planning: “What routines, components and functions did we produce, that might be recombined to form a new product?”  Product Development: “What components and parts are reusable for our new product to minimize complexity?”  Manufacturing: “Feed the BoMs and routings documented into the PPS for production of the desired product!”  Sales: “What components might be replaced for the customer in order to give him a lower price?”  Product use: “Show me the specifications for single parts, so I can optimize my spare part and maintenance management”  Recycling: “Show me dangerous connections and parts to disassemble (e. g. vacuum, tension) and potential toxic waste (e. g. batteries) in the product.

3.3.3 Reasons for Implementing PDM There are several reasons why PDM is one of the hottest topics in industrial IS and its introduction is discussed in many firms:  In the never ending quest for raising efficiency of development and manufacturing, both the CAx applications and PPS have been optimized very thoroughly. Companies do not see profit in optimizing them independently even more. New

134 | 3 Integration of Information Systems: Forms, Methods and Concepts

leaps of productivity can only be reached by integrating these systems and by creating cross-system development processes.  Companies increasingly focus on their core competencies and outsource modules and components. German car companies have outsourced almost 80 % of their value creation. However, outsourcing modules like a cockpit forces all companies involved to practice a concurrent (=simultaneous) engineering, which means that they have to develop new cars together with their module suppliers. This can hardly be achieved without a common product data management.  Some companies have grown very big in the last 30 years and are present in many markets. They do not only source and sell in a very wide area, but also have spread their development activities across countries and across the globe. Such a fragmented development process can only be sustained by a companywide data management.  On the market interfaces (sales and procurement), the web has raised requirements for accessibility and uniformity of product data. Concepts like eprocurement, vendor managed inventories via e-Kanban (please research the term) and web shops with product configurators cannot operate efficiently without PDM. These general trends driving the spread of PDM can be specified by showing how PDM actually helps improve the three most important levers of business success: time reduction, cost reduction and quality improvement.

3.3.3.1 Various Time Reductions by the Use of PDM PDM can reduce time-to-market in product development by making information access and communication easier. In various studies, it was found that technical staff – especially technical designers – spends 40 % of their work time searching for specification, norms, BoMs, and other design documents. This time is greatly reduced by PDM. Also, communication efficiency is raised by a common classification standard for products and parts. Concurrent engineering described above helps to reduce waiting time and inventories. Live simultaneous access to the current results of different developers allows parallelizing designing considerably. Also cycle-time of manufacturing can be reduced by using a modular system for parts and components across brands and variants of product. The successful platform strategy in the Volkswagen group production system relies on consistent data management and a form of PDM, which can be found here:  http://www.oracle.com/technetwork/database/features/availability/volkswage nprofile-134197.pdf  http://www.emeraldinsight.com/journals.htm?articleid=849824&show=abstract

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 135

3.3.3.2 Cost Reduction Of course, most time reduction phenomena described above also reduce expenditure and will find their way into financials. However, there are also more direct cost savings, like rationalizing administration of information necessary for product development. A big potential for cost reduction is the proactive reuse of parts and components already present in the company without having to design them from scratch. Unnecessary redesign also leads to complexity in materials management since seemingly ”new” materials need the same data administration as their twin part already present in the materials management system. PDM enables efficient configuration management, which can increase the rate of design reuse by up to 8 times.

3.3.3.3 Quality Improvement Implementing PDM improves the quality of both products and processes. It integrates all the CAx applications – which means Computer aided Quality Assurance (CAQ) can be applied in all stages of the product development process, not just in controlling the quality of manufacturing output. The use of CAQ tools is an integral part of the process management module of PDM systems sketched above. This way, the quality of products and processes can be improved considerably. This also may lead to additional cost savings, since errors are detected earlier in the development process. The law of error cost progression shows that the cost of fixing a design error progresses exponentially farther down in product development and production. A recall program of a car producer easily amounts to millions in administrative expenditure, repairing and loss of reputation as well as revenue. It might only have cost a few thousands during an early stage of design and development to avoid this error. Thorough documentation and recording of all changes made to the design enables a very structured change management and makes documentations required by law or business partners a lot easier. Finally, reuse of components already proven to be of good quality and sourced from well-known existing suppliers also increases quality without the need to re-check product quality or the quality of the suppliers.

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) The previous example of integration did not explicitly show how two systems can be connected if they are not integrated in an ERP system. How exactly can customer addresses from sales or accounting be retrieved by a marketing system in order to send the customers season greetings letters for Christmas?

136 | 3 Integration of Information Systems: Forms, Methods and Concepts

In order to explore the software enabling this connection, we need to focus once more on the objects of integration which are simplified here into three possible levels. The figure below shows these levels of integration, the information transported, and common metadata two systems must share if they want to communicate. 3 The newer term EAI is very broadly defined and basically means all kind of interfaces on all levels of integration. The older term “middleware” describes several technologies, standards and software parts that mainly integrate data and also objects.

This is exemplified by our example above; using sales and accounting to get addresses for Christmas cards. Depth of Integration

Exchanged information

Integration on Process level

Integration on object level

Integration On data level

Common Metadata

Meaning

IS understand the process of getting an address, printing it on a card and sending out the card

An address and its parts

Systems must know the meaning of an “address” in order to retrieve it and send

The bits that form Text like names of persons and streets

Range of application

EAI

Middleware

Network protocol

Fig. 3.18: Levels of Integration (Based on Laudon/Schoder (2012), p. 493)

We will talk about the term SOA in chapter 3.4.4. All of the technologies below are very well documented in literature about EAI. They are what we colloquially call an “interface”.

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 137

3.4.1 “Traditional” Means of Enterprise Application Integration Especially Middleware As soon as different applications in isolated functional silos started supporting business, the question of integration became relevant. So, integration and its technologies started long before there were integrated ERP systems or the internet. Software, technology and methods of integration used to be summed up by the term “middleware”. However, the ways to enable some form of integration varies considerably. This chapter is dedicated to traditional forms of integration, which have been around for quite some years and are still being used successfully: as with every form of technology, companies do not get rid of their old technology whenever there is a new one available. As stated in chapter 1, IS (here: middleware) are just tools to improve process support and business. It has to work profitably no matter how “new” it is.

3.4.1.1 Database Middleware A basic well-proven concept is database middleware. It provides a standardized interface between various application programs and different databases. This was necessary quite early because every database manufacturer used their own, proprietary way for applications to talk to their databases. Widespread examples are ODBC (Open Database Connectivity) and JDBC (Java Database Connectivity). A database and an application can interact when both are able to understand ODBC convention. The language in which a request from application to database is made is called Standard Query Language (SQL). It has become an international standard, so both ODBC and JDBC are prepared to process SQL requests to retrieve data from databases. These are called SQL statements and are close to real language. For example: we want to get some information out of our material database for another application. We send the following SQL statement via ODBC (Based on Laudon/Schoder 2012, p. 301): SELECT PART.Part_Number, PART.Part_Name, SUPPLIER.Supplier_Number, SUPPLIER.Supplier_Name FROM PART, SUPPLIER WHERE PART.Supplier_Number = SUPPLIER.Supplier_Number AND Part_Number = 137 OR Part_Number = 150;

In everyday language, this reads somewhat like (though not exactly!): “Get me some records from the tables (spreadsheet) PART and SUPPLIER. I do not need ALL columns, but just the name of the part, the supplier number and the

138 | 3 Integration of Information Systems: Forms, Methods and Concepts

supplier name (from table supplier). Besides, I do not need ALL records, just those where the part number is either 137 or 150”. So, in our initial example from sales, we might get the addresses we need for our Christmas cards by accessing the “accounts receivable” table in the accounting data base. It is accessed by sending an SQL statement to the ODBC interface. You will get a list that might be fed into a word processing program for a Christmas card serial letter.

3.4.1.2 Remote Procedure Call (RPC) RPC is quite an old technology. RPC provides ways to make the invocation of a routine on a server application by a (foreign) client application on a different machine look like the function was invoked within the server application. It “masks” the remote call as being local. Here is an example: an isolated application used in the sales department might have a procedure to print out a standard letter to a customer, reminding him to pay his bill. The program needs to retrieve certain values from its database, like the address and a certain text we want to print on the letter. Now, our marketing application wants to use this routine to print out a Christmas letter. The marketing application (the client) sends its own data to a so-called stub (like a receptor) on the sales application. This receptor takes the data and starts the printing routine. The printing routine cannot detect any difference in whether this request came from inside or outside the server program. This inter-application transfer is not without risk. It needs to be “guided”, preventing the handover at the stub to cause problems inside the server application and vice versa, in case values are returned to the client – which is, however, not the case in our example. This guidance is called “marshalling functions”.

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 139

Client

Server

Application

Application

Client Stub

Server Stub

Client Runtime Library

Server Runtime Library

Transport

Transport

Fig. 3.19: RPC Processes and Interactions (Source: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx5)

3.4.1.3 Object-Request-Broker (ORB) While RPC is focused on procedures like “printing”, modern programming languages build everything around “objects”. So, with the beginning of object oriented programming, there was the need to enable RPC’s to work in an objects oriented environment and applications. So, in order to let two object oriented applications talk to each other, ORB creates objects on its own to interact with these application. There are many more functions to it, especially to coordinate the “traffic” of multiple objects being exchanged. ORB is just a basic principle and is specified in ORB languages. For further investigation, please research the term CORBA, which is a very common ORB language.

3.4.1.4 Message-Oriented Middleware (MOM) Unlike RPC, “message-oriented middleware” does not intrude on the server application and invoke a routine there. It rather actually sends messages from one application to another, like humans are sending e-mails:

140 | 3 Integration of Information Systems: Forms, Methods and Concepts

Request sent

Reply sent Application 1

Application 2

Fig. 3.20: Message-Oriented Middleware (Based on Ruh (2001), p. 42)

One application sends a message to another that says: “I need the total amount of material 8973245 in stock”, and waits for an answer. The receiving application translates this message, gets the data and sends a message back with the amount in stock. So it does not take too much for both of them to talk. They just need a common language and a sender and receiver stub on every application that joins the communication. Immediately, two problems arise in the simple model described above:  The communication is synchronous and blocks the requesting applications while the conversation is running.  There needs to be some marshalling or orchestration that checks whether the message was received, understood, is processed, and so on. One solution to this problem is called message queue-model. In this concept, the messages can be placed in queues. Since they do not have to wait for each other, it is called an asynchronous communication.

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 141

Application 2

Application 1

API

API = Application Programming Interface

Queue Manager Q Sending the message

API

Q Queue Manager Receiving the message

Fig. 3.21: Message Queue-Model

3.4.2 The Concept of Web-Services With the arrival of the internet, new forms of interfaces were necessary, since all of the methods above were primarily focused on connecting isolated applications within a company. A web-shop like Amazon, however, needs to employ functions of several other partners outside Amazon. This has several implications for the way such an interface should work: the transport of data is outside the companies’ boundaries, and there are many webservices, so we have to find the right one. Since every web service might have its own adaptor, there must be some form of description of how a specific web service works, and this description should be written in a common language. E.g., Amazon wants to find out whether a credit card (e. g. VISA) used for a single purchase without login is valid. Amazon will seek the VISA server, send out card-data entered by the customer (like number and date valid thru), and will hope to receive a message that the card is OK or NOT OK. In order to enable such a conversation, several basic elements are necessary (based on Sotomayor 2005):  Web service discovery: Available web services register themselves in a kind of phonebook with a language called UDDI. This allows another application to locate one particular service from among the huge number of web services.

142 | 3 Integration of Information Systems: Forms, Methods and Concepts  Web service description: One of the most interesting features of web services is that they are self-describing. This means that, once a web service is located, it can be asked to “describe itself” and tell what operations it supports and how to invoke it. This is handled by the Web Services Description Language (WSDL).  Service invocation language: Invoking a web service (and, in general, any kind of distributed service such as CORBA described in the previous chapter) involves passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how the server should format its responses. In theory, we could use other service invocation languages (such as some ad hoc XML language). However, SOAP is the most popular choice for web services.  Transport protocol: Finally, all of these messages must be transmitted somehow between the server and the client. The protocol of choice for this part of the architecture is HTTP (HyperText Transfer Protocol), the same protocol used to access conventional web pages on the Internet. Again, in theory we could use other protocols, but HTTP is currently the most frequently used one. The following figure shows a web service communication at work. Here, e. g. a website (client) searches for a web service for weather information by looking in the directory provided by server A. Server A tells the client about server B, so client and server B start communicating about the format and the values to exchange.

Server A 1. Where can I find a “ weather service” ?

2. There´s a “weather service” in Server B

Discovery Service

Server B

Client 3. How exactly should I invoke you? 4. Take a look at this: WSDL 5. SOAP request: Invoke get Weather Info With parameter ”12345” 6. SOAP response: “cloudy with a chance of meatballs”

Fig. 3.22: Web service communication (Based on Sotomayor (2005))

Web Service

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 143

Web-services became very popular and proved to be a good way to exchange messages between any kinds of applications. So it became a candidate to be generally used for applications communicating inside and outside the company with each other. In order to do so, however, some issues had to be resolved:  How can it be ensured that the message came through in the first place? Web services were originally designed to “fire and forget”. An application sends something and hopes something comes back.  How can multiple web services (like in an order process) be invoked just in the right time and how can the overall process using many different web services be orchestrated?  On all levels and with all protocols used: How can the exchange be made absolutely secure?  How can an old IS (so called legacy systems) join the web service game? In many companies, systems from the last century are still successfully and economically used, but at the time of their creation no one thought about webservices. This is solved by a so called “wrapper” which translates web service signals into procedures of the legacy system. If you are interested in this very special detail, please research the term “wrapper” yourself on the web; it is well documented. The following chapter deals with some solutions to these issues.

3.4.3 Extending Web-Service Standards for Business Needs In order to solve the problems cited above and to make web services a reliable and safe standard for supporting business processes, several extension to the original standard have been added. We are not talking about software here, but about standards that might be used by applications communicating with web services. Table 3.5 shows areas where standards and technology have been enhanced. As you can see, the original components make up only a small part of the total web service stack. We do not need to discuss all of those extensions and standards that supplement the original concept of web services, but rather focus on one core issue and extension: transaction and business process orchestration. A first step to coordinate single web service actions was the introduction of web service choreography description language (WS-CDL), as you can see in the previous figure. WS-CDL enables several actions of different web services to work together in coordinated fashion in order to fulfil a real business process.

144 | 3 Integration of Information Systems: Forms, Methods and Concepts

Table 3.5: Enhanced Web-Services Standards and Technology (Based on Wilde/Glushko 2011, p. 19) Business Domain

Business Domain Specific Extensions

Various

Management

Distributed Management

WSDM, WS-Manageability

Provisioning

WS-Provisioning

Security

Portal and Presentation Transaction and Business Process Messaging

Metadata

Security

WS-Security

Security Police

WS-Security Police

Secure Conversation

WS-Secure Conversation

Trusted Message

WS-Trust

Federated Identity Portal and Presentation

WS-Federation WSRP

Asynchronous Services

ASAP

Transaction

WS-Transactions, WS-Coordination, WS-CAF

Orchestration Events and Notification Multiple message Sessions

BPEL4WS, WS-CDL WS-Eventing, WS-Notification WS-Enumeration, WS-Transfer

Routing/Addressing

WS-Addressing, WS-Message Delivery

Reliable Messaging

WS-Reliable Messaging, WS-Reliability

Message Packaging Publication and Discovery

SOAP, MTOM UDDI,WSIL

Policy

WS-Policy, WS-Policy Assertions

Base Service and Message Description Metadata Retrieval

WSDL WS-Metadata Exchange

5 Please read chapter 5.2. and 5.3. on the w3.org website to learn how orchestrated web services work together across the net in the case of booking a flight with three parties involved: http://www.w3.org/TR/wsci/TOC5.2

Since all these actions are interconnected, they have to be orchestrated; that means at least:  The activation of single steps must be in a certain order.  The web service must give a clear OK whether or whether not the transmission of data was successful  The rollback of all previous actions in case of cancellation or connection failure must be organized. For details of how these http://www.w3.org/TR/wsci/.

orchestration

issues

are

handled,

refer

to

3.4 Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) | 145

Another step further is the implementation of certain “rules” in an orchestrated business process. The following example shows an application process for credit, and how the applicant’s information and external data trigger some rules for adding points to his credit score that will decide whether the credit will be granted or not. If applicant owns residence, then add 40. If applicant rents, then add 30. If applicant has lived at current address 2 to 4 years, then add 20. If applicant’s income is under 20000, then add 10. If applicant’s income is between 40000 and 50000, then add 40. Source: http://www.w3.org/2005/rules/wg/wiki/UCR/BPEL_Orchestration_ of_Rule-Based_Web_Services.html The language that spells out such rules is called Business Process Execution Language (BPEL). There is one last ingredient missing to create a standard that make web services a means of seamless intercompany integration of whole business processes: a standardized graphical representation. Business Process Modelling Language (BPMN) finally delivers this standard. It is a graphical representation fully compatible with web services, their extensions, orchestration and business rules. BPMN also closes another gap: it is not just a graphical representation. Once it is drawn in appropriate software, it actually can be converted into real computer code, the base of a real program. For a short overview about the notation, take a look at this poster: http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf or watch the tutorials of vendors that sell BPMN modelling software, like http://www.bizagi.com.

3.4.4 IS-Integration: Towards a Real SOA The web has forced companies to find new ways of IS integration, and web services have been the answer. These have proved so successful that they are proposed to be used generally as a standard for interfaces. The standards and languages for the orchestration have somehow converged into BPMN by the year 2014. All of these developments have fostered the vision of a true Service Oriented Architecture (SOA). There are many types of SOA descriptions and you might want to research some yourself. We will not follow the all-too-simple definitions that will call every client-server relationship (see chapter 4), or the use of any web-services or traditional EAI technologies, a SOA. Even if those services are orchestrated the way described above, it lacks breadth of vision. A full definition should include the independence from application and especially hardware.

146 | 3 Integration of Information Systems: Forms, Methods and Concepts

From a management perspective, SOA realizes a relationship between IS and the business the way it should be: hardware serves the applications and the applications serve business processes. So, SOA is a way of single services communicating in an orchestrated way with each other in order to carry out or support a real business process. It is independent of applications, front-end clients and, especially, from hardware. SOA is likely to use web services, but all traditional EAI-technologies can and are actually employed to build SOAs. The following figure illustrates this extended SOA understanding.

Fig. 3.23: Extended SOA definition (Based on: http://www.brockhaus-gruppe.de/wp-content/plugins/as-pdf/generate.php?post=836)

The figure shows a sales-process that begins with an order request from a customer. This process might be formally modelled or mapped with BPMN as the modelling language. The approval manager might use any web-ready client to access the applications. It is typical for a process to cross department boundaries and use data and routines from different IS. Our sales process here uses the ERP, the sales force automation; for checking the customer order credit limit, perhaps it has to take a look into the CRM system.

3.5 Intercompany Integration via Exchange Standards | 147

The process might be supported by some execution rules. For example, the process will branch out depending on the order being below 5.000 €, between 5.000 and 10.000 €, or above 10.000 €. These rules are formulated as BPEL commands. The process, of course, uses applications that already exist in the company like SAP, databases and so on. Those applications are running on hardware that might be owned and run by the company, outsourced somewhere in the so-called cloud, or operated by a third party.

3.5 Intercompany Integration via Exchange Standards The SOA principle described in the previous chapter will help companies to integrate their business within themselves and also with outside parties via the web. Also, the languages describing such architectures are getting more and more standardized. However, talking the same language does not necessarily mean the content will have the same format. Let’s take the company in chapter 3.4.4 that follows a SOA approach and is ready for all kinds of interfaces, especially web services. It now wants to connect more closely and in an automated way with its suppliers, who also can do webservices. Still the question remains: what will they send across their orchestrated web-services in order to exchange stock-levels, bills, prices, figures and data of material to be purchased, and so on? How will they write their messages? For the sake of clarity, let’s assume a worst-case scenario on the left side of the figure: the partners in an industrial supplier network are not following a common standard, and need to decide on an individual common rule for each pair of their systems, and to implement them.

148 | 3 Integration of Information Systems: Forms, Methods and Concepts Communication through a Centralized exchange format

Bilateral communication Partner 1

Partner 1

Partner 1

Partner 1

Partner 2

Partner 2

Partner 2

Partner 2

Partner 3

Partner 3

Partner 3

Partner 3

Partner n

Partner n

Partner n “ Each with everyone.”

n*(n-1) Communication rules

Partner n “ Each with one. One with everyone.”

2n Communication rules

Fig. 3.24: Intercompany Communication Rules (Based on Laudon/Schoder (2012), p. 499)

Without a common standard, companies would either be forced to define countless individual interfaces or rely solely on a self-explaining standard like web-services, which not every company might want to employ. The solution to this problem is to establish common standards for exchanging data. Industrial enterprises especially need three kinds of standards in order to minimize individual definitions of interfaces. For each, needed standardization theory and practice have found more than one answer: several competing standards do exist, since every industry has special needs which might be irrelevant to another industry. Also, some nations and big vendors have set their own standards. Unfortunately, standards that are very common in Germany, like OpenTrans for documents, BMECat for catalogues, and e-class for classification, are not so widespread in the rest of the world. There are successes and ongoing efforts to merge standards to reduce their numbers. For reasons shown above, however, it is neither useful nor realistic to expect one day that all standards will be merged into one. We will only have a short view at three dimensions of standardization. The topic will be covered in other modules, like logistics, and is also very well and openly documented on the web, since these standards compete for followers.

3.5 Intercompany Integration via Exchange Standards | 149

There is a bilingual website explaining and comparing these and more standards at www.prozeus.de. It even has some fine online tutorials about standards – these, however, are only 1 in German: http://www.prozeus.de/prozeus/mediathek/lernmodule/index.htm

A company does not have to pay to use a standard, just like there is no charge to speak English, Chinese or German. However, software adaptors on an ERP system or consulting about these standards might very well create some cost. Despite the fact that a standard might be used free of charge, choosing the wrong standards might have serious consequences: it might isolate the company, lead to additional cost if the company’s IS need to be reprogrammed or augmented to support another standard, and many more. E.g. in the market for smartphones, the decision of which standards to follow (android, apple, windows) is a strategic question that – if answered wrongly – will lead to serious problems for a company. Some more details about standards can be found in Laudon/Laudon 2012.

3.5.1 Electronic Document Exchange Standards (EDI) Long before there was an internet, companies wanted to exchange electronic documents, like delivery forecasts, dispatch advice messages, transport booking purchases, order message confirmations and so on. So, they created standards for electronic data interchange (EDI). There are several competing standards today. In international business, EANCOM, EDIFICE and ODETTE are the most widely known. If you’d like to learn more, please research these terms. Since the usage of standards is free, they 5 are very well documented on the web. Check for example http://www.gs1.org/ecom/eancom

3.5.2 Catalogue Exchange Standards Electronic documents are just paper documents in digital format and replace papers and letters being sent back and forth. Catalogues are different, since they hold large amounts of data, are frequently updated and rely on a complex inner structure. They contain objects (products) that have certain parameters expressed in text, photographs, figures or technical drawings and, of course, actual prices and pricelists. So, there are standards for exchanging these data from e. g. the ERP of a supplier to the materials management IS of an OEM (Original Equipment Manufacturer). This is the way suppliers’ prices for certain goods in the buyer’s ERP system are being kept up to date. PRICAT and RosettaNet are internationally accepted standards, while BMECat is more commonly used in Germany.

150 | 3 Integration of Information Systems: Forms, Methods and Concepts

3.5.3 Material Classifications Standards Industrial companies often have a lot of “materials” (including components, modules, and so on, as you will see in chapter 4), maybe 100.000 or more. The materials and their parameters must be organized somehow for various reasons: reuse of existing parts and designs, bundling of purchasing power, easy search for related materials, and so on. Please see chapter 3.3.3 again. More than the other two standards, a useful material classification depends on the individual industry. Airbus and Boeing might very well use the same material classification standard, but this might not be suited at all for BMW. To be clear: a common standard does not mean materials in two different companies have the same description, but the structure and the manner of description will be the same. 1 For more explanation and success stories of companies introducing these standards, please check www.prozeus.de again.

3.6 Summary of Chapter 3 Many businesses’ needs in different functions have led to the development of many specialized applications that are normally not connected to each other. However, the disadvantages of isolation and the advantages of connecting and integrating applications (or their data) becomes evident. Before starting to integrate, however, the dimensions of integration should be clearly decided (what, where, what direction, etc.) and the optimal degree of integration should be determined. An ERP system, by now, can be called a traditional way of integration. A recent development has been Data Warehouses and a current topic for technical companies is Product Data Management. There are many different technical means of integrating independent applications via interfaces being employed. In the new century, the Internet gave rise to a new type of self-describing interface called “Web Services”. Several enhancements to the original Web-Service technologies and standards have been applied to make them a general standard of integration inside and outside the company, if these boundaries can be drawn at all nowadays. The vision of a real “Service Oriented Architecture” that integrates processes across companies, regardless of applications or hardware, is being discussed and introduced right now. Another simple way of integrating across companies is the compliance to intercompany standards, rather than programming individual interfaces. Choosing the best of the competing standards in each area (classification, catalogue exchange and business documents) remains an ongoing task of information management.

3.8 Review Questions for Chapter 3 | 151

3.7 Literature for Chapter 3 Gadatsch, A: Grundkurs Geschäftsprozess-Management (7th edition), Springer 2012 Gausemaier, J.: Computer Integrated Manufacturing (CIM), in: Enzyklopaedie der Wirtschaftsinformatik hrsg. von Kurbel, K. et al., Oldenbourg Verlag 2008. http://www.enzyklopaedie-derwirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/informationssysteme/SektorspezifischeAnwendungssysteme/Computer-Integrated-Manufacturing-(CIM) Krause, L.: Methode zur Implementierung von integriertem Produktdatenmanagement, in: ScholzReiter, B. (Ed.), Series: Informationstechnische Systeme und Organisation von Produktion und Logistik, Vol. 1, 2nd Edition, GITO-Verlag Berlin, 2008 Laudon K.; Laudon J.: Management Information Systems (12th edition), Prentice Hall 2012 Laudon K.; Laudon J.; Schoder, D.: Wirtschaftsinformatik (2nd edition), Pearson Studium 2010 Motiwalla, L.; Thompson, J.: Enterprise Systems for Management (2nd edition), Prentice Hall 2011 Ruh, William A.; Maginiis, Francis X.; Brown, William J.: Enterprise Application Integration – A Wiley Tech Brief; John Wiley & Sons Inc.; New York 2001 Sotomayor, B.: The Globus Toolkit 4 Programmer’s Tutorial, University of Chicago – Department of Computer Science 2005. http://gdp.globus.org/gt4-tutorial/multiplehtml/index.html Wilde, E.; Glushko, R.: Enterprise Organizing Systems, in: Principles and Patterns of Organizing Systems, Spring 2011 — INFO 290-6 (CCN 42628), UC Berkeley School of Information 2011. http://dret.net/lectures/ppos-spring11/enterprise(1)

3.8 Review Questions for Chapter 3 3.8.1 Close: Dimensions of IS integration For each gap, please choose the correct word to complete the sentence: 1)

“Data” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

2)

“Intercompany” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

3)

“Functions” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

4)

“Horizontal” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

5)

“Real-Time” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

6)

“Vertical” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

7)

“Functional area- and process comprehensive” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

152 | 3 Integration of Information Systems: Forms, Methods and Concepts

8)

“Partial” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

9)

“Processes” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

10) “Batches” is one answer to the question of the [object, direction, range, degree of automation, date] of IS integration

3.8.2 True/False: Benefits of Integration Check all statements about IS integration, that are TRUE: 1) Integration overcomes artificial boundaries of departments, functional areas and processes. As described in learning object 1, the needs of internal and external customers do not care about boundaries a company has created to organize itself. 2)

Customizing of integrated standard software is cheap and requires less training.

3)

Modern concepts of collaboration like Supply Chain Management (Supply Chain Management) in technical companies or Efficient Consumer Response (Efficient Consumer Response) in trade are based on data integration.

4)

Transferring data from one medium onto another, e. g. by retyping, occupies resources and reduces the quality since every entry bears the risk of data mutation and might lead to errors.

5)

There is a lower risk of chain reaction in case of errors. The tighter a system is integrated, the less elements are affected by the problems of other elements.

6)

The complexity of an integrated system requires less testing and maintenance.

7)

Integrated IS enable a tighter control of processes and enable automation.

8)

Integration reduces unwanted redundancy and avoids unnecessary data storage and documentation. It also reduces expenditure for data management and makes inconsistency of data more unlikely.

3.8 Review Questions for Chapter 3 | 153

3.8.3 Chose: Optimum Point of Integration Choose the optimum point of integration: a), b), c) or d)?

Cost/benefit of integration Integration benefit trough increase in efficiency Integration costs

Degree of integration a)

b)

c)

d)

3.8.4 True/False: Difference Between ERP-Systems and Data Warehouse For each statement, please choose the sentences that describe a Data Warehouse. 1)

Objective: Provision of relevant information for decision making from different data sources

2)

Information content: Less detailed data. Compressed information for long-term periods

3)

Data structure: Process- and/or function-oriented

4)

Performance at analyses: Good, because of access to dedicated data base

5)

History of data: No, on range at best. Data is continuously updated and supplemented

6)

User: Decision-making preparers, top-management and controlling

7)

Standardization: Data taken from the source systems will be homogenously structured and formatted. Inconsistencies must be revised in advance.

154 | 3 Integration of Information Systems: Forms, Methods and Concepts

3.8.5 Close: ETL Processes Choose the right position for each term in the figure.

Data Warehouse – Database Customers

Turnovers

a)

…

b) c)

e)

d)

f)

Finance

Staff

Ext. Databases

g)

Internet

Company externally Data sources

1)

Loading programs

2)

Products

3)

Staging area

4)

Transformation programs

5)

Company internally

6)

Extraction Programs

7)

Sales

3.8.6 Choose: Error Correction in the Transformation of Data Please check all errors that can be detected automatically. 1)

Format adjustment necessary (known): “Euro” will always be changed into “€”

2)

Correction of obvious outliers by a defined variance threshold: In a 100; 105; 1.02 ;103 row the entry 1.02 is considered an erroneous outlier and corrected to 102

3)

Wrong entries: Customer N. Woytek classified as “consumer” is really a “reseller”

3.8 Review Questions for Chapter 3 | 155

4)

Empty fields/missing values: Actual “reject rate” for 2010 is missing and will be filled with 2009 actuals or planned values 2010

5)

Format incompatible: An entry “xyhV23,12E-1” should be changed into whatever is the right format

3.8.7 Close: Transformation of Data For each gap, please choose the correct word to complete the sentence: 1)

Different formats and coding from source data is set to a defined standard. E. g. different entries in the field that defines gender in the tables of different sources like M/F, O/1, male/female, y/x are all converted to m/f for the DWH. Likewise, different metrics like US inches and European centimetres might all be transformed into millimetres. This operation is called [harmonizing, aggregation, enrichment, loading, extraction]

2)

The system might create new and previously non-existent values from the data available in the operational systems. E. g. values for a new column “gross margin” might be calculated by subtracting “cost of goods sold” from “revenue”. This operation is called [harmonizing, aggregation, enrichment, loading, extraction]

3)

It might be necessary to reduce the amount of data. For example, the number of users accessing a website might be counted by the second, but maybe we want an hourly average only. Likewise, we do not need the numbers of employees for each workstation, but for the whole plant. This operation is called [harmonizing, aggregation, enrichment, loading, extraction]

3.8.8 Close: OLAP Cube Terms For each gap, please choose the correct word to complete the sentence: The name of a criteria by which a column’s data can be sorted by is called a [slice, classification, fact, dimension, dice]. The number of dimension is limited to [3, 99, number of columns contained in the base data of the DWH, no amount at all]. Dimensions can be aggregated, e. g. days into months and months into years; this is called [slicing, drill down, roll up, dicing]. The other way around, zooming into more detail of a dimension is called [slicing, drill down, roll up, dicing]. The order of these detail levels is laid down in the [dimensions, classification hierarchy, facts, columns]. The elements in the cells chosen by selected dimensions are called [dimensions, classification hierarchy, facts, columns] and contain, for example, revenues, margins and pieces sold. The operation of getting information for a single dimension across all other dimensions is called [slicing, drill down, roll up, dicing],

156 | 3 Integration of Information Systems: Forms, Methods and Concepts

while carving out a specified area limited by several ranges of dimensions is called [slicing, drill down, roll up, dicing].

3.8.9 Close: Data Mining Operations For each gap, please choose the correct word to complete the sentence: 1)

[Association, Sequences, Classification, Clustering]: Connecting events over time. Example: What are typical events at wind turbines before a downtime occurs?

2)

[Association, Sequences, Classification, Clustering]: Creating groups of individuals in order to reduce complexity. Example: Are there any distinguishable groups of downtimes for which we would create a standard procedure?

3)

[Association, Sequences, Classification, Clustering]: Finding the right group an item/event belongs to by comparing it to other items that were already classified into a group. Example: What “kind” of downtime was the one last night?

4)

[Association, Sequences, Classification, Clustering]: Characteristics attributed to a single event. Example: What do typical downtime events look like?

3.8.10 Close: Knowledge Based Systems in Design For each gap, please choose the correct word to complete the sentence: 1)

[CAE, CAQ, CAP, CAD] helps in drawing the engine, most likely in a three dimensional model

2)

[CAE, CAQ, CAP, CAD] simulates running the engine and measures probable real-life results in material deformation, noise, and vibrations, and helps in optimizing the design

3)

[CAE, CAQ, CAP, CAD] generates routings and workplans that will be processed in actually manufacturing the product

4)

[CAE, CAQ, CAP, CAD] helps in setting the standards and measuring the outputs to ensure the quality desired is produced directly in design.

3.8.11 Choose: Reasons for Integrating CAD and PPS Systems Choose all reasons for integrating CAD and PPS Systems: 1)

Most companies are pressed by market forces and  consequently  marketing to offer many variants of the same product. If mechanical designers cannot access existing designs, they will create them anew, which leads to double work, cluttered master data and fragmentation in materials management.

3.8 Review Questions for Chapter 3 | 157

2)

The advancements in internet and mobile devices, like Smartphones and tablets, make a closer integration necessary. Otherwise, compatibility and process orientation cannot be fully guaranteed.

3)

Companies are forced to act quickly on the market since the lifecycle of products are ever shortening. Renewing a product without quick access to previous versions of design documents, like BoMs and routings, might be too slow and too costly.

4)

Not only the introduction of new products but the complete documentation of their lifecycle, including all changes in design, materials used, components sourced from suppliers, and so on, have to be documented at all times for legal reasons, quick problem response and spare part management.

5)

With the introduction of new materials and new methods of manufacturing, the number of parameters that need to be exchanged between design and production has increased sharply.

3.8.12 Choose: Reasons for Implementing PDM Choose all reasons for implementing PDM: 1)

Both the CAx applications and PPS have been optimized very thoroughly. New leaps of productivity only can be reached by integrating these systems and by creating cross-system development processes.

2)

Companies increasingly focus on their core competencies and outsource modules and components. However, outsourcing modules like a cockpit forces all companies involved to practice a concurrent (= simultaneous) engineering. This hardly can be achieved without common product data management.

3)

PDM secures product data better against unauthorized access and prevents the loss of data caused by system failures.

4)

Some companies do not only source and sell globally, but also have spread their development activities across countries and across the globe. Such a fragmented development process can only be sustained by company-wide data management.

5)

Several new laws like SOX and KontraG urge companies to ensure compliance in all parts of the company. PDM helps to guarantee compliance in design and production.

6)

At the market interfaces (sales and procurement) the internet has raised requirements for accessibility and uniformity of product data. Concepts like e-procurement, vendor-managed inventories via e-Kanban, and web shops with product configurators cannot operate efficiently without PDM.

158 | 3 Integration of Information Systems: Forms, Methods and Concepts

3.8.13 Close: Basic Elements of the Web-Service Concept Name the element of the web-service concept described in the following sentences and how the named facility makes these elements work. 1)

[Web service description, Web service discovery, Service invocation language, Transport protocol]: Available web services register themselves in a kind of phonebook with a language called [WSDL, UDDI, HTTP, SOAP]. This allows another application to locate one particular service from among the huge number of web services.

2)

[Web service description, Web service discovery, Service invocation language, Transport protocol]: Web services are self-describing: once a web service is located, it can be asked to “describe itself” and tell what operations it supports and how to invoke it. This is handled by the [WSDL, UDDI, HTTP, SOAP].

3)

[Web service description, Web service discovery, Service invocation language, Transport protocol]: Using a web service involves passing messages between client and server. The standard [WSDL, UDDI, HTTP, SOAP] specifies how we should format requests to the server, and how the server should format its responses.

4)

[Web service description, Web service discovery, Service invocation language, Transport protocol]: Finally, all of these messages must be transmitted somehow between the server and the client. The protocol of choice for this part of the architecture is [WSDL, UDDI, HTTP, SOAP], the same protocol used to access conventional web pages on the Internet.

3.8.14 Close: Web Service Communication Name the sender and the recipient of the following messages sent during a conversation of a weather app using a web-service: 1)

[Client App, Weather Web-Service, WS Discovery Service] to [Client App, Weather Web-Service, WS Discovery Service]: Where can I find a weather service?

2)

[Client App, Weather Web-Service, WS Discovery Service] to [Client App, Weather Web-Service, WS Discovery Service]: There is “Weatherite” at 123.34.56.6.

3)

[Client App, Weather Web-Service, WS Discovery Service] to [Client App, Weather Web-Service, WS Discovery Service]: Exactly how should I invoke you?

4)

[Client App, Weather Web-Service, WS Discovery Service] to [Client App, Weather Web-Service, WS Discovery Service]: Take a look at this piece of WSDL.

3.8 Review Questions for Chapter 3 | 159

5)

[Client App, Weather Web-Service, WS Discovery Service] to [Client App, Weather Web-Service, WS Discovery Service]: Invoke getWatherinfo();657;56.

6)

[Client App, Weather Web-Service, WS Discovery Service] to [Client App, Weather Web-Service, WS Discovery Service]: “Cloudy with a 10 % chance of rain”

3.8.15 Choose: Extension of Basic Web Service Communication Please choose three challenges that need to be solved in order to use web services for complex business processes: 1) How can it be ensured that the message came through in the first place? Web services are originally designed to “fire and forget”. An application sends something and hopes something comes back. 2)

How can web-services be used in networks other than the internet, like company LANs and WANs?

3)

How can multiple web services (like in an order process) be invoked just in the right time and how can the overall process using many different web services be orchestrated?

4)

On all levels and with all protocols used: How can the exchange be made secure?

5)

How can web-services be integrated into self-optimizing processes of network communications?

6)

How can connectivity to modern ERP-Systems be realized?

3.8.16 Close: Intercompany Integration via Exchange Standards For each gap, please choose the correct word to complete the sentence: 1)

Before there was an internet, companies wanted to exchange electronic documents like delivery forecasts, dispatch advice messages, transport booking purchases, order message confirmations, and so on. So, they created standards for [transport protocols, catalogue exchange, electronic data interchange, Material Classification, Web-Services]. One example of such a standard is [Odette, PRICAT, E-Class]

2)

Compilations of real content are different from simple business documents, since they hold large amounts of data, are frequently updated, and rely on a complex inner structure. They contain objects (products) that have certain parameters expressed in text, photographs, figures or technical drawings and, of course, actual prices and pricelists. A standard for exchanging these data from, e. g. the ERP of a supplier to the materials management IS of an OEM, is called

160 | 3 Integration of Information Systems: Forms, Methods and Concepts

a(n) [transport protocol, catalogue exchange standard, electronic data interchange standard, Material Classification, Web-Service]. One example of such a standard is [EDIFICE, BMECat, UNSPC]. 3)

Industrial companies often have a lot of “materials” (including components, modules, and so on, as you will see in lesson 4), maybe 100.000 or more. The materials and their parameters must be organized somehow for various reasons: reuse of existing parts and designs, bundling of purchasing power, easy search for related materials, and so on. A standard for describing and sorting materials in a common way is called a(n) [transport protocol, catalogue exchange, electronic data interchange, classification system, web-service]. An example of such a standard is [Odette, RosettaNet, E-Class].

3.9 Suggestions for Written Exercise or Groupwork for Chapter 3 3.9.1 Data Defects and OLAP Please download the excel sheet “32-downtimes” from your instructor/course site that should contain data of downtimes of wind turbines from 2014 and the reasons for downtimes. What “defects” in the data in the first 40 lines can you spot? Please name them, how they might have happened, and more importantly: how to deal with these defects. Hint: There are at least 6 defects. Then please use a pivot table in Excel to find out the total duration AND number of downtimes of all machines caused by retooling in the month of November 2014. You do NOT have to correct the defects in the table to do this!

3.9.2 CIM and Industry 4.0 Please discuss in detail differences and common aspects between the catchwords “CIM” and “Industry 4.0”.

4 ERP Systems: Basic Concepts and the Example SAP ERP Systems are a very popular way to integrate company applications. This chapter will focus on ERP as a means of integration, and will exemplify it with SAP as the leading vendor in 2014. After this chapter, you should be able to …  … distinguish the way ERP systems integrate from other means of integration.  … describe in detail how data integration and process integration is achieved in ERP systems.  … describe the market structure for ERP systems.  … evaluate the success of ERP introduction projects and use.  … describe relationships and hierarchy of objects in the financial, logistics and sales module of an ERP system exemplified by SAP.  … navigate through SAP (or another ERP system) and start transactions.  … create materials master data.  … use materials master data in a simple production process.

4.1 System Integration via ERP System As described in chapter 3, there are many forms and means of integration. This chapter will focus on one very popular manner of integration: the horizontal integration of different company functions via a common program and common master data. This type of application is called Enterprise Resource Planning System, or ERP, in short. In this chapter, we will focus on how ERP systems achieve integration via common master data and processes. You will also learn more about the underlying technology and basic architecture to understand the basic logic. The core of ERP systems lies in the integration of two company functions that traditionally need a lot of computational power: production planning and accounting. Materials Requirements Planning (MRP) and production planning (PPS) need a lot of calculations, as you have seen in chapter 2. That is why IS were developed quickly to support these calculations. Also, every action in the material world of material management (like purchasing, manufacturing and building up inventories) has a corresponding “shadow” in the financial realm besides the commercial and tax balance sheet. In both functions, a lot of calculation needs to be done. Both use the same master data (e. g. for materials and suppliers). So, they were the natural targets of an integrated IS support called ERP systems in the 80s and 90s. The following figure shows the history of ERP, from the MRP point of view. The development of accounting programs ran parallel to those of MRP and is omitted in the figure.

162 | 4 ERP Systems: Basic Concepts and the Example SAP

Table 4.1: Evolution of Enterprise Systems (Texts from Motiwalla/Thompson (2012), p. 31) System 1970s: Material requirements planning (MRP)

Platform Mainframe legacy using third-generation Software (e. g., Cobol, Fortran)

Description With a focus on sales and marketing, these systems were designed for job shop scheduling process. MRP generates schedules for production planning operations control, and inventory management.

1980s: Manufacturing requirements planning (MRP II)

Mainframe legacy using fourthgeneration database software and manufacturing applications

With a focus on manufacturing strategy and quality control, these systems were designed for helping production managers in designing Production supply chain processes from product planning, parts purchasing, inventory control and overhead cost management to product distribution.

1990s: Enterprise resource planning (ERP)

Mainframe or clientserver using fourthgeneration database software and package software application to support most organizational functions

2000s: Extended ERP or ERP II

Client-server using Web platform, open source and integrated with fifth-generation applications like SCM, CRM, SFA. Also available on Software as a Service (SaaS) environments

With a focus on application integration and customer service, these systems were designed for improving the performance of the internal business process across the complete value chain of the organization. They integrate both primary business activities like product planning, purchasing, logistic control, distribution, fulfillment, and sales, additionally, they integrate secondary or support activities like marketing, finance, accounting, and human resources. With a focus on agility and customer-centric global environment, these systems extended the first generation ERP into inter-organizational systems ready for e-Business operations. They provide anywhere anytime access to resources of the organization and their partners; additionally, they have integrate with newer external business modules such as supply chain management, customer relationship management, sales force automation (SFA), advanced planning and scheduling (APS), etc.

4.1.1 Integration of Master Data The original thought behind the development of ERP systems was the integration of data. E.g. we need the address of a customer for shipment, accounting and marketing purposes. It makes no sense to maintain this data in several functional silos. The same is true for materials management and accounting – both need the data of suppliers. PPS in industrial production (see Chapter 2) and merchandise management systems (MMS) in trade require intense computing. Also, financial accounting is basi-

4.1 System Integration via ERP System | 163

cally math, and so, the nucleus for an integrated system became clear: horizontal integration of PPS and accounting. And this was indeed the beginning of SAP (and later, other ERP systems). However, in the year 2014, many other company functions (like HR, Sales and Quality Management) have joined the ERP nucleus and make for the broad, almost total horizontal integration of systems described below. If the same master data (for example a “material”) is used by many different company functions, a problem arises: different company functions have very different information needs, as the figure shows:

Controlling Data

Accounting Data Material Master

Fig. 4.1: Different Material Information for Different Company Functions

Each function might need to maintain up to hundreds of data fields. Most of them are, however, irrelevant to other functions as can be exemplified by a finished good like a motorcycle: sales needs information like “sales price”, “delivery time” and “required packaging”, which are of no interest at all for manufacturing on the shop floor. On the other hand, production needs the BOM, connected workplans (routings), etc., which are of no interest for sales. However, if both use the same data object, the same material which is the very essence of data integration, this data object must envelop all fields of all company functions. This might lead up to a thousand possible data fields. No single company function will ever need all of them, and it would be confusing to work with all fields present all the time. ERP systems like SAP solve this by the concepts of “data views”. Data views are a sensible grouping of data fields in order to structure information needed by certain functions; they are graphically represented as tabs.

164 | 4 ERP Systems: Basic Concepts and the Example SAP

Fig. 4.2: Different Data Views Structure the Information in a Master Data Record in SAP

Each department or company function just maintains the data that they are interested in, and are not concerned about the rest. This coordinated maintenance of master data is supported by “roles”: a sales person probably will not even see the tabs that contain specific information (views) for production people. 3 Please note: For the live case-study (see chapter 4.4.2) you will be a multi-purpose employee with many more rights, and thus “views”, to work on than normal staff in a company.

4.1.2 Integration of Processes The integration of master data enables different departments to work together on common customer-focused processes. The main characteristic of a process is exactly this: it does not care at all about functions or departments (see again chapter 1.3). The following figure shows once more how a complete business process (“order to cash”) needs support and information from three different departments.

4.1 System Integration via ERP System | 165

Sales

Accounting

Manufacturing and Production

Generate order

Submit order

Check credit

Approve credit

Generate invoice

Assemble product

Ship product

Fig. 4.3: Simple Order to Cash Process Going Through Three Departments (Laudon/Schoder (2010), p. 484)

In chapter 2, functional silos that support single company functions were described. For the processes supported by IS, the different functional IS will just be part of one ERP. The following figure shows the change in focus of an application system from functional silos to an integrated, process-centric ERP system, in which different functions will use different modules within the same system:

166 | 4 ERP Systems: Basic Concepts and the Example SAP

Business Areas Manufacturing and Production

Finance and accounting

Sales and Marketing

Human Resources

Business processes

Business processes

Business processes

Business processes

Manufacturing and Production planning systems

Finance and accounting systems

Sales and Marketing support systems

Manufacturing and Production planning systems

Vendors

Organizational Boundaries

Customers

Organizational Boundaries

Application Systems

Fig. 4.4: Functional Silos (Based on Laudon (2012) p. 133)

Separate applications do not support business processes that reach over boundaries of departments. The support across functions by an ERP System is visualized in the following figure: Finance and Accounting

Manufacturing and Production

Organizational Boundaries

Organizational Boundaries

Business processes Business processes

Vendors

Customers

Business processes Enterprise-wide business processes

Human Resources

Sales and Marketing

Fig. 4.5: Integrated ERP System (Based on Laudon/Laudon (2012), p. 134)

In ERP systems, there are no real departments, just processes and the single tasks (transactions) grouped into so called “modules” (see chapter 4.2.3).

4.1 System Integration via ERP System | 167

With this knowledge, we shall detail the simple order-to-cash process further. The following figure shows the single steps in different departments that will complete the business process “end to end”.

SD

MM

FI SD = Sales Distribution MM = Materials Management FI = Financial Accounting SD

MM

FI

Fig. 4.6: Business process “End to End” (Source: SAP)

Each step will employ a certain action in the system; these actions are called “transactions” in SAP language. It can be accessed through the menu or with a shortcut code – if you are allowed to use this transaction in your role, see chapter 4.4.2. So, if you are a sales person, you will probably be given access to many transactions of SD (Sales Distribution). Entering the quick access code VA03 will, for example, open the transaction “Display Sales Order”. This way, the dilemma of customer processes and company departments is solved: each department works on its steps with their own transaction, while accessing the same data and following the common process structure. So an ERP system also enables a programmed workflow (see again chapter 1.3.3). These single steps are carried out in the system by a so-called “transaction”, the basic action item of an ERP system that has certain characteristics: A transaction in

168 | 4 ERP Systems: Basic Concepts and the Example SAP

an ERP system and its database must atomic, consistent, independent and durable. This is sometimes abbreviated as the ACID principle. 5 Please research the ACID principle on the web and find practical examples of a violation of one of these principles for an MRP run. You will find that the strict ACID principle is weakened in SOA and web environments.

4.1.3 ERP Architecture This module focuses on applications and does not usually dig deeper into the inner core of applications or even hardware. However, in the case of ERP systems, there will be a small exception, since the functionality of an ERP system is closely related to its technical architecture. A basic understanding of ERP architecture has several advantages (Motiwalla/Thompson 2012, p. 82):  Help management and the implementation teams understand, in detail, the features and components of the enterprise system.  Provide a visual representation of the complex system interfaces among the ERP application and databases, operating systems, legacy applications, and networking.  Help management develop a better IT plan if the requirements for system infrastructure, training, change management, and business process reengineering are clarified.

4.1.3.1 History of IT Architecture for ERP Applications Applications depend, to a certain extend, on the hardware and how the different parts can work together physically. So. it is useful to have a look at basic forms of architecture used for the ERP applications described above. Please note that “older” forms of architecture do not become extinct; they survive and may just become less dominant or numerous. In many industries, so-called “legacy” systems from an earlier period of computing remain an essential part of their IS landscape. This was one reason many companies feared the “year 2000 problem”, since systems were suspected to be unable to compute “00” if they operated with two-digit fields for years. The following figure shows the stages in IT infrastructure evolution. All of these forms are still present today, with enterprise computing being the dominant form. Cloud computing is omnipresent in the media and also gaining ground in the real world in 2014.

4.1 System Integration via ERP System | 169

Mainframe/Minicomputer (1959 – present)

Personal computer (1981 – present)

Enterprise computing (1992 – present)

Client/Server (1983 – present)

Cloud and Mobile Computing (2000 – present)

Fig. 4.7: Stages in IT Infrastructure Evolution (Based on Laudon/Schoder (2012), p. 214)











1959–present: Mainframes are physically large central computers. The users do not have machines with large memory or computing power. The so-called terminals (screens and keyboards) were directly connected to the central computer by wires. This is like many people using one single computer. 1981–present: Personal computers literally personalized computing by giving individual users memory, processors and applications. Data was transferred by floppy-disks and more and more by networks. However those networks were far from the connected use of machines today. 1983–present: Client server logic separated computing power and storage again, however, in a much more refined way than mainframe computing. This way, an optimal use of hardware and software and coordinated access of integrated data is ensured. This classical three tier approach is still dominantly used in ERP systems and will be explained below in more detail. 1992–present. Enterprise computing is still the dominant form of architecture today. It integrated mainframes, personal computer, client-server based ERP Systems and Internet applications via powerful local area and wide area networks. 2000–present. Currently cloud computing is gaining ground. Various devices like Notebooks, Desktop computers, smartphones and tablets access applications via the web. Application programs and storage are physically located somewhere in the world. This does not matter to the user as long internet and data security is ensured via passwords and encrypted transfers.

170 | 4 ERP Systems: Basic Concepts and the Example SAP

Each of these approaches brings its own challenges, advantages and disadvantages. However, there is a clear trend toward modern architectures since they use the best available hardware and satisfy the needs of the customers. Despite other hypes in the media, the dominant form today is still the classical three tier client-server architecture.

4.1.3.2 The “Classical” Three Tier Client-Server Approach of ERP Systems Architecture Most current ERP implementations follow a three tiered architecture, which consists of  a presentation tier (often web),  an application tier, and  a data(base) tier. This segmentation allows the system, as a whole, to be more scalable and optimizes resource utilization. It also provides higher security due to the separation of resources (Motiwalla/Thompson 2012, p. 91). Basically, a client server architecture distributes tasks optimally in a network by separating client applications and server applications. The following figure and the text below explain these tiers in more detail: Presentation Logic Tier

Business Logic Tier

Data Tier

Disk DB Server

Remote user clients, Integration servers, Load Balancing Web Servers, CITRIX Farm

Load Balancing, Application Servers, Batch Servers, Print Servers

Fig. 4.8: Three Tiered Architecture Example of ERP System (Based on Motiwalla/Thompson (2012), p. 35)

Reporting DB Server

Production DB Server

4.1 System Integration via ERP System | 171

The following description is a shortened version of Motiwalla/Thompson (2012), p. 92: Presentation Logic Tier: The presentation tier includes the web servers that a client interacts with for application access. Here, data is entered into the system by users via graphical user interfaces like SAP masks or web forms. Sufficient bandwidth is necessary to ensure smooth communication, especially when transferring non-textual inputs like videos. The requests issued by the different clients must be coordinated and supported by enough capacity of application. Since this is the entry door into the system, the roles and accesses have to be secured and organized, so any unauthorized access is blocked. Business Logic Tier: The application tier is where most of the processing of the ERP system is carried out. It handles clients’ requests from users, retrieves data from the database tier, and processes data as needed. For efficient use of computing power, user requests and data operations need to be coordinated and processed one after another, but in a very fast manner. In SAP, this handler is called a dispatcher. During times of heavy client traffic, responses of the application will slow down or even abort. You might have already experienced this from websites if they have too many requests or too little computing power. This tier includes reusable objects of business process rules that can be reassembled. For example, entering master data might always use the same routines in sales and materials management where just the content differs. Data Tier: The data tier is responsible for data management. This layer provides the central repository for all data that is shared among functional modules and maintains the integrity of data transferred to and from the clients and servers. The data tier not only writes, stores and retrieves data, but is also responsible for maintaining security and availability of the data by employing backup concepts and planned redundancies. Since the storage is basically independent from the application servers, more storage can simply be installed. Currently, a new generation of database technology, like SAP HANA, speeds up data access considerably by tightly integrating the database application into the hardware. The process of client server interaction is straightforward: a client asks a server to execute certain tasks by sending certain inputs. The application-server connects to the database and gets stored information necessary to fulfill the task. Then, information from the database and information from the client is processed and certain actions and values are returned to the client, and perhaps also written down in the database. For example, we need to change the characteristics of a certain semi-finished material in our ERP system. The user starts, via the client (installed on Windows or any other operating system), the transaction MM02, which means “changing material masters record”. She then enters the name of the material she wishes to change. These values are transmitted to the application server that starts searching in the database server. If the material was misspelled by the user and not found in the

172 | 4 ERP Systems: Basic Concepts and the Example SAP

database, the application will pass on a message of the database server: “Material not found”. If it was found, the values will passed on to the client where the material appears on the screen with all its values the user is allowed to see. When the user changes some values (e. g. the weight of the material) in the client, the values are passed on to the application server which initiates writing down the changed data into the database. This happens really fast; however if client-server systems are physically distributed over the internet, it might take longer. Every one of you has had this experience with overloaded web shops where nothing happens no matter how often you click the button on our client (web-browser). In order to regulate the load of traffic requests from clients, there need to be routines and rules and a program that applies these rules. The three tier architecture is still the approach of choice for many ERP systems, since it offers several advantages over previous forms of architectures: Scalability: Three tier architecture allows easier architecture to add, change, and remove applications because the user interface and database are not affected by upgrades to applications. Reliability: Three tier architecture makes it easier to increase reliability of a system by implementing multiple levels of redundancy. In addition, scheduling and prioritization of jobs can be managed better from a central location. Flexibility: By separating the business logic of an application from its presentation logic, three tier architecture makes the application much more flexible to changes. Flexibility in partitioning can be as simple as “dragging and dropping” application code modules onto different computers. Maintainability: Support and maintenance costs are less on a single server than it would be to maintain each installation or upgrade on a desktop client because the middle layer adds scheduling and prioritization for work in progress. Reusability. Separating the application into multiple layers makes it easier to implement reusable components. Security: Three tier architecture provides higher security because there is less software on the client machines, which means the IT staff has more control over the ERP system. Motiwalla/Thompson 2012, p. 9394

Three tier applications also have some limitations, including the following: Economics: Three tier applications require additional hardware and software infrastructure to support the middle layer, which can increase the overall platform costs. Complexity. A key limitation with three tier architectures is that the development environment is reportedly more difficult to use than the visually oriented development of two tier applications. Motiwalla/Thompson 2012, p. 9394

4.2 ERP Systems in the Market | 173

4.1.3.3 Current Developments in ERP Systems Of course, technology of ERP systems is permanently evolving; for example, the recently introduced database technologies HANA by SAP or Exalytics by Oracle. There are other developments in ERP you should be familiar with if specializing in ERP implementations. We cannot detail all trends here; however, they can easily be researched on the web. To name just a few:  Trends in architecture towards SOA (see chapter 3.4)  Cloud Computing for ERP  Enterprise Content Management elements in ERP  ERP employs virtualization to run several “software machines” on the same hardware  Inclusion of all aspects of the web and partly social software  ERP might move from monolithic modules and rare, but profound, updates towards a collection of “Apps”, like in consumer markets.  ERP vendors try to expand into four directions: “backward” to integrate SCM solutions, “forward” to integrate tightly with CRM, “upwards” to include MIS, data warehousing and business analytics, and “downwards” to get a tighter grip on Manufacturing execution (see chapter 2) It is typical for ERP systems to be “all things to everyone”; that is their job. That is why they will try to include new trends and demands and optimize the never-ending dilemma between specialization and generalization of an IS.

4.2 ERP Systems in the Market After introducing basic principles of ERP systems, this chapter will more closely examine the reality of ERP systems by taking a look into the current market of ERP vendors, explaining the basic structure of transactions and modules, and also taking a general look at the advantages and disadvantages and the success of ERP systems from a customer point of view.

4.2.1 Current ERP Market The ERP market is not highly dynamic. It has proven quite stubborn against the hype of “on demand” software or even cloud computing: about 60 % of companies using ERP still prefer traditional on premise software, 14 % use ERP software as a service, and just 12 % in the cloud. Open Source ERP seems not yet to be relevant. Also, there is a well-established set of ERP vendors. Between 2010 and 2014, the field of ERP in the race for customers has separated into three groups called “tiers” – not to be confused with the three tier logic of client-server systems: the big three

174 | 4 ERP Systems: Basic Concepts and the Example SAP

(SAP, Oracle and Microsoft Dynamics), some well-known smaller systems in a tier two segment, and a tier three segment in which there are some greater dynamics with newcomers coming in and companies dropping out. This is, of course, no “official” segmentation of the ERP vendor market, but it is used by several authors and institutions. The following figure shows some relevant names. Oracle has decided to preserve the brands of some well-established early players they have acquired during the years, as the figure shows. Table 4.2: Typical ERP Vendors in 2012 (Based on Thompson/Motiwalla (2012), p. 47) Tier I

Tier II

SAP

Epicor

Tier III ABAS

Oracle Oracle-e-Business Suite Oracle-JD Edwards

Sage Infor IFS

Activant Solutions Inc. Bowen and Groves Compiere

Oracle-Peoplesoft

QAD

Exact

Microsoft Dynamics

Lawson

NetSuite

CDC Software

Visibility CGS Hansa World Consona Syspro

One of many organizations conducting ERP market studies is Panorama Consulting, which is quite often cited in magazines for IT management. Since there are no unified official statistics on ERP market share, each calculation depends on the methodology and sample used. However, the following distribution researched by Panorama Consulting proves to be stable and is mirrored by other surveys: the “big three” make up half the market, as the figure shows:

4.2 ERP Systems in the Market | 175

Oracle 18% Tier III and others 36% SAP 24%

Tier II

Microsoft

11%

Dynamics 11%

Fig. 4.9: Vendor Market Share in 2010 (Panorama Consulting (2011), p.4)

Compare these vendor market share data from 2010 to the following global market share data in 2012; the numbers are similar. 37%

Global market share held by the leading enterprise resource planning software companies in 2012

25%

13% 6%

6%

5% 2%

2%

2%

Fig. 4.10: ERP Software Market Share in 2012, by Company (Statista, Source: Forbes)

1%

1%

176 | 4 ERP Systems: Basic Concepts and the Example SAP

If the overall survey is narrowed to manufacturing and distribution, the tier two companies Infor and Epicor are close to the big three for market share.

SAP

Others

28%

33%

Oracle

Epicor 5%

15% Infor 7%

Microsoft 12%

Fig. 4.11: Market Share of ERP-Systems in Manufacturing (Panorama Consulting (2011), p. 15)

One other interesting analysis is the question: Who chooses which vendor? Do big companies also choose a vendor of the big three? This is definitely the case for SAP and Oracle, as the following figure shows. Microsoft Dynamics AX does not fit into the figure; the center of its customer base lies in medium sized companies below 500 Mio revenue:

4.2 ERP Systems in the Market | 177

Fig. 4.12: Who Chooses Which Vendor? (Panorama Consulting (2011), p. 5)

Market surveys are available for your own research if you want to dig deeper into the market for ERP 5 systems. From a managerial point of view, it seems more relevant to show how successful ERP implementations have been both as a project and the use of the system.

The number of users, the revenue of the companies, and types of industries using ERP systems vary considerably: no one seems to be exempt from the wish to integrate systems. Just among little companies, the share without an ERP (and without the wish/plan to introduce one) is higher. Of course, company size influences the choice of vendor: specifically, SAP appears to be better liked by big companies, while small companies often have specialized solutions. Another fact is the size of ERP system implementations. They always belong to the bigger investments in IS, on average 5 % of a company’s yearly revenue (Panorama 2013, p. 15).

178 | 4 ERP Systems: Basic Concepts and the Example SAP

4.2.2 Success of ERP Systems Implementation Success of ERP implementation and ERP use is permanently researched and, every year, you will find fresh studies about it. This chapter looks at a study from the year 2011. An interesting detail of ERP success (implementation and use) is the fact that it hardly has changed over the years. Also, ERP seems unmoved by IS megatrends like cloud computing or social software, so the following results are stable and might be similar in the next year. 5 To validate this, you might easily check out studies about ERP from the company cited below or any other study.

4.2.2.1 Success of Introduction Projects The study cited below was answered by some 700 companies of various industries and sizes; it might be seen as quite representative, since it shows the same results as other researches. Projects for introducing ERP systems are an object of intense analysis on its own. As you know from project management, a project can be called successful if it meets the three general project targets: completion in time, in spec(-ification) and in budget (cost). Specification is the pure functionality of software, but also refers to the benefits the company was hoping to gain from the implementation. The following figure shows the success of ERP introduction projects during recent years in their volume and their three measures of success. Table 4.3: Success of ERP Projects in Recent Years (Based on Panorama Consulting (2013), p. 2) Year

Average Cost

% experienced cost overruns

Average Duration

% experienced duration overruns

% receiving 50 % or less Benefits

2012

$ 7,1 MM

53 %

17,8 months

61 %

60 %

2011

$ 10,5 MM

56 %

16 months

54 %

48 %

2010

$ 5,5 MM

74 %

14,3 months

61 %

48 %

2009

$ 6,2 MM

51 %

18,4 months

36 %

67 %

The percentages represent the share of respondents agreeing to the item. So the line for the year 2012 reads like this: In the year 2012 the average cost of an ERP project was $7.1 Million and lasted 17.8 months, on average. 53 % of the respondents experienced a cost overrun, 61 % a time duration overrun, and 60 % received only half or less of the benefit they had expected from introducing the software.

4.2 ERP Systems in the Market | 179

So, in general, ERP software implementations are big, take a long time and are not very successful. Frequently, less than 15 % of the companies report their ERP projects were completed on time, in spec and in budget. This seems bad, but please keep in mind, that a) big projects and b) software projects both show a mediocre rate of success, as you see in other studies. ERP implementations are both: big and software projects – and thus reflect the general bad rates of overall success in these two kinds of project types. Averages do not tell the whole story; so, the following figure gives a detailed view on the three measures of success and the distribution of answers. The legend starts at the top of the circle proceeding clockwise down. Implementation Cost

ERP Project Duration

2% 4%

Percent of Benefits Realized

5%

8%

10%

12%

34%

35%

11%

27%

12% 14%

16% 12%

22% 27%

31%

On budget Over budget by 25% or less 26% - 50% over budget

On schedule Over schedule by 25% or less Over schedule by 51% to 75%

Under budget

Over schedule by more than 76%

51% - 75% over budget

Over schedule by 26% - 50%

Over budget by more than 76%

Earlier than scheduled

18%

0-30% of projected benefits 31-50% of projected benefits 51-80% of projected benefits We didn´t have a business case No measurable benefits to date 81-100% of projected benefits

Fig. 4.13: Success of ERP Implementation: Cost, Duration, Benefits (Panorama Consulting (2013), p. 13–16)

So, it becomes clear that a successful ERP implementation is a tough task. All studies agree to a large extent on the reasons causing the time and cost overruns and underachievement. The problems and mitigation steps cited by Panorama (2013, p. 19) are representative for the empirical insights and experience of most professional studies:

180 | 4 ERP Systems: Basic Concepts and the Example SAP

“1. Budgets and timeframes that do not take into account business process improvement, organizational change management, backfilling and resource allocation, and/or software customization. Mitigation Step: Create a business case and devote adequate resources to ensure accurate project planning. 2. Leadership teams that choose systems based on reputation or vendor sales pitches rather than systems that truly fit their future state requirements. Mitigation Step: Leverage independent resources to conduct full requirements gathering, business process improvements and software evaluations and negotiations. 3. Leadership teams that fail to anticipate the magnitude of the project and the impact it has on end-user productivity and/or morale both prior to and following software implementation. Mitigation Step: Conduct executive alignment and education exercises; create a business case determining goals and measurement tools, and ensure strong organizational change management planning and execution. 4. Non-customized training that is based solely on the technical aspects of the system and fails to train users on new processes. Mitigation Step: Leverage third-party resources to customize training to each practice area and its processes. 5. Lack of concerted communication to end-users about the reasons behind the implementation, the anticipated benefits stemming from successful adoption and the ways in which each individual end-user and executive will affect project success or failure. Mitigation Step: Create and follow a comprehensive organizational change management plan.” Panorama (2013, p. 19)

We will have a closer look on how to avoid problems and improve success in big IS projects in chapter 6 and 7.

4.2.2.2 Success of Use In chapter 1, we set the premise that IS is not important in itself, but only long term business success (e. g. ROCE) is. IS might be a means of improving ROCE or reach the objectives of the stakeholders of a company better. So, every kind of integration (here: ERP integration) should clearly be judged by serving overall business purposes. Thompson/Motiwalla (2012, p. 70) have identified the following overall benefits and limitations of ERP integration, which they further explain in their book and can be read in Table 4.3: Table 4.3: Benefits and Limitations of Systems Integration (Based on Motiwalla/Thompson (2012), p. 70) Benefits of Systems Integration

Limitations of Systems Integration

Increased revenue and growth Leveling the competitive Environment Enhanced information visibility Increased standardization

High initial setup cost Power and interdepartmental conflicts Long-term and intangible RoIs Creativity limitations

4.2 ERP Systems in the Market | 181

So after investigating the success of ERP projects, the ultimate question in a broader sense would be: Was it worth it and are you subjectively satisfied with implementing the ERP solution? When asked this question, companies have responded in the ERP study cited above like this:

Failure 10% Neutral or "I don´t know"

Success

30%

60%

Fig. 4.14: Implementation Outcome (Panorama Consulting (2013), p. 4)

So at first sight, the hardship of introducing an ERP system seems to have been worth it. However, there is a strange effect in the studies: whenever trying to pin down the satisfaction into different, single aspects, the single aspects are not rated that positively. Satisfaction levels of single goals/aspects of ERP introduction do not really add up to overall satisfaction with implementation outcome. The following figure shows satisfaction in single criteria like “ease of use”. As you can see, there are only three criteria in which customers were satisfied by a clear majority.

182 | 4 ERP Systems: Basic Concepts and the Example SAP

Flexibility to Change the Software Overall Software Functionality Implementation Service of Vendor Implementation Service of Third-Party Ease of use Ability to meet business needs Amount of customization needed Implementation cost Employee adoption Overall implementation experience 0 Very Satisfied

Satisfied

10 Neutral

20

30

Unsatisfied

40

50

60

Very unsatisfied

Fig. 4.15: Single Aspects of Satisfaction (Panorama Consulting (2013), p. 6)

Researchers speculate that customers are a little bit worn out by the ERP introduction and adjust their expectations, so the overall satisfaction might have also some answers of “resignation satisfaction”. Also, when it comes to satisfaction with the vendor of the software, not all is happiness: 50 % are satisfied or moderately satisfied with the vendor, but also 20 % are moderately dissatisfied. One claim of software vendors to introduce an ERP is the potential of improving efficiency. The following figure shows a collaborative process of purchasing new equipment, e. g. machinery. In this process, three very different departments/functions of the company are involved and have to work together until the new equipment is integrated technically and from accounting side. On the left and right side of the process, steps some real world business effect and the according value potentials (benefits in numbers) are envisioned. These potential improvements were collected by vendor SAP in discussions with customers, and SAP wants this figure only to be published with the following disclaimer: “The shown value potentials in the table were reported by selected SAP-customers or independent third parties. However, it cannot be guaranteed that these value potentials can be reached in every customer-specific business process and SAP offers no guarantees and assumes no kind of liability in view of the suitability of the mentioned value potentials for specific customer situations.”

4.2 ERP Systems in the Market | 183

Value Potentials

Business benefits

Up to 50% Improvement In cost control

Integration of cost producing Departments by integrated approval processes

Up to 70% more effective Work Processes

Comprehensive workflow linking for optimization of process sequences

Maintenance engineer

Materials Manager

Assets accountant

Business benefits Automatic data comparison between fixed assets and equipment by attaching inventory numbers

Checking and processing of changes in requirements Selection of material and creation of an order Creating purchase order Entering asset number in the purchase order

Value Potentials

Up to 100 % reduced workload

Linking of material and equipment data by Inventory numbers

Up to 100 % Increased Transparency

Depreciation of fixed assets directly on goods receipt

Up to 100 % faster booking

Automatic distribution of relevant data to all parties concerned

Up to 60 % time savings

Automatically fixed assets archiving Up to 60% lowered Maintenance tasks

High level of automation for data administration

Receipt of goods: Attaching of inventory numbers and generated equipment Deduction of goods from equipment which is marked with inventory numbers

Up to 50% reduced incorrect purchases

Direct selection of materials for maintenance by integration in the material management

Installation and maintenance of equipment

Synchronization between equipment and fixed assets

Fig. 4.16: Business Benefits and Value Potentials of Integrating a Process with SAP (Source: SAP 2005)

ERP systems do the trick of integrating departments via supporting business processes via single transactions, which are grouped into modules.

4.2.3 ERP Components Exemplified by SAP In SAP, the basic component is a so-called “transaction”, which in everyday language might better be translated by “action”. You already got to know some transactions and their screens in this and other chapters. SAP transactions are, for example:

184 | 4 ERP Systems: Basic Concepts and the Example SAP    

creating a material, creating a production order, releasing production orders, starting a materials requirement planning calculation (MRP-Run), and so on.

A transaction is dedicated to a single activity, and since SAP claims to cover every activity in a company, there are a lot of activities: currently some 16.000 (16 thousand!) single transactions exist in SAP. However, not every transaction will be used regularly, and most of us using SAP will never see all transactions since we do not have the roles and according rights. Transactions can be accessed via the easy access menu, but also by entering a “shortcut” code. E.g. MM01 will start “Creating Material Master Record”, MM02 “Change Material Master Data Record” and MM03 “Display Material Master Record”. A transaction is organized in a structured way and the system will guide you through a transaction (workflow) and will alert you if a must-field is not filled in. It makes sense to group and name those 16.000+ transactions into clusters or groups, if they are closely related and used by certain departments. These major groups are called “modules” in SAP and represent a collection of logically related transactions within identifiable business functions. Main modules are:  Materials Management – MM (“Buy”)  Production Planning – PP (“Make”)  Sales Distribution – SD (“Sell”)  Financial Accounting – FI (“Keeping books”)  Controlling – CO (“Track via Management Accounting”)  Human Resource Management – HR.  Using only this high level grouping would comprise too many transactions, so sub-modules and sometimes even sub-sub-modules are used. We will zoom in step by step into the module PP that might be most interesting to a production engineer.

4.2.3.1 The SAP Module PP and its Sub-Modules The module PP supports functions for the preparation and execution of manufacturing and supports optimal utilization of production capacities and production planning in general. The module PP consists of several sub-modules like  PP-SOP – Sales and Operations Planning  PP-CRP – Capacity Requirement Planning  PP-MP – Master planning  PP-ATO – Assembly orders  PP-BD – Basic Data  PP-IS – Information System  PP-KAB – Kanban/Just-in-Time

4.2 ERP Systems in the Market | 185

    

PP-MRP – Material Requirements Planning PP-PDC – Plant Data Collection PP-PI – Production Planning for Process Industries PP-REM – Repetitive Manufacturing PP-SFC – Production orders

Let’s focus on one single sub-module, e. g. PP-BD – Basic Data. This sub-module can be divided into several other sub-sub-modules, which will not completely be listed here.  PP-BD-RTG – Routings (work-plans)  PP-BD-BOM – Bill of Materials  PP-BD-CAP – standard values and formulas  … etc … Source: All information from the SAP help-system on the web

4.2.3.2 The SAP Sub-Sub-Module PP-BD-BOM Let’s focus on one single sub-sub-module, e. g. PP-BD-BOM – Bill of Materials. Please note that sub-sub-modules are not used in every sub-module.

Our sub-sub module PP-BD-BOM consists of transactions relevant to the creation and management of BOMs.  CS01 – Create Material BOM  CS02 – Change Material BOM  CS03 – Display Material BOM  CS05 – Change Material BOM Group  CS06 – Display Material BOM Group  CS07 – Allocate Material BOM to Plant  CS08 – Change Material BOM - Plant Alloc.  CS09 – Display Allocations to Plant  CS11 – Display BOM Level by Level  CS12 – Multilevel BOM  … etc … Source: All information from the SAP help-system on the web As you can see, the transaction name stands on its own without any resemblance to the module or sub-module name. This underlines the fact that modules and submodules simply act as a cluster of the basic action item: the “transaction”. Modules also serve as a means of packaging of relevant transactions for marketing rea-

3

186 | 4 ERP Systems: Basic Concepts and the Example SAP

sons. For example, a user might want to use the finance and controlling module (FI and CO), but not the HR module and might be given access to the according module.

4.2.3.3 Modules and Company Functions Modules group certain activities according to company functions. This is not confined to SAP; other vendors package their transactions into function-related modules as well. The next figure shows how the “big three” ERP vendors do this:

Table 4.4: ERP Modules From 3 Vendors (Based on Motiwalla/Thompson (2012), p. 84) Function

SAP Modules

Oracle/PeopleSoft Enterprise Modules

Microsoft Dynamics Modules

Sales

SD: Sales and distribution, sales opportunity

Marketing and sales, supply chain management

Retail POS, field service management

Procurement

MM: Purchasing, supplier relationship management

Procurement and supplier relationship management

Supply chain management

Production

PP: MRP, product life circle management

Manufacturing

Manufacturing

Accounting

FI: Financial accounting

Distribution

Warehouse Management

Financial management Supply chain management

Financial management Distribution management

Customer services

CRM

CRM

CRM

Corporate performance and governance Human resources

Governance, risk and compliance management HR: Human capital management

Corporate performance management

Analytics

Human capital management

HR management

Miscellaneous

Banking

Campus solutions

e-Commerce, portals

SAP has recut its modules several times and has also renamed the modules. The following figure is the classic SAP module grouping of the 1990s:

4.2 ERP Systems in the Market | 187

SD Sales & Distribution

FI Financial Accounting

MM Materials Management

CO Controlling

PP Production Planning QM Quality Management PM Plant Maintanance

AM Fixed Assets Management

R/3 Client Server ABAP/4

PS Project System WF Workflow

HR Human Resource

IS Industry Solutions

Fig. 4.17: Structure of SAP Modules Last Century (Source: SAP)

More recent marketing material from SAP structures modules and sub-modules differently and especially seeks to integrate important catchwords and new concepts like “Talent Management”, “Life-Cycle Data Management”, etc. Of course, big vendors like SAP have to react to new concepts and market demands, so new transactions are introduced regularly to meet the demand of the customer.

188 | 4 ERP Systems: Basic Concepts and the Example SAP

Analytics

Strategic Enterprise Mgmt.

Financial Analytics

Operations Analytics

Workforce Analytics

Financials

Financial Supply Chain Mgmt.

Financial Accounting

Mgmt. Accounting

Corporate Governance

Human Capital Management

Talent Mgmt.

Workforce Process Mgmt.

Procurement and Logistics Execution

Procurement

Supplier Collaboration

Inventory and Warehouse Mgmt.

Inbound and Outbound Logistics

Transportation Mgmt.

Product Development and Manufacturing

Production Planning

Manufacturing Execution

Enterprise Asset Mgmt.

Product Development

Life-Cycle Data Mgmt.

Sales and Service

Sales Order Mgmt.

Aftermarket Sales and Service

Professional Service Delivery

ForeignTrade Mgmt.

Incentive and Commission Mgmt.

Corporate Services

Real Estate Mgmt.

Project Portfolio Mgmt.

Travel Mgmt.

Environment

Quality Mgmt.

SAP NetWeaver

People Integration

Information Integration

Workforce Deployment

Process Integration

Application Platform

Fig. 4.18: Recent Structure of SAP Modules this Century (Source: SAP)

However, this does not change the “real thing”, meaning the transaction and its codes, at all. For over 30 years now, material master data has been created with the transaction “MM01” and it probably will stay that way for some more years. Companies all over the world using SAP have invested billions of Euro and Dollars to train their staff to use and get used to the SAP world, and they do not want this investment to vanish because of new names and structures within transactions. All ERP systems, like the market leader SAP, are reaching out to Supply Chain Management (SCM) and Customer Relationship Management (CRM) – but we will not deal with these topics in this book. ERP systems follow an “all to everyone” approach and are ready to map any kind of business and company into their integrated system. However, this size and integration comes at a cost, as you learned in chapter 3 by discussing advantages and disadvantages of integration. Having an integrated, all-encompassing system is great, but it still has to be customized for the individual customer. This customization effort raises the broader the reach of ERP systems into every industry gets. Customers of ERP systems try to avoid too much customization effort. So, there is a clear dilemma that will never go away and is independent from technology: in order to offer ERP (like SAP) to more and more different industries and customers, the expenditure for customizing rises as well. SAP has reacted to

4.3 Detailed View on Structure of Objects in SAP Modules | 189

this dilemma by predefining scenarios for certain industries, where many things are already preset or pre-customized for a certain industry. SAP offers its systems both to banks and the petrochemical industry. Every company in these industries is individual, but the difference between banks and chemical companies will be far greater than between banks. So banks and the chemical companies will be offered pre-configured industry solutions by SAP right away, see: http://help.sap.com/industries.

4.3 Detailed View on Structure of Objects in SAP Modules The following chapter deals with important data objects in certain modules and how they are structured to support the processes.

4.3.1 Enterprise Structure in Materials Management and Production Planning The tasks and processes of Materials Management as a SAP module are exactly what you would expect: they deal with the purchase, storage and valuation of materials coming into the company. The only surprise to a non-SAP or ERP specialist would be that every physical thing in the company is called “material” (see chapter 2), so creating a master data record for a finished good that will be sold after manufacturing is, of course, a “material” as well. Typical transactions in the module Materials Management (MM) include, but are not confined to:  Creation, change, deletion and reporting of master data records for materials and suppliers (vendors)  Creation, change, deletion and reporting of info records which contain prices of a certain vendor for a certain material  Creation, change, deletion and reporting of Request for Quotations (RFQ’S)  Issuing and administrate purchase orders to vendors  Creation and monitoring of stock movements and stock level and documenting of physical inventory  … For more information, see official SAP documents that can be found here: http://sapdocs.info/application-modules/mm-overview/

Transactions of Production Planning (PP) include, but are not confined to:  Creation, change, deletion and reporting of master data records for materials, BOMs and routings

1

190 | 4 ERP Systems: Basic Concepts and the Example SAP     

Creation, change, deletion and reporting of capacities that can be used in workplans Creation, change, deletion and reporting of cost centers Creation, release and confirmation of work orders. Managing of MRP runs …

3 For more information, see official SAP documents that can be found here: http://sapdocs.info/application-modules/pp-overview/

Basically, PP transactions in SAP represent IS support of real world actions described in chapter 2. In order to use materials or other objects in manufacturing and production planning, they need to be attributed to logical units of action. E.g. if a finished good is manufactured and put into storage, it needs to have a unique storage location. Only there can it be accessed by sales to be shipped and delivered to customers. Since every storage location belongs to exactly one company (legal unit), it is also clear that this finished good will increase the inventory of exactly this firm’s balance sheet, and so on. These logical units have to be defined in a certain order in which their relationships (1:n, n:1; n:n) are precisely regulated. For example, one storage location can only belong to exactly one company code (legal unit). Every legal unit renders its balance sheet to exactly one tax authority in one country, and so on. On the other hand, every company might have several storage locations and shipping points for sales distribution, and so on. On the other hand, a purchasing organization (global) and a purchasing group do not need to care about country or company boundaries. Several purchasing groups might buy for several different legal entities, without any strict connection. This would be called an n:n relationship. The following figure shows important objects in Materials Management needed for master data records.

4.3 Detailed View on Structure of Objects in SAP Modules | 191

Fig. 4.19: Important Objects in MM Needed for Master Data Records (Based on SAP-Material)

Corporation and Client: Revestacon is the name of a corporation that manufactures wind turbines and offers maintenance services for offshore wind parks. This corporation owns several firms as subsidiaries around the world. When Revestacon declares profits in the US, it is not just including the US company, but the entire world. SAP claims being able to reflect such a multi-national multi-division cooperation in one system. This system is called a SAP Client and a material master record, like a wind turbine, can be accessed from anywhere in this system’s database, and its number will be unique in a client. Company Code: Revestacon in the US, in Canada and in Germany will be run as separate legal entities or subsidiaries. A company code is one legal entity that reports its financials as a P&L and a balance sheet. So, every expenditure and revenue and every valuated material in stock has to go into the P&L and balance sheet of exactly one company code. Plant: A plant is the facility where goods like wind turbines are manufactured. In a trading or pure service company, the production might not be physical in the traditional way. However, there is still a place of production like an outlet of a fast food chain, and this would still be a plant in SAP-speak. So, a plant can be a physi-

192 | 4 ERP Systems: Basic Concepts and the Example SAP

cal or virtual place where goods are manufactured or services delivered. And it is also the organizational level where Material Requirements Planning (MRP) runs are executed. For example, there is a plant in Hamburg that manufactures the nacelle of the wind turbine. Storage Location: Each plant might have several storage locations. Storage is a place where raw materials are stored after being purchased, semi-finished goods are stored between stages of production, or finished goods are stored before being sold. For example, the Hamburg plant could have storage locations directly in Hamburg itself and another one in a village nearby. Of course, a storage location is just a logical place that might exactly be a real location. However, it is also possible that a storage location comprises three warehouses within several kilometers’ distance. Shipping Point: A Shipping Point is the highest level organizational unit of shipping and controls’ shipping activities. Material can enter or leave the premises of an organization through a Shipping Point. Each outbound delivery is processed by only one Shipping Point. A Shipping Point can be assigned to more than one plant and a plant can also have more than one shipping point. Purchasing Organization: A purchasing organization is responsible for the procurement of materials and services in a legal sense, so it might serve different plants in a single company code. The company is free to reflect its specific real life organization of purchasing – for example, purchase by plant, by country or by group of materials. A purchasing organization can avail the conditions and centrally agreed contracts contained in the assigned reference purchasing organization. Purchasing group: A purchasing group is responsible for specified purchasing activities. It is often used to identify individual buyers and is focused on persons in purchasing. For example, there is a purchasing group responsible for buying metals that will be used in manufacturing the wind turbine. However, Revestacon focuses tightly on countries, so they form purchasing groups for single countries. There is no direct relationship between a purchasing organization and a purchasing group. Central Purchasing Organization: A central purchasing organization enables a corporation to define a unit in which contracts can be globally agreed. As compared to a normal purchasing organization, it is not confined to a single company code, but stretches across the whole client. Big ERP vendors always try to extend their offerings into markets that were previously occupied by specialized small vendors. One example of this expansion is the extension of the logistics module: SAP also enables running a warehouse by defining aisles, racks and storage places. For more information see: http://waltoncollege.uark.edu/lab/ProfMIS/WCOB5223/NonBPI%20Presentations/Slides_F2F_08252012_MM-SD_ABRIDGED.ppt Slide 16.

4.3 Detailed View on Structure of Objects in SAP Modules | 193

To understand the processes of Material Management and Production Planning that use these 1 structures, you might want to reconsider the underlying concepts: The transactions of Material Management (MM) are topics in lessons about supply chain logistics and procurement. The transactions of Production Planning (PP) are topics of PPS systems, and therefore, discussed in detail in chapter 2.

4.3.2 Enterprise Structure in Financial Accounting and Controlling While MM and PP deal with the real material world, there is a financial world, as well, that can be managed in an ERP system like SAP. As you know from other lectures, there are three purposes for keeping track of the money streams of a company. First and foremost, in every country there are laws of the government that force a company to show what they have earned in the last year (P&L) and what assets and liabilities they have (balance sheet). Authorities force these publications onto companies to have a solid base for taxing them. On the other hand, a true and fair view on the state of the company enables shareholders, customers and suppliers to make efficient decisions. Available, trustable information is a very important part of creating markets and making them work. This is called financial accounting (external accounting) and supplied by the “FI” module and its submodules in SAP. Secondly, an internal cost accounting (= management accounting) helps management to base decisions on cost or revenue data. Internal management accounting is not regulated by law and can be done as seems fit. It uses most information from regular financial accounting, but of course, differs in some values and positions: tax authorities and management have different information needs. Management wants to base decisions about objects like cost, centers, profit centers, products on financial numbers. This is called “management accounting” (internal accounting) and supplied by the “CO” modules in SAP. Third, there is the world of pure cash and liquidity whose task it is to ensure that the company is solvent and can meet its obligations at any time. However, keeping cash is also expensive (earning no or little interest/returns), and so cash management seeks an optimal level of solvency. Planning for liquidity is quite different from the P&L for two reasons: first, there are many positions in the P&L that do not touch cash-flow and positions might be missing that are relevant for cash, like building up inventories. Secondly, a P&L needs to be done once a year, whereas there needs to be enough cash every day in the company to meet its obligations. This separate calculation is called cash management and covered by the “Treasury” module in SAP.

194 | 4 ERP Systems: Basic Concepts and the Example SAP

5 You might want to reconsider lectures about financial accounting, management accounting and corporate finance to refresh the basic rules, tasks and processes of these areas to better understand how SAP helps companies manage these areas.

The following figure gives a rough overview of how these parts work together:

Fig. 4.20: Overview of Connections Between Finance and Accounting Elements (Based on SAP-Material)

Human resources: Real live action in the physical world in human resources, inventory management, sales, and so on will cause a monetary shadow that needs to be booked into account. If we for example purchase screws, we will receive an invoice that needs to be booked into the general ledger. Accounts receivable: There are also so-called special ledgers that represent an excerpt from the general ledger. They are usually enhanced with information that is of no further interest for creating the balance sheet and the P&L statement, but gives important information for the responsible company function. The special ledger Accounts Receivable, for example, will show information from the general ledger like amount and name of customer. However, it will also report the total amount receivable for certain customers and enables statistics that show whether this customer is a quick payer.

4.3 Detailed View on Structure of Objects in SAP Modules | 195

Balance sheet and P&L: The information in the general ledger will be processed to create the financial and commercial balance sheet and the financial and commercial Profit and loss statement (commonly abbreviated as P&L), as well. Treasury and Cash management: A separate branch of accounting is treasury or cash management. It serves to calculate and ensure liquidity at every moment of the company’s operations. A good P&L with a lot of accounts receivable might translate into a bad cash position, so there needs to be a separate cash calculation. Cash management not only gets its information from the general ledger, but also from logistics modules that deal with the physical world. For example, when a purchase invoice is booked, its payment deadline is automatically transferred to cash management to raise cash demand for the day the invoice is due. Product Costing: Finally, the bookings in the general ledger are also used for management accounting. There have to be some adjustments to revenues and expenditure, overhead costing has to be solved via cost centers, and ultimately profitability of various objects (like products) can be calculated. These interconnected processes need a structure for financial management. In order to let SAP run the calculations described above, every material, customer, expenditure or revenue has to be attributed to a SAP object. The following figure augments the structure of chapter 4.3.1by explaining the objects needed for financial modules.

196 | 4 ERP Systems: Basic Concepts and the Example SAP

Fig. 4.21: Objects Needed for Financial Modules (Based on SAP Material)

Operating Concern or “Result Area”, as it is sometimes called, represents the highest reporting level in profitability analysis. By examining costs against revenue, operating profit can be calculated for individual market segments. Operating concerns also allow complex analyses of operational results of different objects, such as analysis by product, customer or geographical region, and so on. An operating concern might span across several companies and countries. Since it belongs to internal cost accounting, it is not restricted by any laws or regulations. A Credit Control Area is a logical unit created to control customer credit limits. Since most companies and most of their customers are operating as multinational and multidivisional, a control of credits needs to be established on a high level. E.g. if one of our customers has had too many outstanding accounts in Germany and did not pay the invoices we sent him, he will be barred from receiving any further shipments from us, or even placing orders. We need to prevent his subsidiaries in China from placing orders at our subsidy in China, and this needs cross-company code coordination. A company code is assigned to one and only one credit control area, while multiple company codes can be assigned to one credit control area.

4.3 Detailed View on Structure of Objects in SAP Modules | 197

A chart of accounts lists and structures the bookkeeping and cost accounts. A chart of accounts must be assigned to every company code, while several company codes can use the same chart of accounts. So the Reveastacon cooperation might use the same chart of accounts for the companies located in Germany, Austria and Switzerland. A business area allows reporting commercial balance sheets and P&L’s across company codes, which will not be used for commercial and tax law. They are used for internal reporting purposes and segment reporting across company codes as defined by the corporation. This might be necessary because a multidivisional cooperation, like Revestacon, manufactures wind turbines (next to other things) in all subsidiaries and companies across the world. However, we want to know how our wind turbine business is doing across the corporation without other products (like technical services). All essential balance sheet items, such as fixed assets, receivables, payables, and inventories, and all items of the profit and loss statement can be assigned directly to a business area. A cost center is a logical unit to which indirect or overhead cost can be attributed. Often, it might be a real department. A cost center can be assigned to only one company code and to one division. A cost center serves two purposes: first, it facilitates the distribution of overhead cost to single products. Often, it is easier to first separate cost line items, like labor cost to cost center, and then distribute it onto products that use the cost centers. The second purpose is to allocate overhead budget to a cost center so it can be controlled more easily and the person responsible for a cost center is also responsible for the overhead budget.

4.3.3 Enterprise Structure in Sales Sales is the third important function of every company next to sourcing and producing. Transactions in the realm of sales comprise selling activities in the marketing sense, but also all outbound logistics and shipments from company to customer. The following figure shows the organizational units and logical objects used in sales:

198 | 4 ERP Systems: Basic Concepts and the Example SAP

Fig. 4.22: Organizational Units and Logical Objects in Sales (Based on SAP Material)

Sales organizations within a company are responsible for selling goods in a legal sense. Just like purchase organizations, they might be organized along several dimensions. In this example, sales is organized by geography. For example, the western sales organization is responsible for selling goods in the western states of the USA and is also responsible for handling returns, credits, availability of materials, etc. If sales is organized by types of customers, there might be two sales organization named “Key Account Management”, serving large customers, and “Bulk Business”, providing sales to many smaller customers. A sales office is a physical internal unit in which sales personnel are organized to sell products to customers. Usually, sales offices are used to service a certain geographical area; thus, one sales office generally, but not in compulsory fashion, is assigned to one sales organization. Each sales office contains multiple sales groups which have a fixed set of responsibilities. It could be based on the products that they sell, the type of sales that they perform, or the role they play in the actual sale. For example, a sales group could be responsible for selling MRO parts used in wind turbines, while others will be responsible for selling the software used in the ma-

4.4 Using an ERP system by the example of SAP | 199

chines. One sales person belongs to only one sales group, and one sales group belongs to only one sales office. Just as the name implies, a distribution channel is the sales channel through which products are distributed. In this figure, the products could be sold through the direct channel via internet or through wholesale trade customers. Other sales channels might be retail or independent sales representatives. Each one will be represented as a distribution channel, and this will allow controlling the logistics flow and the profitability of a channel to be evaluated. A division is an external, market-oriented grouping of certain products and customers. For every division, customer-specific agreements can be fixed, for example, partial deliveries, pricing and terms of payment. Within a division, statistical analyses can be reported or separate marketing procedures can be set up. For example, the “Offshore division” of our company, Revestacon, comprises certain products for customers who build wind parks offshore. A combination of the sales organization, distribution channel and division is called the sales area. It is used for reporting and controlling purposes. If you are interested in the transactions of the module Sales Distribution, you can look this up on 1 the web on the official SAP site or here: http://sapdocs.info/application-modules/sd-overview/

4.4 Using an ERP system by the example of SAP In the previous chapters, you have learned about the processes and logical structures of SAP in its different modules and parts. In this chapter, you will learn more on how to use a real SAP client. This entire chapter assumes that you take this class at an institution that is a member of the SAP 3 Academic Alliance (AA) and has access to an IDES client (see chapter 4.7). You might also use copyright protected material from SAP that you will need to download separately. Links to this external material will be offered if using the SAP IDES client is part of your class. If your instructor is using a different ERP System than SAP, like for example, Microsoft Dynamics AX, your instructor will deliver information and training material. The following explanations only refer to SAP.

4.4.1 Basic Look and Feel of the ERP System and Individual Settings Before getting into the real thing – working in transactions – you should get a feeling for the look and feel of SAP and how to tweak basic personal parameters in order to work comfortably.

200 | 4 ERP Systems: Basic Concepts and the Example SAP

The word “customize” should carefully be avoided in this context. Customizing in the SAP world means to structure a client to the need of the cooperation (see chapter 4.2.3). All structures explained above are merely an offer to the individual cooperation and needs to be set individually. For example, our company, “Revestacon” wants to assign the sales organization of their service “Revestacon Services” with the distribution channel “direct sales” and their division, “Revestacon offshore services and measurement”. This, of course, cannot be prepared in advance in the standard SAP package, and thus, needs to be customized. SAP is compliant with the windows environment with which you are probably familiar. However, it paid tribute to the fact that there are many other operating systems (see chapter 4.4.2). 5 There is a separate document that will introduce you into the look and feel of SAP. If your university is member of the SAP AA, your instructor might supply this material. This document should be called something like Navigation_Introduction_en.PDF and will be supplied by your instructor. Read through this document and make yourself familiar with the look and feel of SAP!

On the web, you find many links for a commented introduction into SAP if you look for “SAP navigation tutorial”, for example: http://youtu.be/i8JgAtE19II. Once you have looked through the basic navigation presentation, you might want to try some basic operations yourself. You will be able to do real live actions in a real SAP system. In order to take part, you need a login and a way to access a training client of your institution (see chapter 4.4.2). 5 Before you try it out yourself, download the following document from your course site and work through it carefully: Navigation_Course_en.PDF

This Navigation Course is recommended by SAP before doing the real business scenario of the case study. The navigation course is self-training for you to go on your first steps in the SAP world. An average user of Windows, Apple, Android and typical internet browsers will find some unusual things when working with SAP. Here are some tips for using the system:  If tables are not displayed correctly or with all columns you want to see, please resize them accordingly, to see what you need.  Also, some lists are longer than the screen can show, so you might need to scroll.

4.4 Using an ERP system by the example of SAP | 201





 

 



You are not told to fill all the fields and in most of the cases this is not necessary. However, there are some “must”-fields that must be filled before you are allowed to save a data set or even move on to the next register. Values or text typed into text fields are not saved before you press enter or click the save button. If this is a must field, only after pressing enter will you be allowed to move on. Just clicking somewhere else will not be enough. Always try to finish a transaction: the ACID principle demands that you finish a transaction by pressing save. Data entered, but not saved, might be lost. Do not open too many windows accessing the system – otherwise, there might be conflicts, and the system will reply that data is “locked” because you might already be working on it. The help function, “performance assistant”, will be filled by the real company – in IDES it often empty, because it was not filled by SAP. Sometimes values are already present, even if you start a fresh transaction. Often, these values might already be the ones demanded by your case study paper, but sometimes wrong values are present. You have to check each field carefully and make sure only values are entered. Be especially careful with storage locations. If you enter 0100 for a storage location, when it should be 1000, a material will be booked exactly in location 0100, and not 1000, and you will have a tough time finding it.

Some users find the tight control of the system when using a transaction annoying, but this is the way SAP works: it not only supports existing processes, but forces users into processes predefined by SAP or the company. For example, it is not possible to carelessly enter material with values missing: SAP will not allow you to finish the transaction unless it is really finished in the mind of SAP: with all values present and all required mandatory fields filled.

4.4.2 System Roles and Transactions Once you are logged into the training system, you will see many transactions available to you in the Easy Access menu. An ordinary staff member in an average company probably will not see as many transactions. Access to any ERP system is restricted by a role system: every person or login is given one or more roles. Each role is allowed to execute certain transactions. For example, Mr. Suplician might work in the purchasing department as a strategic purchaser. His task is to search, evaluate and monitor major suppliers. For his work, he needs only certain functions of the system, like looking at statistics of the deliveries of suppliers, entering new suppliers, changing existing suppliers and issuing RFQ (Requests for Quotations). These real-life tasks might be supported by a dozen SAP transactions. So, if Mr. Suplician logs into the SAP system, he will only

202 | 4 ERP Systems: Basic Concepts and the Example SAP

see the transactions he is entitled to see in order to do his work, like e. g. MK01 for creating a vendor (= supplier). Mr. Suplician is assigned the role of a “purchasing manager”, a role that needs to be defined by the company. His colleague, Ms. Purcasa may be given the role of a purchasing manager and the role of a project manager (with according rights and transactions) too, since she needs it. All roles must be defined by every company individually. In order to save companies time, SAP offers some predefined roles that can serve as templates for the companies’ individual roles. The following figure shows some predefined roles that are offered by SAP. Table 4.5: Predefined Roles Offered by SAP (Source: http://help.sap.com/bp_ekit604/Documentation/ NWBC_How_to_Improve_User_Experience_via_Roles.ppt) Accounts Receivable Accountant Accounts Receivable Manager Accounts Payable Accountant Accounts Payable Manager Administrator Assets Accountant Bank Accountant Business Analysis Purchaser Buyer Customs Agent Employee Engineering Specialist Enterprise Controller

Customs Agent Finance Manager General Ledger Accountant Maintenance Employee Maintenance of Accounts Receivable Master Data Pricing Specialist Product Cost Controller Production Planner Project Manager Purchasing Manager Quality Specialist Sales Administration

In order for you to get a sense of the overarching business processes, the case studies show a process that demands many different roles and persons in reality. So, for you to complete the case study, you will play several roles that would seldom be granted to a single person in reality. Each student account in this chapter will be granted the following roles:  materials management personnel,  production planer,  controller, and  production worker.

4.4 Using an ERP system by the example of SAP | 203

4.4.3 Access to the Training System In this chapter, you will start working in a “real” SAP System. SAP gives members of its university program (SAP AA) the opportunity to rent full-fledged SAP clients for training purposes. Those clients are usually hosted in only a few central universities (UCC – University Competence Centers) in each country. So, AA members will just have the clients installed in their institution and access the systems hosted in the UCCs. This is a good example of the client-server structure described in chapter 4.1.3.2. The client and application server may be physically thousands of miles apart and are connected via the internet. Part of the AA arrangement is that SAP does not support users of the training system directly; this is the job of each instructor teaching SAP. So please: Never contact SAP directly. Support of IDES users is positively NOT their task. Contacting 4 SAP directly might result in additional fees for which your university is not responsible. The sole responsible person is your instructor and the persons and institutions he or she chooses to support you – never SAP directly.

AA members are offered a remote access for their students. In order to be granted access, the instructor has to list your name or login at the SAP UA homepage. Please consult your instructor for details. The following figure shows the client server structure used if you are accessing via remote:

204 | 4 ERP Systems: Basic Concepts and the Example SAP

Instructor of UA member

Students at home

UCC Database Server

Fig. 4.23: Client Server Structure for SAP Remote Access to Case Studies

An AA member probably also has SAP clients installed in their computer rooms. Please look for further individual information, like the number of the SAP clients available. If you do not access the client remotely, but are using the computers in your university, you will log in by starting the Windows SAP client on the desktop of your institution’s computer. Once you start the SAP-Client on your desktop computer or any other device, you will see this screen.

Fig. 4.24: Login Details (Source: SAP)

4.4 Using an ERP system by the example of SAP | 205

Enter the information requested:  Client: The training client for your university, e. g. 903  User: HCC-##, where ## is your personal 2-digit ID  Password: The initial password for first login will be sent to you by your instructor. You will be asked to change it after first use. You, as a student, will be assigned a two-digit number that will be your unique ID for using the SAP system, especially for the case study described below. This number will be given to you by your instructor. Your student ID or name will be assigned to the two-digit number, from now on called your “training ID”. Your training ID serves two functions: 1. It is part of your login. If you have been assigned training ID 25, your login will be HCC-25. 2. It will uniquely identify the materials and other data you create in the system and distinguish you from other students. When you are assigned training ID 25 and are asked to create a material called UCC-MOTORCYCLE-##, it means that you must call this material UCC-MOTORCYCLE-25. Whenever you read “##” in your case study, please replace it with your training ID. Entering a non-customized SAP client containing no data whatsoever would not enable you to experience a real business scenario. That is why SAP is providing a complete “real” cooperation called Internet Demo and Evaluation System, shortened to IDES. It is customized to a corporate structure and filled with real data that you will be using. IDES represents a cooperation that enables demonstration of all SAP functions for the purpose of training, tryouts for potential customers, and academic simulation. In order to show all functions and possibilities, it is expanded very far:  It is active in many different business fields, like banking, retailing and manufacturing.  It comprises many different companies (legal units) that each have a different focus of operations and special features  It is active in many different countries with different currencies If you are interested in the details of this training cooperation, you can easily look this up, e. g. 1 here: http://sapecc6.blogspot.de/2008/06/ides-organizational-structure-and.html

The SAP clients of the UA members all contain clones of the IDES cooperation, and this is where you will log into. Other ERP vendors have their own training cooperation. SAP provides a fixed set of case studies using its IDES cooperation that build upon another.

206 | 4 ERP Systems: Basic Concepts and the Example SAP

Table 4.6: Content of the SAP IDES Case Studies and Modules Used Name Case Study 1: PP Production Planning Case Study 2: CO Controlling Case Study 3: LO Logistics Case Study 4: PS Project Management

SAP Modules used MM PP CO

Create internal cost center and use them to distribute general and administrative overhead cost onto finished products.

PP CO

MM PP

CO

Content of case study Creating material master records and combine them to manufacture a finished product

SD

FI

SD

FI

A complete “order to cash”- process including sales, purchasing, accounting, inbound and outbound logistics. Create HR master records and use them for selling consulting services. Create a project HR PS milestone plan for invoicing consulting services during the project.

If your instructor uses the IDES case study, an animation prepares you for the case study. Then you can work on the case study itself, or the instructor might present it to you in class. After this introduction, you are ready to complete the case study that will also be supplied by the instructor in case the university is a UA member. 3 In case the instructor for this chapter wants to present a different ERP system, like e. g. Microsoft’s Dynamics AX (formerly known as “Navision”), there might be a different presentation for introducing you to a case study and a different case study available for download on your course site. Also, in an international context, there is another SAP training system: Global Bike Inc. – ask your instructor for more information.

4.5 Summary of Chapter 4 ERP systems are still a form of horizontal integration often chosen by midsize and bigger companies. They integrate by using common master data records and map real business processes to single transactions. Integrated applications like ERP systems also need efficient hardware architecture to support them. This hardware architecture was developed first in the 70s with mainframe computers, and is now starting to get more and more virtualized with cloud computing widely distributing the IS landscape all over the world. However, the classical three tier approach of client server systems still prevails as the base for most ERP systems. The client server approach offers many advantages, especially for an efficient use of hardware and for scalability. Also, in ERP

4.6 Literature for Chapter 4 | 207

systems, there are new developments like cloud computing, SOA and database improvement; they are not yet able to replace the three tier approach, but rather just modify it. The ERP market is ruled by big three vendors that make up half the market: SAP, Oracle (with different brands) and Microsoft NAV. However, there are several two tier players that continue to play a role. The use of ERP systems is widespread in many industries and all company sizes, except very small ones. Success of the implementation and the use of ERP systems seems mixed, at best. However, some modern businesses would not even be able to take part in the market without using ERP systems. The basic item of an ERP system is a transaction in which data is created, changed and retrieved via the client server system. Transactions map single steps of a business process across company functions. Transactions are grouped into modules by vendors to cluster transactions for the company functions that need them. Also, modules can be booked or bought individually, thus enabling better marketing packages for the vendors. So, transactions connect processes and map the company structure. ERP systems achieve this through data objects and units (e. g. a “plant” or a “material”) to which processes and data are tied. Materials management, sales and HR of ERP systems offer logical units to which a real company can map. The names of these units might be vendor specific, and mapping a real company structure and processes to the system needs customizing since it is what makes a company unique. ERP vendors offer case studies for training and simulation purposes. One of them is IDES by SAP. Before starting a case study, you should get a feeling for the look and feel and get to know the system. Access to the real life client is provided by the university offering this module.

4.6 Literature for Chapter 4 Laudon K.; Laudon J.: Management Information Systems (12th edition), Prentice Hall 2012 Laudon K.; Laudon J.: Management Information Systems (11th edition), Prentice Hall 2010 Laudon K.; Laudon J.; Schoder, D.: Wirtschaftsinformatik (2nd edition), Pearson Studium 2010 Motiwalla, L.; Thompson, J.: Enterprise Systems for Management (2nd edition), Prentice Hall 2011 Panorama Consulting Solutions: 2011 Guide to ERP Systems and Vendors, Denver Colorado, http://panorama-consulting.com/Documents/2011-Guide-to-ERP-Systems-and-Vendors.pdf Panorama Consulting Solutions: 2013 ERP Report, Denver Colorado, http://PanoramaConsulting.com/resource-center/2013-erp-report/

208 | 4 ERP Systems: Basic Concepts and the Example SAP

4.7 Review Questions for Chapter 4 4.7.1 Close: Evolution of Enterprise Systems Please choose the name of the enterprise system described, when it first was introduced, and on what platform it was running. 1)

With a focus on sales and marketing, [Inventory management and control, Enterprise resource Planning (ERP), Materials requirements planning I, MRP II, Extended ERP or ERP II] systems were designed for job shop scheduling processes. They generate schedules for production planning, operations control, and inventory management. They were first introduced in the [1960s, 1970s, 1980s, 1990s, 2000s] and were running on [mainframe legacy using thirdgeneration software like Cobol and Fortran, mainframe legacy using fourthgeneration database software and manufacturing applications, mainframe or client-server using fourth-generation database software and application support for most company functions, client-server using web platforms with fifthgeneration applications and cloud environments].

2)

With a focus on agility and customer-centric global environment, [Inventory management and control, Enterprise resource Planning (ERP), Materials requirements planning I, MRP II, Extended ERP or ERP II] systems extended the first-generation ERP into inter-organizational systems ready for e-Business operations. They provide anywhere, anytime access to resources of the organization and their partners; additionally, they integrate with newer external business modules, such as SCM and CRM. They were first introduced in the [1960s, 1970s, 1980s, 1990s, 2000s] and were running on [mainframe legacy using third-generation software like Cobol and Fortran, mainframe legacy using fourth-generation database software and manufacturing applications, mainframe or client-server using fourth-generation database software and application support for most company functions, client-server using web platforms with fifth-generation applications and cloud environments].

3)

With a focus an manufacturing strategy and quality control, [Inventory management and control, Enterprise resource Planning (ERP), Materials requirements planning I,MRP II, Extended ERP or ERP II] systems were designed for helping production managers in designing production supply chain processes  from product planning, parts purchasing, inventory control, and overhead cost management to product distribution. They were first introduced in the [1960s, 1970s, 1980s, 1990s, 2000s] and were running on [mainframe legacy using third-generation software like Cobol and Fortran, mainframe legacy using fourth-generation database software and manufacturing applications, Mainframe or client-server using fourth-generation database software and applica-

4.7 Review Questions for Chapter 4 | 209

tion support for most company functions, client-server using web platforms with fifth-generation applications and cloud environments]. 4)

With a focus on efficiency, [Inventory management and control, Enterprise resource Planning (ERP), Materials requirements planning I, MRP II, Extended ERP or ERP II] systems were designed to manage and track inventory of raw materials and guide plant supervisors an purchase orders, alerts, and targets, providing replenishment techniques and options, inventory reconciliation, and inventory reports. They were first introduced in the [1960s, 1970s, 1980s, 1990s, 2000s] and were running on [mainframe legacy using third-generation software like Cobol and Fortran, mainframe legacy using fourth-generation database software and manufacturing applications, Mainframe or client-server using fourth-generation database software and application support for most company functions, client-server using web platforms with fifth-generation applications and cloud environments].

5)

With a focus on application integration and customer service, [Inventory management and control, Enterprise resource Planning (ERP), Materials requirements planning I, MRP II, Extended ERP or ERP II] systems were designed for improving the performance of the internal business processes across the complete value chain of the organization. They integrate both primary business activities like product planning, purchasing, logistics control, distribution, fulfillment, and sales; additionally, they integrate secondary or support activities like marketing, finance, accounting, and human resources. They were first introduced in the [1960s, 1970s, 1980s, 1990s, 2000s] and were running on [mainframe legacy using third-generation software like Cobol and Fortran, mainframe legacy using fourth-generation database software and manufacturing applications, Mainframe or client-server using fourth-generation database software and application support for most company functions, client-server using web platforms with fifth-generation applications and cloud environments].

4.7.2 True/False: Statements about Data Views Only two of the following statements are TRUE – please choose. 1)

Data views offer a history of data, in case it has changed over time

2)

Data views group data for certain departments and roles

3)

Each data view contains a single different material

4)

Each material has exactly one data view

5)

In one ERP client, a certain data view on one unique material number will show exactly one set of values

210 | 4 ERP Systems: Basic Concepts and the Example SAP

4.7.3 Close: The Core Strength of an ERP-System The strength of an ERP system lies in solving the dilemma of customer processes and company department: each [company, department, process, worker] works on its steps with their own [department, process, transaction] but accessing the same [department, data, transaction] and following the common [department, process, data] structure. So, an ERP system also enables a programmed workflow.

4.7.4 Close: ACID Principle in ERP Database Operations Please tell which ACID principle would be violated by the following phenomena in a database. There is a sentence for every principle. 1)

[Atomicity, consistency, durability, isolation] requires that each transaction is “all or nothing”: if one part of the transaction fails, the entire transaction fails, and the database state is left unchanged.

2)

[Atomicity, consistency, durability, isolation] means that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors.

3)

The [atomicity, consistency, durability, isolation] property ensures that any transaction will bring the database from one valid state to another. Any data written to the database must be valid according to all defined rules.

4)

The [atomicity, consistency, durability, isolation] property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i. e. one after the other.

4.7.5 Close: Client Server Structure and Tiers For each gap, please choose the correct word to complete the sentence: 1)

The [presentation tier, business logic tier, database tier] handles clients’ requests from users, retrieves data from the database tier, and processes data as needed. For efficient use of computing power, user requests and data operations need to be coordinated and processed one after another, but very quickly. In SAP, this handler is called a dispatcher.

2)

In the [presentation tier, business logic tier, database tier] data is entered into the system by users via graphical user interfaces like SAP -masks or web -forms. Sufficient bandwidth is necessary to ensure smooth communication, especially when transferring non-textual inputs, like videos. The requests issued by the different clients must be coordinated and supported by sufficient capacity of the application.

4.7 Review Questions for Chapter 4 | 211

3)

The [presentation tier, business logic tier, database tier] provides the central repository for all data that is shared among functional modules, and maintains the integrity of data transferred to and from the clients and servers. It not only writes, stores and retrieves data. It is also responsible for maintaining security and availability of the data by employing backup concepts and planned redundancies.

4.7.6 Close: Client Server Operations For each gap, please choose the correct word to complete the sentence: The process of client server interaction is straightforward: a [client, server, database] asks a [client, server, database] to execute certain tasks by sending certain inputs. The application-[client, server, database] connects to the [client, server, database] and gets stored information necessary to fulfil the task. Then, information from the [client, server, database] and information from the client is processed, and certain actions and values are returned to the [client, server, database] and perhaps also written down in the [client, server, database].

4.7.7 True/False: Advantages of Client Server Please choose three statements that are true about client server architecture. 1)

Scalability. Three tier architecture allows for easier architecture to add, change, and remove applications because the user interface and database are not affected by upgrades to applications.

2)

Flexibility. By separating the business logic of an application from its presentation logic, three tier architecture makes the application much more flexible to changes. Flexibility in partitioning can be as simple as “dragging and dropping” application code modules onto different computers.

3)

Economics. Three tier applications require overall considerable less hardware and software infrastructure to support the middle layer, which can decrease the overall platform costs.

4)

Reusability. Separating the application into multiple layers makes it easier to implement reusable components.

5)

Complexity. A key advantage of three tier architectures is that the development environment is less difficult to use than the visually oriented development of two tier applications.

212 | 4 ERP Systems: Basic Concepts and the Example SAP

4.7.8 Choose: Key Players of ERP Please choose three dominant players in the ERP Market: 1)

Hansa World

2)

Infor

3)

SAP

4)

Epicor

5)

MS Office

6)

Oracle

7)

AutoDesk

8)

Syspro

9)

Microsoft Dynamics

10) SolidWorks

4.7.9 Choose: Success of ERP Projects in the Last Years Please choose the percentage for the problems of ERP projects in 2012. 1)

[41, 53, 65] % of all ERP projects experienced a cost overrun; were over budget

2)

[21, 42, 61] % of all ERP projects experienced a duration overrun; took too long

3)

[60, 71, 82] % of all ERP projects received only half or less of the expected benefits and can, thus, be regarded as less successful than planned.

4.7.10 Close: Modules and Submodules in SAP Please place the SAP elements to their according spot in the hierarchy according to the SAP logic of naming modules and transactions. SAP

a)

MM

b)

PP-CRD

PP-PBD-RTG

CO

PP-PBD

c)

PP-PBD-BoM

e)

f)

d)

4.7 Review Questions for Chapter 4 | 213

1)

CS01

2)

PP

3)

PP-MRP

4)

CO-PK

5)

MM-EDI

6)

PP-PBD-CAP

4.7.11 Order: Hierarchy of Terms in SAP Please order the SAP-ERP Terms from top (broad) to down (detail). 1) Data Field 2)

Data View

3)

Modules

4)

Sub-Sub-Modules

5)

Sub-Modules

6)

ERP-Application

7)

Transaction

4.7.12 Close: Structures in Materials Management For each gap, please choose the correct word to complete the sentence: 1)

A [company code, plant, storage location, shipping point, purchasing organization, purchasing group, Central Purchasing Organization] is the facility where goods, like wind turbines, are manufactured or services delivered. And it is also the organizational level where Material Requirements Planning (MRP) runs are executed.

2)

A [company code, plant, storage location, shipping point, purchasing organization, purchasing group, Central Purchasing Organization] is a place where MRO and raw materials are collected after being purchased, semi-finished goods are between stages of production, or finished goods are before being sold. It is just a logical place that might exactly be a real location. However it is also possible that it comprises three warehouses within several kilometers’ distance.

3)

A [company code, plant, storage location, shipping point, purchasing organization, Central Purchasing Organization] enables a corporation to define a unit where contracts can be globally agreed. As compared to a normal purchasing organization, it is not confined to a single company code, but stretches across the whole client.

214 | 4 ERP Systems: Basic Concepts and the Example SAP

4)

Revestacon in the US, in Canada and in Germany will be run as separate legal entities or subsidiaries. A [company code, plant, storage location, shipping point, purchasing organization, purchasing group, Central Purchasing Organization] is one legal entity that reports its financials as a P&L and a balance sheet. So, every expenditure and revenue and every valuated material in stock has to go into the P&L and balance sheet of exactly one of them.

5)

A [company code, plant, storage location, shipping point, purchasing group, Central Purchasing Organization] is highest level organizational unit of Transports and controls transport activities. Material can enter or leave the premises of an organization through it. Each outbound delivery is processed by only one of them. It can be assigned to more than one plant and a plant can also have more than one of them.

6)

A [company code, plant, storage location, shipping point, purchasing organization, Central Purchasing Organization] is responsible for the procurement of materials and services in a legal sense. So, it might serve different plants in a single company code. The company is free to reflect its specific real-life organization of purchasing, for example purchase by plant, by country or by group of materials. This unit can avail the conditions and centrally agreed contracts contained in the assigned reference purchasing organization.

4.7.13 Close: Structures in Accounting For each gap, please choose the correct word to complete the sentence. Each paragraph only talks about one accounting object and every term is only used once. 1)

SAP and other ERP systems are able to reflect a multinational, multi division cooperation in one single system. This system and upmost level is called a [client, credit control area, controlling area, chart of accounts, business area, company code, cost center]. A material master record, like a wind turbine, can be accessed from anywhere in this level’s database and its material number will be unique in the system.

2)

A [client, credit control area, controlling area, chart of accounts, business area, company code] is only able to report cost data, but not profitability. It is a logical unit defining the company's cost/managerial accounting operations. A company code is assigned to one and only one of those objects, while it can have multiple company codes assigned to it. This allows cross-company cost allocations and reporting.

3)

A [operating concern, credit control area, chart of accounts, business area, company code, cost center] is a logical unit created to control customer credit limits. Since most companies and most of its customers are operating multinational and multidivisional, a control of credits needs to be established on a high

4.7 Review Questions for Chapter 4 | 215

level. E.g. if one of our customers has too many outstanding accounts in Germany and did not pay the invoices we sent him, he will be barred from receiving any further shipments from us or even placing orders – even in China. 4)

A [client, operating concern, controlling area, chart of accounts, company code, cost center] lists and structures the bookkeeping and cost accounts. One must be assigned to every company code while several company codes can use the same. So the Revestacon cooperation might use the same of these objects for the companies located in Germany, Austria and Switzerland.

5)

A [client, credit control area, controlling area, chart of accounts, company code, cost center] is one legal entity that reports its financials as a P&L and a balance sheet. So, every expenditure and revenue and every valuated material in stock has to go into the P&L and balance sheet of exactly one of those basic units of financial accounting.

6)

A [client, credit control area, controlling area, chart of accounts, business area, company code, cost center] allows for reporting of commercial balance sheets and P&L’s across company codes, which will not be used for commercial and tax law. They are used for internal reporting purposes and segment reporting across company codes, as defined by the cooperation. This might be necessary because a multidivisional cooperation manufactures wind turbines (next to other things) in all subsidiaries and companies across the world.

7)

A [client, operating concern, credit control area, chart of accounts, business area, company code, cost center] is a logical unit to which indirect or overhead cost can be attributed. Often, it might be a real department and will be assigned to only one company code and to one division. It facilitates the distribution of overhead cost to single products, and also allows for planning and controlling overhead cost on the lowest level.

4.7.14 Close: Structures in Sales Please describe the relationship between these objects in sale. E.g., the relationship “company code – plant” is 1:N. That means one company code can own many plants but one plant belongs to exactly one company code. N:1 would be the other way round. N:N means there is no fixed hierarchy and relationship; several x can belong to several y. Choose the correct relationship. 1)

Sales Office – Client [N:N, 1:N, N:1]

2)

Distribution Channel – Sales Office [N:N, 1:N, N:1]

3)

Client – Sales Organization [N:N, 1:N, N:1]

4)

Distribution Channel – Company Code [N:N, 1:N, N:1]

5)

Company Code – Sales Organization [N:N, 1:N, N:1]

216 | 4 ERP Systems: Basic Concepts and the Example SAP

6)

Sales Organization – Sales Office [N:N, 1:N, N:1]

7)

Division – Company Code [N:N, 1:N, N:1]

8)

Sales Office  Division [N:N, 1:N, N:1]

4.7.15 True/False: Roles in an ERP System Please mark the four statements about roles in ERP-Systems that are TRUE. 1)

A role restricts access to enter an ERP-System at all

2)

A role restricts access to view and execute certain transactions

3)

A real person can only be assigned one and only role at a time

4)

In a training scenario, to view a company-wide process, students usually are granted several roles

5)

A role lets the user view typical transactions usually needed for her work

6)

Users can choose their roles freely after login.

7)

ERP-Systems usually offer some predefined roles that can be adjusted later by the company

4.8 Suggestions for Written Exercise or Groupwork 4.8.1 ERP Case Study For this chapter, it is advisable to get a short introduction and do a case study in a real ERP System, like SAP, Dynamics AX or Oracle. Ask your instructor at class or the HR department how you can obtain access to a training system.

4.8.2 Differences Between SAP and Competitors Research advertising material of SAP and its competitors, like an Oracle Brand or Microsoft Dynamics AX. Also search some neutral studies. Deliver a high-level comparison of the two systems in a structured way.

5 IT-Management This chapter shifts the focus from using IS to managing IS. In order to do so, two other related, but different areas will be described quickly: IS governance and IS compliance. A company also should have an IS strategy that is derived and aligned with business strategy. So, the tools, elements and process of building a business strategy will be explained. The vast area of IS management will be exemplified by the well-established framework ITIL. Since ITIL is considered to be the most practical and hands-on, it is described in greater detail. It also seems sufficient to focus on a hotspot of operative IS management, namely “change management”, to illustrate one ITIL process in detail. COBIT and IT-Controlling, two other frameworks/approaches to managing IS, are given a short introduction. At the end of this chapter, you should be able to …  … describe the scope and reason of IS management.  … distinguish among IS management, compliance and governance with practical examples.  … explain the influences of corporate strategy on IS strategy with examples.  … describe the basic idea and focus of the ITIL framework.  … know the structure of ITIL framework and the typical microstructure of an ITIL chapter/process.  … give examples, from your company, of ITIL processes, especially in service transition.  … create a simple Change Management process, with all necessary components.  … describe the use of cost accounting information for controlling IS.

5.1 The Big Figure: IT Service Management (ITSM) In the previous lectures, we looked at software from a user’s point of view, with only a basic sense of managerial duties. In these chapters, it was taken for granted that IS was always operational, and that somehow the right software was chosen and implemented and that the “IT department” kept the whole thing running. For the remaining chapters, we radically change our focus towards managing IS: how do applications come into being, into the company, and how are they kept up and running and improved? As a master student and engineer aspiring to managerial competencies, such a focus benefits you in two ways:

218 | 5 IT-Management –

–

You will gain a management view outside your experience as a user of CAD and ERP systems to get a better understanding of how the key success factor IS is managed (planned, organized, controlled, staffed etc.). You get to know what a professional involvement of an internal customer of IS (e. g. mechanical engineers) should look like, and what can be expected from a professional IT to serve business.

This chapter will keep a macroscopic view and aims to show the big figure: what are the overall tasks of IT service management (ITSM) and what frameworks and supportive tools are available for professional ITSM? ITSM is one of the most intensely discussed topics of the new century in information systems. How did IS get into the focus of management and optimization? During the “new economy bubble” at the turn of the millennium, IS seemed to dominate everything. Companies were told by strategy consultants to build their businesses around IS. Sales, marketing and production were to follow where IS would lead them. After the new economy bubble burst in 2002, management viewed IS in a new light: it was an important administrative function that ate up a lot of revenue budget and seemed to be not at all transparent. So why not subdue IS and the IS department under the same optimizations and management principles as production and other areas have been before? IS was to serve the “real” business and internal and external customers with tightly defined processes and roles, and its success was to be measured. This was the time when the frameworks to manage IT described in this chapter gained wider acceptance. A big challenge will be to sort out the different approaches, catchwords and frameworks in ITSM that are available to us today. Do not be confused if different concepts seem to cover similar areas, but do not fit exactly. The different approaches stress certain aspects more strongly and others more weakly, and even some terms are even used differently: “It is not a bug, it is a feature”. Different opinions and need for structuring reality have led to different frameworks. Specifically, three of them have gained wider acceptance:  The ITIL framework and its according publications are focused on ITSM, IT improvement, best practices and, via good IT management, also compliance  COBIT is a standard for good control over IT and IT compliance. ITSM might be improved via COBIT as well, but it was introduced by auditors to check IS compliance.  IT-Controlling is less of a coherent framework, but focused on four important management tools: budgeting, measuring, controlling and reporting.

5.1 The Big Figure: IT Service Management (ITSM) | 219

These frameworks might look abstract and all too detailed at first sight, and always need to be transformed into fitting processes for a company step by step. So what is the use of a framework like ITIL in the first place?  It is a big “checklist” of what to consider to implement good IT Management  It suggests examples, tools and best practices from other companies by which to be inspired  It serves as a common understanding/language. If you talk to IT professionals about a “change request” or “request for change” (RFC), most of them will have a precise idea of what you are talking about, even if the details might vary from company to company  As with many concepts and ideas: Talking and thinking about it creates ideas and moves the IT organization towards action. Before talking about frameworks for ITSM, let’s sort out some other terms and put ITSM in a broader context. The following figure visualizes, on a high level, the order of terms. IS Governance Business

IS

Strategy

Strategy

COBIT

IS Projects Organisation and Processes of Business

IS Controlling Running IS ITIL IS Compliance

Fig. 5.1: A Map of ITSM and Related Frameworks

IS exist to support and enable business. In order to do so, three objects have to be managed in IS: First of all, IS strategy needs to align with business strategy. For example, it has to decide whether the use of open source software might or might not serve the strategic needs of the business. Changes in the IS landscape of a company are real-

220 | 5 IT-Management

ized via IS projects, in which new IS are introduced or optimized, e. g. a project to customize and introduce an ERP system like SAP. Keeping every day IS running; for example, how problems and functions using the software are recorded and solved. IS management (ITSM) is simply the way in which these areas are planned, controlled and organized. IS Governance is the way ITSM in itself is ruled and basically organized. It answers questions like: is ITSM centralized or decentralized? Who has the right to decide what? For example, who appoints chiefs of local IS: local business management or central IS management? IS compliance ensures that IS are compliant themselves and will support businesses to be compliant. For example, an ERP system should have mechanisms to prevent fraud by demanding mutual checks and balances before real money is transferred. There are lists of actual tasks that have to be carried out to do IS management, governance and compliance. However, a loose selection of tasks, forms and job description for these would be inconsistent and unpractical. That’s why frameworks have been developed; they help management in realizing good IS governance, compliance and service management. COBIT stems from auditors and is focused on control and evaluation of IS activities. Of course, a good grip on IS processes will not only ensure compliance, but also help management – compliant or not. ITIL is focused on showing examples and best practices of how to keep IS running and improve it. IS Controlling is derived from management control applied to IS, and therefore, uses KPIs and cost accounting information intensively. What seems to be confusing in separating those objects and concepts is the fact that they cannot be clear-cut, and the frameworks cannot be attributed perfectly to these areas: COBIT will help compliance, but also management, and ITIL will do the same. However, COBIT is more focused on control while ITIL wants to show recipes and examples for good IS management. Before digging deeper into the established IS frameworks, the two other areas besides ITSM need to be explained briefly: IS governance and compliance. These terms are sometimes confused since they have mutual relationships: of course, good ITSM might be expected for good IT governance and may also lead to better IT compliance. However, the focus and ultimate goal is still very different.

5.1.1 IT Governance “Governance” describes the ways stakeholders of an enterprise organize themselves to get their different interests in the enterprise organized and harmonized? This includes mechanisms to choose and replace management and systems of planning and controlling on a high level. So, questions of governance reside logically above questions of management: e. g. “Who determines the Chief Officers or top manage-

5.1 The Big Figure: IT Service Management (ITSM) | 221

ment in the first place?” is a question of governance, independent of how these managers later might manage the company. Please refer to the extensive literature (also on the web) about the term “corporate governance” to 5 deepen your knowledge about the term “governance”.

At all times, every organization has had some form of “governance”. However, this topic has been discussed more intensely and scientifically during the last 15 years. The reasons for these discussions lie in explicit stricter laws concerning the control of management and company boards and strengthening internal controls to be (more) compliant. Since IT has such a strong influence on almost every process in the company, the idea was to apply concepts of governance not only to companies as a whole, but also to IS as a subsystem of the company. One definition might be (taken from Gartner 2002, p. 24–26): IT governance is “the assignment of decision rights and the accountability framework to encourage 1 desirable behavior in the use of IT” (Weill, 2001; Broadbent & Weill, 1998). This abstract task translates into three components: 1. What decisions are needed to be made: Decisions about major IT domains? 2. Who has the decision and input rights: Rights are exercised in different governance styles? 3. How are the decisions formed and enacted: Multiple mechanisms make governance work?

The table below details IT decision domains: for which areas do decision rights need to be defined? Table 5.1: Five Major IT Decision Domains (Based on Weil/Woodham (2002) p. 5f.) IT principles

High level statements about how IT is used in the business

IT infrastructure strategies

Strategies for the business foundation of budget – for IT capability (both technical and human) shared throughout the firm as reliable services, and centrally coordinated (e. g. network, help desk, shared data) An integrated set of technical choices to guide the organization in satisfying business needs. The architecture is a set of policies and rules that govern the use of IT and plot a migration path to the way business will be done (includes data, technology, and applications)

IT architecture

Business application needs

Business applications to be acquired or built

IT investment and prioritization

Decisions about how much and where to invest in IT, including project approvals and justification techniques

222 | 5 IT-Management

For further discussion, consult sources about “IS governance” that are used and cited in this chapter. Here, we will focus more strongly on the tasks ITSM will have to carry out once chosen and empowered by the IS governance of the enterprise. However, it is important to keep in mind that, ultimately, the way IS management might exercise power is just derived from a deliberate or implicit IS governance.

5.1.2 IT Compliance Questions of compliance have a narrower focus than governance: compliance is to ensure and check whether a company and its members act within laws and regulations imposed from the outside. It is to prevent illegal action and minimize the risks of making illegal action possible. The ultimate goal is to avoid damage to the stakeholders, which include the public and the government. Sometimes IT governance is confused with IT compliance. The relationship between the two terms might be stated as follows: good IT governance supports IT compliance, and without proper IT governance, tight IT compliance seems hard to reach. However, even an organization with refined IT governance might act against the law, like a drug smuggling enterprise that has a very well organized and governed IS. The scientific and managerial discussion about compliance really took off with the Sarbanes Oxley act (SOX) in the US. In Germany, the law most closely related to SOX is the KonTraG, and other countries have similar laws you might want to research, if desired. To put it very briefly: these laws increased the fines for companies considerably in case they would not systematically install controls that would prevent unlawful and criminal acts of their members. SOX can be described by the following key points (Motiwalla/Thompson 2009, p. 307–309):  SOX, sponsored by U. S. Senator Paul Sarbanes and U.S. Representative Michael Oxley, represents the biggest change to federal securities laws in a long time.  It came as a result of the large corporate financial scandals involving Enron, WorldCom, Global Crossing and Arthur Andersen.  The act discusses the necessity for clear responsibility in IT systems, as well as for maintaining an adequate internal control structure and procedures for financial reporting.  Audits are applied to a company’s ERP system to test privacy and security levels.  Major areas of privacy include access to the system, user ID and verification, evaluating configurations relating to business processes, change management, and interfaces.  Users should have IDs, passwords, and access controls.  Users should not be able to change financial, personnel or vendor information.

5.1 The Big Figure: IT Service Management (ITSM) | 223

These requirements are also controlled during annual financial audits. Most auditors …  … get a list of users and what permission they have in the system.  … check to see what process is used for user IDs and passwords.  … check how often passwords are changed.  … check how complex the user IDs are.  … check how easily changes or modifications can be made. IS are involved in almost all company processes and must therefore be subject to compliance considerations. To name a few, laws that might be violated through IS or badly managed IS are those concerning bookkeeping, data security, confidentiality of customer and employee data, and many more. Risk management plays a key role: a company cannot be made responsible for everything that might happen to it; however, they must assess possible risks that might endanger compliance. This is especially visible in the KonTraG (The “German Version” of SOX), in which having risk management is a must. The following figure shows the relationship of the three core terms of governance, compliance and risk management. Governance

Business strategy/goals

Information technology Risk Management

Compliance

Fig. 5.2: Relationships between Governance, Risk Management and Compliance (Based on Kranawetter (2009), p. 24)

These new legislations all over the world have forced companies to rethink governance and risk management across all company functions. Management scientists and consultants have urged companies to use demands for compliance by government authorities to improve governance in general and to professionalize ITSM. The following figure shows how business requirements and regulatory requirements (compliance) lead to the same overall management objectives.

224 | 5 IT-Management

Requirements

• •

• • •

Regulatory requirements

Protection of privacy in processing personal data Data access and auditability of digital documents by financial authorities Orderliness, security and auditability of IT supported accounting systems Corporate governance and risk management Minimum capital requirements, minimum risk management requirements, disclosure and market discipline

Objectives

Protection

Availability

Business requirements

• • • • • • • • •

Process efficiency and effectiveness Security of intellectual property and customer data Fraud Protection Incident/emergency management Transparency to external stakeholders Image and reputation Sustainability and social responsibility Legal compliance Prevention of liability

Traceability

Transparency

Due diligence

Fig. 5.3: Synergies Between Business and Regulatory Targets (Based on Kranawetter (2009), p. 28)

This shows that both goals (business and regulatory) might lead to similar management requirements. However, there might be also examples of conflict between regulatory and business goals; this would be a conflict of stakeholder interests. If management is incentivized to act like shareholders (e. g. by being paid in stock options) they will prioritize business (shareholder) goals.

5.2 IT Strategy and Business Alignment The connection between corporate strategy (the real business and its organization) and IS is mutual. They influence each other: business needs to be supported by IS, but new IS solutions also bring new opportunities to companies, might change the rules of an industry considerably, or might even influence the broader environment, so the company must react to this. In this module, we decided on the premise that IS and IS strategy need to follow the business. Consequently, in this chapter, we will closely follow this top down approach, even if IS might have a serious influence on company or functional strategy (like production strategy). In any case, the connection and transmission between business and IS in a strategic level should manifest itself in an IS strategy.

5.2 IT Strategy and Business Alignment | 225

As you know from other classes or books, management can be applied on a strategic (> 5 years), tactical (1–5 years) and operative level (< 1 year). Not only the time horizon, but also the scope is different in these three stages. Typically, the strategy of a single function like HR, marketing or production is a tactical issue from an overall company perspective and should be compliant with overall business strategy; this will be explained in the following chapters. There is another link between a function strategy (here: IS strategy) and overall business strategy: the tools used in the process of strategic management, like portfolios, SWOT analyses, and so on also may be utilized in crafting an IS strategy. There is a strong force the other way around: of course, new IS technology enables new forms of organizations and processes and may enable a company to change its basic strategies or even redefine the rules of the business. However, this role of IS as a strategic enabler will not be further explored in this chapter. Here, the serving role of IS for business will be dominant.

5.2.1 Basic Business Strategies and Tools – Used for IS strategy As stated in chapter 5.2, the relationship between business strategy and IT strategy is twofold: they should be aligned and they use similar tools. Therefore, we will very briefly review basic concepts and tools of business strategy. Before any kind of strategic conclusion is made or action is planned, there should be thorough analyses of the situation. The following tools and elements are used for the analysis stage in strategic management: 1. The PESTEL (sometimes also: PESTLE) analysis evaluates the broader external legal, economical and technical context a company is operating in. 2. Porter’s five forces model structures information about the closer external industry context of customers, competitors and suppliers (See again chapter 1.1.4). 3. The internal analysis evaluates resources and competencies and compares it to the closest competitor (or market leader). It is also called strength weakness analysis. 4. Analyses 1 and 2 deliver the “threats and opportunities” from the outside, while analysis 3 shows strength and weaknesses of the company itself. The results might be simply put together in a SWOT analysis. However, a SWOT analysis might create more value if some external and internal factors are matched and strategic initiatives are suggested, e. g. to use a strength to take advantage of a certain opportunity. This part of the SWOT analysis sometimes is called “TOWS” analysis.

226 | 5 IT-Management

These standard tools of strategic management will not be explained in detail in this module, but can easily be researched in literature or the web. They are also used in crafting an IS strategy, as can be seen in chapter 5.2.3. Generic Strategy: In every strategic business unit (SBU), two important independent decisions have to be made to set the basic strategy of this SBU:  Does the company want to serve the whole industry/a broad market or rather focus on a niche?  And secondly, does the company want to be very different and unique to its customers or rather act as mass producer with an extremely efficient production system that can operate at unbeatable cost? Some studies have found that companies deciding these questions very clearly have above average RoI’s, while those in an unclear position have below average returns on capital. Michael S. Porter deducted from these empirical insights, that every company must decide on these questions to seek a clear position. The resulting strategies in the next figure are called “generic” because every SBU in every industry has to decide on that regardless of how their individual characteristics might look. Advantage Target Scope

Low Cost

Product Uniqueness

Broad (Industry Wide)

Cost Leadership Strategy

Differentiation Strategy

Narrow (Market Segment)

Focus Strategy (low cost)

Focus Strategy (differentiation)

Fig. 5.4: Porter’s Generic Strategies

3 Please be aware that these “classical” generic strategies are amended by recent studies and theories in strategic research. In the first place, the strategy of outpacing coordinates a sequence of gaining cost advantages and differentiation advantages taking turns. Secondly, globalization has extended the niche theory by the model of the “Hidden Champion”: small niche players that dominate their niche globally.

Wherever a company chooses to position itself in the matrix above, it will certainly have influence on its IS strategy as well, as will be explained in chapter 5.2.2.

5.2 IT Strategy and Business Alignment | 227

These strategic tools (and others) will be used in actually formulating an IS strategy, described in chapter 5.2.3. The use of portfolios, especially in ITSM, will be explored in chapter 5.4.2.3.

5.2.2 The Relationship Between Business and IT One relationship between IS and business in strategy is the influence IS has on the broader context or the industry. Looking at the concept of Porters “five forces” (see chapter 1.1.4), there are several things an IS can do to improve competitive advantage (Piccoli/Feeny/Ives (2003), p. 5):  Improvement and automation of business processes may lead to cost and quality advantages, e. g. in computer aided manufacturing  New IS enable new business opportunities and products, e. g. remote optimization and maintenance of machinery  A tight IT connection reaching out to markets (suppliers and customers) might strengthen the ties between them and the company  Investment in IS and IS standards raise the market entry barriers for new competitors  On the level of strategic management, better and faster information might improve strategic decisions (see chapter 1, chapter 2) Zooming into a single SBU, the question presents itself: how can IS support the strategic choices there that lead to the strategies of niche focus, cost leadership, differentiation, etc. Imagine a manufacturer of standard steel pipes for the mass market in need of extreme high efficiency (cost leader) and a highly specialized manufacturer for special rolling bearings for the offshore wind industry in limited amounts (differentiation strategy). Now go through its value chain (see chapter 1.2.2 again) step by step and imagine how the different strategies influence their organization and processes. Then, imagine how the information systems must differ to support the strategy in all the parts of the value chain.

228 | 5 IT-Management

IT/IS: Potential to change the Industry, the business model and the organization

Business Strategy • Requirements resulting from the business strategy • Demand oriented • Application oriented

Where is the business going and why?

Orientation of the business

Support of the business

IS Strategy • Requirements resulting from the business strategy • Demand oriented • Application oriented IT Infrastructure and services

Demands and priorities IT Strategy

• Activity oriented • Supply oriented • Technology oriented

What is required?

Fig. 5.5: The Relationships of Business Strategy, IS Strategy and IT Strategy (Based on Laudon/Schoder (2012), p. 830)

 Following the business strategy of “cost leadership” will result in several requirements for the overall IS strategy. In the figure above, we assume this might be a standardization strategy.  The IS strategy of standardization then requires certain IT strategy actions, like choosing global partners to supply IS and initiatives to standardize formerly heterogeneous systems via enforcing ERP rollouts.  If the IT strategy can comply with the requirements, it will deliver IT infrastructure and IT services that are standardized and efficient.  The standardized services will enable the business to provide cost efficient, reliable, standard services to customers and thus help realize the “cost leader” business strategy.  Technical innovation in IS might sometimes change the environment and rules of the industry in a fundamental way. In this case, top management needs to react and formulate a new business strategy, taking into account the change in the technological environment.

5.2 IT Strategy and Business Alignment | 229

The relationship sketched does not yet answer a practical question: how will an IS strategy be derived? The following chapter will answer this question following a different author. Please note that the IS strategy in the figure above corresponds with IS strategy in the following chapter, while “IT Strategy” corresponds with steps 4 and 5 of the process drawn in the next chapter.

5.2.3 The Process and Results of an IS Strategy After knowing the mutual relationship between corporate and IS strategy, we need to focus on the process (how to derive an IS strategy) and the result (content of the IS strategy document). As always, in the realm of strategic management, there is no strict rule of what to decide in an IS strategy. However, most authors and CIOs (Chief Information Officers = Head of IT and Information Systems) agree that, next to overall basic strategies, the following questions need to be answered in an IS strategy:  In what areas and how far do we want to standardize “Information Systems” and their hardware? How do we cope with the trend of “consumeration”? (Please research the term “consumeration” yourself).  Which parts and how “far” do we want to outsource IS and according services (for a detailed discussion of the “Outsourcing Question”, see chapter 8).  How do we organize and govern multinational and global structures of a multinational or global player?  What projects will be prioritized in the IS project portfolio? The following figure shows that an IS strategy has to consider the company strategy in any case and should be derived from it. The development of an IS strategy and the derived IS architectures are understood as a gradual and iterative process. Every cycle can increase the maturity level of the strategy paper (as a documentation of the strategy) and, where possible, additional areas can be covered. The following steps were proven useful in the development of an IS strategy (see Tiemeyer 2007, p. 42ff.):

1

230 | 5 IT-Management

Corporate goals

Competition Laws

Corporate strategy

Business processes

Resources

Environment analysis

Situation analysis

SWOT-Analysis

IS-principles & IS-strategies • IS Visions and IS Missions • Quality targets • Technical standards • System strategies • Organization strategies • Resource strategies

Plan and manage IS-architectures: • IS Infrastructure • IS Application • IS Processes • IS Organizations

Activity planning: • Project portfolio • Migration plan

Fig. 5.6: The Process of Deriving an IS Strategy (Based on Tiemeyer (2007), p. 42ff)

Step 1: Analysis of company strategy and determination of critical success factors of the business: The first step always has to be an analysis of the company strategy and the consequential effects on IS strategy. This includes competitor and environment analysis. The business processes (supported later by IS) should be derived from corporate strategy. If a company, for example, wants to differentiate itself from competitors, it might find it useful to improve business and set up a new service process, which might again later be supported by a new IS. Company strategy should be documented and known before crafting an IS strategy. Step 2: Perform IS analyses and IS diagnoses: Step two mirrors exactly what management should do for a company strategy – however, this time, focused on information systems. Environmental, company and competition analysis might be documented in an Information Systems – SWOT analysis. For example: a new law about IS compliance is adopted and we know a competitor is already very strong in organizing compliant IS structures. This might lead to setting a new goal of achieving excellence in IS compliance – maybe at the expense of other strategic IS goals.

5.2 IT Strategy and Business Alignment | 231

Step 3: Updating IS principles and formulating sub strategies Crucial for the implementation of an IS strategy is a clear statement about the strategic goals of the IS. This is the starting point and the basis for the development of a concept, e. g. the derivation of IS principles and sub strategies. Based on the strategic challenges and the strategic IS goals, the responsible IS staff (if necessary, supported by a neutral consultant) should develop and adjust the sub goals of the company in a workshop. For example, the quality targets are lowered to a level in which the cost to achieve these quality level fits with corporate strategy to become a global cost leader. Step 4: Defining and describing IS architectures (IS development plan) The strategic requirements and derived sub-strategies are the basis for the conceptual architecture to serve corporate processes. It is a matter of technology architecture (hardware), applications architecture (software) and information architecture (data order). For example, the IS organization is decentralized to fit the IS strategy of highly individualized services per country, which again, was derived from the corporate strategy of decentralization. Step 5: Setting up proposal planning (project portfolio and migration plan) If the desired state is already achieved, there is no need for action – however, this is hardly ever the case. The likely gap between the target concept and the actual situation starts the planning for action. The projects need to be validated for fundamental feasibility and transferred in a mid-term plan with a planning horizon of three to five years. Also, the developed architecture plans will be compared to the actual situation and a migration plan created, if necessary. For example, the IS strategy of standardization calls for a global rollout of the ERP system, like SAP projects. Steps 4 and 5 can be illustrated by the following example: in recent years, many large companies had acquired other companies, driven by a corporate strategy of growth, expansion and diversification. Now they needed to integrate and standardize the IS of the acquired companies (IS strategy) and this led to strategic projects, as described in the following table:

232 | 5 IT-Management

Table 5.2: Targets of IT Strategy and Current Projects (Based on Gaddatsch (2012), p. 35)

Company

Targets of the IT strategy

Important current projects

BMW

Speed, Flexibility, depth of product range

Material supply just in time and just in sequence, standardization of production related systems

Bayer

Demand oriented services with prices in line with the market, standardization, further development of technologies

Support the foundation of the subsidiary Lanxess, Projects to reduce complexity

Daimler

Realization of global processes, support of brand crossing activities, technological leadership

Digital factory, expansion in China, consolidation of the infrastructure

Deutsche Bank

Align IT to business processes, global homogenization of systems, variable costs by outsourcing of non-core competencies

Harmonization of architectures and platforms

Eon

Reusability, infrastructure consolidation, purchasing synergies at hard and software

Group application strategy, group Infrastructure strategy, shared service concept

Volkswagen

Value creation, process integration across regional company and brand limits

Consolidation of IT infrastructure, product data management, production planning and control system, original parts system, virtual vehicle/digital factory

The described steps and their results will be defined in an IS strategy paper that might have the following structure (Tiemeyer 2007, p. 43): 1. Management summary 2.

Goals and framework conditions

3.

Positioning of IS in the company (Value adding etc.)

4.

Environment analysis 4.1. Internal aspects (business model) 4.2. External aspects (competitive analyses) 4.3. Technology aspects

5.

Actual analysis and IS diagnosis 5.1. Methodical approach and results 5.1.1. Situation analysis 5.1.2. SWOT analysis

5.2 IT Strategy and Business Alignment | 233

5.2. IS diagnosis and evaluation 5.2.1. Professional evaluation 5.2.2. Technical evaluation 5.2.3. Organizational evaluation (IS organization) 6.

Fundamentals and standards for the IS (IS principles)

7.

Description of sub strategies target concept and decisions 7.1. Permitted basic systems of IS 7.2. Organizational positioning of IS (E Governance) 7.3. Methods and approach in requirements management 7.4. IS service strategy 7.5. IS personnel strategy 7.6. IS sourcing concept 7.7. Methodology and approaching models for IS projects 7.8. Concept for the IS quality management and quality assurance 7.9. Guidelines for IS security and IS risk policy

8.

Recommendations for IS architectures (IS architecture concept) 8.1. Technology architecture 8.2. Applications architecture 8.3. Personal architecture (professional concepts) 8.4. Organization (processes, structures etc.) 8.5. Security architecture

9.

Proposal planning 9.1. Project portfolio 9.2. Economic evaluation 9.3. Project budgeting

An IS strategy is an important prerequisite for consistent operational planning of IT; however few companies seem to be successful in creating and executing it. The following problems are frequently reported in creating an IS strategy (Tiemeyer 2007, p. 50):  There is no systematical approach applied: IS strategy is special and cannot directly be subjected to the classic strategy and target formulation process.  IS products dominate the strategy, and not vice versa: too often existing standards are taken as givens (“We only use MS Office”; “We have the following Linux components”). Strategy must be thought in a more radical and greenfield based way: What do we have to do to support our company strategy in an optimal way by IS?

234 | 5 IT-Management  The company strategy is unknown: Often the company strategy is simply not known by IS management, if it is documented at all. But without this knowledge, development of an IS strategy is not possible.  No common understanding about the role of IS: The corporate management, the specialist departments and the IS department itself value the complexity and importance of IS differently and often work with very different assumptions.  IS strategies are often initialized only once as a project, because the top management ordered it to be done, perhaps because some IS governance evaluation (see chapter 5.1.1) asks for an “IS strategy”. Strategy development should be understood as a permanent process, which is associated with a certain effort and which has to be planned and organized in the company. Not every company will have an explicit IS strategy. Small companies, especially, will find it too “theoretical” and bureaucratic to formulate an IS strategy. However, having a sound IS strategy helps to prevent the same arguments popping up every time an operative decision touches a strategic issue. Frameworks of ITSM, like ITIL, take into account the important task of formulating an IS strategy (see chapter 5.3.1.4.1)  only the words or the tasks differ a little bit.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) There are many frameworks that aim to help companies in managing their IT better. In some respect and areas, they look similar, while in other respects, they do differ considerably. In this chapter, we will focus on the ITIL framework that is chosen by many organizations to guide them fully or partly in ITSM. Two other approaches will be looked at in chapter 0.

5.3.1 The Macro View and Logic of the ITIL Framework ITIL is indeed a kind of library: it is a framework and collection of best or good practices for IT Service Management. It originated from the IT department of the National Health Service of the UK. Problems between IT and other functions showed the need to improve this relationship by introducing clear rules and procedures between IT and other departments and defining the various processes of IT service management. ITIL is clearly focused on a running IT infrastructure serving the business, rather than projects of introducing IS. We will have a closer look into introducing systems in chapter 6. To stress this fact, we use the term ITSM (Information Technology Service Management) rather than simply IS Management. Furthermore: ITIL

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 235

is not a prescriptive theory that tells companies what to do, but it supports ITSM in the following ways:  It gives a framework and a checklist of what has to be considered and organized in professional ITSM. This checklist aims to ensure nothing will be forgotten. Further into this chapter, you will see that there are quite a lot of these processes you might not have thought of naturally.  Within each item (e. g. change management) of the checklist, it further tells you what to consider there, like processes, responsibilities and possible forms of organization, metrics for evaluation and recommendations for do’s and don’ts.  For all the aspects listed in the points above, examples and best/or good practices are offered.  And, finally (like every other framework), it gives professionals and staff a common language everybody can refer to. In an ITIL conscious company, everybody immediately knows what “change management” stands for. Before we explore single components, let’s have a look at why ITIL has been quite successful at being accepted and used by companies for their ITSM. Basically, there are two ingredients that make the ITIL approach so attractive to business management and staff outside IT: Service Orientation and focus on processes. These will be explained in the following chapters.

5.3.1.1 Service Orientation ITIL sees IS clearly as a servant to the business and to the real value creation of a company. The only reason for the existence of IS is to serve the customer within and outside the company. All modern approaches of ITSM claim to serve the internal (and external) customer, but in the ITIL framework, this is stressed explicitly and frequently. Please note: In this chapter the word “customer” always means an internal department (like me- 3 chanical design) or process (like procurement) that is served by ITSM, e. g. via organizing updates for the CAD system. That is why ITIL easily can be adapted by pure IT companies, like an internet service provider, since, for good service, it should not matter whether the customer is inside or outside the company.

A supplier customer relationship between real business and the IT (department) should be established at all levels of the company. The following figure shows on the left side the customers in the company and on the right side the IT functions that must negotiate and organize their service offerings with their customers.

236 | 5 IT-Management Customer Organization

IT Organization IT Customer Relationship Management

Strategic

Tactical Operational

Business Manager

Strategic Alignment

IT Management

Budget holders

Service Levels

Service Level Management

Policy Reporting

Change Requests Department Managers Project Managers Users

Demand

Support

Change Management Incident Management Service Desk Production

Supply

Fig. 5.7: Customer Supplier Relationship on Every Level Between Business and IT (Based on itSMF (2007), p. 26)

Here are some examples for these levels:  Support: Service Desk gives support to an engineer who reports failure of his CAD system to export BOMs.  Change request: A team leader in mechanical design would like to have a new interface programmed to export BOMs from CAD to SAP more easily.  Service levels: The head of mechanical design (who must plan his budget) negotiates with service level management as to what kind of support (24/7? Or just at regular working hours) he would like to have and what part of his department budget he is willing to spend.  Strategic alignment: Business management and IT management consider tightening restrictions for using open source software in the company. They need to do this because the business has changed, since the company gets more orders from defense companies – and the new customers are critical of open source. The term “service” is central to the whole ITIL structure and philosophy. It is not just the basic attitude of service orientation towards the business, but also the name of the actual things that IT wants to do for the real business. We will use the following definition by Rance (2011, p. 15.) for service and IT service: “Service: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. IT service: A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes. An IT service directly supports the business processes of one or more customers and its service level targets should be defined in a

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 237

service level agreement.Other IT services, called supporting services, are not directly used by the business but are required by the service provider to deliver customer-facing services.” Rance (2011, p. 15.)

5.3.1.2 Focus on Processes The second ingredient next to the tight focus on serving the business is the dominance of processes by ITIL. ITIL is focused on processes, not departments. In the previous figure, the right side is shown as functions or processes, not as persons or department. This is the second important premise of ITIL: what’s important is what processes need to be done, not (yet) who is doing them. That is a modern functionalist approach that corresponds with processes dominating over resources. The following figure shows the central role of processes:

Process owner

Process goal Quality Parameters and Key Performance Indicators

Process Control

Input and Input Specifications

Output and Output Specifications

Activities and Subprocesses Process

Resources

Roles

Process Enablers

Fig. 5.8: Processes in the Center of Management Attention (Based on itSMF (2007), p. 30)

The process is in the center of all considerations. It is enabled by process enablers – resources that take certain roles to support the process and process control: the process needs to be measured and evaluated at all times.

238 | 5 IT-Management

You might want to reconsider the chapter about processes in chapter 1. Processes are at the very foundation of every application. Here, the tasks to keep the IT running and improving are also strictly viewed as a process; it is not about the things a department does. Here, all elements of an IT-department are redefined into processes. “Problem solved: The adapter used an outdated Java Engine”

IT Management

Out Software Department

Project organization

Operations

Service Desk In

Software Maintenance and Application Management

Office Automation and Telecommunication

Network Management

,,The export of my BoM did not arrive in the ERP System“

Fig. 5.9: Processes Do Not Care About Departments (Based on itSMF (2007), p. 31)

5.3.1.3 Benefits and Challenges Using ITIL Processes So, ITIL sounds like it has the right “attitude” to serve as a framework for modern ITSM. The following points summarize benefits and challenges to the company and the customer using ITIL processes: Benefits of ITIL to the customer/user:  The provision of IT services becomes more customer-focused and agreements about service quality improve the relationship.  The services are described better, in customer language, and in more appropriate detail.  The quality, availability, reliability and cost of the services are managed better  Communication with the IT organization is improved by agreeing on the points of contact. Benefits of ITIL to the IT organization:  The IT organization develops a clearer structure, becomes more efficient and more focused on the corporate objectives.  The IT organization is more in control of the infrastructure and services it has responsibility for, and changes become easier to manage.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 239

 



An effective process structure provides a framework for the effective outsourcing of elements of the IT services. Following the ITIL best practices encourages a cultural change towards providing service, and supports the introduction of quality management systems based on the 150 9000 series or on BS15000. ITIL provides a coherent frame of reference for internal communication and communication with suppliers, and for the standardization and identification of procedures. van Bon (2009), p.14

Of course, nothing comes for free and so the implementation and use of the ITIL framework and its components might also bear some risks or unwanted side effects (van Bon 2009, p. 14.):  The introduction can take a long time and require significant effort, and may require a change of culture in the IT organization. An overambitious introduction can lead to frustration because the objectives are never met.  If process structures become an objective in themselves, the service quality may be adversely affected. In this scenario, unnecessary or over engineered procedures are seen as bureaucratic obstacles that are to be avoided where possible.  There is no improvement in IT services due to a fundamental lack of understanding about what the relevant processes should provide, what the appropriate performance indicators are, and how processes can be controlled.  Improvement in the provision of services and cost reductions are insufficiently visible, because no baseline data was available for comparison and/or the wrong targets were identified.  A successful implementation requires the involvement and commitment of personnel at all levels in the organization. Leaving the development of the process structures to a specialist department may isolate that department in the organization and it may set a direction that is not accepted by other departments.  If there is insufficient investment in appropriate training and support tools, improved processes will not be carried out as designed, and ultimately, the service will not be improved. Additional resources and personnel may be needed in the short term if the organization is already overloaded by routine IT Service Management activities, which may not be using “best practices”.

5.3.1.4 Structure of the ITIL Framework After these basic discussions about the nature and evaluation of the ITIL framework, we need to look at its structure top to down. The areas of ITIL (“stages”) are service strategy, a dynamic service life cycle and, as the service life cycle repeats itself, a process of (hopefully) continuous improvement if the phases are well managed and lessons learned documented for improvement.

240 | 5 IT-Management

Continual Service Improvement

Service Transition

Service Strategy

Service Design

Service Operation

Fig. 5.10: Logic of the ITIL Framework 3.0 Stages (Based on van Bon (2009) p. 18)

The whole cycle is viewed from an IS organization that needs to offer its services to customers. These basic components are called “stages” in the ITIL language. This is a little bit misleading since it suggests that they are strictly following each other in a kind of IT Service “super process”. This is not the case. The so-called stages are merely a collection of single processes and try to illustrate the ever ongoing life cycle of service management. In the following figure, the eternal cycle is simply put in one logical order to show all the life cycle stages. In order to fulfill good practice in each of those stages, several processes (e. g. “Change Management” see chapter 5.3.3) are suggested.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 241

Continual Service Improvement

Service Strategy

Service Design

Service Transition

Service Operation

Financial Management

IT Service Continuity Management

Knowledge Management

Incident Management

The 7-Step Improvement Process

Service Portfolio Management

Availability Management

Change Management

Access Management

Service Reporting

Demand Management

Service Capacity Management

Asset and Configuration Management

Event Management

Measurement

Strategy generation

Service Level Management

Transition Planning Management

Request Fulfillment

Business Questions for CSI

Service Catalogue Management

Release and Deployment Management

Problem Management

ROI for CSI

Information Security management

Service Validation and Testing

Supplier management

Evaluation

Fig. 5.11: Processes in the ITIL Stages

Those single ITIL processes (not the stages) are the basic “unit” ITIL is all about. To distinguish between the general process, as it is used in the company, and an ITIL service process, the latter one will be called ITIL process. Each ITIL service process (a block in the figure above) contains the following chapters:  Basic Policies (principles and best practices)  Actual processes (purposes, scope, value to businesses, policies and advice, input, output and interfaces): e. g. How can “availability management” be designed?  Organization and roles: Who does what?  Tools and Technology used (like templates and databases used in ITSM)  Metrics for control, evaluation and optimization We will explore one important process (namely “change management”) in detail in chapter 5.3.3, and you will see how many details and how much content a single ITIL process will offer.

242 | 5 IT-Management

1 It is impossible to explore all 28 of them in this module in equal depth. In the literature used for this chapter, and on the web, you find information on each of these processes in full depth.

The whole range of service processes offered by ITIL seems impressive, and even a bit frightening. Some companies might find it convincing to have an improved “change management” process, but find it less necessary to model other service processes according to the suggestions and best practices of ITIL publications. Also, they might be afraid of introducing too much bureaucracy. The question they ask is: “Can we introduce just a few of these processes or even focus on just one? Will this work without the others?” The answer is a qualified yes: it is possible to start with a few ITIL processes and add more later. There is no need for a “big bang” introduction of a full range of all 28 ITIL processes. However, there is a limitation when introducing just a few processes in isolation: in the ITIL framework, processes rely on their neighboring processes. E.g. good Change Management relies on some form of Asset and Configuration Management (SACM). Changes cannot be managed in an orderly fashion without having the state of the systems properly documented at all times. So, if starting small, make sure the interfaces of your first process find at least a basic form of response at their ends. In our example, this would be a simple database about the current state of IT installations and software releases that does not fully live up to ITIL standards, but supports Change Management sufficiently. The following chapters will give a quick view of the other lifecycle stages of the ITIL framework and will examine “service transition” (where Change Management belongs to) more closely. 3 Please note that the life cycle stages are just a convenient cluster to which single processes are assigned. Maybe some of the people involved in the processes assigned to one stage work more closely and more often together, and the processes in one stage have more interfaces to each other than to other processes. However, it is just a logical grouping in the first place. The place for actual tools, organizations and tasks are the single ITIL processes.

5.3.1.4.1 ITIL Stage: Service Strategy In the stage of service strategy, the questions from chapter 5.2 are considered:  What is the situation of our IT department and our business?  What assets do we have?  What IT services can be offered that might be useful for the business of our company?

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 243

Also, a question of strategy is the basic organization of delivering the services; the service might be delivered by central IT, decentralized IT or external service providers. The strategic question of outsourcing and managing outsourcing relationships will be the subject of chapter 6.2.2. A basic concept or tool for strategy is the formalization of the status of services to the business in a so-called service portfolio. In the service portfolio, actually offered services are published in the “service catalogue”; retired services, which are not offered anymore (maybe because new technologies make the service completely unnecessary), are also listed. It also documents a service pipeline, in which new services are being developed, that might be offered to the business soon. As you know from your own business, it is not always clear what services are offered by the IS department and what services can be expected from them. Service strategy, and especially publishing the service catalogue, is exactly aiming at making available services transparent and steering the demands requested from IS. Finally, strategy also is in charge of finding a way for how the actual services can be constructed and evaluated and supplied with IT resources. The financial implications of offering certain services in a certain way are also located in the stage of service strategy.

5.3.1.4.2 ITIL Stage: Service Design Service design comprises processes necessary to define and design the IT services in a literal sense. Logically, what the business gets and how it does so must be agreed upon before actual service can be delivered. Rance (2011, p 7.) sums it up like this: “For services to provide true value to the business, they must be designed with the business objectives in mind. Design encompasses the whole IT organization, for it is the organization as a whole that delivers and supports the services. Service design is the stage in the lifecycle that turns a service strategy into a plan for delivering the business objectives. ITIL Service Design provides guidance for the design and development of services and service management practices. It covers design principles and methods for converting strategic objectives into portfolios of services and service assets. The scope of ITIL Service Design is not limited to new services. It includes the changes and improvements necessary to increase or maintain value to customers over the lifecycle of services, the continuity of services, achievement of service levels, and conformance to standards and regulations. It guides organizations on how to develop design capabilities for service management. Other topics in ITIL Service Design include design coordination, service catalogue management, service level management, availability management, capacity management, IT service continuity management, information security management and supplier management.”

For example: one ITIL process in the stage of service design is “Capacity Management”. Like every asset, IT capacity (storage, computing power, transfer speed, etc.)

244 | 5 IT-Management

navigates between two undesirable states: too little capacity might interrupt services, e. g. there is not enough bandwidth to work simultaneously with our supplier in a shared 3D CAD environment. Too much capacity guaranteed (not just technical but also organizational) is not cheap; an underutilization of capacity is a waste of resources. “Capacity Management therefore is responsible for ensuring that all IT services are backed by adequate processing and storage capacity. Without proper capacity management resources are not used optimally and unnecessary investments are made resulting in additional maintenance and administration cost. Or even worse, insufficient resources are available, leading to degradation in quality of service and might not serve the business in the needed and promised way. The responsibilities of Capacity Management include:    

Ensuring current and future IT capacity needs are met. Monitoring the performance of the IT infrastructure. Drawing up capacity plans associated with the levels of service agreed. Managing and rationalizing demand for IT services.” Source: http://itil.osiatis.es/ITIL_course/

Monitoring and forecasting of the actual demand of capacity serves as an important base of information for managing capacity of storage. The following figure shows a tool that monitors, calculates and forecasts aggregated demand for capacity companywide, but also in detail to estimate capacity needed.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 245

Disk Percent Busy for Windows Systems

Disk Percent Busy for Unix Systems

I/O Activity for Windows Systems

I/O Activity for Unix Systems

Fig. 5.12: Disk Busy and IO Activity Reports for Windows and Unix Systems (Based on http://www.teamquest.com/products/cmis/data-storage/)

A central document and tool of Capacity Management is the Capacity Plan, in which all information is consolidated to form a base for action.

5.3.1.4.3 ITIL Stage: Service Operation The stage or cluster of “service operation” comprises ITIL processes to support the everyday work of users. Here, regular events and irregular incidents are recorded, which might eventually be classified as a real problem and then need to be solved. The central institution for these processes is the “Service Desk”, which serves as a communication center between users and the IT organization. These ITIL processes are what you might associate with “IT support” in your everyday work. Rance (2011, p. 9) sums this stage up like this: “ITIL Service Operation describes best practice for managing services in supported environments. It includes guidance on achieving effectiveness and efficiency in the delivery and support of services to ensure value for the customer, the users and the service provider. Strategy objectives are ultimately realized through service operation, therefore making it a critical capability. ITIL Service Operation provides guidance on how to maintain stability in service operation, allowing for changes in design, scale, scope and service levels. Organizations are provided with detailed process guidelines, methods and tools for use in two major control perspectives: reactive and proactive. Managers and practitioners are provided with knowledge

246 | 5 IT-Management

allowing them to make better decisions in areas such as managing the availability of services, controlling demand, optimizing.” Rance (2011), p. 9

One of the elements of good service operation is the process, organization and metrics of the so called Incident Management. An “incident” is an unplanned or unwanted event that can be distinguished from the regular, planned events like the backup every night that shuts down computers before it starts. For example, a CAD workstation shuts down in core working hours and the user cannot work on his/her designs. The following figure shows a process in an organization to resolve such an incident. In this example, there was perhaps just a wrong entry in the backup schedule that caused the CAD workstation to shut down during working hours. 1 Please note that the process might branch out into another process named “Problem Management”. In the example above, this could be the case if the incident cannot be explained and resolved via incident management alone e. g. by a simple change of the entry in the backup schedule.

Individual user can´t work or call

Monitoring Service

Collect additional Information

Helpdesk Ticket

Incident resolved Inform all users about ailed application

Inform Call about responsible resolved experts incident IT experts (Incident Management

Users

Take action (Incident response)

Fig. 5.13: Incident Management (Based on http://www.hcboos.net/blog/2009/01/21/integrating-itil-and-automation)

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 247

5.3.1.4.4 ITIL Stage: Continual Service Improvement ITIL Continual Service Improvement provides guidance on creating and maintaining value for customers through better strategy, design, transition and operation of services. It combines principles, practices and methods from quality management, Change Management and capability improvement. ITIL Continual Service Improvement describes best practices for achieving incremental and large scale improvements in service quality, operational efficiency and business continuity, and for ensuring that the service portfolio continues to be aligned to business needs. Guidance is provided for linking improvement efforts and outcomes with service strategy, design, transition and operation. A closed loop feedback system, based on the Plan-Do-Check-Act (PDCA) cycle, is established. Feedback from any stage of the service lifecycle can be used to identify improvement opportunities for any other stage of the lifecycle. (Rance 2011, p. 8) The following figure shows how the various feedback cycles enable continuous improvement:

Service Strategy Strategies, polices, standards

Output

Feedback Lessons learned for improvement Service Design Plans to create and modify services and service management processes

Output

Feedback Lessons learned for improvement

Feedback Lessons learned for improvement Service Transition Manage the transition of a new or changed service management process into production Output

Continual Service Improvement Activities are embedded In the service lifecycle

Fig. 5.14: Continual Service Improvement and the Service Lifecycle (Based on Rance (2011), p. 33)

Feedback Lessons learned for improvement Feedback Lessons learned for improvement

Service Operation day-to-day operation of services and service management processes

248 | 5 IT-Management

Service Strategy determines Service Design. Service Design defines whether transitions need to be made. Finally, the transition of a service is employed in the everyday work during Service Operation. However, the relationship is mutual – each following stage needs to evaluate whether the ideas and parameters from the previous stage can be put to work. So, feedback and lessons learned for improvement are reflected “upstream”. The feedback for improvement is not strictly bound between each pair of stages. Of course, there is valuable information and experiences from, say, service operation for service strategy, which can be directly used for improvements. Continual Service Improvement itself provides the tools and methods the single stages need to use information given by other stages for real improvement. These are, for example, measures of evaluation and processes of feedback gathering and processing.

5.3.2 Zoom in on Processes in the Stage of Service Transition Since we will describe “Change Management” in greater depth, it seems necessary to describe its neighborhood, the stage of Service Transition, more closely, as done by Rance (2011, p. 4.): Service transition in the service lifecycle ensures that new, modified or retired services meet the expectations of the business as documented in the service strategy and service design stages of the lifecycle. The objectives of service transition, as a stage in general, are for example to:  Plan and manage service changes efficiently and effectively  Manage risks relating to new, changed or retired services  Successfully deploy service releases into supported environments  Set correct expectations on the performance and use of new or changed services  Ensure that service changes create the expected business value  Provide good-quality knowledge and information about services and service assets. In order to achieve these objectives, there are many tasks to be fulfilled during the service transition lifecycle stage. These include, according to Rance (2011, p. 4.):     

“Planning and managing the capacity and resources required to manage service transitions Implementing a rigorous framework for evaluating service capabilities and risk profiles before new or changed services are deployed Establishing and maintaining the integrity of service assets Providing efficient repeatable mechanisms for building, testing and deploying services and releases Ensuring that services can be managed, operated and supported in accordance with constraints specified during the service design stage of the service lifecycle”

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 249

These were the overall objectives and tasks of service transition. For each of these points, ITIL publications go into great detail, clarifying the policy, giving advice on how to do it (principles), and also offering some best practices that are gathered from real firms which are considered to be doing (very) good service transition. The basic element of ITIL, however, is the single service process. As can be seen, the figure “Service Transition” in the Beginning of chapter 5.3.1.4, comprises the following single ITIL processes (van Bon 2009, p. 96):  Transition Planning and Support  Release and Deployment Management  Service Validation and Testing  Evaluation  Knowledge Management  Service Asset and Configuration Management (SACM)  Change management (detailed in chapter) The processes besides Change Management are quickly described to get a better figure of the neighboring processes Change Management deals with most often.

5.3.2.1 Transition Process: Transition Planning and Support Transition planning and support ensures planning and coordination of resources in order to realize the specification of Service Design. Additionally, the process ensures the identification, management and minimization of risks which can interrupt the service during the transition phase (van Bon 2009, p. 96) The scope of Transition Planning consists of:  design specifications and requirements of the software production department in the transition planning process  management of planning, support activities, transition progress, changes, issues, risks, deviations, processes, supported systems and tools  monitoring the Service Transition performance  communication with the client, users and stakeholders The planning and support activities are (van Bon 2009, p. 96):  set up transition strategy  prepare Service Transition  planning and coordination of Service Transition  support

250 | 5 IT-Management

Example: The transition of several connected applications to a new version of their according current updates needs to be backed by a master plan. Also, a close coordination with the owners of the business processes supporting these applications is needed.

5.3.2.2 Transition Process: Release and Deployment Management Release and deployment management aims at building, testing and deploying services specified in Service Design, and ensuring that the client utilizes the service effectively. The objective of release and deployment management is to ensure that … (van Bon 2009, p. 98):  … there are release and deployment plans  … release packages (composition) are successfully deployed  … the IT organization transfers knowledge to the clients  … there is minimal disturbance to the services. The process activities of Release and Deployment Management are mainly comprised of (van Bon 2009, p. 98):  planning  preparation of building, testing and deployment  building and testing  service tests and pilots  planning and preparation for deployment  transfer, deployment and retirement  verify deployment  Early Life Support (ELS)  review and dose Example: In a highly interconnected environment, the CAD system needs to be updated. There also was an improvement of a work plan export filter from the PDM (see chapter 2) into the CAD application. Release and Deployment Management pack these two changes into one release, test it thoroughly and keep tight control over the actual deployment of the release package.

5.3.2.3 Transition Process: Service Validation and Testing Service tests deliver an important contribution to the quality of IT service provision. Tests ensure that the new or changed services are “fit for purpose” and “fit for use”. The goal of service validation and testing is to deliver a service which is of added value to the client's business. When not properly tested, additional incidents, problems and costs occur. The objectives of service validation and testing are to ensure that (van Bon 2009, p. 98):

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 251

 the release fulfils the expectation of the client  the services are “fit for purpose” and “fit for use”  the specifications (requirements) of the client and other stakeholders are defined. Service validation and testing are applied during the entire service lifecycle and are intended to test the quality of the service. Testing directly supports the release and deployment process. The output from testing is used by the evaluation process. The test process activities are not conducted in a fixed order and can be implemented in parallel. In any case, they include, according to van Bon (2009, p. 99):  validation and test management  planning and design test  verification of test plan and design  preparing the test environment  testing  evaluation of exit criteria and reports  cleaning up and closure There are many different test techniques and approaches, including: document review, simulation, scenario and laboratory tests, and role plays. The best choice depends on the type of service, the risk profile, the test goal and the test level. Example: For a new connector/interface between the CAD and the ERP system, test cases with real data need to be prepared. It also demands a test environment, including the connection of those two applications without interfering with the running old versions of the applications. We will go deeper into testing as an indispensable part of introducing software in chapter 7.2.

5.3.2.4 Transition Process: Evaluation Evaluation is a generic process that is intended to verify whether the performance of “something” is acceptable, for example, whether it has the right price/quality ratio, whether it is continued, whether it is in use, whether it is paid for, and so on. In the context of Service Transition, the objective of evaluation is the definition of the performance of a service change. Evaluation delivers important input for Continual Service Improvement (CSI) and future improvement of service development and Change Management (van Bon 2009, p. 99). The evaluation process is comprised of the following activities (van Bon 2009, p. 99):  planning the evaluation  evaluation of the predicted performance  evaluation of the actual performance  risk management.

252 | 5 IT-Management

Example: Our new interface between CAD and ERP is predicted to process one BOM or drawing per minute. The actual performance is, however, lower: it takes five minutes for one set of data. The evaluation showed that everything was implemented and operated correctly, but the mistake lies within service design: the chosen combination of software modules does not allow for the performance predicted.

5.3.2.5 Transition Process: Knowledge Management The goal of knowledge management is to improve the quality of decision making by ensuring that reliable and secure information is available during the Service Lifecycle. The objectives of knowledge management include:  enabling the service provider to improve the efficiency and quality of the services  ensuring that the service provider’s staff has access to adequate information. Knowledge management is used in the entire lifecycle, but is particularly relevant during service transition: a successful transition depends mainly on the information available and knowledge of users, service desk, support and the service provider (van Bon 2009, p. 99). Effective sharing of knowledge requires the development and maintenance of a service knowledge management system (SKMS). This system should be available to all information stakeholders. Knowledge management is comprised of the following activities, methods and techniques according to van Bon (2009, p. 99):  knowledge management strategy  knowledge transfer  data and information management  the use of the SKMS. Example: Evaluation of the performance of our new CAD-ERP interface and other interfaces, as well as information from other ITIL processes, is stored in the knowledge base. In a second step, these are used to optimize the combination of program modules or standards in order to increase transfer performance.

5.3.2.6 Transition Process: Service Assets and Configuration Management (SACM) SACM manages the service assets in order to support the other service management processes. It is a cornerstone of Transition Management, since without recording and documenting the configuration, no change and change rollback will be secure. The central object is a configuration item (CI). This might be an application, a piece of hardware, an interface or object whose historical states are of interest for Transition Management. The objective of SACM is (van Bon 2009, p. 97):

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 253

 The definition of service and infrastructure components and the maintenance of accurate configuration records.  For this, it is important that the integrity of the service assets and configuration items (CIs) is protected, all assets and CIs are categorized in configuration management, and the business and service management processes are effectively supported.  SACM may cover non IT assets and CIs of work products which support the development of services.  The scope of the process also includes assets and CIs of other suppliers (“shared assets”) if these are important for service. The SACM activities are according to van Bon 2009, p. 98):  management and planning  configuration identification  configuration management (control)  status accounting and reporting  verification and audits. Example: The new interface will only work with exactly the defined release of the CAD and the ERP system. Every change on either one of the applications will cause the interface to fail. So, all versions of applications, states and configurations have to be documented and every change on them needs to be recorded. Otherwise, a possible error cannot be traced back to its origin and a roll back to a previously working state is also not possible if the configuration of the items in the working environment is not known.

5.3.3 Zooming in on the ITIL Service Process of Change Management (CM) in the Stage of Service Transition Since we cannot replicate all 28 ITIL processes, we will just focus on one important process as an example, to exercise its micro-structure: Change Management has proven to be a central issue in all organizations using IT. Change Management (CM) in IT and ITIL must be sharply distinguished from “Change Management” 4 in an organizational sense, which means changing an organization to a (new) desired state.

Literally, CM manages the change of existing IT services by fixing problems or initiating improvements. The following figure shows how CM and neighboring processes of service transition together form a PDCA cycle.

254 | 5 IT-Management Innovation Improvement Change

Corrective measures

Problem Management (Act)

Analyze/ Evaluate

Change Management (Plan)

Configuration Management (Register)

Incident Management (Check)

Build/ Buy

Release Management (DO)

Install

Fig. 5.15: The Context of Change Management (Based itSMF (2007), p. 87)

To provide IT services effectively, the organization should be able to deal with a large number of changes smoothly and responsibly, and this has to be formally organized. Bad or non-existing Change Management is often named as the biggest problem in IT management by IT professionals. Specific benefits of good Change Management include, according to itSMF 2007, p. 99f.:  Reduced adverse impact of changes on the quality of IT services.  Better estimates of the costs of proposed changes.  Fewer changes are reversed, and any back-outs that are implemented proceed more smoothly.  Enhanced management information is obtained about changes, which enables a better diagnosis of problem areas.  Improved user productivity through more stable and better IT services.  Improved IT personnel productivity, as they are not distracted from their planned work by urgent changes or back-out procedures.  Increased ability to accommodate frequent changes without creating an unstable IT environment.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 255

The following problems may be encountered when introducing CM:  Paper-based CM systems are too difficult to use and will present too many problems.  There may be resistance against an umbrella CM authority that monitors all aspects of the IT infrastructure.  The integrity of the CM process depends on full compliance. Some problems can be addressed by implementing the following suggestions:  Ensure that each change follows the complete procedure.  Communicate with all IT personnel and all suppliers to ensure that they accept Change Management, and do not try to implement changes without coordination.  Ensure that changes are evaluated and that standard changes are handled by effective change models to reduce work.  Work with SACM to ensure that CI changes are registered in the SACM database.  In the following chapters, the real processes, institutions, tools and interfaces of CM are more closely examined.

5.3.3.1 Processes of Change Management At the core of all ITIL processes, suggestions and best practices are offered on how to design a process of doing good service. Of course, every company needs to find its own processes that fit. However, ITIL makes a strong case on two points:  The process needs to be documented in a formal way and  there are general recommendations and examples of good processes. The following figure shows the basic steps of a good CM according to ITIL. On the web, you will find many other examples and variations of this process map and also practical examples of Change Management process in certain companies.

256 | 5 IT-Management

Create RFC Change proposal (optional)

1

Record to RFC

Initiator

requested

2

Review RFC

Change Management

ready for evaluation

3

Assess and evaluate change

Work orders

ready for decision

4

Authorize Change proposal

Authorize Change

Change Authority

authorized

5 Change Management

6 Change Management Evaluation report

Update change and configuration Information in CMS

7

Plan Updates

Work orders

scheduled Coordinate change implementation implemented Review and close change record closed

Fig. 5.16: Basic Steps of a Good CM Process (Based on van Bon (2009), p. 237)

1. Create and record: The change is raised by a request from the initiator – the individual or organizational group that requires the change. For example, this may be a business unit that requires additional facilities, or problem management staff instigating an error resolution from many other sources. All requests for changes (RFCs) are registered and it must be possible to identify them via a unique identification number. The scope and impact of the eventual change determine how much information is required for the change. 2. Review the RFC: After registration, the stakeholders verify whether the RFC is: totally impractical, repeats earlier RFCs, accepted, rejected or still under consideration, incomplete submissions, e. g. inadequate description or without necessary budgetary approval. Such requests are rejected and returned to the initiator with

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 257

details of the reason for the rejection. The initiator should have a right of appeal against rejection. 3. Assess and evaluate changes: This step starts with categorizing the change. The likelihood that the risk will occur and its possible impact determine the risk category of the change. In practice, a risk categorization matrix is generally used for this purpose. After the change has been categorized, it is evaluated. Based on the impact, risk assessment, potential benefits and cost of the change, the change authority (e. g. the Change Manager and/or change authority board) determines whether the change is supported or not. The seven Rs of Change Management must be answered for all changes:  Who raised the change?  What is the reason for the change?  What is the return required from the change?  What are the changes’ risks?  What resources does it require?  Who is responsible for building, testing and implementation?  Which relationships exist between this and other changes? Changes that are classified as minor or as urgent will take a slightly different path in the process as compared to so called “normal” changes. 4. Authorize the change: Formal authorization from a change authority is required for every change. This may be a role, person or group of people. The level at which approval is required depends on the change type: the bigger and riskier the change, the higher the hierarchy for approval needs to be. 5. Change planning and scheduling: CM schedules the changes on the change calendar: the Schedule of Change (SC) that contains the details for all approved changes and their planning, e. g. implementation dates. Changes can be bundled into a release. In consultation with the relevant IT departments, the change authority board may set up fixed times to implement changes at moments in which services will be hindered as little as possible by changes. A recovery plan must be prepared in case of a change implementation. 6. Coordinate change implementation: Authorized RFCs should be passed on to the relevant technical groups for building the changes. Building and creating a release are issues discussed in the ITIL process of “Release and Deployment Management”. The changes should be tested thoroughly, as well as the remediation and the implementation method for the changes. The ITIL process “Service validation and testing” describes testing in detail. 7. Review and close change record: Implemented changes are evaluated after some time – perhaps with the exception of “standard changes”. The change advisory board (CAB) then determines whether further follow-up is required. The CAB pays attention to the following matters:

258 | 5 IT-Management    

Did the change realize its intended purpose? Are all the stakeholders satisfied with the outcome? Did any side-effects occur? Were the estimated costs and effort exceeded?

If the change is successful, it can be closed. The outcome should be included in the Post Implementation Review. For better readability, we omitted any branches or loops in the previous figure. There are, however, some decisions after which the process branches out and takes different paths (if organized this way):  In evaluating the change it might be classified as a minor or standard change. Such a change has a shorter way into deployment and might be decided upon and organized by the Change Manager alone.  In the last step: Change successful XOR change not successful. If not successful then a back-out plan can be initiated.  Independent of a big or a minor/standard change, it might be urgent, and be processed rapidly as such.  … and others depending on how the organization organized the process. After understanding the basic model, the following figure shows a process with different branches and the person/role who actually is responsible for this step. Please be aware that this is a) just one suggestion of how a good process of CM could be provided and b) just the basic procedure. After the decisions: “Is it an urgent change?” and “Is it a standard (= minor) change?”, the process branches out into different paths that can be found in a different figure in the source cited.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 259

Initiators Reject

Change Manager

Configuration Manager

Filters request

Initial Logging of RFC

Accept Change Manager Allocates initial priority

Configuration Manager Updates log

Urgent Procedure (Picture 3)

Yes

Urgent No

Change Manager Decides category and/or use of standard model

Standard model

Minor

Significant

Change Manager Authorizes and Schedules Changes. Reports to CAB

Change Manager Circulates RFC´s to CAB members

Change Manager Estimate impact and resources, confirm agreement to Change, confirm priority, Schedule Changes

No

Major eg Board Passes approved Changes to CAB for actioning

Configuration Manager Updates log , Issues forward Schedules

Can be iterative

Authorized

Standard Procedure (Picture 2)

Configuration Manager Updates log, Issues FSC

Yes Change Builder Builds Change, devises backout and testing plans

Configuration Manager Updates log with progress reports

Failure Independent Tester

Configuration Manager

Test Change

Updates log

Success

Change Manager Coordinates implementation of Change

Working Yes Elapsed Time

No

Configuration Manager Informs Users, Updates log Change Builder Back-out plans implemented

Configuration Manager Updates log

Fig. 5.17: Basic Change Management Process (Based on http://itservicemngmt.blogspot.de/2007/07/change-management-quickreference.html)

260 | 5 IT-Management

The following chapter will explain the roles of important institutions of Change Management in more detail.

5.3.3.2 Roles and Institutions of Change Management In this chapter, roles and institutions of CM and terms that have been used in the previous chapters like Change Initiator, Change Manager, Change Advisory Board will be explained in detail. Change Initiator: The change is raised by a request from the initiator – an individual or organizational group that requires the change. For example, this may be a business unit that requires additional facilities, or problem management staff instigating an error resolution from other sources (van Bon 2009, p. 236). A service provider from inside or outside the company might raise a change request as well, e. g. if he is unable to deliver a certain feature in a service anymore or it might save a lot of work if the customer would agree to this change. Change Manager: The Change Manager is the person responsible for filtering, accepting and classifying all Requests For Change (RFC). In a large organization, the Change Manager may be supported by Change Coordinators who represent the Change Manager by connecting with the various areas of the organization. Change Management is in charge of obtaining the required authorization. The Change Manager is also responsible for planning and coordinating the implementation of the changes (van Bon 2009, p. 237). Change Advisory Board (CAB): The Change Advisory Board (CAB) is a consultative body, and meets regularly to assess, prioritize and plan changes. It always includes the Change Manager. Normally, only the more significant changes are presented to the CAB. Its size and members might vary with the size of the company and the IT-organization. The following representatives of stakeholders and neighbors of Change Management might be members of the CAB, next to the Change Manager:  customers  end users  application developers  system administrators  experts  service desk representatives  service provider representatives  … (more).

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 261

The CAB should meet regularly and is additionally triggered by certain events, like emergencies. For regular meetings, the CAB should have a number of fixed items on the agenda, including (itSMF 2007, p. 96):  Unauthorized changes observed in the organization  Authorized changes that have not been submitted to the CAB.  RFC’s which must be assessed by the members of the CAB.  Open and closed changes  Evaluations of past changes  Estimating the impact and resources to determine the authorization necessary to get certain changes approved (see below). “The Authorization”: Modern ITIL interpretations talk neutrally of the “Change Authorization” that will change for different levels of risk/impact of changes as predefined by Change Management:  The Change Manager herself for low risk/small changes,  The CAB for medium changes  Up to board level management for high risk/major change in very limited level 1 cases. The assignment of a certain type of change to a certain level of authorization needs to be defined in advance by Change Management.

Communications, decisions and actions

Communications, escalation for RFCSs, risks, issues

262 | 5 IT-Management

Business executive board

High cost/risk change-requires decision from executives

Level 1

IT management board or IT steering group

Change impacts multiple services or organizational divisions

Level 2

CAB or ECAB

Change which only affects local or service group

Level 3

Change manager

Low-risk change

Level 4

Local authorization

Standard change

Level 5

Fig. 5.18: Example of a Change Authorization Model (Based on Rance (2011), p. 78)

Not all companies follow these fine gradients of the severity of a change. However, a Change Manager and a CAB belong to the basic repertoire and they usually decide and process by far the most changes.

5.3.3.3 Tools and Concepts of Change Management In order to practice good Change Management, some tools, documents and concepts are used that have already been mentioned in chapters 5.3.2.1 and 5.3.2.2. They will be explained in more detail here. The central document of Change Management is the change request and its further documentation in a change log. The terms “change”, “change record” and “RFC” are often used inconsistently, leading to confusion. So, it has to be clarified here (Rance 2011, p. 65): A change is the addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items (CI).

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 263

For example, we need a new data field in our PDM system (see chapter 2) for recording some information about whether the material used in the design is classified as dangerous. Here, the according database table would be the configuration item (CI) that might be changed, if the change is successful. A request for change (RFC) is a formal proposal for a change to be made. It includes details of the proposed change and may be recorded on paper or electronically. The term RFC is sometimes misused to describe a change record, or the change itself. To be clear: A 4 RFC is a paper or a form of description that describes a change. An RFC is going down into the change record in the database and is updated regularly.

A change record contains the details of a change. Each change record documents the lifecycle of a single change. A change record is created for every RFC that is received, even those that are subsequently rejected. Change records should reference the configuration items that are affected by the change. They may be stored in the configuration management system or elsewhere in the service knowledge management system. Here are examples of the information that could be included in an RFC (itSMF 2007 p. 93):  Identification number of the RFC.  Associated problem/known error number (where relevant).  Description and identification of relevant configuration items (CIs).  Reason for the change, including justification and business benefit.  Current and new version of the CIs to be changed.  Name, location, email, telephone number of the person submitting the RFC.  Submission date.  Estimated resources and timeframes. A change leads to modification of a configuration item (CI) of the data in configuration management and its database; for example:  A change in the status of an existing CI  A change in the relationship between CI and other CIs  A new CI, or variation of an existing CI  A new owner or location of the CI. If the RFC is accepted, the information required for the further processing of the change is included in a change record. Later, the following information will be added to the record:  Assigned priority  Assessment of the impact and required costs

264 | 5 IT-Management             

Category Recommendations by the Change Manager Date and time of authorization Planned implementation date of the change Backup plans Support requirements Implementation plan Information about the builder and implementers Actual date and time of the change Date of the evaluation Test results and observed problems Reasons for rejection of the request (where relevant) Scenario and evaluation information.

This list is literally taken from itSMF 2007 p. 94. 1 If you research the web for the term “ITIL” and “RFC template”, you will find many suggestions of what it could look like, and you might find even word documents to use. A simple checklist of what it should contain can be found here: http://wiki.en.it processmaps.com/index.php/Checklist_Request_for_Change_RFC

There are three different types of Service Changes that might lead to a branching of the process into different paths (Rance 2011, p. 65):  Standard change: A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction.  Emergency change: A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch.  Normal change: Any service change that is not a standard change or an emergency change. Changes are often categorized as major, significant or minor, depending on the level of cost and risk involved, and on the scope and relationship to other changes. This categorization may be used to identify an appropriate change authority; see chapter 5.3.3.2. One of the most important characteristic of a change is its perceived risk, a combination of impact and probability. No change is without risk: simple changes may seem innocuous, but can cause damage out of all apparent proportion to their complexity. There have been several examples in recent years of high-profile and expensive business impacts caused by the inclusion, exclusion or misplacing of a single dot in software code (Rance 2011, p. 65).

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 265

It is, therefore, necessary to classify the risk category independently from the kind of change described above. There is much literature about risk management which cannot be detailed here. The central instrument of risk management is the risk matrix, in which risks are positioned. Impact is the severity of consequences if the event happens (like loss of revenue) and probability is the chance of the unwanted event happening.

Change impact

High Impact

High Impact

Low probability

High probability

Risk category: 2

Risk category: 1

Low Impact

Low Impact

Low probability

High probability

Risk category: 4

Risk category: 2 Probability

Fig. 5.19: Risk Matrix (Based on Rance (2011), p. 75)

According to the category above, the change authority (see chapter 5.3.3.2) might vary. Level 1 changes might even need top management approval. A documented calculated risk is the opposite of a blind gamble. Taking the risk is a business decision and not an IT decision. It is a common cultural problem between the business part and engineers (software or mechanical): while business is willing to take risks, engineers often prefer zero risk decisions. Rance gives an example of different views on the risks of a change in a high-risk industry: “In one volatile and competitive business environment, the mobile telephone supply business, customers asked IT if they were now able to implement a much-needed change to the business software. The reply was that it could not go forward to the next change window because there was still a 30 % risk of failure. Business reaction was to insist on implementation because, in their eyes, a 70 % chance of success, and the concomitant business advantage, was without any hesitation the right and smart move. Very few of their business initiatives had such a high chance of success. The point is that the risk and gamble of the business environment (selling mobile telephones) had not been understood within IT, and inappropriate (IT) rules had been applied. The dominant risk is the business one and that should have been sought, established, understood and applied by the service provider. Sensibly, of course, this might well be accompanied by documentation of the risk based decision, but nonetheless it is necessary to understand the business perspective and act accordingly.” Rance (2011, p. 75)

266 | 5 IT-Management

However, only risks documented and evaluated can serve as a base for taking a calculated risk by business management. Process management always needs means of controlling and measurement. ITIL (so tightly focused on processes) consequently offers metrics to measure process success and enable improvement. Reports can be provided on the following points to show the current situation of the organization. Here are some suggestions for KPIs to measure the state of Change Management in general (taken from itSMF 2007, p. 98):  Number of changes implemented in a period (overall and per CI category)  List of the causes of changes and RFCs  Number of successfully implemented changes  Number of back-outs and their reasons  Number of incidents related to implemented changes  Graphs and trend analysis for relevant periods. Performance indicators show to what extent the CM deals efficiently with changes, with the smallest possible adverse impact on the agreed service level. These indicators cover issues such as (taken from itSMF 2007, p. 99):  The number of changes completed per time unit, by category  Rate at which changes are implemented  Number of rejected changes  Number of incidents resulting from changes  Number of back-outs related to changes  Cost of the implemented changes  Number of changes within resource and time estimation.

5.3.3.4 Interfaces of Change Management As described, CM has close ties with its “sister processes” in the stage of Transition Management. Let’s begin with the origins of changes. Where might they come from? Reasons for changes might stem from more strategic issues and requirements like legal/regulatory change, organizational change, change after analyzing business, customer and user activity patterns, addition of new service to the market space, and so on. The most frequent, operative reasons for a change are problems (as discovered and defined in Problem Management) that are decided to be solved by a change. For example, a connection to a server had too many timeouts and the solution to this problem was to change the service of the server by changing the server timeout parameters. Figure 5.20 shows the interaction of a change process with some neighboring processes of Service Transition.

5.3 IT Service Management with the IT Infrastructure Library (ITIL) | 267

Other processes

External processes

Configuration Management

Change Management

Release Management

Receive request for change

Buy or develop/ applicatio n hardware

IT environment baseline data

Buy

Document in change log

Approve, schedule, and distribute change

Test

Availability management- IT Component status Service desk incident evaluation and resolution Incident management – incident evaluation and resolution

Document in change log

Develop

Configuration Management database

Receive release authorization

Organize release team

Definite Software Library

Develop release plan

Build release

Initiate communications process

Problem management – problem evaluation and resolution

Monitor build, testing, and release process

Capacity management –IT environment picture

Document in change log

Implement pilot staging

Contingency planning –IT environment blueprint

Post implementation review

Implementful release

Financial management IT component status

Close request for change in change log

Security administrationsecurity protocols

Fig. 5.20: Change, Configuration, and Release Management (Based on http://technet.microsoft.com/en-us/library/cc966506.aspx)

Perform user acceptance testing

268 | 5 IT-Management

The figure above visualizes the interconnectedness of Change Management as just one example. A more general list of possible relations can be found here (itSMF 2007, p.90):  Incident Management: Two sided: might lead to a change request. Change request might cause an incident.  Service Assent and Configuration Management (SACM): Very close integration. SACM must record and document changes.  Problem Management: Two sided: might lead to a RFQ. Change requests also might cause a problem.  Release Management: Changes are packaged together and controlled by Release Management.  Service Level Management: CM must report temporary or permanent effects on Service Level.  Availability Management: Might initiate changes and is often involved in estimating effects of changes concerning availability.  Capacity Management: Cumulative Changes might affect capacity. Capacity might initiate Changes for better use of capacity.  lT Service Continuity Management: Must be aware of all changes that might affect continuity Change Management Raise and record change request

Asses change

Coordinate change implementation

Authorize/ reject change

Review change

Close change

Review change

Close change

Release and deploy new/changed CIs

Reports and audits

Identify affected items

Update records

Capture release & environment baselines

Service asset and configuration management Configuration management system

Fig. 5.21: Change Management and SACM (Based on Rance (2011), p. 87)

5.4 Other Frameworks and Approaches | 269

The process most interconnected with Change Management is Configuration and Service Asset Management (SACM), since by definition, a change is anything that might change a configuration item in the SACM database. These two ITIL Service processes depend highly on each other in several steps, as the following figure shows. If introducing a professional Change Management, at least some basic SACM has to be installed with it.

5.4 Other Frameworks and Approaches There are many different frameworks for ITSM. There is even a book published that claims to give an overview for 50 different ITSM frameworks. However, a framework is just a big checklist for how to establish a good ITSM in your own company. It is important to start introducing professional ITSM at all with any good framework. Even realizing just a part of any good framework will create more value than arguing about the “right” framework. So here we will just have a short look at two other prominent frameworks: COBIT and the approach of “IT-Controlling” that is widely used in Germany.

5.4.1 Cobit as a Framework for ITSM and IS Compliance COBIT (Control Objectives for Information and Related Technology) is a framework for management and for controlling IS and IS governance in the company. It comprises a process model with applicable and internationally accepted requirements to which the IT must comply. The structure of COBIT will be explained top down going from the highest to the lowest/final level. All control activities are grouped into four “domains”. These domains are the same top level like the ITIL stages, and therefore, look familiar. COBIT control domains are:  Plan and organize  Source and implement  Deliver and support  Measure and evaluate. In each of these domains, several processes are comprised, as can be seen in the figure below. These processes (e. g. “Manage Portfolio” in the domain “Plan and Organize”) are logically on the same level of the ITIL processes. There are 34 processes in the COBIT framework. Smallest elements are the so called “control objectives” in each process. Depending on the processes, there are 3 to 15 control objectives to be met in each process. They help to measure how well a process is managed. Especially appealing is

270 | 5 IT-Management

the fact that these control objectives might be linked to KPIs in a Balanced Scorecard, thus linking ITSM and business management even closer. If all of the more than 200 “control objectives” in COBIT are met properly, very good IT governance and management can be assumed. Like ITIL, COBIT is independent from technology or industry – it might be used everywhere focusing on tasks and processes rather than on organizations. Evaluate, Direct and Monitor EDM01 Ensure Governance Framework Setting & Maintanance

EDM03 Ensure Risk Optimisation

EDM02 Ensure Benefits Delivery

EDM04 Ensure Resource Optimisation

EDM06 Ensure Stakeholder Transparency

Align, Plan and Organise APO01 Manage the IT Mgmt. Framework

APO02 Manage Strategy

APO08 Manage Relationships

APO09 Manage Service Agreements

APO05 Manage Portfolio

APO06 Manage Budget & Costs

APO03 Manage Enterprise architecture

APO04 Manage Innovation

APO10 Manage Suppliers

APO11 Manage Quality

APO12 Manage Risk

APO13 Manage Security

BAI04 Manage Availability and Capacity

BAI05 Manage Organisational Change Enablement

BAI06 Manage Changes

APO07 Manage Human Resources

Monitor Evaluate & Assess MEA01 Monitor Evaluate & Asses Performance and Conformance

Build, Acquire and Implement BAI01 Manage Programs and Projects

BAI02 Manage Requirements Definition

BAI03 Manage Solutions Identification & Build

BAI08 Manage Knowledge

BAI09 Manage Assets

BAI10 Manage Configuration

BAI07 Manage Change Acceptance & Transitioning

Build, Acquire and Implement DSS01 Manage Operations

DSS02 Manage Service Requests & Incidents

DSS03 Manage Problems

DSS04 Manage Continuity

DSS05 Manage Security Services

DSS06 Manage Business Process Controls

MEA02 Monitor Evaluate & Assess the System of Internal Control

MEA03 Monitor Evaluate & Assess Compliance with External Requirements

Processes for Management of Enterprise IT

Fig. 5.22: COBIT 5 Process Reference Model (Based on http://www.isaca.org/Knowledge-Center/Blog/Lists/Posts/Post.aspx?ID=193)

5.4 Other Frameworks and Approaches | 271

So far, COBIT sounds a lot like ITIL and they are often cited together when talking about frameworks that help to improve ITSM. However, there are some differences you might want to research by using the search phrases “compare ITIL and COBIT” or “ITIL COBIT mapping”. To put it briefly: COBIT was introduced in the auditing context to ensure compliance and good governance of information systems in the company. Therefore, it is more structured and tightly focused on control. ITIL, on the other side, is targeted towards practical improvement of IS with many suggestions and best practices. Like ITIL, COBIT overviews are widely available on the net. Here are just two sources: http://www.bcs.org/upload/pdf/smsg-210612.pdf http://www.isaca-washdc.org/presentations/201203_cobit_session1.pdf

5.4.2 IT-Controlling and Budgeting IT-Controlling is not really a closed framework, but rather a point of view on how to manage IT properly. It is popular in Europe and, especially in Germany, and that is why the term “controlling” has to be clarified and expanded from an Anglo-Saxon point of view to the German understanding of it. In Britain and the US, the function of “controlling” in a company is tightly linked to finance and accounting. In Germany, however, controlling is seen in a more expanded view: here, controlling means a service to the management task of planning and controlling the business, and coordinating the information the business needs and generates. Most of the information controlling gathers contains monetary information, especially cost; however not all of it is. There is growing interest in the report of non-monetary numbers both on an operative and strategic level. So, a more adequate translation of German “controlling” for British or American ears would be something like “performance measurement and planning & control services”.

5.4.2.1 Functions and Processes of IT-Controlling Controlling, in the extended definition above, might be targeted at any object in the company. There are many types of “controllings” and people with according titles and positions, e. g. for products (product controller), processes (sales controller) or resources (human resource controller). Information systems might be just another controlling object. Immediately, the question arises of how IT-Controlling can be distinguished from ITIL or COBIT:  COBIT does not go into the process of controlling; it merely details the control objects. That means it simply lists what to check and monitor and suggestions for performance metrics.

1

272 | 5 IT-Management  ITIL has metrics built into every process, as well, but goes a little bit further: it also comprises a separated process called “financial management” that details budgeting, planning and controlling monetary values. IT-Controlling on the other side is tightly focused on measuring, planning and controlling objects in the IT world. IT-Controlling separates its tasks into three areas:  Portfolio Controlling: What kind of applications and services do we want to offer from a strategic point of view?  Project Controlling for projects creating and introducing software and services. This is not forgotten in ITIL; however, ITIL is more focused on running services.  Product Controlling for running applications, infrastructures and services. After clustering the areas, we need to describe a task list. But what is IT-Controlling doing about those objects? Other than in ITIL and COBIT, there is no direct assignment of actual processes to objects. The following processes of IT-Controlling might be directed to all of those objects above (portfolio, projects, products): Table 2.4: Tasks of IT-Controlling (Excerpt from Gomez et al. (2009), p. 4243) Execute IT planning  Plan the IT Budget  Plan IT sourcing  Plan IT portfolios  Set IT standards

Execute data collection  Collect data actuals (e. g. cost)  Maintain IT-Controlling database

Execute internal IT cost allocation  Construct value structure  Executive internal billing of services  Balance internal accounts  Balance deficit and surplus

Executive deviation analysis  Analyze data and refine information  Update IT-Controlling system  Create and deliver reports  Create ad hoc reports and retrieve information on management demand

5.4.2.2 Tools of IT-Controlling In practice, IT-Controlling is about providing tools to plan, calculate and steer the performance, esp. financial performance of IT services. Consequently, many management and controlling tools are also being applied in IT-Controlling. The following table shows some tools associated with IT-Controlling:

5.4 Other Frameworks and Approaches | 273

Table 5.3: Tools of IT-Controlling (excerpt from Gaddatsch (2011), p.11–12) Tools of strategic IT-Controlling  Information demand analysis  SWOT analysis of IT  Benchmarking  Portfolio analysis  Process optimization  IT balanced scorecard

Tools of operative IT-Controlling  Internal cost calculation an pricing of IT services to other departments and products  Key performance indicators (KPIs)  Capital investment calculation, capital budgeting and scoring models to decide about investing in new services

These instruments are described in literature in detail, e. g. in Gomez at al. 2009. In the English-speaking world, IT-Controlling is not a widely researched or published topic, at least not under this very name. However, these instruments also can be found in parts of the frameworks described above. For example, KPIs are part of every ITIL process and the portfolio analysis might be part of strategic IT management. Here, just the three most important tools will be briefly discussed: Portfolios, KPIs and IT costing.

5.4.2.3 Portfolios as a Tool of Strategic Controlling Portfolios are a well-introduced instrument of strategic management, as you might know from other lectures about strategy. The career of portfolios started with the strictly finance-based BCG (Boston Consulting Group)  Matrix (Cash Cows, Stars, …) and spread to be widely used in strategic management in all company functions. All portfolios work similarly: items are evaluated in two dimensions and placed in a field according to their score in each dimension. Then, a grid is drawn across the field dividing each dimension into “high” and “low”, thus cutting the matrix into four areas. After this placement of items, there is also an action part. For each of the four areas in the matrix, and the items in it, standard strategic advice is given. The following figure shows one suggestion for an IT portfolio: it is aimed at evaluating projects that are still in the planning phase. Each project’s “return on investment” and risk expressed as “probability of realization” is evaluated, and the projects are then positioned in the matrix according to their score in each dimension. The size of the dots (projects) represents the individual project volume (cost) to show its importance and the money that is at stake.

274 | 5 IT-Management

high

P1 P3

P7

P2

Return on Investment P5

P4

P6

low low

Probability of realization

high

Fig. 5.23: Project Portfolio (Based on (Gadatsch 2011), p. 71)

As always with portfolios, the position of a project in a certain segment suggests certain actions to be taken:  Return on investment high, Probability of realization low: Reevaluate project risk and find ways to handle the risk (avoid, mitigate, share, the risk).  Return on investment high, Probability of realization high: Clear winner: Realize idea/project now with high priority.  Return on investment low, Probability of realization low: Abandon idea; do not realize the project.  Return on investment low, Probability of realization high: Reevaluate project RoI and find ways to make it more profitable by balancing requirements and resources. 4 Please note: The figure just shows the portfolio method as an isolated instrument of strategic management. Please distinguish this instrument from the task of “IT portfolio management” in a broader sense. IT portfolio management means using this tool to evaluate and decide what applications, projects and services support the business strategy best (see chapters above).

5.4.2.4 Key Performance Indicators (KPIs) as Tool of Operative IT-Controlling With modern ERP systems and some basic data acquisition, the amount of numbers in a company that can be collected is enormous. Consequently, the number of KPIs that can be constructed from those base numbers is virtually limitless. However, most of those numbers are not needed to substantiate good planning and decisions. There are also some numbers that might be desirable or wanted by management,

5.4 Other Frameworks and Approaches | 275

but are not readily available, like “satisfaction with IT services”, unless you initiate a survey to get this number. Basically, there are many different types of KPIs that might be used by ITControlling, which is visualized in the following figure: IT key figures

Absolute key figures

Number of IT staff

Ratio indices

Classification key Figures (shares of equal reference values)

Number of servers

Number of pc workplaces

Relation key figures (shares of different reference values)

Shares IT costs/ total costs Shares IT staff/ employee

Shares IT training costs/ employee Shares IT costs/ turnover

Index key figures

Development IT budget in the last 10 years Forecast IT costs in the next 2 years

Fig. 5.24: IT Key Figures (Based on Gaddatsch (2012), p. 98)

So, one task of IT-Controlling is to choose or construct good KPIs. These KPIs should have certain characteristics; they should be …  … transparent for staff and management  … able to be influenced and controlled by the persons made responsible for these numbers  … independent from other KPIs  … measurable with real numbers  … easily available without too much cost to get the numbers  … comprehensible  … accepted by staff and management If a company uses a KPI to measure, to plan and to evaluate performance of IT staff, maybe even with monetary consequences for them, the KPI should be documented in an orderly manner. The KPI should be described independently from actual use and measurement before actual measurement is applied. The following figure shows how controlling might document a certain KPI and its use:

276 | 5 IT-Management

Table 5.4: Description Sheet for the KPI “First Fix Rate at Standard Software Bugs” (Based on Gadatsch (2012), p. 104105)

General KPI description KPI name

description

First fix rate at standard software bugs Deviations between the agreed first fix rate with the IT outsourcer and the achieved first fix rate

Data data sources

Help Desk tickets

data quality (deviation, validity)

Addressee:

Head of IT

person responsible

Target value

80 %

data preparation

Tolerance value

7080 %

method of calculation

Operation manager

Number of solved problems Number of all processed Tickets

Escalation guidelines

connection (with other key figures)

Validity

Presentation

Creation frequency quantifiability (hard and soft goals) Space for remarks

monthly

Form of Representation

Accessibility and competence of the User Help Desk

Diagrams

aggregation levels

archiving

Some of the fields are not filled – try examples that might make sense for yourself.

5.4.2.5 Management Accounting and Transfer Pricing for IT Services As seen in chapter 1, IS consumes a considerable amount of revenue by causing cost. This cost cannot easily be attributed to products or departments because IS is an administrative function. This has several implications for cost accounting:  It uses many different resources posted in many different accounts, like labor, external cost, depreciation of hardware, yearly software licenses, and so on. The concept of TCO (see chapter 1) shows the wide range of those resources and attributed expenditure.  It offers many different services, which consume those resources differently, e. g. an application that is leased externally in the “cloud” vs. physical IT service performed by internal staff.

5.4 Other Frameworks and Approaches | 277

 It is used by almost all departments and ultimately by all products the company offers to its external customers. Traditionally, IS expenditure was just summed up in the P&L (profit and loss statement) under the fixed cost of G&A (“general and administrative” expenses) together with many other cost positions. This simple summation proved less and less suitable for good cost controlling since this:  did not help planning and steering the cost budgets of the IS departments and  did not attribute IS cost fairly to single business products or product lines because G&A cost were spread evenly across all kind of products. There are several attempts to IT management accounting. A prerequisite for any improvement is to establish both cost center and internal products/services of IT. Cost centers allow businesses to plan and evaluate deviations in the consumption of resources. The definition of internal products/services of IT items helps to attribute cost more precisely to departments and products according to their use of IT services. Once service cost centers and internal service products are defined, the usual tools of management accounting can be applied to IT cost:  Standard costing and deviation analysis that allows for evaluating why a cost center (e. g. in IT) had overrun budget.  Creation of internal transfer pricing that puts a price tag on every IT service another department (like production or sales) is consuming from IT.  Improved allocation of IT overhead cost that cannot be immediately attributed to a single IT service or cost object. So, in a large company with several business units, the whole process of management accounting, pricing and planning of IT services might look like the following figure.

278 | 5 IT-Management

1

3

IT Line Item Costs

Cost Pools Reallocations etc.

4 5 7

2

Other Line Item Costs like HR or facilities

Some costs taken through activities in an ABC methodology

Activities

Total Cost of Service e.g., Helpdesk, Production, Security

Business Unit Demand

6

Unit Cost of Service

Itemized invoice

Fig. 5.25: Process of Management Accounting, Pricing and Planning of IT Services (Based on Barret/Grundy 2006, S. 5)

1.

2.

3.

4.

5.

IT line item cost from accounting might be attributed directly to one single receiving business unit. However, sometimes they are used by more than one service and more than one business unit and have to be reallocated via pools. The Total Cost of Ownership of IT consumes other line items as well, e. g. from HR or facilities. The cost used by IT can hardly ever be directly attributed to a single business unit. The cost pools gather different line item costs and reallocate these for the TCO of a service. This can be done directly if only one service uses/causes certain cost. If more than one service uses cost items, they are distributed via activity based costing: the more activities (and its associated cost) are consumed by a service, the more cost this service must carry. This central step of cost allocation will be detailed later in this chapter. Total cost of a service like “basic helpdesk support” finally comprises the internal cost price of the service.

5.4 Other Frameworks and Approaches | 279

6.

7.

However, high demand of services, overuse of services or other considerations, might make IT management and controlling set the transfer price to the business units differently from the internal cost price. Finally, a business unit (or function, department or a single product line) is charged for the services it uses. Using internal transfer pricing for the use of IT services aims to steer demand for these services via market mechanisms.

Often, business units are additionally forced by corporate management to forecast their demand, and the department for IT services configures their resources according to the forecasts of business units. In this case, an internal “market” is created and a standard cost calculating and deviation analysis can be applied. This helps to pin down the causes of over- or underutilization of the capacity of IT services. Basically, this process follows typical internal management accounting rules. The really difficult part lies in the distribution of the pooled overhead cost in step 4 of the process above. That is why we need to have a closer look at it. The modern way to allocate pooled non-direct cost (typical overhead cost) to single cost objects (IT services) is called “Activity Based Costing” (ABC). It tackles the most difficult task for controlling of any central service: how to attribute IT resource consumption across the company for a certain cost object or an IT service, like “messaging”, “training”, “production”, “security”, etc.. The technique of allocating cost via ABC is shown in the figure below:

Resources

Activities Resources

Cost Objects

Processes

Fig. 5.26: Allocation of Non-Direct IT Cost to IT Cost Objects via Activity Based Costing (Based on Neumann et al. 2004, p. 7)

Let’s take a closer look at the three components and throw in some realistic numbers that were researched by Neumann et al. 2004. The provisioning and use of resources basically cause labor and equipment cost:

280 | 5 IT-Management

Table 5.5: Percentage of Labour and Equipment by IT Division (Neumann et al. (2004), p. 7) Division

Labour Costs

Equipment Costs

Computing Networking Voice Worldwide Service Delivery Management Information Systems

14.6 % 10.6 % 2.4 % 48.8 % 23.6 %

50.0 % 12.0 % 0.7 % 35.0 % 2.3 %

“Labor cost consists of all costs associated with salaries, travel and entertainment, and contract professional services. The company had never allocated the labor cost out to the internal users, so it was important to provide a way in which the total indirect cost could be assigned with or without labor. Equipment is all the equipment (and depreciation) for which its IT division is responsible. Company XYZ continued transferring equipment costs directly from the resource entity to the cost-object entity”. (Neumann et al. 2004, p. 7).

Many cost positions that are caused by delivering IT services cannot be attributed directly to one single IT service. For example, labor cost and equipment cost are found in more than one account and used to deliver more than one service. The solution is to measure the time IS departments are spending on certain single activities. These single activities from different departments and accounts are then summed up into consistent processes. Table 5.6: The Percentages Reported for Seven Activities (Neumann et al. (2004), p. 7) Activities

Time Reporting per Activity

Supervision, Administration, and Other Technical Support Operations Support

10 % – 10 % – 5% –

15 % 25 % 45 %

Requirements Analysis Keeping Current

5% – 10 % –

20 % 20 %

Project Management

5%

–

30 %

Planning and Design

30 % –

50 %

Processes are ultimately consumed by cost objects (IT services). ABC reflects exactly this and charges the services. All IT costs from accounting are attributed to cost objects in a ratio that reflects the real consumption of resources that provide these processes via single activities.

5.5 Summary of Chapter 5 | 281

Table 5.7: Percentage of IT Costs Consumed by the Cost Objects (Neumann et al. (2004), p. 7) Cost Objects

Internet Intranet

Percentage

1.4 0.7

Messaging

0.7

AT and Managed Labs

0.3

Server Platforms

21.0

Training PC Services

3.8 37.0

LAN/WAN Services Phone Marketing Support Other Support service not included in this analysis

14.0 9.8 0.1 11.2

Total

100.0

So, finally internal pricing of IT cost can be put to work. The concepts of ITIL, like defining a service catalogue, capacity management, finance and budgeting consideration, might help IT-Controlling a great deal in setting up management cost accounting for IT services.

5.5 Summary of Chapter 5 IS consumes a considerable amount of budget and influences the profitability and compliance of companies. So, organizations see the need to govern and manage this important function. Theory and practice have found several concepts and frameworks to support management in this important task, for example ITIL, COBIT and IT-Controlling. Every kind of management (including IT management) should be headed by strategic management. Strategic IT management employs processes and tools from strategic business management. One framework known to cover every area of ITSM is ITIL. It offers 28 possible “processes” of IT management. For each process, ITIL publications offer policies, role descriptions, example process diagrams, tools and templates, and best practice examples. In this chapter, we explored just one of these 28 processes, that is often named as problematic in practice: “Change Management”. There are many competing frameworks, but the only one comparable to ITIL in breadth and structure seems to be COBIT. IT-Controlling can offer additional insight focused on cost allocation and KPI use.

282 | 5 IT-Management

The most important message of this chapter, however, is: all frameworks are just offerings to build an individual, good ITSM and IT governance. There are successful companies that mix tools and processes of all three frameworks explored in this chapter.

5.6 Literature for Chapter 5 Barrett, R., Grundy, C.: Costing and Cross-Charging IT Services, business object publications, 2006, http://www.algsoftware.com.au/Resources/Costing_and_Cross_Charging_IT_Se_Whi_Eng_00 2472.pdf Bon, J. v. (Ed.): Foundations of IT Service Management based on ITIL (ITIL v.3). 1st ed., 4th. impression. Van Haren 2009. Gómez, J.M., Junker, H., Odebrecht, S.: IT-Controlling: Strategien, Werkzeuge, Praxis, Berlin 2009. itSMF: Foundations of IT Service Management based on ITIL (ITIL v.2). 2nd ed., 6th impression. Van Haren 2007. Kranawetter, M.: Benefits of Regulatory Requirements with respect to Business Optimization, Unterschleißheim 2009, http://ebookbrowse.com/it-infrastructure-compliance-maturity-modelmicrosoft-kranawetter-en-pdf-d103253512 Neumann, B., Gerlach, J. Moldauer, E., Finch, M., Olson, C.: Cost Management using ABC for IT Activities and Services, in: Management Accounting Quarterly, VOL. 6 No. 1, Fall 2004, 112. Piccoli, G., Feeny, D. and Ives, B. Creating and Sustaining IT-Enabled Competitive Advantage, in: Luftman, J. (ed.) Competing in the Information Age: Align in the Sand, pp. 107136, Oxford University Press 2003. Rance, S.: ITIL v.3 Service Transition, 2nd ed., The Stationary Office London 2011. Rüggeberg, M.: ITIL®-COBIT® Mapping, Gemeinsamkeiten und Unterschiede der Frameworks, Ergebnisse des Arbeitskreises ITIL®-COBIT® Mapping, 2011, http://de.slideshare.net/digicomp/itil-cobit-mapping-gemeinsamkeiten-und-unterschiededer-frameworks Tiemeyer, E.: IT-Strategien entwickeln – IT-Architekturen planen, Munich 2007. Weill, P., Woodham, R.: Don’t Just Lead, Govern: Implementing Effective IT Governance, MIT Sloan Working Paper No. 4237-02, April 2002, http://papers.ssrn.com/sol3/papers.cfm?abstract_id=317319

5.7 Review Questions for Chapter 5 5.7.1 Choose: Benefits of an IS Management Framework Please check all benefits of an IS management framework: 1)

It is a big “checklist” of what to consider to implement good IT Management.

2)

It describes how most companies manage their IS in reality.

3)

It suggests examples, tools and best practices from other companies by which to be inspired.

5.7 Review Questions for Chapter 5 | 283

4)

It tells a company exactly and in detail how to organize its IS management.

5)

It serves as a common understanding/language. If you talk to IT staff about a “change request” or “request for change” (RFC), most of them will have a precise idea of what you are talking.

6)

It ensures that a companies’ IS tightly follows requirements of authorities and regulators.

7)

As with many concepts and ideas: talking and thinking about it creates ideas and moves the IT organization towards action.

5.7.2 Close: Different Frameworks for IS Management For each gap, please choose the correct word to complete the sentence: 1)

[COBIT, ITIL, IS-Controlling] stems from auditors and is focused on control and evaluation of IS activities. Of course, a good grip on IS processes will not only ensure compliance, but also help management – compliant or not.

2)

[ITIL, IS-Controlling, COBIT] is focused on showing examples and best practices of how to keep IS running and to improve it with good service management.

3)

[COBIT, IS-Controlling, ITIL] is derived from management control applied to IS, and therefore, uses KPIs and cost accounting information intensively.

5.7.3 Choose: Questions of IS Governance 1)

Please mark all questions/issues of IS governance. What decisions are needed to be made: Decisions about major IT domains.

2)

What work assignments will be fixed: What is the task of a support desk employee?

3)

Who has the decision and input rights: Rights are exercised in different governance styles.

4)

How are the decisions formed and enacted: Multiple mechanisms make governance work.

5)

How will the project portfolio be optimized: What projects will yield the highest benefits for our IS-strategy?

6)

How to secure day-to-day operations: What backup media should be used?

284 | 5 IT-Management

5.7.4 Close: Compliance vs. Governance For each gap, please choose the correct word to complete the sentence: 1) The relationship between IT governance and IT compliance might be described as follows: [IT compliance, IT governance] is supported by good [IT compliance, IT governance]. Without proper [IT compliance, IT governance] tight [IT compliance, IT governance] seems hard to reach. 2)

On the other hand, even an organization with refined [IT compliance, IT governance] might act against the law, thus violating [IT compliance, IT governance], like a drug smuggling enterprise that has a very well organized and governed IS.

5.7.5 Choose: IT Compliance Checked by Auditors Check all correct statements: In order to check IT compliance most auditors will … 1)

… get a list of users and what permission they have in the system.

2)

… evaluate efficiency of IT operations.

3)

… test usability of systems.

4)

… check to see what process is used for user IDs and passwords.

5)

… check how often passwords are changed.

6)

… evaluate how quickly new releases of software can be organized.

7)

… check how complex the user IDs are.

8)

… check how easily changes or modifications can be made to the system.

5.7.6 Close: Business Strategy Tools as a Base for IS strategy For each gap, please choose the correct word to complete the sentence: 1)

The [PESTEL, Portfolio Analysis, Generic strategies] analysis evaluates the broader external legal, economical and technical context a company is operating in.

2)

The [Five Forces model, Portfolio Analysis, Generic Strategies, Internal Analysis] structures information about the closer external industry context of customers, competitors and suppliers.

3)

The [Five Forces model, Portfolio Analysis, Generic Strategies, Internal Analysis] evaluates resources and competencies and compares them to the closest competitor (or market leader). It is also called strength weakness analysis.

4)

The [PESTEL, Portfolio Analysis, Generic strategies] and the [Five Forces model, Portfolio Analysis, Generic Strategies, Internal Analysis] deliver the “threats

5.7 Review Questions for Chapter 5 | 285

and opportunities” from the outside while [Five Forces model, Portfolio Analysis, Generic Strategies, Internal Analysis] shows strength and weaknesses of the company itself. The results might simply be put together in a SWOT analysis. 5)

The [Five Forces model, Portfolio Analysis, Generic Strategies, Internal Analysis] will answer two questions: Does the company want to serve the whole industry/a broad market or rather focus on a niche? And does the company want to be very different and unique to its customers, or rather, act as mass producer with unbeatable cost and prices?

5.7.7 Choose: Business Strategy and IT Strategy Please choose which IT strategy fits best for a) small niche player that sells highly specialized items with unique technology or b) a mass producer and cost leader: 1)

IT-System with high flexibility to serve special customer needs

2)

Variety of different industry standards to incorporate all suppliers that fit our business

3)

High transaction systems

4)

Standardization of interfaces and processes

5)

Zero defect and zero downtimes with high performance

6)

Following biggest industry standard

7)

Outsourcing standard tasks to a cheap provider

8)

Outsourcing to obtain best in class knowledge.

5.7.8 Choose: Strategic and Operative Questions of IT Management Please mark all strategic questions of IS: 1)

In what areas and how far do we want to standardize “Information Systems” and its hardware? How do we cope with the trend of “consumeration”, that means people bringing their own devices?

2)

How much should we pay specialized IT staff?

3)

What parts and how “far” do we want to outsource IS and according services.

4)

How do we organize and govern multinational and global IT structures of a multinational or global player?

5)

What backup concepts would suit our applications well?

6)

Should we update the operating system to the newest version or wait until some teething problems are straightened out?

7)

What projects will be prioritized in the IS project portfolio?

286 | 5 IT-Management

5.7.9 Close: IT Strategy Written Down in an IT Strategy Paper Fill the gaps in the headlines of this IT strategy paper: 1.

Management summary

2.

Goals and framework conditions

3.

[Environment analysis, IS diagnosis and evaluation, Description of sub strategies, IS sourcing concept, Guidelines for IS security and IS risk policy, Applications architecture, Project portfolio] 3.1. Internal aspects (business model) 3.2. External aspects (competitive analyses) 3.3. Technology aspects

4.

Actual analysis and IS diagnosis 4.1. Methodical approach and results 4.1.1. Situation analysis 4.1.2. SWOT analysis 4.2. [Environment analysis, IS diagnosis and evaluation, Description of sub strategies, IS sourcing concept, Guidelines for IS security and IS risk policy, Applications architecture, Project portfolio] 4.2.1. Professional evaluation 4.2.2. Technical evaluation 4.2.3. Organizational evaluation (IS organization)

5.

Fundamentals and standards for the IS (IS principles)

6.

[Environment analysis, IS diagnosis and evaluation, Description of sub strategies, IS sourcing concept, Guidelines for IS security and IS risk policy, Applications architecture, Project portfolio] 6.1. Permitted basic systems of IS 6.2. Organizational positioning of IS (E-Governance) 6.3. Methods and approach in requirements management 6.4. IS service strategy 6.5. IS personnel strategy 6.6. [IS sourcing concept, Environment analysis, IS diagnosis and evaluation, Description of sub strategies, Applications architecture, Project portfolio] 6.7. Methodology and approaching models for IS projects 6.8. Concept for the IS quality management and quality assurance 6.9. Guidelines for IS security and IS risk policy

5.7 Review Questions for Chapter 5 | 287

7.

Recommendations for IS architectures (IS architecture concept) 7.1. Technology architecture 7.2. [Environment analysis, IS diagnosis and evaluation, Description of sub strategies, IS sourcing concept, Guidelines for IS security and IS risk policy, Applications architecture, Project portfolio] 7.3. Personal architecture (professional concepts) 7.4. Organization (processes, structures etc.) 7.5. Security architecture

8.

Proposal planning 8.1. [Environment analysis, IS diagnosis and evaluation, Description of sub strategies, IS sourcing concept, Guidelines for IS security and IS risk policy, Applications architecture, Project portfolio] 8.2. Economic evaluation 8.3. Project budgeting

5.7.10 Choose: Customer Supplier Relationships Between Business and IT Please assign the persons/words to their appropriate place in the figure. Customer Organization

IT Organization IT Customer Relationship Management

Strategic

Tactical Operational

Business Manager

a)

IT Management

Budget holders

b)

Service Level Management

Policy

c) Department Managers Project Managers Users

Demand

1)

Change Requests

2)

Support

3)

Service Levels

4)

Strategic Alignment

d)

Change Management Incident Management Service Desk Production

Supply

Repoting

288 | 5 IT-Management

5.7.11 Choose: Benefits of the ITIL Framework Check six answers that describe benefits using the ITIL framework: 1)

The provision of IT services becomes more customer-focused and agreements about service quality improve the relationship.

2)

ITIL is quickly introduced and easily adopted without further organization.

3)

The services are described better, in customer language, and in more appropriate detail.

4)

The quality, availability, reliability and cost of the services are managed better.

5)

ITIL reduces bureaucracy, paperwork and reporting.

6)

ITIL can be left to specialists and does not need to involve all members of the IT service.

7)

Communication with the IT-organization is improved by agreeing on the points of contact.

8)

The IT organization develops a clearer structure, becomes more efficient and more focused on the corporate objectives.

9)

The IT organization is more in control of the infrastructure and services it has responsibility for, and changes become easier to manage.

10) There is no additional investment in training and tools necessary for ITIL

5.7.12 Close: Components of ITIL 3.0 Framework Please assign the terms to their appropriate place in the figure.

5.7 Review Questions for Chapter 5 | 289

Continual Service Improvement

a)

Service Design

b)

c)

Financial Management

IT Service Continuity Management

Knowledge Management

Incident Management

The 7-Step Improvement Process

d)

Availability Management

Change Management

Access Management

h)

Demand Management

Service Capacity Management

Asset and Configuration Management

Event Management

Measurement

Strategy generation

e)

Transition Planning Management

Request Fulfillment

Business Questions for CSI

Service Catalogue Management

f)

g)

ROI for CSI

Information Security management

Service Validation and Testing

Supplier management

Evaluation

1)

Service Operation

2)

Release and Deployment Management

3)

Service Reporting

4)

Service Portfolio Management

5)

Service Strategy

6)

Service Transition

7)

Service Level Management

8)

Problem Management

5.7.13 Close: Substructure and Chapters of Single ITIL Processes For each gap, please choose the correct word to complete the sentence: 1)

KPIs for controlling, evaluation and optimization are to be found in the chapter “[Basic Policies, Processes, Organization and Roles, Tools and Technology, Metrics]”

290 | 5 IT-Management

2)

Principles and best practices are to be found in the chapter “[Basic Policies, Processes, Organization and Roles, Tools and Technology, Metrics]”.

3)

Useful templates, databases, portfolios and supporting software for the administration of the service are to be found in the chapter “[Basic Policies, Processes, Organization and Roles, Tools and Technology, Metrics]”.

4)

Purposes, scope, value to businesses, policies and advice, input, output and interfaces of this service, and the question “How can availability management be designed?” are to be found in the chapter “[Basic Policies, Processes, Organization and Roles, Tools and Technology, Metrics]”.

5)

Determining who does what, and who has what rights, is to be found in the chapter “[Basic Policies, Processes, Organization and Roles, Tools and Technology, Metrics]”.

5.7.14 Choose: Responsibilities of the Service Capacity Management Please check four responsibilities of capacity management: 1)

Ensuring disaster recovery and business continuity in case of disaster.

2)

Ensuring that current and future IT capacity needs are met.

3)

Deciding on the level of quality of a service and the associated cost.

4)

Monitoring the performance of the IT infrastructure.

5)

Drawing up capacity plans associated with the agreed levels of service.

6)

Recording which services are offered right now, which will be introduced in the future and which have been discontinued in the past.

7)

Making acquired capacity secure against external and internal attacks.

8)

Managing and rationalizing demand for IT services.

5.7.15 Choose: Responsibilities of the ITIL Service Process of Incident Management Please check six responsibilities of incident management: 1)

Identifying incidents

2)

Logging incidents

3)

Ensuring request fulfillments

4)

Categorizing incidents

5)

Test and deploy incidents

6)

Resolving incidents and problems

7)

Prioritization of incidents

5.7 Review Questions for Chapter 5 | 291

8)

Managing access to services

9)

Escalation of incidents

10) Investigation and diagnosis of incidents.

5.7.16 Close: Processes and Tasks in Service Transition Please choose which ITIL service these tasks belong to: 1)

Set up of transition strategy is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management]

2)

Preparing the test environment is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management]

3)

Creating service simulations and pilots is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management]

4)

Planning and preparation for deployment is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management]

5)

Early Life Support (ELS) is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management]

6)

Planning and coordination of Service Transition is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management]

7)

Planning and design testing is a task of [Service validation and Testing, Transition Planning and Support, Release and Deployment management].

5.7.17 Choose: Benefits of Good Change Management Please check the benefits of good change management: 1)

Fewer changes are reversed, and any back-outs that are implemented proceed more smoothly.

2)

With Change Management, change procedures do not have to be carried out completely.

3)

Enhanced management information is obtained about changes, which enables a better diagnosis of problem areas.

4)

Change Management can be introduced without additional communication, because its advantages are self-evident.

5)

Improved IT personnel productivity, as they are not distracted from their planned work by urgent changes or back-out procedures.

292 | 5 IT-Management

6)

Increased ability to accommodate frequent changes without creating an unstable IT environment.

7)

Change Management can be started without prerequisites, because it is not dependent on any other ITIL processes.

5.7.18 Choose: Basic Steps of a CM Process Please assign the words to their positions in the figure. Create RFC Change proposal (optional) a) Initiator

requested b)

Change Management

ready for evaluation c) ready for decision

Authorize Change proposal

d) Change Authority

authorized e)

Change Management

scheduled f)

Change Management Evaluation report

implemented g) closed

1)

Plan Updates

2)

Record RFC

3)

Review RFC

4)

Assess and evaluate change

5)

Review and close Change record

5.7 Review Questions for Chapter 5 | 293

6)

Authorize Change

7)

Coordinate change implementation

5.7.19 Close: Institutions of Change Management For each gap, please choose the correct word to complete the sentence: 1)

The change is raised by a request from the [Change Initiator, Change Advisory Board, Change Manager, the Authorization], an individual or organizational group that requires the change. For example, this may be a business unit that requires additional facilities, or problem management staff instigating an error resolution from many other sources.

2)

Modern ITIL interpretations talk neutrally of the [Change Initiator, Change Advisory Board, Change Manager, Authorization] that will finally decide on the change and might vary for different levels of risk/impact of changes.

3)

The [Change Initiator, Change Advisory Board, Change Manager, the Authorization] is a consultative body that meets regularly to assess, prioritize and plan changes and always includes the [Change Initiator, Change Manager, the Authorization]. Its size and members might vary with the size of the company and the IT-organization.

4)

The [Change initiator, Change Advisory Board, Change Manager, the Authorization] is responsible for filtering, accepting and classifying all Requests for Change (RFC). In a large organization, she may be supported by Change Coordinators who represent her by liaising with the various areas of the organization.

5.7.20 Close: Authorization of Changes For each gap, please choose the correct word to complete the sentence: 1)

High cost/risk changes should be authorized by the [business executive board, local authorization, IT management board, CAB or ECAB, Change Manager].

2)

Standard changes should be authorized by the [business executive board, local authorization, IT management board, CAB or ECAB, Change Manager].

3)

Changes that affect only one service group should be authorized by the [business executive board, local authorization, IT management board, CAB or ECAB, Change Manager].

294 | 5 IT-Management

4)

Changes that impact multiple services or divisions should be authorized by the [business executive board, local authorization, IT management board, CAB or ECAB, Change Manager].

5)

Low risk changes should be authorized by the [business executive board, local authorization, IT management board, CAB or ECAB, Change Manager].

5.7.21 Choose: Contents of a Newly Raised Request for Change (RFC) Please check all information that should be contained in a newly raised RFC: 1)

Identification number of the RFC.

2)

Description and identification of relevant configuration items (CIs).

3)

Actual cost of implementation.

4)

Reason for the change, including justification and business benefit.

5)

Date of Implementation.

6)

Name, location, email, telephone number of the person submitting the RFC.

7)

Assigned priority.

8)

Submission date.

5.7.22 Choose: Change Management: Metrics and Controlling Please check 5 KPIs that inform about the performance of change management and not just about the current situation of the organization. 1)

The number of changes completed per time unit, by category

2)

Number of changes implemented in a period (overall and per CI category)

3)

Rate at which changes arc implemented

4)

Number of incidents resulting from changes

5)

List of the causes of changes and RFCs

6)

Number of successfully implemented changes

7)

Number of back outs as percentage of changes

8)

Number of changes within resource and time estimation

5.7 Review Questions for Chapter 5 | 295

5.7.23 Close: Interfaces of Change Management For each gap, please choose the correct word to complete the sentence: 1)

The process most closely connected to change management with several interfaces is [Configuration Management, Availability Management, Service Level Management, Release Management]. Change management can hardly be realized without it.

2)

[Configuration Management, Availability Management, Service Level Management, Release Management] is another closely connected process that depends mainly on the result of change management.

3)

[Problem management, Availability management, Service Level Management, Release Management] has a two sided relationship with change management: it can be the initiator of changes, but also be affected and triggered by changes.

5.7.24 Choose: Operative and Strategic Tools of Controlling Please check four tools that are considered primarily for strategic IS controlling: 1)

SWOT analysis of IT

2)

Internal cost calculation and pricing of IT services to other departments and products

3)

Key performance indicators (KPIs)

4)

Benchmarking to learn industry best practises

5)

Capital investment calculation, capital budgeting to decide about investing in new services

6)

Portfolio analysis

7)

IT balanced scorecard.

5.7.25 Close: IT Project Portfolio Please give a basic suggestion for these projects according to the position project portfolio.

296 | 5 IT-Management

high

P1 P3

P7

P2

Return on Investment P5

P4

P6

low low

Probability of realization

high

1)

P7: [Re-evaluate project risk and find ways to handle the risk, Realize project now with high priority, Do not realize the project and abandon idea, Reevaluate project RoI and find ways to make it more profitable by balancing requirements and resources]

2)

P6: [Re-evaluate project risk and find ways to handle the risk, Realize project now with high priority, Do not realize the project and abandon idea, Reevaluate project RoI and find ways to make it more profitable by balancing requirements and resources]

3)

P1: [Re-evaluate project risk and find ways to handle the risk, Realize project now with high priority, Do not realize the project and abandon idea, Reevaluate project RoI and find ways to make it more profitable by balancing requirements and resources]

4)

P2: [Re-evaluate project risk and find ways to handle the risk, Realize project now with high priority, Do not realize the project and abandon idea, Reevaluate project RoI and find ways to make it more profitable by balancing requirements and resources]

5)

P5: [Re-evaluate project risk and find ways to handle the risk, Realize project now with high priority, Do not realize the project and abandon idea, Reevaluate project RoI and find ways to make it more profitable by balancing requirements and resources]

5.8 Suggestions for Written Exercise or Groupwork for Chapter 5 | 297

5.7.26 Choose: Characteristics of Good KPIs Please check all appropriate characteristics of a good KPI. A good KPI should always be … 1)

... transparent for staff and management

2)

... able to be influenced by and controllable by the responsible persons

3)

… ISO 9000 standard

4)

… taken from direct competitors

5)

… measurable with real numbers

6)

… accessible on demand at any time

7)

... easily available without too much cost to get the numbers

8)

… dependent on other KPIs

9)

… accepted by staff and management.

5.8 Suggestions for Written Exercise or Groupwork for Chapter 5 5.8.1 ITIL Process of Problem Management Mailorder Specialist “Screws Supplies LTD” is selling all kinds of standard screws via catalogue, Webshop and e-procurement connections to customers. They have 600 employees and 300 Million € turnover. Their business model depends heavily on IT. Describe the ITIL process of “Problem Management” in the stage of “Service Operation”. Follow the structure used in this chapter to describe “Change Management”. This can be easily researched on the web. Please cite the material you use correctly and use real life examples from the case above. Please no abstract copy of ITIL publications or web!

5.8.2 IS Governance and Strategy – –

Describe in short how IT is governed in your company, or any other organization you know. Use the structure and terms shown in the learning object. Describe in short how the IT strategy of your company, or any other organization you know. Use the structure and terms of this chapter.

If you have not worked in a company, use your university or any other organization of which you know something.

6 Planning and Preparing IS Development The last chapter dealt with managing IT once it is up and running. But how do ITsystems come into existence and how are they created? This chapter will deal with two aspects:  What approaches can be applied to manage the creation of Information Systems?  What tools and methods will be used during the first parts of the development cycle? How can the creation of IS be planned and prepared? After this chapter you should be able to …  … describe the software development cycle for standard software and individual software and its key elements.  … describe classical process models and judge their suitability for certain kinds of IS development.  … evaluate the criticism of the agile movement against the Waterfall Model and describe the radically different approach and its tools embodied in the agile SCRUM method.  … convert technical characteristics of an IS to organizational impact and to financial impact, distinguishing full value and incremental approaches.  … construct a business case spreadsheet for a NPV based financial evaluation of an IS project.  … distinguish the different forms of outsourcing and translate general cost and benefit of outsourcing for an actual outsourcing decision.  … decide on a real outsourcing scenario and create a raw draft of an SLA.  … organize a basic requirement engineering process.  … prepare a rough requirements specification document describing functional and non-functional requirements professionally.  … describe the process of vendor selection and the tasks of its single steps.  … create a scoring-model for an actual vendor selection decision.  … explain important parts to be covered by a contract with a vendor of standard software like ERP.

6.1 The Software Development Cycle The previous chapters dealt with questions of using IS and managing existing IS. This chapter and chapter 7 will describe important steps in creating and introducing IS.

300 | 6 Planning and Preparing IS Development

Of course, this will cover a very heterogeneous field: creating IS can reach from creating a big ERP within the company to programming a small change (see change management in chapter 5.3.3) in an interface between the ERP system and the web shop. We will take the broadest and widest approach to cover all questions of IS creation a non-software specialist, like a mechanical engineer, might be confronted with. In any case, a company should adhere to some kind of theoretical support to structure its IS projects, or in a broader sense, its IS ventures. Attempting to create IS without a process model and a clear structure is a recipe for disaster. Failed software projects often indicate a chaotic approach without sound conceptual support as the main reason for failure. However, in everyday practice of software creation, process models are not always valued, but rather evaded by calling them too theoretical, bureaucratic and unfit for “real life”. The opposite is true: process models offer not only a working plan how to do things, but also tools and practical best practice examples from which a company can benefit. When confronted with criticism of being too “theoretical and impractical”, you should reply that thinking will help to lead practical processes to success and improve the ROCE. Another problem is time for process models being used coherently and thoroughly. Planning and structuring the processes that shall later be supported by IS is often undervalued. Management wants to see results and grows impatient if programmers and IT specialists “waste” their time on structuring and thinking. This impatience of internal customers or management is sometimes called the WISCY problem/syndrome, an acronym for “Why Isn’t Someone Coding Yet?”, when seeing the IT specialists drawing process maps and not typing program code. This first chapter will focus on the overall process that will be used to structure this and the next chapter. You will learn about some older and some newer process models, what they do have in common, and what separates them from each other. Process models that deal not yet with “real” IS, but with the how to create and introduce information systems are relevant for two reasons:  Each process model suggests several tools and procedures for every step. This supports practical everyday work and might help getting software better developed and introduced.  Some of those models differ considerably in their approach and their philosophy. The decision of which way to follow and what “language” to use is of strategic interest for IS, since the company and its software vendors must agree on certain procedures.

6.1 The Software Development Cycle | 301

6.1.1 Basic Cycle of Software Development The models may differ, but they all contain certain steps and are considered to be cyclic. The end of development and implementation is the beginning of maintenance and possible improvement that might lead to new development and implementation. The following figure shows the basic cycle; its steps will reappear in several actual process models further down this chapter. Understand the business problem or opportunity

Systems investigation Product: Feasibility study systems

System operations will lead into a maintenance cycle that will deliver the need and opportunity to the next iteration of system investigation Maintenance cycle Develop an Information system (IS) solution

System analysis Product: System requirements

• Analyze in detail the information needs of end users, the organizational environment, and any system presently used • Develop the logical input, processing, output, storage and control

System design Product: System specifications

• Develop Specifications for the hardware (machines and media), software (programs and procedures), people (specialists and end users), data resources, and information products that will satisfy the information needs of end users

Systems Implementation Product: New system

• Acquire (or develop) and install hardware and software • Test and document the system • Train people to operate and use the system

Testing cycle

Implement IS solution

• Determine whether a business problem or opportunity exists • Conduct a feasibility study to determine whether plan is feasible

Systems operative maintenance Product: Upgrades/revisions

• Convert to the new system • Use a post implementation review process to monitor, evaluate, and modify the system as needed

Fig. 6.1: Generic Software Development Cycle (SDLC) (Motiwalla/Thompson (2012), p. 114)

This very basic and generic model has to be differentiated in several ways. First, its actual shape in companies depends on how severe or big the change or introduction of an IS will be. It also will look different whether we are talking about buying and installing so-called standard software or letting individual software be programmed.

302 | 6 Planning and Preparing IS Development

In academics about IS, there used to be a strict separation between “off the shelf” standard software, that is just bought and installed on one side, and individually (internal or externally) programmed software on the other. Specifically, ERP systems as a customizable standard software claim a different life cycle. The following figure shows basic differences between the classical SDLC and the ERP life cycle Table 6.1: Comparing and Contrasting SDLC with ERP-LC (Based on Thompson/Motiwalla 2012, p.128)

SDLC

ERP Life Cycle

Goal

Develop a new system to support the organization requirements

Implement a packaged system to support the organization requirements

Analysis

Evaluate user needs through observations and interviews and create system specifications

Vendor analysis and evaluation of business process changes due to the implementation

Design

Develop new system architecture, user interface, and reporting tools

Installation and Customization plan of ERP software, data conversion, and change management strategies

Implementation

Acquire hardware, software, develop applications, installation, testing, training, and conversion

“Go-Live” conversion or releasing the system to the users, training, and support

Consultant Role

Technical support mainly during design and implementation

Change management, process change, and technical support from beginning to end

Management Role

Some oversight and support

Significant oversight and involvement especially in change management

End-User Role

Focus group providing input during various stages with most involvement during Implementation stage

Multiple groups such as SMEs, advance users, and self-service users are part of implementation team with continuous involvement

Operations

Maintains, updates, and provides technical support

Maintains, updates, upgrades, monitors change management strategy

6.1 The Software Development Cycle | 303

While it is good to know about those differences, we do not focus too tightly on this distinction in our further investigation for two reasons: 1. Most software solutions cannot easily be attributed to one or the other. SAP or other ERP systems seem to be standard software. However, there is so much customizing and additional programming necessary. 2. The software matters only in part. It is important to see the whole project of introducing it; that means especially getting the organization ready. So, we will confine this to neither individual software development, nor a customized ERP system nor an unaltered “off the shelf” system. Rather, a very broad model of IS development will be presented and several of its steps will be detailed. Some of these steps will be more important in choosing a vendor, others in programming individual software. It’s up to you and the situations you might encounter in your company to choose the right tools and use them according to your individual case.

6.1.2 A Broad Model of IS-Development Before describing existing process models for software development, a very broad model will be introduced. It aims to envelop all the steps that all other actual process models know and will be suited only for very large projects in its entirety, like introducing an ERP system. This model closely resembles the Waterfall Model in chapter 6.1.3.1, but is not restrained by its very strict order of steps. It serves to illustrate the important elements in the software development cycle. The actual process models described further below will use several elements. Even if your company and the software provider cannot agree on a single “official” process model, you might still want to use methods and instruments suggested for single steps like, for example, “Requirements Engineering”.

304 | 6 Planning and Preparing IS Development

Feasibility+ Strategy Business plan Requirement specification

Validation

Requirements workshop/interviews

Requirements analysis Validation Raw systems design

Specification bid Design documents

Important documents, that also serve as legal base and milestones for project plan

Search for Vendors with specification as base Contract negotiations

Validation

Screen and data design Validation

Design workshops Test meeting and optimization

Programming (Coding)

Code + test logs Test documents

Organizationinternally and with external providers/ vendors

Strategy workshop

Unit-Test

Training plan Cutover Planning Operation concepts

Systems Integration Application test Implementation User Test Operations Monitoring

Fig. 6.2: A Broad Model of Information System Development and Introduction

The broad model consists of several steps that have a logical order. Each step is carried out by the organization in a certain way and will also produce documents. Each step also should have built in some internal validation or test-mechanism in order to produce good quality in each step.  The strategy and feasibility step will evaluate whether investing in new or improved software will improve the long-term value of the organization. It might be validated by an external consultant or another department within the company.  Requirements analysis will document what functions and other characteristics the company and its stakeholders want from the software. It can be validated according to the rules described in the chapter about requirements.  A vendor or the internal IT department will sketch a raw systems design for how to realize the requirements with certain software, and make an offer. This bid will be verified by legal and technical staff in the company.

6.1 The Software Development Cycle | 305











After closing the contract, the customer and the internal or external provider will sit down and design the details of the software, like screens and necessary data structure. For big ERP Systems, this is the phase of planning for customizing. Prototypes or automatic checking programs will verify whether this is workable at all. The coding or setting customizing parameters will be verified by built-in test. These tests will just check whether the code was correct in syntax and that the isolated modules produce correct output. Once the modules and parts are integrated to form the desired information system, an integration test will be conducted. Inputs and outputs are defined in test cases and are compared with real outputs of end to end processes. Implementation means that the new system is now at work and real users, who are not specialized in IT, work with the system. Only if they find the system to work as designed, might the implementation be called a success. Finally, the everyday operations pick up and are monitored with the tools and organization that are described in the chapter about IT management.

There is, of course, a certain order to these steps; however, in the broad model, the steps are more important than their strict order or a strict rule, that only if the previous step is validated the next might be started. Also, there are two important backward loops:  If the detailed screen and data design does not work out, the requirements must be reconsidered.  If the integration test fails, it’s not the coding that must be fixed, but the detailed design documents that laid the base for coding. Each step should produce some “paper” or some tangible results. The business plan, requirements document and the bid from the vendor serve as a base for legal matters and internal decision making. The same is true for the documents in later steps. The approval test documents and/or the training plan also serve as milestones in the project plan. This and the next chapter will be structured by the elements of this broad model. Before the steps are described in further detail, we will have a closer look at actual process models suggested in theory and used in practice to see how the generic SDLC is actualized in several different ways.

6.1.3 “Classical” Approaches of Structuring Software Development In this chapter, we will take a short look at the so-called “classical” approaches for how to structure the endeavour of creating software. These are the first models that were consolidated and published to a broader community in the 70s and 80s. There

306 | 6 Planning and Preparing IS Development

were several attempts from single companies to define a process for themselves, and also, consultants and large software companies suggest new process models even today. This area is not driven by academic systematization, but rather by practical craft, and that is the reason why the models seem similar, and yet different, and why the terms are not always used in a consistent way. We will have a closer look at the Waterfall Model, the Spiral Model and the Rational Unified Process (RUP). There is another classical model that will not be discussed in detail further down: the so called “V-model” is the standard procedure that governmental customers in Germany require their vendors to follow in order to be eligible at all. 5 Please research the term “V-model” on the web or Wikipedia for further information.

6.1.3.1 The Waterfall Model The Waterfall Model was introduced as a deliberately strict process that was to end former “chaotic” planning and programming of software. It was first introduced by Herbert D. Benington in 1956, but only gained wider publication and acceptance by 1983. It derives its name from the typical cascading order of steps. Requirements definition System and software design Implementation and unit testing Integration and system testing Operations and Maintenance

Fig. 6.3: The Waterfall Modell (Based on Sommerville (2011), p. 30)

Sommerville describes the different stages as follows: 

Requirements definition: Refines project goals into defined functions and operation of the intended application. Analyses end-user information needs.

6.1 The Software Development Cycle | 307



   

Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation. Implementation: The real code is written here and tested in a unit test. Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. Maintenance: What happens during the rest of the software’s life: changes, correction, additions, moves to a different computing platform and more. The least glamorous and perhaps most important step of all will then lead to the initiation of a new waterfall/improvement. Sommerville (2011), p. 30ff

One core feature of the Waterfall Model is the strict advice that each stage must be passed by a validation before proceeding to the next step. If this is not successful, you must step back to the previous stage. For example, the collected software requirements must be validated by future users or experts before the phase of “Software Plans & Requirements” can be considered successfully closed and move on to the next phase of product design. Also, integration of a system might only be considered successful if integration tests confirm that the whole business process is working with support of the software. This is, of course, a higher level than simply summing up isolated successful unit tests. A validation or test for each phase needs to be passed before the organization shall move on to the next stage. The Waterfall Model is considered simple and easy to use. Every phase has specific deliverables and a built-in review process, which makes it easy to manage and clear cut. Phases of this model are processed and concluded one at a time and one after another without parallelization. This model is best used for smaller projects, in which requirements are very well understood. On the other side, the model has some limitations: especially uncertainty and changes in scope during the life cycle can delay or kill a project. This model is best used if the organization knows exactly what it wants and will not be open to many changes. It is not fit for a volatile, fast changing environment and for complex, long, ongoing and object-oriented projects. Also no running, visible software is produced until late during the life cycle, which might be discouraging and allows misunderstandings to be unresolved deep into the late phases. Please refer to the web or any book about software development to find out detailed advantages 5 and disadvantages of this model, and where it is suited or unsuited to successfully introduce software.

308 | 6 Planning and Preparing IS Development

6.1.3.2 Spiral Model and Prototyping The Spiral Model seeks to solve one severe weakness of the Waterfall Model: the strict, linear “one final step after another” approach. The one dimensional approach of the waterfall in which time and progress of creating software are seen as identical does not seem realistic. Often, not all information needed is immediately at hand and can only be retrieved once the users have worked on a real prototype. Then, iteratively new objectives are found and they have to be realized and tested. So the following four basic phases will be repeated several times: 1. Determining the objects 2. Identifying and resolving risks 3. Developing and testing and 4. Planning the next iteration Cumulative Cost 1. Determine Objectives

2. Identify and resolve risk

Progress Riskanalysis Requirements Plan

Review

Riskanalysis

Prototype 1

Concept of Concept of Opera- Requiretions ments

Riskanalysis

Prototype 2 Draft

4. Plan the next iteration

Release

Detailed Design Code

Development Plan Test Plan

Operational Prototype

Verification & Validation Implementation

Integration Test 3. Development and Test

Fig. 6.4: The Spiral Model (Based on http://leansoftwareengineering.com/wp-content/uploads/2008/05/spiral_model_ boehm_1988.png)

6.1 The Software Development Cycle | 309

1.

2. 3. 4.

Before real programming and implementation starts, concepts of requirements and operations need to be defined quite similarly to the Waterfall Model. In the next step, the objectives are defined and an actual requirements plan is created. This requirements plan will be evaluated and risks need to be assessed and minimized. Prime tools for doing this are simulations and creating prototypes. After the risks are identified and solved, a product version is created. New knowledge and new requirements from creating the product leads to planning the next iteration in which risks are again assessed.

With each iteration, the product improves and ripens, until finally, the product will be released. This spiral will be extended for further releases, if necessary. An important feature in the Spiral Model, besides iterating the waterfall elements, is the use of prototypes. They play an important role in many modern process models, so we will have a quick look at different types of prototypes here:  Explorative Prototyping will deliver an overview of the specification and whether the functionalities are feasible.  Evolutionary Prototyping delivers a program with basic functionalities and is used to let the users try and evaluate it and give feedback to the programmers. During improvement, the product is kept running, until ultimately, the finished product emerges.  Experimental prototyping is used to gather experiences and try out different solutions in a real program.  Vertical Prototyping delivers a certain part of the system with all levels, like database, function, presentation. Especially if some parts are not yet specified, the vertical prototypes can be put to work.  Horizontal Prototyping is exactly the other way round. It finishes one level, e. g. the graphical user interface (GUI) completely in all parts of the software, while layers below might not yet be finished. Prototyping is a method used in several process models. Especially the so called AGILE approaches in chapter 6.1.4 use prototyping very intensely.

6.1.3.3 Rational Unified Process (RUP) The RUP is also shaped as two dimensional: it separates single phases of a software project or software creation just as you already know from the Waterfall Model. The phases are actually on a timeline and follow one another. In each phase, there are several disciplines to be fulfilled. Some will be more strongly emphasized and will use up more resources in certain phases than in others. E. g. analysis and design will peak in the beginning, but will recur to a certain extent in all phases.

310 | 6 Planning and Preparing IS Development

Phases

Disciplines

Interception

Elaboration

Construction

Transition

Business Modelling Requirements Analysis & Design Implementation Test Deployment

Initial

E1

E2

C1

C2

C3

T1

T2

Iterations

Fig. 6.5: The Rational Unified Process (RUP) (Based on http://www.ibm.com/developerworks/webservices/library/ws-soa-term2)

The phases are a logical sequence of events:  During inception, the basic goals and strategies for the software are conceived. Technical feasibility, different options and a financial calculation will tell whether the project will be pursued further.  In the elaboration phase, the requirements should be known in detail, so that 80 % of the use cases are defined. Possible vendors are screened and a detailed planning of the project is executed. There already might be prototypes used at this point and the basic architecture should be decided, e. g. which operating systems.  The phase of construction sees the real programming and customizing of the software and integrating of new hardware. The software also needs to be tested thoroughly a) in single modules and b) interacting with each other to support a whole business process.  Transition hands over the software to the internal or external customer. Also, cutover and start of operation can be assigned to this phase.

6.1 The Software Development Cycle | 311

The disciplines might be needed in different phases to a varying degree: Business modelling explains how to describe the organization in which the system will be installed, and how to outline the process, roles and responsibilities. Understanding the business means that software engineers understand structure and dynamics of the client, the current problems in the organization, and possible improvements. Requirements Engineering transforms stakeholder requests into a set of requirements for the system, how it is built and what it will do. Design and analysis serves as an abstraction of the source code. It acts as a ‘blueprint’ for how the source code is structured and written. It needs to be able to translate the requirements and the given situation of the organization into software code. Systems are realized through the implementation of components. The process describes how to reuse existing components, or implement new components with well-defined responsibility, making the system easier to maintain and increasing the possibilities to reuse. In short: this is programming and testing individual modules. The purpose of testing is to assess product quality. This not only involves the final product, but also begins early in the project with the assessment of the architecture and continues through all other phases, as the figure shows. The purpose of deployment is to successfully produce product releases, and to deliver the software to its end users. It covers a wide range of activities, including producing external releases of the software, packaging the software and business application, distributing the software, installing the software, and providing help and assistance to users. Not graphically represented in the figure are the so-called support disciplines that only indirectly 3 add value to the application development. Nevertheless, they are necessary to ensure good functioning of the disciplines in each phase described above. Support disciplines are: configuration and change management, project management and environmental analysis. Please consult the web for further details, e. g.: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpracti ces_TP026B.pdf.

So, the RUP, like the Spiral Model, detaches actual tasks (disciplines) from project phases, which makes it more flexible than the Waterfall Model.

6.1.4 Agile Concepts As seen in the previous chapter, several improvements to the original Waterfall Model have been made in a rather evolutionary way. In the history of process mod-

312 | 6 Planning and Preparing IS Development

els, however, there is also a revolutionary point that has made a lasting impression on company practice. Let’s call it the “agile revolution”. The following chapters will shortly show the basic creed of the agile movement, the impact on business practice and show the dominant process model that evolved out of agile principles, called SCRUM.

6.1.4.1 Criticism Against Traditional Process Models and the Agile Manifesto In 2001, several authors and specialists in the field of software creation launched a full attack on the traditional process models described in chapter 6.1.3 and their use as a base of developer-customer relationship and contracts. Traditional methods/ process models, especially the Waterfall Model, were criticized in many aspects. To name just a few:  Tools are too bureaucratic  Too focused on documents and formalities  In most real situations, not all requirements are known before the start of programming  Changes are not the exception, but rather the rule in everyday programming and the old methods cannot cope with this  The ultimate goal of delivering visible value to customers seems to be subservient to preparing formalities. There is also empirical evidence that projects managed following the Waterfall Model are less successful than those governed by more flexible, “agile” methods. The authors of the “agile manifesto” deliberately chose a dramatic language, like that of a revolutionary pamphlet, to clearly convey their point and to emphasize that there could be no compromise between the old and the new. The base of the new creed was formulated in four basic values that are clearly directed against the traditional methods: “Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan” http://agilemanifesto.org

Based on these basic values, 12 principles of how to organize software development were defined: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

6.1 The Software Development Cycle | 313

Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly” http://agilemanifesto.org

Of course, as in every revolution, there is reaction and criticism from various perspectives. To name just a few:  Agile principles without a clear structure and discipline might lead back to the chaotic times before the use of the Waterfall Model  Just using agile methods does not heal all problems in software development  The strong opposition against “old models” is too exaggerated: traditional models can incorporate agile methods, and this has already been done successfully. As can be seen in the next chapter, software development in many companies has be transformed by following these new principles.

6.1.4.2 Use of Agile Methods in Business Today Since agile principles have made such a lasting impression on software development in companies, it has also become an object of research. For example, the following numbers and figures are taken from an annual survey about the use of agile methods. http://www.versionone.com/state_of_agile_development_survey/2011/ First of all, agile has established itself firmly: 68 % of the over 6.000 respondents know about agile methods, and 60 % of the respondents say up to a half of their projects are managed by agile methods. The following chapter will take a quick look at the reasons and perceived benefits of using agile methods and techniques and also concerns against using agile methods. Reasons for adopting agile methods are mainly in accelerating time to market and managing changes that result from changing priorities.

314 | 6 Planning and Preparing IS Development

Accelerate time-to-market Manage changing priorities Increase productivity Better align IT/Business Enhance software quality Project visibility Reduce risk Simplify development process

24

9

10 15

Improve team morale

12 14

Improve/increase engineering discipline

Somewhat Important

39

26

48

23 42

18

46

16

35

14

38

39

11

36

40

10

36

9

37

40 45

15

42

33

14

Manage distributed teams

Not important at All

31 33

5

Reduce cost

Enhance software…

26

9

29

51

17

5

37

46

3 14 3

39

38

18

5

29

Very Important

21

5

Highest Importance

Fig. 6.6: Reasons for Adopting Agile (Data based on VersionOne (2011), p. 6)

Agile concepts and agile methodology need to be packaged in a consistent concept, since “agile” just sets the basic values and principles, but does not tell exactly how to organize programming. There are several agile process models, but one is clearly dominant: SCRUM or SCRUM variants make up more than two-thirds of the methodologies being used in practise. Also very popular are custom methods or scrum hybrides.

6.1 The Software Development Cycle | 315

Others 8% Don´t Know 9% Custom Hybrid 10% Scrum 58% Scrum/XP Hybrid 15%

Fig. 6.7: Agile Methodology Used (Data based on VersionOne (2011), p. 4)

The tools and techniques employed are partly explained in the following paragraphs. If you are interested in details, please consult a book about Scrum or agile technologies or research the terms on the web; they are very well documented. Some of the elements used by the SCRUM model will be explained in the next chapter.

316 | 6 Planning and Preparing IS Development

Daily standup

78%

Iteration planning

74%

Unit testing

70%

Release planning

65%

Burndown

64%

Retrospectives

64%

Continuous integration

54%

Automated builds

53%

Velocity

52%

Coding standards

51%

Refactoring

48%

Test-driven development TDD

38%

Open workarea

38%

Story mapping

35%

Digital taskboard

32%

Pair programming

30%

Collective code ownership

28%

Automated acceptance testing

25%

Kanban

24%

Onsite customer

24%

Continuos deployment

24%

Analog taskboard

22%

Agile games Cycle time Behavior-driven development BDD

15% 12% 9%

Fig. 6.8: Agile Techniques Employed (Data based on VersionOne (2011), p. 4)

Agile was largely welcomed by the management and by the IT. However, like with every concept, there are also limitations and barriers. The following figure shows barriers to further Agile adoption:

6.1 The Software Development Cycle | 317

Ability to change organizational culture

52%

Availability of personnel with right skills

40%

General resistance to change

39%

Management support

34%

Project complexity

30%

Confidence in ability to scale

27%

Customer collaboration

26%

Perceived time to transition

14%

Budget constraints

14%

None

12%

Fig. 6.9: Barriers to Further Agile Adoption (Data based on VersionOne (2011), p. 5)

The following figure shows the greatest concerns about adopting Agile in the first place, and reveals general concerns about using agile methods. Lack of up-front planning

33% 33%

Loss of management control Management opposition

32%

Lack of documentation

30%

Lack of predictability

28%

Lack of engineering discipline

25%

Dev team opposed to change Quality of engeneering talent Reduced software quality

23% 16% 15%

Regulatory compliance

14%

Inability to scale

14%

No concerns

14%

Fig. 6.10: Concerns Against Adopting Agile Methodology (Data based on VersionOne (2011), p. 5)

After all – agile methods seem to have lived up to the rather high expectations: 64 % of the respondents say that they accelerated time to completion in their projects and virtually no respondent felt they were being slowed down by it. The following figure shows the benefits obtained from implementing agile.

318 | 6 Planning and Preparing IS Development Ability to manage changing priorities

6%

84%

Improved project visibility

77%

5%

Increase productivity

75%

11%

Improved team morale

72%

Faster time-to-market

13% 15%

71%

Better alignment between IT & Business…

68%

17%

Enhanced software quality

68%

17%

Simplify development process

68%

16%

65%

19%

Reduce risk Improved/increased engineering discipline Enhance software… Reduce cost Manage distributed teams

Got better

Not benefit

62%

21%

60%

23%

49%

28%

41%

35%

Got Worse

Don´t Know

Fig. 6.11: Benefits Obtained Implementing Agile (Data based on VersionOne (2011), p. 7)

To summarize: Agile has itself established well and does seem to fulfil the expectations.

6.1.4.3 The Dominant Agile Process Model: Scrum In all surveys, SCRUM or SCRUM-hybrid methods have been shown to be the dominant process model of the agile world. Other methods, like Extreme Programming (XP) or Kanban (not to be confused with Kanban in Logistics, though related), can be easily researched in web encyclopaedias. In this chapter, we shall explain SCRUM in further detail. The following figure shows the basic process of software creation according to the Scrum method.

6.1 The Software Development Cycle | 319

Daily

Daily Scrum

Burndown Chart

Scrum Master

Sprints

Product Owner

Sprint Backlog

Sprint Review

Sprint Planning Product Backlog

Sprint Retrospective

Fig. 6.12: Elements and Process of Scrum, the leading Agile Model

The Product Owner first tells all the stories and features the system should be able to support in the end. Of course, he/she will find new features after the first release of the software, so this is open for evolution in further iterations. The stories and features are stored in the Product Backlog. Some of the stories and features are packaged into a Release Backlog. This release backlog might again be split into one or more Sprint Backlogs. In a Sprint, all the features in the then unchangeable sprint backlog will be worked on comprehensively. Sprints typically last 20 or 30 days. The Scrum Master is a kind of project manager who ensures the programmers have all they need and are working together. He also organizes meetings and reports programming progress. Every day, the team gathers for a stand-up meeting that should not last longer than 15 minutes and is called the Daily Scrum. In this meeting, the programmers report what they have done, what obstacles they perceived while working on their backlog, and what they will do until the next Daily Scrum. The basic reporting tool during a sprint is the so-called Burndown Chart. It shows, on a time scale, the number of features left in the current Sprint. The progress so far allows the Scrum Master to measure productivity and to forecast the features not yet programmed at the end of the sprint.

320 | 6 Planning and Preparing IS Development

At the end of the Sprint, the new features are presented to the product owner in a prototype. If it is the last sprint of a release, it will be deployed and implemented. A Sprint Retrospective gathers the lessons learned and gives ideas for improvement for the next sprint. Since many Agile and Scrum supporters are keen to get the “gospel” of Agile out, there are many good tutorials and advertisements for Scrum tools on the web, for example here: http://youtu.be/XU0llRltyFM The dominant tool of project controlling in scrum is the so-called burndownchart of features and user stories realized so far in a sprint. With extrapolation, it also forecasts where the sprint will end up, meaning how many features will be realized at the end of the sprint? The following figure shows a commercial product that helps in visualizing the progress. My sprint 1: Hours left to do

Hours 600

Original estimation Left scope 500 Burn-down extrapolation

400

Extrapolation deviation with 95% probability

300 Variable team size supported

200 Change request 100

Scope of changes in hours

23. May

22. May

21. May

20. May

19. May

16. May

15. May

13.May

14. May

12.May

8. May

7.May

5. May

Work dates of sprint

6. May

4.May

30. Apr

29. Apr

28. Apr

0

Work days

Initial estimation Overall scope in hours 95 % extrapolation sector

Fig. 6.13: Burndown Chart as SCRUM Reporting Tool

Scrum has gained wide recognition in daily business and programming. It will not cover all steps of our broad model of software development, and is rather tightly focused on programming and delivering value quickly to the customer. Agile meth-

6.2 Business Plan and Outsourcing Decision | 321

ods have also been introduced into testing and other steps of the software development cycle and will play an important role in the next few years.

6.2 Business Plan and Outsourcing Decision In the “broad model”, there is a step of basic strategic decision that should answer the question: Should we build or renew a certain IS at all? Is it worth it? A rational decision should be based on facts and figures, and not on fads (“everybody now has a PDM”) or whims (“I just feel a new CRM system will help us boost sales”). So, there is the need to gather and describe all information about positive and negative impacts of a solution, try to convert them into financial data, and put this data into an evaluation model (like NPV) to get a sound base for the decision. This will be called a business case and the document and calculation in which the business case is documented is called a business plan. At first sight, it seems surprising that decisions about making or buying (= inhouse solution or outsourcing) is placed in this strategic phase, too. However, as you will see, this basic decision will have a strong impact on the business case and strategic issues, and therefore, cannot be separated from the basic decision of whether to invest in this IS at all.

6.2.1 The Business Plan – is it Worth it? While writing the business plan upfront, not all information will be available: especially the data gained from Requirements Engineering (see chapter 6.3); the vendor offer (see chapter 6.4.3) will deliver more exact data than a-priori assumptions. However, in practice, the basic decision about whether to do a larger software project (like introducing an ERP system) usually needs approval from the management board. This, in turn, can only be achieved by presenting them with a compelling business plan, in which the technical and organizational impact are translated into monetary values, and ultimately, in impact on profits and return on capital (see chapter 1.1.5.3). The main medium of this communication with management is called a business plan. This is a piece of financial calculation of the overall impact for the business case, in a spreadsheet and text backup, to justify and explain each line that will find its way into the calculation.

322 | 6 Planning and Preparing IS Development

Like all stages of our broad model introduced in chapter 6.1.2, the work invested into this phase needs to fit the actual needs. Introducing a big ERP system, like SAP, deserves a more detailed business plan than deciding about programming a little interface. As always, in this course, we assume a big kind of decision to make all the details and the whole range of available tools visible. So, please imagine the following descriptions in this chapter for creating a business case for something big like introducing or changing an ERP system. This chapter will give a guideline and some hints on how to write, or at least how to read, a business plan. If you are responsible for writing the business plan yourself, please research the sources cited here more thoroughly. According to Marchewka (2012, p. 41), a good business plan should have the following characteristics:  It details all possible impacts, costs, and benefits  It clearly compares alternatives  It objectively includes all pertinent information  It is systematic in terms of summarizing findings. In order to reach these goals, the following process has been suggested by Marchewka 2012 (p. 42).

6.2 Business Plan and Outsourcing Decision | 323

Select core team ( See right below here in chapter “The Business Plan-Is it worth it?”)

Identify alternatives

(See chapter “Determining Feasibility and Data Sources of Alternatives”)

Define measurable organizational value (See chapter “Converting Technical and Organizational Impact into Financials”)

Define feasibility

Define total cost of ownership

(See chapter “Determining Feasibility and Data Sources of Alternatives”)

Define total benefits of ownership

(See chapter “Writing the Business Case and Using Evaluation Tools)”

Analyze alternatives (See chapter “Writing the Business Case and Using Evaluation Tools”)

Propose & support recommendation (See chapter “Writing the Business Case and Using Evaluation Tools”) Fig. 6.14: Process of the Strategy Phase – Feasibility and Business Plan (Based on Marchewka (2012), p. 42)

The following steps will be explained in the next three chapters. First we will clarify why it is important to gather a “core team” to build the business case. This core team might contain important members of the organization and the project team that will later be in charge for realizing the project. According to Marchewka (2012, p. 43), there are several advantages of employing a core team:  Credibility: A team made up of individuals from various departments can provide access to expertise and information that may not be readily accessible to others outside that particular area. In any case, it will give credibility if the head of mechanical design will be involved in creating the business case for a new CAD system.

324 | 6 Planning and Preparing IS Development 







Alignment with organizational goals: Higher-level managers connect the business case with the organization's long-term strategic plan. The business case should outline how the successful completion of the proposed project will help the organization achieve its overall mission, goals, and objectives. Access to the real cost information: Core members with certain expertise or access to important information can help build more realistic estimates in areas such as salaries, overhead, accounting and reporting practices, training requirements, union rules and regulations, and hiring practices. Ownership: A cross-functional team can spread a sense of ownership for the business case and reduce the political problems associated with territorial domains. Agreement: A business case created in isolation will need more defending of assumptions and subjective judgments. However, if a core team develops the business case, the critics may be more apt to argue the results, rather than the data and methods used. If critics are involved early and can be convinced, there will be fewer attacks later on in the decision about the case.

6.2.1.1 Converting Technical and Organizational Impact into Financials The most difficult task is to convert real world impacts of an IS into financial terms. The chain of logic usually consists of four steps: 1. The system will have a certain function or characteristic, e. g. our new CAD program will have an automatic export filter to another system. 2. This leads to a real life impact: e. g. we do have less work redrawing designs. 3. This leads to a measurable non-financial improvement: e. g. the number of drawings generated in our design department increases with the same people working there (increase of efficiency). 4. This leads to a financial improvement: e. g. we do not have to pay an additional person to do the redrawing and thus have a decrease in cost. Since cost is only one aspect of financial improvements next to revenues or capital employed, a more overarching financial measure, that comprises all financials, needs to be used In many books about the measurement of IS success, the term ROI is used, which basically means: “What return does the investment in a new system yield?” Since the term and formula ROI is tightly associated with measures already expressed in monetary terms, e. g. like “cost of software license” and “less maintenance cost”, it seems too restricted for our purposes. We will rather go with the more thorough term of MOV (Measurable Organizational Impact). Before something is converted into financials, it must pass the following MOV test according to Marchewka 2012, p. 43:

6.2 Business Plan and Outsourcing Decision | 325

“Be measurable – Measurement provides focus for the project team in terms of its actions. Instead of implementing an Information System, the project team attempts to achieve a specific Performance target. Moreover, an MOV provides a basis for making decisions that affect the project through its remaining phases. Why do additional work or make decisions that affect the project if they do not help you achieve the MOV? Provide value to the Organization – Resources and time should not be devoted to a project unless they provide some kind of value to the Organization. Keep in mind that Information technology in itself cannot provide value. Technology is only an enabler – that is, IT enables organizations to do things. Be agreed upon – A clear and agreed upon MOV sets expectations for the project stakeholders. It is important that all project stakeholders understand and agree to the projects MOV. It is not easy to get everyone to agree to the projects goal so early; but it will be well worth the time and effort in the later stages of the project. Verifiable – At the end of the project, the MOV must be verified to determine if the project was a success.”

So, how can an organization in general profit from an IS and its features? Organizational value can be derived in the following ways for the example of a new CAD system:  Better: The new CAD software might enable a flawless export of design, increasing the quality.  Faster: The new CAD software might enable us to deliver proposals faster to our potential customers and thus increase revenue.  Cheaper: The new CAD software causes less maintenance cost than the old one.  Do more: The new CAD software now allows us to work together with new customers that would otherwise not invite us for concurrent engineering because our systems used to be incompatible. These different kinds of advantages (better, faster, cheaper, more) might show up in different areas:

326 | 6 Planning and Preparing IS Development

Table 6.2: Potential Areas of Impact (Based on Marchewka (2012), p. 45) Potential Area

Example of Desired Impact

Strategic

  

Penetration of new markets Transformation of the terms of competition within the market Increased market share

Customer

 

Customers have more choices of products or services Customers receive better products or services

Financial

 

Increased profit Increased margins

Operational

  

Lower costs due to streamlined operations Increased operational effectives Improvements to supply chain

Social

   

Education Health Safety Environment

Keep in mind that there might also be some negative impact, which must not be forgotten if detected. For example, the new CAD system might require a different (higher) knowledge and will increase training cost. There are several complications and challenges in converting organizational advantages into financials: First, a decision is needed on the final model that will be calculated (like in chapter 6.2.1.3). Of course, the final evaluation tool will influence the values and metrics that need to be investigated. Since we will use a net present value (NPV) method in the end, we do need cash-flow relevant data and a required internal rate of return (often called “hurdle rate”). We do not need any information about depreciation in an NPV calculation. This is only important if we would choose a cost comparison as the final method of evaluation. Also, there are a lot of assumptions to be made, since we might not know all requirements about the software and perhaps do not have all information about the vendor. We also need to make predictions, and therefore, we need to make the underlying assumptions explicit: e. g. we assume that exporting to PDF’s will be sufficient for export options and that PDF remains the standard for document exchange. Also, we need to make simplifications, e. g. if we do not treat the knowledge of all our mechanical designers individually, but rather separate them into two groups: one that will not require additional training and one that will need it, and thus caus-

6.2 Business Plan and Outsourcing Decision | 327

ing additional cost. Every assumption needs to be recorded in detail – nothing should be taken for granted or as self-evident. Every business case also needs to define its boundaries and its scope. Very important for the NPV method is the time span calculated; are we assuming the new software will last for 5 years or for 10 years? Are the numbers we are deriving for a specific division or the whole company? What are we leaving out in the business plan because we take it for granted and it is not affected by our decision, like the existing network infrastructure and the backup system? What will be the required interest rate of return of the company for the NPV (“hurdle rate”)? One of the most difficult aspects is the question of how to compare different systems that will leave many numbers unchanged and only change some parameters, like replacing old CAD software with new CAD software. For example, a new system enables three standard drawings per person and day, and the old system enables one standard drawing per person and day. If a drawing yields 100 €, how will you evaluate the advantage of choosing a new system? There are basically two ways to handle this: the full value approach and the incremental value approach.  The full value approach compares the values completely and thus right into the financial calculation in a line “revenues”: for the old system, 100€ per day and person, and for the new system, 300€ per day and person.  The incremental value approach will only take the increase or the decrease and only needs one spreadsheet for the new system. The old system will not be calculated, it rather sets the base for measuring improvements (or deteriorations). There, you would find a line name “revenue increase” with 200€. “Business as usual” is not calculated, but serves just as the offset point for incremental change in cost and revenues. The following figure shows the difference between the two approaches. Please note that we exemplify one year only for three alternatives and with two different approaches. Table 6.3: Full Value Approach (Close to Schmidt 2003, p. 12) Full Value approach Example for one year (2015) IT Operating Gains/revenues IT Operating Costs IT Investment/acquisition cost Net Gain (Loss)

New CAD “Solidus” New CAD “Auteska” 210 T€ 160 T€ −130 T€ −90 T€ −30 T€

−40 T€

50 T€

30 T€

Our Old CAD System 110 T€ −100 T€

10 T€

328 | 6 Planning and Preparing IS Development

The full value approach is straightforward: the benefits are entered with a plus, the running cost with a minus, and any one-time investments with a minus, as well. The sum will be called the net gain of the respective alternative. This is done for all alternatives. Table 6.4: Incremental Approach (Close to Schmidt 2003, p. 12) Incremental approach Example for one year (2015) IT Operating Gains/revenues IT Operating Costs IT Investment/aquisition cost Net Gain (Loss)

New CAD “Solidus” 100 T€ −30 T€ −30 T€ 40 T€

New CAD “Auteska” 50 T€ 10 T€ −40 T€ 20 T€

The incremental approach does not start with zero, but with the existing solution right away. Here, this will be the old CAD system and all values are measured against this starting point. So, only incremental values will be entered. They are the result of the new alternative Solidus minus the starting level of the old solution. Don’t get confused with the minus signs. If the new CAD system will cause operating cost of 130 T€ (entered as minus 130) and the old solution causes operating cost of 110 T€ (entered as minus 110) – then the new solution will lead to incremental operating cost of an additional 20 T€, thus being entered as minus 20. This is done for all positions, then summarized and repeated for all alternatives. Both approaches lead to the same conclusion and are equally valid. However, in calculating the value of an IT investment, the incremental approach is often preferred. First, it is closer to typical investment considerations: “What will we get out, if we invest amount x?” Second, many systems changes lead only to little change compared to the huge rest of the numbers that simply stay the same. So, in a full value approach, the small changes would be masked by the big numbers unchanged and at first view. Choosing a new system would hardly show a difference (Schmidt 2003, p. 13). However, the incremental approach has its challenges, like many business plans in practice show:  Mixing incremental and full value in the same calculation. This makes the results meaningless. If choosing an incremental approach, each line of cost and revenues has to be checked in its relationship to the “business as usual – do nothing” alternative. Only the difference to this alternative counts and is recorded.  Sometimes plus and minus signs might be confused. In the above example, our old system cost 110 T€ and the new AUTESKA cost 100 T€, so the cost will shrink by 10 T€, entered with a + sign. Remember: only the difference counts.

6.2 Business Plan and Outsourcing Decision | 329



So, an incremental approach requires absolute clear rules and discipline in creating the spreadsheet. Productivity gains can only be converted into real cash if the resources no longer needed are really eliminated off the payroll. In the example above, the work of 4 draftsmen can now be done by 2 draftsmen. You may only count the decreased personnel cost as an increase in cash if you fire two of them or put them into an entirely different department in a world “outside” your business case. Do you want this? Maybe not – but then you will have no cash savings, and incrementally spoken: no cash increase.

For more details of the problems of the preferred incremental approach, see Schmidt 2003, p. 6 ff.

6.2.1.2 Determining Feasibility and Data Sources of Alternatives There are always alternatives to introducing a new system. For example, an important customer asks us to switch to a new 3D CAD system (preferably Solidus or Auteska). If we won’t change our system, he demands a price reduction in order to make up for his higher expenditure. His extra expenditure might be caused by dealing with our old system and interface problems in the common development of components. There are several alternatives in this situation the company might choose from:  Introduce new CAD software Solidus as asked.  Introduce new CAD software Auteska as asked.  Introduce new CAD software from another vendor.  Write an interface/interpreter ourselves and do not introduce new CAD Software.  Do not change system and give the rebate he asked for.  Do nothing and do not give him a rebate, accepting the risk of losing the customer. Each of these options is a valid alternative; however, some might be more profitable than others. A valid alternative in the sense above is one that is feasible at all in the first place. We will not undergo the cumbersome work of writing a business plan for options that are simply impossible. Marchewka (2012, p. 49f) lists several kinds of feasibility.  Economic feasibility: Although a cost/benefit analysis will be conducted to look at the alternatives in greater depth, some alternatives may be too costly or simply not provide the benefits envisioned. This can be just a rough estimate, since most of the time we do not have all information from the vendor and from

330 | 6 Planning and Preparing IS Development







Requirements Engineering. So, an alternative should be clearly economically unfeasible in order to sort it out right in this step. Technical feasibility focuses on the existing technical infrastructure needed to support the IT solution. Will the current infrastructure support the alternative? Does the current IT staff have the skills and experience to support the proposed solution? Is the new technology needed available to us at all? If not – will we be able to fill these gaps at all? Organizational feasibility considers the impact on the organization. It focuses mainly on how people within the organization will adapt to the planned change. How will people and the way they do their jobs be impacted? Will they accept this change willingly? Will business be disrupted while the proposed solution is implemented? Other feasibilities – Depending on the situation and the organization, a business case may include other issues, such as legal and ethical feasibility.

Be careful not to dismiss an option too easily just because it seems unusual or difficult to enforce; otherwise you will limit your choices needlessly. For each feasible alternative, the according data has to be retrieved since an evaluation should be based on facts and figures. The source of the data should be recorded very clearly. Possible sources of financial and non-financial information include, according to Schmidt (2003, p. 16):  Other business plans  Budget (historical, current, or future)  Spending record or other historical information  Vendor proposal  Feasibility study  Pilot project  Outside consultant’s estimate  Published industry average, benchmark, or “best-in-class” figure. 3 Business case professionals, like consultants, often reserve one column of their calculation spread sheet just for entering the sources for the numbers of each line. If you are in charge of a business plan and do not cite a source for a certain number, it might be automatically interpreted like this: “The number is the personal opinion or gut feeling of the author”.

It is not advisable to offer only one scenario of the future and just give one definite number. The future is uncertain and this influences the forecasted impacts. However, neither does it make sense to assume a large number of possible developments to each single line (cost/revenue) in the business plan. The compromise is thinking in scenarios. E.g. we assume three scenarios: one with our best guess (real case), one in a pessimistic view (worst case) and one with an optimistic view (best case), and

6.2 Business Plan and Outsourcing Decision | 331

find a value for an item (e. g. “cost reduction through improved communications”) for each of the three scenarios.

6.2.1.3 Writing the Business Case and Using Evaluation Tools After all information has been gathered and transformed in financial terms as far as possible, the business plan needs to be put together. In very simple cases, there might be no need for a full size business case, for example, if no big initial investments are needed. We might, for example, just upgrade our CAD software to a newer version and pay a little more for the license fee. Here, a simple cost comparison or break even model might do. If you tell your boss that your department needs a new CAD system, she will most likely ask you for a “business-plan” or a “calculation” before she will decide about it. However, there is no absolute rule about what is meant and expected by creating a “business plan”. Some might just want the financial spreadsheet described below, while some will expect detailed text as well; so it is advisable to ask for a template or an existing business plan to get a feeling for the level of details expected by the decider. As always, we take the broadest approach and the biggest size and fit, e. g. for a new ERP system. On this large scale, a business case comprises the following blocks and chapters.

332 | 6 Planning and Preparing IS Development

Table 6.5: Suggested Outline for Developing and Writing a Business Case (Marchewka (2012), p. 57) Cover Page

  

Title and subtitle Author and address Date

Executive Summary

  

Brief description of the problem or opportunity Brief description of organization’s goal and strategy Brief description of projects MOV and how it ties to the organizational goal and strategy Brief description of each option or alternative analysed Brief explanation of which alternative is being recommended and why

  Introduction

     

Background Current situation Description of the problem or opportunity Projects measurable organizational value How achieving the projects MOV will support the organizations goal and strategy Objectives of writing this business case

Alternatives

  

Description of alternative 1 (Base Case) Description of alternative 2 Description of alternative N

Analysis of Alternatives

         

Methodology of how alternatives will be analysed Data collection methods Metrics used and explanation of why they are relevant Presentation of results that compares each alternative Metrics Sensitivity analyses Risks Assumptions Proposed recommendation Required funding and support

The chapters described in the overview of the table above are the verbal preparation of what is finally put into numbers and will be evaluated with the tools described below. There are many examples, templates and books on how to write a good business plan. We will not go into detail on how to write a good text for a business plan, but rather focus on figures.

6.2.1.3.1 Construction of a Business Plan Sheet At the heart of the financial calculation, there is a spread sheet with the cash flow impact of alternatives. The method of choice is clearly a net present value (NPV) approach. That means the impact of the decision on software is forecasted over

6.2 Business Plan and Outsourcing Decision | 333

several years, and later, cash surplus or deficit in each year is discounted by a certain interest rate. So there are basically three “vertical” parts in the construction of a business plan sheet:  Total benefit of ownership that will result in cash inflow (or less cash outflow): Most of these benefits are yearly benefits that might not kick in immediately, but will rise in the course of the ownership.  Total cost of ownership (TCO) that will result in (higher) cash outflow: TCO consists of visible and invisible cost. Part of it will be one time cost, precisely called “investment”, that includes capital expenditure, like buying the software and hardware. Some cost will be recurrent. Since all cash in and cash out positions will be included, it is wrong to take any “amortisation” or other non-cash relevant figures into account. Also, “theoretical” savings, like time-efficiency of staff that is not actually reduced (fired) will not result in less cash outflow. It, therefore, should be left out of the calculation.  Finally, the yearly cash surplus, or deficit, from the positions above needs to be “discounted”. Money in the future is worth less than money now. The discount factor for each year is calculated by the formula: 1/(1+i)y where i is the interest rate the investment must reach (given from controlling and finance) and y is the amount of years away from today. Example: if it is now 2015 and we are calculating the discount factor for 2018, y will be “3”. If you are not familiar with the NPV method, please research it yourself, e. g. in any book about 5 financials.

The following business plan chooses the incremental method described in chapter 6.2.1.1. It is compressed to just a few typical cost and benefit types. Each line is used to illustrate some typical mechanics of a business plan, especially the use of parameters/factors to automate the development of some positions.

334 | 6 Planning and Preparing IS Development A 1 Alle numbers compared to 2014 2 Cash in (sum of lines below)

B 2015

C 2016

D 2017

E 2018

F 2019

420.000 € 436.000 € 512.120 € 518.362 € 524.730 €

3 Sell off old equipment

50.000 €

4 Improvement of quality

20.000 €

80.000 € 150.000 € 150.000 € 150.000 €

5 Decreased maintanance cost

50.000 €

50.000 €

50.000 €

50.000 €

50.000 €

6 Additional business for drawings 300.000 € 306.000 € 312.120 € 318.362 € 324.730 € 7 Cash Out (sum of lines below)

680.000 € 100.000 € 80.000 €

8 New CAD software and hardware

500.000 €

9 Training for new system

100.000 €

20.000 €

10 additional cost of labour

80.000 €

80.000 €

80.000 €

60.000 €

2 days

2 days

2 days

2 days

2 days

40.000 €

40.000 €

40.000 €

40.000 €

40.000 €

days

1 days

2 days

3 days

4 days

11 additional people 12 salary of additional draftsmen 13 Cash Surplus/ Deficit 14

(undiscounted) per year

15 Discount factor Discounted Cash Flow 16 (DCF) per year

G Param.

2%

60.000 € 115.000 €

H Notes

50.000 €

Vendor offer

5.000 € 60.000 €

0%

Training over 2 years. Refresher Vendor offer after 4 years formula: people x salary draftsm. Thru experience 1,5 can do the estimation head of work for 2 design we assume a 5 % rate of formula: inflation in salary last year + inflation

-260.000 € 336.000 € 432.120 € 458.362 € 409.730 € 1,00

0,87

0,76

0,66

0,57

-260.000 € 292.174 € 326.745 € 301.381 € 234.264 €

17 Discounted Cash Flow cumulative -260.000 € 32.174 €

358.919 € 660.299 € 894.564 €

I Source/ formula

formula: Sum of lines below Market Price used Old eqipment no longer needed Equipment In the beginning not everything Experience from head of will work out. design Numbers from our operators and contracts Business growth by 2% each Experience from earlier year once started. new businesses formula: Sum of lines below

cash in - cash out

15%

Hurdle rate (from finance) Future cash and debt is less worth as of today Shows the value of the investment so far

formula: 1/(1+interest) ^ year formula: undiscounted cashflow x discount factor formula: sum of all previous DCF per year

Fig. 6.15: Example of an Incremental Business Plan with NPV Financial Calculation

Let us go through the spreadsheet step by step, looking at different cell areas and clarifying the cash-in and cash out positions. (A3:A6) First, we will construct the grid, and later fill in the values. Let’s start with the incremental benefits that will bring cash in, like selling old equipment, improvement of quality, less maintenance cost and additional business. (A8:A9) The new system will have some initial cash outs, which shall be called investments, like new hard- and software and training. (A10:A12) The additional cost of labour will not be entered directly, but by multiplying additional people and the amount of their salary, including non-wage labour costs. This method is suggested whenever it is possible – enter numbers and prices separately and then multiply them. (A2+A7) For a quick overview, we add two summation lines: Cash in and Cash out that will sum up the lines below accordingly. (B1:BF) Since we want to calculate the NPV, we need numbers for the entire period covered. They will vary in time: there are one-time investments and recurring items that will change over the years. (G1:I1) We add three more columns; one for parameters we might use to calculate the dynamics of values over time, one for notes on the values and positions, and one for the source from which the numbers came. If a line, like a summation, is calculated automatically, the formula of the calculation is described there. (B3:F5) Now we start entering the values. The first three lines of cash outs are entered directly. Please note: the improvement of quality will not immediately kick in, but will take a while. This is a realistic assumption for new systems.

6.2 Business Plan and Outsourcing Decision | 335

(H3:I5) For each line, notes and explanations about assumptions will be added. Very important is the documentation of the source of information: who told us this number, where is it from? (B6:I6) The cash in by additional business is calculated with a parameter. We start off in the first year with 300.000 € additional revenue. Then the business is caching on and will increase each year by 2 %. So, each new value for a year is calculated by taking last year and adding 2 %. This parameter might later be varied in order to simulate different scenarios. (B2:I8) The values for the investments are derived from vendor offers and thus, entered directly. (B11:I12) The head of mechanical design told us how many additional people we need for the scenario. Their cost of labour is calculated with an inflation parameter of 5 %. Each year will be calculated by taking last year plus 5 %. (B10:I10) Finally, the additional cost of labour is calculated by multiplying cost per person times the persons needed. Now we are done with the base data. B2:I2+B7:I7+B13:F13 Now we sum up the cash inflow positions and the cash outflow positions. Cash in minus cash out will amount to our yearly cash surplus or cash deficit. A15:I15: As you know from financial management and calculating investments, cash in the future is not worth as much as cash now. So, we have to discount our yearly cash surplus with a factor that will be smaller with each year away from today according to the discount formula described above. A16:I16: Multiplying the pure yearly cash flow with the discount factor will deliver the discounted cash flow. It shows the value of future surpluses (or deficits) from the perspective of today. A16:I16: Since we want to know the entire value for the whole project, we will add up the discounted cash flows by cumulating them from year to year. This shows the total status of the investment up to the according year. The total value of the investment will be the accumulated discounted cash flow for all years up to 2019, which can be seen in cell F17.

6.2.1.3.2 Selecting Information to be Monetized for the Business Plan The concept of TCO (see chapter 1) gives a very broad sense of what cost could find their way into the spreadsheet. It also is a source of deriving benefits if some of these costs will be less in the alternative “new CAD system” compared to the business as usual scenario “keep old system”. But can all cost, and especially benefits, go into the business plan? Here, the business plan team needs to find a compromise between two extremes:  The purist approach: Only really hard facts that are already provable in financials go into the business plan. The danger here is to leave out too many hidden advantages.

336 | 6 Planning and Preparing IS Development 

The creative approach, on the other hand, tries to translate as many advantages into financials as possible. The danger here is to lose credibility and to seem too optimistic.

Two aspects of a parameter or value have to be considered when deciding about expressing it in cash terms or not: 1. First, determine the type of benefit and its believability: direct savings, like contractual cost reductions, are “hard” facts. Semi-direct savings, like expected reduction in cost, less so. Even softer are indirect savings, like “increase in staff productivity”, and finally, very indirect savings, like “more revenue caused by better image”, is highly speculative. 2. Second, the measurement strategy for the benefit matters: direct observation, pilot sites or historical data is quite good; case studies, benchmark data and expert guesses are a sufficient means of measurement; and vendor estimates and non-experts’ “gut feeling” is a poor measurement. The suggestion is:  Hard benefits with a good measurement should always be converted to cash positions and enter the financial calculation.  Speculative benefits with poor measurement should never be transformed to cash and be left out of the financial calculation.  Hard benefits with poor measurement or very soft benefits with good measurement need further consideration. The impacts that do not make it into the financial calculation will not be lost. Typically, they are put into a scoring model. The technique of the scoring model for comparing non-financial characteristics in a numeric way is explained in the vendor selection, since it plays such a vital role there. It could also be used here to compare the status quo (old system) to the proposed new solution.

6.2.1.3.3 Different Scenarios and Sensitivity Analysis As proposed above, it is not smart to just offer one possible future and one result for the NPV, but rather offer several alternatives futures. This can easily be done with changing the parameters and looking at the overall result of the total NPV. This is also called a sensitivity analysis. The following figure shows the impact on the total NPV (sum of all years or accumulation 2019) when playing around with the parameter, “slowdown of business”, while leaving all other parameters as they are.

6.2 Business Plan and Outsourcing Decision | 337

NPV 900 T€

800 T€

700 T€

600 T€ -2%

0%

+2%

+4%

+6%

Fig. 6.16: Simulating the NPV Impact of a Parameter Variance in the Business Plan

When getting the numbers, we were asking for different values for different scenarios. Now we will use them. The original value of our real case was estimated at +2 %; that means a business increase by 2 % each year. Starting from there, the parameter was varied two 2 % steps down and two 2 % steps up. For each entry, the NPV was recorded and all the combinations laid the base for the graph above. Not all variations produce linear curves – it depends on how the parameter affects the business case. Different scenarios can be produced if a whole set of parameters is entered and the total impact on the NPV is then recorded. Try it for yourself and produce two other scenarios with the Excel file for the business case above: 5 Worst case: Business growth: 6 % (decrease) and 10 %inflation of salaries should produce 692.248 € NPV Best case: Business growth: +2 % (growth) and no (0 %) inflation of salaries should produce 936.679 € NPV

Finally, all the verbal descriptions, technical explanations and financial calculations need to be integrated into a clear presentation and recommendation. In our case, it is safe to say: go for it! There is a clear positive NPV, even in our worst case scenario.

338 | 6 Planning and Preparing IS Development

6.2.2 A Basic Decision in the Strategy Phase: Outsourcing Like all other functions of a company, IT processes are subject to considerations about outsourcing. In order to get a deeper understanding of professional outsourcing, the following chapters will need to answer these questions:  What are the goals of outsourcing – and what exactly is meant by outsourcing? In reality, outsourcing comes in many variations and companies have many different goals that lead them to the conclusion that outsourcing might be good for them.  What are the means and methods of evaluating outsourcing? Outsourcing is a strategic decision and should be based on a rational decision process.  How should a successful outsourcing relationship be managed? The most important roles (next to personal ties) are good contracts, and notably, a document named the Service Level Agreement (SLA), which regulates the relationship between a customer and the outsourcing provider.

6.2.2.1 Goals and Forms of IT-Outsourcing The goals of outsourcing (in IT, as well as production) can be better understood when looking at recent history: many companies focused on growth in the 80s to reach economies of scale, and grew quite big and complex. This had several negative effects, against which outsourcing was seen as a cure: The product programs of companies grew very complex and this complexity led to growing administrative cost in all functions, e. g. purchasing and logistics. The idea, then, was to outsource big packages of the product (like modules in automotive industry) or corporate services to external companies to let them handle the complexity. Secondly, hiring permanent staff and buying automation equipment increased fixed cost while flattening the variable cost curve. This is good during growth, but dangerous during downturns, since the company might fall below the break-even point. Outsourcing makes some of this fixed cost variable again, and thus, lowers the break-even point. If the business declines, the outsourcing supplier is simply given less business. Finally, increasing competition forced companies to focus all their attention on things they really can do better than others. You cannot be all to everyone. Outsourcing non-core-activities of IS was one way of focusing on their real core activities and competencies.

6.2.2.1.1 Outsourcing of Information Systems Information systems and technologies are increasingly outsourced, as you can see in the following figure depicting the spending on IS by US companies. Roughly 35 %

6.2 Business Plan and Outsourcing Decision | 339

of the cost is spent outside the company and another 4 % is outsourced in the form of Software as a Service (SaaS), a special form of outsourcing that will be described later in this chapter. 300 Expenditures (billions $) 250 Total Software spend 200

150 Outsourced Software Expenditure 100

50

Software as a Service (SaaS)

0 1990

1992

1994

1996

1998

2000

2002

2004

2006

2008

2010

Fig. 6.17: Sources of Software (Based on Laudon/Laudon (2013), p. 223)

Of course, this is just an overall value and will vary in different industries. Financial services like banks and insurances do have a higher IT outsourcing quota, followed by telecommunication providers. Manufacturing companies that develop their own products or pharmaceutical companies are less likely to outsource, mostly for reasons of confidentiality. A company also has to carefully think about what is the best level and form of outsourcing for them as an individual organization. Despite the media hype about cloud computing and outsourcing in the early 2010s, the curve looks like it is flattening. Some also proclaim that the age of outsourcing is drawing to an end, as this article provocatively assumes: http://www.forbes.com/sites/ciocentral/2012/12/28/the-death-of-outsourcing-andother-it-management-trends/ No matter how the trend is: outsourcing has established itself very well in IT and is here to stay. So instead of speculating about the future of outsourcing, we’d rather concentrate on detailing different levels, forms and flavours of outsourcing.

340 | 6 Planning and Preparing IS Development

6.2.2.1.2 Different Levels of Outsourcing There are many dimensions by which outsourcing can be classified. The following figure shows three different levels of outsourcing and the different objects of outsourcing in each level. It was prepared by the global consulting firm Accenture, which played a major role in advising large corporations to outsource parts of their IT. Please note that the acronyms used in the following figure are used mainly by Accenture; other authors might name them differently. Outsourcing models:

Business processes

BPO: Business Process Outsourcing APO: Administrative Process Outsourcing

Administrative processes ASP: Application Service Provider Application development and maintenance

DBRO: Design, Build, Run&Operate ADM: Application Development & Maintenance

ITO: IT Infrastructure Outsourcing IT Infrastructure ITS: IT services, Managed Hosting

Fig. 6.18: Types of Outsourcing (Based on Accenture (2005), S. 6)

On the lowest level, there is outsourcing of the IT infrastructure. Two different parts might be outsourced: first, the hardware for the infrastructure itself might be outsourced, what is here called IT Infrastructure Outsourcing. The second part is the service for hardware, like running a service desk or hosting the infrastructure.

6.2 Business Plan and Outsourcing Decision | 341

On the level of application outsourcing, there are also different flavours. ADM is what you could call an external programmer: they create software for the company and will also deliver updates and maintenance of the application, for example, if an interface needs an update to communicate with another updated application. DBRO goes farther: the provider additionally runs and operates the software that was created under the guidance of the client. ASP is the most extreme form: here, the provider offers a readymade program and just lets the client use this program. Special client wishes are incorporated by adjusting certain parameters to customize the software. Process outsourcing gives away the complete process to a provider. Some companies have outsourced their entire customer service or accounting to a provider. Some of these processes are located in administration, some in core business. In the so-called exchange model, the outsourcing provider takes over equipment and staff from the customer’s company that is used for the process now to be outsourced. At this point, we shall focus more closely on the further development of ASP in the figure above. There has to be another phrase around called “utility outsourcing” that needs to be explained. Unlike ASP, with fixed pricing models and fixed plans that the provider will deliver, utility outsourcing comes with fully flexible scalability: if you need more database space, you just use it and pay as you go, without having to fix this in advance. This truly can be called “computing on demand”. ASP with good/infinite scalability close to the idea of utility outsourcing is known under the name of “Software as a Service” (SaaS). Unlike older ASP, Providers of SaaS always include the provider as also owning and operating the hardware. How does “Cloud Computing” – a buzzword of the 2010s – fit into this scheme? Basically, everything outside the company’s firewall is “in the cloud”. So, the cloud is rather a technical concept that describes having file space and computing power somewhere outside the company and connecting via the internet. Distinctively, three kinds of services are offered in the cloud today: Applications, Frameworks and Infrastructure:

342 | 6 Planning and Preparing IS Development

Frameworks offered in the cloud provide standards for collaborating with each other. For example “google app engine” provides the neutral application layer you know from the three tier system of client server computing in chapter 4.

Modern ASP is offered in the cloud because only there the scalability and flexibility expected from a modern “Software as a service” solution can be provided. The CRM system “Salesforce.com” is often quoted as the first and typical SaaS model. However today other traditional players like Microsoft also offer their applications in the way of software as a service as well.

Hardware services like storage, memory and computing power can be bought on the net in any amount as needed. For example rackspace.com offers databases or storage for any use at a certain price per month and gigabyte.

Fig. 6.19: Types of Cloud Services and Examples Based on http://webapps.stackexchange.com/questions/301/what-is-cloud-vs-saas-vs-asp

Frameworks offered in the cloud provide standards for collaborating with each other. For example, “google app engine” provides the neutral application layer you know from the three tier system of client server computing in chapter 4. Modern Applications Service Providing (ASP) is offered in the cloud because only there can the scalability and flexibility expected from a modern “Software as a Service” solution be provided. The CRM system “Salesforce.com” is often quoted as the first and typical SaaS model. However, today, other traditional players, like Microsoft, offer their software in the way of software as a service, as well. Hardware services like storage, memory and computing power can be bought on the net in any amount as needed. For example, Rackspace ™ offers databases or storage for any use at a certain price per month and gigabyte.

6.2.2.1.3 Advantages and Disadvantages of Outsourcing Outsourcing in various forms is a fact of modern IT organization. It might be beneficial, but nothing ever comes for free, so we also need to have a closer look at the

6.2 Business Plan and Outsourcing Decision | 343

possible disadvantages of outsourcing. The following table shows some advantages and disadvantages of outsourcing in different categories. Please note that the category “Human Resources” assumes a typical exchange model, in which company staff is transferred to the outsourcing company. Table 6.6: Advantages and Disadvantages of Outsourcing in Different Categories Advantages Outsourcing

Disadvantages/Risks Outsourcing

Cost

 Overall Cost reduction via economies of scale  Better planning possible  Improved cost transparency by detailed contracts

 Risk of negotiating wrong (too high) prices  If the contract is too rigid, it does not allow participating in cost digression  Misunderstandings about what is included in the cost and what is billed extra

Human Resources

 No more problems of getting IT professionals  Relieving internal IT from routine tasks  Cutting down IT staff without termination by transfer to the outsourcer

 Deterioration of labour relations  Difficult transfer of staff to outsourcer  Loss of personalized know-how  Remaining tasks not attractive/ motivating for remaining staff  Disruption in company climate and efficiency during the phase of transfer

Technology Know how

 Focus on core competencies  Access to state of the art technology  Access to state of the art knowhow  Documentation often better/more disciplined in outsourcing relationships

 Tied to the technology of the provider  Provider is too standardized, does not customize enough to our needs.  Loss of know-how to outsourcer  Diffusion of know-how to competitors if the provider is serving them as well

Risk

 Lower risk of technology oblivion  Risk reduction due to lower complexity in-house  Mitigation and transfer of risk to provider fixed by contract

 Strong dependency on provider  No direct, operative control into processes possible to react quickly  Long term commitment  Difficult to rebuild knowledge once lost  Risk of maintaining data security

344 | 6 Planning and Preparing IS Development

Since IT outsourcing has been around for at least 10 years, there are already many studies on the success of outsourcing. One of them showed the following reasons and experiences companies made with outsourcing (Deloitte 2005, p. 24):  70 % of the responding companies outsourced IT to decrease cost. 38 %, however, were confronted with hidden cost they considered already included in their contract with the provider.  57 % hoped to participate in best practices of the outsourcing provider. 31 % of the respondents complained that, after the contract was signed, the provider acted rather self-satisfied and was not driving innovation or propelling best practices.  35 % wanted more cost flexibility and scalability. In many cases, the flexibility was not improved since rather rigid contracts with the provider made it difficult to react to new requirements.  34 % outsourced seemingly non-core functions to focus on core competencies. However, a quarter admitted that they had outsourced some activities that proved to be an integrated part of their core competencies, which was not clear at that time.  Finally, for 22 %, access to highly qualified personnel was a reason for outsourcing. 20 % experienced that the base of knowledge they paid for was diminishing: the experts who were so impressive in selling the outsourcing contract were slowly replaced by other, less competent staff in the course of the outsourcing relationship. So, great effort should be put in evaluating and preparing the outsourcing decision to avoid disappointments like these.

6.2.2.2 Evaluating the Outsourcing Decision and Preparation Whether, how and whom to outsource needs to be based on a rational process. Basically there are two aspects: A strategic analysis and a financial calculation. First, it has to be decided what functions or IT services should be outsourced based on their individual characteristics. There are many portfolios suggested to support this decision and the following figure shows one example. Whether an IT service or an application is fit to be outsourced mainly depends on two parameters:  First, on the strategic significance of IT process or application concerning company strategy and core competencies.  Secondly, on individuality and uniqueness of IT process or application concerning company goals and core processes.

6.2 Business Plan and Outsourcing Decision | 345

high SAP CRM Strategic significance of IT process or application concerning company strategy and core competencies

Standard accounting software

User Service Desktop

Server administration

CAD with PDM integration

Conversion service for our old legacy system legacy

low low

Individuality and uniqueness of IT processes or application concerning company goals and core processes

high

Fig. 6.20: Portfolio for basic outsourcing decision (Based on Gaddatsch (2012), p. 145)

IT-services can be placed in this matrix according to their significance and uniqueness. For each area, there is a certain standard recommendation, which needs to be validated before taking action.  Services and application of low strategic significance and low individuality/uniqueness are prime targets for comprehensive outsourcing.  Services with neither both low nor both high significance and uniqueness are placed in a middle zone. They are subject to further consideration and analysis. Here, selective outsourcing is suggested.  Services and application of high strategic significance and high individuality/ uniqueness are not suited for outsourcing. Since a company should not give away services and applications of strategic importance, it will be difficult and costly to outsource due to their individuality anyway. When we have a first idea of what services might be suited for outsourcing, the question arises: Where should we go to outside our company? Before deciding what partner would be the right match for us, there is a more strategic question to be answered that will influence cost and quality considerably: How “far” away should we outsource? From the perspective of an US or European company, outsourcing farther away decreases the price, but comes at the cost of growing geographical and cultural distance. There are three different “zones” outside the company itself where the internal IT department or certain services might be outsourced:

346 | 6 Planning and Preparing IS Development 

  

The first step is chosen in many big corporations: the central IT department is transformed into its own company (legal unit) that has to sell its services to its sister companies. Outsourcing “off-site” gives the business to local service providers that are probably well known, but are not attached or owned by the cooperation. Near-shore means crossing borders to find a provider, but in the same wider cultural area. For a German company, this might be to Eastern Europe. Offshoring, e. g. to India usually offers unbeatable cheap prices and also good quality. However, the felt distance and cultural differences might decrease quality from a user perspective.

Finally, we are ready to find an actual partner for the services and in the areas chosen above. At this point, we will not dive too deeply into this question of choosing a supplier. This closely resembles the vendor selection that is described in chapter 6.4. After having all information and having chosen possible providers, a financial calculation needs to be conducted to find the best cost/benefit relations for us. Under the assumptions of getting the same benefit from an in-house solution and an outsourcing solution, the question boils down to: Where do we have less cost? Both for in house-solutions and outsourcing, it is difficult to retrieve the real cost, since some expenditures are hidden; see chapter 1 again for the TCO concept. The following figure follows the marketing claims of an outsourcer that offers a platform to let companies easily integrate their suppliers (www.supplyon.com) for various e-procurement solutions. The outsourcing provider makes a strong point on the danger of underestimating the cost of an in-house solution.

6.2 Business Plan and Outsourcing Decision | 347

Cost of inhouse solution Supporting suppliers (hotline, service desk training suppliers,…)

Support test suppliers, roll out concept Developing and implementing application Cost of external solution

Implementation BackendInterface

Adjustments to applications

Suppliers onboarding (getting them onto our system)

Hosting, further development incl. test, adjust training material, …

Cost easy to plan

Time

Cost difficult to plan

Usually underestimated cost

Marketplace flat fee all inclusive (includes Rollout, operations, improvements, test, …) B. End Adjustments Training of Buyer company and more…

Time

Fig. 6.21: Cost Comparison Inhouse vs. Outsourcing Based on Material by www.supplyon.com

At first sight, the costs are easy to plan: the development, introduction, test and adjustments is a onetime expenditure, while the fee for the provider must be paid monthly. So after some time, we will save cost if we create and run an in-house solution. Most companies will admit that an in-house solution will have some running cost for their solution, like hosting and further development. However, these are difficult to plan and might be underestimated. What most proponents of an in-house e-procurement solution frequently underestimate is the cost of getting new suppliers onto the system and especially supporting them with internal purchasing staff. This is the view of an outsourcing provider. On the other side, there is also hidden cost in an outsourcing solution that is sometimes not taken into account. Such hidden cost usually includes searching, selecting and evaluating the provider and the project of transferring the business to the provider. Further hidden expenditures are: making the company run with the outsourcing provider solution, the cost of proposing and negotiating a good contract, and managing and controlling the vendor/provider.

348 | 6 Planning and Preparing IS Development

To make things more difficult, these costs are subject to a high uncertainty. The following table focuses tightly on those hidden cost and estimates them in different scenarios of the specific form of outsourcing, “offshoring”. Table 6.7: Total Cost off Offshore Outsourcing (Based on Laudon/Laudon (2013), p. 543) Cost of outsourcing contract Hidden Costs

$ 10,000,000 Best Case Additional Cost ($)

Worst Case Additional Cost ($)

1. Vendor selection

0%

20,000

2%

200,000

2. Transition costs

2%

200,000

3%

300,000

3. Layoffs & retention

3%

300,000

5%

500,000

4. Lost productivity/Cultural issues

3%

300,000

27 %

2,700,000

5. Improving development processes

1%

100,000

10 %

1,000,000

6. Managing the contract Total additional costs

6%

600,000

10 %

1,000,000

1,520,000

Outstanding Contract ($)

Additional Cost ($)

5,700,000

Total Cost ($)

Additional Cost

Total cost of outsourcing (TCO) best case

10,000,000

1,520,000

11,520,000

15,2 %

Total cost of outsourcing (TCO) worst case

10,000,000

5,700,000

15,700,000

57,0 %

This table looks at the best and worst case scenarios for hidden costs in outsourcing.  The best case column shows the lowest estimates for additional cost,  The worst case reflects the highest estimates for this cost,  The sum of the column “Additional Cost”, at the lower right, shows a possible increase in cost up to 15 % to 57 % compared to pure contract cost. However, it is important to note, that even with these extra hidden costs, many firms will benefit from offshore outsourcing if they manage the outsourcing relationship well. The bottom line from the table above is summarized by Laudon/ Laudon 2012 on p. 523:

6.2 Business Plan and Outsourcing Decision | 349

“If a firm spends $ 10 million on offshore outsourcing contracts, that company will actually spend 15.2 percent in extra costs even under the best-case scenario. In the worst-case scenario, where there is a dramatic drop in productivity along with exceptionally high transition and layoff costs, a firm can expect to pay up to 57 percent in extra costs on top of the $ 10 million outlay for an offshore contract.”

There is one more addition to the calculation: cost and benefit are stretched over a longer period of time and they are asynchronous. Many one-time investments will occur at the start of outsourcing, while the benefits will appear at a later point, but each year. Whenever cost and benefit is unevenly stretched over time, there is the need to discount the results of future years. So it is advisable to execute a NPV calculation for an outsourcing decision like it is proposed in chapter 6.2.1.3. There are more analyses a company could apply on the question of outsourcing like risk analysis, but that must be left for your own research. There have been several good scientific studies and practical suggestions of how to handle this vital strategic question professionally.

6.2.2.3 Service Level Agreements as a Frame of Managing Outsourcing Relationships The central tool in managing the relationship to the outsourcer is the Service Level Agreement (SLA). SLAs are contracts or appendices to contracts that formally define the service a custom company will obtain from an outsourcing provider. As distinguished from material goods, where certain material characteristics and quantified performance numbers can easily be defined, it is not immediately clear what is meant by an offer like “providing a CAD conversion service” by a provider. This service has to be defined closely, so both parties are absolutely clear about what they give and get like they would with a contract about any material good. Originally, SLAs were first used in the telecommunication industry, but are now widely used in outsourcing IS or even other material goods. This is due to the fact that additional services and service-like components in material goods have increased. Also, SLAs are not only used between companies, but also within a company. In the ITIL concept (see chapter 5.3), internal or external providers are deliberately not distinguished. Both serve the real business and the way for both internal and external providers is to be expressed in a SLA. So, basically, all IS relationships should be based on SLAs, whether they are outsourced or not. The following figure shows a detailed two-step relationship hierarchy of SLAs.

350 | 6 Planning and Preparing IS Development

Customer Department …

…

…

…

IT management/ responsible SLA

Internal provider Target agreement

SLA

External provider Contract

SLA

Fig. 6.22: SLAs Formalize Customer-Supplier Relationships Inside and Outside the Company



 

The responsible instance of IT services is IT management itself. IT management closes a contract with the business department and the internal or an external customer. Establishing customer-supplier relationships throughout the company with SLAs is the core of modern IT-management. An external provider will sign a contract that will contain a detailed SLA and his payment will depend on fulfilling the SLA. Also, an internal provider, like the service desk will have a sort of SLA with the IT management responsible for ultimately delivering a service to the business department as its customer. Maybe the bonus of the programmer will depend on fulfilling the SLA, to give him an additional incentive to do so.

There are good reasons for using SLAs externally and internally in professional IS relationships:  SLAs identify and define the customer’s needs: they force the customer to exactly define his requirements (see chapter 6.3).  SLAs provide a framework and common language for mutual understanding: this document forces the partners to be clear about the meaning of the terms they are using: do both mean the same thing when they are talking about “uptime”? There are many templates for SLAs and international standards that of-

6.2 Business Plan and Outsourcing Decision | 351









fer a glossary of terms and definitions. This helps in simplifying complex issues in an SLA document. SLAs provide a framework for charging and pricing services: Pricing and Penalties are not as flat and easy as buying a material good; rather they are tightly connected to the defined performance. Reduce areas of conflict: whenever something is not soundly defined in advance, it will lead to conflicts. If a conflict arises, it is very difficult to solve it without having a defined method of resolution in advance. Eliminate unrealistic expectations: both parties know what they are getting and there are no disappointments like, “I thought this was included in our contract …”. After all, making the service a tightly defined “material” it is not so unique anymore and can be put up for competitive bidding to find the best provider.

So, there seem to be a lot of advantages to SLAs if they are prepared properly. A SLA is a good base for a successful outsourcing relationship, but there are some problems with them that are frequently reported in practice: Not all aspects of the relationship can be put in the contract and some might simply be forgotten, so the contract might be incomplete. Also, a contract close to perfection would cost a lot of money that rises with the value and the size of the contract. Evaluating the acceptable cost of contracting in relationship to the savings expected from outsourcing is a management task. Typically, vendors know much more about the cost of providing the service than the purchaser because the provider is specialized in this business and has many years of experience. For the buyer, it might be the first time and he might not be fully aware of his TCO he is about to replace and how much of these costs can really be reduced (see chapter 6.2.1.3). If you are directly involved in management an outsourcing relationship, it is advisable to dig deeper 1 into this topic by researching “Managing Successful IT Outsourcing Relationships”, e. g. in a book by this name written by Petter Gottschalk.

Let’s have closer look into the chapters and contents of a SLA: Service Specification is the exact description of the nature and extent of the services to be provided (e. g., implementation, operation and maintenance of standard software. Dates and Deadlines: Services are to be provided at certain times (e. g. “delivery of performance-report by the 5th of the following month”) or within specified deadlines (e. g. “Troubleshooting within eight hours of work”). Ideally, these are in relation to previously agreed priorities, such as the elimination of critical problems (server downtime) within two hours and removing less critical faults (failure of a printer) within one working day.

352 | 6 Planning and Preparing IS Development

However, it seems impractical to define the priority for each service or event individually. Rather, different service levels should be predefined and assigned to certain services. The following example suggests three different service levels that can be assigned to specific services. Table 6.8: Distinct Service Levels as a Means of Standardization in an SLA (Gadatsch (2012), p. 122) SLA-Level Uptime Maintenance windows Hotline service hours

Failure frequency/ Maximum downtime Maximum reaction time in case of failure Backup

Level 1: Very high availability 24/7

Level 2: High availability 24/7

2 h per month in mutual arrangement plus 5 h per quarter Mo–Fr. 6 a.m. –10 p.m. Sa 8 a.m. 2.p.m. Su 60 h total p.a. to be defined in mutual arrangement Rest of time (24/7) Emergency number Once per month max. 1 h each

3 h per month in mutual arrangement plus 10 h per quarter Mo–Fr. 6 a.m. – 10 p.m. Rest of time (24/7) Emergency number

20 min after notification via phone/fax/email

60 min after notification via Phone/Fax/email Daily online backup 8 generations

Daily online backup 15 generations

Twice per month max. 1 h each

Level 3: Standard availability Monday–Saturday 8 a.m. til 10 p.m. Every Sunday plus 10 h per quarter Mo–Fr. 6 a.m. – 10 p.m. Rest of time (24/7) Emergency number

Four times per month max. 2 h each 90 min after notification via email Daily online backup 3 generations

Further Elements of a professional SLA include: Terms and conditions: The amount of fees and penalties and their manner of calculation (e. g. discounts and other variable pricing) need to be specified, as well as the frequency of invoicing (weekly? monthly? yearly?). Organizational framework: Here, rules of the relationship will be agreed, particularly about working hours and standby times. It also needs agreement on how the order to fix problems will be communicated: automatically via remote maintenance, by email, by telephone, or other means of communication. Proof of performance: By default, the provider shall demonstrate the performance and fulfilment of his contract. He has to produce verifiable records of the nature and extent of the services. A common committee including both parties has to be set up to settle disputes. For invoicing, only measurable criteria should be used.

6.3 Requirements Engineering (RE) | 353

Permissible outlier ratio: There will be always some outlier, and it might be inefficient to call each of them a breach of contract. So, the maximum amount of events and deliveries outside the quality and delivery agreed needs to be fixed. Consequences of SLA violations: Only when the allowable outlier ratio is exceeded, action can be taken, which includes penalties that compensate loss of revenue or damages. However, penalties should just serve as an insurance against underperformance and not as a source of revenue for the customer. The penalty should hurt the provider just enough to keep him on track, but not force him into bankruptcy. The following figure shows a possible solution to terms and conditions and the consequences of SLA violations: Overperformance Bonus Contractual performance level Normal fees Acceptable minimum performance level Penalties Unacceptable performance level Right to terminate contract and to claim damages Underperformance Fig. 6.23: Structure of Performance and Fees

The SLA also describes procedures for how to evaluate the fulfilment and success together and work on further improvements.

6.3 Requirements Engineering (RE) After the basic strategic decision about the introduction or improvement of an IS has been made, the next step should be: What does the software have to look like in detail, what features does it need and what data needs to be maintained?

354 | 6 Planning and Preparing IS Development

There might be considerable difference in how extensively this will be researched: Programming a small interface will have fewer variables than choosing an ERP system. Also, the question of how rigid these requirements have to be decided upfront varies: a classical Waterfall approach demands the specification to be completely finished before proceeding, while an agile concept, like Scrum, only needs fixed requirements during a Scrum sprint (see chapter 6.1.4.3). One way or the other, the organization or customer should formulate their requirements and take the lead in in this task. As stated in previous chapters: IS and its creators are to serve the business – not the other way around. This position can only be maintained if the company or the business department in need of an IS knows what they want, without assistance by the vendor. This is also true if the company decides to use an off the shelf (standard) software and not let it be programmed individually. Knowing the requirements will also be necessary for a good vendor selection; see chapter 6.4. Finding out the requirements might have different names; in this chapter we will use the professional term Requirements Engineering (RE). 1 Please note: Requirements Engineering happens all the time before, during and after software creation. Only in a very rigid Waterfall Model, can it be assumed to be completed before real programming starts. It depends on the individual approach how entangled and ongoing into the project of programming RE becomes.

3 To carve out the special aspects of RE not covered so far, we try to isolate RE from other project work. Please be aware that in an actual project, the elements of RE would need to be integrated into the overall project plan by the project manager.

6.3.1 Preparation and Management of Requirements Engineering Like all parts of the software development process, RE needs preparation, organizing and planning. In this chapter, the basic goals of the stakeholder, standards to be agreed on, and practical questions of organizing the RE process will be covered. RE is to be carried out by business customers, software engineers and others. However, there is also a real job description for a “Requirements Engineer” (REng). Her job is bringing expertise into the process of RE and help organizing and coordinating it. Her job is definitely not to do the RE on her own – just as a project manager is not doing the project. Is a REng. as a person necessary at all? The answer is a qualified “no”: RE is a function that can be fulfilled by different persons, as long as they have the skills to do so. As in other coordinating functions (like controlling or project management), a dedicated person for REng. will only be necessary if the RE of a project is big and/or complex.

6.3 Requirements Engineering (RE) | 355

6.3.1.1 Goals and Scope of Requirements Engineering The process of RE starts with defining goals, because without them, no accomplishment of goals is possible. The objectives for a new or improved IS should come from the strategy phase: Why do we want to introduce a new IS, e. g. like an ERP in the first place? The objectives and goals for RE should be formulated according to the SMART principle. A good definition sets clear boundaries; that is the literal meaning of the Latinbased word “definition”. Systems or functions out of scope at this time and for this project should be explicitly excluded right away. For example: We want to introduce a new CAD system in our automotive division – NOT in the ship building division. We will only take care of defining requirements for the CAD system itself, and NOT for the CAE plugins or the PDM. A great help in defining the boundaries of the system are so-called use cases drawn as UML diagrams. UML is a modelling language which we mentioned, but did not get deeper into while discussing modelling and notation standards in chapter 1. Please note that UML also offers a detailed description of how a process will be run. Here, we just 1 want to use the part of UML that offers a macro view of the future system. Use cases do not yet show how exactly a process will be carried out, but rather: Who is involved and what events and situation might arise that need to be covered by the system? Please read through the Wikipedia article on use case and the use case UML diagram here http://en.wikipedia.org/wiki/Use_Case.

The following figure is taken from a RE for a student’s administration software. It does not detail processes, but shows the users and actors involved.

356 | 6 Planning and Preparing IS Development

Input student marks

Obtain student grant Obtain student loan

Financial institution

Reimburse course fees

Grade Administrator

Teach seminar Distribute transcripts

Pay fees

Print teaching schedule

Instructor

Distribute Distribute free information to schedule students Post office

Student

Enroll in seminar

Distribute schedules

Drop seminar Registrar Drop out of school

Attended seminar Apply for grant

Graduate from school

Finish seminar

Researcher

Fig. 6.24: Use Case Diagram Defines Systems Boundaries in Requirements Engineering (http://www.agilemodeling.com/artifacts/useCaseDiagram.htm)

We cannot go deeper into UML notation in this module. However, since it is an open standard, there is plenty of good material to learn about how to define system boundaries, e. g. like here http://www.uml.org.cn/requirementproject/pdf/re-a2theory.pdf, p. 28 ff.

6.3.1.2 Stakeholders’ Interest as Base of Requirements Engineering So far, we have taken a neutral, technical approach as if everybody agrees on things to be done and what is important. In real life, this is not the case; instead, there are different stakeholders that have literally different stakes in the Information System for which the RE is conducted. Typical stakeholders of any project, and consequently, of RE, might be active and passive stakeholders like:

6.3 Requirements Engineering (RE) | 357

       

Programmers Users Top-Management IT-Management Shareholder Banks Authorities …

There are usually two tools that can be used together to explore them. First, there is a more detailed matrix of possible stakeholders (lines) and their characteristics (columns) like:  Stakeholder interest in project, impact of the IS to be planned on stakeholder  Stakeholder influence  Stakeholder attitude  Strategies for obtaining support or handle opposition of stakeholders. For a detailed example of a stakeholder analysis, please see the following article: http://ppmtoolkit.undp.org/1c_Stakeholder_Analysis_Tool.cfm Additionally, the stakeholders can be placed in a matrix with two dimensions – “influence” and “attitude” or a cube with the axes “power”, “interest” and “attitude”. According to their position, there will be specific recommendations on how to handle those stakeholders. One example of such a cube can be found here: http://www.brighthubpm.com/project-planning/23481-stakeholder-analysisspheres-of-influence Some stakeholders play different roles at the same time: the same person might be a user and also 3 have management functions. Please see a module or literature about project management to dig deeper into the stakeholder analysis, since project management was the first discipline to use it. For RE, the bottom line recommendation is: it is important to know the stakeholders, their motives, goals and powers since this will influence their role in the RE process

Also, there needs to be a management of requirements since they might already be changing as they are written and changes must be recorded. Changes arise, for example, if stakeholder interests and the requirements they cause are conflicting, and prioritized or changed to resolve the conflict. The ITIL process of “change management” (see chapter 5.3) will give some idea of how to organize the management of requirements and requirement changes. In the course of their life-cycle, requirements might change, their priority might change or might become obsolete and also new requirements arise. Professional RE includes some basic form of requirements management that might also be supported by software or a spreadsheet to keep track of the requirements.

358 | 6 Planning and Preparing IS Development

6.3.2 Organizing and Executing Requirements Engineering After the basic information about goals and stakeholders is processed, the RE is to be executed. RE not only will draw processes of the real business that lead to requirements for the IS. RE itself also should be organized in a professional process like any other project. It does not make sense for all stakeholders to just shout out their conflicting requirements. Workshops with the stakeholders to extract their requirements are a central tool to executing RE.

6.3.2.1 The Requirements Engineering Process Processes and tools used for RE vary considerably depending on the kind of application, stakeholders involved and the organisation developing the requirements. However, there are a number of generic activities common to all that shall be explained very briefly in this chapter. Sommerville (2011, p. 101) suggests the following generic process of RE:

Feasibility study

Requirements elicitation and analysis Requirement specification

Feasibility report

Requirements validation System models

User and system requirements Requirements document

Fig. 6.25: The Process of Requirements Engineering (Based on Sommerville (2011), p. 101)

In this figure, we assume a feasibility study has already been conducted in the strategy phase, in which the business plan has been drawn.  Requirements elicitation or discovery, as it sometimes called, finds sources of requirements and the kinds of requirements that need to be specified.  The requirement specification finds out the actual values and details of the requirements.  All requirements must be validated to be correct, consistent, unambiguous, and so on.  Each step will also deliver a documentation output as main result.

6.3 Requirements Engineering (RE) | 359

These tasks are not performed in a strict chronological order, but will often iteratively lead to final results and will, therefore, be represented by a spiral similar to chapter 6.1.3.2.

6.3.2.2 Creating Information for Requirements Engineering Elicitation finds and consolidates requirements in close interaction with stakeholders. After discovering requirements, they need to be classified and organized. Whenever requirements or goals are collected, there will be duplicates, and the hierarchical relationship of requirements might be unclear. For example, “User friendly screen design” is just a sub-requirement to “Usability”. In the end, all requirements should be structured in a tree and be mutually exclusive and collectively exhaustive. Some requirements might outright conflict with each other, like security vs. comfort and easy access. Even if they do not conflict directly, they will compete for the same project resources, like time and money, and might not be realized at the same time. Direct conflicts and competition for resources have to be resolved by negotiation and prioritizing requirements. The actual requirements specification employs several methods of research. In formal and informal interviews and workshops, the stakeholders are asked about requirements. Just like in any other research, also in RE, good practices and rules for conducting interviews should be applied. The value of interviews is usually very good for getting to know users. However, interviews are not always ideal when researching special expertise and domain knowledge, e. g. security admins. RE might not always understand their special technical jargon and specialists sometimes take certain aspects and requirements for granted, so they will not mention these in an interview. Another approach for creating information is the direct or indirect observation. Talking part in everyday work of, e. g. future users will reveal more about their processes and social and organizational context than can be put into words in an interview. It shows the researcher and RE interviewer “the way it is really done around here”. Since this is a rather lengthy process and might sometimes lead a bit off track, such ethnographic research should be supported by prototypes. Watching people work with prototypes in their natural habitat has proven to provide a lot of valuable information. Other valuable sources of information are existing documents: many technical and legal requirements are already simply written down, like data transfer rates, encryption standards and also organizational processes. A word of caution: processes created by quality management for ISO certification often show the organization as it should be – not how it really works. The more human interaction is involved in those processes, the more intensely the ISO 9001 documentation has to be

360 | 6 Planning and Preparing IS Development

checked to reflect the reality of company before being put into requirements. Otherwise they will not be really useful for RE.

6.3.2.3 Requirement Workshop In practice, the requirement workshop is commonly used to specify requirements from people and documents and discuss conflicts of requirements right away. The following process for conducting efficient and effective workshops was prepared by the project management resource website www.projectconnections.com. The pages refer to an in-depth document about workshops that can be obtained there. “Clarify the requirement area and scope for the workshop. A good place to start is with the project scope and objectives, or the problem statement that lead to the project’s initiation if one exists. Begin by drafting a list of the information you think you need to collect. Then seek input from the project manager, sponsor, or business lead to make sure that the purpose of the requirements workshop is clear and agreed upon. What are you trying to accomplish by bringing the participants together into a workshop? How will you know the workshop has been successful? Identify which stakeholders need to participate in the discussion. Once the purpose is clear, review the business processes or functions related to the workshop focus area, and review the Stakeholder Analysis to see who represents those areas. Consult with those stakeholders, the project manager, and the sponsor for input on additional candidates to participate in the workshop. Determine whether or not it is feasible to gather this group together all at one time for a workshop. Requirements collaboration can also be done online or through various electronic collaboration tools, so if a face-to-face workshop is impractical for some reason, there are other options. A virtual meeting may be the right approach in some situations. Consider the use of videoconferencing if it is available and economical, but be prudent; is the added cost necessary? Decide when the workshop will be held. Reserve time on the participants’ calendars with as much notice as possible. If you’re not sure exactly how much time to plan for, block a little more than you think you will need. You can free up any excess time as soon as you have a firm agenda. Set the stage and expectations. Use the pre-workshop checklist on page 2 to help you organize and complete the workshop planning and preparation activities. Distribute the agenda and any pre-workshop preparation material at least a week ahead of the meeting, allowing ample time for review. Conduct the workshop. Use the workshop conduct checklist on page 5 for guidance on conducting the meeting. Remember to thank your participants for sharing their time and knowledge, both as you begin and at the conclusion of the workshop. Reiterate any key findings or points captured during the meeting, and distribute a summary to all participants as a means to seek clarity and feedback on the requirements details you captured. Follow-up on workshop tasks and requirements, to generate final deliverables. After the workshop, review and summarize your notes with the facilitation team (see page 7) and send them to your workshop participants for review. Incorporate any feedback you receive into the final requirements deliverables you generate based on the workshop output”. http://www.projectconnections.com/templates/detail/requirements-workshop-planning.html

6.3 Requirements Engineering (RE) | 361

It might be useful to give some homework before the workshop, if the participants are already introduced to the topic so they can prepare some things in advance. Included in the preparation is an agenda, which the workshop should closely follow. The following agenda exemplifies basic steps: Table 6.9: Example for a Requirements Workshop Agenda (Based on Laudon/Schoder (2012) p. 8) Workshop “Requirements for PDM export functions” 1. General inception and setting the rules for the workshop 2. Introduction into the topic  Introduce the project: What is the mission of the software project and what objectives have been agreed with the management  Explain single process steps and methods of extracting the requirements  Explain important terms and words like “stakeholder” and “requirement”  Show the contents of the requirement engineering plan and the role of this workshop in this plan 3. Enumerate possible types of requirements for the export function BREAK 4. Analyze context delivering and receiving systems, setting system boundaries 5. List existing requirements from other workshops or documents BREAK 6. Define functional requirements in a brainstorming 7. Define non-functional requirements in a brainstorming BREAK (parallel: requirements engineer purges brainstorming from double requirements and structures remaining requirements) 8. Consolidate and agree on requirements) 9. Summary, next steps and closing

App. Time 20 min 60 min

15 min 40 min 40 min 60 min 60 min

40 min 20 min

After the interviews and the workshop, some post-processing might be necessary. In the end, any requirement must be validated and should pass the following test. A requirement always should be:  Correct  Consistent  Unambiguous  Complete  Feasible  Relevant  Testable  Traceable. This process and the organization should be applied for all types of requirements that will be explained in the next chapter.

362 | 6 Planning and Preparing IS Development

6.3.3 Types, Documentation and Management of Requirements RE can only be managed if the requirements are documented, be it on paper or digitally. This chapter deals with the questions: 1. what requirements there are to be documented and 2. how to write them down correctly to form this important final document of the “requirement specification” or “specification book”. If you are responsible for writing a software requirements specification book, you will need to deepen your knowledge about this discipline. You will find support for writing requirement specifications in every book about RE or, for example, here: http://www.letu.edu/people/jaytevis/Software-Engineering/Examples/writingsoftware-requirements-specifications.doc

6.3.3.1 Types of Requirements in a Specification Document A common mistake in non-professional RE is to just focus on the functions an information system should possess like, “The system needs a PDF export function!” In professional RE, there are basically two kinds of requirements: functional requirements describe what the IS should do and what features it should offer, while non-functional requirements focus on all other aspects. Other authors split up these categories into four: customer requirements, product requirements, product-component requirements and derived requirements. Functional requirements state the capabilities the IS shall provide, how it will react to particular inputs and how to behave in defined situations. It might also be useful to clearly state what the system should not do. Sommerville (2011, p. 86) gives the following example of a functional requirement of an appointment system for a hospital: “A user shall be able to search the appointments lists for all clinics. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.”

The functional requirements cover all aspects of the software that was defined by the overall scope. Again, use cases are a good starting point to derive the single functions. After all – a use case can only successfully be executed if all necessary features are present. Non-functional requirements concern all other requirements besides the functions. The following figure structures several kinds of non-functional requirements.

6.3 Requirements Engineering (RE) | 363

Non-functional requirements

Organizational requirements

Product requirements

Efficiency requirements

Dependability requirements

Usability requirements

Performance requirements

Security requirements

Environmental requirements

Operational requirements

Spare requirements

External requirements

Regulatory requirements

Development requirements

Accounting requirements

Ethical requirements

Legislative requirements

Safety/ security Requirements

Fig. 6.26: Types of Non-Functional Requirements (Based on Sommerville 2011, p. 88)

A great challenge with non-functional goals and requirements is the fact that they are sometimes difficult to measure. However, they need to be transformed into measurable ways; otherwise, no test and evaluation will be possible. The following example by Sommerville (2011, p. 89) shows how to transform a non-functional goal into a testable non-functional requirement. “The system should be easy to use by the design staff and should be organized in such a way that user errors are minimized. (Goal) Design staff shall be able to use all the system functions after 30 hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)”

The following table shows some more measures that help to specify non-functional properties of software.

364 | 6 Planning and Preparing IS Development

Table 6.10: Possible Measures for Non-Functional Properties (Based on Sommerville (2011), p. 90)

Property

Measure

Speed

 Processed transactions/second  User/event response time  Screen refresh time

Size

 Mbytes  Number of ROM chips

Ease of use

 Training time  Number of help frames

Reliability

   

Robustness

 Time to restart after failure  Percentage of events causing failure  Probability of data corruption on failure

Portability

 Percentage of target dependent statements  Number of target systems

Mean time to failure Probability of unavailability Rate of failure occurrence Availability

Generally, RE in software engineering is not much different from gathering the requirements in mechanical engineering. And just like in mechanical design, the documentation is the most important part, in which all information comes together in a structured form.

6.3.3.2 Writing a Specification Document The document in which the requirements are written down has different names, like “specifications book”, “specs” or “software requirements document”. Here, we will use the name requirements document. Many companies have fixed standards of how a requirements document should look. This standard might be self-developed, manufactured by a consultant or taken directly from an international standard, like “ANSI/IEEE Std. 830–1984”. Sommerville (2011, p. 93) lists the following typical chapters for a requirements document:

6.3 Requirements Engineering (RE) | 365





 













“The Preface defines the expected readership of the document and describes its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. The Introduction describes the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. The Glossary defines the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. In the user requirements definition you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. The system architecture chapter presents a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted. System requirements specification describes the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. The system models chapter might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution describes the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. Appendices should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.”

Another important task for management and the requirements engineer is to decide upfront on the standards used in the documentation, e. g. for drawing processes and the language used to describe the requirements. In practice, a lot of time is wasted arguing about what templates or notational standard will be used. There are many

366 | 6 Planning and Preparing IS Development

norms and standards publicly offered at no cost and every company might also have invented their own standards. Deciding on common standards is important for working efficiently and frees energy to focus on the content of the requirements. There are basically three areas in which a common notation for a RE must be found: On the macro level “use cases” will be drawn to show what actors will be involved in what events. Here UML use cases (see chapter 6.3.1) have been proven very useful. Secondly, the detail level will be sketched by a process model (see chapter 1). In the German speaking world, this will probably be EPKs, while internationally BPMN might be the choice for drawing processes. The third decision is about the language used. Since a requirement document is the link between users and stakeholders needs and the programming code, there is a wide range of languages possible, starting with natural language, like an average user would do (taken from Sommerville 2011, S. 95):  Natural language: The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.  Structured natural language: The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.  Design description languages: This approach uses a language, like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used, although it can be useful for interface specifications.  Graphical notations: Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.  Mathematical specifications: These notations are based on mathematical concepts, such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract. Since the specification document represents the customer needs, it should be written in some form of natural language, the way we speak with each other outside the computer world. However, pure natural language suffers from several problems like lack of clarity, requirements confusion (functional and non-functional requirements tend to be mixed-up) and requirements amalgamation (several different requirements may be expressed together).

6.3 Requirements Engineering (RE) | 367

A compromise to avoid an ambiguous document might be using structured natural language. This is, e. g. supported by formulating templates that prescribe a certain form of how features are to be expressed. The following figure shows the typical structure of language templates. Legal relevance Language template for a structured natural language When, at what incident?

The system/ the actor

must

can

Whom to deliver/ enable

Verb/ action/ process

Object Is able

Shall / will

Language template used in an example Every Monday at 8.a.m.

The PDM system

Legal relevance shall

Mail

To the head of product data

A predefined report about the state of possible double entries

Fig. 6.27: Language Template for a Structured Natural Language (Based on Sommerville (2011), p. 97)

The final requirement specification document (on paper or digital) serves several purposes for different people, as the following table shows.

368 | 6 Planning and Preparing IS Development

Table 6.11: Purposes of the Final Requirement Specification Document (Based on Sommerville (2011), p. 92) Users

Description

System customers

Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.

Managers

Use the requirements document to plan a bid for the system and to plan the system development process.

System engineers

Use the requirements to understand what system is to be developed.

System test engineers

Use the requirements to develop validation tests for the system.

System maintenance engineers

Use the requirements to understand the system and the relationships between its parts.

Once the requirements are written down, they will be subject to change, since there are intense relations between the RE and other phases of the software creation cycle, as described above. There might be new information from the vendors, some pricing issues, and changing user demands that might re-prioritize certain requirements. Since the requirements specification is a living document, the changes should be kept to a minimum and must be introduced in an orderly way. This task is called requirement management. The ITIL change management process (see chapter 5.3) is a good starting point for how to organize a good requirement change request process.

6.4 Selecting and Contracting Vendors The process of vendor selection is especially relevant for deciding on standard software (especially ERP software like SAP) that will be bought and then customized. This chapter will focus on such a selection process. However, the tools that are described might also help a company if it is looking for a good partner for programming individual software or must choose between possible outsourcing partners. The generic process of vendor selection and contracting for standard software is described by Motiwalla (2012 p. 191) in the following steps: 1. Vendor research and information gathering 2. High-level vendor demonstrations and evaluation 3. Needs and requirements assessment 4. Development of request for bid or proposal 5. Release request for bid to vendors 6. Analysis and selection  Evaluation of bids

6.4 Selecting and Contracting Vendors | 369

7.

8.

 Functional evaluation  Technical evaluation  Vendor – detailed demonstrations  Contact references  Develop a total cost of ownership model Vendor negotiation  Contract review and change  Pricing – software, maintenance, and consulting, support Purchase system

This fits in our “broad model” developed in chapter 6.1.2, in which the requirements assessment is placed after vendor research and his high level workshop demonstration. This order ensures that, during requirement engineering, company members get a feeling of what is available and also get inspired by what might be possible. However, this must not lead to the “shortcut” of buying a merely good system without proper requirement engineering. For ERP systems, a slightly different approach is suggested that integrates the vendor more closely into the upcoming implementation called “fit/gap”. In the fit/gap approach, the vendor will lead the organization step by step through the functionality of his ERP. The organization can see what works for it, what business processes need to change, and what changes are necessary to the ERP to work for the organization (Motiwalla 2012 p. 198). This might enhance the quality of the project plan for customizing and implementation and lead to more realistic numbers for the cost of customizing. There are also other suggestions for a vendor selection process, for example here: http://operationstech.about.com/od/vendorselection/a/VendorSelectionHub.htm Some software vendors try to urge the company into an implementation strategy that goes like this: “Buy our software now – adjust and reorganize later, according to our software”. This is not completely impossible, since ERP systems are sometimes introduced to organize the processes better and to benefit from best practice processes offered in the software. Also, companies, like SAP, have prepared a methodology and tools (e. g. readymade project plans) to help in implementing their software quicker. In the following chapters, we maintain a more autonomous position: the company chooses according to its needs, which were documented during RE.

6.4.1 Preparation and Preselection The selection of a good vendor is a dilemma: all possible vendors should be researched with high intensity, but this might be very costly. Like in similar selection challenges (e. g. selecting countries in international marketing), the solution is a

370 | 6 Planning and Preparing IS Development

multiple step process. In the course of the selection, the candidates are reduced and the evaluation methods will get more refined and costly. The following figure shows a real-life selection process that is slightly different from the generic process proposed above. Bids are only requested after the vendors presented in depth solutions for certain company specific problems in workshops. The numbers in the following example are fictional, but realistic. Update Businessplan + Create Scoring Model

Market Study Specification

Vendor Case Studies

1= very bad; 10=very good Weight Functions (Sum)

Bid > 30

     

Stability References Know – how Culture Commitment … 8%

8

8%

10

Relevant Contac- Workvendors ted shop

Bid

6%

3%

7

6 5

15%

-

Number of import formats

5%

10

Technology standards Interfaces to ERP

5%

9

Performance (Summe)

3

-

10%

Article management Duplicate detection

5%

5

20%

-

5%

10

5%

5

10%

9

Capacity Speed Scalability

Provider (Sum)

30%

Iconic

Poesis

Points Score Points Score Points Score

Integration new suppliers

Search functions

9

35%

Process of article import

Integration (Sum)

5

System K-Catalog

Provider:

-

2,67

-

1,64

-

1,39

0,56

5

0,40

1

0,08

0,80

3

0,30

3

0,30

0,80

8

0,64

4

0,32

     

Functions Usability Integration Performance Standards …

0,36 0,15

4 2

0,24

0,06

9 5

0,54

0,15

1,20

-

0,70

-

0,60

0,50

5

0,25

3

0,15

0,45 0,25

6 3

0,30 0,15

4 5

0,20 0,25

1,15

-

0,25

-

0,95

0,50 0,25

8 3 1

0,40 0,15

3 9 5

0,15 0,45

0,90

2,24

-

0,10 1,49

-

0,50 1,30

Stability and size

2%

6

0,12

6

0,12

4

0,08

Reference projects

3%

4

0,12

9

0,27

4

0,12

Know-How in our industry

5%

5

0,25

3

0,15

4

0,20

Support Commitment/ Cultural Fit

5%

8

0,40

7

0,35

3

0,15

15%

9

1,35

4

0,60

5

0,75

Grand Total

100%

7,26

4,08

4,24

Fig. 6.28: Example of a Multilevel Selection Process

In the first step, relevant vendors are determined from existing market studies. Scanning the market studies also helps to see what functions might be available at all. In our example, there are some 30 vendors that sell the software we are looking for. After checking some basic facts about the software and the vendor, nine of them are selected to be potential partners. In the second step, the existing requirements are updated and sent to the nine chosen providers. In our case, five of them agree that their software is able to fulfil the requirements and we invite them to a demonstration workshop. Case studies with specific company issues and requirements will be sent to them and they are asked to present solutions with their software in workshops. In the workshop, two vendors were not able to deliver feasible results to our core problems and they also did not fit at all with the project culture of the company. The three remaining providers on the short list are asked to make an official bid. When the bids are received, the business plan might be updated with the new information about investment, running cost or even benefits. All non-financial information is collected in a scoring model to compare solutions and providers. This will be the main subject of the next chapter.

6.4 Selecting and Contracting Vendors | 371

Here, we will focus on the earlier stages of the selection process, while the scoring model for deep evaluation and decision will be the object of chapter 6.4.2. Some of the steps in the figure above will be further explained: The first step relies on secondary research, e. g. via market studies about ERP systems. There are many market studies available (please enter “market overview ERP” in a search engine). As always: quality has its price, so a really good study about standard software like ERP, CRM and CAD might cost some money. Also, there needs to be somebody within the company or a supporting consultant who digests this information. The requirements and specifications (see chapter 6.3.3) are a good starting point for evaluation. However, there need to be criteria added on how to judge a vendor, which is presented in the following table:

372 | 6 Planning and Preparing IS Development

Table 6.12: Additional Criteria for Evaluating Vendors (Taken from Motiwalla/Thompson (2012), p. 193) Criteria

Explanation

User Base

How many companies are using the system and for what purposes. Identify competitors using the system.

Financial Position

If publicly traded, this information is fairly straightforward. If not, the ERP vendor information may not be available until such time later in the purchase process. It should include sales revenues, profits, growth, research and development, and any outstanding debt.

Implementation Issues and Support

This can be accomplished through calls to companies using the software or IT researching companies that survey and collect this type of information on a regular basis. Be sure information is current. What may have happened three or four years ago may not be accurate.

HW/SW Infrastructure Fit and Scalability

ERP vendors usually support more than one platform. Identifying and documenting the platforms will provide a better understanding of the scalability of the system and ultimate fit with the company’s direction.

Vendor Direction

This information should be tracked through the vendor history of change and upgrades to the system along with a statement of direction from each vendor. The ability to implement a stated direction is important; hence, knowing the history is critical to understanding the hype versus the reality.

Currency of Technology

Like legacy systems, a vendor’s software is often written in older technology. In some sense every vendor goes through this because technology is changing rapidly, but the ability to migrate to new technology must be understood and documented during the research process.

Release Strategy

How often are there releases to the system, and what is included in the releases? Are fixes timely and minor upgrades included periodically? What is the timing for major releases, and are there defined upgrade paths? Are there vendor costs related to upgrades?

Development and Maintenance Staff

This is an area that sometimes requires some exploration. It is difficult to compare apples to apples because the “size” of the ERP vendor system will have an effect on the development and maintenance staff. One should really look for a disproportionate number within an ERP vendor and across ERP vendors. This is a key area. It helps to understand how much your company’s direction and long-term needs will be met by the vendor. A company’s involvement in further defining the functional direction of an ERP system is important to understand and document in the vendor research process.

System Update Process

There might not be information on all criteria and they should not yet be researched in depth. If information is available, it can be structured in the way above and will be reused in greater depth in the final selection below. At the end of this first step, the company should a) have an overview of the market b) have selected a set of

6.4 Selecting and Contracting Vendors | 373

maybe 10 vendors that seem to be feasible partners for the system the company is looking for. In the second step, the company develops a request for bid or proposal with the specification created in the Requirements Engineering process sent out to the vendors. In our example, however, the company invites the vendors first for a detailed demonstration. Those workshops are usually very revealing. The vendor will be confronted with a special challenge or requirement of the company and must show how to solve it with his software. The technical solution is not the only goal of these workshops. They are a test of how committed and how individualized the vendor is in considering the customer’s problems. Also, the cultural fit and the “chemistry” between customer and vendor will surface in this close interaction. These workshops are common in supplier relations in the form of a “conceptcompetition” or in media agencies where they are called “pitches”. Some vendors focused on just selling their product might find this unusual, so we might need to explain it to them. Also, obstacles like questions of confidentiality and compensation for the vendor’s cost of preparing the workshops need to be solved by the customer company.

6.4.2 Scoring Model The pre-selection has produced a shortlist of three software products/vendors in the last chapter. For the final evaluation of financial and non-financial information for the product, and especially the vendor, several competencies and functions across the company are needed:  Office staff should evaluate functionality. No vendor will meet all requirements, so vendor discussions and negotiations should focus on the best fit for the business.  Controlling updates and analyses the total cost of ownership (TCO) once the final few providers are known to us. The business plan was explained in chapter 6.2.1.3. It might now be updated with the information we gathered, especially from the bids we received from the vendors.  IT staff should evaluate the technology requirements.  Legal/contracting should evaluate the contract and pricing of the system. The professional instrument for evaluating non-financial information is a scoring model. It is frequently used for different purposes in business, technology and in engineering. However, there are some rather strict rules to this method that are not always followed in practice. A professional scoring model can be created in four steps:

374 | 6 Planning and Preparing IS Development

First, the criteria are chosen for evaluating vendors. The most important source of these criteria concerning the solution of the vendor will be the specifications of RE (see chapter 6.3.3.2). However, also the vendor itself must be evaluated. Especially when entering a long-term relationship and with a lot of customizing ahead, the relationship to the vendor is just as important as functions and technical requirements of his product or service. In the suboptimal case of no requirement specification present yet, there is a shortcut: a brainstorming to find criteria might be conducted. The criteria found in the brainstorming must be structured hierarchically in target-tree. This is to ensure the catalogue of criteria is MECE; mutually exclusive and collectively exhaustive. Secondly, the criteria have to be weighed against each other, since not all of them will have the same importance for the decision. One objective method for doing that is a pair comparison of all criteria: decide, for each pair, whether criterion A is more, less or equally important as criterion B. 2 points are given for “more important”, one for “equal” and zero for “less important”. In the end, all points are summed up for each criterion and the sums are transformed into a 100 % scale. The following table shows a simple example of relatively weighing four criteria for vendor evaluation. Table 6.13: Pair Comparison for Weighing Different Criteria Performance of base functions

Provider Know how

Interfaces Import/ Export

Provider Reference Projects

Sum of Points

Performance of base functions

x

2

2

2

6

50 %

Provider Know-how

0

x

2

1

3

25 %

Interfaces Import/Export

0

0

x

1

1

8%

Provider Reference Projects

0

1

1

x

2

17 %

12

100 %

left more important than above: 2 left less important than above: 0 equally important: 1

Transformed to %

In theory, each relationship should be consistent: in our example, performance should beat interfaces in both matches. However, it is not necessary to check this; just let the team members vote on the matches. To be clear: this is just for weighting the criteria objectively; not to award points to a particular vendor. In the third step, a scale for awarding points is chosen, that is neither too detailed nor too coarse, and should not have a middle value. So “0–5” or “1–10” is a good scale also often used in practice. Sometimes, also minimum values are fixed for some criteria; the alternative/vendor is rejected immediately if the value is below the threshold in a criteria. In our case, only alternatives/vendors that are feasible and passed the pre-selection tare rated, so there is no minimum threshold.

6.4 Selecting and Contracting Vendors | 375

In the third step, points are given to each vendor for each criterion. The points should be given relatively rating the solutions against each other. However, if there is an outlier, it should not dominate the rest of the rating. For example, a peak performance of 1.000 operations per day is needed for us and we have four solutions capable of processing 1.000, 2.000, 3.000 and 50.000 operations. A capacity of 3.000 and 50.000 operations might both get the maximum score of 10 points, since anything above 3.000 is irrelevant in our case anyway. The fourth step is simple math: for each criterion and each vendor, the points awarded to this criterion are multiplied horizontally with the weight of the criteria. This will result in a score that is then vertically summed up to deliver the total score of a vendor.

A 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

B

C

D

E

F

G

H

K-Catalog Iconic Poesis Provider: 1= very bad; 10=very good Weight Points Score Points Score Points Score 2,67 1,64 1,39 Functions (Sum) 35% 0,56 0,40 0,08 Process of article import 8% 7 5 1 0,80 0,30 0,30 Integration new suppliers 10% 8 3 3 0,80 0,64 0,32 Article management 8% 10 8 4 0,36 0,24 0,54 Duplicate detection 6% 6 4 9 0,15 0,06 0,15 Search functions 3% 5 2 5 1,20 0,70 0,60 Integration (Sum) 15% 0,50 0,25 0,15 Number of import formats 5% 10 5 3 0,45 0,30 0,20 Technology standards 5% 9 6 4 0,25 0,15 0,25 Interfaces to ERP 5% 5 3 5 1,15 0,25 0,95 Performance (Summe) 20% 0,50 0,40 0,15 Capacity 5% 10 8 3 0,25 0,15 0,45 Speed 5% 5 3 9 0,90 0,10 0,50 Scalability 10% 9 1 5 2,24 1,49 1,30 Provider (Sum) 30% 0,12 0,12 0,08 Stability and size 2% 6 6 4 0,12 0,27 0,12 Reference projects 3% 4 9 4 0,25 0,15 0,20 Know-How in our industry 5% 5 3 4 0,40 0,35 0,15 Support 5% 8 7 3 1,35 0,60 0,75 Commitment/ Cultural Fit 15% 9 4 5 100% 7,26 4,08 4,24 Grand Total

Fig. 6.29: Weighted Scoring Model for Evaluating three Vendors from 1 to 10

Let us go thru the spreadsheet step by step looking at different cell areas:  (A1:A22) The criteria are derived from the requirements specification and some additional criteria are needed to evaluate the provider itself. Typically, they are segmented into different parts to structere the content and make single segments like “performance” comparable.

376 | 6 Planning and Preparing IS Development 

  



 

(B1:B22) The weights are derived from a pair comparison transformed into a 100 % scale. Weighting should be expressed in percentages and not absolute figures to avoid abstract high numbers in the final score. In this example, the final score will be on the same scale as for single criterias, 1–10. (C1:H2) To the right, vendors on the shortlist are entered with a cell for the raw points and for the weighted score of each. (C3:C22) The points are awarded according to a relative distribution among the vendors, but should avoid the problem of outliers. (D4:D8) The raw points are multiplied with the weighting and this will produce the score. For example, K-Catalog was awarded seven points on the criteria of “process of article import” which is weighted with 8 %. 0,08 times 7 equals 0,56. (D10:D12, D14:D16, D18:D22, A23:D23) This will be done for all other criteria for the provider “K-Catalog”. Finally, the weighted scores are vertically summed up to deliver the final score, in this case 7,26 for “K-Katalog”. (B3:D3, B9:D9, B13:D13, B17:D17) The summation lines are calculated automatically. (E3:H23) These operations are repated for all other vendors.

A so called “sensitivity analysis” can be applied to the model by playing around with some values and weightings just to see how stable the result proves against small changes. This is the same techniqe used in the business plan (see chapter 6.2.1.3) to simulate scenarios. Sometimes, this instrument is criticized as beeing “subjective” – of course it is. However, the problems lie in the wrong adoption of this instrument, not in the instrument itself. If comparison by a scoring model is put to work sensibly, it will have three major benefits:  Only when facts are written down, weights are distributed and points to be awarded are discussed, opinions of the stakeholders involved really become clear.  The quality of the decision will really improve, since the mathematical model evens out some psychological problems, like focusing too much on one single issue that is on the mind of everybody due to recent events.  And last, but not least: the decision is documented by a method everybody had to agree on before. In case something goes wrong with the provider, the model will answer the question: “Why did we choose this provider?” and protect the deciders against the charge of being subjective. After this final analysis, and sometimes even parallel to it, the contract and legal matters will be negotiated.

6.4 Selecting and Contracting Vendors | 377

6.4.3 The Bid, Contract and Legal Matters At some point of the process, the customer (the company) will submit a request for bids (RFB) and the vendor needs to make an offer also called a “bid” or “proposal”. The depth and binding strength of the offer might vary. In our example, the company only asked for a high level proposal before the workshop, and after the workshop a detailed and binding official “bid” from the vendors. Motiwalla (2012, p. 204–207) offers a template for such a RFB (= Request for Bids). It is important for the customer company to exactly articulate what it expects from the vendor to write into this offer and how the process of bidding will be organized. In most cases, the requirement specification (see chapter 6.3.3.2) will be attached to the RFB and the vendor will be asked to clearly state a) that the requirements can be fulfilled and b) how his software modules and functionalities will match the requirements specification. The bid that comes back from the vendor will be the base for negotiations about which parts of the software will be purchased, and how much the software and its customizing will cost. Motiwalla (2012, p. 197) gives the following advice for negotiations, especially on ERP systems:  Talks should center on the products included in the purchase and maintenance terms of each product.  Professional services for the implementation or installation can be included or bid separately.  Contract life cycle management will need to be addressed during contract talks. Acording to Motiwalla (2012, p. 197), every ERP contract should have the following:  All deliverables must be clearly identified with delivery dates associated.  Ensure that you, the customer, have acceptance authority.  Identify those responsible on both sides for contract management and who has the authority to authorize changes to the contract.  A quality manager or contract monitor appointed by the program manager will have primary responsibility for making sure both sides abide by the terms and conditions of the contract.  Changes should only be made when necessary due to unforeseen circumstances, mutually beneficial reasons, or unintended mistakes.  Communicating progress keeps all involved and will also help to maintain momentum.  It is best to over-communicate during this phase: communicating progress keeps everyone involved Contracting is mainly a legal matter, but other members of the company (e. g. end user or IT department) might be involved; for example, discussing the question of

378 | 6 Planning and Preparing IS Development

whether a feature is really needed, whether it is needed now or can be purchased later, and so on. In the end, this will result in a contract that probably has some technical attachments like the specification suggested by the vendor. The compliance or law department of your company might offer templates for such contracts. Finally, the vendor selection and negotiation process is not just for IT specialists and lawyers. In order to yield the best results, management needs to be involved. Motiwalla (2012, p. 198) sees the following management tasks in the steps described above. Management should …  … play a role in choosing the right system that will meet the company’s needs and requirements,  … allocate enough time to evaluate the system, observe a complete and comprehensive demonstration, and communicate to references and others using the system,  … discuss with the vendor future improvements and the strategic roadmap of the application,  … negotiate with two or more vendors. This is time-consuming, but it will yield a better purchase price. The contract with a vendor of standard software or with a programmer starts the next phases: programming, customizing, testing and implementing the IS into the organization.

6.5 Summary of Chapter 6 The software development cycle is an important process in the company and often not optimally structured and managed. Companies individually choose what steps they will formalize and the tools they use, depending on culture, size and type of IS to be introduced. To give companies a guideline of how to structure this important process, 40 years ago, the first formal and quite rigid models were introduced to avoid chaos in software creation. In the new century, the AGIL movement challenged these inflexible models as being too bureaucratic and delivering value too late. They proposed radically different ways to organize software creation, which can be seen in SCRUM, the dominating model in practice born out of the AGIL revolution. Before programming starts, a strategy phase should evaluate all cost and benefits of changing or introducing a IS in order to decide whether the investment is worth it. The main challenge here is to convert organizational improvements caused and enabled by technology into financial terms. This is needed to construct a NPV model for the decision that also allows for simulating different scenarios. Like in all other company functions, the question of outsourcing is a strategic issue. Outsourc-

6.7 Review Questions for Chapter 6 | 379

ing, in its various forms, has many advantages and disadvantages – many of them hidden at first sight. Key success factors for profitable outsourcing are a good preparation, a rational decision process and especially a good service level agreement (SLA). Every organization should know exactly what they expect from introducing a new or improved IS. Requirements Engineering is the professional way of finding out the requirements of the stakeholders. The information collected in interviews, documents and workshops is consolidated, structured and written down in a specification requirements document, a central document in vendor selection and later stages of software creation. Selecting the right software vendor or programming supplier has also proven to be a critical success factor. A company should take its time for this selection and use professional tools. No contract can replace a good match between customer and vendor, but legal matters and a good contract support a good match. If the tools in the steps above are professionally used, the company is ready to create and introduce the Information System with a much higher chance of successful implementation.

6.6 Literature for Chapter 6 Laudon K.; Laudon J.: Management Information Systems (12th edition), Prentice Hall 2012 Deloitte Consulting: Calling a Change in the Outsourcing Market, http://www.deloitte.com/assets/Dcom-Luxembourg/Local%20Assets/Documents/ Global_brochures/us_outsourcing_callingachange.pdf, 2005 Accenture: Overview of Outsourcing, May 2005, http://www.ulb.ac.be/soco/gest116/ppt/Solde du cours/ACN – Outsourcing Overview V02.ppt Bender, K., Hörauf, J., Mahr, A.: IT-Outsourcing – (K)ein Königsweg?, Roland Berger InfoCom Studie, München 2007 Schmidt, M.: Business Case Essentials, a Solution Matrix white paper revised edition 2003, http://cs.iupui.edu/~mroberts/n361/Business_Case_Essentials.pdf, September 2th 2013. Sommerville, I.: Software engineering, 9th international edition, Pearson 2011. Marchewka, J.: Information Technology Project Management: International Student Version, 4th Edition, John Wiley & Sons 2012. Motiwalla, L.; Thompson, J.: Enterprise Systems for Management (2nd edition), Prentice Hall 2011. VersionOne: The State of Agile Development, 6th Annual Survey, 2012, http://www.versionone.com/state_of_agile_development_survey/2011/

6.7 Review Questions for Chapter 6 6.7.1 Close: Comparing and Contrasting SDLC with ERP-LC Please chose the right phase and type of lifecycle the description applies to:

380 | 6 Planning and Preparing IS Development

1)

“Evaluate user needs through observations and interviews and create system specifications” describes the [Design, Analysis, Implementation] in a [Software Development Cycle, ERP Life-Cycle].

2)

“Vendor analysis and evaluation of business process changes due to the implementation” describes the [Design, Analysis, Implementation, End-User Role] in a [Software Development Cycle, ERP Life-Cycle].

3)

“Develop new system architecture, user interface, and reporting tools” describes the [Design, Analysis, Implementation, End-User Role] in a [Software Development Cycle, ERP Life-Cycle].

4)

“Acquire hardware, software, develop applications, installation, testing, training, and conversion” describes the [Design, Analysis, Implementation, EndUser Role] in a [Software Development Cycle, ERP Life-Cycle].

5)

“Go-Live” conversion or releasing the system to the users, training, and support describes the [Design, Analysis, Implementation, End-User Role] in a [Software Development Cycle, ERP Life-Cycle].

6)

“Multiple groups such as SMEs, advance users, and self-service users are part of implementation team with continuous involvement” describes the [Design, Analysis, Implementation, End-User Role] in a [Software Development Cycle, ERP Life-Cycle].

6.7.2 Close: A Broad Model of Software Development Please choose the right phase of the software development model. Every answer is only to be used once. 1)

The [strategy and feasibility phase, requirements analysis, raw systems design, detailed design, coding/customizing, integration test, implementation] will document what functions and other characteristics the company and its stakeholders want from the software. It can be validated according to the rules described in the chapter about requirements.

2)

A vendor or the internal IT department will sketch the [strategy and feasibility phase, requirements analysis, raw systems design, detailed design, coding/customizing, integration test] for how to realize the requirements with certain software and make an offer. This bid will be verified by legal and technical staff in the company.

3)

The [strategy and feasibility phase, requirements analysis, raw systems design, detailed design, coding/customizing, integration test, implementation] will evaluate whether investing in a new or improved software will improve the long term value of the organization. It might be validated by an external consultant or another department within the company.

6.7 Review Questions for Chapter 6 | 381

4)

After closing the contract, the customer and the internal or external provider will create the [requirements analysis, raw systems design, detailed design, coding/customizing, integration test, implementation], like screens and necessary data structure. For big ERP Systems this is the phase of planning for customizing.

5)

Once the modules and parts are integrated to form the desired information system, the [requirements analysis, raw systems design, detailed design, coding/customizing, integration test, implementation, everyday operations] will be conducted.

6)

The [requirements analysis, raw systems design, detailed design, coding/ customizing, integration test, implementation] will be verified by built-in tests. These tests will just check whether the code was correct in syntax and the isolated modules produce correct output.

7)

[Strategy and feasibility phase, requirements analysis, raw systems design, detailed design, coding/customizing, integration test, implementation, everyday operations] means that the new system is now put to work in normal operations and real users, who are not specialized in IT work with the system.

6.7.3 True/False: The Waterfall Model of Software Development Please check the statements about the Waterfall Model that are TRUE. The Waterfall Model … 1)

… is easy to use

2)

… is a rigid framework

3)

… allows parallelizing phases

4)

… does not require a lot of documentation and is non-bureaucratic

5)

… was the first theoretical model of software development

6)

… is well-suited if not all requirements are known right from the start of the software project

6.7.4 True/False: The Spiral Model of Software Development Please check the statements about the Spiral Model that are TRUE: 1)

It has basically similar steps as the Waterfall Model

2)

The steps are repeated in iterations

3)

The development in the Spiral Model ends after two iterations

4)

It works with prototypes

382 | 6 Planning and Preparing IS Development

5)

It does not consider risk of development

6)

It is best fit for development projects in which all requirements are known right from the start.

6.7.5 Close: Different Types of Prototypes Please name the correct prototype that is described here. Every answer is only to be used once. 1)

[Explorative, Evolutionary, Experimental, Vertical, Horizontal] prototyping delivers a certain part of the system with all levels like database, function, presentation.

2)

[Explorative, Evolutionary, Experimental, Vertical, Horizontal] prototyping delivers a program with basic functionalities and is used to let the users try and evaluate it and give feedback to the programmers. During improvement, the product is kept running until ultimately, the finished product emerges.

3)

[Explorative, Evolutionary, Experimental, Vertical, Horizontal] prototyping will deliver an overview of the specification and whether the functionalities are feasible.

4)

[Explorative, Evolutionary, Experimental, Vertical, Horizontal] prototyping is used to gather experiences and try out different solutions in a real program.

5)

[Explorative, Evolutionary, Experimental, Vertical, Horizontal] prototyping finishes one level, e. g. the graphical user interface (GUI), completely in all parts of the software, while layers below might not yet be finished.

6.7.6 True/False: Principles of Agile Development Please mark the 5 wrong statements that do NOT comply to agile principles: 1)

Highest priority is to satisfy the customer through a final, perfect delivery of finished software.

2)

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3)

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4)

Business people and developers must work as separately focused on their own tasks throughout the project.

5)

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

6.7 Review Questions for Chapter 6 | 383

6)

The most efficient and effective method of conveying information to and within a development team is email conversation and specification documents.

7)

Good documentation and concepts are the primary measure of progress.

8)

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9)

Continuous attention to technical excellence and good design enhances agility.

10) Simplicity – the art of maximizing the amount of work not done – is essential. 11) The best architectures, requirements, and designs emerge from externally structured and organized teams. 12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

6.7.7 Choose: Benefits from Agile Programming From the following benefits, identify the three top benefits companies see in “agile” programming: 1)

Enhance Software maintainability

2)

Ability to manage changing priorities

3)

Increased productivity

4)

Reduce cost

5)

Improved project visibility

6)

Manage distributed teams

6.7.8 Choose: Concerns and Barriers for Agile Programming From the following problems and issues, identify the four top problems companies face in introducing agile or adopting agile further: 1)

Cannot change organizational culture

2)

Budget constraints

3)

Not enough personnel with right skills for agile

4)

Reduced software quality

5)

Problems with regulatory compliance

6)

General resistance to change

7)

Loss of management control

8)

Inability to scale projects

384 | 6 Planning and Preparing IS Development

6.7.9 Close: Elements of Scrum Project Management Concept For each gap, please choose the correct word to complete the sentence: 1)

The [Product Owner, Sprint Master, Daily Scrum] first tells all the stories and features the system should be able to support in the end. The stories and features are stored in the [sprint backlog, product backlog, sprint review].

2)

Some of the stories and features are packaged into a [sprint backlog, product backlog, sprint reviews, release backlog], which might again be split into one or more [sprint backlogs, product backlogs, sprint reviews].

3)

In a sprint, all the features in the then unchangeable [sprint backlog, product backlog, sprint review] will be worked on comprehensively.

4)

The [Product Owner, Scrum Master, Daily Scrum] is a kind of project manager who ensures that the programmers have all they need and are working together. He also organizes meetings and reports programming progress.

5)

Every day, the team gathers for a stand-up meeting that should not last longer than 15 minutes and is called the [sprint backlog, sprint retrospective, sprint review, daily scrum].

6)

The basic reporting tool during a sprint is the so-called [sprint retrospective, sprint review, daily scrum, burndown chart]. It shows, on a time scale, the number of features left in the sprint.

6.7.10 Close: Converting Technical and Organizational Impact into Financials Please choose the right level of measurable organizational improvement (MOV) for a business plan introducing a new CAD system. Every answer is only to be used once. 1)

We do not have to pay an additional person to do the redrawing and thus, have a decrease in cost. This is a [technical function, real life impact, measurable non-financial improvement, financial improvement].

2)

We do have less work redrawing designs with the new system. This is a [technical function, real life impact, measurable non-financial improvement, financial improvement].

3)

Our new CAD program will have an automatic export filter to another system. This is a [technical function, real life impact, measurable non-financial improvement, financial improvement].

4)

The number of drawings generated in our design department increases with having the same people working there. This is a [technical function, real life impact, measurable non-financial improvement, financial improvement].

6.7 Review Questions for Chapter 6 | 385

6.7.11 Choose: Characteristics of Measurable Organizational Impacts Please choose the characteristics any possible benefit of a new system must have in order to be considered in the “measurable organizational value” concept. 1)

They must be measurable

2)

They must comply to ISO 9001

3)

The must provide value for the organization

4)

They must exceed competition

5)

They must be expressed in financial terms (€, $, etc.)

6)

They must be verifiable at the end of the project

7)

They must be agreed upon by the project stakeholders

6.7.12 Calculate: Full Value and Incremental Approach Please tell the numbers for the missing fields a)d) on the figure.

Example for one year (2019) IT Operating Gains/revenues IT Operating Costs IT Investment/ acquisition cost Net Gain (Loss)

Full Value approach New CAD New CAD “Solidus” “Auteska”

Old CAD System

Incremental approach New CAD New CAD “Solidus” “Auteska”

300 €

250 €

100 €

200 €

a)

130 €

90 €

100 €

b)

c)

30 €

40 €

€

30 €

40 €

140 €

120 €

€

d)

120 €

Please enter the missing values for the incremental approach without the € sign. In case of a negative value, please enter the minus sign, e. g. “50”.

6.7.13 Calculate: Financial Business Plan Please enter he missing values without the € sign and without points or commas. In case of a negative value, please enter the minus sign, e. g. “–5000”.

386 | 6 Planning and Preparing IS Development

All numbers compared to 2014 Cash in (sum of lines below)

2015 a)

2016

2017

400.000 €

443.000 €

Sell off old equipment Improvement of quality Decreased maintenance cost Additional business for drawings

50.000 € 20.000 € 50.000 € 300.000 €

80.000 € 50.000 € b)

150.000 € 50.000 € 243.000 €

Cash Out (sum of lines below)

680.000 €

104.000 €

88.200 €

New CAD software and hardware Training for new system additional cost of labor additional people salary of additional draftsmen

500.000 € 100.000 € c) 2 40.000 €

20.000 € 84.000 € 2 d)

88.200 € 2 44.100 €

Cash Surplus/Deficit (undiscounted) per year

–260.000 €

e)

354.800 €

1,00

f)

0,83

Discount factor Discounted Cash Flow (DCF) per year

–260.000 €

269.091 €

293.223 €

Discounted Cash Flow cumulative

–260.000 €

9.091 €

302.314 €

Parameter

–10 %

+5 %

10 %

6.7.14 Close: Facts to be Converted into Cash Positions for a Financial Calculation Please decide what to do with the following potential positions to be put in a financial calculation: 1)

Hard benefit with poor measurement should [always be converted into cash positions, never enter financial calculation, be reconsidered and analysed].

2)

Speculative benefits with poor measurement should [always be converted into cash positions, never enter financial calculation, be reconsidered and analysed].

3)

Hard benefits with a good measurement should [always be converted into cash positions, never enter financial calculation, be reconsidered and analysed].

4)

Soft benefit with good measurement should [always be converted into cash positions, never enter financial calculation, be reconsidered and analysed].

6.7.15 Close: Types and Levels of Outsourcing Please choose the correct name for the outsourcing type described. Every answer is only to be used once. 1) Outsourcing hardware, hosting and IT-services is called [infrastructure outsourcing, application outsourcing, utility outsourcing, business process outsourcing, software as a service]

6.7 Review Questions for Chapter 6 | 387

2)

Outsourcing developing, programming and operating programs is called [infrastructure outsourcing, application outsourcing, utility outsourcing, business process outsourcing, software as a service]

3)

Outsourcing with high scalability and full flexibility is called [infrastructure outsourcing, application outsourcing, utility outsourcing, business process outsourcing, software as a service]

4)

“Application Providing” with utility outsourcing models is called [infrastructure outsourcing, application service providing, business process outsourcing, software as a service]

5)

Outsourcing a complete business unit or process is called [infrastructure outsourcing, application outsourcing, utility outsourcing, business process outsourcing, software as a service]

6.7.16 Choose: Advantages and Disadvantages of Outsourcing Please check all items that are TRUE advantages of outsourcing. 1)

Gaining flexibility by converting fixed cost into variable cost

2)

Increased cost awareness in business departments using IT

3)

No investment in outsourcing and low switching cost

4)

Independence from scarce technical staff or personalized know

5)

Access to state-of-the-art technology

6)

Risk reduction due to lower complexity in-house

7)

Direct, operative control into processes – it is possible to react quickly

8)

Improvement of team morale and labour relations

6.7.17 Close: Strategic Decision on Possible Outsourcing Targets Please name an example for an application cited below and chose the outsourcing suggestion according to the outsourcing portfolio.

388 | 6 Planning and Preparing IS Development

high

3

2

Strategic significance of IT process or application concerning company strategy and core competencies 1 low low

Individuality and uniqueness of IT processes or application concerning company goals and core processes

high

1)

For application 1 a good example would be a [CRM-System, Server Administration, CAD with PDM integration] and the basic outsourcing recommendation would be: [Outsource application or service, selectively outsource and combine with internal service, do not outsource application or service].

2)

For application 2 a good example would be a [CRM-System, Server Administration, CAD with PDM integration] and the basic outsourcing recommendation would be: [Outsource application or service, selectively outsource and combine with internal service, do not outsource application or service].

3)

For application 3 a good example would be a [CRM-System, Server Administration, CAD with PDM integration] and the basic outsourcing recommendation would be: [Outsource application or service, selectively outsource and combine with internal service, do not outsource application or service].

6.7.18 True/False: Advantages of a SLA Agreement Please check all true advantages of a good SLA agreement 1)

SLAs identify and define the customer's needs in written form.

2)

SLAs provide a framework and common language for mutual understanding.

3)

SLAs will lead to continuous improvement of the service

4)

SLAs ensures the cheapest provider will be chosen.

5)

SLAs provide a framework for charging and pricing the services.

6)

SLAs will make sure that delivery of services will always be on time.

6.7 Review Questions for Chapter 6 | 389

7)

SLAs reduce areas of conflict since whenever something is not soundly defined in advance it will lead to conflicts.

8)

SLAs eliminate unrealistic expectations: Both parties know what they are getting and there are now disappointments like “I thought this was included in our contract …”.

6.7.19 Close: Elements and Chapters of a Good SLA Please assign the described contents to the right chapter of a SLA. Every answer is only to be used once. 1)

Services are to be provided at certain times, e. g. “delivery of performancereport by the 5th of the following month”. This is part of the chapter [Service Specification, Dates and Deadlines, Terms and Conditions, Organizational Framework, Proof of Performance, Consequences of SLA violations].

2)

The exact description of the nature and extent of the services to be provided e. g., implementation, operation and maintenance of standard software is part of the chapter [Service Specification, Dates and Deadlines, Terms and Conditions, Organizational Framework, Proof of Performance, Consequences of SLA violations].

3)

When the allowable outlier ratio is exceeded, action can be taken which includes penalties that compensate loss of revenue or damages. This is part of the chapter [Service Specification, Dates and Deadlines, Terms and Conditions, Organizational Framework, Proof of Performance, Consequences of SLA violations].

4)

The amount of fees and penalties and their method of calculation (e. g. discounts and other variable pricing) need to be specified, as well as the frequency of invoicing (weekly, monthly? yearly?). This is part of the chapter [Service Specification, Dates and Deadlines, Terms and Conditions, Organizational Framework, Proof of Performance, Consequences of SLA violations].

5)

By default, the provider shall demonstrate fulfilment of his contract. He has to produce verifiable records of the nature and extent of the services. This is part of the chapter [Service Specification, Dates and Deadlines, Terms and Conditions, Organizational Framework, Proof of Performance, Consequences of SLA violations].

6)

Rules of the relationship will be agreed to, particularly about working hours and standby times. It also needs to be how the order to fix problems will be communicated: automatically via remote maintenance, by email, by telephone or other means of communication. This is part of the chapter [Service Specifica-

390 | 6 Planning and Preparing IS Development

tion, Dates and Deadlines, Terms and Conditions, Organizational Framework, Proof of Performance, Consequences of SLA violations].

6.7.20 Choose: Sources of Information for Requirements Engineering Please check the 3 best sources for Requirements Engineering: 1)

Quality management certification documentation

2)

Direct observation by taking part in everyday business

3)

Requirements specification from competitor

4)

Existing technical and organizational documentation of the company

5)

Industry benchmarks

6)

Vendor marketing material

7)

Programmer experience

8)

Interviews with stakeholders

6.7.21 Order: Agenda of a Good Requirements Workshop Please place the agenda of this requirement workshop in the correct order: a)

Consolidate and agree on requirements

b) Introduction into the topic c)

Analyse context delivering and receiving systems, setting system boundaries

d) Define non-functional requirements in brainstorming e)

Define functional requirements in brainstorming

f)

General inception and setting the rules for the workshop

g)

Summary and next steps

h) Enumerate possible types of requirements that might be collected in the workshop i)

List existing requirements from other workshops or documents that have been done before this one

6.7.22 Close: Possible Measures for Non-Functional Properties Please choose the non-functional requirement, for which the property of a system can serve as a good measure. Hint: four of them are measures for reliability.

6.7 Review Questions for Chapter 6 | 391

1)

Processed transactions per second is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

2)

Availability is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

3)

Screen refresh time is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

4)

Training time is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

5)

Probability of data corruption on failure is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

6)

Number of help frames is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

7)

User/event response time is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

8)

Mean time to failure is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

9)

Probability of unavailability is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

10) Rate of failure occurrence is a measure of [Speed, Size, Ease of use, Reliability, Robustness] 11) Time to restart after failure is a measure of [Speed, Size, Ease of use, Reliability, Robustness]

6.7.23 Close: The Requirements Specification Document Please indicate which chapter of a requirements specification document is described here/in what chapter you would find this information. Every answer is only to be used once. 1) The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System models, System evolution, Appendices] should define the expected readership of the document and describe its version history. 2)

The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System models, System evolution, Appendices] should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems.

3)

The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System models, System evolution, Appendices] should define the technical terms used in the document.

392 | 6 Planning and Preparing IS Development

4)

In the [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System evolution, Appendices], you describe the services provided for the user. This description may use natural language, diagrams, or other notations that are understandable to customers.

5)

The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System evolution, Appendices] chapter should present a high-level overview of the anticipated system structure, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.

6)

The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System models, System evolution, Appendices] should describe the functional and non-functional requirements in more detail. This is the main part.

7)

The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System models, System evolution, Appendices] should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on.

8)

The [Preface, Introduction, Glossary, User requirements definition, System architecture, System requirements specification, System models, System evolution, Appendices] should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions.

6.7.24 Close: Using the Requirements Specification Document Please chose what the following users of a requirements specification document need it and use it for. Every answer is only to be used once. 1)

[System Customers, Managers, System Engineers, System Test Engineers, System Maintenance Engineers] specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.

2)

[System Customers, Managers, System Engineers, System Test Engineers, System Maintenance Engineers] use the requirements to understand the system and the relationships among its parts.

3)

[System Customers, Managers, System Engineers, System Test Engineers, System Maintenance Engineers] use the requirements to understand what system is to be developed.

6.8 Suggestions for Written Exercise or Groupwork for Chapter 6 | 393

4)

[System Customers, Managers, System Engineers, System Test Engineers, System Maintenance Engineers] use the requirements to develop validation tests for the system.

5)

[System Customers, Managers, System Engineers, System Test Engineers, System Maintenance Engineers] use the requirements document to plan a bid for the system and to plan the system development process.

6.7.25 Calculate: Scoring Model for Evaluating Providers and Products Please calculate/write the values for a)–f): Criteria 1= very bad; 10=very good Functions (Sum) Process of article import

K-Catalog

Iconic

Poesis

Weight 38 %

Points –

Score 2,97

Points –

Score 1,88

Points –

Score 1,51

8%

7

0,56

5

0,40

1

0,08

Integration new suppliers

10 %

8

a)

3

0,30

3

0,30

Article management

11 %

10

1,10

8

0,88

4

0,44

Duplicate detection

6%

6

0,36

4

0,24

9

0,54

Search functions

3%

5

0,15

2

0,06

5

0,15

b)

–

2,08

–

c)

–

1,10

9%

10

0,90

5

0,45

3

0,27

Technology standards

7%

9

0,63

6

0,42

4

0,28

Interfaces to ERP

11 %

5

0,55

3

0,33

5

0,55

Performance (Sum)

35 %

–

1,77

–

0,49

–

1,73

Capacity

10 %

10

1,00

d)

0,80

3

0,30

e)

5

0,60

3

0,36

9

1,08

Scalability

13 %

9

1,17

1

0,13

5

0,65

GRAND TOTAL

100 %

Integration (Sum) Number of import formats

Speed

6,82

3,57

f)

6.8 Suggestions for Written Exercise or Groupwork for Chapter 6 6.8.1 Scoring Model for Vendor Selection For the final selection of a vendor for a CAD or PPS (choose one!) IS, you are to construct a decision matrix (= scoring model) in a spreadsheet program like MS-Excel. The real content and numbers might be fictitious. However, please tell HOW you would get the criteria, the weighting and the point distribution in real life.

394 | 6 Planning and Preparing IS Development

6.8.2 Software Creation Process Models For a) waterfall-model, b) Spiral Model and c) SCRUM, please research its advantages and disadvantages. Describe three situations/software creations in a technical company that point to the use of one of these models. In other words: for each model, create a case that this model fits.

6.8.3 Create a “Software Requirement Specification” for a PPS System “Plastally Inc.” produces standard plastic parts for car manufacturers in a highly automated way. They have several manufacturing sites around the world, but buy the basic raw materials (plastics) centrally. Any numbers and content might be fictional. However, the structure and the language should comply with Requirements Engineering as described in this lecture. There needs to be content in this specification relating to the case above. The content can be purely fictional! However, a template with no or generic content will NOT be enough. The presentation should be 10 pages max. with every slide covering one chapter. If there are fewer than 10 chapters in your structure, use 2 or more slides for describing the functional and non-functional requirements.

6.8.4 Write a Business Case Write a business case for a new PPS system with an incremental approach. The accuracy of values is completely irrelevant, just the structure counts. Insert fictional values.

7 Creating and Introducing IS This chapter focuses on the second part of the software creation cycle. It includes methods and tools for modelling applications in detail and explores the different types and ways of testing an application. Finally, we take a short look at the actual introduction of IS into organizations and necessary preparations and strategies. After this chapter, you should be able to …  … choose UML models and diagrams for specific purposes of modelling an IS  … discuss the cost and benefit of customization.  … describe the basic concept of COCOMO II and some parameters that influence the size of a software project.  … distinguish the roles and organization of a software project from other projects like, e. g. building a plant.  … apply a basic model of project risk management with given data.  … translate some characteristics of software quality into practical terms.  … create a simple equivalence and partition boundaries test.  … distinguish unit, system and acceptance testing.  … create a simple scenario test and fill a test case template.  … roughly paint the process of a bug’s life cycle and describe severities and resolutions of bugs.  … describe the role of business process redesign and management in software introduction.  … name some elements of a training plan and the levels of evaluating learning efforts.  … describe cost and benefits of cutover strategies and aptness for specific situations.  … describe the challenges of go-live support and stabilization phase.

7.1 Systems Modelling, Design and Programming This chapter picks up two phases out of the “broad model” of software development presented in chapter 6: The phase of detailed systems design and the phase of programming. In detailed systems design screens, data structure and reaction of the system to certain inputs are fixed. We will not dig too deeply into real programmers writing code; this has to be left to the programmers. Rather, we focus on the actions for standard software like ERP: customizing the software to fit the needs of the organization. An essential part of the software development cycle is project management that accompanies every phase. This chapter will take a closer look at some special features of project management in software creation.

396 | 7 Creating and Introducing IS

7.1.1 Modelling Systems and Architecture The tasks and tools presented in this chapter are focused more on creating (programming) individual applications, since most of these questions will already be answered by buying a particular standard software. However, some of them might also be useful in buying a standard software like ERP. Also, some tools or notations might already be known from earlier chapters (LO’s) and from earlier stages of the software development cycle. That is the nature of a tool or a model. It can be used in different stages of software creation: “Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system. Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation” (Sommerville 2011, p. 119).

The first and foremost task of a model is the fact that it cannot draw the future system in every detail. This would be like a map at the scale 1:1. Rather, it leaves out detail and represents an abstraction of reality. Sommerville (2011, p. 119) also describes systems models as follows:  System modelling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system.  System modelling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modelling Language (UML).  System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.  A system must be modelled from different perspectives, like how the system should be structured, how the system should accompany processes and what other systems and users will it interact with. In this chapter, the various perspectives are clustered into three groups:  “Behaviour” for describing context, processes, interaction, events and sequences  “Structures” for describing classes (= objects), data hierarchies and system structures  “Architecture” for determining what combination of machines will carry out the applications of the system. UML is a family of notational standards that covers all perspectives that might be needed to model a system. It ranges from high level use case diagrams (see earlier

7.1 Systems Modelling, Design and Programming | 397

stages in our broad model of software development in chapter 6) to processes, sequences and classes. To dive deeper into the UML notational universe, please see resources on the net for examples: 1 http://en.wikipedia.org/wiki/Unified_Modelling_Language and http://www.uml.org/

UML 2.2 Diagram

Structure Diagram

Behavior Diagram

Use Case Diagram Class Diagram Activity Diagram Object Diagram

Package Diagram

Component Diagram

State Machine Diagram Interaction Diagram

Composite Structure Diagram Deployment Diagram Profile Diagram

Sequence Diagram Communication Diagram Interaction Overview Diagram Timing Diagram

Fig. 7.1: Available Types of UML Diagrams for Different Purposes (Based on http://www.uml-diagrams.org/uml-22-diagrams.h) There is another important area we cannot cover in this module: Designing software for usability. 1 For a short introduction, look here: http://groups.csail.mit.edu/graphics/classes/6.893/F03/lectures/L1.pdf and the lecture these slides are taken from.

Another almost infinite topic of discussion is the various dimensions of security. This concerns software creation, like built in access restrictions and encryption and every day work issues of managing software, like password policies and firewalls.

398 | 7 Creating and Introducing IS

5 It is strongly advised to treat this issue very seriously and be informed about it. Use the literature cited in the article http://en.wikipedia.org/wiki/Information_security for a starting point.

7.1.1.1 Behaviour Models and Diagrams This chapter will introduce dynamic perspectives of systems modelling, or to put it more simply: models that focus on how the system behaves and how requests are processed. Not all of them can be detailed here; rather we focus on some important diagrams/models: Use case diagrams show who is acting on what processes. They were introduced in raw system design during requirement engineering. Context models simply show the other systems in the environment, not how the system being developed is used in that environment. They are used to illustrate the operational context of a system and show what lies outside the system boundaries. For example, if our system is a CAD application, the PPS system would be outside our system, but still influence the operations of our systems, e. g. if they are connected by an interface. The following figure shows, for the system “Medical Health Care-Patient Management System”, the surrounding systems that are its context. While not explicitly written in this figure, you might want to try to find out for yourself what the connections might be.

system Patient record system system Management reporting system

system Admissions system system MHC-PMS

system HC statistics system

system Prescription system system Appointments system

Fig. 7.2: Systems Context for the System MHC-PM (Based on Sommerville 2011, p. 122)

7.1 Systems Modelling, Design and Programming | 399

Process Models show how the system being developed is used in broader business processes. Different process modelling notations were already discussed in chapter 1 and do not have to be repeated here. We will just add one more standard that was not detailed in chapter 1: UML activity diagram. UML activity diagrams may be used to define business processes. The following figure shows a process of an involuntary detention of a crime suspect drawn in the form of a UML activity diagram. Start Confirm detention decision

Transfer to police station

Find secure place

Inform social care

(available) Inform patient of rights

(dangerous)

Inform next of kin

End

Update register

Record detention decision (not dangerous)

system MHC-PMS

Transfer to secure hospital

Admit to hospital

system Admissions System

system MHC-PMS

Fig. 7.3: UML Activity Diagram for the Process of Involuntary Detention (Based on Sommerville 2011, p. 123)

   

First, the detention decision is confirmed. Once the detention decision is confirmed, the patient will be informed about his rights and the detention decision is recorded in the system. In the next step, the process splits at the branching point, “dangerous or not dangerous”, and follows different paths. Once the detention is accomplished in one of the branches, there are three operations, one of them affecting the system.

Sequence diagrams are used to model interactions between the actors and the objects in a system and the objects themselves. A sequence diagram literally shows the order and sequence of interactions during a case (Sommerville 2011, p. 127).

400 | 7 Creating and Introducing IS

Finally, there is another form of diagram not targeted on organization or persons, but purely on data: data flow diagrams describe which data is interchanged by the objects and from where they come. The objects in the following figure are use cases and the arrows show what data is collected and produced by those use cases/events.

RequestedCourses Student

1.0 Verify availability

Accepted/ rejectedselections

Opencourses

Course file

Coursedetails Courseenrollment

Confirmationletter 2.0 Enroll student

Student master file Student-details

3.0 Confirm registration

Fig. 7.4: Data Flow Diagram for a Mail-In University Registration System (Based on Laudon (2013), p. 533)

What diagrams are useful for describing the behaviour of a system? This depends entirely on the system to be described and how much time and effort an organization wants to spend on them.

7.1.1.2 Structure Diagrams Structure diagrams force functions and objects in a hierarchical order and clarify their relationship to each other. In this chapter, some forms of structural representation are described in short. The first figure shows a very simple example of a hierarchy of functions. The diagram reads like this: in order to process a payroll, we need to get valid inputs, calculate the pay and write an output. In order to get valid inputs, we need to first get the inputs, but also validate the inputs, and so on. This breaks down general functions to small elements that need to be realized later in programming.

7.1 Systems Modelling, Design and Programming | 401

Process payroll

Get valid inputs

Get Inputs

Calculate pay

Validate Inputs

Calculate gross pay

Write outputs

Calculate net pay

Update master file

Write checks reports, and output files

Fig. 7.5: Hierarchy of Functions (Based on Laudon (2014), p. 534)

Besides their functions, objects have to be classified, as well. Such a hierarchy of types does not read like functions, “in order to accomplish (superordinate) function we need to accomplish the following (subordinate) functions”. Rather, the relationship will be expressed in structural, logical terms like: “All bolts are screws but not all screws are bolts”. The figure below illustrates such relations: a hospital doctor and a general practitioner are both doctors. Consultants and team doctors are both hospital doctors. Doctor

Hospital Doctor

Consultant

General practitioner

Team doctor

Trainee doctor

Qualified doctor

Fig. 7.6: A Generalization Hierarchy (Based on from Somerville (2011), p. 132)

Please note that this hierarchy does not describe “real facts”. It describes how the artificially created and defined objects “Doctor” and “Consultant” relate to each other. Another hospital software development team might define them and their relations differently, or they might define the same characteristics and relation-

402 | 7 Creating and Introducing IS

ships, but give objects different names. They might choose to name the “doctor” in the figure a “medical professional”. This way of structuring resembles a classification system in mechanical terms (see chapter 3) and these objects are indeed called “classes” in software code. While this vertical structuring in itself might be useful, it also has very practical logical implications: subclasses (also called child classes) inherit their characteristics from superclasses (also called parent classes). Subclasses might add some characteristics of their own, but they all have the characteristics of their superclass.

Employee Id Name Adress dateHired Position pay

Salaried

Hourly

Temporary

Annual Salary Bonus

hourlyRate overtimeRate

dailyRate ytdHours

calcBonus

calcOvertime

determinePermEligibilty

Fig. 7.7: Class Inherit Diagram (Based on Laudon/Laudon (2014), p. 535)

 





An employee has an ID, a name, an address, a date hired and a certain position in the organization. Among other things, he gets a form of pay. There are several types of payment for an employee. One type might be a salaried pay. Any employee that is classified as salaried pay has, of course, all characteristics of an employee inherited from its superclass. However, two additional characteristics, like a field for the annual salary and the bonus might be added. There might be more than one form of calculating a bonus, so the salaried employee might father child classes of salaried employees with different forms of bonuses. The same enrichment with additional characteristics is done for employees with hourly or temporary pay.

7.1 Systems Modelling, Design and Programming | 403

The structure diagrams above deal with vertical relationships of objects or classes. There is also a need to clarify the horizontal relationships between classes (=objects) that are not direct relatives in the parent-child relationship described above. UML provides a special type of association between classes called “aggregation”: One object (the whole) is composed of other objects (the parts). To show this, we use a diamond shape next to the class that represents the whole. The following figure shows that a patient record is a composition of exactly one patient and an indefinite number of consultations represented by “1..*”.

Patient record

1

1

1

1..*

Patient

Consultation

Fig. 7.8: Aggregation of Two Unrelated Classes to Form a New Class (Based on Sommerville (2011), p. 113)

Try for yourself to relate the following classes for material Management: Material, Price/Conditions, 5 Supplier.

Again, it is up to the company which combinations of diagrams they choose.

7.1.1.3 Systems Architecture Architectural design can be described as the way a system is organized and structured. It is concerned not only with application software, but especially with hardware and what actors and machines carry out what functions. It also shows the relationships between the components. Just from this basic description, it is clear that it must also be part of the requirements engineering. Like business planning and the functions of the system in requirements systems, architecture might be crafted in a raw version earlier in the stage of the software development cycle (especially requirements engineering). Architectural design might show a system to be developed, but also how an existing system is structured. It is also used on two different levels: it might describe all the parts and machines of an entire organization or for a single information system. This chapter focuses on the latter.

404 | 7 Creating and Introducing IS

The following figure shows an abstract model of the architecture for a packing robot system with the components to be developed.

Vision System

Object Identification System

Arm Controller

Gripper Controller

Packaging Selection System

Packing System

Conveyor Controller

Fig. 7.9: Architecture for a Packing Robot System (Based on Sommerville (2011), p.149)

This robotic system can pack different kinds of objects. It uses a vision component to pick out objects on a conveyor, identify the type of object, and select the right kind of packaging. The system then moves objects from the delivery conveyor to be packaged. It places packaged objects on another conveyor (Sommerville 2011, p. 149). The graphical representation of systems architecture might get quite complex, since it will comprise hardware (like servers, RFID readers, mobile devices) and software elements (database), as well as the connecting technologies. Take a look at this example of a complex architecture for a real-time tracking system, in which RFID chips supply information about storage information on demand to all shipping parties involved: http://www.emeraldinsight.com/content_images/fig/1770120305003.png  The architecture in this example roughly consists of three parts. The lower part describes the application and the associated database functions.  The part in the upper left describes the technical connections to terminals and devices outside the company. The connections are realized via the internet using a virtual private network (VPN).

7.1 Systems Modelling, Design and Programming | 405



The part in the upper right describes the architecture in the physical warehouse of the company. Information about stored and moved goods is fed back via the hub-processor into the system.

How can architectural design be practically achieved? Sommerville suggests seeing architectural design not as a fixed process or a set of activities, but rather as a consideration about some fundamental practical decisions on the structure of the system (Sommerville 2011, p. 151):  Is there a generic application architecture that can act as a template for the system that is being designed?  How will the system be distributed across a number of cores or processors?  What architectural patterns or styles might be used?  What will be the fundamental approach used to structure the system?  How will the structural components in the system be decomposed into subcomponents?  What strategy will be used to control the operation of the components in the system?  What architectural organization is best for delivering the non-functional requirements of the system?  How will the architectural design be evaluated?  How should the architecture of the system be documented? We will not dig deeper into this special IT topic, since mechanical engineers will not often be involved in designing IS architecture. However, as more and more components of machinery become 1 digital, it might be an area of interest. There is plenty of material available – even a book about IT architecture from the “for dummies” series.

Every real system has its own architecture that is somehow unique; however, that does not mean that they each are created on unique individual principles. There are some basic generic patterns an IS architecture might follow (Sommerville 2011, p. 155164):  The Model-View-Controller (MVC) pattern is the base in many web-based applications. It separates presentation and interaction from system data. These systems are structured into three logical components that interact with each other. The model component manages the system data and associated operations on that data.  Layered Architecture is used to model the interfacing of sub-systems. It organises the system into a set of layers (or abstract machines), each of which provide a set of services. It supports the incremental development of sub-systems in different layers: when a layer interface changes, only the adjacent layers are affected.

406 | 7 Creating and Introducing IS 



In the repository approach, all data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository. Two very important architectural patterns were already described in this module: the client-server architecture that is the base of most ERP systems was described in chapter 4 and the current approach of a Service Oriented Architecture (SOA) in chapter 3.

Each of these general/generic patterns has benefits and disadvantages and the question “Which one is the best?” can only be answered by a clear: “It depends!” It depends on the applications to be supported, the size and speed needed, and so on. So, the requirements of the information system will help in choosing the patterns of architecture, and ultimately, in designing the actual architecture for the application to be developed. As described in chapter 6, not all goals and requirements (performance, security, safety, availability, etc.) can be reached at the same time and some goals are directly conflicting. Focus on critical requirements shows the basic direction in which the architectural design should go (Sommerville 2011, p. 152f):  Focus on Performance: The architecture should be designed to localize critical operations within a small number of components, with these components all deployed on the same computer rather than distributed across the network. This may mean using a few relatively large components rather than small, finegrain components, which reduces the number of component communications. You may also consider run-time system organizations that allow the system to be replicated and executed on different processors.  Focus on Security: A layered structure for the architecture should be used, with the most critical assets protected in the innermost layers, with a high level of security validation applied to these layers.  Focus on Safety: The architecture should be designed so that safety-related operations are all located in either a single component or in a small number of components. This reduces the cost and problems of safety validation and makes it possible to provide related protection systems that can safely shut down the system in the event of failure.  Focus on Availability: The architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system.  Focus on Maintainability: The system architecture should be designed using fine-grain, self-contained components that may readily be changed. Producers of data should be separated from consumers, and shared data structures should be avoided.

7.1 Systems Modelling, Design and Programming | 407

7.1.2 Programming and Customizing For non-professionals, this is viewed as the core of software creation: writing the code for individual software or setting the parameters to customize standard software. However, it is just a small part of software creation, as can be seen in our broad model in chapter 6. Since this module aims at covering both the use of standard programs and the creation of individual software, this chapter will take a quick look at both:  writing code (programming) and  changing variable parts of a standard software (customizing).

7.1.2.1 Software Programming As described in the “broad model” of chapter 6, the actual coding is a rather small part considering the voluminous work on the requirements and the preparation. Pure coding is sometimes outsourced or even offshored, e. g. to India. In this chapter, we will not discuss programming languages in detail nor will we start programming itself. There are countless programming languages that can be researched on the web, e. g. here: http://en.wikipedia.org/wiki/Programming_language http://griffsgraphs.files.wordpress.com/2012/07/programminglanguages_label.png Like any other tool, every programming language has its advantages and disadvantages. They were created at different times, for different hardware and different purposes. There are two languages that dominated mainstream programming in the new millennium: C++ and Java. For industrial applications and computer controlled machinery, there are special languages like Kuka Robotic Language or G-code for CNC Machines. For a basic description of G-code, see: http://atyourservice.haascnc.com/expert-tip/an-introduction-to-g-code/ In most IS architectures, there are separate modules that might be programmed in different languages, but work together via standardized interfaces (see chapter 3).

7.1.2.2 Customizing Standard Software like ERP Systems So-called standard software mostly needs to be adjusted; however, this occurs in a wide range of intensity. It starts with setting the options in an office application (e. g. the toolbar in the user interface) and ends in programming additional modules and interfaces, e. g. in SAP’s own programming language ABAP. “Plain vanilla” (a technical term used by IT specialists) implementations that do not change anything in the standard package are possible, but standard implementations have their disadvantages and issues in return.

408 | 7 Creating and Introducing IS

For a fresh standard SAP installation, there is a 300-page guide by SAP for how to customize the system to your needs, called “Implementation Guide for R/3 Customizing (IMG)”, which can be obtained here: http://help.sap.com/saphelp_46c/helpdata/en/e0/71369adc56d11195100060b0 3c6b76/frameset.htm or as a normal document here: http://de.scribd.com/doc/ 7214469/SAP-Customizing Here are just a few examples of what there is to do in customizing:  The real company structure needs to be expressed in SAP objects, e. g. defining our warehouse in Hamburg as a SAP storage location (see chapter 4).  Languages, currencies and colours have to be assigned, e. g. setting everything to €.  Roles and rights need to be defined, e. g. what transactions a strategic purchaser is allowed to execute.  Decide what fields to use and what to show in certain data views and transactions, e. g. hiding standard fields that are not applicable to our business at all. These are just a few examples of setting the options, when no code of the software needs to be changed. Nevertheless, this is called “customization” in SAP speak. Customizing workflows to fit company processes goes one lever deeper: SAP, for example, offers a tool that allows to draw processes in an EPK-like style (See chapter 1), which will be then translated into code. 5 For example, we want to add a field for “confirmation of compliance” by the purchaser built into the workflow of ordering materials that is only checked once the supplier has signed a sheet of compliance. Please search the web for “SAP Workflow Builder” to see what this tool looks like and how it works. Go beyond simply setting the parameters by creating new data objects.

SAP tries to minimize this kind of customizing by offering preconfigured packages for different industries: banks and chemical companies, for example, will be offered preconfigured industry solutions by SAP right away, see: http://help.sap.com/industries. Even deeper goes individual customization with changing the code of the standard application and programming separate additional elements and modules. The following figure shows that customization, in the sense of changing code, is a reality of companies that use ERP systems: almost 50 % have done some or significant customization.

7.1 Systems Modelling, Design and Programming | 409

2% Minor customization (1-10%

4%

of code modified) 10% Some customization (11-25%

36%

of code modified) Significant customization

23%

(26-50% of code modified) No customization 25%

Fig. 7.10: Level of Customization (http://panorama-consulting.com/the-long-term-effects-of-heavy-erp-system-customization)

The question of how much of the system should be customized or whether a plain vanilla approach should be pursued, involves several issues:  ERP customization can create problems during implementation: The more the system needs to be customized, the less it can rely on the tests, experiences and the standards of the software. Also, it seems to be not optimal if the system needs to be changed radically in order to fit the current process, while many other companies seem to work fine with it: maybe the processes and the organization need to be changed. Also, customization will consume a considerable amount of budget for consultants and within our organization.  ERP customization can create problems after implementation: Upgrades might become more difficult, since the customized code needs to be rewritten to support newer versions of the software. This leads to an unpleasant choice: changing entirely to another, newer software and throwing away all customizations, or putting a lot more money into current customization.  On the other hand, plain vanilla ERP systems can create strategic disadvantages: ERP systems always involve trade-offs of flexibility versus standardization: a single system for all company functions and departments versus a best of breed approach for each function individually. If we use the system exactly like the vendor planned and all other competitors do, our strategic advantage and individuality might vanish.

410 | 7 Creating and Introducing IS

A customization plan for a big ERP system might as well be as detailed and demanding as a project plan for creating individual software from scratch. See chapter 7.2.3.3 for a deeper discussion of how to organize the actual implementation and customization phase.

7.1.3 Special Aspects of Project Management for Creating IS The creation and introduction of a big software system has all theoretical characteristics of a project, and they are explicitly organized as projects most of the times. Most literature about project management actually deals with IT projects or cites them as examples. In IT projects, all typical problems of projects show in high intensity. 1 Since there are separate classes and books on project management and it is just a small part of our overall learning objectives, we cannot replicate a complete project management module. There are models of good project management, especially for IT projects. They systematize and discuss different aspects of project management and suggest tools. Please research the terms “Prince II” or “PMBOOK” if you are interested in project management frameworks. Also, SCRUM (see chapter 6) shows how to organize software projects in an Agile way.

We’ll just focus on some specialties or interesting points in the management of software creation along the typical phases of project management.

7.1.3.1 Project Planning and Estimation Techniques In order to reach the goals of a software project, the project and its single tasks need to be planned. Project planning and creating a Gantt chart with dates of when to start certain tasks consists of three distinct steps: 1. First, the overall project goal will be systematically broken down into work packages and single tasks. The systematic disaggregation of an overall goal, like “Buying and implementing new CAD software”, is the same as you learned about in chapter 6 when creating a scoring model. The result is called a Work breakdown structure (WBS) and graphically, it looks like an upside down tree. 2. The single tasks, or the “leaves” of the tree, if you will, can be accomplished by a single person in a much shorter time than the overall time of the project. A typical single task in an ERP Project might be e. g. changing the options of the new program to the pre-sets we desire, like our country, measurement units, desired colour scheme, and so on.

7.1 Systems Modelling, Design and Programming | 411

3.

This single tasks will be described more closely with at least three parameters: how long will the task take, who is responsible for it and what other tasks need to be finished before this task can be started? Having all the information about every single task, the optimal order of tasks for minimum project duration can be calculated. This is done by the algorithm called critical path analysis (CPM). It places the steps in order – taking into account their necessary predecessors and finding the shortest way to finish the project. This can be done by hand, or by programs that automate the CPM algorithm, like MS Project or freeware like http://gantter.com/.

This is basic project planning, which can be studied in any book or chapter of your choice about project management. For an in-depth view, please look at the current edition of J. Marchewka’s “Information technology project management” that is cited in this chapter. In the second step listed above, information is needed that is usually very hard to get: how long will the task take, or to be more precise: what is the work effort (in man days and in overall time) needed to fulfil this task? In software creation, this is a difficult thing to answer both on the overall level of software and on the level of single modules or tasks. Theory and practice of IT project management have found several tools and concepts to improve those estimations. Marchewka (2013, p. 158ff) lists the following methods of finding out how long a certain work package or task of programming will take:  “Guesstimating” is really taking a guess on the numbers. It is based on feeling rather than on facts. Although often used, it is not very professional and cannot be called a method at all.  The Delphi Technique involves several experts on a topic that estimate the same item. Then the results are redistributed to them and they discuss the differences to finally agree on a value or take an average of their opinions.  Time Boxing very rigidly assigns a certain time for a task. It takes the risk that the task will not be completed and just what is completed will be available after the allocated time.  Top-Down Estimation starts with time and cost for whole project allowed. The leaders of project parts or certain modules then have to distribute these imposed numbers further down the line. This can be very effective when done with a realistic view of the realities of the project and the capacity of the staff involved. Unfortunately, many companies use the top-down approach to enforce unrealistic expectations on the time or resources used (e. g. 50 % less time than known to be somewhat appropriate) and to get the most out of project members and suppliers. Very drastically, those projects can lead into so called “death march projects” that are doomed to failure.

412 | 7 Creating and Introducing IS 





Bottom-up estimating lets individuals responsible for certain tasks estimate the effort/work for their tasks. This could yield a realistic number for the work needed. However, there needs to be a culture of openness and a good relationship with the programmers and project workers involved. Otherwise, they might exaggerate the time needed to complete their task to build in large safety margins for themselves. On the other hand, they might underestimate the effort needed to get the job done and take longer and bill the customer (or the business department) extra according to extra time and material. Analogous Estimates from past experiences are always a good support for any estimation. No IT project is the same, but they might be similar. They are a good way to check other methods described above. Parametric calculations are the best, but also the most costly estimations, when there is no idea how much effort (man-days) a new software application will take. Function point is a classic tool of parametric calculation and COCOMO II added more refined parameters to it. It will be explained in chapter 7.1.3.2.

Another important piece of information for every task is listing its predecessors – that means documenting which other tasks have to be fulfilled before this one can be started. Unfortunately, project members think too little in advance about what they need from other teams or functions. It is advisable to let each member know that this is absolutely crucial. If they do not tell what they need from others to execute their tasks, they will have no guarantee that these prerequisites will be ready when they need it.

7.1.3.2 COCOMO as a Model of Parametric Estimation Probably the best, but also the most costly, way of estimating a completely unknown software project is parametric modelling. It uses certain parameters of the software to be created to estimate the work needed to program it. A well-established variant is called COCOMO II (Constructive Cost Model v.2). For all parameters used in this model, there are plenty of benchmarks and examples, so they do not need to be guessed. The basic formula states that the effort of a project or module measured in man days is a function of the: a) Size of the Software, b) process scale factors to calibrate the size of the project and c) the effort multipliers that tell how easy/difficult it will be to realize the project of the size calculated by a) and b): Effort = SizeProjectScaleFactors*Effort Multipliers Project Scale Factors and the Effort Multipliers are both called “cost drivers” sometimes – a term we will not further use, since we want to distinguish the two different factors right away. Without going to deep into the math behind it, we will just have

7.1 Systems Modelling, Design and Programming | 413

a brief look at the parameters and how they are calculated. Please note: the “Project Scale Factors” are sometimes also called “Process Scale Factors”. The basic size of a software application is expressed in lines of programming code. To get the number of lines of code, the so called function point method is applied. The function point method is a basic method of parametric estimation that is also used stand alone or in other calculation frameworks outside COCOMO. It counts the inputs, outputs, internal files, etc. as described in the following table: Table 7.1: Parameters of the Function Point Method to Calculate the Basic Size of a Software (Baik (1998), p. 18) External Input (Inputs)

Count each unique user data or user control input type that (i) enters the external boundary of the software system being measured and (ii) adds or changes data in a logical internal file.

External Output (Outputs)

Count each unique user data or user control output type that leaves the external boundary of the software system being measured.

Internal Logical File (Files)

Count each major logical group of user data or control information in the software system as a logical internal file type. Include each logical file (e. g. each logical group of data) that is generated, used, or maintained by software system.

External Interfaces Files (Interfaces)

Files passed or shared between software systems should be counted as external interface file types within each system.

External Inquiry (Queries)

Count each unique input-output combination, where input causes and generates an immediate output, as an external inquiry type.

Each of these inputs, outputs and logical files will result in a different amount of code to write. Also, it depends on how complex, for example, an “internal logical file” is. To catch all this information, points are given to a specific object of a certain complexity. For example, an internal logical file of low complexity will get 7 points, medium complexity 10, and high complexity 15 points. Counting all these points together, there might be a total sum of 1431 (arbitrary example) points. In the last step, these points are translated into lines of code, depending on what programming language will be used. For example C++ will produce 29 lines of code per point, while the older COBOL language needs 91 lines per function point. The size will be 41.499 in C++ and 130.221 if COBOL will be used. Lines of code are a measure of size and the work that will be needed to estimate a software project. Project scale factors adjust the basic size of the software project calculated above. We do not want to know about a typical application to be built, but rather our application in our organization. Our application will always be special in some way.

414 | 7 Creating and Introducing IS

To calculate the project scale factor, standard scoring tables are used and points are awarded for certain circumstances. The table below shows some of these scale factors, how they can be rated, and what points are awarded for the rating. In the overall formula, these scale factors will be comprised in one big formula in the end to form the variable “Scale Factors” described in the COCOMO formula. To pick just one of the many scale factors: the precedentedness (abbreviated PREC) rates how familiar the project and application is to the organization that builds it. If it is completely familiar to us, like just updating an important interface, the project will be less difficult and the basic project size will not need to gain weight (factor=0.00). If completely unfamiliar, it will gain a lot of weight (factor =6.20). These factors are taken from a database in which a lot of real project experiences and surveys are comprised. They can be represented in the form of tables, and COCOMO literature also helps to judge what it means when a project is “familiar”. There are three tables for different stages of estimation: a) Application Composition Model (earliest phase with prototyping), b) Early Design Model in which basic decision already have been made and c) Post-Architecture Model in which the information is accurate and detailed. The following figure shows the scale factors and the standard values for the early design phase (a): Table 3.3: Project Scale Factors for COCOMO II View 1 (Based on Boehm (2006), p. 12) Scale Factors

Very Low

Low

Nominal

High

Very High

Extra High

Precedentness (PREC)

Thoroughly unprecedented

Largely unprecedented

Somewhat Unprecedented

generally familiar

Largely familiar

Thoroughly familiar

rigorous

Occasional relaxation

Some relaxation

General conformity

some conformity

general goals

Little (20 %)

Some (40 %)

Often (60 %)

generally (75 %)

mostly (90 %)

full (100 %)

very difficult interactions

some difficult interactions

Basically cooperative interactions

Largely cooperative

Highly cooperative

Seamless interactions

Development Flexibility (Flex) Architecture/risk resolution (RESL) Team Cohesion (TEAM) Process maturity (PMAT)

Weighted average of “Yes” answers to CMM Maturity Questionnaire

7.1 Systems Modelling, Design and Programming | 415

The result of the generic basic size powered by the scale factors is the size of the project under the specific circumstances in this specific organization with the resources available in this organization. Although this interim result has no name in COCOMO, we shall call this the “Scaled Project Size”. Finally, the scale project size is multiplied with the so-called effort multipliers. They describe factors about the software product to be built, the platform, the personnel, and so on. There are 17 single factors, which can be grouped like in the table below. Table 7.2: Effort Multipliers for COCOMO II (Baik (1998), p. 22ff.) Product Factors

DATA – Data Base Size CPLX – Product Complexity RELY – Required Software Reliability RUSE – Required Reusability DOCU – Documentation match to life-cycle needs

Platform Factors

TIME – Execution Time Constraint STOR – Main Storage Constraint PVOL – Platform Volatility

Personnel Factors

ACAP – Analyst Capability PCAP – Programmer Capability AEXP – Applications Experience PEXP – Platform Experience LTEX – Language and Tool Experience PCON – Personnel Continuity

Project Factors

TOOL – Use of Software Tools SITE – Multisite Development SCED – Required Development Schedule

We will just zoom into the product factors to explain what they describe (Baik 1998, p. 22ff): DATA: Data Size. This measure attempts to capture the effect large data requirements have on product development e. g. testing. The rating is determined by calculating D/P, where D is the number of bytes of data in the database at the end of (and necessary for) testing and P is the number of SLOC. DOCU: Documentation match to life-cycle needs. This cost driver captures the suitability of the project’s documentation to its life-cycle needs. CPLX: Product Complexity (CPLX). This is the combination of areas that characterize the complexity of the product or a sub-system of the product, such as control operations, computational operations, device-dependent operations, data management operations, and user interface management operations. The complexity rating is the subjective weighted average of these areas utilizing the table at the end of this document.

416 | 7 Creating and Introducing IS

RUSE: Develop for Reuse. This cost driver accounts for the additional effort needed to construct components intended for reuse on the current or future projects. RELY: “Required Software Reliability (RELY). This is the measure of the extent to which the software must perform its intended function over a period of time.”

We will pick out just one of the factors to show how it will be rated: the factor of Required Software Reliability (RELY). This is the measure of the extent to which the software must perform its intended function over a period of time. If the effect of a software failure is only slight inconvenient, then RELY is low. If a failure would risk human life, then RELY is very high. Table 7.3: Rating Table for the Effort Multiplier RELY (Required Software Reliability) (Baik (1998), p. 22)

RELY

Very Low

Low

Nominal

High

Very High

slight inconvenience

low, easily recoverable losses

moderate, easily recoverable losses

high financial loss

risk to human life

For “very low” to “very high” there are tables with points to be awarded. All factors will then be put together to form the effort multiplier. For a complete example of a COCOMO calculation, see http://www.codeproject.com/Articles/9266/SoftwareProject-Cost-Estimates-Using-COCOMO-II-Mo Although most mechanical engineers will not be involved in COCOMO calculations, it is good to know about the influencing parameters of the effort to program software in a specific environment in a specific variant and how these efforts are rated.

7.1.3.3 Project Organization and Team Members In this chapter, we will just take a short glimpse at some specialties of IS project management concerning organization and staff. One special feature of software project management is the fact that there are always four important roles (three for management plus the users) involved in executing the project work (Motiwalla/Thompson 2011, p. 252):  The Project Manager, who is sometimes supported by a Program Management Office (PMO) in big projects.  Software Module Experts are responsible for analysing requirements and converting them into solutions within the software. They provide direction and application knowledge with respect to business process design, configuration, testing, training, and implementation.

7.1 Systems Modelling, Design and Programming | 417





Subject Matter Experts (SMEs) provide coordination and facilitation of communications between the project team and the organization. SMEs coordinate and prioritize functional requirements. SMEs provide leadership and functional expertise in support of the implementation with specific knowledge in one or more business processes. Users and internal IT-Staff will later use and maintain the system. They will deliver requirements, tell about how they do the processes, and are trained on the system.

This needs to be considered in the organization of the project. Project management, module experts and SME’s can come from three organizations:  The software company or the software vendor  An independent consultant company  From within the company, for example from the internal IT department. Each source of personnel might have its advantages and disadvantages. Many companies choose a mix to optimize the competencies and optimize the organisation of the project work. There are many interesting questions and conflicts that might arise here: For example, a SME might also be responsible for a certain part of the software, e. g. the e-procurement part of a heavily customized ERP. He is also responsible for managing the external supplier of this module, e. g. a module expert and two programmers. However, he does not yet have that much experience in project management and especially software projects. On the other side of the table, the software vendor is a project specialist, seasoned in many projects. There is a high risk that the internal SME is not on par with the external specialist. The external manager from the vendor might take advantage of that, e. g. by talking the SME into lowering of standards in requirements or a more relaxed time schedule. There are more roles in large scale software projects, like in the introduction of an ERP system. Motiwalla/Thompson (2012, p. 132 f.) give an overview of the roles for ERP implementation. In large technical projects, like a software introduction, there is always a mix of very different kind of people from different professions. They come from a different professional culture that can be equally different as national cultures. To put it bluntly: software engineers coming from India and from Germany might sometimes understand each other better and are closer in their approach to work than a software engineer and a legal counsel from Germany. Scientific research mostly agrees that interdisciplinary teams can work very effectively with above average creativity, if these cultural differences are managed properly. They have a higher rate of failure if those differences are not considered and managed. Besides having a professional project manager, the quality of the working environment is an important success factor. Motiwalla/Thompson (2012,

418 | 7 Creating and Introducing IS

p. 254) describe some points that help in creating an effective working environment in ERP software projects: A software project should not just somehow begin. It should be opened with a team building event that binds inside and outside personnel, as well as software and functional staff. There is literature about events, and even games that help to break the ice and start forming a real team. Also, the different goals and mind-sets of technical and functional staff will cause friction that needs to be balanced. The goal of the technical staff is to implement a solid and reliable ERP system infrastructure; whereas the goal of the functional staff is to ensure that the ERP system works as defined. Functional staff will want several ERP system instances in which to test and validate the system. In almost every study about the success of software creation and implementation, commitment of senior management during the whole project is vital, not just at the starting event. This especially means supporting the project in times of conflict with functional management. For example, the sales reps need to take part in a requirements workshop. They have a lot to do in their regular job and they just do not attend. The project manager asks the sales manager to motivate and order his staff to join the workshops, but the sales manager does not do it. It’s vital that senior management (like the CEO) show support to the project when it is really needed. Staff and professional consultant turnover happens in every project; some will leave and some will join. An undesirable, but common, practice of software vendors is to exchange their staff like this: the very competent consultant attending at the meeting where the software was sold is only involved in the start-up of the project. She is then replaced with a less competent colleague, who will, however, still do the job properly. Then, there is a delay in the project and this person is already staffed on another project of the vendor and somebody completely new comes in. Also, regular turnover of the customer’s staff might be common. Project management needs to minimize the negative effect of knowledge going away and minimize the cost of introducing new members. A first step is good ongoing documentation in the way of a “project handbook” on the intranet that explains procedures, templates, goals and tools of the project to newcomers.

7.1.3.4 Controlling and Risk Control in Software Projects In this chapter, we will have a short view on two aspects that are relevant in the execution phase of most projects, and which become especially relevant in IS projects:  How can the state of completeness of single tasks and work packages be measured and how can the “almost done” phenomenon be avoided?  How can project risks be communicated and steered?

7.1 Systems Modelling, Design and Programming | 419

Once the project plan is completed and the project is running, project controlling sets in. One of the most important pieces of information for project controlling is measuring the state of completeness of single tasks that are tracked in the project plan. The state of completeness will be entered in a column named “% work completed”. This information, together with the time and money spent so far, can be used to calculate several other important numbers, e. g. a prognosis of the real end date and the money spent at the end of the project. Also, deviation analyses about the planned and real state of completion can be calculated with this information. The prominent instrument for doing this is called “Earned Value Analysis” and is described in project management literature. In any case, the identification and documentation of the true state of completeness of single work packages or tasks is the base for all calculations described above. There is, however, a strange phenomenon in the practice of software engineering and software project work that complicates matters: the so called “95 %” or “almost done” syndrome. It can be shown by asking software engineers, at various points of time in the duration of their work package, about the state of completeness of their work package. Subjective state of completion by developer

Planned end Date

mid-term

100 90

90

95

98

98

95

98

99 98

80 75

70 60 50

50

40 30

30

20 10

10

0 Course of project/time

Fig. 7.11: The 95 % Syndrome in Documenting the State of Completion

Let’s assume a work package, like programming an interface, is planned with 30 days of work. Every day, the developer will enter the state of completion from his view. Most likely, he will announce a state of completion already after midterm on

420 | 7 Creating and Introducing IS

day 15. However, during the next 15 days, the task will remain at approximately 95 % in his reporting. Most of the time, it will stay under 100 %, even for some time after the deadline. This is a delay without warning, and the project manager cannot do anything about it once the deadline is close or crossed. The reason for this overly optimistic assumption lies within human psychology: not incorporating the Pareto Principle in estimations. The Pareto principle is widely known and understood by most professionals: 20 % of the work will yield 80 % of the results, and the last 20 % to perfection is the hardest to achieve and takes 80 % of the effort. However, when estimating progress and completion of a task, this principle is not anticipated. It sure looks like, at 20 % of the time 80 % of the job is done and 95 % is complete after half of the total time. However, a software module is digital – either it works or it does not. So, the last 5 % of the work to achieve 100 % completion and quality are grossly underestimated in time. One solution chosen by project managers is simply not to allow a state of “almost done” (95 %) anymore. They will just report four discrete states of the work packages: 0 %: Not started yet, 20 %: Started and achieved some results, 40 % in the middle of the work and 60 % for all other states of completion – including “almost done”. During the last 10 years, risk evaluations and risk management have pervaded many aspects of business planning, management and controlling. Professional software project management has always included some form of risk evaluation and risk management. No plan is without risk and the tight, complex interactions of IS projects is highly affected by possible risks. You will find several books about “Software Engineering Risk Analysis and Management” if you enter this term in a search engine. To put it very shortly here, there are two independent steps in risk management:  Finding and evaluating risks  Deciding on how to handle risks and controlling the necessary measures. Risks can occur in every part of the project plan and the requirements. Finding and evaluating risks is the first step of risk management. It can be done by brainstorming or in a more systematic way. The result will be a table of risks considered with two important parameters:  First: How high is the probability of the problem occurring? Expressing a probability in percentages bears all the problems of probability estimations that you might be aware of from statistics.  Second: How severe will the effect/impact be if the problem actually hits? Expressing the possible severity/impact in points bears the problems of converting, for example, a negative financial impact or, even injuries to humans, into points. The following table shows an example of a risk table with potential risks evaluated.

7.1 Systems Modelling, Design and Programming | 421

Table 7.4: Risk Table (Sommerville (2011), p. 600) Risk

Probability

Effects

Organizational financial problems force reductions in the project budget (7) It is impossible to recruit staff with the skills required for the project (3) Key staff are ill at critical times in the project (4)

Low

Catastrophic

High

Catastrophic

Moderate

Serious

Faults in reusable software components have to be repaired before these components are reused (2)

Moderate

Serious

Change to requirements that require major design rework are proposed (10) The organization is restructured so that different management are responsible for the project (6)

Moderate

Serious

High

Serious

The database used in the system cannot process as many transactions per second as expected (1)

Moderate

Serious

The time required to develop the software is underestimated (12 ) Software tools cannot be integrated (9)

High

Serious

High

Tolerable

Customers fail to understand the impact of requirements changes (11) Required training for staff is not available (5)

Moderate

Tolerable

Moderate

Tolerable

The rate of defect repair is underestimated (13)

Moderate

Tolerable

The size of the software is underestimated (14)

High

Tolerable

Code generated by code generation tools is inefficient (8)

Moderate

Insignificant

Try it yourself by placing these risks in a matrix. The next figure is an example of its own and does 5 not use the table above!

Typically, the single risks are placed in a risk matrix according to their scores in each dimension (probability and impact). Here, you can see a screenshot of a project management tool that will draw a risks matrix from risk entered in the table on the left side of the figure:

422 | 7 Creating and Introducing IS

Fig. 7.12: 07.12 – Software for Creating a Risk Matrix (http://www.intaver.com/images/RP_Product_RiskMatrix.html)

Once the problems are placed in the matrix, they can be prioritized. The red area contains problems with high probability and high impact. These are top risks that need to be counteracted. On the other hand, risks with low impact and/or low probability that do not need full attention and immediate counteraction are in the green zone. Knowing the risk is the first step; the second is how to handle them and to plan and control the counteraction. Basically, there a four strategies for how to handle a risk, like e. g. the risk of an unforeseen peak in requests to the software, that leads to losing customers due to system failure.  Avoidance: The possible processes or functions are not realized with the software and are not operated by the software. Instead there will be an organizational workaround, e. g. handling requests by hand.  Reduction or mitigation will try to lower severity or probability of the impact. For example, implementing an overflow mechanism that slows the system, but does not let it crash. Some customers will not be pleased, but we will lose fewer of them.  Sharing the risk might be handled by outsourcing the operation. It is the problem of the outsourcer to handle the requests.

7.2 Testing and Quality Assurance | 423



Retention of a risk means to accept and budget it: if the peak hits our system and we cannot handle the request, the system just will get slower and we might even lose some customers. That is OK for us, since we counted that in and calculated this loss into the budget right away from the start.

The choice depends on the nature of the risk, available resources in the organization and especially the preferences of the stakeholders how to handle risks in general. In order to put measures cited above, the risk table will be amended by some columns: A trigger which flags that the risk has occurred, an owner of the risk i. e., the person or group responsible for monitoring the risk and ensuring that the appropriate risk response is carried out, a response based on one of the four basic risk strategies and adequate resources. One of the biggest risks in software creation and customizing is the so called “feature creep”: after requirements have been documented, and during implementations, more and more ideas about additional features arise and will lengthen the project and add to complexity. Sometimes, changes or even additional features cannot be avoided. However, they need to be managed efficiently in order to avoid chaos. Installing a change management process according to ITIL recommendations (see chapter 6) might be a good starting point.

7.2 Testing and Quality Assurance In the broad model of software development from chapter 6, two stages were reserved for “Testing”. In this chapter we will take a closer look at quality assurance and quality management in general, the different levels and types of tests, as well as the tools of testing.

7.2.1 Quality Management as a Frame for Testing Quality is not testing, but testing plays an important role in quality management. At this point, we cannot replicate an entire quality management lecture. There are special modules and courses on quality management, maybe even in your current program. The objective of this chapter is to show some aspects of quality management which will be important for software quality. Therefore, it will deliver a short definition of quality and some basic information on the level of quality an organization can achieve.

424 | 7 Creating and Introducing IS

7.2.1.1 Defining Software Quality The original definition of quality was developed in the manufacturing industry and focuses on a product complying with detailed requirements specifications within a range of tolerance. This is not directly applicable to software products or information systems. As you learned in chapter 6, it is hardly possible to define all requirements completely, especially since they are forged together from different stakeholder wishes. Certain quality characteristics (e. g., maintainability) cannot be measured directly and so they cannot be specified in an unambiguous way (Sommerville 2011, p. 655). So, defining software quality will be the sum of different criteria and a subjective decision whether “all in all” the software is acceptable. The following figure shows most of these criteria. For each, you should be able to give an example of how to fulfil the characteristics and describe what they mean. Table 7.5: Criteria of Software Quality (Sommerville (2011), p. 656) Safety Security Reliability

Understandability Testability Adaptability

Portability Usability Reusability

Resilience

Modularity

Efficiency

Robustness

Complexity

Learnability

Not all of the characteristics can be reached to the fullest extent, since many of the goals are conflicting, e. g. security vs. usability.

7.2.1.2 Quality Systems Every step of the process can be tested and evaluated, not just the final software product. In our broad model and the chapters about business planning and requirements engineering, every step was accompanied by some form of evaluation, e. g. validating the requirements. This broad evaluation beyond simple testing supports quality management in general and will be described here quickly. The following figure shows how the software development process and quality management process are connected.

7.2 Testing and Quality Assurance | 425

Software Development Process

D1

D2

D3

D4

D5

Quality Management Process

Standards and Procedures

Quality Plan

Quality Review Reports

Fig. 7.13: Quality Management and Software Development (Based on Sommerville (2011), p. 653)

Software development process: The software development process is defined in several steps, like business planning, requirements engineering, design specifications, and so on. Each step will create a delivery, e. g. a requirements specification document. Quality management process: The software development process is accompanied by a quality management process. It is initiated from team members, other than those who are responsible for the deliveries, to enable independent checks. This starts with setting standards and procedures, creating a quality plan and defining quality review reports for each delivery of the software development process. Quality management aims to distinguish itself sharply against simply “testing the software” at the end of the development to see whether the software works. Quality management accompanies the software development cycle right from the beginning. This idea is further developed in the so-called “process based quality” approach that sets the base for ISO 9001 certification. The idea behind this is: quality management must focus on establishing good processes. If a product is developed in good processes, the product will most likely have a good quality. The following figure shows the quality based approach that sees assessment of product quality simply as a means of measuring the quality of a process.

426 | 7 Creating and Introducing IS

Define Process

Assess Product Quality

Develop Product

Improve Process

No

Quality OK

Yes

Standardize Process

Fig. 7.14: Process Based Quality (Based on Sommerville (2011), p. 657)

   



First, a process needs to be initially defined. For example, it might be the process of how interfaces are programmed. With this process, an actual product is developed, for example, an interface between our CAD and the ERP system. With a test routine, the product quality is assessed; for example it is measured in how accurately an interface works. If the product quality is OK, the process is standardized; for example, the interface development process is documented and made a standard for the whole company. If the product quality is not OK, the process will be improved and another product is developed with the newly designed process.

This simple principle is refined and expanded and leads to concepts of quality systems laid down in the ISO 9001.

7.2.1.3 Capability Maturity Model (CMM) Looking at the success of single processes for software development shows an accurate figure of whether a company is professionally developing applications and is running services at a high level. However, this approach seems too simplistic for reality. The quality of a process is not “all or nothing” and cannot be judged simply checking whether the product built by this process works or not. CMM takes a more differentiated look at the quality of processes and defines five levels of process quality (here called maturity). The following figure explains these five levels of process maturity in an organization.

7.2 Testing and Quality Assurance | 427

Processes are continuously improving Processes are predictable Processes are standard and consistent Processes are disciplined

Level 5 Optimizing

Level 4 Managed

Level 3 Defined

Level 2 Repeatable

Level 1 Initial

Fig. 7.15: Capability Maturity Model and its Levels (Based on Marchewka (2013), p. 325)

Marchewka (2013, p. 325f.) describes these levels as follows: Organizations on the initial Level 1 are characterized by an immature software organization in which the software process is ad hoc and often reactive to crises. It does not have a stable environment for software projects. Success of a project rests largely with the people on the project and not the processes that they follow. Level 2: Processes are repeatable. Basic policies, processes, and controls for managing a software project are in place. Previous project successes can be repeated by other project teams on other projects following the same process. Level 3: Defined – Software engineering and management processes are documented and standardized throughout the organization. Level 4: Managed – Quantitative metrics for measuring and assessing productivity and quality are established for both software products and processes, which are characterized as being quantifiable and predictable. Level 5: Optimizing – At the highest level of software process maturity, the whole organization is focused on continuous process improvement. To be classified in a CMM level, organizations must have installed certain mechanisms. For example, to be classified in level 2, organizations are expected to have project planning, while to qualify for level 4 organizational process performance measurements must be in place to enable controlling and reporting the KPIs of a process like cycle time. Being classified on a certain level has practical effects on companies. Customers, especially governmental agencies, might require certain areas to be on a defined minimum level. Also, the CMM level is one of the parameters to estimate the project scale factor for the COCOMO model in in chapter 7.1.3.2. A lower level of

428 | 7 Creating and Introducing IS

process maturity will mean a more difficult environment for the IS project, and thus, lead to a higher calculated effort for creating the software.

7.2.2 Different Areas and Levels of Tests Testing covers an important area of quality management. When creating a new system, tests will be conducted a) on several levels and b) from several parties. The ultimate goal of testing is to make sure the IS produces the desired results at any time and in known conditions. Usually, the time and resources necessary for testing is underestimated. It is a common complaint of project managers that testing does not get the attention it deserves, because especially at the end of a project everybody is looking to finally go live. As Laudon/Laudon (2014, p. 512) state: “Testing is time-consuming: Test data must be carefully prepared, results reviewed, and corrections made in the system. In some instances, parts of the system may have to be redesigned. The risks resulting from glossing over this step are enormous.”

The expectations towards testing must be realistic: testing can only show the existence of bugs/faults, not their absence. If many tests are executed and no problem was found, this simply means that no test was used so far that found a problem. It cannot guarantee that there is no problem – just a lower probability of problems still existing. The following figure shows the process of professional testing.

Test Cases

Design Test Cases

Test Data

Prepare Test Data

Test Results

Run Program with Test Data

Test Reports

Compare Results to Test Cases

Fig. 7.16: A Generic Model of the Software Testing Process (Based on Sommerville (2011), p. 210)

Since testing is time-consuming, but necessary, it needs to be optimized. It does not make sense to just test the whole system at the end. Little errors in small modules will make the test case fail. To prevent this, a multi-level approach is employed that first tests single units, then whether they work together, and finally, whether a business process can be correctly completed as supported by the software.

7.2 Testing and Quality Assurance | 429

Another important ingredient for efficiency is documentation: every test needs something to be tested against – otherwise, it would not be possible to decide whether the test was successful or not. The following figure explains the multi-level approach and the documents each level will be tested against. Client

Developer Object Design Document

Systems Design Document

Requirement Analysis Document

Client Expectations

Unit Testing

Integration Testing

System Testing

Acceptance Testing

Fig. 7.17: Hierarchy of Test Types (Based on Bruegge/Dutoit (2009), p. 20)

Unit testing will ensure that single objects are working properly, like calculating results correctly producing outputs from inputs, etc. A component test ensures that single objects or modules work together. This is focused on the interfaces working together without error. It shows how different functions across units will work together from a technical point of view. In a system test, the system is tested as a whole with all its software and hardware components. It tests business processes from an integrated systems perspective. The release and acceptance test also tests the system as a whole, but from a radically different perspective. It will decide whether the internal or external customer accepts the product as finished. All of these tests need a document or a specification to be tested against. Unit testing uses the object design documents, integration testing the systems design documents, system testing the requirement specification and acceptance testing will be tested against customer expectations. The form of test, the testing staff and the goals of tests on different levels are quite different. Specialists warn to create lukewarm mixtures of unit and integration tests, see e. g. here. http://blog.stevensanderson.com/2009/08/24/writing-greatunit-tests-best-and-worst-practises/ Before discussing these levels in detail, some terminology about software problems must be clarified here (Bruegge/Dutoit 2009, p. 4) with examples from a CAD system:

430 | 7 Creating and Introducing IS 







Failure: Any deviation of the observed behaviour from the specified behaviour: e. g. the CAD system does deliver wrong numbers of the geometry when design is exported in metric system. Length and diameters are always too small. Erroneous state (error): The system is in a state such that further processing by the system can lead to a failure. E.g. the calculation for the export of designs is wrong. Fault: The mechanical or algorithmic cause of an error. This is commonly called a bug (see 7.2.3.3). Correcting such an error in the code is called “debugging”. E. g. a developer forgot to add a parameter for converting inches into centimeters. Validation: Activity of checking for deviations between the observed behaviour of a system and its specification. E.g. entering values in inches and checking whether an export in the metric system shows the correct expected result.

7.2.2.1 Unit Testing Unit testing must show components behaving like expected and producing the right outputs if they are fed with the correct data. This part is called testing for normal operations. Additionally, there needs to be a second type of test that relies on experience: how will the unit behave if it fed with wrong data, overloaded, etc.? Will it crash, produce useless output or correctly refuse operation and detect abnormal input? To test a unit thoroughly, many different aspects of the unit need to be tested (taken from http://testingbasicinterviewquestions.blogspot.de/2012/01/what-is-unittesting-explain-it-with.html):  Module Interface tests check whether the information is properly flowing into the program unit (or module) and properly out of it or not.  Local data structures are tested to inquire if the local data within the module is stored properly or not.  It is observed that much software often fails at boundary related conditions. That’s why boundary related conditions are always tested to make sure that the program is properly working at its edges.  All independent paths are tested to see that they are properly executing their task and terminating at the end of the program.  Error handling paths are tested to review if errors are handled properly by the unit or not. There are basically two strategies here that can be effective in helping you choose test cases. In the test plan, both sources of tests should be used (Sommerville 2011, p. 213):

7.2 Testing and Quality Assurance | 431





Guideline-based testing uses guidelines to choose test cases. These guidelines reflect previous experience of the kinds of errors that programmers often make when developing components. This will be called “top down” testing here. “Thorough Testing” (Please note: this is not an established term) seeks to test the entire software “bottom up”.

The second approach (thorough testing) will take a lot of time and create a lot of work, since basically, the possibilities to create test cases are unlimited. That’s why it is important to a) automate and b) efficiently choose tests that cover all aspects of a unit described in the beginning of the chapter. Even while the source code is written, it is possible to test different aspects before the code is compiled and melted down to an executable program: in integrated software development, workspaces and environments (“programs for writing code”), like e. g. ECLIPSE warnings, errors and explanation during writing and compiling, already deliver some hints for things that have gone wrong. Plug-ins for ECLIPSE also will check the code for code guideline violations, code anomalies and structural anomalies; see, for example, http://metrics.sourceforge.net. These socalled “static tests” are also called white box tests, since the code itself will be examined instead of expected outputs from given inputs. Once the raw code is compiled into an executable program, testing takes the form of a black box: tests will give inputs and expect certain behaviour or outputs by the unit/program. However, for thorough testing, there would be an infinite number of inputs to be tested, which is not efficient. The solution to this dilemma is called partition testing. The following example, taken from Sommerville (2011, p. 215), might be translated into engineering context like this: a program is fed with problems and downtimes of wind turbines during the last 30 days. Depending on the number of downtimes, the program will react differently according to the specification: fewer than 4 downtimes will lead to no reaction at all, between 4 and 10 will produce a list with the machines and reasons of downtimes, and more than 10 will give a signal to initiate an immediate maintenance procedure. If there are up to 31 daily downtimes possible (per month), should therefore, 31 test cases be created for each number of downtimes as an input? The following figure shows how to reduce test cases efficiently:

432 | 7 Creating and Introducing IS

0

3

Less than 4

4

7

10

Between 4 and 10

11

345

More than 10

Fig. 7.18: Equivalence Testing and Partition Boundaries (Based on Sommerville (2011), p. 15)

 





First there should be a test with 7 downtimes right in the middle of the partition 4−10 to test this partition. Most problems occur at the edges of partitions. Therefore, the left and right of partition boundary test cases are especially revealing. Test cases with an input for 3 and 4 and for 10 and 11 should be created. So, there are just 5 test cases necessary to test the whole range. If the tests in the middle and on the edges of partitions are passed, there is a very high chance that the whole partitions need to be correct, as well. It is highly unlikely that inputs of 4 and 7 pass the test, while 5 would fail. To make it absolutely safe, you might add a test for zero (which is always a special case for computer programs), and an abnormally high number like 345 downtimes, as well.

There are also programs to support black-box unit testing. www.junit.org, for example, is a java framework for writing and running unit tests that features test cases and fixtures, test suites and a test runner. We will not look further into component testing, which integrates several units and interfaces working together. There are different types of interfaces, like parameter interfaces, shared memory interfaces, procedural interfaces and message passing interfaces (see chapter 3). Typical problems that might occur at interfaces of collaborating units are:  interface misuse,  interface misunderstanding and  timing errors. For details, see Sommerville 2011, p. 216f. 1 The important take-home lesson about unit testing for a customer can be summarized like this: unit tests are built into programming environments and are often automated. They have an isolated, technical “inside-out” perspective. Successful unit tests are not suited to test whether the system is doing what is expected by requirement specification and they are far from able to ensure user/customer satisfaction with the software.

7.2 Testing and Quality Assurance | 433

7.2.2.2 Systems Testing System testing checks the functioning of the IS as a whole with many units and components. It switches perspectives and the question shifts from: “Do units and components behave technically correctly?” to “is the system performing as required in the technical specification?” Consequently, it expands tests of functions to tests of performance, capacity, handling peak loads, recovery, restart capabilities, etc. Another consequence is: the test team might also involve people other than developers to get an outside-in perspective. In system testing, it becomes clear that the sum of a system is more than its single parts. Emergent behaviour might arise if components work together for the first time on certain hardware. In systems testing, bugs will show up, that – by definition – cannot be detected in isolated unit testing. Famous and tragic problems, especially in space engineering, are due to reuse of software and emergent behaviour that can only be detected in systems. Please research the Ariane 5 problem, a chain reaction that was undetected due to a lack of integra- 5 tion testing: http://www.cs.toronto.edu/~sme/presentations/BugsInTheSpaceProgram.pdf

The best base for an integration test is a real use case as described in chapter 6. The following figure shows a simple example of a complete use case/process that is to be executed by the system using different units: a service technician for an offshore wind turbine wants to know the weather report from the wind park weather station.

434 | 7 Creating and Introducing IS

Weather Information System SatComms

Weather Station

Commslink

WeatherData

request (report)

acknowledge

Report Weather

acknowledge get (summary)

summarize ( )

send (report)

reply (report)

acknowledge

acknowledge

Fig. 7.19: Systems Test Involving Several Modules on Different Machines and Hardware (Based on Sommerville (2011), p. 186)

1.

2.

3. 4. 5. 6.

The SatComms object receives a request from the weather information system to collect a weather report from a weather station. It acknowledges receipt of this request. SatComms sends a message to WeatherStation, via a satellite link, to create a summary of the collected weather data. SatComms does not suspend itself waiting for a reply. WeatherStation sends a message to a Commslink object to summarize the weather data. Commslink calls the “summarize” method in the object WeatherData and waits for a reply. The weather data summary is computed and returned to WeatherStation via the Commslink object. WeatherStation then calls the SatComms object to transmit the summarized data to the weather information system, through the satellite communications system.

7.2 Testing and Quality Assurance | 435

This simple process uses different units running on different hardware that have to work together. It is not about single units working correctly, but rather getting the desired weather report at the end. The expected results can be defined in advance by supplying the weather station with artificial data that was not created by the measuring instruments, but by the testing team. With artificial data, the output of the weather-report at the end can be predicted. The test will compare the expected result with the actual result. This is not confined to the content of the report, but also to the time it takes for the operation and other criteria defined for the test. However, there are also tests that do not use an expected behaviour, but look for errors just by using the functions of the system randomly. Since testing can only show the existence of bugs, but never completely their absence, testing by definition has no end. Stop testing (e. g. if you are out of time or money) simply shifts the work of eliminating problems to the customer and user. A reasonable end of system testing might be if all “show stopper” bugs (see 7.2.3.3), that will make the use of the system completely impossible or useless, have been fixed. Another indication would be the rate at which new bugs are being found is falling below an acceptable level: if testing is thorough, the rate at which new bugs are found serves as a good indicator of how many bugs still remain.

7.2.2.3 Release and Acceptance Testing Release testing shifts the perspective completely to the user, customers or the designers of other systems that communicate with that system. That is why it will be called release and acceptance test. There are two important points that distinguish it from system testing:  A separate team that has not been involved in systems development will be responsible for release testing.  System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is now to check that the system meets its requirements and is good enough for external use (validation testing). Acceptance testing provides the final certification that the system is ready to be used in a production setting. Tests are evaluated by users and reviewed by management. When all parties are satisfied that the new system meets their standards, the system is formally accepted for installation.

436 | 7 Creating and Introducing IS

Test Criteria

Define Acceptance Criteria

Plan Acceptance Testing

Test Plan

Derive Acceptance Tests

Tests

Test Results

Run Acceptance Tests

Testing Report

Negotiate Test Results

Accept or Reject System

Fig. 7.20: The Process of Acceptance Testing (Based on Sommerville (2011), p. 224)

Sommerville (2011), p. 224ff. describes these steps as follows: Acceptance criteria should be defined early in the process before the contract for the system is signed. They should be part of the system contract and be agreed between the customer and developer. In practice, it is often difficult to define criteria this early, since detailed requirements may not be available and significant requirements changes during the development process might happen. Planning acceptance testing involves deciding on the resources, time, and budget for acceptance testing and establishing a testing schedule. The plan should include the coverage of the requirements wished for and the order in which system features are tested. It should define risks to the testing process, such as system crashes and inadequate performance, and how these risks can be mitigated. Once acceptance criteria have been established, tests will be designed to check whether or not a system is acceptable. Acceptance tests should aim to test both the functional and non-functional characteristics like performance of the system. In practice, it is difficult to establish completely objective acceptance criteria. The agreed acceptance tests are executed preferably in the productive environment that will be used later in everyday operations. Sometimes, a test environment is cloned 1:1 from productive environment to avoid disruption of operations, but this again is costly. Since acceptance testing involves interactions between endusers and the system, some training of end-users may be required. It is very unlikely that all of the defined acceptance tests will pass without problems. In such cases, the developer and the customer have to negotiate to decide if the system is good enough to be put into use. They must also agree on the developer’s response to identified problems. If the system is not good enough for use, then further development is agreed upon to fix the identified problems. Once complete, the acceptance testing phase might be repeated or just classified as accepted by the customer. After having described the test process, we need to clarify what exactly is tested in an acceptance test. Central to the acceptance test is testing the requirements. E.g. for a PPS system (see chapter 3), we have a requirement about a “double entry alarm” that sets off if a seemingly new material will be entered that has the same

7.2 Testing and Quality Assurance | 437

characteristics as an existing material. Requirements based testing needs to derive tests for this requirement to check if they have been satisfied:  Set up a materials record in the system with a defined set of characteristics. Try to enter a material that does not have these characteristics. Check that a warning message is not issued by the system.  Try to enter another material that does have exactly the same characteristics. Check that a warning message is issued.  Try to enter a material that does have exactly these characteristics. Check that the system suggests choosing the existing material identical to the entry to take this material instead of the new entry.  Accept the suggestion of the system. Check that the entry of your material will increase the inventory of the existing material and not create a new one.  Overrule the suggestion of the system. Check a) whether a new material was created and b) inventory of the existing material does not change.  Etc. Scenario testing is an approach to release testing in which typical scenarios of use are devised and employed to develop test cases for the system. Scenarios should be realistic, credible and fairly complex. Real system users should be able to relate to them. If you have used scenarios as part of the requirements engineering process, then you may be able to reuse these as testing scenarios (Sommerville 2011, p. 225). A scenario for the case above might look like this: “Michael belongs to purchasing staff and is asked to enter new materials. Since he needs to interrupt his work frequently for other tasks, he sometimes enters the same material twice. His colleagues, Fred and Debbie, do the same, so up to three materials might be entered at the same time. After entering, he wants to generate a report that shows freshly entered materials, but only those entered by him and his colleague Debbie, and not from Fred. Since he wants to leave the office early today, he wants this report not to be printed out, but automatically emailed to an address other than his standard company email (granted, that this allowed). While entering materials, there is also a power failure and the system needs to reboot.” With this scenario, several requirements are tested at the same time and make sure different requirements do not conflict when simultaneously called on. Finally, the integrated system needs to be tested for performance and reliability. A typical method is running a series of tests in which the load is increased from under the performance limits slowly above the limits until the system performance becomes unacceptable. Besides the question of whether the performance is reached, it also shows the systems failure behaviour. Will it just get slower (linear? digressive?) or will it suddenly shut down? It is important not to artificially try to overload certain functions, but rather multiply normal business processes that access a mixture of functions. This real-live performance test will reveal problems that cannot be anticipated since

438 | 7 Creating and Introducing IS

the interaction of different functions in different quantities will stress the system differently than straining an isolated function like data entries.

7.2.3 Processes and Tools for Testing Integration, systems and acceptance tests have different goals and test cases, but they all rely on some practical support and have to follow certain processes. This chapter will explore the practical aspects of testing. Another good view from a testing manager can be read here: http://sunnyday.mit.edu/16.355/Yamaura1.pdf Unit tests, as described in chapter 7.2.2.1, are tightly integrated in the programming environment and executed by the developer/programmer. So, please consider the following aspects especially for integration, systems and acceptance tests.

7.2.3.1 Organizing and Planning Tests To organize tests professionally, testing personnel is needed. While unit tests are executed by developers themselves, systems tests must involve non-developers. Acceptance tests, by definition, should involve no programmer from the delivering party (IT vendor or internal IT department), otherwise suppliers would judge themselves. A real systems test also needs a test environment, where error provoking tests can be executed, but do not interrupt real live operations. This can be costly, so the compromise of constructing a test environment that uses existing hardware, but still keeps the test environment separated, can save money. The test environment does not only include servers and databases, but also connections (physical and network) and access rights. Building a system test environment will take its time, since there will be unpleasant surprises, so start well in advance of testing. The following figure shows some necessary elements of a professional test environment for a very big project: an industrial web-marketplace with external connections, a huge catalogue system, and data warehouses all provided by different suppliers. Small scale projects will need a smaller systems test environment.

7.2 Testing and Quality Assurance | 439

Developer/ Supplier 1

Developer/ Supplier 2

Developer/ Supplier 3 Key

shared Development: Unit Test

Web Server

shared Connecting: Integration Test

Real System: Systems Test

Internet

shared

Application Server Catalogue & WebServer

Data Warehouse

Internet Database Storage

After Go Live: Ongoing Tests

Antivirus server,etc

Fig. 7.21: Test Environments for Different Test Levels

Unit Test for Development: Developers from different suppliers will execute their unit tests on the same software and hardware they are programming. Integration Test for Connecting: An integration test environment will not simply add up the single environments of the suppliers. Rather, hardware will be shared to let several applications run on it. Additionally, an internet connection will be needed to test connectivity of the units and components. Systems Test: In a perfect world, system tests and acceptance tests will run on the very machines that will later become the productive system after going live, when real operations will be conducted. This will be a larger setting than for integration test since performance issues are tested in real life and are not just simulated. Ongoing Tests after Go Live: After going live, the systems test environment is probably used for production. It cannot be used for testing without disturbing daily operations. However, testing never stops since the software evolves and needs to be validated. Only few companies afford to mirror their productive environment completely to have a safe test environment.

440 | 7 Creating and Introducing IS

The requirements will get even more complex once training will be done on the real system. A solution could be a shared environment for tests and training, but only if both tasks are coordinated tightly. A training system permanently breaking down because of tests conducted on it can be a great source of frustration for users. Another prerequisite for successful test is the test plan. A good test plan includes the various conditions to be tested, the requirements for each condition tested, and the expected results. Test plans require input from both end users and information systems specialists. (Laudon/Laudon 2014, p. 531). Sommerville supports the necessity of a test plan to coordinate all of this: “Test planning is particularly important in large software system development. As well as setting out the testing schedule and procedures, the test plan defines the hardware and software resources that are required. This is useful for system managers who are responsible for ensuring that these resources are available to the testing team. Test plans should normally include significant amounts of contingency so that slippages in design and implementation can be accommodated and staff redeployed to other activities.” Source: http://www.SoftwareEngineering-9.com/Web/Testing/Planning.html

The following figure shows a part of a test plan. It looks at six different possible situations, given a user of the system attempting to change a record in the database, from trying to change an existing address in the system (Test Ref. 2.1) to not completing the record change (Test Ref. 2.6). Table 7.6: Extract of a Test Plan (Based Laudon/Laudon (2014), p. 531) Procedure Address and Maintance “Record Change Series” Prepared By: Date: Version: Test Condition Tested Special Ref. Requirements 2.0 Change records 2.1 Change existing Key field record 2.2 Change Other fields nonexistent record 2.3 Change deleted Deleted record record must be avaiable 2.4 Make second Change 2.1 record above 2.5 Insert record

OK if valid

2.6

No change

Abort during change

Abort 2.5

Test Series 2

Expected Results

Output On

Next Screen

Transaction file Transaction file Transaction file

V 45

Not allowed “Invalid key” message “Deleted message” OK if valid

V 45 V 45

7.2 Testing and Quality Assurance | 441

Every project and company needs to find their own way of testing. People involved and the effort made will vary with the size and breadth of change the system will bring about. There are two sources that might help you, when involved in organizing the tests: For smaller scale adjustments in a running environment, the ITIL process of “Service Validation and Testing” from chapter 5 will give valuable advice on how to organize tests for incremental changes in software. For big software projects, like introduction of a new ERP system or a selfprogrammed new software application, you should refer to specialized literature about testing, like chapter 8 and chapter 24 of Sommerville 2011 and the sources cited there.

7.2.3.2 Creating and Administrating Test Cases Dominant tools of testing are test cases, which are created for various reasons and various styles. The IEEE Standard 610 from 1990 defines a test case as follows: “A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.”

Test cases have several purposes besides simply finding defects. They can block premature product release, help managers in deciding to go live now or not, minimize support cost, asses conformance to specification, and find safe scenarios for use of the products (for a complete list, see Kaner 2003, S.2f.). Because of these multiple purposes and goals of tests, there will be no test that serves all purposes equally well, so you should be aware of what are your the exact goals for testing. Most likely, it will be to discover defects in the software. In this case, the quality of a testcase can be judged by four basic characteristics (Kaner 2003, p. 4). It should …  … have a high probability of exposing a bug  … reveal significant problems that will affect stakeholders’ goals negatively  … give developers and users insights into the problem and help them to fix the problem  … be easy to evaluate with little effort and a clear result whether the test has passed or failed. Every organization has to find individual test cases according to the software, its requirements and the level and goals of testing described above. However, every test case document should have certain characteristics. This list is taken from http://www.softwaretestinghelp.com/test-case-template-examples/:  Test case ID: Unique ID for each test case. Follow some convention to indicate types of test. E.g. “TC_UI_1′ indicating ‘user interface test case nr. 1”.

442 | 7 Creating and Introducing IS 

         

 

 

Test priority (Low/Medium/High): This is useful during test execution. Test priority for business rules and functional test cases can be medium or higher, whereas minor user interface cases can be low priority. Test priority should be set by reviewer. Module Name – Mention name of main module or sub module. Test Designed By: Name of author Test Designed Date: Date when designed Test Executed By: Name of tester who executed this test. To be filled after test execution. Test Execution Date: Date when test executed. Test Title/Name: Test case title. E.g. “verify login page with valid username and password”. Test Summary/Description: Description of test objective in brief. Pre-condition: Any prerequisite that must be fulfilled before executing this test case. List all pre-conditions in order to successfully execute this test case. Dependencies: Mention any dependencies on other test cases or test requirements. Test Steps: List all test execution steps in detail. Write test steps in the order in which these should be executed. Make sure to provide as much details as you can. Tip – to efficiently manage test cases with fewer numbers of fields, use this field to describe test conditions, test data and user roles for running test. Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as an input. Expected Result: What should be the system output after test execution? Describe the expected result in detail, including message/error that should be displayed on screen. Post-condition: What should be the state of the system after executing this test case? Actual result: Actual test result should be filled after test execution. Describe system behaviour after test execution. http://www.softwaretestinghelp.com/test-case-template-examples/

The following figure shows a simple test case for a telecommunications company that does not, however, have all the fields described above, and names some fields differently. The test case is as follows: A customer is created and services/products are assigned to her. She is then suspended for a defined reason at defined date. The last two steps of the test cases are to provoke error messages in case a suspended customer is again suspended or a non-existing customer is suspended.

7.2 Testing and Quality Assurance | 443

ID T.103 Use Case Suspend Customer Status: in progress

CID 999011776 Version 3 Author Lena Kiki

A-Nr

040-11101030

Test date

07.01.2014

Systems Steps Variant CAS, IMS 2 1

Varaiant Description 1 Suspend Customer (CID, Reason-Code, Suspend-Date) Step 1 2

Sender IMS Billing

Receiver Billing IMS

Description s result code Pseudocode Suspend Customer (CID, reason-code, suspend-date) IF Locate Customer (CID) THEN IF customer IS active THEN Suspend_Customer (CID, reason-code, suspend-date) Step ID Customer ID T.103.1

999011776

Parameters

Comment Do not suspend existing customer of another test case! Please create new customer first. Test step

Create new customer

Customer will be created

CID: 999011776 Service: Power-Flat

Assign services

Service will be assigned to customer

CID: 999011776 Reason-Code: Tescase T103 Suspend-Date: (immediately)

Suspend customer

Customer and associated services will be suspended

Suspend customer

Error message: "Customer already suspended!"

Suspend customer with non-existing ID

Error message: "Customer does not exist"

CID: 999011776

T.103.2

999011776 Reason-Code: Tescase T103

T.103.3

CID: 999002304 Reason-Code: Tescase T103 Suspend-Date: (immediately)

Suspend-Date: (immediately)

999002304

Result

CID: 999011776 Last name: Testfall.T103 First Name: Carlos Market: FN_Market

Fig. 7.22: Example of a Test Case for Testing the Database of a Telecom Provider

Keeping track of all test cases and their state of processing requires, again, a test administration system, or at least a spread sheet. Please note that test cases in systems testing can also be run automatically and permanently. An automated set of basic tests is a good way of evaluating whether the system is “basically” running – especially after a new release. For more information about organizing and staffing software tests, see e. g. http://www.softwaretestingsoftware.com/.

7.2.3.3 Managing the Bug Life Cycle If a test case fails or other undesired results of the software are encountered, it is commonly called a “bug”. It is helpful to look at the “life cycle” of a bug, since it is closely connected to the process of detecting and solving bugs. The life cycle of a bug begins with a message from a tester or a user that something does not work as the tester or user expected. The life cycle ends with one of the following solutions:  The bug was fixed and now the test case and the software works as desired.  The bug has been identified as already known and therefore, is a duplicate, which happens quite often.  The developers won’t fix the bug (in this release of the software), because they are unable to do so or a management decision prevents them from fixing it (maybe because it takes too long for this release to be on time).  Often, developers try the reported test case or the function themselves and they will respond, “works for me”, meaning they cannot replicate the bug and it works on their system.

444 | 7 Creating and Introducing IS 

Invalid means that the problem described is not a bug, but is e. g. just a desired function that was never part of the specification.

Figure 7.23 figure shows the different stages of a bug until it is resolved. Please note that we left out some additional connections, especially shortcuts, that can happen at several stages. Instead, we show the whole cycle. QA means quality assurance.

Unconfirmed New bug from a User With can confirm Or a product without Unconfirmed state

Bug confirmed or receives enough votes

Developer takes possesion

New

Ownership Is changed

Developer takes possesion

Assigned Possible resolutions: Fixed Duplicate Wontfix Worksforme Invalid

Development is finished with bug

Resolved

Bug is closed QA verifies Solution worked

QA not satisfied with solution

Reopen

Development is finished with bug

Bug is reopened

Bug is reported

Verified

Bug is closed Closed

Fig. 7.23: Life Cycle of a Bug as Managed by Bugzilla (Based on http://www.bugzilla.org/docs/3.0/html/lifecycle.htm)

7.2 Testing and Quality Assurance | 445

A bug might be reported by a tester or a user. It is in an unconfirmed state because we do not know yet whether it is really a bug and if it is a new one. If the bug is confirmed, it is classified as NEW. It also might be entered directly from an external source, like the developer as a confirmed bug. Every bug needs a responsible developer to be assigned to. A developer might also immediately take possession of the bug and it is then assigned to this developer. If development is finished with working on the solution, the bug is called “resolved” in the sense of the possible resolutions described above. Of course, an unconfirmed bug might be resolved immediately if it is detected to be a duplicate. If testing and QA verify that the solution works, the bug is closed. A bug might reappear in a new release or at another occasion. In this case, it is simply reopened. There is some information entered for every bug, e. g. the symptoms and information about the environment where it occurred. The most important characteristic, however, is its severity. Typically, developers and QA use three to five different levels of bugs:  Blockers or Showstoppers need to be fixed immediately. They will prevent the product from working if the system would be released in that state.  Critical bugs influence the functionality considerably, too, but they typically have a workaround or a quick fix that can be applied post-release.  Major bugs have a workaround and can be put off without impacting the functionality of the application.  Minor and Trivial issues are usually reserved for enhancements or “nice to haves”. They document a deviation from specification, but the software will work just as well. There are many other functions offered by a professional bug tracking system, e. g. export functions and statistics. Please check the website www.bugzilla.org for further explanations of one system. A bug tracking system is typically employed during the creation of new software that has a major impact on the organization. It is not necessarily suited for everyday use in a running environment. For smaller changes and enhancements in everyday IT management, the collection and management of errors/bugs can by organized the ITIL process of “Problem Management” (see chapter 5).

7.2.3.4 Reporting of Test Advancement Bug tracking tools allow a professional handling of finding and solving bugs. Its statistical functions also allow transparent controlling of the QA process. Having the number of detected, closed and open bugs with their severity, assigned developers, and priorities for each day enable many useful reports. The following figure, for example, shows several release dates and the status of open and closed bugs at that particular date.

446 | 7 Creating and Introducing IS Number of Bugs 220 200

closed open

180

open

blocker critical medium trivial

160 140 120

closed

100 80 60 40 20

Date

0 20.06.

27.06.

04.07.

11.07.

18.07.

25.07.

01.08.

08.08. 15.08. 22.08

Fig. 7.24: Cumulated Open and Closed Bugs by Severity at Release Dates

A very important piece of information is the rate of discovering new bugs: ince it falls considerably, it is a good indication of when to go live and stop testing. Remember: In reality, it is almost impossible to straighten out all bugs before going live. However, there must be no more show-stoppers and going live with critical bugs (and workarounds) needs explicit management board approval. In AGIL programming and testing, “burndown charts” (see chapter 6) of bugs and functions are a preferred controlling tool. They can also be derived from the base information of bug tracking tools.

7.3 Preparing the Organization for Introduction An information system is not an isolated piece of software. Without the organization, and its members using and accepting it, there will be no measurable organizational value by simply having new software in place. Out of the many topics that might help companies to prepare the organization for actual introduction, we will have a look at some selected questions:  How can organizations be changed at all and how can this change be initiated and supported?  How can the preparation of skill and knowledge (training) be optimized?  How will the actual switch/cutover from one system to another be organized in detail?

7.3 Preparing the Organization for Introduction | 447

7.3.1 Planning, Executing and Guiding Organizational Change After hearing a lot about software design, creation and testing, we must not forget that information systems include users and organizations. A new or improved information system will bring or require changes to the organization. There are different intensities of change with different returns and associated risks. The following figure shows four different levels of change exemplified by a CAD system.

gh

Paradigm shifts Redesign

Rationalization

Automation Low Low

Return

High

Fig. 7.25: Risks and Rewards of Different Levels of Organizational Changes (Based on Laudon/Laudon (2014), p. 520f)

Automation: The most common forms of organizational change are automation and rationalization. These relatively slow-moving and slow-changing strategies present modest returns but little risk. E. g. a CAD system now calculates material cost of a new design automatically. Rationalization: Rationalization is achieving more quality with evolutionary smaller changes. E. g. there is an automatic mechanism in the CAD system that checks the plausibility of numbers entered. Also, the designers are educated and incentivised to avoid errors. Redesign: Faster and more comprehensive change – such as redesign and paradigm shifts – carries high rewards, but offers substantial chances of failure. An example of a “redesign change” for our example would be: Leave out human cost

448 | 7 Creating and Introducing IS

controllers completely in calculating the cost (all done automatically) or outsource special aspects cost calculation. Paradigm shifts: A paradigm shift fundamentally changes the business: e. g. an intelligent CAD system with a lot of automation might make current business more and more obsolete. It might force the engineering company to seek new business areas, e. g. to offer consulting services for design to cost, and target costing projects for their customers. This chapter will focus on the most challenging change: Business Process Redesign. Additionally, a short glimpse of organizational change management will show how to handle and manage change in a professional manner.

7.3.1.1 Business Process Reengineering and Management In order to use software the best way and take advantage of all possibilities the software offers, a change in the organization might be necessary. This mainly concerns processes, but sometimes also structures of departments. However, the relationship is not one way: the needs and possibilities of a system will enable new processes and force the organization to rethink their business processes. Introducing a new system, especially an ERP system, may force an organization to think about processes for the first time because the software is process-based (see chapter 4). SAP itself goes one step further and suggests introducing a standard version of their software customized to a standard industry template (e. g. automotive manufacturing) right away. The users and staff of the company will then be forced into processes operated by the software. However, most authors and practitioners agree that it is better to redesign processes first, optimize them, and adjust them to process oriented software. This redesign, that is also executed on its own without introducing IS, is called Business Process Reengineering (BPR). Reengineering of processes is one of the most powerful tools in management and can yield enormous improvements in cycle time of processes, quality and cost. BPR projects are also associated with quantum leap cost savings, downsizing, outsourcing and job cutting. The basic model of BPR can be described as a cycle that is exemplified in the following figure:

7.3 Preparing the Organization for Introduction | 449

Test and Implement target processes in the organization.

Test & Implement To-Be

Continuous measurement and Benchmarking

Identify Process

Identify processes: What are processes from the perspective of an internal and external customer perspective? Which ones are worth optimizing?

Measure and benchmark

Design target processes “as to be”: Optimize processes according to the techniques described below.

Processes permanently in order to improve and adjust them further. This leads back into process analysis and thus evolves as a cycle. Review, Design To-Be

Update Analyze As-is

Analyze or review the current processes “as-is”: Drawing processes with the tools described in learning Object 1, e.g. swim lane diagrams, and analyzing them.

Fig. 7.26: Business Process Reengineering Cycle

After radical redesign of processes, a more evolutionary approach of Business Process Management (BPM) is pursued by many companies. For more information about BPM as distinguished from BPR, please see Motiwalla/Thompson 2011, 272ff. BPR and BPM easily fill books and complete classes, so we will just take a short glance at some examples of how processes can be improved. There are two levels of process optimization, which shall be called a macro level and a micro level. On the macro level processes, the single processes themselves and their coordination are subject to improvements. Typical methods of BPR on the macro level are, for example:  Stabilize process by assigning process owners, improving data quality and curing bottlenecks in the process. Example: A mechanical engineer from design is assigned as process owner of the process of converting drawings from CAD to ERP. This process ownership, in the first place, means managing and coordinating – not necessarily doing all the work.  Differentiate processes: Cluster all real processes into a few (!) sensible groups and design a process for each group. Example: There will be a standard conversion process for the drawing for most customers. Producing for defense industry customers, however, will need a special process, since only staff with high security clearance may take part in the process.

450 | 7 Creating and Introducing IS 

Simplify processes, e. g. by Kanban or Just in Time concepts, that eliminate the need to plan ahead what input the process might need – but rather let the process tell when it needs something. Other methods are: Automating processes, synchronizing processes within a company and with outside partner, qualifying and motivating process owners and staff doing the work, and most important of all: eliminate process if not required by customer and not necessary to keep other processes running.



Most BPR literature is concerned with working on the micro level optimizing the structure of process steps within a single process. The following figure shows just one important method, called parallelization of project steps, as an example. Hidden independent activity

1

2

3

causal dependency

4

4b

5

6

7

8

9

Business Process Reengineering 5 1

2

3

parallel split

6 4b

7 8

9

time savings

synchronization

Fig. 7.27: Identifying and Extracting a Potentially Parallel Activity (Based on Draheim (2010), p. 20)

An analysis of the existing process of converting CAD designs to ERP revealed two important facts. The process step “gather documentation for export” carried a hidden independent activity: checking whether documentation from our suppliers about modules in our design is still accurate. This information and updates would only have a causal dependency to step 8, which is “releasing data and documentation”. By BPR, a parallel split was introduced after step 4. Step 4b could be parallelized to steps 5 to 7. This allowed for effectively shortening the total time by the length of 4b. It is the same effect as killing a dependency of a work package in a project plan. The project software will parallelize the steps to let it start as early as possible. The result is a decrease in cycle time and project time. Further methods of redesigning a process on the micro levels are:

7.3 Preparing the Organization for Introduction | 451

   

eliminate unnecessary steps, outsource single steps for quicker execution, change the positions of single steps to achieve an optimized flow, avoid process loops and rework.

Please consult literature dedicated to BPR for more details.

A well designed process will help the organization yield more improvements from a new software and is a powerful instrument of optimizing organization in itself.

7.3.1.2 Managing Organizational Change Changing and redesigning processes will be one of the biggest organizational challenges that the introduction of a new system brings about: BPR might be painful to the organization. Contrary to management belief, not all employees embrace change as something good and desirable and organizational change does not just happen by itself. An independent discipline in management science works on the challenge of how to manage change. Please note: “Change management”, in the business sense of this chapter, has nothing to do with the ITIL process of Change Management as described in chapter 5. Training and clear communication, as well as taking fear of the unknown seriously, are seen as the keys to success in organizational change management. There are basically three roles in change management (Marchewka 2012, 264ff.): Sponsors can be individuals or a group who have the power and the resources to demand and sustain change. There might be initiating sponsors like senior management who hand down the project to a sustaining sponsor. Top-management support for the project is named an important success factor in all studies about project and change management. The commitment to the change must materialize in communication and resources throughout the process of change. Change Agents are individuals or groups that operatively work on changing processes and (maybe) also company culture. This is most likely the project team, which needs to be rooted firmly in the company to achieve sustainable change. Switching from 2D to 3D systems and design cannot be achieved without the SME’s (see chapter 7.1.3.3) like team members from mechanical design. Targets of Change may be the users or customers of the new system or those who will use or be directly involved with the final product of the project. Their conversion or adjusted behaviour will be the ultimate measure of success. Mere lipservice will not do for sustainable change. They must clearly understand the real impacts of the change, the breadth of change, what will stay the same and what will not, and how the rules for success in operating and getting ahead have changed. As with most management issues, it is a good idea to select a certain strategy for change management that is fit for use in a given situation. The following Ta-

1

452 | 7 Creating and Introducing IS

ble shows some basic strategies for how to manage change. Those strategies are never purely applied on all targets of change, rather an efficient mixture is necessary. Table 7.7: Basic Change Management Strategies (Nickols (2010), p. 2f) Strategy

Assumptions and Description of Strategy

Empirical-Rational

People are rational and will follow their self-interest – once it is revealed to them. Change is based on the communication of information and the proffering of incentives.

NormativeReeducative

People are social beings and will adhere to cultural norms and values. Change is based on redefining and reinterpreting existing norms and values, and developing commitments to new ones.

Power-Coercive

People are basically compliant and will generally do what they are told or can be made to do. Change is based on the exercise of authority and the imposition of sanctions.

EnvironmentalAdaptive

People oppose loss and disruption, but they adapt readily to new circumstances. Change is based on building a new organization and gradually transferring people from the old one to the new one.

Of course, it is impossible to tell which one is “the best”, since the best option depends heavily on the situation. Nickols describes the following criteria that help in choosing the right mix of change management strategies. “Degree of Change: Radical change or transformation argues for an environmental-adaptive strategy (i. e., ‘wall off’ the existing organization and build a new one instead of trying to transform the old one). Less radical changes argue against this strategy. Degree of Resistance: Strong resistance argues for a coupling of power-coercive and environmental-adaptive strategies. Weak resistance or concurrence argues for a combination of rational-empirical and normative-reeducative strategies. Population: Large populations argue for a mix of all four strategies, something for everyone, so to speak. Diverse populations also call for a mix of strategies. This implies careful segmentation. Stakes: High stakes argue for a mix of all four strategies. When the stakes are high, nothing can be left to chance. Moderate stakes argue against a power-coercive strategy because there is no grand payoff that will offset the high cost of using the power-coercive strategy. There are no low-stakes change problems. If the stakes are low, no one cares, and resistance levels will be low. Avoid Power-Coercive strategies in low stakes situations. Time Frame: Short time frames argue for a power-coercive strategy. Longer time frames argue for a mix of rational-empirical, normative-reeducative, and environmental-adaptive strategies. Expertise: Having available adequate expertise at making change argues for some mix of the strategies outlined above. Not having it available argues for reliance on the power-coercive strategy.

7.3 Preparing the Organization for Introduction | 453

Dependency: This is a classic double-edged sword. If the organization is dependent on its people, its ability to command and demand is limited. On the other hand, if the people are dependent on the organization, their ability to oppose is limited. Mutual dependency almost always signals a requirement to negotiate.” Nickols (2010), p. 6

If you are involved in a system introduction that brings wide and disruptive change, it is strongly recommended to concentrate on change management. Many studies confirm: technical obstacles can be overcome, while organizational resistance is challenging and cultural issues outright difficult. In every book about IT project management, there is a chapter about managing change, resistance and conflict, e. g. Marchewka 2013, p. 346.

7.3.2 Training for New Information Systems Moving from an old system to a new one requires that end users are trained to use the new system. Detailed documentation showing how the system works from both a technical and end-user standpoint is finalized during conversion time for use in training and everyday operation (Laudon/Laudon 2014, p. 531). Several studies have exposed a lack of proper training as one of the main reasons why new systems, like ERP applications, did not live up to the expectations. The direct cost (e. g. paying trainers) and indirect cost (user work time during training) of training can easily surpass the cost of licenses and hardware (see TCO in chapter 1). This makes training a top target for quick cost cutting whose negative effects will show up later in using the software. We cannot cover all educational aspects of training and will focus on two aspects especially relevant for management:  Planning and organizing training  Evaluating training success.

7.3.2.1 Designing the Training Plan There are multitudes of training formats available (e. g., web-based virtual classrooms, computer-based training, knowledge warehouses, video courses, self-study books, and pop-up help screens) to suit every need of any sized company with small or large budgets. A variety of these methods improves efficiency and effectiveness, because not all users learn the same way (Motiwalla/Thompson 2011, p.218). Some authors also stress the need for educating rather than just training users and other people involved in the system. That means educating them to understand the process, rather than just showing how to “point and click” certain operations. It should involve real data and real cases, and a dedicated practice environment must be provided. Practicing on a test or developer system will disrupt training and frustrate

454 | 7 Creating and Introducing IS

users if they are misused as bug finders. Only very good coordination allows training and testing on one system; if you can afford it – avoid it. Training should start early and does not need to be completed with going live. In any case, software training should be based on a solid training plan and be optimized in cost and value adjusted to the system and organization to be trained. A consulting company specializing in organizing ERP training (ISC) suggests the following deliverables for a training plan: “The prerequisite end user skills plan outlines the business skills and knowledge end users must obtain before ERP training begins, along with a timeline for acquisition of these prerequisites. The training staffing plan defines the talent mix and resources required for the ERP training project. It identifies resources committed and needed for analysis, design, development, delivery, and administration of training and spots possible gaps to be closed by staffing. The training delivery plan answers basic questions about how the curriculum is going to be developed and delivered. It contains an overview of tools needed, logistical challenges, technical infrastructure weaknesses, training system environment, and delivery mechanisms. It also provides an initial timeline for rollout of education and training. The curriculum matrix is the most useful reference for training designers, and it will grow into a big, complex document over the life of the project. It lists tasks to be trained and information to be presented for each job role in the new environment. The budget estimates the cost of internal and external resources for development and delivery.” http://www.isc-usa.com/whitepappers/ Seven%20Pieces%20of%20the%20ERP%20Training%20Puzzle.pdf

The budget addresses the cost to the organization for end-user training. Good budgeting will involve a comprehensive and realistic view of all possible cost involved. Typical spending categories are hardware, (additional) software licenses, tools for remote access to the training system, design and production of training materials, internal staff that needs to be replaced temporarily during training hours, consultants and training developers, trainers and training support. Especially in ERP implementations, there is not only the need to understand the software, but also for understanding processes or the redesign for processes, so there is always a software and a process side in training as well. The roles in training within the company might be described as follows (Heierhoff et al. 2011, p. 507). Please note that external trainers are not listed here.  Process Owners are champions at management levels who will connect knowledge needs with operations of an organization.  Super Users/Process Experts act as connectors across an organization and, in addition, beneficiaries of strengthened knowledge flows. They might be SME’s during the project phase (see chapter 7.1.3.3).  End users are knowledge consumers and beneficiaries of strengthened knowledge flows.

7.3 Preparing the Organization for Introduction | 455

 

The IT department acts as enabler and technical support of knowledge management solutions. The human resource department (HR) also plays a role in software training because, in most companies, HR generally is in charge of organizing and purchasing training.

For details on the planning and organization of good ERP training, please take a look at the literature cited in this chapter.

7.3.2.2 Measuring Training Success Planning and organizing needs to be supplemented by controlling in order to answer the ultimate question, “Is the training efficient and effective?” This question is more difficult to answer in education and training than, for example, in manufacturing. In manufacturing, right after production the workers or an MES will feed back data from the shop floor into the ERP system listing the amount of scrap work, good parts and rework to measure the success of production. This does not work the same way in teaching and training, since its success only will show later in using the system. A still widely used and accepted training evaluation model was framed by Kirkpatrick 1959 and suggests a multilevel approach to measure quality and success of training. The four levels of measuring success in training are Reaction, Learning, Behaviour and Results and can be exemplified by training for a new CAD program here:  Reaction would be the immediate reaction of the trainees to whether they enjoyed the training and subjectively found it to be useful. This can be done by an evaluation form, as you do sometimes for your classes or professional training.  Learning measures the acquisition of certain skills, knowledge and facts and attitudinal change. Usually, this is checked by a test or an exam, e. g. a test asking about the function of the CAD system.  Behaviour takes a look at whether the trained users now really work differently with the system. This assessment is based on the objectives of the course and are assessed through tests, observations, surveys, and interviews with coworkers, supervisors, and so on. For example: do the users employ standard templates of the CAD system more often now instead of formatting everything by themselves?  Results finally represent the hard facts: did the support issues for the CAD system decrease? Do the users work faster with fewer errors on the CAD system? The following figure suggests how to apply these four levels of evaluation to get an accurate and early figure of the success of ERP training in the overall implementa-

456 | 7 Creating and Introducing IS

tion and training process. The authors distinguish between training of the implementation team (the project team) and training of the end users.

Project Preparation

Business bluePrint/Systems design

Realization

Final preparation

Go & Live

Postimplementation

Create training plan Team training Team reaction Team learning

Team Behavior Team results

Draft end-user training Enduser training

End-user Follow-up And training

End-user reactions End-user learning

End-user behavior End-user results

Training plan monitoring

Fig. 7.28: ERP Training Evaluation Framework (Based on Estevez (2002), p. 11)





The training plan should be created right in project preparation, since it has to be aligned with other project tasks, like customizing and testing. Team training on the ERP software will start parallel to systems design, since the team needs to know how the software works at this point of time. This training does not need to be specially drafted – a standard training package might be sufficient here. During systems design and realization, the end user training is drafted to specific needs, processes and customizations in the company. It will actually start during final preparation and be executed during going live. It will later change into continuous follow up and improvement process.

7.3 Preparing the Organization for Introduction | 457



 

 

Training plan monitoring will check whether the training plan created in the first step is executed as planned. This will be done by checking whether training lessons really took place and the users really attended. Immediately during and after team learning, the reactions and learning results of the project team can be evaluated by feedback questionnaires and tests. Team behaviour and team results can be evaluated after team training is finished. Only then can behaviour be observed and results of working with the system be measured. Immediately during and after end user learning, reactions and learning results of the end users can be evaluated by feedback questionnaires and tests. End user behaviour and end user results can be evaluated after end user training is finished. Only then can behaviour be observed and results of working with the system be measured.

This framework is explicitly created for standard software like ERP, as you can see by the ERP specific phases, but it might be applied to other big software introductions, as well. The segmented early evaluation ensures tight control on the training plan. It also enables learning from bad evaluations early so as to improve and adjust training. This would not be possible when starting the evaluation after going live.

7.3.3 Introducing New or Improved Information Systems The implementation of a software system does not work by simply switching on the new software. There are three main areas in the critical phase of implementation that management needs to consider:  Determine the readiness of the organization to go live  Choose and execute an optimum conversion strategy  Steering the stabilization phase after going live and deliver “Early Live Support”.

7.3.3.1 Go Live Readiness for Implementation The implementation phase just before going live is one of the most critical success factors for a project’s overall success. At this point, the perspective must change – away from simply following a project plan. Before going live, the only question should be: will everything (not only the software) be ready to go live on the day desired, what is missing and what are we going to do about missing parts? This information is called “go live readiness” and it is assessed in the go-live readiness process. It should begin several months before the go live date and involve as many team members as possible (Motiwalla/Thompson 2011, p. 214). The first assessment might show tremendous gaps and many things as unready, but this

458 | 7 Creating and Introducing IS

Group 2

Group 1

Site 2

Criterion

Minimum Site 1

no. # Category

Criticality

is not unusual. This shock must not lead to frustration, but must be converted into action. In this phase, all “almost done” work packages will be clearly marked as “incomplete” and this might lead to tension in the team. This should especially not lead to an immediate postponement of the go live date. Motiwalla/Thompson (2011, p. 215) rather suggests to let three assessments pass before deciding on a postponement: once the first assessment showed the gaps, the project might have sped up and experienced project managers warn to take out the pressure too early.

Key measures

Current

Contingent

Decision "Pass

actual

Asess- Asessment

workouround

Owner

status

ment Date

Status"

Web server installed, 95% tested, stable. All required Go-live on

Tech InfraWeb M

1.04 structure

x

Nina

available for 1 80%

Nov. 11

Victor

month prior

available

2014

87%

Nov. 20

available

2014

software installed, tested. production

servers Server available during

Readiness

Web server to Go-live

scheduled hours Use legacy Rainer

Data converted 4.02 n

on

85% of data

programs to

Conversio Conversi L

x

converted

view retirees.

x

Geisler

successfully

successfully

Post-

Readiness criteria

conversion fix …

…

…

… … … … … …

…

…

…

…

…

…

Fig. 7.29: Go Live Readiness Assessment

 

      



No. #: Each item is identified by a unique predefined number. Category: Readiness items are assigned to a certain category or type, like technical infrastructure readiness, operational readiness, testing readiness, conversion readiness and so on. Criterion: What activity or component needs to be ready? Criticality: A high, medium, or low criticality will be assigned according to possible impact on the go live date. Site or group: Area, location, or group that must be ready. Not all units of the company might need to be ready at the go live date. Key measures: How will the readiness be measured? Workaround: If the task or activity is not complete before Go-live, is there an acceptable workaround? Decision Owner: Name of the person responsible for making this decision or person in charge of that item. Minimum Pass: Usually, a percentage of task or activity that must be completed before going live. This can be anywhere from 85 % to 100 % completion according to the project plan. But beware of the 95 % syndrome (see chapter 7.1.3.4). Current Status: This is the status as of the readiness assessment.

7.3 Preparing the Organization for Introduction | 459





Assessment: This is usually a red, yellow, green indicator. Red means that, given the current assessment, this activity will not be ready before the Go-live date. Yellow indicates that, in all likelihood, the task or activity will be completed. Green indicates the activity is complete. Assessment Date: Date on which the task or activity was assessed.

This is, again, quite some work to be done and to be organized. In bigger IT-projects, there is support to the project manager called PMO (Project Management Office) that will execute and document tasks like this. The readiness assessment must be reviewed by the teams and with senior management for consensus once it is done and documented (Motiwalla/Thompson 2011, p. 217).

7.3.3.2 Conversion Strategies for Implementation If the organization is ready according to the readiness assessment, the new or improved software can be put to work and “go live”. This can be done in several ways and must be decided after careful consideration. Imagine a technical company switching from an old PPS and accounting system to a new integrated ERP system. There are thousands of transactions each day (e. g. invoices) and the P&L statement required by law must be absolutely consistent. This cannot be achieved with a mix of both systems. When will the new system take over the data? Basically, there are three approaches to this question that are described in the figure below. Direct Cutover

Parallel Strategy

Old system

Old system New system

New system Target date

Target date

Phased Approach Old system New system Phase 1

Phase 2

Target date

Phase 3

Target date

Target date

Fig. 7.30: Three Basic Conversion Strategies for Introducing New Systems (Based on Marchewka (2013), 412 ff.)

460 | 7 Creating and Introducing IS

In the direct cutover approach (also called “big bang”), the new one is turned on and the old system is shut down. All data flows into the new system immediately. This may be appropriate when quick delivery of the new system is important because the old one does not work properly anymore and the system is not missioncritical. This strategy is risky and may result in major delays, frustrated users, lost revenues, and missed deadlines. It will put high pressure on the project team. In the parallel strategy, old and new systems run concurrently. It may be appropriate when the failure of the system can have a major impact on the organization. It provides a fall back option and a backup in case of problems. It takes longer and requires more resources than a direct cutover. Since users need to operate two systems at the same time, it places more pressure on them. In the phased approach the system is introduced in modules or in different parts of the organization incrementally. This allows for an organized approach for introducing systems modules or upgrades in different departments or geographical locations. Experience with earlier implementations in some units help make implementations go more smoothly in others. It takes longer and may cost more than the direct cutover approach. Early introductions might affect later stages if they are not finished in time. Additionally, these approaches may be supported by a pilot study strategy. It introduces the new system to a limited area of the organization, such as a single department or operating unit. When this pilot version is complete and working smoothly, it is rolled into the rest of the organization, either simultaneously like in a direct cutover, or in stages like in a phased approach (Laudon/Laudon 2014, p. 531). Each approach has its advantages and disadvantages and is suited for different situations and contexts. It should be considered and decided at project start as part of the overall strategy and must not be improvised shortly before going live.

7.3.3.3 Stabilization and Early Live Support Since the only reason for using IS is improving the business, the going live is not a goal in itself even though it is very prominent in project planning and on a management level. However, “pressing the button” to start the new software just leads into the so called “stabilization” phase, which might take another 60 to 90 days. In this time, there will be many teething problems, new requirements will arise, training needs to be completed and adjusted, and so on. Simultaneously researching and fixing problems of multiple components working together is still far away from a stable, smooth running system. According to Motiwalla/Thompson (2011, p. 220), typical issues arising in the phase of stabilization are:  “Customizations add to the complexity if they are not documented and communicated properly.

7.3 Preparing the Organization for Introduction | 461









Not being able to perform ad hoc activities (like exporting a design) is another issue during early life of the system. The new system is capable of ad hoc activities, but users are still learning how to accomplish the activity that seemed so simple in the legacy system. This is often frustrating to users or managers, and it sometimes leads to low morale or motivation.” Often, processes are redesigned (see chapter 7.3.1.1) before introduction. So, business processes are new to users, and they will make mistakes as they follow the new process for the first time. If the organization opts for a parallel implementation approach, the ERP system is operated concurrently with the old legacy system. This is labour intensive and might lead to confusion and additional work keeping the data in sync. To use the system in real live work for the very first time will lead to a lot of incidents (questions, wishes and problems). It is not easy to sort out whether it is a real bug or problem or just a wish, that is not implemented since it was never planned.”

Most of these issues and countermeasures will result in higher resource requirements. The following figure shows how an ERP introduction will lead to different resource requirements during implementation and applications management. This example depicts a direct cutover strategy; it will look more stretched in a parallel strategy. Resource Requirements

Applications Management Operations and Postproduction

Implementation

High Production Med

Low Base Personnel Strategy & Design Develop- Tes- Go- BackRequirements & Gap ment ting Live log Fig. 7.31: Resource Requirements in ERP Introduction (Based on Motiwalla/Thompson (2011), p. 221)

Required Maintenance Major New Modules Upgrades

462 | 7 Creating and Introducing IS

During the early phases of an ERP project, resources will built up during requirements engineering and peak while the software is programmed or customized. Once the software goes live, some developers will leave the team. However, during deployment and early live support, other tasks will keep the organization busy. After the software is introduced, its evolution is not finished. First, the backlog of features and functions not implemented in the initial go live will be produced and deployed. Since markets, as well as business and legal environments change, there will be more additional modules and major upgrades necessary. Maintenance and further developments will become more costly and intense with time away from introducing the state of the art initial package at go live. So what causes so much work during and after going live? Motiwalla/Thompson (2011, p. 222) describe post implementation support in five points:  Training will go on after going live depending on the training strategy and training plan chosen.  Go-live support needs to support the everyday work with the new system, so all basic tasks of the business get done. Software errors within the system or faulty use by the user will be mixed in this phase and need to be differentiated by the help desk.  Data validation must ensure that users enter the right data and the system also delivers correct data outputs. Additionally, there might be data in the system that was not converted correctly from the old system.  During the implementation process, and even while in production, software errors/bugs will be encountered and reported to the vendor for a solution. Once the error is resolved through coding changes or other means, the vendor will distribute the patch/fix to the software for testing and implementation.  No system is ever complete: businesses change or grow, and with that the system must keep pace to remain current. In addition to patches/fixes, vendors (or developers) will release upgrades to the product. While upgrades are not as elaborate as an implementation, they must be planned and managed using an implementation methodology to ensure the upgrade is implemented effectively. So far we have focused on big system changes, especially introducing a new ERP system and the according processes. For a CAD introduction, this all might apply on a smaller scale and shift more to technical necessities and less organizational understanding. Finally, there is a human and cultural effect in the phase of early live support: the project team worked together as a unit with the clear goal of getting the project live on time, specification and budget. Now it is transformed or replaced by the staff for everyday work. This is a different world now and it can be hard for project members to leave “Project Island” and dive into the sea of “Daily Work”. It is a management task to keep up motivation for staff during these times and ensure that the

7.4 Summary of chapter 7 | 463

knowledge about the software and the project will be preserved and documented after the go live date. After implementation, the management of IT systems will gradually be taken over by structures and processes of IS management that can be modelled after the ITIL concept described in chapter 5.

7.4 Summary of chapter 7 There are many diagrams available that help in designing the information system in detail. Specifically, the UML family offers a variety of models for describing structure and behaviour of the systems to be created. There are many different programming languages; however, C++ and Java play a dominant role for standard software today. Customizing of standard software, like an ERP system, might become just as demanding as programming and causes cost and benefit for the organization. In project planning, it is difficult to estimate work packages for software projects and there are several estimation techniques to forecast them. The most advanced and complex is COCOMO, which illustrates the factors that can make a software project costly. There are some special issues about the organization and staffing of a software project that have to be considered, and risk management has by now become a standard feature of software project management. Testing plays an important role in quality management and is quite different from “Quality Management Systems”, according to ISO 9001. Testing is costly, but necessary, and needs to be separated in different levels called unit, system and acceptance test. Especially test cases for unit and systems tests look quite different and each have specific techniques and procedures. Creating good test cases represents the core of testing. Testing also needs the appropriate environment and staff and must be planned according to the overall project plan. The test and the use of the new system will reveal errors (bugs) in the software and the management of those bugs plays a decisive role in improving the software during testing. An information system is software plus organization and therefore, new software might enable or demand organizational changes. One of the most efficient, but also disruptive, optimization approaches is Business Process Redesign that radically changes and improves processes and their results. Optimizing processes before introducing software will yield a higher benefit from the software, but the software will also establish and demand compliance to processes. Organizational changes do not happen by themselves, and must not emerge unguarded in order to reach the desired change in a sustainable way. Training is one of the key success factors for new software. Management can improve it by creating good training plans and establishing an early evaluation of different stages of the learning process. Before the new system is turned on, the “golive readiness” of the organization should be evaluated. The actual introduction of

464 | 7 Creating and Introducing IS

software must follow a clear cutover strategy suited for the application and the organization. Introduction does not suddenly end with the go live date, but rather extends into a phase of stabilization and early live support for the system that has its own challenges and tasks to be supported.

7.5 Literature for chapter 7 Baik, J.: COCOMO II Model Definition Manual Version 1.4, University of Southern California 1998, http://sunset.usc.edu/research/COCOMOII/Docs/modelman.pdf Boehm, B.: The COCOMO II Suite of Software Cost Estimation Models, Barry Boehm, USC COCOMO/SSCM Forum 21 Tutorial November 2006, http://sunset.usc.edu/events/2006/CIIForum/pages/presentations/The%20COCOMO%20II% 20Suite-Forum21.ppt Bruegge, B.; Dutoit, H.: Object Oriented Software engineering – chapter 11 (Testing), 2009, www.cs.uga.edu/~jam/home/courses/csci4050/testing/L23_UnitTesting_ch11lect1.ppt Draheim, D.: Business Process Technology: A Unified View on Business Processes, Workflows and Enterprise Applications, Springer 2010. Esteves, J., Pastor, J., Casanovas, J. : A Framework Proposal for Monitoring and Evaluating Training in ERP Implementation Projects, Technical Research Report Universidad Politécnica Catalunya, Barcelona, Spain July 2002, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.5350 Heierhoff, V., Arntzen, A., Muller, G.: A Training Model for Successful Implementation of Enterprise Resource Planning, in: World Academy of Science, Engineering and Technology 2011, International Science Index 60, 5(0), 1597–1604. http://www.waset.org/journals/waset/v60/v6094.pdf Kaner, C.: What Is a Good Test Case?, Florida Institute of Technology Department of Computer Sciences, 2003, http://www.kaner.com/pdfs/GoodTest.pdf Laudon K.; Laudon J.: Management Information Systems (13th edition), Prentice Hall 2014 Marchewka, J.: Information Technology Project Management: International Student Version, 4th Edition, John Wiley & Sons 2012. Motiwalla, L.; Thompson, J.: Enterprise Systems for Management (2nd edition), Prentice Hall 2011. Nickols, F.: Four Change Management Strategies, Distance Consulting 2010, http://www.nickols.us/four_strategies.pdf Sommerville, I.: Software engineering, 9th international edition, Pearson 2011.

7.6 Review Questions for Chapter 7 7.6.1 Close: UML Behaviour Diagrams Please choose which UML behaviour diagram is described here. Every answer is only to be used once. 1)

[Use case, Context model, Sequence, Activity, Data flow, Deployment] diagrams show who is acting on what processes and instances in an overview.

7.6 Review Questions for Chapter 7 | 465

2)

[Use case, Context model, Sequence, Activity, Data flow, Deployment] diagrams simply show the other systems in the environment, not how the system being developed is used in that environment.

3)

[Use case, Context model, Sequence, Activity, Data flow, Deployment] diagrams may be used to define business processes in detail.

4)

[Use case, Context model, Sequence, Activity, Data flow, Deployment] diagrams are used to model the order of interactions between the actors and the objects in a system and the objects themselves.

5)

[Use case, Context model, Sequence, Activity, Data flow, Deployment] diagrams describe which data is interchanged by the objects and from where they come.

7.6.2 Close: Critical Requirements that Help Choosing Basic Architectural Patterns Please choose which requirement is important to produce the suggestion for the according architecture described here. Every answer is only to be used once. 1)

If [Performance, Security, Safety, Availability, Maintainability] is very important: The system architecture should be designed using fine-grain, selfcontained components that may readily be changed. Producers of data should be separated from consumers and shared data structures should be avoided.

2)

If [Performance, Security, Safety, Availability, Maintainability] is very important: The architecture should be designed to localize critical operations within a small number of components, with these components all deployed on the same computer, rather than distributed across the network.

3)

If [Performance, Security, Availability, Maintainability] is very important: A layered structure for the architecture should be used, with the most critical assets protected in the innermost layers, with a high level of security validation applied to these layers.

4)

If [Performance, Security, Safety, Availability, Maintainability] is very important: The architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system.

5)

If [Performance, Safety, Availability, Maintainability] is very important: The architecture should be designed so that operations to be protected are all located in either a single component or in a small number of components.

466 | 7 Creating and Introducing IS

7.6.3 Choose: Basic “Customization” in the SAP-Sense Check four actions that are part of basic “customization” in the SAP-Sense. 1)

The real company structure needs to be expressed in SAP objects, e. g. defining our warehouse in Hamburg as a SAP storage location (see learning object 4).

2)

Programming additional functions and modules for basic SAP applications in ABAP – the SAP programming language.

3)

Change workflows in SAP, e. g. changing procurement workflows in materials management to ensure a faster order – process, that fits the company.

4)

Languages, currencies and colours have to be assigned, e. g. setting everything to €.

5)

Roles and rights need to be defined, e. g. what transactions a strategic purchaser is allowed to execute.

6)

Programming interfaces in SAP to connect the ERP to CRM and other company systems.

7)

Decide what fields to use and what to show in certain data views and transactions, e. g. hiding standard fields that are not applicable to our business at all.

7.6.4 Choose: Problems with Intense Customization of ERP-Systems Please mark four problems of heavily customized ERP-Systems: 1)

The more the system needs to be customized, the less it can rely on the tests, experiences and the standards of the software.

2)

If the system needs to be customized heavily in order to fit the current process, while many other companies are fine with the standard – maybe our processes are not good.

3)

Customizations might take away company specific competitive advantages.

4)

Upgrades might become more difficult, since the customized code needs to be rewritten to support newer versions of the software.

5)

Customized Systems have a much higher failure rate.

6)

Software support by the vendor becomes more difficult or might diminish completely.

7.6 Review Questions for Chapter 7 | 467

7.6.5 Close: Methods of Estimating the Effort of a Software Project Please choose the estimation technique described here. Every answer is only to be used once. 1)

[Guesstimating, The Delphi Technique, Time Boxing, Top-Down estimation, Bottom-up estimating, Parametric calculation] involves several experts on a topic that estimate the same item. Then the results are redistributed to them and they discuss the differences to finally agree on a value or take an average of their opinions.

2)

[Guesstimating, The Delphi Technique, Time Boxing, Top-Down estimation, Bottom-up estimating, Parametric calculation] is really taking a guess on the numbers. It is based on feeling rather than on facts. Although often used, it is not very professional and cannot be called a method at all.

3)

[Guesstimating, The Delphi Technique, Time Boxing, Top-Down estimation, Bottom-up estimating, Parametric calculation] very rigidly assigns a certain time for a task. It takes the risk that the task will not be completed and available is just what is completed after the allocated time.

4)

[Guesstimating, The Delphi Technique, Time Boxing, Top-Down estimation, Bottom-up estimating, Parametric calculation] starts with time and cost for the whole project allowed. The leaders of project parts or certain modules then have to distribute these imposed numbers further down the line.

5)

[Guesstimating, The Delphi Technique, Time Boxing, Top-Down estimation, Bottom-up estimating, Parametric calculation] lets individuals responsible for certain tasks estimate the effort/work for their tasks. This could yield a realistic number for the work needed. However, there needs to be a culture of openness and a good relationship with the programmers and project workers involved.

6)

[Guesstimating, The Delphi Technique, Time Boxing, Top-Down estimation, Bottom-up estimating, Parametric calculation] is the best, but also the most costly, estimation. Many parameters of the project are evaluated and points are awarded to those parameters in our project in order to calculate the overall effort via several formulas.

7.6.6 Close: Function Point Method for Calculating the Basic Effort of Creating an IS Choose the parameter for the function point method to describe the basic size of a project that is described here. Every answer is only to be used once:

468 | 7 Creating and Introducing IS

1)

Count each major logical group of user data or control Information in the Software system as a logical internal file type: [Inputs, Outputs, Files, Interfaces, Queries]

2)

Count each unique user data or control output type that leaves the external boundary of the Software system being measured: [Inputs, Outputs, Files, Interfaces, Queries]

3)

Count each unique user data or user control input type that (i) enters the external boundary of the Software system being measured and (ii) adds or changes data in a logical internal file: [Inputs, Outputs, Files, Interfaces, Queries]

4)

Files passed or shared between Software systems should be counted as external interface file types within each system: [Inputs, Outputs, Files, Interfaces, Queries]

5)

Count each unique input-output combination, where an input causes and generates an immediate output as an external inquiry type: [Inputs, Outputs, Files, Interfaces, Queries].

7.6.7 Close: Effort Multipliers for Calculating the Size of the Project Choose the COCOMO Effort Multiplier for adjusting the project size that is described here. Every answer is only to be used once: 1)

This measure attempts to capture the effect large data requirements have on product development, e. g. testing: [Data Size, Documentation match to lifecycle needs, Product Complexity, Develop for Reuse, Required Software Reliability]

2)

This is the measure of the extent to which the software must perform its intended function over a period of time: [Data Size, Documentation match to life-cycle needs, Product Complexity, Develop for Reuse, Required Software Reliability]

3)

This is the combination of areas that characterizes the complexity of the product or a sub-system of the product, such as control operations, computational operations, device-dependent operations, data management operations, and user interface management operations: [Data Size, Documentation match to life-cycle needs, Product Complexity, Develop for Reuse, Required Software Reliability]

4)

This cost driver captures the suitability of the project's documentation needs: [Data Size, Documentation match to life-cycle needs, Product Complexity, Develop for Reuse, Required Software Reliability]

5)

This cost driver accounts for the additional effort needed to construct components intended for reuse on the current or future projects: [Data Size, Documen-

7.6 Review Questions for Chapter 7 | 469

tation match to life-cycle needs, Product Complexity, Develop for Reuse, Required Software Reliability]

7.6.8 Close: Types of Team Members Choose the kind of team member that is described here. Every answer is only to be used once. 1)

[Project Managers, Module Experts, Subject Matter Experts, Users and internal IT-Staff] will later use and maintain the system. They will deliver requirements, tell about how they do processes and are trained on the system

2)

[Project Managers, Module Experts, Subject Matter Experts, Users and internal IT-Staff] are responsible for analyzing requirements and converting them into solutions within the software. They provide direction and application knowledge with respect to business process design, configuration, testing, training, and implementation.

3)

[Project Managers, Module Experts, Subject Matter Experts, Users and internal IT-Staff] who are sometimes being supported by a Program Management Office (PMO) in big projects.

4)

[Project Managers, Module Experts, Subject Matter Experts, Users and internal IT-Staff] provide coordination and facilitation of communications between the project team and the organization. They coordinate and prioritize functional requirements. They provide leadership and functional expertise in support of the implementation with specific knowledge in one or more business processes.

7.6.9 True/False: Professional and Cultural Diversity in Team Dynamics Please check all statements about IT project work that are TRUE: 1)

Scientific research mostly agrees that interdisciplinary teams can work very effectively with above average creativity, if these cultural differences are managed properly.

2)

They have a higher rate of failure, even if cultural differences are considered and managed

3)

A software project should not just somehow begin. It should be opened with a team building event that binds inside and outside personnel, as well as software and functional staff.

470 | 7 Creating and Introducing IS

4)

In almost every study about the success of software creation and implementation, commitment of senior management at starting event is seen as vital, but less important in the further course of the project.

5)

Staff and professional consultant turnover happens seldom in projects.

6)

Project management needs to minimize the negative effect of knowledge going away and minimize the cost of introducing new members.

7.6.10 Choose: The “Almost Done!” Syndrome as a Threat to IS Project Controlling and Success A programmer needs to adjust a large chunk of code by hand. There were 20 days for this task estimated in the project plan. What will the programmer most likely report on the following days, for how far she is done with her work? Assume that the “almost done/95 %” syndrome fully applies here and she is actually quite on time with her work: 1)

Day 5: [25 %, 50 %, 75 %, 95 %]

2)

Day 10: [25 %, 40 %, 75 %, 95 %]

3)

Day 15: [40 %, 50 %, 75 %, 95 %]

4)

Day 20: [50 %, 80 %, 95 %, 100 %]

7.6.11 Choose: Evaluating and Reporting Risk A project team has evaluated both probability and impact of risks on a 3 step scale. They ask you to put the risks into one of three categories: a) Top Priority: Develop individual counter strategy and reconsider daily b) Medium Priority: Draw raw standard strategy and reconsider weekly c) Low Priority: Just monitor regularly

7.6 Review Questions for Chapter 7 | 471

Risk 1) It is impossible to recruit staff with the skills required for the project 2) The database used in the System cannot process as many transactions per second as expected 3) Key staff are ill at critical times in the project 4) The size of the Software is underestimated 5) Changes to requirements that require major design rework are proposed 6) Required training for staff is not available 7) The Organization is restructured so that different management are responsible for the project 8) The time required to develop the Software is underestimated 9) Customers fail to understand the impact of requirements changes 10) Code generated by code generation tools is inefficient

Probability

Impact

High

Serious

Moderate

Tolerable

Moderate High

Serious Insignificant

Low

Serious

Moderate

Insignificant

High

Serious

High

Tolerable

Moderate

Tolerable

Low

Insignificant

7.6.12 Close: Strategies for Handling Risk Basically, there four strategies for how to handle a risk, like e. g. the risk of an unforeseen peak in requests to the software, that leads to losing customers due to system failure. Chose the ones that are described here: 1)

[Avoidance, Reduction/Mitigation, Sharing, Retention] of a risk means to accept and budget it: If the peak hits our system and we cannot handle the request, the system just will get slower and might even lose some customers. That is OK for us, since we counted that in and budgeted this.

2)

[Avoidance, Reduction/Mitigation, Sharing, Retention]: The possible processes or functions are not realized with the software and are not operated by the software. Instead, there will be an organizational workaround, e. g. handling requests by hand.

3)

[Avoidance, Reduction/Mitigation, Sharing, Retention] of risks might be handled by outsourcing the operation. It is the problem of the outsourcer to handle the requests.

4)

[Avoidance, Reduction/Mitigation, Sharing, Retention] will try to lower severity or probability of the impact. For example, implementing an overflow mechanism that slows the system but does not let it crash. Some customers will not be pleased, but we will lose less of them.

472 | 7 Creating and Introducing IS

7.6.13 True/False: Testing and QM Please check 3 statements about the relationship between testing and quality management (QM) that are TRUE: 1)

Testing is the same as QM.

2)

QM is a part of testing.

3)

QM concerns all results of the software lifecycle, while testing is focused on the finished software product.

4)

Testing can play an important part in practical QM.

5)

An ISO certification for QM also defines how testing is organized.

6)

QM and testing should be coordinated, but can exist in parallel.

7)

QM process starts as soon as the final product is finished.

7.6.14 Close: Capability Maturity Model (CMM) What CMM level is described here? Assign the right level. Every answer is only to be used once. 1)

Level [1, 2, 3, 4, 5]: Managed – Quantitative metrics for measuring and assessing productivity and quality are established for both software products and processes which are characterized as being quantifiable and predictable.

2)

Level [1, 2, 3, 4, 5]: Processes are repeatable. Basic policies, processes, and controls for managing a software project are in place. Previous project successes can be repeated by other project teams on other projects following the same process.

3)

Level [1, 2, 3, 4, 5]: Optimizing – At this level of software process maturity, the whole organization is focused on continuous process improvement.

4)

Level [1, 2, 3, 4, 5]: Organizations on this level are characterized by an immature software organization in which the software process is ad hoc and often reactive to crises. It does not have a stable environment for software projects. Success of a project rests largely with the people on the project and not the processes that they follow.

5)

Level [1, 2, 3, 4, 5]: Defined – Software engineering and management processes are documented and standardized throughout the organization.

7.6 Review Questions for Chapter 7 | 473

7.6.15 Close: Different Levels of Testing Please assign the right name for the test described here. Every answer is only to be used once. 1)

The [Unit test, component test, system test, release and acceptance test] ensures that single objects or modules work together. This is focused on the interfaces working together without error. It shows how different functions across units will work together from a technical point of view.

2)

The [Unit test, component test, system test, release and acceptance test] also tests the system as a whole, but from a radically different perspective. It will decide whether the internal or external customer accepts the product as finished.

3)

The [Unit test, component test, system test, release and acceptance test] will ensure that single objects are working properly, like calculating results correctly producing outputs from inputs, etc.

4)

In a [Unit test, component test, system test, release and acceptance test] the IS is tested as a whole with all its software and hardware components. It is testing business processes from a customer perspective.

7.6.16 Close: Errors, Bugs and Faults Please choose what is described here. Every answer is only to be used once. 1)

[Failure, Erroneous state (error), Fault, Validation]: The mechanical or algorithmic cause of an error. This is commonly called a bug. Correcting such an error in the code is called “debugging”. Example: a developer forgot to add a parameter for converting inches into centimeters.

2)

[Failure, Erroneous state (error), Fault, Validation]: Activity of checking for deviations between the observed behaviour of a system and its specification. Example: entering values in inches and checking whether an export in the metric system shows the correct expected result.

3)

[Failure, Fault, Validation]: Any deviation of the observed behaviour from the specified behaviour: CAD system does deliver wrong numbers of the geometry when design is exported in metric system. Lengths and diameters are always too small.

4)

[Erroneous state (error), Fault, Validation]: The system is in a state such that further processing by the system can lead to a failure. Example: the calculation for the export of designs is wrong.

474 | 7 Creating and Introducing IS

7.6.17 Close: Elements of Unit-testing Please choose what object of the unit test is described here. Every answer is only to be used once. 1)

[Module Interfaces, Local data structures, boundary related conditions, independent paths, Error handling paths] are tested to review if errors are handled properly by them or not.

2)

It is observed that much software often fails at [Module Interfaces, Local data structures, boundary related conditions, independent paths, Error handling paths]. That’s why boundary related conditions are always tested to make sure that the program is properly working at its edges.

3)

[Module Interfaces, Local data structures, boundary related conditions, independent paths, Error handling paths] are tested to inquire if the local data within the module is stored properly or not.

4)

[Module Interfaces, Local data structures, boundary related conditions, independent paths, Error handling paths] test checks whether the information is properly flowing in to the program unit (or module) and properly out of it or not.

5)

All [Module Interfaces, Local data structures, boundary related conditions, independent paths, Error handling paths] are tested to see that they are properly executing their task and terminating at the end of the program.

7.6.18 Calculate: Boundary/Partition Testing A program is fed with problems and downtimes of wind turbines during the last 30 days. Depending on the number of downtimes, the program will react differently according to the specification: fewer than 5 downtimes will lead to no reaction at all, 5 to 12 will give out a list with the machines and reasons of downtimes, and more than 12 will give a signal to initiate an immediate maintenance procedure. You are only allowed to create a test with five different values. What values should you use? Name 5 values (ae) for your test-design.

7.6.19 Close: Process of Acceptance Test Please fill the gaps to describe the process of the acceptance test. Every answer is only to be used once. 1) In the first step [planning acceptance testing, defining acceptance criteria, deriving acceptance tests, running acceptance tests, negotiating test results, ac-

7.6 Review Questions for Chapter 7 | 475

cepting or rejecting system] will deliver [the testing report, a test plan, test criteria, tests, test results, final result of acceptance]. 2)

In the second step [defining acceptance criteria, deriving acceptance tests, running acceptance tests, negotiating test results, accepting or rejecting system, planning acceptance testing] will deliver [the testing report, a test plan, test criteria, tests, test results, final result of acceptance].

3)

In the third step [deriving acceptance tests, defining acceptance criteria, planning acceptance testing, running acceptance tests, negotiating test results, accepting or rejecting system] will deliver [the testing report, a test plan, test criteria, tests, test results, final result of acceptance].

4)

In the fourth step [defining acceptance criteria, running acceptance tests, planning acceptance testing, deriving acceptance tests, accepting or rejecting system] will deliver [the testing report, a test plan, test criteria, tests, test results, final result of acceptance].

5)

In the fifth step [defining acceptance criteria, planning acceptance testing, deriving acceptance tests, running acceptance tests, negotiating test results, accepting or rejecting system] will deliver [the testing report, a test plan, test criteria, tests, test results, final result of acceptance].

6)

In the sixth step [accepting or rejecting system, defining acceptance criteria, planning acceptance testing, deriving acceptance tests, running acceptance tests, negotiating test results] will deliver [the testing report, a test plan, test criteria, tests, test results, final result of acceptance].

7.6.20 Close: Resolution of Bugs Please choose the type of resolution of a bug/fault that is described here. Every answer is only to be used once. 1)

[Fixed, duplicate, “won’t fix”, works for me, invalid], means that the problem described is not a bug, but is simply just a desired function that was never part of the specification.

2)

Often, developers try the test case or the function themselves and they will tell the others then that they [fixed, duplicate, “won’t fix”, works for me, invalid] the bug, so the bug disappeared.

3)

The bug has been identified as already known and therefore [was fixed, is a duplicate, is a “won’t fix”, works for me, is invalid], which happens quite often.

4)

The bug [was fixed, is a duplicate, is a “won’t fix”, works for me, is invalid] and now the test case and the software works as desired.

476 | 7 Creating and Introducing IS

5)

The developers set the bug to [fixed, duplicate, “won’t fix”, works for me, invalid] in this release of the software, because they can’t, or a management decision prevents them from doing so.

7.6.21 Close: Severity of Bugs Please choose the severity of bugs that are described here. Every answer is only to be used once. 1.

[Blockers or Showstoppers, Critical bugs, Major bugs, Minor and Trivial issues] are usually reserved for enhancements or “nice to haves”. They document a deviation from specification, but the software will work just as well.

2.

[Blockers or Showstoppers, Critical bugs, Major bugs, Minor and Trivial issues] influence the functionality considerably, too, but they typically have a workaround or a quick fix that can be applied post-release.

3.

[Blockers or Showstoppers, Critical bugs, Major bugs, Minor and Trivial issues] need to be fixed immediately. They will prevent the product from working if the system would be released in that state.

4.

[Blockers or Showstoppers, Major bugs, Minor and Trivial issues] have a workaround and can be put off without impacting the functionality of the application.

7.6.22 Close: Forms of Organizational Change Choose what kind of organizational change is described here. Every answer is only to be used once. 1)

Faster and more comprehensive change carries high rewards, but offers substantial chances of failure. This would be to leave out controllers completely in calculating the cost or even to outsource special cost calculation. This is called [automation, rationalization, redesign, paradigm shift].

2)

This type of change is achieving more quality with evolutionary smaller changes. For example, there is an automatic mechanism in the CAD system that checks the plausibility of numbers entered. Also, the designers are educated and incentivized to avoid errors. This is called [automation, rationalization, redesign, paradigm shift].

3)

Relatively slow-moving and slow-changing strategies present modest returns but little risk. For example, a CAD system now calculates material cost of a new design automatically. This is called [automation, rationalization, redesign, paradigm shift].

7.6 Review Questions for Chapter 7 | 477

4)

An intelligent CAD system with a lot of automation might make current business more and more obsolete. It might force the engineering company to seek new business areas, e. g. to offer consulting services for design to cost, and target costing projects for their customers. This is called [automation, rationalization, redesign, paradigm shift].

7.6.23 Close: Basic Change Management Strategies Please choose the kind of basic change management approach, with its assumptions, that is described here. Every answer is only to be used once. 1)

People oppose loss and disruption, but they adapt readily to new circumstances. Change is based on building a new organization and gradually transferring people from the old one to the new one. This is called the [Empirical-Rational, Normative-Reeducative, Power-Coercive, Environmental-Adaptive] approach.

2)

People are social beings and will adhere to cultural norms and values. Change is based on redefining and reinterpreting existing norms and values, and developing commitments to new ones. This called the [Empirical-Rational, Normative-Reeducative, Power-Coercive, Environmental-Adaptive] approach.

3)

People are rational and will follow their self-interest – once it is revealed to them. Change is based on the communication of information and the proffering of incentives. This called the [Empirical-Rational, Normative-Reeducative, Power-Coercive, Environmental-Adaptive] approach.

4)

People are basically compliant and will generally do what they are told or can be made to do. Change is based on the exercise of authority and the imposition of sanctions. This called the [Empirical-Rational, Normative-Reeducative, Power-Coercive, Environmental-Adaptive] approach.

7.6.24 Close: Designing the Training Plan for User Testing Please choose which part of the training plan is described here. Every answer is only to be used once. 1)

The [prerequisite end user skills plan, training staffing plan, training delivery plan, curriculum matrix, budget] defines the talent mix and resources required for the ERP training project. It identifies resources committed and needed for analysis, design, development, delivery, and administration of training and spots possible gaps to be closed by staffing.

2)

The [prerequisite end user skills plan, training staffing plan, training delivery plan, curriculum matrix, budget] estimates the cost of internal and external re-

478 | 7 Creating and Introducing IS

sources for development and delivery. It also addresses the cost to the organization for end-user training. 3)

The [prerequisite end user skills plan, training staffing plan, training delivery plan, curriculum matrix, budget] outlines the business skills and knowledge end users must obtain before ERP training begins, along with a timeline for acquisition of these prerequisites.

4)

The [prerequisite end user skills plan, training staffing plan, training delivery plan, curriculum matrix, budget] answers basic questions about how the curriculum is going to be developed and delivered. It contains an overview of tools needed, logistical challenges, technical infrastructure weaknesses, training system environment, and delivery mechanisms. It also provides an initial timeline for rollout of education and training.

5)

The [prerequisite end user skills plan, training staffing plan, training delivery plan, curriculum matrix, budget] is the most useful reference for training designers, and it will grow into a big, complex document over the life of the project. It lists tasks to be trained and information to be presented for each job role in the new environment.

7.6.25 Close: Measuring Training Success Please choose what level of training success is described here. Also bring them into an appropriate logical order from closest to the training measure to farthest away from the training measure. Every answer is only to be used once. 1)

[Behaviour, Results, Reaction, Learning] takes a look whether the trained users now really work differently with the system. This assessment is based on the objectives of the course, which are assessed through tests, observations, surveys, and interviews with co-workers, supervisors, and so on. For example: Do the users employ standard templates of the CAD system now more often instead of formatting everything by themselves? This is the [First, Second, Third, Fourth] level to be measured.

2)

[Behaviour, Results, Reaction, Learning] would be the immediate response of the trainees as to whether they enjoyed the training and subjectively found it to be useful. This can be done by an evaluation form as you do sometimes for your modules. This is the [First, Second, Third, Fourth] level to be measured.

3)

[Behaviour, Results, Reaction, Learning] finally represents the hard facts: Did the support issues for the CAD system decrease? Do the users work faster with fewer errors on the CAD system? This is the [First, Second, Third, Fourth] level to be measured.

7.6 Review Questions for Chapter 7 | 479

4)

[Behaviour, Results, Reaction, Learning] measures the acquisition of certain skills, knowledge and facts, and attitudinal change. Usually, this is checked by a test or an exam, e. g. a test asking about the function of the CAD system. This is the [First, Second, Third, Fourth] level to be measured.

7.6.26 Close: Fields of a Go Live Readiness Assessment matrix Please name the fields of a go live readiness Assessment matrix that are described here. Every answer is only to be used once. 1)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Minimum Pass, Current Status]: A high, medium, or low criticality will be assigned according to possible impact on the go live date.

2)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Current Status]: Name of the person responsible for making this decision or person in charge of that item.

3)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Current Status]: What activity or component needs to be ready?

4)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Current Status]: This is the status of the readiness assessment.

5)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Current Status]: Usually, a percentage of a task or activity that must be completed before going live. This can be anywhere from 85 % to 100 % completion according to the project plan

6)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Current Status]: Area, location, or group that must be ready. Not all units of the company might need to be ready on the go live date.

7)

[Criterion, Criticality, Site or group, Key measures, Decision Owner, Minimum Pass, Current Status]: How will the readiness be measured?

7.6.27 Close: Basic Implementation/Cutover Strategies Please name the implementation strategy described here. Every answer is only to be used once. 1)

In the [direct cutover, parallel strategy, phased strategy, pilot study strategy] old and new systems run concurrently. It may be appropriate when the failure of the system can have a major impact on the organization.

480 | 7 Creating and Introducing IS

2)

In the [direct cutover, parallel strategy, phased strategy], the system is introduced in modules or in different parts of the organization incrementally. This allows for an organized approach for introducing systems modules or upgrades in different departments or geographical locations.

3)

In the [direct cutover, parallel strategy, phased strategy, pilot study strategy] approach (also called “big bang”), the new one is turned on and the old system is shut down. All data flows into the new system immediately.

4)

Additionally, these approaches may be supported by a [direct cutover, parallel strategy, pilot study strategy]. It introduces the new system to a limited area of the organization, such as a single department or operating unit. Only if it works well there will a rollout plan possibly be pursued.

7.7 Suggestions for Written Exercise or Groupwork for chapter 7 7.7.1 Creating a Test Case Create a test case for a function of a PDM-system (see chapter 3 for PDM systems). This can either be a unit test or a systems test (choose one). The function could be, e. g. a double entry check. Please formalize the test case with the typical information a test case should contain. Since you will not have all surrounding information, you can make up this content– the structure counts.

7.7.2 IT Project-Success Please research two or more empirical studies each about the success of a) general software and b) ERP projects. Present a synopsis of the key success and failure factors. Please explain the main differences in the key success and failure factors of ERP projects vs. general software projects.

8 Solutions for Review Questions 8.1 Review Questions for Chapter 1 1.7.1 Elements of an Application System: 1, 2, 4, 5 1.7.2 Advantages of IS: 1, 2, 5, 7, 8 1.7.3 Reasons for Problems with IS: a, d 1.7.4 Share Of Information Technology: b, b 1.7.5 Relation Between IT-Stock/Assets and Productivity: 3 1.7.6 Spending on Information Technologies: a-3, b-1, c-4, d-2 1.7.7 Distribution of IS and Running Cost in a TCO View: b, c, b 1.7.8 Types of Cost according to TCO: 1-c, 2-a, 3-a, 4-b, 5-c, 6-a, 7-a, 8-b, 9-b, 10-c 1.7.9 The ultimate goal of IS: 4 1.7.10 Classification of IS: 1-a, 2-f, 3-i, 4-k, 5-n, 6-p 1.7.11 Different IS Applications: 1-c, 2-d, 3-b, 4-e, 5-a 1.7.12 Functions of TPS systems: 1-b, 2-c, 3-f, 4-g 1.7.13 Management Systems: a-6, c-1, g-4, h-5, i-3, j-2, k-7 1.7.14 Characteristics of a Process: 1, 4, 6 1.7.15 Notation Systems for Processes: 1-c, 2-b, 3-a 1.7.16 Automation Levels of a Workflow System: a-4, b-3, c-1, d-5, e-2

8.2 Review Questions for Chapter 2 2.7.1 Elements of MRP: 1, 4 2.7.2 Functions of MRP II – Steps: 1-c, 2-d, 3-a, 4-e, 5-b 2.7.3 Elements in MRP II Explained: 1-b, 2-a, 3-f, 4-c, 5-d, 6-e 2.7.4 Different Material Types: 1-c, 2-b, 3-a, 4-d, 5-e 2.7.5 Categories of BoMs: 1, 3, 4 2.7.6 Types of BoMs: 1-a, 2-b, 3-b, 4-a 2.7.7 Purposes of a Work Center: 1, 3, 4 2.7.8 Purposes of a Work Plan (Routing): 1, 2, 4, 7, 8 2.7.9 Calculation: Exploding a BoM: 130 units, 230 units, 3-80 kg, 420 kg 2.7.10 Calculation: Calculating Lead Time and Start of Production: 22th of April 2.7.11 Capacity Offered: a, b, b, b, c 2.7.12 The Cycle of Production Control: a-4, b-1, c-3, d-2 = 1-b, 2-d, 3-c, 4-a 2.7.13 Production Order: 3 2.7.14 Chose: PO Single Process Steps: 1-d, 2-b, 3-e, 4-a, 5-c 2.7.15 Calculation: Availability Check: a-48, b-60, c-60 2.7.16 Releasing the Production Order: 1, 2, 4, 7

482 | 8 Solutions for Review Questions

2.7.17 Standard Reference Model for Manufacturing IS: 1-b-c, 2-d-a, 3-a-c, 4-c-b 2.7.18 Information Contained in a Work Order Completion Message: 1, 4, 6, 8

8.3 Review Questions for Chapter 3 3.8.1 Dimensions of IS integration: 1-a, 2-c, 3-a, 4-b, 5-e, 6-b, 7-c, 8-d, 9-a, 10-e 3.8.2 Benefits of Integration: 1, 3, 4, 7, 8 3.8.3 Optimum Point of Integration: b 3.8.4 Difference Between ERP-Systems and Data Warehouse: 1, 2, 4, 6, 7 3.8.5 ETL Processes: 1-b, 2-a, 3-e, 4-c, 5-g, 6-d, 7-f = a-2, b-1, c-4, d-6, e-3, f-7, g-5 3.8.6 Error Correction in the Transformation of Data: 1, 2, 4, 5 3.8.7 Transformation of Data: 1-a, 2-c, 3-b 3.8.8 OLAP Cube Terms: d, c, c, b, b, c, a, c 3.8.9 Data Mining Operations: 1-b, 2-d, 3-c, 4-a 3.8.10 Knowledge Based Systems in Design: 1-d, 2-a, 3-c, 4-b 3.8.11 Reasons for Integrating CAD and PPS Systems: 1, 3, 4 3.8.12 Reasons for Implementing PDM: 1, 2, 4, 6 3.8.13 Basic Elements of the Web-Service Concept: 1-b-b, 2-a-a, 3-c-d, 4-d-c 3.8.14 Web Service Communication: 1-a-c, 2-c-a, 3-a-b, 4-b-a, 5-a-b, 6-b-a 3.8.15 Extension of Basic Web Service Communication: 1, 3, 4 3.8.16 Intercompany Integration via Exchange Standards: 1-c-a, 2-b-b, 3-d-c

8.4 Review Questions for Chapter 4 4.7.1 Evolution of Enterprise Systems: 1-c-b-a, 2-e-e-d, 3-d-c-b, 4-a-a-a, 5-b-d-c 4.7.2 Statements about Data Views: 2, 5 4.7.3 The Core Strength of an ERP-System: b, c, b, b 4.7.4 ACID Principle in ERP Database Operations: 1-a, 2-c, 3-b, 4-d 4.7.5 Client Server Structure and Tiers: 1-b, 2-a, 3-c 4.7.6 Client Server Operations: a, b, b, c, a, c 4.7.7 Advantages of Client Server: 1, 2, 4 4.7.8 Key Players of ERP: 3, 6, 9 4.7.9 Success of ERP Projects in the Last Years: 1-b, 2-c, 3-a 4.7.10 Modules in SAP: 1-f, 2-a, 3-c, 4-d, 5-b, 6-e = a-2, b-5, c-3, d-4, e-6, f-1 4.7.11 Order: Hierarchy of Terms in SAP: 6-3-5-4-7-2-1 4.7.12 Structures in Materials Management: 1-b, 2-c, 3-f, 4-a, 5-d, 6-e 4.7.13 Structures in Accounting: 1-a, 2-c, 3-b, 4-d, 5-e, 6-e, 7-g 4.7.14 Structures in Sales: 1-c, 2-a, 3-b, 4-a, 5-b, 6-b, 7-a, 8-a 4.7.15 Roles in an ERP System: 2, 4, 5, 7

8.6 Review Questions for Chapter 6 | 483

8.5 Review Questions for Chapter 5 5.7.1 Benefits of an IS management Framework: 1, 3, 5, 7 5.7.2 Different Frameworks for IS Management: 1-a, 2-a, 3-b 5.7.3 Questions of IS Governance: 1, 3, 4 5.7.4 Compliance vs. Governance: 1-a-b-b-a, 2-b-a 5.7.5 IT Compliance Checked by Auditors: 1, 4, 5, 7, 8 5.7.6 Business Strategy Tools as Base for IS strategy: 1-a, 2-a, 3-d, 4-a-a-d, 5-c 5.7.7 Business Strategy and IT strategy: 1-a, 2-a, 3-b, 4-b, 5-a and b!, 6-b, 7-b, 8-a 5.7.8 Strategic and Operative Questions of IT management: 1, 3, 4, 7 5.7.9 IT Strategy Written Down: 3-a, 4.2-b, 6-c, 6.6-a, 7.2-f, 8.1-g 5.7.10 Customer Supplier Relationships: 1-c, 2-d, 3-b, 4-a = a-4, b-3, c-1, d-2 5.7.11 Benefits of the ITIL Framework: 1, 3, 4, 7, 8, 9 5.7.12 Components of ITIL: 1-c, 2-f, 3-h, 4-d, 5-a, 6-b, 7-e, 8-g = a-5, b-6, c-1, d-4, e-7, f-2, g-8, h-3 5.7.13 Substructure and Chapters of Single ITIL Processes: 1-e, 2-a, 3-c, 4-b, 5-c 5.7.14 Responsibilities “Capacity Management”: 2, 4, 5, 8 5.7.15 Responsibilities “Incident Management”: 1, 2, 4, 7, 9, 10 5.7.16 Processes and Tasks in Service Transition: 1-b, 2-a, 3-b, 4-c, 5-c, 6-b, 7-a 5.7.17 Benefits of Good Change Management: 1, 3, 5, 6 5.7.18 Basic Steps of a CM Process: a-2, b-3, c-4, d-6, e-1, f-7, g-5 5.7.19 Institutions of Change Management: 1-a, 2-d, 3-b, 4-c 5.7.20 Authorization of Changes: 1-a, 2-b, 3-d, 4-c, 5-e 5.7.21 Contents of a Newly Raised Request for Change (RFC): 1, 2, 4, 6, 8 5.7.22 Change Management: Metrics and Controlling: 1, 3, 4, 7, 8 5.7.23 Interfaces of Change Management: 1-a, 2-d, 3-a 5.7.24 Operative and Strategic Tools of Controlling: 1, 4, 6, 7 5.7.25 IT Project Portfolio: 1-a, 2-d, 3-a, 4-b, 5-c 5.7.26 Characteristics of Good KPIs: 1, 2, 5, 7, 9

8.6 Review Questions for Chapter 6 6.7.1 Comparing SDLC with ERP-LC: 1-b-a, 2-b-b, 3-a-a, 4-c-a, 5-c-b, 6-d-b 6.7.2 A Broad Model of Software Development: 1-b, 2-c, 3-a, 4-c, 5-e, 6-d, 7-h 6.7.3 The Waterfall Model of Software Development: 1, 2, 5 6.7.4 The Spiral Model of Software Development: 1, 2, 4 6.7.5 Different Types of Prototypes: 1-d, 2-b, 3-a, 4-c, 5-e 6.7.6 Principles of Agile Development: 1, 4, 6, 7, 11 6.7.7 Benefits from Agile Programming: 2, 3, 5 6.7.8 Concerns and Barriers for Agile Programming: 1, 3, 6, 7 6.7.9 Elements of Scrum Project Management: 1-a-b, 2-d-a, 3-a, 4-b, 5-d, 6-d

484 | 8 Solutions for Review Questions

6.7.10 Converting Technical and Organizational Impact: 1-d, 2-b, 3-a, 4-c 6.7.11 Characteristics of Measurable Organizational Impacts: 1, 3, 6, 7 6.7.12 Full Value and Incremental Approach: a=150€, b= -30€, c=10€, d=140€ 6.7.13 Financial Plan: a=420.000€, b=270.000€, d=42.000€, e=296.000€, f=0,91 6.7.14 Facts to be Converted into Cash Positions: 1-c, 2-b, 3-a, 4-c 6.7.15 Types and Levels of Outsourcing: 1-a, 2-b, 3-c, 4-d, 5-d 6.7.16 Advantages and Disadvantages of Outsourcing: 1, 2, 4, 5, 6 6.7.17 Strategic Decision on Possible Outsourcing Targets: 1-b-a, 2-c-c, 3-a-b 6.7.18 Advantages of a SLA Agreement: 1, 2, 5, 7, 8 6.7.19 Elements and Chapters of a Good SLA: 1-b, 2-a, 3-f, 4-c, 5-e, 6-d 6.7.20 Sources of Information for Requirements: 2, 4, 8 6.7.21 Agenda of a Good Workshop: 1-f, 2-b, 3-h, 4-c, 5-i, 6-e, 7-d, 8-a, 9-a, 10-g 6.7.22 Possible Measures …: 1-a, 2-c, 3-a, 4-c, 5-e, 6-c, 7-a, 8-d, 9-e, 10-d, 11-e 6.7.23 The Requirements Specification Doc.: 1-a, 2-b, 3-c, 4-d, 5-e, 6-f, 7-g, 8-i 6.7.24 Using the Requirements Specification Document: 1-a, 2-e, 3-c, 4-d, 5-b 6.7.25 Scoring Model: a=0,80, b=27 %, c=1,20, d=8, e=12 %, f)=4,34

8.7 Review Questions for Chapter 7 7.6.1 UML Behaviour Diagrams: 1-a, 2-b, 3-d, 4-c, 5-d 7.6.2 Critical Requirements Choosing Architectural Patterns: 1-e, 2-a, 3-b, 4-d, 5-b 7.6.3 Basic “Customization” in the SAP-Sense: 1, 4, 5, 7 7.6.4 Problems with Intense Customization of ERP-Systems: 1, 2, 4, 6 7.6.5 Methods of Estimating the Effort of a Software …: 1-b, 2-a, 3-c, 4-d, 5-e, 6-f 7.6.6 Function Point Method: 1-c, 2-b, 3-a, 4-d, 5-e 7.6.7 Effort Multipliers for Calculating the Size: 1-a, 2-e, 3-c, 4-b, 5-d 7.6.8 Types of Team Members: 1-d, 2-b, 3-a, 4-c 7.6.9 Professional and Cultural Diversity in Team Dynamics: 1, 3, 6 7.6.10 The “Almost Done!” Syndrome: 1-b, 2-d, 3-d, 4-c or d (both correct) 7.6.11 Evaluating and Reporting Risk: 1-a, 2-b, 3-a, 4-b, 5-b, 6-c, 7-a, 8-a, 9-b, 10-c 7.6.12 Strategies for Handling Risk: 1-d, 2-a, 3-c, 4-b 7.6.13 Testing and QM: 3, 4, 6 7.6.14 Capability Maturity Model (CMM): 1-d, 2-b, 3-e, 4-a, 5-c 7.6.15 Different Levels of Testing: 1-b, 2-d, 3-a, 4-c 7.6.16 Errors, Bugs and Faults: 1-c, 2-d, 3-a, 4-a 7.6.17 Elements of Unit-testing: 1-f, 2-c, 3-b, 4-a, 5-d 7.6.18 Boundary/Partition Testing: a-4, b-5, c-8-9 or 10 (all correct), d-12, e-13 7.6.19 Process of Acceptance Test: 1-b-c, 2-f-b, 3-a-d, 4-b-e, 5-e-a, 6-a-f 7.6.20 Resolution of Bugs: 1-e, 2-d, 3-b, 4-a, 5-c 7.6.21 Severity of Bugs: 1-d, 2-b, 3-a, 4-b 7.6.22 Forms of Organizational Change: 1-c, 2-b, 3-a, 4-d

8.7 Review Questions for Chapter 7 | 485

7.6.23 Basic Change Management Strategies: 1-d, 2-b, 3-a, 4-c 7.6.24 Designing the Training Plan for User Testing: 1-b, 2-e, 3-a, 4-c, 5-d 7.6.25 Measuring Training Success: 1-a-c, 2-c-a, 3-b-d, 4-d-b 7.6.26 Fields of a Go Live Readiness Assessment: 1-b, 2-e, 3-a, 4-g, 5-f, 6-c, 7-d 7.6.27 Basic Implementation/Cutover Strategies: 1-b, 2-c, 3-a, 4-d

List of Figures Fig. 1.1: Fig. 1.2: Fig. 1.3: Fig. 1.4: Fig. 1.5: Fig. 1.6: Fig. 1.7: Fig. 1.8: Fig. 1.9: Fig. 1.10: Fig. 1.11: Fig. 1.12: Fig. 1.13: Fig. 1.14: Fig. 1.15: Fig. 1.16: Fig. 1.17: Fig. 1.18: Fig. 1.19: Fig. 1.20: Fig. 1.21: Fig. 1.22: Fig. 1.23: Fig. 1.24:

The Relationship Between Information System and Applications System (Based on Laudon/Schoder (2012) p. 18) | 2 Features of an Application System (Based on Laudon/Schoder (2012) p. 18) | 3 IS in Organizations (Close to Laudon/Schoder (2012) p. 32) | 5 IS The Cross-Linked Company (Close to Laudon/Schoder (2012) p. 37) | 6 Rise of Investments in Assets (Based on Laudon/Laudon (2012), p. 8.) | 11 Relation of Productivity and IS Investment (Based on Brynjolfson/Hitt (1998), p. 52) | 12 Percentage of Revenue Spent on IS in Various Industries (Based on Gartner (2011), p. 22) | 13 Investments and Running Costs (Based on Pfüller (2005), p. 19) | 15 Total Cost of Ownership | 16 Performance Evaluation with Return on Capital Employed | 18 Classification of IS (Close to Laudon/Schoder (2012), p. 435) | 20 Industry Value Chain (Based on Laudon/Laudon (2010), p. 103) | 22 Payroll Accounting Information System (Based on Laudon/Laudon (2010), p. 46) | 24 Materials Requirement Planning (MRP) (Based on Laudon/Schoder (2012), p. 444) | 25 Management Information Systems (Based on Laudon/Schoder (2012), p. 474) | 26 DSS Example (Based on Laudon/Laudon (2010), p. 49) | 30 Executive Support System (Based on Laudon/Laudon (2010), p. 52) | 31 Integrated Business Process- and Workflow Management (Based on Gadatsch (2012), p. 2) | 32 Process Versus Function (Based on Gadatsch (2012), p. 13) | 34 EPK Example for Giving out a Credit (Based on Gadatsch (2012), p. 80) | 37 EPK Notation of Elements (Based on Gadatsch (2012), p. 78) | 38 Swim Lane Diagram (Based on Gadatsch (2012), p. 85–86) | 39 The Process of Confirming an Order (Based on Gadatsch (2012), p. 229) | 40 Functions of a Workflow Management System (Based on Gadatsch (2012), p. 234) | 42

488 | List of Figures

Fig. 1.25: Value Chain of the Information System Industry (Based on Pussep et al. 2011, p. 6) | 44 Fig. 2.1: Manufacturing Drill Pipe (Based on http://www.nov.com/Drilling/Drilling_Tubulars/Drill_Pipe/Drill_Pipe_Ma nufacturing_Process.aspx) | 56 Fig. 2.2: Areas of Manufacturing Management Covered by MRP (Based on Hackstein 1989, p. 5) | 58 Fig. 2.3: Material Types in an PPS (Based on SAP “Standard Material Types” 2013) | 61 Fig. 2.4: Semi-finished Goods in SAP | 63 Fig. 2.5: Graphical Representation of a BoM (Based on SAP “BoMs” 2001, S. 15) | 64 Fig. 2.6: Categories of BoMs (Based on SAP “BoMs” 2001, S. 26) | 65 Fig. 2.7: Multilevel BoM | 66 Fig. 2.8: Single Level BoM | 67 Fig. 2.9: Quantity BoM | 68 Fig. 2.10: Maximum BoM and Configured BoM | 69 Fig. 2.11: Work Center (Based on SAP “Work-Centers” 2001, S, p. 9) | 71 Fig. 2.12: Capacity of a Work Center | 72 Fig. 2.13: Work Plan | 73 Fig. 2.14: Maximum Work Plan and Configured Work Plan | 74 Fig. 2.15: Deterministic Disposition | 75 Fig. 2.16: Lead Time Offset | 77 Fig. 2.17: Capacity Planning and Capacity Leveling | 79 Fig. 2.18: Capacity Planning (Based on SAP “Capacity Planning” 2001, p. 10) | 80 Fig. 2.19: Reporting the Load of Work Places | 81 Fig. 2.20: Overview Production Control | 82 Fig. 2.21: Production Order – Important Elements | 84 Fig. 2.22: Production Order Information | 85 Fig. 2.23: Operation Overview | 86 Fig. 2.24: Component Overview | 86 Fig. 2.25: Display Material Cost Estimate with Quantity Structure | 87 Fig. 2.26: PO Single Process Steps | 88 Fig. 2.27: ATP Example | 89 Fig. 2.28: Standard Reference Model for IS in Manufacturing (Based on ZVEI 2001, p. 9) | 92 Fig. 2.29: IS Types and Hardware (Based on Brandl/Owen 2003, p. 27) | 93 Fig. 3.1: Integration of Information Processing (Based on Laudon/Schoder (2012), p. 466) | 108 Fig. 3.2: Optimum Degree of Integration (Based on Laudon/Schoder (2012), p. 472) | 110

List of Figures | 489

Fig. 3.3: Fig. 3.4: Fig. 3.5: Fig. 3.6: Fig. 3.7: Fig. 3.8: Fig. 3.9: Fig. 3.10: Fig. 3.11: Fig. 3.12: Fig. 3.13: Fig. 3.14: Fig. 3.15: Fig. 3.16: Fig. 3.17: Fig. 3.18: Fig. 3.19:

Fig. 3.20: Fig. 3.21: Fig. 3.22: Fig. 3.23:

Fig. 3.24: Fig. 4.1: Fig. 4.2: Fig. 4.3: Fig. 4.4: Fig. 4.5: Fig. 4.6: Fig. 4.7: Fig. 4.8: Fig. 4.9:

IS Pyramid (Based on Laudon/Schoder, (2012), p. 433) | 111 Horizontal Integration (Based on Laudon/Schoder (2012), p. 478) | 114 Data Warehouse (Based on Laudon/Schoder (2012), p. 307) | 115 Business Analytics from SAP (Source: SAP 2011) | 117 Extract, Transform Load (ETL) | 118 Data Cube | 122 Hierarchy of Dimensions in a Data Cube | 123 OLAP operations Slicing and Dicing | 124 OLAP Operations Drill Down and Roll Up | 125 Process of Data Mining | 126 Data Mining: Example of Association | 127 Collaborative Filtering at Amazon (Source: Amazon.com) | 128 Original CIM Vision (Based on Gausemaier (2008)) | 129 Product Data Management (Based on Krause (2008), p. 14) | 132 Product Lifecycle (Based on Krause (2008), p. 12) | 133 Levels of Integration (Based on Laudon/Schoder (2012), p. 493) | 136 RPC Processes and Interactions (Source: http://technet.microsoft.com/enus/library/cc738291(v=ws.10).aspx5) | 139 Message-Oriented Middleware (Based on Ruh (2001), p. 42) | 140 Message Queue-Model | 141 Web service communication (Based on Sotomayor (2005)) | 142 Extended SOA definition (Based on: http://www.brockhausgruppe.de/wp-content/plugins/aspdf/generate.php?post=836) | 146 Intercompany Communication Rules (Based on Laudon/Schoder (2012), p. 499) | 148 Different Material Information for Different Company Functions | 163 Different Data Views Structure the Information in a Master Data Record in SAP | 164 Simple Order to Cash Process Going Through Three Departments (Laudon/Schoder (2010), p. 484) | 165 Functional Silos (Based on Laudon (2012) p. 133) | 166 Integrated ERP System (Based on Laudon/Laudon (2012), p. 134) | 166 Business process “End to End” (Source: SAP) | 167 Stages in IT Infrastructure Evolution (Based on Laudon/Schoder (2012), p. 214) | 169 Three Tiered Architecture Example of ERP System (Based on Motiwalla/Thompson (2012), p. 35) | 170 Vendor Market Share in 2010 (Panorama Consulting (2011), p.4) | 175

490 | List of Figures

Fig. 4.10: ERP Software Market Share in 2012, by Company (Statista, Source: Forbes) | 175 Fig. 4.11: Market Share of ERP-Systems in Manufacturing (Panorama Consulting (2011), p. 15) | 176 Fig. 4.12: Who Chooses Which Vendor? (Panorama Consulting (2011), p. 5) | 177 Fig. 4.13: Success of ERP Implementation: Cost, Duration, Benefits (Panorama Consulting (2013), p. 13–16) | 179 Fig. 4.14: Implementation Outcome (Panorama Consulting (2013), p. 4) | 181 Fig. 4.15: Single Aspects of Satisfaction (Panorama Consulting (2013), p. 6) | 182 Fig. 4.16: Business Benefits and Value Potentials of Integrating a Process with SAP (Source: SAP 2005) | 183 Fig. 4.17: Structure of SAP Modules Last Century (Source: SAP) | 187 Fig. 4.18: Recent Structure of SAP Modules this Century (Source: SAP) | 188 Fig. 4.19: Important Objects in MM Needed for Master Data Records (Based on SAP-Material) | 191 Fig. 4.20: Overview of Connections Between Finance and Accounting Elements (Based on SAP-Material) | 194 Fig. 4.21: Objects Needed for Financial Modules (Based on SAP Material) | 196 Fig. 4.22: Organizational Units and Logical Objects in Sales (Based on SAP Material) | 198 Fig. 4.23: Client Server Structure for SAP Remote Access to Case Studies | 204 Fig. 4.24: Login Details (Source: SAP) | 204 Fig. 5.1: A Map of ITSM and Related Frameworks | 219 Fig. 5.2: Relationships between Governance, Risk Management and Compliance (Based on Kranawetter (2009), p. 24) | 223 Fig. 5.3: Synergies Between Business and Regulatory Targets (Based on Kranawetter (2009), p. 28) | 224 Fig. 5.4: Porter’s Generic Strategies | 226 Fig. 5.5: The Relationships of Business Strategy, IS Strategy and IT Strategy (Based on Laudon/Schoder (2012), p. 830) | 228 Fig. 5.6: The Process of Deriving an IS Strategy (Based on Tiemeyer (2007), p. 42ff) | 230 Fig. 5.7: Customer Supplier Relationship on Every Level Between Business and IT (Based on itSMF (2007), p. 26) | 236 Fig. 5.8: Processes in the Center of Management Attention (Based on itSMF (2007), p. 30) | 237 Fig. 5.9: Processes Do Not Care About Departments (Based on itSMF (2007), p. 31) | 238 Fig. 5.10: Logic of the ITIL Framework 3.0 Stages (Based on van Bon (2009) p. 18) | 240 Fig. 5.11: Processes in the ITIL Stages | 241

List of Figures | 491

Fig. 5.12: Disk Busy and IO Activity Reports for Windows and Unix Systems (Based on http://www.teamquest.com/products/cmis/data-storage/) | 245 Fig. 5.13: Incident Management (Based on http://www.hcboos.net/blog/2009/01/21/integrating-itil-andautomation) | 246 Fig. 5.14: Continual Service Improvement and the Service Lifecycle (Based on Rance (2011), p. 33) | 247 Fig. 5.15: The Context of Change Management (Based itSMF (2007), p. 87) | 254 Fig. 5.16: Basic Steps of a Good CM Process (Based on van Bon (2009), p. 237) | 256 Fig. 5.17: Basic Change Management Process (Based on http://itservicemngmt.blogspot.de/2007/07/change-managementquick-reference.html) | 259 Fig. 5.18: Example of a Change Authorization Model (Based on Rance (2011), p. 78) | 262 Fig. 5.19: Risk Matrix (Based on Rance (2011), p. 75) | 265 Fig. 5.20: Change, Configuration, and Release Management (Based on http://technet.microsoft.com/en-us/library/cc966506.aspx) | 267 Fig. 5.21: Change Management and SACM (Based on Rance (2011), p. 87) | 268 Fig. 5.22: COBIT 5 Process Reference Model (Based on http://www.isaca.org/KnowledgeCenter/Blog/Lists/Posts/Post.aspx?ID=193) | 270 Fig. 5.23: Project Portfolio (Based on (Gadatsch 2011), p. 71) | 274 Fig. 5.24: IT Key Figures (Based on Gaddatsch (2012), p. 98) | 275 Fig. 5.25: Process of Management Accounting, Pricing and Planning of IT Services (Based on Barret/Grundy 2006, S. 5) | 278 Fig. 5.26: Allocation of Non-Direct IT Cost to IT Cost Objects via Activity Based Costing (Based on Neumann et al. 2004, p. 7) | 279 Fig. 6.1: Generic Software Development Cycle (SDLC) (Motiwalla/Thompson (2012), p. 114) | 301 Fig. 6.2: A Broad Model of Information System Development and Introduction | 304 Fig. 6.3: The Waterfall Modell (Based on Sommerville (2011), p. 30) | 306 Fig. 6.4: The Spiral Model (Based on http://leansoftwareengineering.com/wpcontent/uploads/2008/05/spiral_model_ boehm_1988.png) | 308 Fig. 6.5: The Rational Unified Process (RUP) (Based on http://www.ibm.com/developerworks/webservices/library/ws-soaterm2) | 310 Fig. 6.6: Reasons for Adopting Agile (Data based on VersionOne (2011), p. 6) | 314 Fig. 6.7: Agile Methodology Used (Data based on VersionOne (2011), p. 4) | 315

492 | List of Figures

Fig. 6.8: Fig. 6.9: Fig. 6.10: Fig. 6.11: Fig. 6.12: Fig. 6.13: Fig. 6.14: Fig. 6.15: Fig. 6.16: Fig. 6.17: Fig. 6.18: Fig. 6.19:

Fig. 6.20: Fig. 6.21: Fig. 6.22: Fig. 6.23: Fig. 6.24:

Fig. 6.25: Fig. 6.26: Fig. 6.27: Fig. 6.28: Fig. 6.29:

Agile Techniques Employed (Data based on VersionOne (2011), p.) | 316 Barriers to Further Agile Adoption (Data based on VersionOne (2011), p. 5) | 317 Concerns Against Adopting Agile Methodology (Data based on VersionOne (2011), p. 5) | 317 Benefits Obtained Implementing Agile (Data based on VersionOne (2011), p.) | 318 Elements and Process of Scrum, the leading Agile Model | 319 Burndown Chart as SCRUM Reporting Tool | 320 Process of the Strategy Phase – Feasibility and Business Plan (Based on Marchewka (2012), p. 42) | 323 Example of an Incremental Business Plan with NPV Financial Calculation | 334 Simulating the NPV Impact of a Parameter Variance in the Business Plan | 337 Sources of Software (Based on Laudon/Laudon (2013), p. 223) | 339 Types of Outsourcing (Based on Accenture (2005), S. 6) | 340 Types of Cloud Services and Examples Based on http://webapps.stackexchange.com/questions/301/what-is-cloud-vssaas-vs-asp | 342 Portfolio for basic outsourcing decision (Based on Gaddatsch (2012), p. 145) | 345 Cost Comparison Inhouse vs. Outsourcing Based on Material by www.supplyon.com | 347 SLAs Formalize Customer-Supplier Relationships Inside and Outside the Company | 350 Structure of Performance and Fees | 353 Use Case Diagram Defines Systems Boundaries in Requirements Engineering (http://www.agilemodeling.com/artifacts/useCaseDiagram.htm) | 35 6 The Process of Requirements Engineering (Based on Sommerville (2011), p. 101) | 358 Types of Non-Functional Requirements (Based on Sommerville 2011, p. 88) | 363 Language Template for a Structured Natural Language (Based on Sommerville (2011), p. 97) | 367 Example of a Multilevel Selection Process | 370 Weighted Scoring Model for Evaluating three Vendors from 1 to 10 | 375

List of Figures | 493

Fig. 7.1: Fig. 7.2: Fig. 7.3: Fig. 7.4: Fig. 7.5: Fig. 7.6: Fig. 7.7: Fig. 7.8: Fig. 7.9: Fig. 7.10: Fig. 7.11: Fig. 7.12: Fig. 7.13: Fig. 7.14: Fig. 7.15: Fig. 7.16: Fig. 7.17: Fig. 7.18: Fig. 7.19: Fig. 7.20: Fig. 7.21: Fig. 7.22: Fig. 7.23: Fig. 7.24:

Available Types of UML Diagrams for Different Purposes (Based on http://www.uml-diagrams.org/uml-22-diagrams.h) | 397 Systems Context for the System MHC-PM (Based on Sommerville 2011, p. 122) | 398 UML Activity Diagram for the Process of Involuntary Detention (Based on Sommerville 2011, p. 123) | 399 Data Flow Diagram for a Mail-In University Registration System (Based on Laudon (2013), p. 533) | 400 Hierarchy of Functions (Based on Laudon (2014), p. 534) | 401 A Generalization Hierarchy (Based on from Somerville (2011), p. 132) | 401 Class Inherit Diagram (Based on Laudon/Laudon (2014), p. 535) | 402 Aggregation of Two Unrelated Classes to Form a New Class (Based on Sommerville (2011), p. 113) | 403 Architecture for a Packing Robot System (Based on Sommerville (2011), p.149) | 404 Level of Customization (http://panorama-consulting.com/the-long-termeffects-of-heavy-erp-system-customization) | 409 The 95 % Syndrome in Documenting the State of Completion | 419 07.12 – Software for Creating a Risk Matrix (http://www.intaver.com/images/RP_Product_RiskMatrix.html) | 422 Quality Management and Software Development (Based on Sommerville (2011), p. 653) | 425 Process Based Quality (Based on Sommerville (2011), p. 657) | 426 Capability Maturity Model and its Levels (Based on Marchewka (2013), p. 325) | 427 A Generic Model of the Software Testing Process (Based on Sommerville (2011), p. 210) | 428 Hierarchy of Test Types (Based on Bruegge/Dutoit (2009), p. 20) | 429 Equivalence Testing and Partition Boundaries (Based on Sommerville (2011), p. 15) | 432 Systems Test Involving Several Modules on Different Machines and Hardware (Based on Sommerville (2011), p. 186) | 434 The Process of Acceptance Testing (Based on Sommerville (2011), p. 224) | 436 Test Environments for Different Test Levels | 439 Example of a Test Case for Testing the Database of a Telecom Provider | 443 Life Cycle of a Bug as Managed by Bugzilla (Based on http://www.bugzilla.org/docs/3.0/html/lifecycle.htm) | 444 Cumulated Open and Closed Bugs by Severity at Release Dates | 446

494 | List of Figures

Fig. 7.25: Risks and Rewards of Different Levels of Organizational Changes (Based on Laudon/Laudon (2014), p. 520f) | 447 Fig. 7.26: Business Process Reengineering Cycle | 449 Fig. 7.27: Identifying and Extracting a Potentially Parallel Activity (Based on Draheim (2010), p. 20) | 450 Fig. 7.28: ERP Training Evaluation Framework (Based on Estevez (2002), p. 11) | 456 Fig. 7.29: Go Live Readiness Assessment | 458 Fig. 7.30: Three Basic Conversion Strategies for Introducing New Systems (Based on Marchewka (2013), 412 ff.) | 459 Fig. 7.31: Resource Requirements in ERP Introduction (Based on Motiwalla/Thompson (2011), p. 221) | 461

List of Tables Table 1.1: Table 1.2: Table 1.3: Table 1.4: Table 1.5: Table 1.6: Table 1.7: Table 1.8: Table 1.9: Table 2.1: Table 3.1: Table 3.2: Table 3.3: Table 3.4: Table 3.5: Table 4.1: Table 4.2: Table 4.3: Table 4.3: Table 4.4: Table 4.5:

Table 4.6:

Four Changing Business Conditions (Based on Laudon/Schoder (2012) p. 8) | 4 Positive and negative impacts of IS on general and society level (Close to Laudon/Schoder (2012) p. 45) | 7 Examples of IS on Different Levels (Based on Laudon/Schoder (2012), p. 442) | 21 Functions of TPS Systems (Based on Laudon/Schoder (2012), p. 437) | 23 Object of Management Systems | 27 Management Systems (Based on Laudon/Schoder 2012, p. 436) | 28 Consolidated Consumer Products Corporation Sales (Based on Laudon/Laudon (2010), p. 48) | 29 Different Documentation Methods and Their Characteristics (Based on Gadatsch (2012), p. 102) | 35 Levels of Integration and Automation (Based on Gadatsch (2012), p. 248) | 43 Commitment Factor | 90 Organizational Position of Real Systems in the IS-Pyramid (Based on Laudon/Schoder (2012), p. 443445) | 112 Difference Between Operative Systems and Data Warehouses (Partly based on Gadatsch (2012), p. 286) | 116 Three “Classes” of Errors | 119 Example Data Warehouse Base Table | 121 Enhanced Web-Services Standards and Technology (Based on Wilde/Glushko 2011, p. 19) | 144 Evolution of Enterprise Systems (Texts from Motiwalla/Thompson (2012), p. 31) | 162 Typical ERP Vendors in 2012 (Based on Thompson/Motiwalla (2012), p. 47) | 174 Success of ERP Projects in Recent Years (Based on Panorama Consulting (2013), p. 2) | 178 Benefits and Limitations of Systems Integration (Based on Motiwalla/Thompson (2012), p. 70) | 180 ERP Modules From 3 Vendors (Based on Motiwalla/Thompson (2012), p. 84) | 186 Predefined Roles Offered by SAP (Source: http://help.sap.com/bp_ekit604/Documentation/ NWBC_How_to_Improve_User_Experience_via_Roles.ppt) | 202 Content of the SAP IDES Case Studies and Modules Used | 206

496 | List of Tables

Table 5.1: Table 5.2: Table 2.4: Table 5.3: Table 5.4: Table 5.5: Table 5.6: Table 5.7: Table 6.1: Table 6.2: Table 6.3: Table 6.4: Table 6.5: Table 6.6: Table 6.7: Table 6.8: Table 6.9: Table 6.10: Table 6.11: Table 6.12: Table 6.13: Table 7.1: Table 3.3:

Five Major IT Decision Domains (Based on Gartner (2002), p. 24) | 221 Targets of IT Strategy and Current Projects (Based on Gaddatsch (2012), p. 35) | 232 Tasks of IT-Controlling (Excerpt from Gomez et al. (2009), p. 4243) | 272 Tools of IT-Controlling (excerpt from Gaddatsch (2011), p.11– 12) | 273 Description Sheet for the KPI “First Fix Rate at Standard Software Bugs” (Based on Gadatsch (2012), p. 104105) | 276 Percentage of Labour and Equipment by IT Division (Neumann et al. (2004), p. 7) | 280 The Percentages Reported for Seven Activities (Neumann et al. (2004), p. 7) | 280 Percentage of IT Costs Consumed by the Cost Objects (Neumann et al. (2004), p. 7) | 281 Comparing and Contrasting SDLC with ERP-LC (Based on Thompson/Motiwalla 2012, p.128) | 302 Potential Areas of Impact (Based on Marchewka (2012), p. 45) | 326 Full Value Approach (Close to Schmidt 2003, p. 12) | 327 Incremental Approach (Close to Schmidt 2003, p. 12) | 328 Suggested Outline for Developing and Writing a Business Case (Marchewka (2012), p. 57) | 332 Advantages and Disadvantages of Outsourcing in Different Categories | 343 Total Cost off Offshore Outsourcing (Based on Laudon/Laudon (2013), p. 543) | 348 Distinct Service Levels as a Means of Standardization in an SLA (Gadatsch (2012), p. 122) | 352 Example for a Requirements Workshop Agenda (Based on Laudon/Schoder (2012) p. 8) | 361 Possible Measures for Non-Functional Properties (Based on Sommerville (2011), p. 90) | 364 Purposes of the Final Requirement Specification Document (Based on Sommerville (2011), p. 92) | 368 Additional Criteria for Evaluating Vendors (Taken from Motiwalla/Thompson (2012), p. 193) | 372 Pair Comparison for Weighing Different Criteria | 374 Parameters of the Function Point Method to Calculate the Basic Size of a Software (Baik (1998), p. 18) | 413 Project Scale Factors for COCOMO II View 1 (Based on Boehm (2006), p. 12) | 414

List of Tables | 497

Table 7.2: Table 7.3: Table 7.4: Table 7.5: Table 7.6: Table 7.7:

Effort Multipliers for COCOMO II (Baik (1998), p. 22ff.) | 415 Rating Table for the Effort Multiplier RELY (Required Software Reliability) (Baik (1998), p. 22) | 416 Risk Table (Sommerville (2011), p. 600) | 421 Criteria of Software Quality (Sommerville (2011), p. 656) | 424 Extract of a Test Plan (Based Laudon/Laudon (2014), p. 531) | 440 Basic Change Management Strategies (Nickols (2010), p. 2f) | 452

Index Acceptance criteria 436 Accounts receivable 194 Activity Based Costing 279 Activity diagram 399 Aggregation 120 Agile – benefit and risk 317 – origins and Agile Manifesto 312 – principles 312 – use in practice 313 Alignment 224, 227 95 % 5 (almost done) syndrome 419 Application system 2f. Application tier 171 ATP (Available To Promise) 89 Authorization (in ITIL) 261 Availability check 89 Balance sheet 195 Black box test 431 BMECat 148 BoM (Bill of Materials) 63, 130f. – categories in SAP 65 – maximum and configured 68 – multilevel 66 – quantity BoM 68 – single level 67 BPEL (Business Process Execution Language) 145 BPM (Business Process Management) 449 BPMN (Business Process Modelling Language) 145 BPR (Business Process Reengineering) 448 Bug 443 Burndown Chart 319 Business Area (in SAP) 197 Business plan 321 – documentation 331 – full value vs. incremental 327 – impact into financials 324 – process of creating 323 – sensitivity analysis 337 – spreadsheet 333 CAD (Computer Aided Design) 27, 130 Capacity Management (in ITIL) 243 Capacity planning 59, 78 – workload 81

Catalogue exchange standards 149 CAx technologies 130 Central Purchasing Organization (in SAP) 192 Change (in ITIL) – types and forms 264 Change (organizational) 447 Change Advisory Board (CAB) 260 Change Management (in ITIL) 253 – Benefits and Risk 254 – interfaces 266 – Process 255 – roles and institutions 260 – tools 262 Change Management (organizational) 451 – strategies 452 Change Manager 260 Chart of Accounts (in SAP) 197 CIM (Computer Integrated Manufacturing) 129 Class (software design) 402 Client (in SAP) 191 CMM (Capability Maturity Model) 426 CNC (Computer Numeric Control) 22, 93 COBIT 269 COCOMO 412 Commitment factor 89 Company Code (in SAP) 191 Compliance 222 Context diagram 398 Continual Service Improvement (ITIL stage) 247 Contract 378 Control Objectives (COBIT) 270 Controlling 271 – ITIL processes 266 Controlling (IT) – functions 271 – tools 272 Conversion strategy 459 CORBA 142 Cost advantages 10 Cost calculation 87, 195 – of Outsourcing 346 Cost center 16 – in SAP 197 Credit Control Area (in SAP) 196 CRM (Customer Relationship Management) 21, 113

500 | Index

Customizing 407 – problems 409 Data mining 125 – collaborative filtering 127 Data tier 171 Digital factory 130 Direct cutover 460 Distribution Channel (in SAP) 199 Division (in SAP) 199 DSS (Decision Support System) 29 DWH (Data Warehouse) 114 – differences to ERP 115 (DWH) Data Warehouse 115 Early life support 460 E-class 148 EDI (Electronic Data Interchange 149 Effort multipliers (COCOMO) 415 Enrichment 120 EPK (=EPC) 36 ERP (Enterprise Resource Planning) – architecture 168 – Benefits and risk 183 – Current developments 173 – History and evolution 161 – Modules of different vendors 186 – Success of implementation 178f. – Sucess of use 180 – Vendor market shares 174 Error 430 ESS (Executive Support System) 30 Estimation methods 411 ETL (Extract Transform Load) 117 Evaluation 251 – of outsourcing 344 Expert system 27 Extraction 118 Failure 430 Fault 430 Feasibility 329 Fit/gap approach 369 Five Forces model 225, 9 Function point method 413 Generic strategies 226, 9 Globalization 4 Go live readiness 457 Governance 220 Harmonizing 120 Horizontal integration – of design and production via PDM 128

– via programs 113 HTTP (HyperText Transfer Protocol) 142 IDES 205 Incident Management (in ITIL) 246 Industry 4.0 130 Information system 2 – levels 20 – types 19 Integration 108, 161 – benefits and risk 109 – optimal level 110 Internal transfer pricing 277 Investment in information technology 10, 14 ISO 9001 425 ITIL (Information Technology Infrastructure Library) 234 – basic nature 235 – benefits and Risk 238 – stages 240 – structure 239 IT-productivity paradox 12 ITSM (IT Service Management) 218 Job order planning 59 Knowledge Management (in ITIL) 252 KonTraG 223 KPI 274 – for Change Management 266 – for COBIT 270 Lead time offset 77 Legacy systems 143 Management accounting 193 – for IT controlling 276 Material 60 – master data 163 – semi-finished goods 63 – Types 61 Material classifications standard 150 MES (Manufacturing Execution System) 92 Message-oriented middleware 139 Microsoft Dynamics 174 Middleware 137 – Database Middleware 137 MIS (Management Information System) 28 (MIS) Management information system 26 MOV (Measurable Organizational Impact) 324 MRP 57 – extended MRP I 57 – MRP II 58 MRP (Material Requirements Planning) 24, 161

Index | 501

NPV 326 – sensitivity analysis 336 ODBC (Open Database Connectivity) 137 OLAP (Online Analytical Processing) 121 – classification 122 – Cube 122 – dimension 122 – Drill-Down 124 – Roll-Up 124 OLTP (Online Transaction Processing). 25 Open Source 173 OpenTrans 148 Operating Concern (in SAP) 196 Opportunity cost 16 Oracle 174 Order completion message 94 Order monitoring 59 Outsourcing – benefit and risk 342 – evaluation 344 – financial calculation 346 – goals 338 – types of 340 Parallel strategy 460 Pareto principle 420 Partition testing 431 Payroll accounting 23 PDM (Product Data Management) 108, 128, 130f. – lifecycle integration 132 – reasons for implementing 133 PESTEL 225 Phased approach 460 Plain vanilla implementation 409 Plant (in SAP) 191 PO (production order) 83 – activities 85 – Backwards Scheduling 88 – Components 86 – Forward scheduling 88 – information contained 85 – releasing 90 – timing 88 Portfolio – in strategic IT controlling 273 – outsourcing decision 345 PPS (Production Planning System) 57, 131, 162 Presentation tier 171 Process 31

– Change Management (ITIL) example 258 – definition 33 – documentation 35 – drawing 35 – integration via ERP 164 – of requirements engineering 358 – of testing 428 – service process in ITIL 237 Product lifecycle 133 Product owner (Scrum) 319 Production control 82 Production planning 74 – deterministic disposition 75 – quantity planning 75 – scheduling 77 Production program planning 59 Productivity 12 Programming 407 Project basic size (COCOMO) 413 Project controlling 419 Project manager 416 Project Planning 410 Project scale factors (COCOMO) 413 Prototype – types 309 Purchasing Group (in SAP) 192 Purchasing Organization (in SAP) 192 PWO (Planned Work Order) 75 Quality 424 Quality management 423, 425 Release and acceptance test 435 Release and Deployment Management (in ITIL) 250 Request for bids 377 Requirements – functional and non-functional 363 – sources of 359 Requirements document 364 Requirements engineering – creating information 359 – documentation 362 – goals and scope 355 – managing 354 – organizing 357 Requirements workshop 360 RFC (request for change, change request) 263 Risk management 420 – in ITIL 265 Risk matrix 421

502 | Index

Risk table 420 ROCE (Return On Capital Employed) 17 RoI (Return on Investment) 18 Role 201 RPC (Remote Procedure Call) 138 RUP (Rational Unified Process 309 Sales Area (in SAP) 199 Sales Office (in SAP) 198 Sales Organization (in SAP) 198 SAP – module PP 184 – modules 186 – modules CO and FI 193 – navigation, look and feel 200 – training 203 Scenario testing 437 SCM (Supply Chain Management) 21, 113 Scoring model 373 SCRUM 318 Sequence diagram 399 Service Assets and Configuration Management (SACM) 252 Service Design (ITIL stage) 243 Service levels 352 Service Operation (ITIL stage) 245 Service Strategy (ITIL stage) 242 Service Transition (ITIL stage) 248 Service Validation and Testing (in ITIL) 251 Shipping Point (in SAP) 192 SLA (Service Level Agreement) 349 – benefits 350 – document 352 SME (Subject Matter Expert) 417 SOA (Service Oriented Architecture 145 SOAP (Simple Object Access Protocol) 142 Software development cycle 301 – Broad Model 304 – classic models 305 SOX 222 Spiral model 308 Sprint (Scrum) 319 SQL (Standard Query Language) 137 Stakeholder 356 Storage Location (in SAP) 192 Strategy – business 226 – documentation 233 – IS 229 – process 230

Structure diagram 400 Structured natural language 367 Swim lane diagram 39 SWOT 225 System testing 433 Systems architecture 403 – decision for 406 – types 405 TCO (Total Cost of Ownership) 14 Test cases 441 Test plan 440 Testing – areas and levels 428 – environment 438 – organization 438 – Reporting progress 445 Three tier architecture 170 – benefits and risk 172 TPS (Operative Transaction System) 22 Training 453 – in SAP 200, 203 – measuring success 455 – success factor 180 Training plan 453 Transaction 183 Transformation 119 Transition Planning and Support (in ITIL) 249 UDDI 141, 144 UML diagrams 396 Unit testing 430 Use Case Diagram – during requirements engineering 356 Validation 430 Value chain 22 – of IT-companies 43 Vendor selection 369 – criteria 371 Vertical integration – in functional silos 111 – via data warehouse 114 Waterfall model 306, 312 Web service 141 – extensions 143 Web service stack 143 White box tests 431 Work center 70 – capacity 71 – purpose 70 Work plan

Index | 503

– called routing in SAP 72 – maximum and configured 73 Workflow 40

– management system (WMS) 42 WSDL (Web Services Description Language) 142