Business Analyse in der IT – Systemanalyse 3.0

Prolog

Das ist der Beitrag der SEQIS GmbH zur Blogparade des Business-Analyse-Camp 2016.

SEQIS ist Spezialist für Business Analyse im IT-Kontext. Es ist daher nahe liegend, unseren Beitrag dem Thema „Business Analyse in der IT“ zu widmen, nicht zuletzt auch deshalb, weil wir mit dem Ansatz „Systemanalyse 3.0“ die Konzepte des Business Analysis Body of Knowledge® (BABOK® Guide) mit unseren eigenen umfangreichen Erfahrungen – vor allem im agilen Umfeld – verbinden.

Ziel dieses Artikels ist es – gemäß dem vorgegebenen Motto – zu zeigen, dass und wie Systemanalyse 3.0 dazu beiträgt, gute Business Analyse im IT-Umfeld zu machen und dadurch erfolgreich Veränderungen in Unternehmen zu gestalten.

Mehr von diesem Beitrag lesen

Anforderungsmanagement meets Software Test: Erfolgsfaktoren

von Alexander Weichselberger

… idealer geht’s kaum: Man sitzt mal da (Systemanalyse 1) und mal dort (Software Test) – und jetzt gilt es einen Artikel zu verfassen, der beide Disziplinen gegenüberstellt. Der geneigte Leser erwartet sich selbstredend – wie es der Artikeltitel ankündigt – Erfolgsfaktoren.

