Business Analysis und Business Analyst - Sonstiges, Verschiedenes und übrig Gebliebenes

Ist Wissen über IT und das zu analysierende Fach notwendig? - Ein Glaubenskrieg!
Wer wird Business Analyst?

Ist Wissen über IT und das zu analysierende Fach notwendig? - Ein Glaubenskrieg!

In der IT gibt es ein ziemlich weites Spektrum von Tätigkeiten, die sich grob in techniknah (z.B. Programmierer, Software-Designer, Administrator), verwaltend (z.B. Projektmanager, Release Manager, Qualitätsmanager, Risikomanager) und fachnah (Business Analyst) unterscheiden lassen. Für die verwaltenden Berufe herrscht ein Glaubenskrieg, ob überhaupt IT-Wissen notwendig ist. Für den Business Analysten herrscht darüber hinaus ein Glaubenskrieg, ob er fachliches Know How nötig hat. Da Business Analyst und Projektmanager Hand in Hand arbeiten und im Frühstadium von nicht all zu großen Projekten häufig auch wechselseitig Aufgaben übernehmen, in kleinen Projekten übernimmt eine Person oft auch beide Rollen, werden hier beide Tätigkeiten betrachtet.

Sowohl bei Projektmanagern als auch bei Business Analysten gibt es zwei grundsätzlich voneinander abweichende Standpunkte über das für den Projekterfolg notwendige Know How:

ausschließlich die Methodik ist ausschlaggebend, weder ist IT-Know-How notwendig, noch Sachkompetenz im zu untersuchenden Fach
neben der Methodik ist nicht nur IT-Know-How notwendig, sondern auch solide Sachkompetenz im zu untersuchenden Fach

Rein methodische Projektmanager mit generalistischem Ansatz verwalten ein Projekt und sind ausschließlich organisatorisch tätig, müssen sich wegen ihrer nicht vorhandene Sachkompetenz in IT und Fach auf die Ergebnisse ihrer Leute vollkommen blind verlassen und haben keinerlei Möglichkeit, Entscheidungen zur IT oder zum Fach zu fällen oder die technischen und fachlichen Leistungen einzelner Mitarbeiter zu beurteilen. Zwar müssen sie Verantwortung übernehmen, können aber kompetent keine Aufgaben delegieren. Entscheidungen und Entscheidungsprozesse liegen beim Team, nicht beim Projektleiter. Leider gibt es jedoch eine Reihe von Projektleitern, die die notwendige Zurückhaltung nicht kultiviert haben und vollkommen kompetenzfreie Entscheidungen eigenmächtig treffen, die bestenfalls zufällig richtig sind. Solche Projektmanager kann man in Positionen einsetzen, in denen sie keinen Kontakt zu den Fachanwendern oder IT-Experten haben, sondern ausschließlich mit anderen Managern interagieren. Gefragt ist hier in leitenden Positionen ausschließlich der Stratege, nicht der Spezialist. Im Wesentlichen kümmern sie sich um das Controlling. Bei sehr großen Projekten braucht man jedoch ohnehin mehrere Leute, die nichts anderes tun, als Zeit- und Kostenpläne auf dem laufenden zu halten und die nicht in fachliche oder technische Entscheidungsprozesse involviert sind.

Dort, wo ein unmittelbarer Kontakt mit IT-Experten und Fachanwendern besteht, resultiert die mangelnde Sachkompetenz solcher Projektleiter in der Unfähigkeit, Inhalte, Ergebnisse und vor allem Fragestellungen und Konflikte verstehen und beurteilen zu können. Der Projektmanager hat auch keinerlei Möglichkeit, die Qualität seiner Berater zu beurteilen, und fällt nicht selten auf ebenso gute wie teure Rethoriker herein, die irgendjemandes Interessen vertreten, nur nicht die der beteiligten Fachabteilungen und IT-Teams. Jegliche Entscheidung wird zwangsläufig frei von jeder Kompetenz gefällt. Zweifelsfrei handelt es sich hier um ein erhebliches Projektrisiko.

