Die Istaufnahme - Wie kriege ich die Informationen, die ich brauche?



Zusammenfassung
Definition Istaufnahme
Wann ist eine Istaufnahme notwendig?
Was ist im Rahmen einer Istaufnahme aufzunehmen?
Wer wird befragt?
Methoden der Istaufnahme
Reihenfolge der Istaufnahme - Was wird zuerst aufgenommen?
Tücken der Istaufnahme - bewegte Ziele
Exkurs - kleine Katastrophen bei der Istaufnahme

vgl. auch Anforderungsanalyse, Entstehung eines Anforderungsdokuments und Inhalt eines Anforderungsdokument

google zu Istaufname, Istanalyse oder Istzustandsanalyse

Zusammenfassung

Auf dieser Seite werden die wesentlichen Maßnahmen dargestellt, die im Rahmen einer Istaufnahme für ein IT-Projekt notwendig sind. Dabei wird auf die typischen Situationen üblicher Umgebungen in Fachabteilungen eingegangen, insbesondere auf vorhandene Mischlösungen (Fachanwender arbeitet mit selbst geschriebenen Office-Lösungen) und die Frage, weshalb es u.U. unbezahlbar sein kann, rein manuelle oder Mischlösungen in einem IT-System komplett abzubilden. Situationsabhängige Informationsquellen und der Umgang mit bewegten Zielen werden angsprochen. Die Methodiken (z.B. Interview oder Workshop) finden sich im Abschnitt Benutzerkontakt.

Definition Istaufnahme

Die Istaufnahme beschäftigt sich mit dem vorhandenen Zustand eines Prozesses, bzw. auch einer Organisation oder eines Systems. Bei einer Istaufnahme nimmt man das auf, was gegeben und vorhanden ist. Nicht das, was war, und auch nicht das, was jemand will oder was mal sein soll oder was sich jemand vorstellt. Im Rahmen der Istaufnahme wird der gesamte Prozess, wie er stattfindet, samt eingehenden Informationen (oder allgemein Dingen) sowie samt erzeugten und ausgehende Ergebnissen dokumentiert. Dazu kommen fallabhängig noch andere wesentlich erscheinende Angaben, z.B. Häufigkeit und Frequenz des Vorgangs oder typische Fehlerquellen oder Risiken, die aus fehlerhaften Ergebnissen resultieren.

Ein guter Vergleich aus dem täglichen Leben ist ein Kochrezept in dem die Zutaten und Arbeitsschritte vom Rohmaterial bis zum fertigen Gericht im Detail dargestellt werden. Das Ergebnis kann durch ein Foto und eine Beschreibung ebenfalls dargestellt werden.

Alternative Bezeichnungen für die Istaufnahme sind auch Istanalyse und Istzustandsanalyse.

Wann ist eine Istaufnahme notwendig?

Eine Istaufnahme ist immer dann notwendig, wenn ein bereits existierendes Verfahren durch ein neues ersetzt werden soll. In diesem Fall ist die Istaufnahme die Vorstufe oder Teil der Anforderungsanalyse. Eine Istaufnahme ist nicht nötig und auch nicht möglich, wenn ein neues und noch nicht existierendes Verfahren erfunden und implementiert werden soll.

Dabei ist es gleichgültig, ob das existierende Verfahren rein manuell, ein vorhandenes IT-System oder eine Mischform ist.

Außerhalb der Software-Entwicklung (z.B. beim Rechenzentrumsbetrieb) werden Istaufnahmen i.d.R. dann notwendig, wenn vorhandene Prozesse nicht ausreichend dokumentiert oder nicht mehr nachvollziehbar sind und überarbeitet werden sollen.

Was ist im Rahmen einer Istaufnahme aufzunehmen?


Istaufnahme - Was wird aufgenommen?

Vorhandene IT-Systeme

Für vorhandene Prozesse gilt das EVA-Prinzip genau so wie für geplante Systeme. Folglich sind alle Datenquellen, Datensenken und Arbeitsabläufe zu sichten. In professionellen Organisationen mit einem funktionierenden Release-Management kann man erwarten, dass Dokumentationen vorhanden sind. Deren Vollständigkeit und Lesbarkeit ist jedoch eine andere Frage. Mindestens findet man i.d.R. technische Schnittstellenbeschreibungen zu anderen Systemen und grobe Tabellen-Beschreibungen von relationalen Datenbanksystemen, evtl. auch noch die Beschreibung von Datenbankprozeduren. Diese eher technischen Dokumente sind von Technikern geschrieben, und die haben meist keine literarischen und auch keine fachlichen Ambitionen. Ich will damit sagen, dass sich diese Dokumente weder gut lesen, noch dass sie auf die fachlichen Hintergründe oder das zu Stande kommen der Daten hinweisen. Dafür sind sie kurz und knapp, wenn sie aktuell sind, sind sie auch vollständig, und sie geben eine klare Richtung vor. Man kann sie als Anlage zur Fachspezifikation anfügen, tatsächlich gebraucht werden sie später von den Datenbank- und Softwaredesignern. Ob man diese Dokumente mit dem Fachanwender diskutieren will oder sie ihm nur zeigen will, hängt sehr vom Einzelfall ab. Wenn der Fachanwender keinerlei IT-Kompetenz hat und darüber hinaus noch sehr lösungsfixiert ist, ohne sich um das gegebenen Problem kümmern zu wollen, kann man davon absehen.

Es lohnt sich auf jeden Fall, ein aktuelles ERM (Entity Relationship Model) erzeugen zu lassen und gegen die vorhandene alten Dokumentation abzugleichen. Als Faustregel kann gelten: Wenn das ERM mit der Altdokumentation überein stimmt, hat man gute Karten. Entweder wurde über die Jahre nichts geändert, oder die Dokumentation wurde auf dem neuesten Stand gehalten. Der DB-Admin weiß das. Wahrscheinlich ist auch noch eine alte Spezifikation zu kriegen, ziemlich sicher ein high level Design-Dokument.