1 Systemanalyse, genau gesagt Systemanalyse 3.0 beinhaltet für mich Business Analyse (-> http://www.iiba.org/babok-guide.aspx), Requirements Engineering (-> https://www.ireb.org/de) und noch ein bisschen mehr

Ring

Quelle: SEQIS Software Testing GmbH

 

Mehr von diesem Beitrag lesen

IIBA gestaltet Zertifizierungsmodell um

Bisher hat das IIBA (International Institute of Business Analysis) zwei Zertifizierungen angeboten: CBAP® (Certified Business Analysis ProfessionalTM) und CCBA® (Certification of Competency in Business AnalysisTM). Nun wurde angekündigt, dass dieses Programm erweitert werden soll.

Mehr von diesem Beitrag lesen

Systemanalyse 3.0 – Kapitel 5

Kapitel 5 – Analysieren I

(In dem wir zeigen, was die wichtigste Tätigkeit eines Systemanalytikers ist)

Nachdem wir uns im vierten Kapitel einen Gesamtüberblick über Systemanalyse 3.0 verschafft haben, wenden wir uns nun den einzelnen Elementen zu.

Analysieren als Basis-Element in Systemanalyse 3.0

Abbildung 1: Analysieren als Basis-Element in Systemanalyse 3.0

Das zentrale Element in Systemanalyse 3.0 ist – wohl keine große Überraschung – das Analysieren. In diesem Element entwickelt sich die Lösung aus einer ersten „Lösungs-Hypothese“. Durch Sammeln und Verarbeiten von Information und laufende Abstimmung durch Kommunikation mit den Stakeholdern reift die Lösung so lange, bis sie so stabil ist, dass die erforderlichen Artefakte produziert werden können.

Wenn wir dem Inhalt des Wortes „Analysieren“ auf den Grund gehen, stellen wir fest, dass das Wort aus dem Altgriechischen kommt und wörtlich „Auflösung“ bedeutet. Analyse ist eine „systematische Untersuchung, bei der das untersuchte Objekt in Bestandteile zerlegt wird und diese anschließend geordnet, untersucht und ausgewertet werden. Insbesondere betrachtet man Beziehungen und Wirkungen.“ (http://de.wikipedia.org/w/index.php?title=Analyse).

Diese – allgemeine – Definition beschreibt auch die Arbeit eines Systemanalytikers sehr gut. In diesem Artikel werden wir betrachten, was im Fall der Systemanalyse die „Bestandteile“ sind, in die das Objekt, also das Arbeitsgebiet, zerlegt wird. Die Methode, Komplexität durch Zerlegung zu reduzieren, ist nicht erst in den letzten Jahrzehnten – seit es IT und Software-Entwicklung gibt – erfunden worden, sondern ist ein altes Prinzip für das Verstehen von komplexen Sachverhalten. So gehörte die Analyse in diesem Sinne auch zu den Methoden des Philosophen René Descartes.

„Lösungsorientierte Analyse“ oder „Über rosarote Elefanten und braune Kühe“

Das Verhältnis zur Lösung unterscheidet Systemanalyse 3.0 von anderen Methoden. Requirements Engineering betrachtet die Lösung überhaupt nicht als zu seinen Aufgabenbereich gehörend. Requirements Engineering, so wie es in den Lehrplänen des IREB beschrieben ist, will Anforderungen erheben und sie entsprechend dokumentieren. Die Lösung soll anschließend auf Basis dieser Anforderungen von Designern bzw. auch den Entwicklern entworfen und realisiert werden. In Business Analyse lt. IIBA ist hingegen schon auch von der Lösung, bzw. vom Design der Lösung die Rede. Es wird von einem Lösungsansatz (Solution Approach) gesprochen, von den Anforderungen und schließlich vom Bewerten und Validieren der Lösungen. Wie eine Lösung aber zustande kommt, wie der Prozess der Lösungsfindung ist, das wird vom „Business Analysis Body of Knowledge“ (BABOK-Guide) kaum behandelt.

Systemanalyse 3.0 verfolgt hier einen anderen Ansatz, den wir Lösungsorientierte Analyse“ nennen wollen. Dieser Ansatz besagt, dass der Systemanalytiker vom ersten Moment seiner Aktivität in einem Vorhaben eine Lösungsidee im Kopf hat. Dieses Faktum lässt sich auch gar nicht verhindern. Wer ist schon einmal zu einem Gedankenexperiment eingeladen worden, in dem man aufgefordert wird, jetzt nicht an einen rosaroten Elefanten zu denken? Jeder wird bestätigen, dass das nicht möglich ist; der erste Gedanke in dieser Situation wird der an einen rosaroten Elefanten sein.

Genauso verhält es sich mit dem Gedanken an eine Lösung in einem Analysevorhaben. Nehmen wir an, Sie sollen Analyseaufgaben in einem Projekt übernehmen, in dem es um die Entwicklung eines Web-Shops für ein Handelsunternehmen geht. Sie werden kaum umhin kommen, an den Web-Shop des Online-Buchhändlers Ihrer Wahl zu denken, ob Sie es wollen oder nicht.

In Systemanalyse 3.0 stehen wir auf dem Standpunkt, dass dieses Faktum – das sich ohnehin nicht vermeiden lässt – produktiv genutzt werden sollte, anstatt es zu verdrängen. Natürlich besteht die Gefahr, dass man sich frühzeitig auf eine Lösung festlegt und die Flexibilität für neue Anforderungen und Erkenntnisse verliert. In Systemanalyse 3.0 wird dieser Gefahr dadurch begegnet, dass das „Produzieren“ aus dem „Analysieren“ ausgelagert wird – und tendenziell erst sehr spät im Prozess durchgeführt wird – dann, wenn mit keinen Informationen zu rechnen ist. Zum anderen liegt diese Flexibilität auch im Aufgabenbereich bzw. im Mindset des Analytikers – er muss lange Zeit offen für Neues sein – und bereit, sein Konzept auch zur Gänze über den Haufen zu werfen, wenn neue Informationen oder Stakeholder-Anforderungen dies erfordern.

Wenn wir von „Lösung“ sprechen, müssen wir verschiedene Dimensionen unterscheiden:

  • technisch/fachlich (how/what): es muss jeweils klar sein, ob man von der technischen Lösung spricht oder von der fachlichen Lösung. Die technische Lösung betrifft Themen, wie das exakte Screen-Design, für die Entwicklung verwendete Systeme, Datenbanken, Middleware-Systeme und dergleichen. Die fachliche Lösung wird in Konzepten ausgedrückt, wie etwa Prozessmodelle, fachliche Datenmodelle und ähnliche Darstellungsmöglichkeiten.
  • der Zeitaspekt (now/future): es muss zwischen der aktuellen und der geplanten Lösung unterschieden werden.

Suzanne und James Robertson haben diese Dimensionen im so genannten „Brown Cow“-Modell zusammengefasst [ROBERTSON2013]. Der doch etwas merkwürdige Titel dieses Modells kommt von einer englischsprachigen Aussprache-Übung, mithilfe der Englisch-Lernende die Aussprache der Vokale üben sollen – der Text dieser Übung lautet: „How Now Brown Cow“. Die aktuelle technische Lösung wird in diesem Modell als „How Now“ bezeichnet – der Rest des Aussprach-Spruchs hat dem Modell den Namen gegeben.

Abbildung 2: Das Brown-Cow-Modell [ROBERTSON2013]

Abbildung 2: Das Brown-Cow-Modell [ROBERTSON2013]

Die vier Quadranten des Brown-Cow-Modells haben folgende Bedeutung für den Systemanalytiker:

  • How Now: damit wird die aktuelle Implementierung der Lösung bezeichnet. Diese ist oft die erste Informationsquelle des Systemanalytikers. Es zeigt, wie die betrieblichen Prozesse derzeit unterstützt werden. Häufig sind Dokumentationen (Benutzerhandbücher usw.) über das Ist-System vorhanden, die einen guten Einstieg in die Analyse-Tätigkeit bilden.
  • What Now: das sind die Konzepte und Modelle, die hinter der aktuellen Lösung stehen. Eine entsprechende Dokumentation ist nicht immer verfügbar. Wenn jedoch diesbezügliche Informationen vorhanden sind, sind diese neben den Anforderungen der Stakeholder die wichtigste Informationsquelle für den Systemanalytiker.
  • What Future: dieser Quadrant ist der wichtigste für den Systemanalytiker, er bezeichnet das eigentliche Ziel der Arbeit des Systemanalytikers: die fachliche Lösung. Das Konzept wird im Basis-Element „Analysieren“ erstellt, unter Berücksichtigung der Informationen, die im Basis-Element „Kommunizieren“ gewonnen werden. Im Basis-Element „Produzieren“ erfolgt schließlich die Ausarbeitung im Format, das im jeweiligen Vorgehensmodell gefordert wird.
  • How Future: damit wird die zukünftige technische Lösung bezeichnet. Diese ist nicht Aufgabe des Systemanalytikers. Sehr häufig gibt es jedoch dennoch Beziehungen zu diesem Bereich. Die Entwickler sind wichtige Stakeholder im Analyse-Prozess. Wenn die Technik schon bekannt ist, mit der das Vorhaben letztendlich umgesetzt werden soll, wird das der Systemanalytiker in seinen Konzepten entsprechend berücksichtigen.

Das Brown-Cow-Modell ist eine Hilfe für den Systemanalytiker, Gedanken und Ideen richtig einzuordnen, sodass schließlich das Ziel – das „What Future“ erreicht wird. Es ist jedoch kein Prozess in dem Sinne, dass die verschiedenen Quadranten in einer bestimmten Reihenfolge durchlaufen werden müssen.

Analyse ist Zerlegen – aber in was?

Wie wir oben schon festgestellt haben, bedeutet „Analysieren“ dem Wortsinn nach „Zerlegen“ in Elemente. Dabei stellt sich jetzt die Frage, was sind denn die Elemente, in die wir in der Systemanalyse zerlegen?

Im Bereich der IT-Analyse haben wir es nahezu immer mit zwei Themenkreisen zu tun: mit der Welt der Daten auf der einen Seite und mit der Welt der Funktionen auf der anderen. Die Welt der Daten beschreibt die Informationen, die bearbeitet und festgehalten werden (statische Sicht), die Welt der Funktionen, welche Tätigkeiten bzw. Algorithmen diese Informationen erzeugen und bearbeiten (dynamische Sicht).

Die Objektorientierte Analyse, die vor einiger Zeit sehr modern war, wollte diese beiden Bereiche in einem Konzept vereinen. Dabei werden die Daten in Klassen gegliedert, die die Funktionen in der Form von so genannten Methoden inkludieren. Die Trennung in Daten und Funktionen wäre aufgehoben gewesen. Nur – anders als in der Welt der Programmiersprachen – hat sich in der Analyse dieser objektorientierte Ansatz nicht durchgesetzt. Es entspricht eben doch nicht der Realität, dass die Objekte von sich aus etwas tun. Vielmehr wird – durch die Funktionen – mit ihnen etwas getan.

Aus diesem Grund wollen auch wir in unserer weiteren Betrachtung der Elemente in der Systemanalyse von dieser Trennung in Daten und Funktionen ausgehen. In jeder der beiden Bereiche wollen wir ein „Primäres Analyse-Objekt“ definieren. Das ist nicht notwendigerweise das kleinstmögliche Element. Es ist vielmehr das Objekt, das im Zentrum der Analyse-Überlegungen steht, aus denen sich das Gesamtsystem zusammensetzt – auch wenn eine noch detailliertere Betrachtung möglich ist.

Das Primäre Daten-Analyse-Objekt

Jedes Arbeitsgebiet, das wir als Systemanalytiker untersuchen, setzt sich aus vielen „Dingen“ zusammen. „Dinge“ – das ist jetzt im weitesten Sinne zu sehen. Selbstverständlich können das auch Menschen sein, man denke nur an ein Personal-Informationssystem. Diese Dinge sind häufig materiell, sehr häufig auch immateriell, z. B. eine Reise oder eine andere Dienstleistung. Ja, sie können darüber hinaus auch abstrakt sein, also etwas, das es so in der Realität überhaupt nicht gibt, etwa ein Konto (wobei man jetzt diskutieren könnte, ob es einen Unterschied gibt zwischen immateriell und abstrakt). Da man unter einem „Ding“ allgemein doch etwas versteht, das man angreifen kann – und das kein Mensch ist, wollen wir allgemeiner von „Objekten“ sprechen. Und da uns auch weniger diese Objekte an und für sich interessieren, sondern alles was mit Informationen über diese Objekte zusammenhängt, sprechen wir von „Informationsobjekten“.

Aufgabe des Systemanalytikers ist es, diese Informationsobjekte zu finden – das Arbeitsgebiet in diese Informationsobjekte zu zerlegen. Das Primäre Daten-Analyse-Objekt ist also dieses Informationsobjekt.

Bis zu einem gewissen Punkt ist das auch recht einfach und bedarf weder viel Wissens noch Erfahrung. Viele der Informationsobjekte sind ganz offensichtlich – ein IT-System, das Fahrzeuge verwaltet, wird eben diese Fahrzeuge als Informationsobjekte haben. Daneben wird es jedoch auch etliche Informationsobjekte geben, die erst auftauchen, wenn der Systemanalytiker einiges an Wissen über das Arbeitsgebiet gesammelt hat. Und schließlich kommt dann der Punkt, wo man tiefer in die Analyse eintauchen wird müssen. Da geht es dann um Fragen, wie: Ist es zweckmäßig, ein Informationsobjekt, das auf den ersten Blick wie eines erscheint in zwei aufzuteilen? Es wird auch etliche Informationsobjekte geben, die keinerlei Entsprechung in der Realität haben, die der Systemanalytiker erfindet, um die erforderlichen Informationen in sauberer Form verwalten zu können.

Mit der Identifikation der Informationsobjekte ist es jedoch nicht getan. Die Informationsobjekte sind Träger von Informationen, wie ja der Name schon sagt. Herauszufinden, welcher Art und welchen Umfangs die Informationen sind, die ein Informationsobjekt trägt, ist eine weitere Aufgabe des Systemanalytikers. Die gefundenen Informationsobjekte werden um Attribute ergänzt. Die Attribute für das Objekt „Person“ sind z. B. Vorname und Zuname und – je nach Arbeitsgebiet – eine Menge weiterer Attribute.

Die dritte Art von Information, die mit den Informationsobjekten verbunden ist – neben den Objekten und ihren Attributen, sind die Beziehungen zwischen den Objekten. Diese herauszufinden und zu dokumentieren gehört ebenfalls zu den Aufgaben des Systemanalytikers. Sehr viel Wissen über das Arbeitsgebiet steckt in diesen Beziehungen.

Abbildung 3: Aus "Dingen" werden Informationsobjekte

Abbildung 3: Aus „Dingen“ werden Informationsobjekte

Alles zusammen – das Informationsobjekt, seine Attribute und die Beziehungen zwischen den Informationsobjekten – wird das Datenmodell des Arbeitsgebietes genannt. Es gibt mehrere Möglichkeiten, dieses Datenmodell darzustellen.

Lange Zeit waren die so genannten Entity-Relationship-Diagramme vorherrschend. Diese bezeichnen die Informationsobjekte als Entities und die Beziehungen als Relationships. Seit vielen Jahren hat sich auf dem Gebiet der Modellierung jedoch die UML (Unified Modeling Language) durchgesetzt. Diese sieht für die Datenmodellierung die Klassendiagramme vor. Die Klassendiagramme kommen aus der Objektorientierten Analyse, d. h. es wäre an und für sich vorgesehen, dass in den Informationsobjekten, die in diesem Fall ‚Klassen‘ genannt werden, auch die Methoden – also die Funktionen – modelliert werden. In der Praxis werden die Methoden aber zumeist weggelassen, sodass die Entity-Relationship- und Klassen-Diagramme in ähnlicher Weise verwendet werden und sich lediglich in der Syntax unterscheiden.

Wir fassen also zusammen: Aus der Datensicht zerlegt die Systemanalyse ein Arbeitsgebiet in Informationsobjekte. Diese werden durch die Attribute beschrieben und durch Beziehungen in ein Gesamtsystem gebracht. Das ist die statische Sicht eines Arbeitsgebietes.

Zur vollständigen Beschreibung muss die dynamische Sicht ergänzt werden. Wir müssen also herausfinden, was mit den Daten der statischen Sicht geschieht. Wie entstehen sie, wie werden sie modifiziert und bearbeitet, sodass letztlich Geschäftsnutzen entsteht. Was sind die Primären Funktions-Analyse-Objekte?

Das Primäre Funktions-Analyse-Objekt

Es gibt eine Menge an Tätigkeiten und Aufgaben, die in einem zu analysierenden Arbeitsgebiet anfallen, es werden neue Daten erfasst (Bestellungen, Aufträge, Kunden, …), es müssen Änderungen an bestehenden Daten vorgenommen werden und es gibt Informationsbedürfnisse, die befriedigt werden müssen. Analyse bedeutet, Ordnung in diese zunächst ungeordnete Menge an Aktionen zu bringen.

Dafür sind verschiedene Möglichkeiten vorstellbar. Die gängige und häufig empfohlene Gliederung dieser Aktivitäten sind jene nach Prozessen. Es werden die Arbeitsabläufe mit ihren einzelnen Schritten beschrieben, die zu einem bestimmten Ergebnis führen und ihrer Gesamtheit Wert schaffen sollen.

Ein Begriff, der in diesem Zusammenhang weite Verbreitung gefunden hat, ist der „Use-Case“. Ein Use-Case beschreibt die Reaktion des Systems auf ein externes Ereignis. Beispiel für Use-Cases wären: „Ein Buch entlehnen“, „Geld abheben“, „Kontostand abfragen“. Use-Cases und Prozesse stehen in einem Zusammenhang, sind aber nicht ident. Ein Use-Case stellt das Verhalten eines Systems aus der Außensicht dar, während der Schwerpunkt eines Prozesses auf den einzelnen Prozessschritten liegt und diese in Beziehung zueinander setzt. Die Detaillierung eines Use-Cases erfolgt durch die Beschreibung des dazugehörigen Prozesses.

Die Arbeit des Systemanalytikers muss jedoch über die Use-Case- bzw. Prozess-Ebene hinausgehen. Ein Prozess besteht aus mehreren Schritten. Jeder Prozess-Schritt beinhaltet eine Aktion, die von einem Akteur ausgeführt wird. Jede derartige Aktion kann Prozessschritt in mehreren Prozessen sein. Zum Beispiel kann die Aktion „Kontostand abfragen“ in mehreren Prozessen vorgesehen werden. Diese Mehrfach-Verwendung von Aktionen muss in der Systemanalyse berücksichtigt werden.

Das Hauptaugenmerk des Systemanalytikers liegt auf dieser Aktion, die in einem Prozessschritt ausgeführt wird. Sie ist das „Primäre Funktions-Analyse-Objekt“. Diese Aktion kann wiederum aus mehreren Handlungen bestehen. Herausforderung ist es nun, die Aktionen so voneinander abzugrenzen, dass kompakte Einheiten entstehen, die klar nach außen abzugrenzen sind.

Ein Beispiel für eine derartige Aktion könnte „Kundendaten erfassen“ heißen. Die Aktion kann in mehreren Use-Cases bzw. Prozessen vorkommen und besteht aus mehreren Einzelhandlungen, z. B. „Vorname erfassen“, „Zuname erfassen“, „Adresse erfassen“.

In Systemanalyse 3.0 wollen wir diese Aktion „Transaktion“ nennen. Dieser Begriff wird ursprünglich in der Software-Technik verwendet und bedeutet, dass eine bestimmte Funktion mit allen Schritten ganz oder gar nicht durchgeführt wird. So soll verhindert werden, dass etwa bei einer Bank-Überweisung nur die Abbuchung, nicht jedoch die Zugangsbuchung durchgeführt wird.

Im Bereich der Systemanalyse 3.0 wird der Begriff „Transaktion“ in ähnlicher Weise gebraucht; er bezeichnet ebenso eine Funktion, die eine Einheit darstellt und (in der Regel) ganz oder gar nicht durchgeführt wird. Diese fachliche Transaktion kann, muss aber nicht mit der technischen Transaktion übereinstimmen.

Transaktionen sind also die Bausteine, aus denen die Prozesse zusammengesetzt werden.

Abbildung 4: Aus Handlungen werden Transaktionen

Abbildung 4: Aus Handlungen werden Transaktionen

Aus dynamischer Sicht ist es also Aufgabe der Systemanalyse, die Menge an Tätigkeiten und Aufgaben, die in einem Arbeitsgebiet anfallen, in Transaktionen zu gliedern und zusammenzufassen. Die Transaktionen stehen in einer Beziehung zueinander. Diese Beziehungen bilden die Prozesse. Aus der Außensicht entsprechen diese Prozesse den Use-Cases.

Daten und Funktionen – eine Einheit

Daten und Funktionen müssen letzten Endes in der Lösung eine Einheit bilden. Dennoch können sie in der Analyse bis zu einem gewissen Grad getrennt behandelt werden. Und dann stellt sich natürlich die Frage nach der Reihenfolge. Sollen zuerst die Daten oder zuerst die Funktionen analysiert werden?

Im Prinzip ist das ein Henne-Ei-Problem. Daten sind wertlos, wenn sie in keinen Funktionen verwendet werden. Ebenso sind Funktionen ohne Daten nicht denkbar. Deshalb besteht auch eine enge Abhängigkeit zwischen der Funktions- und der Datenanalyse. Aber trotz dieser Abhängigkeit zeigt die Erfahrung, dass die Welt der Daten wesentlich stabiler ist als jene der Funktionen.

Wenn ein durchdachtes, stabiles Datenmodell vorliegt, dann ergeben sich die dazugehörigen Funktionen häufig wie von allein. Aus diesem Grund sprechen wir die Empfehlung aus: Konzentrieren Sie sich zunächst auf das Datenmodell. Finden Sie die Informationsobjekte, die Attribute zwischen den Informationsobjekten. Und suchen Sie eine klare, auf einfache Grundprinzipien basierende Struktur. Wenn die Basis-Struktur bereits sehr komplex ist, wird es Ihnen schwer fallen, die Komplexität, die sich im Laufe der Analyse zwangsläufig ergeben wird, abzubilden.

Eine Technik, mit der der Zusammenhang formal dargestellt werden kann, ist die so genannate CRUD-Matrix – CRUD steht dabei für „Create – Read – Update – Delete“ – die Basis-Aktionen für die Bearbeitung von Daten.

Die CRUD-Matrix gibt Auskunft darüber, welche Informationsobjekte in welchen Transaktionen wie angezeigt und bearbeitet werden. Zu diesem Zweck werden die Transaktionen, die das Ergebnis der Funktionsanalyse sind, in den Zeilen dargestellt und die ermittelten Informationsobjekte in den Spalten der Matrix. In den Schnittpunkten der Zeilen und der Spalten wird jeweils angegeben, ob und wie das jeweilige Informationsobjekt in der Transaktion behandelt wird, wobei das „C“ für „Create“ (Neuanlage), das „R“ für „Read“ (Lesen), das „U“ für „Update“ (Ändern) und das „D“ für „Delete“ (Löschen) steht.

Das gibt nur einen sehr guten Gesamt-Überblick über die Primären Analyse-Objekte, sondern es kann auch auf einfache Art und Weise festgestellt werden ob noch Lücken in der Analyse bestehen. Wenn etwa ein Informationsobjekt in keiner Zelle ein „C“ stehen hat, so muss sich der Analytiker die Frage stellen, wo dieses Informationsobjekt herkommt. In Einzelfällen kann es gute Gründe dafür geben, häufig ist das aber auch ein Indiz dafür, dass noch eine Transaktion fehlt.

Umgekehrt – falls für ein Informationsobjekt nur ein „C“ eingetragen ist, wird man sich die Frage stellen, ob es überhaupt benötigt wird.

Abbildung 5: CRUD-Matrix

Abbildung 5: CRUD-Matrix

Zusammenfassung

In diesem Artikel haben wir uns mit dem ersten Basis-Element der Systemanalyse, dem „Analysieren“ beschäftigt. Wir haben festgestellt, dass in diesem Basis-Element die Lösung entwickelt und ausgearbeitet wird. Mithilfe des Brown-Cow-Modells werden die verschiedenen Dimensionen der Lösung dargestellt.

Analysieren bedeutet Zerlegen. In Systemanalyse 3.0 sind die Elemente, in die zerlegt wird, die Informationsobjeke aus datenorientierter Sicht und die Transaktionen aus funktionsorientierter Sicht. Mithilfe einer CRUD-Matrix können die beiden Sichten vereinheitlicht dargestellt werden.

Im nächsten Artikel werden wir noch beim Analysieren bleiben. Es soll konkret dargestellt werden, wie der Prozess der Zerlegung in die Primären Analyse-Objekte abläuft. Dabei soll vor allem auch darauf eingegangen werden, wie der Systemanalytiker eine kreative Lösung finden kann.

Systemanalyse 3.0 – Kapitel 4

Kapitel 4 – Das Big Picture

(In dem wir den Gesamtprozess der Systemanalyse 3.0 betrachten)

In den ersten drei Artikeln haben wir definiert, was Systemanalyse 3.0 ist und in welchem Verhältnis sie zu jenen Methoden und Konzepten steht, auf denen sie letztlich basiert. Im nächsten Schritt wollen wir uns nun dem Inhalt von Systemanalyse 3.0 zuwenden. Das soll das Thema dieses Kapitels sein. Es werden die Basis-Elemente von Systemanalyse 3.0 erläutert – darauf aufbauend wird gezeigt, wie sich aus diesen Grundelementen der Systemanalyse-Prozess zusammenfügt.

Zu Beginn wollen wir aber die Anforderungen an den Prozess „Systemanalyse 3.0“ festhalten. Was soll Systemanalyse 3.0 leisten? Das kann in den folgenden Punkten zusammengefasst werden:

  1. Die Vorgehensweise soll erklären, wie Wissen über das Arbeitsgebiet aufgebaut wird.
  2. Sie soll es ermöglichen, dass die betroffenen Stakeholder (= alle Personen, die von dem Vorhaben betroffen sind) einbezogen werden.
  3. Es soll dargestellt werden, wie der Output der Analysetätigkeit aussieht, und wie dieser produziert wird.
  4. Die Methode soll das Finden einer oder mehrerer Lösungen zum Ziel haben.
  5. Sie soll den im vorangegangenen Kapitel gezeigten Schritten des kreativen Prozesses Raum geben.
  6. Der Prozess soll so flexibel sein, dass er sowohl für traditionelle als auch für agile Methoden der Software-Entwicklung anwendbar ist.

Die Aufgabe der Systemanalyse

Die Aufgabe der Systemanalyse ist es, die Lösung (oder auch mehrere Lösungen) für einen Bedarf (Business Need) zu finden.

Was hier „Bedarf“ genannt ist, bezeichnet die Aufgabenstellung, die im jeweiligen Vorhaben (Projekt) bearbeitet werden soll. Das kann vielerlei sein: Es kann ein Problem mit einem Prozess sein, das durch IT-Unterstützung gelöst werden soll. Es kann eine Marktchance sein, die das Unternehmen wahrnehmen möchte – und wofür die IT-Umgebung des Unternehmens erweitert werden muss. Oder es kann einfach ein IT-System sein, das in die Jahre gekommen ist und das ersetzt werden soll.

Bei der Lösung handelt es sich in der Regel um eine Lösung im IT-Kontext, d. h. um ein neues IT-System oder um die Erweiterung eines bestehenden Systems. Es ist aber auch nicht auszuschließen, dass das Ergebnis der Systemanalyse ist, dass das Problem nicht durch IT-Einsatz gelöst werden sollte, sei es, weil es nicht wirtschaftlich ist – oder weil es andere, bessere Lösungen gibt, den Bedarf zu decken.

Wenn hier von „Lösung“ die Rede ist, dann ist immer „Design“ der Lösung gemeint. Für die Umsetzung der Lösung durch Programmierung bzw. durch konkreten Einsatz von Software-Produkten ist nicht die Systemanalyse zuständig.

basis_prozess

Abbildung 1: Basis-Prozess der Systemanalyse

Die Basis-Elemente

Die Arbeit in Systemanalyse 3.0 besteht aus drei Basis-Elementen:

  1. Analysieren
  2. Kommunizieren
  3. Produzieren

Diese drei Elemente spielen zusammen – und verfolgen dabei das Ziel, eine oder mehrere Lösungen zu generieren – Lösungen, die der Aufgabenstellung entsprechen, die den Bedarf decken.

Analysieren

Die Aussage, dass in der Systemanalyse analysiert wird, mag trivial erscheinen. Und doch ist es notwendig, das zu betonen – in den Konzepten der Business Analyse und des Requirements Engineering wird gerade dieser Bereich nicht besonders betont.

Was tut nun ein Systemanalytiker, wenn er analysiert? Was bedeutet eigentlich „Analyse“?

  • Dem Wortsinn nach bedeutet „Analysieren“ „Zerlegen“ – das Arbeitsgebiet wird in überschaubare Einheiten zerlegt – Einheiten, die klein genug sind, um sie vollständig begreifen zu können.
  • Damit dieses „Zerlegen“ funktionieren kann, ist es wichtig, Informationen zu sammeln, wo immer man sie kriegen kann. Durch diese Informationen muss der Systemanalytiker die Essenz des Arbeitsgebiets herausfinden. Wie funktioniert dieses Arbeitsgebiet? Worauf kommt es an? Was sind die Ziele? Was sind die Rahmenbedingungen?
  • Diese kleinsten Einheiten werden anschließend so zusammengesetzt und in ein System gebracht, dass die Aufgabenstellung erfüllt wird – das ist schließlich das Design der Lösung.
Kommunizieren

Der Systemanalytiker erarbeitet die Lösung nicht für sich selbst. Er hat einen Auftraggeber. Es gibt Know-How-Träger, die Informationen liefern können – und müssen. Und schließlich gibt es auch Menschen, die mit der vom Systemanalytiker erarbeiteten Lösung leben und arbeiten müssen.

Daraus ergeben sich auch die Funktionen der Kommunikation in der Systemanalyse 3.0:

  • Einholen von Information
  • Erheben der Anforderungen
  • Abstimmung von Lösungsvorschlägen des Systemanalytikers
  • Abnahme des Lösungsvorschlags des Systemanalytikers.

In Systemanalyse 3.0 ist Kommunizieren immer etwas Dialogisches. Der Systemanalytiker holt sich nicht bloß die Anforderungen ab, sondern er wird immer auch schon mit einer Idee einer Lösung zum Stakeholder gehen – die er vielleicht nicht immer präsentiert, die er aber doch als Hypothese verwendet, die durch die Aussagen des Stakeholders entweder bestätigt wird – oder modifiziert oder gar verworfen werden muss.

Produzieren

Wie jede Arbeit muss auch die Arbeit des Systemanalytikers Ergebnisse liefern. Das Ziel der Arbeit des Systemanalytikers ist das Design der Lösung. Dieses Design ist etwas Geistiges und im Prinzip nicht an materielle Artefakte gebunden. In der Praxis muss dieses Ergebnis aber auch kommuniziert werden. Da dies normalerweise nicht nur mündlich vor sich gehen kann, muss der Output des Systemanalytikers auch in irgendeiner Weise festgehalten werden. Diese Dokumentation kann verschiedene Formen annehmen. Sie kann durch natürlich-sprachige Texte erfolgen. Sehr häufig wird das Ergebnis der Analysetätigkeit aber auch in der Form von Modellen dokumentiert.

Die Art, wie die Ergebnisse dokumentiert werden, ist auch von der gewählten Methode abhängig. In traditionellen Vorgehensweisen entsteht meist ein Pflichtenheft oder eine Anforderungsspezifikation. In agilen Software-Entwicklungsmethoden wird das Ergebnis der Analyse häufig in Form von User-Stories dokumentiert.

Der Mikro-Prozess der Systemanalyse

Die drei Basis-Elemente der Systemanalyse, Analysieren – Kommunizieren – Produzieren, werden zum so genannten Mikro-Prozess der Systemanalyse zusammengesetzt. Dieser Mikro-Prozess ist für alle Vorhaben gültig – unabhängig davon, wie lange sie dauern. Das heißt, ein derartiger Mikro-Prozess nimmt vielleicht nur wenige Minuten in Anspruch – oder auch mehrere Monate; der prinzipielle Aufbau des Mikro-Prozesses bleibt davon unberührt.

Der Mikro-Prozess der Systemanalyse ist in Abbildung 2 dargestellt.

mikroprozess

Abbildung 2: Der Mikro-Prozess der Systemanalyse

Zentrales Element ist das Analysieren. Diese Tätigkeit steuert den gesamten Prozess. Unmittelbar nach dem Start des Prozesses beginnt der Analytiker mit dem Sammeln von Informationen über das Arbeitsgebiet. Dadurch lernt er das Arbeitsgebiet kennen. In den meisten Fällen hat der Systemanalytiker dann schon eine Lösung vor Augen. Das lässt sich auch gar nicht verhindern. Die Lösung ist schließlich das, was letztendlich heraus kommen soll.

Diese „Lösungs-Hypothese“ muss jedoch ständig herausgefordert werden – herausgefordert durch zusätzliche Informationen, herausgefordert auch durch die Anforderungen der Stakeholder. Im wissenschaftlichen Kontext würde man vom Versuch der Falsifizierung sprechen. Dadurch wird sich diese „Lösungs-Hypothese“ verändern und weiterentwickeln. Nicht selten wird sie auch zur Gänze verworfen werden und eine neue Lösungs-Hypothese wird sie ersetzen, die nun ebenfalls wieder gegen neue Informationen und Anforderungen zu überprüfen ist.

Die wesentliche Funktion des Basis-Elements „Kommunizieren“ ist die Herausforderung der Lösungs-Hypothese. Durch die Kommunikation mit Stakeholdern sammelt der Systemanalytiker Wissen. Eine spezielle Art der Information sind die „Anforderungen“. Das sind Ideen und Vorstellungen, die die Stakeholder über die Lösung haben. Anforderungen haben üblicherweise große Auswirkungen auf die Lösungs-Hypothese.

Ab einem gewissen Punkt des Analysierens und damit verbundenen Kommunizierens wird der Systemanalytiker die Entscheidung treffen, jetzt „fertig“ zu sein. Wann dieser Punkt erricht ist, hängt von mehreren Faktoren ab. Diese Entscheidung hat eine fachliche Komponente. Wenn alle Stakeholder befragt sind, alle verfügbaren Informationen ausgewertet, keine neuen Aspekte mehr zu erwarten sind und ein akzeptabel scheinendes Lösungsdesign vorhanden ist, dann ist dieser Punkt erreicht. Nicht zu unterschätzen ist aber auch die planerische Komponente. Wenn ein Meilenstein-Termin näher rückt oder wenn das vorgesehene Budget erschöpft ist, auch dann wird möglicherweise die Analyse-Tätigkeit beendet, auch wenn noch eine bessere Lösung denkbar wäre. Die „Lösungs-Hypothese“ wird dann zur „vorgeschlagenen Lösung“.

Solange die Analyse noch nicht abgeschlossen ist, muss der Analytiker weitestgehend flexibel bleiben. Es darf keinen übermäßigen Aufwand verursachen, wenn eine „Lösungs-Hypothese“ geändert oder gar gänzlich verworfen wird. Wenn zu diesem Zeitpunkt schon viel Arbeitszeit in die Produktion des Ergebnisses geflossen ist, dann geht von dieser Flexibilität verloren. Deshalb sieht Systemanalyse 3.0 vor, dass mit dem „Produzieren“ erst begonnen wird, wenn die Lösung gedanklich – im Kopf des Analytikers – „fertig“ ist. Zu diesem Zeitpunkt sind keine gröberen Änderungen mehr zu erwarten und man kann davon ausgehen, dass die entstehenden Artefakte auch Bestand haben. Das schließt natürlich nicht aus, dass auch in der „Produzieren“-Phase noch die eine oder andere kreative Idee auftaucht. In diesem Fall sollte sich der Systemanalytiker nicht scheuen, in die Phase des „Analysierens“ zurückzuschalten. Es ist eine Frage der Kosten-Nutzen-Abwägung, ob bereits produzierte Artefakte verworfen werden. Deshalb sollte die Rückkehr vom „Produzieren“ – in den „Analysieren“-Status die Ausnahme bleiben.

Die fertiggestellten Artefakte müssen den Stakeholdern auch noch kommuniziert werden. Doch auch hier gilt: es sollten keine großen Änderungen mehr zu erwarten sein. Das bedingt, dass die vorgeschlagene Lösung schon in der Analyse-Phase möglichst weitgehend mit den Stakeholdern abgestimmt wurde.

Der Makro-Prozess der Systemanalyse

Manchmal kommt ein Vorhaben mit einem einzigen Mikro-Prozess der Systemanalyse aus. Das wird vor allem dann der Fall sein, wenn es sich um ein sehr kleines Vorhaben handelt und wenn nach einem strengen Wasserfall-Modell vorgegangen wird. In allen anderen Fällen wird es sehr viele derartige Mikro-Prozesse geben. Diese Summe dieser Mikro-Prozesse ergibt den Makro-Prozess der Systemanalyse. Dieser ist in Abbildung 3 dargestellt.

makroprozess

Abbildung 3: Der Makro-Prozess der Systemanalyse

Der Makro-Prozess der Systemanalyse besteht im Kern aus einer Reihe von Analysieren-Kommunizieren-Produzieren-Blöcken, also von Mikro-Prozessen der Systemanalyse. Wie viele es tatsächlich sind und wie diese strukturiert sind, hängt von der Organisation des Entwicklungsprozesses ab. Der in Abbildung 3 dargestellte würde einem typischen agilen Prozess entsprechen. Nach einem Block, der einen Überblick über das gesamte Vorhaben schafft, gibt es eine ganze Reihe von kleineren Blöcken, die das iterative Vorgehen in einem agilen Projekt repräsentieren. Im Fall der Anwendung des Scrum-Prozesses würden diese Blöcke den Sprints entsprechen.

Bevor jedoch mit dem ersten Mikro-Prozess begonnen wird, sind etliche Vorbereitungen erforderlich. Dafür ist eine eigene Phase vorgesehen, die wir schlicht „Start“ nennen möchten. In dieser Start-Phase werden folgende Aktivitäten durchgeführt:

  • Festlegung der Ziele: es wird definiert, was mit dem Vorhaben überhaupt erreicht werden soll.
  • Festlegung des initialen Scopes: es wird überblickshaft dargestellt, was sich innerhalb des Aufgabenbereichs des Vorhabens befindet und was außerhalb. Es handelt sich dabei um eine grobe Abgrenzung, die sich im Laufe des Analyseprozesses noch verschieben kann. Sie soll jedoch eine Richtlinie vorgeben, an die sich der Systemanalytiker handelt.
  • Erste Abklärung der vorhandenen Stakeholder: Auch die Auflistung der Personen, die von dem Vorhaben in irgendeiner Form betroffen sind, ist eine vorläufige. Im Zuge der Analyse-Arbeiten werden häufig weitere Personen und Personenkreise eruiert, die Interesse an dem Vorhaben haben und dazu beitragen können.
  • Festlegung der geplanten Vorgangsweise: es ist festzuhalten, ob agil oder traditionell vorgegangen werden wird, wie die geplanten Termine sind, welche Artefakte entstehen sollen und ähnliche Fragen mehr.

Das Thema dieses Blogs ist die Analyse. Dennoch müssen auch die Nachbardisziplinen Entwicklung und Test insofern betrachtet werden, als die Analyse damit in Beziehung steht. Einerseits liefert die Systemanalyse mit ihren Artefakten die Basis für Entwicklung und Test. Andererseits liefern diese Bereiche auch Input für das Verständnis der vom Analytiker entwickelten Lösung und sind aus diesem Grund in die Analysetätigkeit einzubeziehen.

Zusammenfassung und Ausblick

Die Basis-Elemente „Analysieren“, „Komunizieren“ und „Dokumentieren“ werden zum Mikro-Prozess der Systemanalyse kombiniert. Der Makro-Prozess der Systemanalyse ergibt sich aus einem oder mehreren Mikro-Prozessen, ergänzt um eine Start-Phase sowie um die Beziehung zu den Nachbar-Disziplinen „Entwicklung“ und „Test“.

In weiterer Folge wollen wir nun detaillierter in diesen Prozess einsteigen und uns im nächsten Kapitel dem Basis-Element „Analysieren“ widmen.

Strategische Partnerschaft zwischen IIBA und IREB

Am 20.08.2015 hat das IIBA (International Institute of Business Analysis) bekannt gegeben, dass globale strategische Allianzen mit mehreren Organisationen geschlossen wurden (http://www.iiba.org/mou.aspx). Unter diesen Organisationen ist auch das International Requirements Engineering Board (IREB), das insbesondere durch seine CPRE (Certified Professional for Requirements Engineering)-Zertifizierungen bekannt geworden ist.

Die Zusammenarbeit soll folgenden Zielen dienen:

  • Förderung des Einsatzes von Business Analyse und Requirements Engineering als Standard-Techniken sowie die Förderung von Zertifizierung und deren gegenseitige Ausrichtung.
  • Ausrichtung der Zertifizierungsprogramme und Schaffung größerer Klarheit über den Kontext und den Zweck.
  • Bewerbung der Ansätze bei Konferenzen und anderen Events.
  • Zusammenarbeit bei akademischen Engagement und weiterer Entwicklung der Fachgebiete.

Diese Entwicklung bestätigt die Entscheidung von SEQIS, seinen Kunden beide Disziplinen in kombinierter Form zur Verfügung zu stellen und so maximalen Wert zu schaffen.

SEQIS setzt in seinen Projekten eine auf die jeweilige Situation abgestimmte Kombination aus Business Analyse und Requirements Engineering ein. Neben diesem praktischen Einsatz entwickelt SEQIS mit „Systemanalyse 3.0“ eine Vorgehensweise, die ebenfalls Business Analyse und Requirements Engineering kombiniert und speziell auf IT-Projekte unter besonderer Berücksichtigung der Lösungsfindung abgestimmt ist (https://blog.seqis.com/systemanalyse-3-0/).

Die nun geschlossene Allianz zwischen IIBA und IREB bestätigt unseren Weg und ermöglicht es uns, noch besser unsere Kunden bei der Erreichung ihrer Ziele zu unterstützen.

Teambuilding-Konzepte für verteilte Teams

APIs, der digitale Klebstoff – damit verbinden wir Komponenten oder Systeme zu einem Ganzen, sind Cloud-aware, flexibel, skalierbar, modular. Durch das Angebot gut dokumentierter Programmierschnittstellen (API) kann unsere Software einen erheblichen Wettbewerbsvorteil für sich verbuchen, wenn Skalierung durch teamfremde (ggf. externe) Entwickler realisierbar ist.

Soweit, so gut. Schaut man hinter die Kulissen auf die Akteure, so haben wir es oft mit „virtuellen Teams“ zu tun. Synonyme gefällig? Gerne: „verteilte Teams“, „Homework“ oder „Telearbeit“. Wenn wir aber eines aus den agilen Werten und Prinzipien gelernt haben, dann sind Kommunikation und Nähe zwischen den Akteuren die Ausgangspunkte erfolgreicher Projekte. Technologien, wie APIs, die eine Verteilung unterstützen, sind generell neutral – aber es kommt darauf an, wie man den damit verbundenen Herausforderungen begegnet. Klar, je weiter entfernt die Menschen von einander arbeiten, sei es aus Sicht der Örtlichkeit, der Zeitzonen, der Kultur, der Sprache – die Kommunikation wird bei verteilten Teams bedeutend schwieriger und ja, die zwischenmenschliche Nähe leidet besonders.

Teambuilding – mehr als nur  gemeinsam auf ein Bier

Was ist falsch am gemeinsamen Bier? Vordergründig: Nichts, passt gut und gehört klarerweise dazu! Ich werde selbst nach Jahren immer wieder zu einem gemeinsamen Bier mit ehemaligen Kollegen eingeladen und nutze diese Gelegenheiten sehr gerne🙂. Aber mal ehrlich: Worüber spricht man beim gemeinsamen Bier? Den Projektstatus und Co. Wenn’s gut läuft, dann redet man auch über Fußball und/oder über’s Kino, weil man eben neben der gemeinsamen Arbeit auch noch andere Interessen teilt. Auf den zweiten Blick wird aber klar, dass man sich kaum über sich, das Team selbst, unterhält. Vergessen wir nicht: Jedes Team, egal ob co-located oder verteilt auf den ganzen Planeten, macht nach -> Bruce Tuckman initial oder nach Teamänderungen mehr oder weniger intensiv die vier Phasen „Forming“, „Storming“, „Norming“ und „Performing“ durch.

Teambuilding-Phasen nach Tuckman

Teambuilding-Phasen nach Tuckman

Es macht sich bezahlt in diesen Teambuilding-Prozess aktiv einzugreifen und dabei zu helfen, das Team in die nächste Phase zu heben. Eine in meiner Praxis bewährte Methode sind teaminterne Diskussionen, unterstützt z.B. durch Metaplantechniken, in denen sich das Team zu folgenden Fragen austauscht:
    • Was erwarte ich – an Prozessen und Rahmenbedingungen?
    • Was kann ich einbringen – an Programmiersprachen, Requirements Engineering Techniken, im Test, etc.?
    • Wie sollten wir miteinander umgehen – Klärung zu Aspekten wie Fehlerkultur, Offenheit, usw.
Performing Team

Performing Team

Es hilft auch, wenn man den Team’s Vorträge über Konfliktbewusstsein anbietet oder auch in diesem Kontext auf Retrospektiven setzt: Nicht nur prozessual und arbeitstechnisch sich zu fragen, was läuft gut und „was wollen wir verbessern“, sondern auch nochmals einen Blick auf die Metaplan-Antworten und checken, ob das auch noch passt.

Für bewusstes Teambuilding muss man die Teambuilding-Phasen bewusst machen und Aktivitäten setzen, die die Team-Irritationen so gering wie möglich halten.

In einem Projekt vor einiger Zeit hatten wir z.B. immer bei Abstimmung- und Planungsterminen auch die Frage: „Wie geht es uns als Team?“ Ein fortschrittlicher Ansatz, wie gesagt, auch schon vor einiger Zeit gelebte Praxis.

Physical closeness -> Mental closeness
Eine weitere Methode um „Nähe“ zwischen den Teammitgliedern herzustellen, habe ich von Jürgen Apello („How to Improve Team Collaboration with Personal Maps“1) gelernt: Er empfiehlt verteilten Teams die Erstellung von sogenannten Personal Maps. Jeder erstellt eine Mindmap über sich selbst und thematisiert darin Hobbies, Ausbildung und weiteres Wissenswertes über sich. Im Anschluss stellt jeweils ein Teammitglied ein anderes auf Basis der Personal Map vor. Er adressiert damit eine mentale Nähe zwischen den Teammitgliedern …

Wir bei SEQIS stehen ebenfalls vor der Herausforderung, dass die einzelnen (organisatorischen) Teams bei jeweils unterschiedlichen Kunden im Einsatz sind – und trotzdem soll und muss der Teamspirit passen und die Zusammenarbeit in den Teams stimmen. Daher haben wir diese Methode bei unserem letzten 4-tägigen Geschäftsjahres-KickOff -Meeting im Selbstversuch ausprobiert. Im Gegensatz zu einer Skype-Session konnten wir das in einem gemeinsamen Meeting-Saal machen. Den konkreten Setup können Sie beiliegender Abbildung entnehmen. Ergebnis: This rocks – und wurde von nahezu allen SEQISANERN im Rahmen des Gesamtfeedbacks zum Treffen thematisiert.

Personal Map - Setup

Personal Map – Setup

Das war noch nicht alles…
Neben den oben stehenden Empfehlungen nachfolgend noch eine Sammlung zur Verbesserung der Kommunikation und zur Förderung von Nähe bei verteilten Teams und Teammitgliedern, die in meinen Projekten funktioniert haben:

  • Definition einer Team Charter (= Teamroadmap, Absicherung, dass alle auf das Richtige fokussiert sind) inkl. Rollen, Verantwortlichkeiten, Ziele und Art-und-Weise, wie gearbeitet wird
  • Strenge Kommunikationsstrategie: Besonders wichtig, wenn das Team in unterschiedlichen Zeitzonen beheimatet ist und unterschiedliche Sprachen spricht
  • Ordentlicher technischer Support: Videokonferenzen, Instant Messaging, VoIP, … sind super, wenn sie auch wirklich funktionieren
  • Genaue Beobachtung der Individual-Performance: Bei Veränderung des Outputs, geringerer Mitarbeit, etc. kann auch im Hintergrund ein Burnout oder anderes lauern. Denken Sie daran: Sie sehen die Kollegen nicht, nonverbale Kommunikation fällt nahezu flach
  • Schaffen Sie Raum für Gemeinsames: Setzen Sie eine Intranet-Teampage auf, verwenden Sie ggf. Webcams
  • Vergessen Sie nicht auf Feedback: Ein Kollege hat ins Projekt-Social Network einen interessanten Artikel gepostet? Geben Sie Feedback!
  • Belohnen Sie außergewöhnliche Leistungen: Etablieren Sie teaminterne Punkte-/Leistungssysteme und vergessen Sie nicht darauf, dass physische Belohnungen gerne durch Post und Co. rund um den Planeten geliefert werden

… diese Liste ist natürlich nicht abschließend!

Haben Sie weitere Empfehlungen? -> Ich freue mich auf Ihre Kommentare!

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

%d Bloggern gefällt das: