ARIS: Use Case, ERP

Stammdatenverwaltung

Oft existieren in einem Unternehmen zahlreiche Anwendungen, die mitunter auf verschiedenen Datenbanken aufsetzen. In jeder Datenbank werden Adressen gespeichert.

Dokumentenmanagement

ERP-Systeme werden gerne zur automatisierten Verarbeitung von Buchungen und Zahlläufen verwendet. In diesem Fall werden alle Ein- und Ausgangsrechnungen eingescannt und mit einer Software automatisiert erfasst.

ERP-Systeme in der Automobilindustrie

In der Automobilindustrie bestimmen immer häufiger die Kunden durch einen Online-Konfigurator, welche Funktionalitäten und Designs sie in ihrem Neuwagen verbaut haben möchten. Ein solcher Konfigurator kann nach Abschluss des Kauf- und Gestaltungsvorgangs die Material- und Produktdaten an ein ERP-System weitergeben. Dieses prüft das Lager auf die Verfügbarkeit der Teile und Rohstoffe. Sind diese vorhanden, werden sie direkt für die Produktion reserviert. Sind sie nicht vorhanden, beginnt der Bestellprozess. Das zu erstellende Fahrzeug besteht systemseitig aus zahlreichen Einzelprodukten, diese wiederum aus zahlreichen Einzelmaterialien. Das ERP-System kann alle verbauten Materialien und Produkte auflisten und deren Herkunft und Kaufbeleg nachweisen.

• Erweiterbarkeit und die Portabilität
• Reibungsloser Betrieb
• Benutzerfreundliches Design der Anwendung
• Internationalisierung
• Skalierbarkeit von ERP-Systemen
• Client-Server-Architektur

Es existieren fünf bedeutende Ziele, die von ERP-Systemen anvisiert und auch erreicht werden. Diese Ziele werden im Folgenden näher erläutert:

• Kostensenkung
• Effizientere Prozesse in der Fertigungsstrasse
• Umsatzerhöhung
• Bessere Auswertung von Kennzahlen
• Planungsqualität erhöhen

Komponenten von ERP-Systemen

• Materialwirtschaft, Produktion, automatisierte Prozessplanung
• Finanzbuchhaltung, Controlling, Personalwirtschaft
• Forschung und Entwicklung
• Verkauf und Marketing
• Stammdatenverwaltung, Produktdatenmanagement, Dokumentenmanagement
• ERP Berichtswesen
• ERP Mobile

• Entscheidung richtet sich nach dem Einsatzgebiet
• Datenschutz gewährleistet
• Vertretbarer Preis für Anschaffung und Implementierung
• Anforderungen an Schulungen und Support
• Evtl. Standard mit spezifischen Anpassungen bevorzugen

• Ca. 50% von Kleinen- und Nischenanbietern
• 4% Anteil bei Eigenentwicklungen
• Marktaufteilung und Marktbeherrschung durch 4 grosse Anbieter : SAP (16%), sage (7%), Microsoft (7%)
• Hoher Anteil an Cloud-Services
• Hoher Benutzergrad bei KMU

Trend: Rand- und Kernprozesse werden gerne in der Cloud abgebildet

• ERP: -> Enterprise Ressource Planing
• Daten erzeugen, verändern und verarbeiten (Stammdaten, Bewegungsdaten)
• Zeit und Kosten sparen
• Reporting ermöglichen
• Wertschöpfungsprozesse abbilden und unterstützen
• Potenziale heben
• Erweiterbarkeit
• Anpassbarkeit I Customizing

• Effizienz steigern
• Prozessübergreifend einsetzbar sein
• Gemeinsames Datenrepository zur Verfügung stellen
• Hohe Integrationsfähigkeit (bipolar)
• Offene Architektur
• Business Intelligence ermöglichen (Auswertungen zur Unternehmenssteuerung)
• Erweiterbarkeit
• Skalierbar ein Anforderungen sein