Die nächste Frage ist dann, ob laufende Änderungen auch dokumentiert wurden. Die Erfahrung zeigt, dass dies nicht immer der Fall ist. Zwar mag die Version 1.0 eines Produkts vollständig spezifiziert worden sein, ein Blick in die alten Benutzerhandbücher zeigt jedoch nicht selten, dass bereits in der ersten Version funktionale Abweichungen von der Spezifikation umgesetzt wurden. Das liegt daran, dass während der Entwicklung festgestellt wird, dass die Spezifikation nicht vollständig war. Änderungen werden dann ad hoc eingebracht und gar nicht oder im Rahmen eines change request dokumentiert. Somit ist klar, wo man als nächstes suchen muss: Irgendwo, meist in einem verstaubten Ordner, sind die frühen change requests zu finden.

Unbedingt angezeigt ist ein Besuch beim Fachanwender. Fachanwender finden sich nicht selten in der Situation, dass sie irgendwie Informationen in ein IT-System hinein bringen müssen, die Verwaltung dieser Information aber nicht möglich ist. Sie definieren dann eigenmächtig einen Workaround, mit dem sie leben können und der nicht an die IT-Abteilung kommuniziert wird. Solche Informationen sind nirgendwo oder bestenfalls zufällig dokumentiert und fallen nur dann auf, wenn sie nachfolgende Prozessabläufe stören. Erfahrungsgemäß beginnt der stillschweigende Missbrauch eines Systems bereits wenige Wochen nach der Einführung. Eine Datennachanalyse kann also angezeigt sein, wobei besondere Anomalien in der statistischen Verteilung verdächtiger Daten, vorwiegend Pflichteingaben, gesucht werden sollten.
Beispiel aus der Praxis

Gerne zitiertes Beispiel, das im Rahmen der Y2K-Projekte mehrfach entdeckt wurde, ist der freizügige Gebrauch von Datumsfeldern. Eine Applikation, die als Pflichteingabe an einer bestimmten Stelle ein Tagesdatum (z.B. Geburtsdatum) verlangt, wird auch eines kriegen, auch wenn der Anwender keines hat. Damals war das Datum 9.9.99 als Füller oder Platzhalter sehr populär.

Gewachsenes IT-System / Mischungen mit manuellen Prozessen / halbautomatische Prozesse

Rein manuelle Systeme existieren heutzutage kaum noch, da verschiedene Office-Lösungen Tabellen-Kalkulations-Systeme oder kleine Datenbanken inkludiert haben, die vom Anwender selbst zum Bau von Lösungen benutzt werden können.

Istaufnahme - halbautomatischer Prozess

Kaum ein Anwender ist sich dabei jedoch darüber im Klaren, dass er selbst Software entwickelt. Die Konsequenzen sind häufig bitter: Da nicht erkannt wird, dass Software entwickelt wird, werden auch minimale Qualitätsstandards nicht eigehalten. Weder wurden die Anforderungen spezifiziert (sie ergeben sich aus den Arbeitsabläufen), noch wird die Lösung dokumentiert (der Anwender hat alles im Kopf), noch einem strukturierten Test unterzogen (man probiert es in der Produktivumgebung aus), noch gibt es irgendeine Form der Versionskontrolle (meist läuft nur die aktuelle Version in mehreren Instanzen bei verschiedenen Anwendern, der Code wird fortwährend weiter entwickelt). Die Anwendungen sind i.d.R. auch nicht sicher sondern anfällig gegen Fehlbedienungen, sodass gravierend falsche Ergebnisse geliefert werden können; gelegentlich eine kostspielige Angelegenheit. Da die Anwender jedoch um die Schwächen des Systems wissen, passiert selten etwas und die Systemschwächen fallen kaum auf. Die Software lebt und stirbt mit der Verfügbarkeit des Anwenders. Verlässt der Anwender das Unternehmen, so stirbt die Software-Lösung, die u.U. über Jahre hinweg gewachsen ist. Zudem gibt es häufig noch Interaktionen mit anderen IT-Systemen, die nicht kontrolliert werden.

Beispiel aus der Praxis

In einem Großunternehmen hatte ein Anwender mit MS Excel und MS Access eine mehrschrittige Lösung im Laufe von ca. zwei Jahren aufgebaut, die notwendig war, um die anfallenden Geschäfte zu bewältigen. Über eine Programmierschnittstelle interagierte ein Teil dieser Lösung mit einer Host-Anwendung, indem sie Bildschirminhalte auslas und Tastatureingaben simulierte. Ein anderer Teil dieser Lösung interagierte mit einer speziellen gekauften Client-Software, die eine Datenschnittstelle anbot. Dazwischen mussten mehrere manuelle Arbeitsschritte erfolgen wie z.B. das Aushaken von Belegen gegen eine Kontrollliste. Da die Lösung nicht dokumentiert war, wusste das Pflegeteam der Host-Anwendung nicht, welche Bildschirmmasken es ohne weiteres verändern durfte und welche nicht. Änderte sich die Client-Software, so war nicht nachvollziehbar, ob die Datenschnittstelle noch stimmte. Ad hoc-Anpassungen waren an der Tagesordnung. Ein besonderes Risiko lag darin, dass der Prozess relativ zeitkritisch war und i.d.R. mehrfach pro Stunde abgearbeitet werden musste, und dass dabei erhebliche Geldsummen im Spiel waren. - Die Nachdokumentation wurde von einem externen Mitarbeiter binnen zwei Wochen erledigt, wobei erstmals nachvollziehbar die betroffenen  Host-Programme und die Geschäftsabläufe dargestellt wurden.
Man sollte hierbei nicht verkennen, dass solche Lösungen von engagierten Mitarbeitern gebaut werden und in vielen Organisationen unumgänglich sind, da sonst der normale Geschäftsbetrieb zusammenbrechen würde. Aus diesem Grund werden solche Lösungen von der IT-Abteilung meist stillschweigend geduldet und vor dem Qualitätsmanagement verschwiegen. Für einen Business Analysten, der über solche Lösungen stolpert, bedeutet dies, dass er sich mit Belehrungen über QM zurückhalten sollte, damit das Engagement des Mitarbeiters am Ende nicht bestraft wird. Vielmehr kann angestrebt werden, dass die Lösung in den QM-Prozess integriert wird, was jedoch bei sehr großen und starren Organisationen häufig ein aussichtsloses Unterfangen ist.

