Was meint er wohl damit?

Auf dieser Seite finden Sie Erläuterungen zu Begriffen, die ich in diesem Webauftritt oder bei meiner Beratung verwende.

Anforderungserhebung

Anforderungserhebung

Der Zweck der Anforderungserhebung ist recht einfach: Bevor man etwas Neues angeht oder etwas Bestehendes ändert, muß man wissen, was man will.

Da klingt trivial, dennoch wird diesem Punkt in vielen Projekten zu wenig Augenmerk geschenkt. Immer noch liegt die Ursache für das Scheitern von Projekten häufig an einer mangelhaften Anforderungserhebung.

Das Vorgehen bei der Anforderungserhebung ist meist wie folgt:

1. Sammeln und Analysieren von Anforderungen Vorab ist eine Prozessanlyse zu empfehlen. Diese hilft, sich nicht zu verzetteln.

2. Strukturieren und Abstimmung der Anforderungen Hier liefert die Lösungsarchitektur eine Struktur, in die die Anforderungen eingeorndet werden und sie hilft, Abhängigkeiten zu erkennen.

3. Püfen und Bewerten der Anforderungen Auch hier liefert die Lösungsarchitektur den Überblick für Priorisierung und Prüfung auf Machbarkeit und Widerspruchsfreiheit

Je nach Vorgehensmodell werden in der Anforderungserhebung formale Dokumente erstellt (z.B. für Ausschreibungen im öffentlichen Sektor). Die Erhebung kann aber auch iterativ und pragmatisch erfolgen, wie z.B. bei agilen Vorgehensweisen. Wichtig ist in allen Fällen, dass es keine Miß´verständnisse zwischen Auftraggeber und Auftragnehmer gibt.


Mehr ...

ARCWAY AG

ARCWAY AG

ARCWAY entwickelt und vertreibt das Modellierungswerkzeug ARCWAY Cockpit, welches als erstes Werkzeug die Modellierung von Geschäftsprozessen, IT und Anforderungen in einem Werkzeug vereint.

Die ARCWAY AG wurde 2004 als erstes Spinn-Off des Hasso-Plattner-Instituts in Potsdam gegründet. In 2010 wurde ARCWAY von der Maurizio Capital GmbH übernommen und arbeitet seitdem sehr intensiv mit den Firmen eitco und conceptQ zusammen.


Mehr ...

Bauzeichnung

DIN 1356 definiert den der Begriff der Bauzeichnung wie folgt:

"Bau­zeichnungen dienen als Verständigungsmittel zwischen dem Bauherren, dem Architekten, den Baubehörden, den ausführenden Handwerkern bzw. Baufirmen und stellen das Design der geplanten baulichen Anlage dar."

Die Komplexität der Systeme im Bereich IT und Organisation erfordert vergleichbare Verständigungsmittel. Die Methoden der Informatik sind hierfür nicht geeignet, genauso wenig wie die Modelle der Baustatik als allgemeines Verständigungsmittel geeignet sind.

Hervorragend geeignet sind die Blockdiagramme der Fundamental Modeling Concepts. Sie basieren auf einfachen klaren Regeln und sind für unterschiedlichste Stakeholder-Gruppen verständlich.


Mehr ...

Blockdiagramm

FMC-Blockdiagramm

FMC-Blockdiagramme zeigen die Aufbaustruktur eines dynamischen Systems. Sie zeigen sehr übersichtlich, aus welchen Teilen das System besteht und wie diese miteinander verbunden sind.

Blockdiagramme unterscheiden zwischen aktiven und passiven Elementen. Die aktiven Elemente, Akteure genannt, werden als Rechtecke dargestellt. Die passiven Elemente dienen zur Speicherung oder zum Transport von Informationen. Die Kanäle für den Transport von Information werden durch kleine Kreise, Speicher für Information werden durch Kreis oder „Rechtecke mit abgerundeten Ecken“ repräsentiert.

Blockdiagramme gehören zu den sogenannten „bipartiten Graphen“, d.h. aktive Elemente dürfen immer nur mit passiven Elementen verbunden werden („rund mit eckig“). Die Verbindungen (die sogenannten „Kanten“) werden als Pfeile dargestellt, welche die Zugriffsrichtung (lesen, schreibend, oder ändern) aufzeigen.

Einfaches Beispiel eines FMC-Blockdiagramms


Mehr ...

Business Analyse

