Upload
berhtram-legler
View
109
Download
1
Embed Size (px)
Citation preview
Management der InformationssystemeModellierung von
Unternehmensarchitekturen
© Prof. T. Kudraß, HTWK Leipzig
Fragen an das IS-Management Wie soll das Management der grundlegenden
Bausteine von Informationssystemen gestaltet werden: Daten und Prozesse ?
Wie wird der Lebenszyklus einer einzelnen Anwendung von der ursprünglichen Idee über Entwicklung und Betrieb?
Wie kann die gesamte Systemlandschaft im Unternehmen harmonisch gestaltet werden, d.h. wie werden neue Informationssysteme aufeinander abgestimmt und ins bestehende Portfolio eingefügt?
© Prof. T. Kudraß, HTWK LeipzigBegriff Unternehmensarchitektur (Enterprise Architecture)
Zusammenspiel von Elementen der Informationstechnologieund der geschäftlichen Tätigkeit im Unternehmen. Sie ist ge-kennzeichnet durch einen ganzheitlichen Blick auf die Rolle der IT im Unternehmen
Architektur = Beschreibung (Modell) der grundsätzlichenStruktur der Teile eines Systems sowie der Zusammenhängezwischen den einzelnen Elementen
ISO-Standard 15704 „Allgemeine Anforderungen an Unternehmensarchitektur“
ANSI/IEEE Std. 1471-2000
The fundamental organization of a system, embodied in itscomponents, their relationships to each other and the environ-ment, and the principles governing ist design and evolution.
© Prof. T. Kudraß, HTWK LeipzigEbenen und Gestaltungsobjekte der Unternehmensarchitektur
Strategieebene: Produkte / DienstleistungenMarktsegmenteStrategische Unternehmensziele / Vorhaben / ProjekteInteraktion mit Kunde oder Zulieferern
Organisationsebene: VertriebskanäleGeschäftsprozesseOrganisationseinheitenRollen / VerantwortlichkeitenInformationsflüsse / Standorte
Integrationsebene: Applikationen und ApplikationsdomainenFachliche Services IS-FunktionalitätenInformationsobjekteSchnittstellen
Softwareebene: SoftwarekomponentenDatenstrukturen
IT-Infrastrukturebene: HardwarekomponentenNetzwerkkomponentenSoftware-Plattformen
© Prof. T. Kudraß, HTWK Leipzig
Weiterentwicklung von Architekturen
Typ1-Architektur vs. Typ2-Architektur– Typ1: Beschreibung der Unternehmensarchitektur zu
einem bestimmten Zeitpunkt (Momentaufnahme)– Typ2: Schwerpunkt ist Prozess zur
Weiterentwicklung der Unternehmensarchitektur
Prozess zur Weiterentwicklung– Weiterentwicklung vom IST zum SOLL als Kreislauf
betrachten– Geschäfts-/IT-Strategie bestimmt Transformation der
Ist-Architektur– Regelmäßige Anpassung bei Änderungen – Ansätze in Enterprise Architektur Frameworks
© Prof. T. Kudraß, HTWK Leipzig
Anwendungsszenarien für Unternehmensarchitektur
Planung IT-Strategie IT/Business-Alignment Prozessoptimierung Architekturkonformität von Projekten Management des Anwendungsportfolios Qualitätsmanagement Security-Management Business-Continuity-Planung (IT-Notfallplanung) IT-Konsolidierung Standardsoftware-Einführung Compliance-Management Sourcing-Entscheidungen Unterstützung von Fusionen / Übernahmen / Teilungen
© Prof. T. Kudraß, HTWK LeipzigPraxisbeispiel: Unternehmensarchitektur bei der UBS AG Zürich Business Architecture
– Tasks and targets at a strategic level– Business principles
Application Architecture– Partitioning of business-oriented functionality into (reference)
models according to different viewpoints Software Architecture
– Set of rules (guidelines, patterns) for software development; may result in application infrastructure components
Technical Architecture– Set of products (basic platforms) and a set of rules and patterns
how to apply these products Operations Architecture
– Elements and Processes needed to run the software system of the bank
© Prof. T. Kudraß, HTWK Leipzig
Enterprise Architecture Frameworks Frameworks unterstützen Unternehmensarchitektur Beispiele:
– Zachman Framework (1987): Einflussreicher Vorläufer heutiger Frameworks
– The Open Group Architecture Framework (TOGAF)– Enterprise Architecture Frameworks amerikan. Behörden:
FEAF, E2AF, DoDAF Werkzeuge
– IBM Rational System Architect– IDS Scheer: ARIS– alfabet: planningIT– Casewise: Corporate Modeler
© Prof. T. Kudraß, HTWK Leipzig
TOGAF Umfassender Ansatz für Entwurf, Planung,
Implementierung und Wartung von Unternehmensarchitekturen
Entwickelt durch die Open Group Aktuell (2009): Version 9 Kostenfrei verfügbar 4 Architekturbereiche: Geschäftsarchitektur,
Informations- und Datenarchitektur, Anwendungsarchitektur, Technologiearchitektur
definiert Prozess zur Architekturentwicklung (Architecture Development Method, ADF)
© Prof. T. Kudraß, HTWK Leipzig
Architekturbereiche
Geschäftsarchitektur: Strategie, Organisation, Geschäftsprozesse des Unter-nehmens, Ergebnis der Geschäftsprozessmodellierung
Informations- und Daten- Daten mit ihren Beziehungen, die für die Durchführung architektur der Geschäftsprozesse benötigt werden
Datenmodell (stabil, vollständig, konsistent)Informationsgruppen (Rollen) mit gleichem Info-Bedarf
Anwendungsarchitektur: Anwendungen für die Ausführung der Geschäftsprozessestabiles AnwendungsportfolioFunktionalität / Informationen
Technologiearchitektur: Elemente für Aufbau und Betrieb der IT-Infrastruktur stabiles AnwendungsportfolioBasis für Beschaffung, Integration und Betrieb von Anwendungen
Basisarchitekturen
Weitere Architekturen möglich:• Sicherheitsarchitektur• Betriebsarchiektur
© Prof. T. Kudraß, HTWK Leipzig
Architecture Development Method (ADF)
© Prof. T. Kudraß, HTWK Leipzig
TOGAF - Bestandteile
1. TOGAF Architecture Develoment Method (ADM) Methodik für Architekturentwicklung Guidelines für Tools Verweise auf Case Studies
2. Enterprise Continuum = „virtuelles Repository“ Zwei Referenzmodelle:
Foundation Architecture: Technical Reference Model (TRM), Standards Information Base (SIB)
Integrated Information Infrastructure Reference Model (III-RM)
3. TOGAF Resource BaseGuidelines, Templates u.ä. für Enterprise Architects
© Prof. T. Kudraß, HTWK Leipzig
Referenzmodelle
Vgl. Begriff Modell: „wovon-wozu-für wen?“ Referenzmodell: nicht nur im Kontext eines IS,
sondern auch in weiteren Anwendungskontexten Referenzmodell
– Ebenen- und Architekturmodelle– Metamodelle, Referenzmodelle, Tools zur Anwendung
von Referenzmodellen
Ein Referenzmodell ist ein für eine Branche oder einen ganzen Wirtschaftszweig erstelltes Modell, das allgemeingültigen Charakter haben soll. Es dient als Ausgangslösung zur Entwicklung unternehmens-spezifischer Modelle (Becker/Schütte, 1996).
© Prof. T. Kudraß, HTWK Leipzig
Referenzmodelle (Forts.) Beispiele
– SAP R/3 Referenzmodell– ISO/OSI Referenzmodell– WFMC-Referenzmodell (Workflow Management)
Bereitstellung von Referenzmodellen durch Softwarehersteller– Dokumentationsfunktion– Zur Entscheidungsunterstützung beim Softwarekauf– Schulung der Mitarbeiter– Dokumentation der betrieblichen Abläufe, die durch
die Software unterstützt wird
© Prof. T. Kudraß, HTWK LeipzigReferenzmodelle: Metamodelle & Architekturmodelle UML
– Funktionsmodell: Funktionen des Systems aus der Sicht des Anwenders (Use Cases)
– Objektmodell: Klassendiagramm mit Attributen, Assoziationen, Operationen
– Dynamisches Modell: Aktivitäts-, Sequenz- und Zustandsbedingungen
ARIS (Scheer)– Datensicht: Entity-Relationship-Modell– Organisationssicht: Organigramm– Vorgangssicht: Funktionsbaum– Steuerungssicht: Ereignisgesteuerte Prozessketten (EPK)
MDA– Beschreibung eines Informationssystems unabhängig von der
technologischen Ebene
© Prof. T. Kudraß, HTWK Leipzig
Metamodelle (Wirtschaftsinformatik)
Organisations-Sicht
Funktionssicht
Datensicht
Steuerungssicht
Leistungssicht
Scheer
Organisation
Funktionen
Daten
Personal
Österle
Leistungssicht
Lenkungssicht
Ablaufsicht
Ferstl/Sinz
Organisations-Sicht
Funktions-Sicht
Datensicht
Gehring
Prozess-Sicht
Organisations-struktursicht
Aktivitäts-struktursicht
Informations-struktursicht
Gadatsch
© Prof. T. Kudraß, HTWK Leipzig
SAP R/3 Referenzmodell
Anwendungskomponentenmodell
Business -Objekt
Ereignis
Funktion
SAP R/3 - Referenzmodell
Interaktionsmodell
Business-Objekt
Datenmodell
Prozessmodell
OrganisationsmodellEreignis
Funktion
© Prof. T. Kudraß, HTWK LeipzigSAP Solution Map – Automotive OEM – Edition 2004
Quality ManagementInventory ManagementSupply to LineManufacturing ExecutionSupply PlanningManufacturing (Make to Order, Make to Stock)
Event ManagementVendor PerformanceBillingInbound LogisticsOperational Procurement
Supplier Relationship Management
Supplier Collaboration (Procurement)
Lifecycle SupportProduct Data Management
Preproduction Phase
Prototyping PhaseVerification of
ConceptDefine Strategy &
ConceptProduct Lifecycle Management
Business AnalyticsFinancial Supply
Chain ManagementCorporate
GovernanceFinancial
AccountingManagement Accounting
Strategic Enterprise Management
Enterprise Management
Event ManagementAssemblyInventory Management (Kit Management)Inbound LogisticsPlanningCKD Assembly Operations
Event Management
Financing, Leasing & Insurance Services
Vehicle Delivery
New & Used Vehicle Sales
Vehicle Planning & Forecast
MarketingCustomer & Vehicle
Relationship Management
Marketing, Sales & Distribution
Dealer Channel ManagementFleet & Rental ManagementCustomer Interaction &
CareWarranty
Service & Workshop Management
Customer Service
Lifecycle LogisticsProcurementManufacturingSales & DeliverySupply Network
PlanningDemand, Planning &
ForecastingService Parts
Fixed Asset ManagementIncentive & Commission
ManagementTravel ManagementProcurement
Employee Life-cycle & Transaction
ManagementBusiness Support
© Prof. T. Kudraß, HTWK LeipzigVerwendung von Referenzmodellen bei Einführung von Software Alternative 1:
– Spezifikation künftiger Systeme nur auf Basis des Referenzmodells
– setzt voraus, dass alle (auch spezialisierte Funktionalitäten) beschrieben sind
– anderenfalls Verlust an Individualität Alternative 2:
– Vergleich eigener Modelle mit dem Referenzmodell der Software → Anpassungsbedarf (Customizing)
– Anpassung der Software vs. Anpassung des Unternehmens– Regel: Relevanz des Geschäftsprozesses (wie wettbewerbs-
kritisch?) bestimmt Entscheidung
IF Prozess wichtig THEN Änderung der Standardsoftware veranlassen
ELSE Veränderung des Prozesses durch Softwareeinführung akzeptieren
(z.B. Bildschirm-Masken oder Reports)
© Prof. T. Kudraß, HTWK Leipzig
ARIS ARIS = Architektur integrierter Informationssysteme Eine methodenorientierte Architektur Ein Programm zur Unterstützung bei der Modellierung Unterscheidung
– ARIS Haus (die „Idee“)– ARIS Toolset (das „Programm“)
Beschreibung von Unternehmen und Anwendungssystemen
Verwendung betriebswirtschaftlicher Beschreibungstechniken
Geschäftsprozess steht im Mittelpunkt der Betrachtung Komplexitätsreduzierung durch Sichtenbildung
© Prof. T. Kudraß, HTWK Leipzig
Die vier Sichten des ARIS-Hauses
© Prof. T. Kudraß, HTWK Leipzig
Die drei Beschreibungsebenen – Von Problem zur IT (Daten- und Prozessbeispiele)
fachliche Sprachwelthalbformale Beschreibungsmethoden(„Lieferant produziert Artikel“)
Modellhafte Abbildung der betrieblichen Realität unter Berücksichtigung einer formalisierten Beschreibungsmethode („ERM“ bzw. „EPK“)
Einbezug von DV-Spezifika („Relationen“ bzw. „Kontrollflüsse“)
Übertragung auf die konkreten DV-Komponenten („SQL-Code“ bzw. „Java-Code“)
© Prof. T. Kudraß, HTWK Leipzig
Sichten und Ebenen ARIS-Architektur
© Prof. T. Kudraß, HTWK Leipzig
Modellierungstechniken auf Fachkonzeptebene
© Prof. T. Kudraß, HTWK Leipzig
Organisationssicht Bildet die Funktionen ausführenden Mitarbeiter, die
Organisationseinheiten sowie deren Struktur untereinander ab
© Prof. T. Kudraß, HTWK Leipzig
Datensicht Beschreibt Informationsobjekte, deren Attribute und Beziehungen Informationsobjekte werden von Funktionen erzeugt, verwendet oder manipuliert
und erhalten in Ereignissen definierte Zustände Datenmodelle dienen zur Klärung und Strukturierung der betrieblichen
Begriffswelten, werden aber vor allem für Anforderungsdefinitionen von DV-Anwendungssystemen genutzt
Darstellung als Fachbegriffsmodell (FBM)
Bestellung
Auftrag FB Lagerauftrag FB Beschaffungs-auftrag FB
bildet ab
Darstellung als Entity-Relationship-Modell (ERM)
OrtKunden-Nr Name
Datum
Kunde
Artikel
Bestellung
Gewicht
BenennungArtikel-Nr.
(0,n)
(0,n)
© Prof. T. Kudraß, HTWK Leipzig
Funktionssicht Beschreibt und ordnet die durch Ereignisse ausgelösten Funktionen
© Prof. T. Kudraß, HTWK Leipzig
Funktionssicht – Gliederungskriterien
Auftrag bearbeiten
Auftrag prüfen
Grunddaten erfassen
Positionsdaten erfassen
Kundenauftrag erfassen
Kundendaten erfassen
Finanzdaten erfassen
Bestelldaten erfassen
Kundenauftrag bearbeiten
Kundenauftrag anlegen
Kundenauftrag ändern
Kundenauftrag löschen
1. Prozess-Schritt
2. Prozess-Schritt
3. Prozess-Schritt
Prozessorientierte Funktionsgliederung
1. Verrichtung
2. Verrichtung
3. Verrichtung
1. Teilfunktion
2. Teilfunktion
3. Teilfunktion
Verrichtungsorientierte Funktionsgliederung
Objektorientierte Funktionsgliederung
© Prof. T. Kudraß, HTWK Leipzig
Steuerungssicht
Bildet die durch die Sichtenbildung verlorenen Zusammenhänge in einer eigenen Darstellung redundanzfrei ab
Das Zusammenwirken der unterschiedlichen Komponenten wird durch die Prozessmodellierung beschrieben
Ereignisse zeigen Übergänge auf
© Prof. T. Kudraß, HTWK Leipzig
EPK Sichtenintegration
© Prof. T. Kudraß, HTWK Leipzig
Hintergrundinformationen zu ARIS Entwicklungsgeschichte
– Idee: Prof. Dr. August-Wilhelm Scheer, Institut für
Wirtschaftsinformatik der Universität Saarbrücken– Hersteller: 1984/85 IDS – Prof. Scheer Gesellschaft
für integrierte Datenverarbeitungssysteme mbH– Seit Anfang 1999: IDS Scheer AG am Neuen Markt– Produkt: ARIS Toolset seit Version 3.x im größeren
Einsatz, seit Version 6.0 auch mit relationaler Datenbank (Oracle)
– Name: Bis Version 4.12 als ARIS-Toolsetseit Version 5.0 als ARIS e-Business Suiteaktuell als ARIS Design Platform
© Prof. T. Kudraß, HTWK Leipzig
Nutzen der Modellierung mit ARIS
Objekte werden genau einmal, einheitlich definiert Modelle erhalten ein einheitliches Layout (Vorlagen) Änderungen an einem Objekt (z.B. Umbenennung einer
Stelle) werden auf alle Modelle in der Datenbank übertragen
Redundant angelegte Objekte lassen sich konsolidieren Es existieren Zusatzfunktionen
– Web Publisher, Business Publisher– Auswertungsreports (z.B. für Prozesshandbuch)– Analysereports– Simulationskomponente– Prozesskostenrechnung (Activity Based Costing, ABC)– Balanced Scorecard (BSC)