Solche gewachsenen Systeme sind sehr typisch für kleine Unternehmen, in denen noch fast jeder jeden kennt. Man findet sie ebenfalls häufig in Großunternehmen, dort aber nur in relativ kleinen Abteilungen mit höchstens zwei Dutzend Leuten. Für die Abbildung in ein neues IT-System gelten bzgl. der Machbarkeit dieselben Überlegungen wie bei den im nächsten Abschnitt besprochenen rein manuellen Lösungen: es gibt möglicherweise sehr gute Gründe, weshalb es bislang noch keine saubere IT-Lösung gibt, es ist nicht auszuschließen, dass eine saubere Lösung sehr teuer oder unbezahlbar ist.

Die Istaufnahme von gewachsenen IT-Lösungen und deren Verquickung mit manuellen Arbeitsprozessen wird i.d.R. auf Basis von Interviews mit dem Anwender, der die Lösung gebaut hat, stattfinden. Dies geschieht am besten in oder in der Nähe der gewohnten Arbeitsumgebung des Anwenders, wobei die Lösung teilweise vorgeführt wird. Dazu werden Code-Walkthroughs und selbstständige Code-Analysen durch den Business Analysten notwendig werden. Die technischen Lösungen müssen also zunächst dokumentiert werden. Ein reiner Fach-Mann bzw. eine reine Fach-Frau ohne fundierte IT-Kenntnisse hat hier in der Rolle des Business Analysten schlechte Karten. Um nun den kompletten Geschäftsprozess zu erarbeiten, ist der einfachste Weg so gut wie immer das Beobachten des Fachanwenders bei der Arbeit, bei dem die manuellen Arbeitsschritte nachvollzogen und dokumentiert werden. Die Eingaben und das Wissen des Fachanwenders kann hier im weiteren Sinne als Datenquelle definiert werden.

Anders gelagert ist die Istaufnahme, wenn der verantwortlichen Anwender nicht mehr verfügbar ist. In diesem Fall setzt meist ein anderer Anwender die Arbeit seines Vorgängers fort, der alte Kollege ist noch telefonisch erreichbar, und der Business Analyst wurde genau aus diesem Grund angefordert. Zunächst sollte man sehen, wie weit man mit dem Nachfolger kommt. Sofern es sich einrichten läßt, kann man selbst Kontakt mit dem Vorgänger aufnehmen und evtl. ein informelles Treffen vereinbaren. Die manuellen Prozesse, die den automatisierten Teillösungen zu Grunde lagen, kennt der Nachfolger häufig nicht mehr. Der Analytiker muss sich also bei allen Anwendern, die das Produkt benutzen, durchfragen; hier kann auch ein Workshop sinnvoll sein.

Manuelle Prozesse

Rein manuelle Prozesse kommen heute nur noch selten vor. Man findet sie noch häufig im öffentlichen Dienst oder vergleichbaren Strukturen, allerdings auch in Marketing- und Vertriebsabteilungen. Im öffentlichen Dienst finden sich immerhin Vollzugsvorschriften und Gesetze, die sagen, was zu tun ist. Der Arbeitsablauf, also das Wie, ist den Mitarbeitern der Behörden überlassen. Als Auftraggeber sollte man ich keinen Illusionen hingeben: Bei komplexen Abläufen wird es lange dauern und teuer werden.

Komplexe rein manuelle Prozesse zeichnen sich i.d.R. durch mehrere der folgenden Punkte aus:
Beispiel aus der Praxis

Der Gesetzgeber ändert seine Meinung im Hochschulbereich etwa einmal pro Jahr. Konkret heißt dies, dass der zugehörige Verwaltungsakt regelmäßig angepaßt werden muss. Dasselbe gilt natürlich für ein IT-System. Darüber hinaus behalten jedoch häufig noch die alten Regelungen weiter Gültigkeit. Landesweit betrachtet schreibt der Gesetzgeber zudem nur vor, was die Hochschulen zu tun haben. Wie die Hochschulen die Vorgaben erfüllen ist ihnen selbst überlassen. Über die Jahre hat sich also je Hochschule ein eigener Weg etabliert, wie der Vollzug der Vorschriften stattfindet. Typischerweise gibt es also je Hochschule einen eigenen Satz Bescheide und die Benutzer-Rollen sind verschieden. Einige seltene Studiengänge weisen Besonderheiten auf, die unique sind, manche Studiengänge gibt es nur an einer einzigen Hochschule. Eine Vereinheitlichung der Verfahren rund um Studentenverwaltung und insbesondere bei der Prüfungsorganisation ist also nicht machbar. Nur wenige Hochschulen haben dank der Initiative einiger Mitarbeiter der IT-Abteilungen eigene brauchbare Verfahren entwickelt, die jedoch von Semester zu Semester immer wieder angepaßt werden müssen. Eine landesweite Lösung wird seit Mitte der achtziger Jahre angestrebt.

Im Fallbeispiel wurde in den frühen achtziger Jahren eine Istaufnahme der Vorgänge im Prüfungsamt einer Fachhochschule durchgeführt, für die zwei Mitarbeiter des zuständigen Landesamtes für Statistik und Datenverarbeitung eineinhalb Jahre beschäftigt wahren. Nur wenige Jahre später war das erarbeitete Dokument, ein mehrere hundert Seiten umfassender Ordner, wertlos, da eine neue Studienordnung eingeführt wurde.
Als Faustregel gilt: Je länger eine Istaufnahme dauert, um so zweifelhafter ist deren Erfolg, denn um so höher ist die Wahrscheinlichkeit, dass sich das Ziel bewegt (im IT-Jargon spricht man dabei von einem moving target). In Wirtschaft und Industrie ist es u.U. möglich wenn auch nicht wahrscheinlich, den Auftraggeber soweit zu kriegen, dass er für die Dauer der Entwicklung eines Systems keine gravierenden Änderungen veranlasst, im öffentlichen Dienst ist dies jedoch unmöglich.