Ganz kurz gesagt: die Business Analyse befasst sich mit der Aufgabe, ein Problem zu verstehen und daraus eine Lösung zu entwickeln. Diese Tätigkeit wurde lange Zeit auch als Systemanalyse bezeichnet.2003 wurde in Toronto das International Institute of Business Analysis (IIBA) gegründet. Das IIBA ist bestrebt das Berufsbild der Business Analyse – so nannte man dort die bisherige Systemanalyse – zu etablieren und einen Standard dafür zu schaffen. Dieser Standard wird im so genannten „Business Analysis Body of Knowledge“ (BABOK-Guide) beschrieben, der sich mittlerweile zu einem Standardwerk der Business Analyse entwickelt hat. Im April 2015 ist er in seiner dritten Version erschienen.Etwa zeitgleich wurde in Deutschland vom International Requirements Engineering Board (IREB) ein ähnliches Ziel verfolgt. Hier wird die Disziplin Systemanalyse als Requirements Engineering bezeichnet.Während die Business Analyse den Schwerpunkt in der fachlichen Analyse (Busines) sieht und damit über den Bereich der IT hinausgeht, hat das Requirements Engineering seinen Schwerpunkt in der Systemmodellierung und damit einen viel deutlicheren IT-Bezug.In der Version 3.0 des BABOK werden 30 unterschiedliche Aufgaben aus diesen sechs Bereichen aufgeführt:
  • Business Analysis Planning and Monitoring
  • Elicitation and Collaboration
  • Requirements Life Cycle Management
  • Strategy Analysis
  • Requirements Analysis and Design Definition
  • Solution Evaluation
Zu jeder Aufgabe wird definiert
  • wozu sie gebraucht wird
  • was der Inhalt der Aufgabe ist
  • welche Inputs gebraucht werden und welche Outputs entstehen
  • welche Leitfäden und Werkzeuge genutzt werden können
  • welche Techniken zu der Aufgabe passen
  • und welche Personengruppen beteiligt sind.
Die aggregierte Darstellung der Aufgaben und deren Zusammenwirken können Sie hier herunterladen:
Functional Architecture of Business Analysis Tasks
146.7 KiB
78 Downloads
Details

Mehr ...

Business Process driven Requirements Engineering

Das Business Process driven Requirements Engineering (BPRE) wurde von der ARCWAY AG als durchgängiger und verständlicher Weg von der Geschäftsprozessanalyse bis zur Spezifikation von IT-Projekten entwickelt. BPRE beginnt mit der Analyse und grafischen Darstellung der Geschäftsprozesse (Ist oder Soll), die durch die zu erstellende IT-Lösung unterstützt werden soll. So soll sichergestellt werden, dass die Spezialisten aus den Fachbereichen die Geschäftsprozesse einheitlich verstanden haben.Danach werden die aus den Geschäftsprozessen die Anforderungen abgeleitet und mit den relevanten Stellen in dem Prozessen verlinkt. Auf der anderen Seite werden die Anforderungen in die IT-Architektur eingeordnet. Die Anforderungen stehen somit nicht einfach in einer großen Liste hintereinander sondern werden in Kontext mit dem Bedarf (dem Geschäftsprozess) und der Umsetzung (der IT-Architektur) gesetzt. Die Qualität von Lastenheften steigt: Es wird transparent, woher Anforderungen resultieren und welche gegenseitigen Abhängigkeiten existieren. Nachträgliche Korrekturen in Projekten durch missverständliche Anforderungen nehmen ab und nachvollziehbare Priorisierungen werden möglich.
Mehr ...

Digitalisierung

Der Begriff der Digitalisierung ist heute in aller Munde. Die Meinungen, was Digitalisierung bedeutet, sind jedoch sehr unterschiedlich. Für mich ist die Definition von Prof. Dr. Thomas Hess in der Enzyklopädie der Wirtschaftsinformatik am treffendsten:
Der Begriff der Digitalisierung wird in zwei Interpretationen verwendet. Er bezeichnet entweder die Überführung von Informationen von einer analogen in eine digitalen Speicherung oder den Prozess, der durch die Einführung digitaler Technologien bzw. der darauf aufbauenden Anwendungssysteme hervorgerufenen Veränderungen.
Die erste Interpretation war lange Zeit gängig. Die Überführung von Informationen von analoger in eine digitale Form ist jedoch nur Mittel zum Zweck. Die zweite Interpretation ist für mich die ausschlaggebende und kennzeichnend für das, was man auch als Digitale Revolution bezeichnet. Durch den technologischen Fortschritt werden Veränderungen in Unternehmen möglich (und erforderlich), die weit über den technologischen Bereich hinausgehen. Die Veränderungen betreffen die Organisation mit ihren Prozessen und die Menschen, die direkt oder indirekt betroffen sind. Neben den Mitarbeitern in der Organisation gehören dazu auch die Kunden, als enorm wichtige Gruppe.
Mehr ...