• Anpassbare [Customizing fähige Benutzeroberfläche
• Zentrale Datenbank und Datenhaltung
• Modulare Aufbau (Skalierung) nach betriebswirtschaftlichen Anforderungen (FI/CO, SD, PP,...
• Erweiterbarkeit durch Fremdanwendungen, vor allem cloudbasierte Services
• Moderne Schnittstellentechnologie (EAI, SOA, API,..)

• Tragfähige, Strategie-taugliche Kosten/Nutzen Relation des Einsatz gegeben
• Grosse Datenmenge zu bewältigen
• Geschäftsprozesse/Use Cases definiert und optimiert
• Strategie zum Einsatz und Implementierung definiert

Bei einem Black-Box Use Case wird dokumentiert, was ein System leisten soll und nicht, wie es dies leisten soll. Die Black-Box-Ansicht zeigt, wie ein System von außen aussieht, einschliesslich der erforderlichen und bereitgestellten Schnittstellen, sowie der Beziehung zu anderen Systemen. Eine Black-Box-Ansicht beschreibt aber nicht die interne Implementierung eines Systems.

Ein White-Box Use Case dokumentiert hingegen, welche Klassen, Schnittstellen und anderen Komponenten einer Komponente helfen, die gewünschte Funktionalität bereitzustellen.

=> In der Praxis werden Use Cases meist als Black-Box beschrieben.

=> Use Cases werden auch in Geschäftsanwendungsfälle und Systemanwendungsfälle aufgeteilt.

Die Anwendung von Use Cases bietet eine Reihe von Vorteilen:

• Sie sind leicht zu verstehen und relativ einfach zu erstellen, denn sowohl die Interaktion zwischen Akteur und System als auch die Beziehung zwischen verschiedenen Use Cases lassen sich gut abstrahieren.
• Sie eignen sich als gute Quelle für die Ermittlung von Anforderungen, die sich aus diesen Interaktionen ergeben.
• Umfangreiche Anforderungen lassen sich mittels Zerlegung der Interaktionen zwischen Akteur und System verfeinern. Damit steigt das Verständnis der Beteiligten.
• Durch die Kombination von textuellen Beschreibungen in Spezifikationsdokumenten und der Visualisierung per Use Case Diagramm gewinnen Organisationen gleichzeitig nützliche Detailinformationen und einen guten Überblick über das gesamte System. 5

Use Case Konzept 1 (Spezifikation)

Use Case Spezifikationen enthalten natürlich-sprachliche Informationen zur Systematik der Interaktionen eines Anwendungsfalls (sogenannte „Narratives"). Idealerweise werden diese Informationen mit einer Vorlage textuell erfasst. Diese Vorlage sollte mindestens folgende Elemente umfassen: Name des Use Cases und Use Case Nummer zwecks eindeutiger Identifizierung .

• Akteure
• Auslöser
• Kurzbeschreibung
• Beschreibung der essenziellen Schritte als Standardablauf
• Beschreibung von alternativen Abfolgen
• Vorbedingungen und Nachbedingungen
• Beschreibung der Systemgrenzen

Use Case Konzept 2 (Diagramme)

Use Case Diagramme gelten damit als grafische Repräsentation von Use Cases und die Unified Modeling Language (UML) definiert sie als Verhaltensdiagramm. Die wichtigsten Modellelemente sind hierbei:

• Akteure
• Anwendungsfälle
• Beziehungen
• Systemgrenzen

Spezifikationen und Diagramme lassen sich gemeinsam verwenden und bieten so eine sich ergänzende Sicht auf das Verhalten eines Systems.

Der Nutzen von Use Cases Unternehmen entwickeln Produkte, Software oder Systeme, die einen Nutzen stiften sollen. Häufig sollen Aufgaben schneller, besser, sicherer oder einfacher erfüllt werden. Der Kunde soll das Produkt nutzen, um damit sein Ziel zu erreichen. Was passiert aber, wenn das Ziel unklar und nicht eindeutig definiert ist? Im schlimmsten Fall wird der Kunde das Produkt nicht verwenden, da es ihm keinen oder nur einen geringen Nutzen bietet. Anwendungsfälle zeigen das Big Picture eines zu entwickelnden Systems. Ohne dieses Big Picture fehlt es oftmals an Orientierung und in der Folge lassen sich Entscheidungen über den Scope — was ist zu entwickeln, was lässt sich später entwickeln oder was kann sogar weggelassen werden — nur schwer treffen. Unvollständige oder unklare Anforderungen behindern die Entwicklung und den Markterfolg. Änderungen müssen nachträglich implementiert werden. Je später dies geschieht, desto schwieriger und teurer wird die Entwicklung.

Fragen zum Akteur

• Wer nutzt das System?
• Was ist das Ziel des Akteurs?
• Welche anderen Systeme interagieren mit dem System?
• Wer liefert dem System Informationen oder erhält Information?

Fragen zu den Abläufen

• Welcher Akteur und welches Event initiiert die Ablauffolge?
• Wie interagiert der Akteur mit dem System und wie reagiert das System?
• Welche alternativen Aktionen kann der Akteur bei jedem Schritt initiieren?
• Welche Unterbrechungen oder Fehler können bei jedem Schritt des Use Cases auftreten?
• Was passiert, wenn der Akteur den Vorgang abbricht?

Sonstige Fragen

• Mit welcher Frequenz wird der Anwendungsfall ausgeführt?
• Welche Beziehungen gibt es zu anderen Anwendungsfällen? 10

Fragen zu den Vor- und Nachbedingungen

• Welche Bedingung muss erfüllt sein, damit der Use Case eintritt?
• In welchem Zustand befindet sich das System, wenn der Use Case eintritt?
• Wie und unter welcher Bedingung wird der Anwendungsfall abgeschlossen?
• In welchem Zustand muss sich das System befinden, so dass der Anwendungsfall abgeschlossen wird?

Die Verwendung von Black-Box Use Cases stellt Unternehmen vor Herausforderungen bei der Ableitung von Testfällen.

Hier können bspw. formale Notationen wie Aktivitäts- oder Zustandsdiagramme als Ergänzung helfen, denn aus ihnen lassen sich Test Cases relativ leicht ableiten.

Zusätzlich sind die Vor- und Nachbedingungen eines Use Cases eine gute Quelle für Testfälle.

Da Anwendungsfälle aber untereinander Beziehungen oder parallele Abläufe haben, reicht es nicht aus, jeden Use Case getrennt zu betrachten, um ein Gesamtsystem zu testen.

Horizontale Integration:

Die horizontale Integration orientiert sich an der Wertschöpfungskette der Organisation. Im Vordergrund steht dabei die Abbildung von abteilungs- und funktionsübergreifenden Abläufen unter Verwendung von einheitlichen Daten: Zum Beispiel werden im Controlling Informationen aus der Produktion für Analysen, Planung oder innerbetriebliche Leistungsverrechnung verwendet.

Vertikale Integration:

Eine vertikale Integration finden wir vor, wenn die operativen mit den taktisch-strategischen Aktivitäten verbunden sind. Wieder auf einer einheitlichen Datenbasis werden die verschiedenen Aufgaben, die jeweils einen anderen Betrachtungszeitraum und -umfang aufweisen, miteinander verbunden.

Systemübergreifende Integration:

Unter systemübergreifender Integration wird die Anbindung von unterschiedlichen IT-Systemen verstanden. Auch hier sollen die Vorteile einer synchronisierten Datenbasis genutzt werden. In den letzten Jahren fand bei verschiedenen Softwareanbietern, vor allem bei den Anbietern von ERP-Systemen, ein eigentlicher Wandel statt. Die Integration von Drittsoftware wird besser unterstützt und die systemübergreifende Integration dadurch markant erleichtert.

Unternehmensübergreifende Integration:

Die unternehmensübergreifende Integration hat zum Ziel, auch die Kunden und Lieferanten in das eigene Datenmodell einzubinden. Dies gilt zum Beispiel auch für verwaltungsinterne Kunden-Lieferanten-Beziehungen (vgl. hierzu auch interne Leistungsverrechnungen). Lieferanten stellen Beispielweise ihren Kunden einen elektronischen Katalog zur Verfügung. Der Kunde bestellt über eine integrierte Plattform und nutzt dabei die bereitgestellte Datenbasis. Die Bestellung wird beim Abschluss auf dem ERP-System angelegt und löst alle notwendigen Prozesse aus.