Sofern der Kunde nicht einige Zeit still halten kann, sollte er sich überlegen, ob es nicht besser ist, das vorhandene manuelle Verfahren beizubehalten und durch qualitätssichernde Maßnahmen zu verbessern, und dafür die Ausgaben für den Business Analyst und den Versuch der Implementierung eines IT-Systems anderweitig zu verwenden. Evtl. kann auch erwogen werden, das vorhandene System komplett zu "zerschlagen", um es durch ein reformiertes neues zu ersetzten. Der Erfolg einer solchen Maßnahme sollte jedoch sicher gestellt sein, ehe man aktiv wird, und man muss sich darüber im Klaren sein, dass man bei den Mitarbeitern der betroffenen Organisation nicht auf Gegenliebe stossen wird. Ich spreche hier wohlgemerkt von sehr komplexen Systemen, deren Realisierung teuer wird oder schon dem Augenscheine nach scheitern kann oder die schon mehrere gescheiterte Versuche hinter sich haben. Man sollte sich als Auftraggeber hier auch nicht dem Gesetz der konsequenten  Fehlinvestition hingeben, das ich einmal entdeckt habe: Der Glaube, dass ein Geschäft oder ein System profitabel wird, wenn man nur immer mehr Geld hinein investiert, kann ein teurer Irrtum werden.

Dass eine Organisation ohne IT-Unterstützung arbeitet ist spätestens seit Mitte der neunziger Jahre kein zufälliges Ereignis. Die Frage der Abbildung eines komplexen rein manuellen Systems in einem IT-System ist nicht, ob es möglich ist, sondern ob es bezahlbar ist.

Bei komplexen rein manuellen Prozessen führen meist viele kleine Schritte zum Ziel. Zunächst sollte versucht werden, den gesamten Prozess in isolierbare Komponenten zu zerlegen, wobei folgende Parameter gemessen werden:
  1. Änderungsaufwand: Der Prozess ist wenig anfällig für Änderungen, d.h. Änderungen können leicht umgesetzt werden.
  2. Änderungshäufigkeit: Änderungen treten selten auf. Es ist absehbar oder doch wahrscheinlich, dass sich das System während der Entwicklungszeit des Gesamtsystems nicht und später nur selten ändert.
  3. Bedienungsaufwand: An den Schnittstellen ist möglichst wenig Datenerfassungsarbeit notwendig.
Der zweite Punkt ist insofern von Bedeutung, als sonst Entwicklerkapazitäten für Pflegearbeiten gebunden werden. Die Komponenten, für die alle drei Parameter günstig sind, werden vorrangig implementiert. In einem nächsten Schritt kommen dann die Komponenten dran, die noch Punkt 1 und 3 erfüllen und erst zuletzt der Rest.

Auf dem Weg zum Ziel kommt man um sehr intensiven Benutzerkontakt gar nicht herum, häufig ist die direkte Mitarbeit beim Endanwender notwendig, aber man wird den Anwender immer wieder bei der Arbeit beobachten müssen. Workshops und Interviews, vor allem mit Leuten aus der Führungsebene, die meist keine Ahnung davon haben, was die Leute weiter unten genau machen, können zu Beginn der Analyse sinnvoll sein, um sich einen Überblick zu verschaffen, sind aber nach der Einstiegsphase kein geeignetes Mittel mehr, um an Informationen zu kommen. Dafür können später Workshops veranstaltet werden, um die Führungsebene einerseits über die Fortschritte der Istaufnahme auf dem Laufenden zu halten und ihnen andererseits wieder die Arbeit ihrer Mitarbeiter näher zu bringen und Verständnis für die Komplexität des Gesamtablaufs zu schaffen.

Ehe ein System in einem Computer funktionieren kann, muss es auf dem Papier funktionieren. Die Arbeitsabläufe sind also im Detail zu dokumentieren. Ein guter Schritt kann sein, dass man Arbeitsvorschriften für die Mitarbeiter erarbeitet und zunächst eine Art Qualitätshandbuch schreibt, an die sich die Mitarbeiter ausnahmslos halten. Diese Arbeitsvorschriften werden dem einzelnen Mitarbeiter natürlich nicht aufs Auge gedrückt, denn zumindest in erster Näherung werden sie falsch sein. Vielmehr wird der Analytiker mit Unterstützung der Abteilungsleitung die Mitarbeiter bitten, diese Abläufe nachzuvollziehen und umzuschreiben bzw. zu ergänzen, wenn sie nicht ausreichen. Da die Vorschriften auch Schnittstellen zu anderen Mitarbeitern und deren Arbeitsvorschriften beinhalten, bleibt es den Leuten selbst überlassen, die Schnittstellen anzupassen. Die Häufigkeit und der Zeitpunkt der Änderungen wird dokumentiert und die (natürlich) ungenauen Änderungen der Mitarbeiter werden eindeutig und korrekt umformuliert. Solange die Anzahl der Änderungen noch steigt, sind die Beschreibungen der zu spezifizierenden Geschäftsprozesse noch weit von der Vollständigkeit und Korrektheit entfernt, die für die Entwicklung eines IT-Systems notwendig ist. Erst wenn die Häufigkeit der Änderungen zu sinken beginnt und eine gewisse Statik erkennbar ist, die fixiert werden kann, ist ein Erfolg in Sicht. - Hier sind direkte Investitionen des Business Analysten gefragt, z.B. ein Stück Kuchen je gefundenem Fehler.