Fundamental Modeling Concepts

Fundamental Modeling Concepts

Die Fundamental Modeling Concepts (FMC) sind eine Modellierungsmethodik, mit der die Strukturen von informationsverarbeitenden Systeme grafisch dargestellt werden können. Der Begriff Informationsverarbeitung ist dabei nicht auf Softwaresysteme oder technische Systeme beschränkt. Er wird in seiner grundsätzlichen (fundamentalen) Bedeutung verwendet, unabhängig davon, ob die Verarbeitung durch Technik oder durch den Menschen erfolgt. So kann FMC auch verwendet werden, um die Zusammenarbeit innerhalb oder zwischen Unternehmen darzustellen.

FMC unterscheidet drei Systemaspekte und sieht dafür jeweils eine eigene Diagrammform vor:
  • Aufbauaspekt: Blockdiagramme
  • Ablaufaspekt/Dynamik: Petri-Netze
  • Wertbereichsaspekt: Entity-Relationship-Diagramme

Für jede Diagrammform liefert FMC eine einfach zu verstehende, semi-formale Notation. Jede Notation kommt mit sehr nur zwei Arten von Symbolen aus: mit runden und eckigen Symbolen.

FMC-Diagramme dienen der Kommunikation zwischen Menschen. Sie ermöglichen es, gedachte Strukturen graphisch darzustellen. Sie sind nicht dafür gedacht, mathematisch ausgewertet zu werden, um z.B. Softwareprogramme daraus zu generieren.

FMC wurde in Zusammenarbeit mit Firmen wie SAP und SIEMENS entwickelt und erfreut sich wegen seiner Einfachheit immer größerer Beliebtheit bei IT- und Unternehmensarchitekten. SAP hat FMC in den firmeninternen Modellierungsstandard TAM (Technical Architecture Modeling) einfließen lassen.

siehe auch:
Mehr ...

Lösungsarchitektur

Was ist eine Lösungsarchitektur?

In der IT-Branche versteht man unter einer Lösung eine Kombination aus Software und Hardware, die für eine bestimmte, konkrete Aufgabenstellung dient.

Ich fasse den Begriff weiter und verwende ihn mehr aus der Sicht eines verantwortlichen Managers: Ich verstehe unter einer Lösung eine Menge von Ressourcen, welche Zusammenwirken um eine Aufgabenstellung oder ein konkretes Problem zu lösen. Neben den technischen Komponenten zähle ich dazu auch Personen und wende den Begriff Lösung nicht nur auf technische Systeme an, sondern auch auf Teams, Abteilungen und ganze Unternehmen.

Die Architektur der Lösung zeigt das strukturierte Zusammenwirken der Ressourcen als System. Sie beschreibt die Arbeitsteilung zwischen den einzelnen Ressourcen.  Je klarer die Lösungsarchitektur konstruiert und kommuniziert ist, desto reibungsloser läuft die Zusammenarbeit.

Wo setzt man Lösungsarchitekturen ein und welchen Nutzen bringen sie?

Typische Beispiele für den Einsatz einer Lösungsarchitektur sind Systeme wie:
  • Unternehmen mit ihrem Geschäftsmodell und ihren Organisationseinheiten
  • Softwaresysteme und Anwendungen, wie z.B. ein Webserver oder ein ERP-System
  • Anlagen und Geräte, wie z.B. eine Förderanlage oder ein DVD-Player

Das Ziel der Lösungsarchitektur ist es, abstrakte Informationen und schwer formulierbare Zusammenhänge durch die graphische Visualisierung für Menschen leicht verständlich zu machen. Die Skizze eines Gebäudes, mit der ein Architekt dem Bauherrn eine Vorstellung des geplanten Bauvorhabens vermittelt, ist ein Beispiel für eine Lösungsarchitektur.

In welchen typischen Situationen setzt man Lösungsarchitekturen ein?

Allgemein gesagt: immer wenn etwas komplexes neu entsteht, geändert wird, oder wenn man den Überblick über das bestehende verloren hat.

