BAS_02_Folien.pdf

BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Unterrichtseinheit 02: Technische Grundlagen und Betriebsmodelle Prof. Dr. Petra Schubert Universität Koblenz Professur für Betriebliche Anwendungssysteme...

BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Unterrichtseinheit 02: Technische Grundlagen und Betriebsmodelle Prof. Dr. Petra Schubert Universität Koblenz Professur für Betriebliche Anwendungssysteme Universitätsstr. 1 D-56070 Koblenz http://bas.uni-koblenz.de Heutige Lernziele Die Studierenden … ◼ kennen technische Komponenten und Architekturformen Betrieblicher Anwendungssysteme, ◼ kennen die Vor- und Nachteile eines ASP-Betriebsmodells (Application Service Providing) für ERP-Software, ◼ kennen die Grundideen von Cloud Computing Services. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 2 Inhaltsverzeichnis ◼ Generischer Aufbau von BAS in einer Drei-Schichten-Architektur ◼ Architekturformen ◼ Betriebsmodelle (Fallstudie Felix Martin) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 3 Inhaltsverzeichnis ◼ Generischer Aufbau von BAS in einer Drei-Schichten-Architektur ◼ Architekturformen ◼ Betriebsmodelle (Fallstudie Felix Martin) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 4 Generischer Aufbau von BAS in einer Drei-Schichten-Architektur Präsentationsschicht Client (Benutzerschnittstelle) Applikationsschicht Applikation (Geschäftslogik) Datenhaltungsschicht (Datenzugriff) Datenbank Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 5 Die drei Schichten 1. Datenhaltungsschicht ◼ Zentraler Informationscontainer, in dem alles gespeichert und protokolliert wird, was für den Betrieb des ERP-Systems notwendig ist und was im Laufe seines Betriebs anfällt. ◼ Allgemeine Systemeinstellungen (sogenannte Konfigurationsdaten, z. B. Sprache, Ländereinstellungen), Stammdaten (z. B. Kunden, Produkte), Transaktionsdaten (z. B. Verkäufe) und Bestandsdaten (z. B. Lagerbestand) 2. Applikationsschicht ◼ Eigentliche „Applikation“ ◼ Programmlogik (Geschäftslogik), also die Funktionen, die das System für die Bearbeitung von Aufgaben zur Verfügung stellt 3. Präsentationsschicht ◼ (Grafische) Benutzerschnittstelle (engl. Graphical User Interface, GUI) ◼ Stellt dem Endbenutzer die Programmfunktionen zur Verfügung ◼ Auch als Client-Schicht (kurz: Client) bezeichnet Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 6 Begriffe ◼ Verteilte Systeme ◼ Physische Trennung von Komponenten (z.B. Datenbankserver, Applikationsserver, Webserver) ◼ Datenbanksysteme ◼ Oft eigenständige Server ◼ Eigenes Datenbankmanagementsystem und tw. auch eigene Middlewarekomponenten für eine optimierte Ansprache und Programmierung ◼ Middleware ◼ Programme, die zwischen Anwendungen vermitteln und auf diese Weise die Komplexität dieser Anwendungen verbergen (Diensteschicht oder Zwischenanwendung). Stellt Softwareschnittstellen oder Dienste bereit. Kommt zum Einsatz in verteilten Anwendungen. ◼ Kapselung ◼ Funktionen, die in Programmobjekten gebündelt sind (z.B. Preisberechnung für ein Produkt). ◼ Wiederverwendbare Einheiten (in einigen Systemen als „Business Objects“ bezeichnet) ◼ Paradigma der objektorientierten Programmierung (OOP) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 7 Inhaltsverzeichnis ◼ Generischer Aufbau von BAS in einer Drei-Schichten-Architektur ◼ Architekturformen ◼ Betriebsmodelle (Fallstudie Felix Martin) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 8 Architekturformen ◼ Monolithische Architektur ◼ Client-Server-Architektur (Multi-Tier-Architektur) ◼ Service-orientierte Architektur (SOA) Monolithische Architektur Multi-Tier-Architektur Service-orientierte Architektur GUI GUI GUI GUI Enterprise Service Bus Enterprise Service Bus APIs Services Web Services Microservices GL GUI GUI GL GL GL GL GL DB GL GL GL DB DB DB DB Monolithisch 2-Tier 3-Tier SOA Webbasierte SOA Microservices 1970er 1980er 1990er 2000er 2010er 2014+ Legende: Benutzeroberfläche (GUI) Geschäftslogik (GL) Datenbank (DB) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 9 Monolithische Architekturen ◼ Datenbank, Applikation und Benutzerschnittstelle untrennbar miteinander verbunden ◼ Auf einem zentralen Rechner, dem Server, installiert ◼ Ersetzen oder Einfügen von Programmteilen sehr schwierig ◼ Wiederverwendbarkeit, Portabilität oder Flexibilität sehr eingeschränkt Quelle: Rautenstrauch und Turowski 2001 Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 10 Begriffe ◼ Terminalemulation ◼ Spezielle Softwarekomponente für den Zugriff auf den zentral zur Verfügung gestellten Rechner (Host oder Server), wird auf dem dezentralen Endgerät (z.B. PC) installiert ◼ „Emuliert“ (simuliert) den Zugriff auf den Server ◼ Portierbarkeit (auch Portabilität) ◼ Möglichkeit, einen Programmcode auf verschiedenen Plattformen (Laufzeitumgebung) ausführen zu können ◼ Abhängig von den Komponenten, die für die Übersetzung und Ausführung des Programmcodes zuständig sind (z.B. Prozessor, Übersetzer (Interpreter), Betriebssystem oder Dienstprogramme) ◼ Performant ◼ Schnell im Antwortverhalten Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 11 Monolithische ERP-Systeme: Historie und Beispiele ◼ MRP / MRP II ◼ SAP (1972) ◼ Lawson (1975) ◼ J.D. Edwards (1977) ◼ SDL/ Oracle (1977) ◼ Baan (1978) ◼ PeopleSoft (1987) ◼ ERP → 1990s ◼ SAP R/3 (1992) Quelle: Jacobs und Weston 2007 Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 12 Client-Server-Architektur ◼ Örtliche/logische Trennung von ◼ Präsentation ◼ Verarbeitung ◼ und Datenhaltung ◼ Client-Arten: Fat, Rich, Thin Quelle: Rautenstrauch und Turowski 2001 Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 13 Client-Server-Architektur ◼ Entwickelte sich in den 1980er-Jahren mit dem Aufkommen von Personal Computern (PC) ◼ Softwarearchitektur mit dem Ziel, ERP-Systeme soweit wie möglich in Komponenten zu unterteilen, so dass dezentrale Clients und der zentrale Server losgelöst voneinander agieren können ◼ Bis zur Jahrtausendwende fand bei nahezu allen ERP-Herstellern eine zunehmende Trennung der unterschiedlichen Schichten in eine sogenannte Client-Server-Architektur statt („Umbau“). ◼ Begleitet durch eine Verbesserung im Bereich der Netzwerktechnologie und der dadurch erzielten performanteren Zugriffe auf dezentrale (örtlich verteilte) Computer. ◼ Datenbank- und Applikationsserver können (müssen aber nicht) auf physisch unabhängigen Geräten installiert werden. ◼ Die Benutzerschnittstelle läuft in dieser Architektur auf dem Client, d.h. dem Endgerät des Benutzers, meist einem Desktop-PC. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 14 Client-Server-Architektur: Thin, Rich und Fat Client Fat Client Rich Client Thin Client Client Client Client Endgerät Applikation Applikation Applikation Applikation Server Datenbank Datenbank Datenbank Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 15 Thin, Rich und Fat Client ◼ Fat Client ◼ Gesamte Programmlogik auf dem Computer des Endanwenders (z. B. seinem Desktop-Gerät) ◼ Benötigt notwendige Kapazität an Hauptspeicher (RAM) und Rechenwerk (CPU) ◼ Traditionelle, proprietäre ERP-Clients sind Fat Clients ◼ Rich Client ◼ Ausführung der Programmlogik zwischen Server und Endgerät verteilt ◼ Nur ein Teil der Programmausführung läuft im Client, so dass ein Teil der Anwendungslogik (z.B. bedienungsnahe Logik wie Druckersteuerung) die Programmnutzung beim Anwender vor Ort unterstützt ◼ Logikelemente, die ohnehin einen Zugriff auf die zentralen Ressourcen des ERP-Systems notwendig machen, zentral installiert und genutzt ◼ Zu installierende Client-Software deutlich kleiner als beim Fat-Client-Konzept ◼ Typisch: Java-Applets (fügen zusätzliche, im Browser eigentlich nicht vorgesehene, Funktionalität hinzu) ◼ Thin Clients ◼ Programmlogik auf dem Server verarbeitet ◼ Client übernimmt nur die Eingabe von Daten und die Präsentation der Ergebnisse ◼ Keine (zusätzliche) Installation von Software auf dem Client ◼ Beispiele sind Terminalemulationen oder Webbrowser ◼ Jedoch: Oft kleine Erweiterungskomponenten für den Browser notwendig, um dem Anwender eine komfortable Programmnutzung zu ermöglichen, (→ Thin-Client-Konzept ad absurdum geführt), Werbung: „Rich-Thin-Client“ oder „extended Thin Client“ o.ä. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 16 Client-Server-Systeme: Beispiele für Clients Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 17 Service-orientierte Architektur (SOA) ◼ Definition der OASIS: ”Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” ◼ SOA ist ein Paradigma ◼ Architekturform entwickelte sich seit den 1990er-Jahren in mehreren Schritten auf Grundlage der verteilten Client-Server- Architektur ◼ Definitionen der Hersteller ◼ Microsoft: Architektur einer Applikationsform ◼ SAP: ESA (ESOA) ◼ Oracle: Technologische Plattform ◼ IBM: Architektur und Programmiermodell ◼ Gemeinsamkeit: Der Begriff „Service” (i.d.R. ein Web Service) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 18 Service-orientierte Architektur (SOA) ◼ Ziel: Entwicklung und Kapselung fachlich geprägter Komponenten (Services) mit eigenständiger Geschäfts- und Datenlogik, die zur Unterstützung der Geschäftsprozesse genutzt werden können ◼ Beispiele für Services: Bonitätsprüfung, RechnungssummeBerechnen, VerfügbarkeitPrüfen ◼ Stärke: Wiederverwendbarkeit von Funktionen in Altsystemen (Legacy Systems) ◼ Vision: Flexible Prozessorchestrierung ◼ Zentrale, fachliche Services werden in der Reihenfolge ihrer Nutzung im Unternehmensablauf aufgerufen ◼ Theoretisch beliebige Funktionsreihenfolge innerhalb eines ERP-Systems für einen bestimmten Unternehmensbedarf ◼ Softwarehersteller sehen darin sogar die Möglichkeit, beliebige Services hinzuzufügen oder Services durch andere Services, etwa durch Drittanbieter, zu ersetzen. ◼ Vision scheint aus technischer Sicht aufgrund der Standardisierung möglich zu sein, allerdings muss die beliebige Austauschbarkeit zumindest bei Services, die Daten etwa durch Berechnungen verarbeiten, kritisch hinterfragt werden ◼ Es kann technisch nicht sichergestellt werden, dass Service 1 von Anbieter A im Austausch mit Service 2 von Anbieter B tatsächlich z. B. bei der Zinsberechnung bei allen Konstellationen tatsächlich zum gleichen Ergebnis gelangt Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 19 SOA-Ebenen Geschäfts- prozesse Präsentation Client Client Client Client (GUI) Service- Orchestrierung Interne Services Externe Services Services Enterprise Enterprise Content Enterprise Resource Collaboration Systems Management Systems Planning Systems Applikationen Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 20 Basiskomponenten einer Service-orientierten Architektur (SOA) ◼ Präsentation ◼ Anwender greift über einen Client auf die Software zu. ◼ Service-Orchestrierung (engl. Orchestration) ◼ Geschäftsprozesse und Geschäftsregeln ◼ Modellierung und Ausführung der Geschäftsprozesse durch BPM (Business Process Management) und BPEL (Business Process Execution Language) ◼ Geschäftsregeln zur Steuerung des Ablaufverhaltens einer Anwendung werden durch Rule Engines modelliert und ausgeführt. ◼ Services ◼ Mechanismen zur Diensteverwaltung, standardisierte Serviceschnittstellen sowie spezielle Dienste ◼ I.d.R. Web Services Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 21 Architektur eines ERP-Systems Präsentations- Proprietärer Client Webbrowser Mobiler Third Party schicht (Fat Client) (Rich/Thin Client) Client Web Services Produkt des ERP-Herstellers Serversoftware Weitere Komponenten Funktionale Mailserver, Webserver Applikations- Erweiterungsmodule EDI-Gateway schicht Applikations- Dokumenten- ERP-Basisframework server managementsystem Datenbank- ERP-Datenbank (DB) Dateiablage schicht Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 22 Schichten und Komponenten ◼ Präsentationsschicht ◼ Benutzeroberfläche ◼ Fat Clients und/oder Rich Clients ◼ Thin Clients (reine Webbrowser), z.B. für SaaS-Angebote ◼ Mobile Endbenutzerschnittstellen für Tablet-Computer ◼ Datenbankschicht ◼ Ein oder mehrere unterschiedliche Datenbanksysteme ◼ Vielzahl relationaler Tabellen ◼ Oft Wahl zwischen gängigen Datenbanksystemen (z. B. SQL-Server, DB2 oder Oracle) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 23 Schichten und Komponenten ◼ Applikationsschicht ◼ Logik der ERP-Anwendung (das eigentliche „Produkt“ des ERP-Anbieters) ◼ Standardkomponenten für Applikations- und Webserver ◼ Am Markt gibt es heute für Applikationsserver eine Dominanz zweiter vorherrschender Technologieplattformen ◼ J2EE (Java Enterprise Edition) und ◼.NET (Microsoft) ◼ Spezialisierte Integrations- und Applikationsplattformen ◼ SAP läuft z.B. auf NetWeaver ◼ Die Business Software von IBM basiert auf Websphere ◼ Weitere: WebLogic Enterprise (BEA), JBoss (Open Source) und WebObjects (Apple) ◼ Komplementär: Messagingserver, EDI-Gateway und Dokumentenmanagementsysteme ◼ Oft sind dies Produkte spezialisierter Drittanbieter, die integriert werden Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 24 Weitere Komponenten ◼ Betriebssysteme ◼ Windows, Linux, Unix, … ◼ Datenbanken ◼ SQL Server, MySQL, Oracle, DB2, … ◼ Programmiersprachen ◼ Java, C/C++, C#, Visual Basic, PL/SQL, … ◼ Entwicklungsumgebungen ◼ Eclipse, Visual Studio, IntelliJ, … Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 25 Beispiele - ABACUS vi Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 26 Beispiele - ABACUS vi ◼ Rich Internet Application (RIA) ◼ Programmiert in Java, Datenbankanbindung in C++ ◼ UltraLightClient-Technologie von Canoo → geringere Bandbreite als Programme, die mit Ajax/HTML entwickelt sind ◼ Enthält Java Open-Source-Komponenten ◼ Import- und Exportschnittstellen ◼ Unterstützt standardmäßig die Datenbank Pervasive.SQL, alternativ Microsoft SQL und IBM DB2 möglich ◼ Serverbetriebssysteme: aktuelle Windows-Versionen, Mac OS X Snow Leopard und Linux ◼ Clientanforderungen: Internetbrowser und Java Runtime Environment (JRE) ◼ Applikationslogik vollständig auf dem Server Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 27 Beispiele - Comarch ERP Enterprise Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 28  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Gibt es Technologietrends zur Verbesserung von ERP-Systemen (speziell Analytics)? SAP HANA – Neue Technologieentwicklung, die OLTP und OLAP in einer DB1 vereinigt DB1 = Datenbank ◼ SAP HANA ist eine In-Memory- DBMS2 = Datenbankmanagementsystem Technologie ◼ Die Datenbank befindet sich komplett im Arbeitsspeicher ◼ Kann sowohl on-premises als auch in der Cloud eingesetzt werden ◼ Speziell geeignet für Real-Time- Analysen von großen Datenmengen ◼ Transaktionale DBMS2 verteilen die Workload normalerweise auf getrennte Datenbanken (OLAP und OLTP). SAP HANA vereint diese. ◼ Erklärung: ◼ OLTP = Online Transaction Processing (verzögerungsfreie Transaktionsverarbeitung, läuft auf der ERP-Datenbank) ◼ OLAP = Online Analytical Processing (Datenanalyse, typischerweise benutzt in Kombination mit einem Data Warehouse) Quelle: http://www.saphana.com/docs/DOC-2272 Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 30 Inhaltsverzeichnis ◼ Generischer Aufbau von BAS in einer Drei-Schichten-Architektur ◼ Architekturformen ◼ Betriebsmodelle (Fallstudie Felix Martin) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 31  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Fallstudie Felix Martin Quelle: Schneider 2006 Prof. Dr. Petra Schubert Universität Koblenz-Landau Institut für Wirtschafts- und Verwaltungsinformatik Professur für Betriebliche Anwendungssysteme Campus Koblenz Universitätsstr. 1 D-56070 Koblenz http://bas.uni-koblenz.de Welche Problemstellung hat Felix Martin? Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 33 Problemstellung ◼ Der Geschäftsinhaber eines HiFi-Geschäfts, Felix Martin, muss entscheiden, welche ERP-Software er künftig für die Unterstützung seiner Buchhaltung und Auftragsabwicklung einsetzen möchte. ◼ In diesem Zusammenhang muss er die Faktoren seiner Geschäftstätigkeit identifizieren, die durch die neue Software beeinflusst werden und die sich ggf. verbessern sollen. ◼ In Abstimmung mit diesen Zielkriterien muss er sich entscheiden, wie teuer die Anschaffung und der Betrieb einer solchen Lösung sein dürfen und mit welchen Partnern er dabei zusammenarbeiten soll. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 34 Business Szenario felix martin radio / tv / hifi Lieferanten Lieferanten Aushandlung Konditionen Einkauf Verkauf Erfassung Konditionen und Artikelstammdaten Verkauf Anfrage / Beratung Kunden Kunde Angebotserstellung Kunde Anfrage Bestellerfassung Bestellung Auftragsabwicklung Lieferung Abnahme Installation Inbetriebnahme Kundendienst Betrieb Rechnung und Bezahlung Debitorenkontrolle Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 35 Fragen für die Diskussion Diskutieren Sie die folgenden Fragen vor dem Hintergrund der felix martin Hi-Fi und Videostudios. 1. Welche Partner braucht ein kleines Unternehmen für den Betrieb von Buchhaltung und Auftragsabwicklung? 2. Welches Kostenmodell wäre für ein solches Unternehmen wünschenswert? 3. Welches Betriebsmodell ist für ein Unternehmen dieser Branche und Größe passend? 4. Wie könnte die technische Sicht aussehen? Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 36  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Welche Partner braucht ein kleines Unternehmen für den Betrieb von Buchhaltung und Auftragsabwicklung? Benötigte Partner? Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 38 Benötigte Partner 1. ERP-Anbieter (Anbieter der „smart-HiFi“-Lösung, Implementierungspartner, Überwachung des Betriebs): atlantis it-solutions 2. Steuerberater (Buchhaltung, Bilanzerstellung, Prüfung): Fidewo AG 3. IT-Service-Provider (Betreiber des Servers, Wartung, Backup): Fidewo AG Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 39  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Welches Kostenmodell wäre für ein solches Unternehmen wünschenswert? Kosten, die bei der Anschaffung eines ERP- Systems anfallen Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 41 Kosten ◼ Umstellungskosten: ◼ Einmalig: 30.000,– Euro ◼ Enthalten: Kosten für die gesamte Einführung, Schulung und zwei Lizenzen ◼ Monatliche Pauschalen: ◼ 375, – Euro an atlantis it-solutions (Support, Wartung, Monitoring der SW, kleinere Anpassungen) ◼ 94,– Euro an Fidewo AG (Nutzungsgebühr Hardware, Unterhalt, Wartung Hardware, Backup) ◼ = jährlich: 5.628,– Euro Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 42 Einsparungen ◼ Pro Jahr Einsparung von ca. 6250,- Euro (Steuerberatungskosten) ◼ Umsatz im Servicebereich um ca. 30 % gestiegen (da alle erbrachten Leistungen nun konsequent auch auf Kundenaufträge erfasst werden) ◼ Rechnung konnten früher nicht mehr ergänzt oder geändert, daher oft nicht mehr verrechnet. ◼ Investition hat sich gelohnt: Schon im ersten Jahr konnten die Kosten amortisiert werden Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 43  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Welches Betriebsmodell ist für ein Unternehmen dieser Branche und Größe passend? Das Spezielle an der Lösung ◼ „smart-tools“-Konzept ermöglicht auch kleinen Betrieben den Einsatz von SAP-Produkten. ◼ Verschiedene Branchen erhalten ein angepasstes Paket, das individuell an die jeweilige Firma angepasst wird. ◼ SAP-System bei felix martin wird von nur zwei Anwendern genutzt und war damit zum damaligen Zeitpunkt wahrscheinlich eine der kleinsten SAP-Installationen, die es gab. ◼ System wird bei einem Partnerunternehmen gehostet und gepflegt. ◼ Auf den eigenen Computern wird nur der SAP-Client benötigt. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 45 Erfahrungen ◼ Frühe Schulung des Geschäftsinhabers (bereits während der Implementierungsphase), Schulung in seinem Team selbst übernommen ◼ Einbezug ins Customizing der Software auf seine Bedürfnisse, gezielte Änderungswünsche eingeflossen ◼ Akzeptanz der Nutzer frühzeitig gesichert Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 46  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Was ist das Betriebsmodell der Zukunft? Selbstbetrieb (on-premises)? ASP? Cloud Computing? Möglichkeiten für den Betrieb eines ERP- Systems 1. Selbstbetrieb eines eigenen ERP-Systems 2. Fremdbetrieb eines eigenen ERP-Systems 3. Nutzung von Cloud Services Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 48 Eigenbetrieb (on-premises) ◼ Unternehmen, die über eine eigene IT-Abteilung bzw. entsprechend qualifiziertes Personal verfügen, können ihre ERP- Systeme auf eigener Hardware in ihren eigenen Räumlichkeiten betreiben. ◼ Entweder übernimmt ◼ das eigene Personal in diesem Szenario die gesamte Wartung selbst (inkl. Backups, Server Management) ◼ oder ein Dienstleister (Service Provider) führt diese Funktionen über einen entfernten Zugriff (Remote Access) als Fremdwartung aus. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 49 Konsequenzen eines Eigenbetriebs ◼ Eigene Hardware und Software ◼ Nachteile ◼ Hard-/Software/Infrastruktur muss selbst betreut werden ◼ Eigene(r) Mitarbeiter oder ◼ Fremdpersonal ◼ Schulung des entsprechenden Personals notwendig ◼ Risiko von Hardwaredefekten, Verantwortung für Ausfallsicherheit, Backups, Zugangsschutz, Wartung des Systems inkl. Updates etc. liegen beim Anwenderunternehmen ◼ Technologiewechsel erfordert weitere Investitionen ◼ Vorteil ◼ Reaktionszeit bei Ausfall liegt „in der eigenen Hand“ (Unabhängigkeit) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 50 Fremdbetrieb (off-premises) ◼ Form des IT-Outsourcing ◼ Unternehmen kann seine Hard- und Software selbst anschaffen und dann in einem externen Rechenzentrum (engl. Data Center) zum Betrieb unterstellen (Server Hosting). ◼ Dienstleister sorgt für die Stromversorgung, den Netzwerkanschluss und führt lokale Wartungsarbeiten durch. ◼ Mitarbeitende des Anwenderunternehmens greifen über Breitbandverbindungen auf die Applikationen des Servers zu. ◼ Interne IT-Abteilung betreut den eigenen Server über Remote Access. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 51 Outsourcing des Betriebs: Application Service Providing (ASP) ◼ Ein Application Service Provider (ASP) ist ein IT-Dienstleister, der einem Kunden eine Anwendung über eine Netzwerkverbindung (i.d.R. eine geschützte Internetverbindung) zur Verfügung stellt. Diese Dienstleistung wird als Application Service Providing bezeichnet. ◼ Application Service Providing bezeichnet eine Dienstleistung, bei der ein Anwendungssystem (z.B. ein ERP-System) von einem spezialisierten Unternehmen (dem sogenannten Application Service Provider) betrieben wird und dem Kunden über eine Netzwerkverbindung (i.d.R. eine geschützte Internetverbindung) zur Verfügung gestellt wird. Beinhaltete Leistungen sind die Aufrechterhaltung der Betriebsbereitschaft des Systems inklusive der Datensicherung, dem Einspielen von Patches und Updates sowie einer Hotline (Benutzerbetreuung). ◼ Dabei ist es unerheblich, ob die Hardware vom Anwenderunternehmen selbst angeschafft wird (der ASP übernimmt dann das Hosting des Servers) oder ob der ASP die Hardware (gegen Entgelt) zur Verfügung stellt. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 52 Konsequenzen eines Fremdbetriebs ◼ Im Falle eines Fremdbetriebs ist es denkbar, dass die Hard- und Software des Anwendungssystems nicht von der Nutzerfirma gekauft, sondern lediglich für die Nutzung „angemietet“ wird. ◼ Reaktionszeiten im Fall eines Ausfalls (down time) werden in sogenannten Service Level Agreements (SLA) geregelt ◼ Vorteile ◼ Keine Einmalkosten (Investitionskosten) bei der Beschaffung von IT ◼ Regelmäßige, vertragsbasierte und damit fest kalkulierbare Aufwandskosten (Mietkosten) ◼ Dienstleister trägt das Risiko für Hardwaredefekte und unvorhergesehene Störungen ◼ Typische Nachteile ◼ Abhängigkeit vom Outsourcing-Anbieter ◼ Kein eigenes Know-how über den Betrieb des Systems im Unternehmen vorhanden ◼ Wechsel auf einen anderen Anbieter ist i. d. R. nicht ohne weiteres möglich Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 53 Cloud Computing ◼ Cloud Computing ist eine neuere Form des IT-Outsourcings, bei dem die Soft- und Hardwareinfrastruktur nicht explizit von einem Anwenderunternehmen angeschafft wird und auch nicht dediziert einem Kunden zugewiesen ist, sondern gemeinsam mit anderen Unternehmen genutzt wird. ◼ Cloud Computing steht für den Betrieb von Infrastruktur, Plattform und Software in einer virtualisierten Umgebung, deren Komponenten über das Internet genutzt werden können. ◼ Das Wort „Cloud“ signalisiert, dass die Leistung angeboten wird ohne das explizite Wissen des Kunden darüber, auf welcher Infrastruktur diese Leistungen physisch erbracht werden. ◼ Wichtige technische Voraussetzung: Virtualisierung = die Aufteilung eines oder mehrerer leistungsstarker Server in virtuelle Computer, um das Leistungspotenzial der physischen Hardware besser nutzen zu können. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 54 Drei Formen des Cloud Computing Enterprise Systems Software as a Service – SaaS Software development environment Platform as a Service – PaaS Personal Virtualization of physical hardware Infrastructure as a Service – IaaS Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 55 Die drei Formen des Cloud Computing ◼ Software-as-a-Service (SaaS) ist die Zurverfügungstellung einer Applikation, die von einem Provider (off-premises) gehostet wird und auf die der Kunde über das Internet zugreift. Im Gegensatz zum Application Service Providing basiert SaaS auf einem Mehrmandantensystem, bei dem viele Kunden dieselbe Installation einer Software benutzen und ihre privaten Datenbereiche haben. SaaS ist sinnvoll geeignet für Standardsoftware, die keine umfangreiche Individualanpassung oder Integration mit anderen Applikationen erfordert. ◼ Platform-as-a-Service (PaaS) ist die Zurverfügungstellung von Ressourcen für die Entwicklung von Applikationen und Services (Softwareentwicklungsumgebung). Das Angebot für den Softwareentwickler (Kunden) wird von einem Provider erbracht. Typische Anwendungsszenarien sind Applikationsdesign, Softwareentwicklung, Testen und Implementation (Deployment) ◼ Infrastructure-as-a-Service (IaaS) (auch synonym Hardware-as-a-Service genannt) bezeichnet die Zurverfügungstellung von Hardware (CPU- und Hauptspeichernutzung, Festplattenspeicher, Netzwerkkomponenten) für einen Kunden von einem Provider. In diesem Model ist es möglich, dass viele Kunden dieselbe (virtualisierte) Hardware gemeinsam nutzen. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 56 Konsequenzen von Cloud Services ◼ Vorteile IaaS ◼ Anwenderunternehmen nutzt lediglich die Hardware eines Cloud-Providers für den Betrieb des ERP-Systems ◼ Kosten für die Cloud-Leistung fallen für die Nutzung von (flexibel skalierbaren) virtuellen Maschinen (VMs) an ◼ Vorteile SaaS ◼ ERP-System wird spezifisch für den Cloud Service entwickelt ◼ Erlaubt die Einrichtung von unabhängigen Mandanten auf derselben Softwareinstanz ◼ Viele Anwender(unternehmen) teilen sich dieselbe physische Installation einer Software ◼ Zugriff über Webbrowser (Thin Client) ◼ Problem: Ansteuerung lokaler Komponenten (z. B. lokaler Drucker) und Integration von Drittapplikationen (z. B. einem POS-Terminal) ◼ Nachteile ◼ Voraussetzung: Ständig verfügbare, performante Internetverbindung ◼ Keine Möglichkeit, die Applikation offline zu betreiben (auch kein Zugriff auf Daten bei fehlender Verbindung) ◼ Bei SaaS zusätzlich: ERP-System ist nicht zu einem neuen Provider portierbar (Lock-in- Effekt) Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 57 Weitere Fallstudien zu ASP-Lösungen ◼ Handel mit Gourmet-Produkten: ◼ Myrach, Thomas (2006): MGM Group Corporation: ERP aus der Steckdose, in: Wölfle, Ralf; Schubert, Petra (Hrsg.), Prozessexzellenz mit Business Software, S. 247-260, München, Wien: Hanser Verlag, 2006. ◼ ASP-Lösung für das Gesundheitswesen, spezielle POS-Lösung für Apotheken: ◼ Schubert, Petra (2003): Fallstudie Triamun, in: Schubert, Petra; Wölfle, Ralf; Dettling, Walter (Hrsg.), E-Business-Integration: Fallstudien zur Optimierung elektronischer Geschäftsprozesse, S. 137-152, München, Wien: Hanser Verlag, 2003. Verfügbar unter: www.experience-cases.de Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 58  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Beispiele für ERP-Systeme „aus der Cloud“ Abacus Scopevisio ABACUS vi - Design the future Source: www.abacus.ch Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 60 Scopevisio Homepage 2013 Professioneller Buchhaltungsservice für KMU → vgl. Anforderungen in der Fallstudie Felix Martin Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 61  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Wie könnte die technische Sicht aussehen?  Technische Sicht felix martin radio / tv / hifi Fidewo AG SAP-Clients Clients Internet Standleitung 3 Mbit Standleitung 4 Mbit Firewall Firewall ERP-System Drucker Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 63 Zusammenfassung: Faktoren für den Entscheid für eine bestimmte Betriebsform ◼ Große Unternehmen ◼ Eigene IT-Abteilungen sind in der Lage, das ERP-System selbst (on-premises) zu betreiben ◼ Ggf. Frage, ob die darunter liegende Hardware als Cloud Service „angemietet“ werden soll, um den ständigen Technologieentwicklungen nicht durch permanente Investitionen begegnen zu müssen. ◼ In der Regel Wahrung der Unabhängigkeit von einem Provider bei einer solch zentralen Applikation wie dem ERP-System ◼ Kleinere Unternehmen ◼ Häufig keine andere Wahl als den Betrieb in die Hände eines Providers zu geben ◼ Wahlmöglichkeit: SaaS-Anbieter oder ASP-Angebot → bei letzterem zumindest noch Möglichkeit für einen Providerwechsel ◼ Man kauft Provider und System in der Regel als untrennbares „Paket“ ◼ Aufgrund der Wichtigkeit und der Komplexität eines ERP-Systems sind die Betriebsmodelle „on-premises“ (Eigenbetrieb) und „gehostet“ (ASP) zum heutigen Zeitpunkt (noch) die verbreitetesten. ◼ Akzeptanz von IT-Outsourcing steigt zwar, allerdings wird sich das Outsourcing von ERP-Systemen wahrscheinlich noch lange Zeit auf ASP bzw. reines Hardwareoutsourcing (IaaS) beschränken Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 64  BAS-Vorlesung Betriebswirtschaftliche Anwendungssysteme Vielen Dank für Ihre Aufmerksamkeit Bitte bereiten Sie die Fallstudie „Blizzard“ für die nächste Veranstaltung vor. Literatur ◼ Schubert, Petra; Winkelmann, Axel (2023): Betriebswirtschaftliche Anwendungssoftware – Enterprise Resource Planning, Berlin: Springer, 2023 (Kapitel 2). ◼ Schneider, Raoul (2006): felix martin Hi-Fi und Videostudios: SAP im Kleinunternehmen, in: Wölfle, Ralf; Schubert, Petra (Hrsg.), Prozessexzellenz mit Business Software, S. 169-182, München, Wien: Hanser Verlag, 2006. ◼ Jacobs, F. Robert und Weston Jr., F.C. ‘Ted’ (2007): Enterprise Resource Planning - A Brief History. Journal of Operations Management, 25, pp. 357-363. ◼ Rautenstrauch, Claus; Turowski, Klaus (2001): "Common Business Component Model (COBCOM): Generelles Modell komponentenbasierter Anwendungssysteme“, Konferenz Wirtschaftinformatik, Paper 49, 2001. Prof. Dr. Petra Schubert © Professur für Betriebliche Anwendungssysteme (BAS) | 66