Wenn sich das Ziel bewegt, dann ändern sich die Vorgaben und somit müssen auch die Arbeitsvorschriften angepasst werden. Auch hier zeigt die Zahl der Änderungen auf, welche Prozesse resistent gegen Änderungen sind, und welche besonders anfällig. Durch diese Messung können die oben aufgezählten Parameter Änderungsaufwand, Änderungshäufigkeit und Bedienungsaufwand schon weit im Vorfeld der Implementierung eines IT-Systems abgeschätzt werden. Dies ist wesentlich für eine langfristige Abschätzung der Wartungskosten des Systems und auch ggf. für die Entscheidung gegen ein vollständiges IT-System. U.U. kann auch schon die Einführung von Teillösungen hilfreich sein.

Die Rolle des Anwenders

Prozesse und IT-Systeme existieren nicht für sich sondern sind in eine menschliche Umgebung eingebettet. Nicht umsonst stellen sehr viele IT-Spezialisten immer wieder ironisch fest, dass der Fachanwender nur den Betrieb stört.

Für jeden Prozess, egal ob manuell, gemischt oder reines IT-System , muss erfasst werden, welche Rechte, Möglichkeiten und Entscheidungsbefugnisse der Fachanwender hat. Man spricht dabei von der Rolle des Anwenders ("user role").
Beispiel

Bei den Finanzbehörden haben bestimmte Mitarbeiter das Recht, Daten zur Steuererklärung eines Steuerpflichtigen zu erfassen. Die Vorgesetzten dieser Mitarbeiter können dagegen diese Daten nur lesen, nicht jedoch eigenmächtig ändern.

Wer wird befragt?

Es lohnt sich nicht Leuten Fragen zu stellen, von denen man weiß, dass sie weder die Antworten kennen noch Leute kennen, die die Antworten kennen, noch Leute kennen, die Leuten kennen könnten, die Antworten kennen. Übertragen auf die bereits dargestellten Punkte, die aufgenommen werden müssen, bedeutet dies:

Vorhandene IT-Systeme: Erste Ansprechpartner sind der Qualitätsmanager und der Release Manager, um an die vorhandene Dokumentation zu kommen. Beide wird man in kleinen Unternehmen vergeblich suchen, aber dort kennt ohnehin jeder jeden, und in großen Unternehmen wird man zumindest von einem Besuch beim Qualitätsmanager abraten. Gerade bei Großunternehmen werden gerne Zuständigkeiten im Kreise geschoben oder aus formalen Gründen boykottiert (z.B. noch kein Projekt für das Controlling aufgesetzt; vgl. z.B. Controlling-Paralyse bei Schwierige Kunden, Situationen und Menschen). Wichtig ist ein Besuch beim Fachanwender, um festzustellen, ob er auch die Version nutzt, deren Dokumentation man bekommen und, und ob er die Anwendung auch so nutzt, wie sie gedacht ist.

Gewachsenes IT-System / Mischung mit manuellen Prozessen: Erster Ansprechpartner ist der Fachanwender, der die Lösung gebaut hat und betreut. I.d.R. kennt er auch die manuellen Zwischenschritte.

Manuelle Prozesse: Erster Ansprechpartner ist der Abteilungsleiter bzw. Ressortleiter. Dieser kann aber im Normalfall nur eine Übersicht über die Prozesse vermitteln, die Details kennt er nur in Ausnahmefällen. Ansprechpartner für Prozessdetails sind alle Fachanwender, die die Arbeit selbst machen.

Generell gilt, dass die Leute, die im Tagesgeschäft die Arbeit machen, auch die notwendigen Informationen haben. Es lohnt also i.d.R. nicht, sich mit dem Management zwei Ebenen höher über Detailfragen auseinander setzen zu wollen. Der direkte Umgang mit den Leuten, die die Arbeit machen, kann jedoch bei manchen Vorgesetzten auf Widerstand stossen. Dies kann z.T. absurde Formen annehmen, z.B. ein Verbot, mit dem Fachanwender direkt zu kommunizieren. Sofern sich derartige Widerstände nicht auflösen lassen, bleibt nur der Weg über den Vorgesetzten. Der Analytiker stellt ihm die Fragen und setzt klare Termine im Rahmen des Projektplans.

Nur, weil jemand etwas nicht weiß, ist das noch kein Grund, aufzugeben. Seit den sechziger Jahren des zwanzigsten Jahrhunderts geht man davon aus, dass jeder Mensch jeden um sechs Ecken kennt, d.h. man kennt jemanden, der jemanden kennt, der jemanden kennt, der jemanden kennt, der jemanden kennt, der die Zielperson kennt. Man muss nur lange genug weiter fragen und sich durchfragen.

Methoden der Istaufnahme

Vgl. hierzu Benuterkontakt - Interaktion, Kommunikation und Fragetechnik

Zur Anwendung kommen die üblichen Kommunikationstechniken, Beobachtung des Endanwenders, Interview, Workshop und informelle Treffen sind der Normalfall, die Mitarbeit beim Fachanwender ist die Ausnahme.

Bei einer Istaufnahme werden im Gegensatz zur Anforderungsanalyse existierende Prozesse untersucht und dokumentiert. Somit kann jede Beschreibung gegen den physikalisch vorhandenen und greifbaren Istzustand verglichen werden, ein pragmatischer Beweis für die Korrektheit und Vollständigkeit eines beschriebenen Prozesses ist jederzeit möglich. Diskussionsbedarf oder Interpretationen ein und desselben Prozesses sind nur selten gegeben und können grundsätzlich zügig zu einem Konsens gebracht werden. Zeitlich ist die Istaufnahme eines vorhandenen Systems meistens schneller möglich, als die Anforderungsanalyse eines vergleichbaren und noch zu definierenden Systems. Die aufwendigen Ausnahmen sind normalerweise große und alte IT-Systeme, die über Jahre gewachsen aber niemals dokumentiert worden sind.

Reihenfolge der Istaufnahme - Was wird zuerst aufgenommen?

Stepwise Refinement