Kreative Ideen, z.B. für ein neues Produkt, entstehen in einzelnen Köpfen. Neue Ideen kommen hinzu, neue Blickwinkel tun sich auf. Die Komplexität steigt kontinuierlich. Das Tagesgeschäft lässt keine Zeit eine gemeinsame Struktur zu entwickeln. Die Gefahr den Überblick zu verlieren, wird größer.

Ähnliches passiert, wenn bestehende und gewachsene Prozesse, Organisationen oder Produkte geändert werden. Auch hier fehlt häufig der Blick von oben. Mitarbeiter konzentrieren sich auf ihre Details. Zusammenhänge und Abhängigkeiten werden nicht berücksichtigt.

Dies sind typische Szenarien, in denen ich meinen Mandanten mit einer Lösungsarchitektur das Big Picture liefere, mit dem sie ihre Teams auf ein gemeinsames Ziel ausrichten und die Zusammenarbeit koordinieren.


Mehr ...

Operatives Geschäftsmodell

Referenzmodell eines Produktionsunternehmen85.9 KiB224Das operative Geschäftsmodell eines Unternehmens beschreibt, wie die eingesetzten Ressourcen zusammenwirken um die operativen Aufgabe des Unternehmens zu erfüllen. Dabei wird auch die Interaktion mit externen Geschäftspartnern wie z.B. Lieferanten oder Banken berücksichtigt. Meist beschreibt das operative Geschäftsmodell das Unternehmen aus der Perspektive des COOs.

Mit meinem Bauplankonzept lassen sich operative Geschäftsmodelle sehr übersichtlich und verständlich darstellen. Als Bausteine können Organisationseinheiten, Prozesse, Aufgabenbereiche oder IT-Systeme vorkommen. Anhand des Bauplans kann das Zusammenwirken der einzelnen Bausteine erklärt und verdeutlicht werden. Baupläne des operativen Geschäftsmodells sind besonders hilfreich, wenn es darum geht neue Prozesse zu installieren, Prozesse zu verbessern oder wenn die Organisation umgestellt wird.

Ein Beispiel des operativen Geschäftsmodells eines Produktionsunternehmens können Sie hier herunterladen.

Referenzmodell eines Produktionsunternehmen (85.9 KiB, 224 downloads)

Mehr ...

Systemarchitektur

Systemarchitektur

Dieser Begriff wird leider sehr unterschiedlich verwendet. In Wikipedia findet man neben eine sehr allgemeinen Verwendung („Struktur und die Benennung/Darstellung von Systemen und ihren Komponenten“) auch eine IT-bezogene Definition, bei der der Begriff auf die Hardware-Ebene von Rechensystemen begrenzt wird. Der hier zugrundeliegende rein technische Systembegriff ist für mein Erachten zu eng gefasst. Im V-Modell XT wird dieser Begriff wiederum weiter gefasst. Hier berücksichtigt die Systemarchitektur neben der Hardware auch die Software und die externen Komponenten. Dies kommt der allgemeinen Bedeutung des Begriffs System viel näher. Wenn man diese Bedeutung des Begriff Systemarchitektur um die Betrachtung der Geschäftsprozesse erweitert, erhält man das, was ich als Lösungsarchitektur bezeichne.


Mehr ...

Systemisches Coaching

Diese Definition in Wikipedia finde ich sehr aussagekräftig: http://de.wikipedia.org/wiki/Systemisches_CoachingHier ein Auszug:
Systemisches Coaching ist Beratung zu Fragen des beruflichen Kontextes mit dem Ziel einer Problem(auf)lösung durch konstruktiv(istisch)e Konversation.
Coaching wird dabei als ressourcen- und lösungsorientierte Prozessberatung verstanden: Der Klient ist Experte für seine Probleme und Lösungen, der Coach ist Experte für den Weg zum Finden der Lösungen. Der Coach unterstützt den Kunden dabei, individuell passende Lösungen zu (er-)finden und gibt selbst keine Lösungen vor. Dies geschieht durch verschiedene systemische Interventionen. Systemisches Coaching ist zielorientiert und anhand konkreter, mit dem Kunden erarbeiteter Zielkriterien evaluierbar.
Systemisches Coaching betrachtet immer die Interaktion (Kommunikation beziehungsweise das Verhalten) im System, das heißt von mindestens zwei Personen – nicht einer ist „bad, mad or sad“.

Mehr ...