Etwas anders gelagert ist der Fall beim Business Analysten. Ein Business Analyst erledigt den ersten Arbeitsschritt auf dem Weg von einer Idee zum fertigen IT-Produkt. Er ist ausführend tätig und seine Arbeit ist bestenfalls dann administrativ, wenn er Aufgaben des Projektleiters mit übernimmt. Um ein IT-Produkt bauen zu können, muss fundamentales Wissen vorhanden sein, wie Software und der Software-Entwicklungs-Prozess überhaupt funktioniert. Ein Analytiker ohne dieses Know How hat keine Möglichkeit zu verifizieren, dass sein Anforderungsdokument vom technischen Personal verstanden wird. Ebenso schwer wiegt, dass er ohne IT-Know How nicht beurteilen kann, ob ein Feature überhaupt implementiert werden kann. Es ist nicht besonders effektiv oder hilfreich, wenn ein Analytiker Anforderungen niederschreibt, die schließlich vom technischen Team zurück gewiesen werden, da sie offensichtlich nicht implementiert werden können oder offensichtlich zu teuer sind. Es ist zwar nicht Aufgabe des Analytikers, genaue Aufwandsabschätzungen abzugeben, im Gegenteil überschreitet er dabei meist seine Kompetenzen, er sollte aber vermeiden "Zeug" zusammen zu schreiben, das vom technischen Team als "offensichtlicher Blödsinn" zurück gewiesen wird. Die Folge ist, dass der Analyseprozess noch auf der Seite der Geschäftsprozesse und Geschäftsdaten letztendlich vom Software-Designer vervollständigt werden muss und die Anzahl der technischen Reviews inflatorisch wächst. Zwar mag der Business Analyst verstanden haben, was der Fachanwender will, er kann es aber nicht weiter kommunizieren und hat damit gegenüber der direkten Aussage des Fachanwenders keinen wirklichen Fortschritt erzielt.

Ähnlich gelagert ist der Fall bzgl. der Fachanforderungen. Einem Analytiker, der keine Ahnung von der Materie hat, müssen wie einem Praktikanten oder Azubi zunächst die Fachsprache und alle Trivialitäten beigebracht werden, ehe komplexere Vorgänge dargestellt werden können. Lernen, verstehen und das Verstandene dokumentieren ist das tägliche Brot des Business Analysten. Aufgrund seiner Ausbildung und Routine kann ein Business Analyst dies natürlich um Größenordnungen schneller als ein Azubi, denn er konzentriert sich lediglich auf die qualitativen Eigenschaften des Geschäfts und vollzieht den Lernprozess bewußt und nur soweit wie nötig. Er reproduziert nicht bestimmte Abläufe, bis er einen Zustand unbewußter Kompetenz erreicht hat, sondern sucht zunächst einen Zustand bewußter Inkompetenz zu erreichen, in dem ihm klar wird, was er alles verstehen muss, um ein vollständiges System zu spezifizieren. Im nächsten Schritt erarbeitet er bewußte Kompetenz, dokumentiert diese Kompetenz, und schreitet zum nächsten Analyseschritt.

Dieser Lernprozess kostet Zeit und somit Geld. Es ist aber immer und in jeder Organisation notwendig, dass sich der Analytiker in die lokalen Gegebenheiten einarbeitet. Fraglich ist nur, wie tief.

Manche Auftraggeber verlangen explizit, dass der Analytiker noch kein Fachwissen mitbringt. Gründe sind die Vermeidung von Betriebsblindheit gegenüber der zu analysierenden Organisation und Voreingenommenheit bzgl. der vorhandenen Prozesse aufgrund von Erfahrungen in anderen Organisationen. Der Analytiker muss dann ein guter Methodiker sein. Analytiker ohne Fachwissen werden gerne dann eingesetzt, wenn Analytiker mit Fachwissen bereits mehrfach gescheitert sind.

Wer wird Business Analyst?

Die Berufsbezeichnung Diplom-Informatiker kann nur tragen, wer ein Diplom hat. Wo er dieses Diplom erworben hat, ist eine andere Frage. Eine weitere Frage bei Informatikern mit Hochschuldiplom ist der Unterschied zwischen Diplom haben und Ingenieur sein.

Den Titel Business Analyst oder auch Systemanalytiker, Software Designer, Software Architekt, Programmierer oder Projektleiter darf sich jeder ungestraft auf das Türschild kleben und in den Lebenslauf schreiben. Der gravierende nach wie vor bestehende Fachkräftemangel in der IT hat eine Reihe Quereinsteiger in die IT gebracht, die i.d.R. nach einer kompakten Umschulung einen Abschluss in einem Ausbildungsberuf nachweisen können, in einer Fortbildungseinrichtung einige Zertifikate über erfolgreiche Kursteilnahmen erworben haben, oder als Autodidakten bzw. im Nebeneffekt in ihrem alten Beruf IT-Wissen aufgebaut haben. Die Betrachtungsweise mag skurril erscheinen, kommt aber aus der Praxis: Zwar könnte ein Studienabbrecher der Informatik einen Schnellkurs in Literaturwissenschaft, Jura oder Chemie machen, jedoch wäre es etwas ungewöhnlich, solch einen Umschüler unmittelbar nach Abschluss der Ausbildung neben Akademikern aus dem Fach an produktionskritischen Stellen zu sehen. Umgekehrt ist dies jedoch regelmäßig der Fall.

Für den Business Analysten konnte ich analog zum Projektleiter vier Karrieren identifizieren, wobei die Subjektivität meiner Betrachtungsweise zu beachten ist:

Typ 1 - Quereinsteiger	Typ 2 - Fachspezialisten, die zur IT gewechselt sind
Quereinsteiger haben keinerlei IT-Ausbildung, häufig auch keine akademische Ausbildung. Das muss jedoch, abhängig von der Qualifikation des einzelnen, kein Nachteil sein. Der Vorteil dieser Leute ist i.d.R. ihr persönliches Engagement, gerade, wenn sie noch nicht so lange im Geschäft sind. Sofern sie sich jedoch nicht massiv um Fortbildung bemühen und schon einige Zeit im Job sind, überwiegen die Nachteile: sowohl mangelhafter Hintergrund in der IT als auch im zu untersuchenden Fach, ungenügend in der Methodik und manchmal große Verständnislücken und Halbwissen. Diese Leute können auf Grund ihres fehlenden Wissens weder dem Fachanwender noch dem IT-Personal das Leben leichter machen. M.E. sind sie dann geeignet, wenn einige der folgenden Punkte gelten: Der Analytiker wird im Rahmen eines größeren Analytiker-Teams eingesetzt. Sachkompetenz ist weder für die IT noch für den Fachbereich wichtig, da in beiden Abteilungen hervorragende Leute sitzen und man eher eine Art Schreibkraft braucht. Methodik und strukturiertes Vorgehen ist nicht wirklich wichtig. Der Analytiker muss vor allem als "Pendler" zwischen Fach- und IT-Abteilung dienen. Die Personalkosten sollen niedrig sein. Die Produktqualität ist nicht wirklich wichtig. Das Projekt ist sehr klein. Die Einhaltung von Zeitplänen ist nicht von Bedeutung. Man sucht jemanden, der großen persönlichen Einsatz zeigt, auch wenn dies noch auf einem sub-professionellen Niveau stattfindet. Bei solchen Analytikern und auch Projektmanagern muss man stets in Erwägung ziehen, dass sie die IT als Berufsumfeld gewählt haben, weil sie irgendwann gehört haben, dass sich dort Geld verdienen lässt. Im technischen Bereich, insbesondere als Entwickler, können sie mangels Know How nicht eingesetzt werden und wählen dann Aufgabenfelder, bei denen ein Glaubenskrieg herrscht, ob nun technisches IT-Wissen notwendig ist, oder nicht. Es existiert ein signifikantes Risiko, dass sowohl die Bedürfnisse der Fachabteilung als auch des IT-Teams vernachlässigt werden.	Hierbei handelt es sich um Leute, die aus der Fachabteilung kommen, und sich Richtung IT-Business Analysis umorientiert haben und schließlich dort geblieben sind. Der Vorteil dieser Leute ist das große Fachwissen aus ihrer Zeit in der Fachabteilung, und, sofern der Analytiker im alten Unternehmen tätig ist, seine guten persönlichen Kontakte zu den alten Kollegen. Der Nachteil ist eindeutig eine nicht zu unterschätzende Betriebsblindheit, vor allem natürlich, wenn solche Analytiker in der Organisation aktiv sind, in der sie früher gearbeitet haben. Sofern sie einige Zeit erfolgreich als Programmierer gearbeitet haben, kennen sie die Leiden der IT-Leute. M.E. sollte diesen Analytikern dann der Vorzug gegeben werden, wenn einige der folgenden Punkte gelten: Der Analytiker arbeitet alleine, oder mit einem Typ-4-Analytiker oder in einer wichtigeren Position in einem größeren Team. Detailwissen über das Business ist sehr wichtig. Die Fachanwender in der zu analysierenden Fachabteilung sind weder proaktiv, noch werden sie aktiv an einer Lösungssuche mitarbeiten. Kleinere, meist ausbildungsbedingte Schwächen in Methodik und strukturiertem Vorgehen sind tolerabel, wobei zu beachten ist, dass es unter diesen Leuten auch hervorragende Methodiker gibt. In der IT-Abteilung sitzen sehr technisch orientierte Leute, die vom Business keine Ahnung haben und auch kein Interesse daran zeigen. Dies ist i.d.R. der Fall, wenn man das Produkt ausser Haus bauen lässt. Die Anforderungen an das Fachwissen überwiegen stark die Anforderungen an das IT-Wissen, wobei zu beachten ist, dass es unter diesen Leuten auch hervorragende IT-Spezialisten gibt. Das Projekt ist eher mittelgroß, evtl. groß. Ein vorhandenes gut dokumentiertes Produkt wird modifiziert. Ein komplett neues Produkt wird geschaffen. Bei solchen Analytikern muss beachtet werden, dass sie eine gewisse Fachlastigkeit entwickeln können, jedoch besteht keine wirkliche Gefahr, dass sie die Bedürfnisse des IT-Teams vernachlässigen.
Typ 3 - Informatiker, die von Anfang an als Business Analyst gearbeitet haben	Typ 4 - Informatiker, die von der Technik zur Business Analysis gewechselt sind
Hierbei handelt es sich i.d.R. um Informatiker, meist mit Studium, die während der Ausbildung oder kurz nach Ausbildungsende festgestellt haben, dass sie weder in der Lage sind, Software zu entwickeln, noch, Software zu administrieren. Der Vorteil dieser Leute ist, dass Sie einen akademischen, wenn auch theoretischen IT-Hintergrund haben. Wenn sie sich durch langjährige Erfahrung im Fach gut auskennen, können sie häufig mit Typ-2-Analytikern konkurrieren, ohne Kompetenz im Fach sind sie evtl. eher beim Typ 1 zu platzieren. Der Nachteil dieser Leute ist eindeutig, dass sie nicht wirklich in der Lage sind, ein IT-System zu konzipieren und daher an den Bedürfnissen der IT-Teams vorbei arbeiten. M.E. sollte diesen Analytikern, sofern sie Sachverstand für die Fachabteilung mitbringen, dann der Vorzug geben werden, wenn einige der folgenden Punkte gelten: Der Analytiker wird im Rahmen eines mittleren oder größeren Analytiker-Teams eingesetzt. In der IT-Abteilung sitzt technisches Personal, das auch vom Fach ein wenig Ahnung hat. Dies ist i.d.R. bei Inhouse-Entwicklung der Fall. Methodik ist wichtig, strukturiertes Vorgehen weniger. Zu beachten ist dabei, dass es hier z.T. lausige Methodiker gibt. Die Anforderungen an IT-Wissen und Sachverstand sind ausgewogen oder IT-Wissen soll überwiegen. Ein technischer Fokus ist gänzlich unnötig, Datenanalysen finden nicht statt. Vorhandene IT-Systeme müssen nicht analysiert werden. Das Projekt ist klein oder mittelgroß. Diese Leute beginnen meist unmittelbar nach Ausbildungsende eine Karriere als Business Analyst, nicht zuletzt, da ihnen alle technischen Bereiche der IT verschlossen sind. Bei solchen Analytikern muss man stets in Erwägung ziehen, dass sie ihren Beruf nur deshalb ausüben, weil sie keine Alternative haben. Es existiert ein Risiko, dass sowohl die Bedürfnisse der Fachabteilung als auch des IT-Teams vernachlässigt werden.	Dies sind meist Informatiker, i.d.R. mit Studium, die irgendwann mal als Programmierer gearbeitet haben und dabei auch noch erfolgreich waren. Häufig haben sie auch eine Reihe anderer IT-Jobs erledigt, z.B. als Designer, Administrator, Tester oder Projektleiter. Der Vorteil dieser Analytiker ist, dass sie im Grunde genommen in der Lage sind, das Produkt komplett von der Analyse über Design, Entwicklung und Test selbst zu implementieren, gäbe man ihne nun genügend Zeit. Sie können also schon während der Analysephase die Bedürfnisse der Entwickler berücksichtigen. Bei Kooperation der Fachabteilung kann dies zur Kostenkontrolle beitragen. Zu beachten ist, dass sie dabei versuchen, auf die Prozesse der Fachabteilung einzuwirken, was jedoch auch zu einer Optimierung dieser Vorgänge führen kann. M.E. sollte diesen Analytikern dann der Vorzug gegeben werden, wenn einige der folgenden Punkte gelten: Der Analytiker arbeit alleine, oder mit einem Typ-2-Analytiker oder in einer wichtigeren Position in einem größeren Team. Technische Arbeiten und intensive Datenanalysen sind wichtig. Im IT-Team ist ansonsten wenig oder kein fachliches Know How vorhanden. In diesem Fall sollte der Analytiker Know How im zu untersuchenden Fach haben. Betriebsblindheit soll vermieden werden. In diesem Fall darf der Analytiker noch kein Know How im zu untersuchenden Fach haben. Methodisches und strukturiertes Vorgehen ist sehr wichtig. Lausige Methodiker sind eher selten. Gesucht ist eher ein technical business analyst, wobei zu beachten ist, dass es unter solchen Analytikern auch hervorragende Fachspezialisten gibt. Vorhandene IT-Systeme müssen analysiert werden, wobei die Dokumentation u.U. fehlt. Die Organisation tendiert insgesamt eher zur Reaktivität. Das Projekt ist sehr groß. Ein vorhandenes nicht oder nur unzureichend dokumentiertes Produkt wird modifiziert. Ein komplett neues Produkt wird geschaffen. Diese Analytiker haben häufig verschieden Fachbereiche kennen gelernt. Bei diesen Leuten muss beachtet werden, dass sie eine gewisse Techniklastigkeit entwickeln können, jedoch besteht keine wirkliche Gefahr, dass sie die Bedürfnisse der Fachabteilung vernachlässigen. - Ich bin einer von denen.