Dieser neudeutsche Begriff wird innerhalb der IT vor allem im Rahmen der strukturierten Programmierung bzw. dem Ausprogrammieren von Methoden innerhalb eines Objekts benutzt und darf direkt ins Deutsche als Technik der schrittweisen Verfeinerung übertragen werden. Dabei werden zunächst als Schritt des Software-Designs lediglich Funktionsschnittstellen und Aufrufe geschrieben, die nach und nach ausprogrammiert werden, wenn die vorgesehende Funktionalität als logischer Ablauf fest steht. Einer der Vorteile des Verfahrens besteht darin, dass redundante Codeteile frühzeitig identifiziert und zusammen gefasst werden können.

Das Verfahren lässt sich fast unverändert auf einen Analyseprozess auch bei der Istaufnahme übertragen. So kann z.B. der Weg vom Eingang einer Bestellung bis zum Versand zunächst nur als ein einziger großer Prozess angesehen werden, der nach und nach untergliedert wird und dessen irreguläre Randbedingungen (z.B. Reklamationsbearbeitung, Rücksendung, Bonitätsprüfung bei Neukunden) ebenfalls identifiziert werden. Irgendwann sind schließlich die Teilprozesse soweit dokumentiert, dass die hohe bzw. strategische Sicht klar wird und der einzelne Prozess im Detail dargestellt werden kann.

Dies ist eine ideale Reihenfolge, denn dabei werden häufig wie auch in der Programmierung Arbeitsschritte erkannt, die von verschiedenen Mitarbeitern unnötig mehrfach vollzogen werden.

In der Praxis lässt sich dieses Verfahren im Gegensatz zur Programmierung bei der Analyse nur selten strikt durchhalten. Da sich eine Istaufnahme im Gegensatz zu einer Anforderungsanalyse aber mit einem zumindest relativ statischen Vorgang beschäftigt ist es nicht kritisch, wenn ein identifizierter Teilprozess zwischendurch oder sofort im Detail dokumentiert wird, vorausgesetzt, dass dessen Relevanz für das noch zu planende IT-System auch sicher ist.

Teilprozesse

Teilprozesse finden nicht unabhängig von einander statt sondern in einer im Rahmen des Gesamtprozesses definierten Reihenfolge. Am Ende muss jeder Prozess als Teilprozess des gesamten Systems dargestellt sein. Insofern sollte man meinen, dass sich eine natürliche Reihenfolge für die Prozessanalyse ergibt. Diese Reihenfolge ist jedoch praktisch kaum einzuhalten. Einerseits kennt der Analytiker zu Beginn seiner Analysetätigkeit  noch nicht alle Prozesse, die tatsächlich berücksichtigt werden müssen. Andererseits ist es eine Frage der Verfügbarkeit der zu befragenden Personen, wann ein Prozess bearbeitet werden kann. Gelegentlich teilt sich auch ein Prozess und hat mehrere definierte und parallel statt findende Folgeprozesse, die nur nacheinander analysiert werden können. Wünschenswert ist dennoch, dass die Einzelprozesse nicht als Puzzelspiel betrachtet werden, sondern soweit möglich ganze Prozessketten analysiert werden.

Die Ausgaben des einen Prozesses sind die Eingaben des anderen und Schnittstellen sind einerseits stets kritsich, andererseits definierte und statische Übergabepunkte, die als Anker oder Wegmarkierung benutzt werden können. Der normale Fachanwender gibt proaktiv keine vollständigen Informationen im Sinne der IT preis, und bei der Untersuchung eines Prozesses wird die Frage nach fehlenden Daten nicht selten mit einem "dann frage ich beim Kollegen [aus dem Vorgängerprozess] nach" beantwortet. Bearbeitet man Prozessketten, so ist die Analyse beim Vorgänger noch frisch in Erinnerung. Er tut sich leichter, die Rückfrage einzuordnen und gibt erfahrungsgemäß noch weitere wichtige Auskünfte zu anderen Prozessausnahmen und -alternativen.

Wie es bei der expliziten Betrachtung eines einzelnen Prozesses Alternativen und Ausnahmen gibt, gibt es auch Prozesse, die nicht im Geradeausflug auftreten. Diese zu erkennen erfordern entweder gründlichere und detailiertere Sachkenntnis als sie der Fachanwender hat, und dies ist bei kaum einem Business Analysten der Fall, oder gesunden Menschenverstand. Häufig hilft auch Allgemeinbildung.
Beispiel aus der Praxis

Als ich in meinem ersten Job an der Fachhochschule München die Studentenverwaltung auf EDV umstellte, war irgend wann die Exmatrikulation als Prozess dran. Ich kam in meiner damaligen Unerfahrenheit nur durch einen Zufall dahinter, dass auch der Tod eines Studenten zur Exmatrikulation führt. Normalerweise werden bei der Exmatrikulation Bescheid und Unterlagen an den früheren Studenten geschickt, bei verstorbenen Studenten wurden jedoch die nächsten Angehörigen benachrichtigt. Diese Ausnahme bei der Anschrift hatte wiederum Auswirkungen auf den Bescheid. Eine andere Ausnahme war, dass die Anschriften der erfolgreichen Abgänger des Studiengangs Architektur an die zuständige Kammer weiter geleitet wurden.

Einzelprozesse

Wie bereits erwähnt folgt jeder Prozess dem EVA-Prinzip - Eingabe, Verarbeitung und Ausgabe. Um diese Forderung zu erfüllen, muss natürlich für eine hinreichend feine Granulierung der Teilprozesse im Rahmen der Geschäftsprozessanalyse gesorgt werden. Der normale Fachanwender freundet sich mit solch einer Sicht nicht gerne an. Seine spontanen fachlichen Interaktionen mit Kollegen oder die spontane Konsultation anderer Datenquellen können als wechselwirkende Teilprozesse innerhalb eines Netzwerks verstanden werden. Die normalerweise nicht sehr digitale Sicht des Fachanwenders ist meist, dass er nur einen Prozess durcharbeitet. Als Analytiker sollte man den Fachanwender nicht mit IT-Philosophie überfordern und das Thema nicht unnötig breit treten, sondern ganz einfach seine Arbeit machen und den betrachteten Prozess nach den Notwendigkeiten der IT in klar abgrenzbare Teile aufbrechen.

Beim Einzelprozess ist das sichtbare Ergebniss am leichtesten greifbar, oder, wenn der Vorgängerprozess und dessen Ausgangsdaten bereits bekannt sind, dessen Eingangsdaten. Die Erklärungen von Fachanwendern, die nicht jahrelanges Training und Praxis in der Strukturierung von Wissen haben, reichen in den seltensten Fällen aus, um Funktionen oder Regelwerke zu definieren, die aus den Eingabedaten die gewünschten Ausgabedaten erzeugen. Insofern kann die Geschäftsprozessanalyse als eine Art investigativer Prozess begriffen werden, bei dem aus den in der Theorie vollständig aber in der Praxis nur teilweise kommunizierten und bekannten Eingabedaten, Verabeitungsschritten und Ausgabedaten ein vollständiges Bild rekonstruiert wird. Letztendlich ist es daher unvermeidbar, an allen drei Ansatzpunkten gleichzeitig zu arbeiten, wobei als Grobrichtung zuerst die erzielten Ergebnisse (Ausgabe), dann ein Eingangsdaten und dann der Arbeitsprozess selbst meist die einfachste Reihenfolge darstellen. Auch wenn der zu betrachtende Einzelprozess, z.B. die Tätigkeit eines Fachanwenders, in weitere Teile zerlegt werden muss, kann man sich an diese Regel halten und die eingehenden Informationen in den ersten und die ausgehenden Ergebnisse aus dem letzten Teilschritt zuerst betrachten.
Beispiel aus der Praxis

Im Rahmen eines Arbeitsprozesses wurde ein Anschreiben erzeugt. Der Analytiker fragte beim Fachanwender nach, woher die Anschrift käme. Der Fachanwender verwies auf einen Personalakt. Die nächste Frage war, woher der Fachanwender wisse, dass genau dieser Personalakt zu bearbeiten war. Der Fachanwender legte dann eine mehrere Zentimeter dicke Druckliste mit einer fünfstellilgen Zahl von zu bearbeitenden Personen vor, die ausgehakt wurde und die nebenbei auch die Anschrift enthielt. Auf die Frage, woher die Liste käme, bekam der Analytiker die Auskunft, dass diese aus einem Rechenzentrum geliefert würde. Somit waren Teile der Eingangs- und Ausgangsdaten geklärt. Gleichzeitig wurde ein verborgener Prozess offenbar, denn irgendwie mussten ja die Daten auch ins Rechenzentrum gekommen sein, um die Liste zu erzeugen. Ebenso wurde eine Ausnahme des Prozesses aufgedeckt, nämlich der Umgang mit unterschiedlichen Adressen auf Liste und Personalakt, also Daten-Inkonsistenzen und deren Bereinigung. Im konkreten Fall wurde auch geklärt was passiert, wenn der Personalakt nicht gefunden wurde, der Prozess war für die vorgesehene Umstellung auf Software jedoch nicht relevant.
Daten sind greifbarer als Prozesse, denn sie können explizit betrachtet werden. Man kann soz. mit dem Finger drauf deuten und fragen, woher eine bestimmte Information kommt bzw. was damit gemacht wird. Das normale Ergebnis kann ein Fachanwender i.d.R. ebenso ohne weiteres vorlegen, wie die dazu notwendigen normalen Eingangsdaten. Der normale Weg dorthin, der zugehörige Verarbeitungsprozess, kann meist auch noch recht zügig nachvollzogen werden. Man sollte jedoch nicht von einem Fachanwender erwarten, ohne weitere Rückfrage mehr als den normalen Geradeausflug darzustellen. Hierzu gehört der Umgang mit inkonsistenten und unvollständigen Daten sowie die Behandlung von bestimmten Datenkombinationen bzw. Datenkonstellationen, die besondere Maßnahmen erforderlich machen. Gerade hier ist der Business Analyst gefragt.

Tücken der Istaufnahme - bewegte Ziele

Von einem bewegten Ziel bzw. einem Moving Target spricht man in der Informatik, wenn sich die Anforderungen an ein System verändern, während das System noch gebaut wird. Moving Targets sind generell als Projektrisiko zu klassifizieren.

Von einem Fachanwender kann ein IT-Spezialist kein Verständnis dafür erwarten, dass sich eine Anforderung nicht einfach so umsetzten lässt. Für die Betrachtung der Komplexität gilt dasselbe: was dem Fachanwender simpel erscheint, kann beim IT-Spezialisten zu Haarausfall führen. Anders herum passiert dasselbe: ein Wunsch, den ein Fachanwender sich wegen der scheinbaren Komplexität nicht zu äußern wagt, kann ohne nennenswerten Aufwand realisiert werden. Etwas locker formuliert ist das wie mit kleinen Kindern die vor Autos laufen, da sie noch keine Vorstellung davon haben, dass ein Auto einen Bremsweg hat und nicht in voller Fahrt sofort anhalten kann. Das Fehlverhalten hat in beiden Fällen gravierende Folgen.

Bei der Feststellung des Istzustands ist ein bewegtes Ziel jedoch immerhin ein definiertes Ziel, denn man hat auch auf der IT-Seite die Gewissheit, dass es existiert. Insofern ist keine zu demotivierende Wirkung auf das Entwicklungsteam zu erwarten. Mit einer u.U. deutlich verlängerten Analysephase muss jedoch gerechnet werden, denn der Analytiker stellt ja nicht nur einen vorhandenen Zustand fest sondern muss auch die möglichen Veränderungen dieses Zustandes dokumentieren.

Wenn man mit beweglichen Zielen im Rahmen einer Istaufnahme zu tun hat, ist folgende Frage vordringlich zu klären: Handelt es sich lediglich um quantitative Veränderungen, also um Veränderungen, die durch einen Algorithmus erfasst werden können, oder um qualitative Veränderungen, also Veränderungen, die eine Anpassung oder Anpassungsfähigkeit des Algorithmus notwendig machen?

Quantitative Veränderungen zeichnen sich dadurch aus, dass die Veränderungen und deren Auswirkungen langfristig und sicher prognostizierbar sind.
Beispiel aus der Praxis

Ein Auftraggeber wollte einen einheitlichen Produktkatalog für die verschiedensten Produkte von einigen hundert Herstellern implementiert sehen, der nach variablen Kriterien durchsucht werden sollte. Die Istaufnahme der Produktpalette zeigte, dass die Palette von Türgriffen bis zu Kühlschränken reichte, das Mengengerüst ging von ca. einer halben Million verschiedenen Produkten aus, die sich in einige Tausend Produktgruppen strukturieren ließen. Bereits nach erster Sichtung war klar, dass sich die Produkte einerseits nicht in ein standardisierbares Schema packen ließen, andererseits jederzeit damit gerechnet werden musste, dass neue Produkte hinzu kommen. Eine laufende Änderung der Datenbank und Software kam nicht in Frage. - Die Lösung hierfür liegt auf der Hand: Der Anwender konnte am Ende selbst Produktgruppen und hierzu suchbare numerische Merkmale (die später durch Auswahllisten ergänzt werden sollten) definieren, wobei die Merkmale Produktgruppen-abhängig Namen bekamen, die dynamisch auf allen betroffenen Bildschirmformularen angezeigt wurden..
Qualitative Veränderungen zeichnen sich durch das Gegenteil aus, weder sind sie prognostizierbar noch lassen sich Auswirkungen festlegen. Hier ist der öffentliche Dienst besonders anfällig, da Änderungen durch den Gesetzgeber ohne Rücksicht auf die notwendigen Kosten für deren Umsetzung stattfinden; die Steuergesetzgebung mag als Musterbeispiel dienen, die ausführenden Finanzbeamten genießen meine Hochachtung. Ebenfalls anfällig sind Vertriebsunterstützungssysteme, da sich Marketingkampagnen und Rabattmodelle am Markt und am Ideenreichtum einzelnen Leute orientieren, nicht an den Möglichkeiten vorhandener Software.

Aufgenommen werden kann letztendlich nur eine Momentaufnahme, d.h. der gerade gülitge Zustand. Aus ihrer Erfahrung heraus können sehr viele Fachanwender aber wichtige Hinweise geben, auf welche Weise und in welcher Geschwindigkeit sich die fraglichen Prozesse ändern und welche Anpassungen notwendig sein können. Ein Studium der Historie vergangener Bewegungen lohnt sich so gut wie immer.

Exkurs - Kleine Katastrophen bei der Istaufnahme

Das Ergebnis einer Istaufnahme entspricht etwa einem Kochrezept. Neben den Zutaten wird auch die Verarbeitung der Zutaten dargestellt. Fehlen wesentliche Zutaten, so ist die Enttäuschung groß; ich erinnere mich mit Grausen an meinen ersten Versuch, Dampfnudeln zu machen, und zwar ohne Hefe! Dasselbe gilt für falsche Verarbeitung, verkohlt schmeckt gar nichts und manche Dinge essen sich gekocht besser als roh.
Beispiele aus der Praxis

Für eine Bibliothek sollte eine Katalogsoftware gekauft werden. Vier Versuche waren bereits gescheitert, d.h. die begutachteten Produkte waren durchgefallen. Tatsächlich gab es jedoch weder eine Beschreibung der Geschäftsprozesse in der Bibliothek noch einen verbindlichen Anforderungskatalog für das gesuchte Produkt.

Eine alte Software, die auf einer vorhandenen Datenbank aufsetzte, sollte neu programmiert werden. Das alte Produkt war bereits auf Zuruf entstanden. Zwar war bekannt, dass die alte Software unvollständig und fehlerhaft war und inhaltlich komplett überarbeitet gehörte, jedoch bestand die einzige Anforderung in einem mündlichen "eins zu eins abbilden". Derselbe Auftraggeber formulierte auf identische Weise die Forderung, eine Clipper-Anwendung als Webanwendung zu realisieren.

Mitte der achtziger Jahre war mein Personalausweis und mein Reisepass abgelaufen. In der Meldebehörde mussten die identischen Daten für beide Dokumente zwei Mal erfasst werden. Ich fragte den Sachbearbeiter, ob er nicht einen Knopf hätte, mit dem er die Daten dublizieren könne o.ä. Er schüttelte nur den Kopf und erklärte leicht säuerlich: "Meinen Sie, irgendwer hätte mich gefragt?"

Für eine kleine Software, die Auszahlungen für bestimmte freiberufliche Mitarbeiter erledigen sollte, wurde eine Istaufnahme gemacht. Betrachtet wurde dabei ein vorhandenes nicht dokumentiertes Altsystem und mit dem Kunden wurden die Zahlungsprozesse mehrfach durchgespielt. Die Spezifikation wurde vom Kunden abgenommen und das Produkt wurde realisert. Schon beim ersten Auszahlungslauf traten Probleme auf. Beim Verwendungszweck der generierten Überweisungen, der als für alle Auszahlungen identisch spezifiziert und abgenommen worden war, wurde reklamiert, dass es eine Ausnahme gäbe. Darauf hingewiesen, dass die Spezifikation abgenommen worden war, erklärte der Fachanwender, dass er sie nicht so genau gelesen hätte. Außerdem könne ja eine Ausnahme nicht so schlimm sein und es müsse doch ganz einfach sein, dies zu beheben. Die IT-Kompetenz des Fachanwenders reichte nicht aus um zu verstehen, dass es sich um einen konzeptionellen Fehler handelte, der sich im Rahmen der technischen Realisierung bereits auf Ebene der Datenbank auswirkte und der sich durch die gesamte Anwendung zog.
home - top - Kontakt - letzter Update 20.4.2004 - © Karl Scharbert