Wie sollten diese Seiten gelesen werden?

Was wissen Sie? Was wollen Sie wissen?
Vorschläge für Nicht-IT-Spezialisten
Vorschläge für IT-Spezialisten
Sie haben andere Interessen oder arbeiten nicht im IT-Projekt mit
Sie wollten eigentlich gar nichts über Business Analysis wissen


Was wissen Sie? Was wollen Sie wissen?

Abhängig von Ihren Interessen und Vorkenntnissen werden Sie nicht alle Seiten studieren wollen. Ich will versuchen, eine grobe Richtlinie zu geben, wie Sie abhängig von Ihrer Interessenslage und Ihren Vorkenntnissen vorgehen können. Sofern Sie besondere Fragen haben oder auch mit dieser Hilfestellung nicht mit diesen Seiten zurecht kommen, schicken Sie mir bitte eine EMail (Kontakt) an karl.scharbert at usa.net oder posten Sie im Forum. Nur durch Ihr Feedback kann ich diese Seiten verbessern!


Vorschläge für Nicht-IT-Spezialisten

Haben Sie keine Ahnung von der IT?

Falls Sie von der IT keine Ahnung haben, dann gehören Sie nicht zur Zielgruppe dieser Seiten.

Ohne Basiskenntnisse der IT können Sie nicht wirklich kompetent in einem IT-Projekt mitwirken. Ich rege an, dass Sie sich zunächst die Grundlagen der Datenverarbeitung aneignen, z.B. durch eine Schulung. Sie können dann diese Seiten in folgender Reihenfolge lesen:
  1. Einführung zum Thema Business Analysis
  2. Datenmodellierung
  3. Darstellung von Daten, Bildschrimformularen und Prozessen
  4. Verschiedenes zur Business Analysis
Orientieren Sie sich dann neu.

Sie kommen aus dem Controlling

Sie gehören nur zur periphären Zielgruppe dieser Seiten. Sie interessieren sich vermutlich vor allem dafür, wie Sie zu einer realistischen Kostenabschätzung für ein IT-Projekt kommen oder weshalb IT-Projekte in Ihrem Bereich Zeit- und Budgetpläne nicht einhalten oder weshalb nur ein Teil der angeforderten Features geliefert wird. Die Einnahmen oder Einsparungen, die sie als Resultat aus einem IT-Projekt erzielen können, kann Ihnen das IT-Team nicht nennen, die müssen Sie natürlich zusammem mit der Fachabteilung bzw. Sales und Marketing erarbeiten. Eine realistische Abschätzung der Entwicklungskosten erhalten Sie erst, wenn die Anforderungsanalyse fertig gestellt ist.  Ich rege folgende Reihenfolge an:
  1. Einführung zum Thema Business Analysis (überfliegen reicht)
  2. Business Analysis als Bestandteil eines Prozess-Modells für IT-Projekte (gründliche Durchsicht, um eine Vorstellung von Prozess-Modellen zu bekommen)
  3. Kosten und Aufwände - Ihre Seite.
  4. Risikomanagement bzw. Projektrisiken der Anforderungsanalyse (Beachten Sie dabei, dass hier nur Projektrisiken angesprochen werden, die sich in der Nähe der Anforderungsanalyse bewegen!)
Orientieren Sie sich dann neu.

Sie gehören zur Fachabteilung und sollen ein IT-Projekt betreuen

Allgemeines

Am besten heuern Sie mich an (Kontakt). Hinweise zur Auswahl einer geeignete Person finden Sie auch bei Verschiedenes zur Business Analysis.

Wie ist Ihre Situation genau?

Sie haben keinen Analytiker, der Ihnen zur Seite steht und Sie haben selbst noch keine vergleichbaren Aufgaben gelöst

Vorausgesetzt wird, dass Sie grundlegende IT-Erfahrung haben. Wenn Ihnen die Durchsicht der Abschnitte Datenmodellierung und Darstellung von Daten, Bildschirmformularen und Prozessen nichts neues sagt, dann sind Sie hier richtig.

Verlangen Sie zunächst von Ihrem IT-Dienstleister, dass Ihnen ein Business Analyst zur Seite gestellt wird, der die Anforderungsanalyse schreibt bzw. die Istaufnahme durchführt. Handelt es sich bei dem IT-Dienstleister um ein externes Unternehmen, so werden Sie besser fahren, wenn Sie sich hausintern einen Analytiker beschaffen oder einen unabhängigen Business Analysten anheuern, der an Sie und nicht an den IT-Dienstleister berichtet. Weigert sich die IT-Abteilung, dann eskalieren Sie den Vorfall. Ohne Analytiker wird das Projekt bestenfalls ein Teilerfolg, der Zeitplan und das Budget wird überzogen werden. Ich schlage folgende Reihenfolge zum Lesen vor, aber Sie sollten sich nicht der Illusion hingeben, dass mit dem Studium dieser Seiten oder auch der Fachliteratur alles andere von alleine geht:
  1. Einführung zum Thema Business Analysis
  2. Istaufnahme (falls ein vorhandenes Verfahren umgestellt werden soll)
  3. Inhalt eines Anforderungsdokuments
  4. Die Anforderungsanalyse - Wie bekomme ich die Informationen, die ich brauche?
  5. Entstehung eines Anforderungsdokuments
  6. Risikomanagement - Projektrisiken der Anforderungsanalyse
  7. Kosten und Aufwände

Die Ergebnisse früherer Projekte waren nicht befriedigend

Ohne Ursachenforschung ist nichts gewonnen. Reevaluieren Sie zunächst die letzten Projekte (auch das kann ich für Sie übernehmen - Kontakt) und finden Sie heraus, wo die Schwächen liegen. Das reine Studium dieser Seiten wird Ihnen nur bedingt helfen und Sie sollten erwägen, für die Schwachstellen professionelles Coaching anzufordern.

Ich schlage vor, folgende Seiten zu lesen und punktuell Themen aus der Themenübersicht nach Ihren Bedürfnissen auszuwählen:
  1. Inhalt eines Anforderungsdokuments (um zu sehen, ob die alten Anforderungsdokumente ausreichend detailliert waren)
  2. Prototyping (um zu sehen, ob die Möglichkeiten des Prototyping auch ausreichend genutzt wurden)
  3. Risikomanagement - Projektrisiken der Anforderungsanalyse
  4. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird?

Die Ergebnisse früherer Projekte waren befriedigend

Vermutlich haben Sie genügend Erfahrung, Sie haben einen Analytiker im Team und Sie werden auch gut ohne mich zurecht kommen. Sie können punktuell Themen aus der Themenübersicht auswählen, sofern Ihnen das Material nicht ohnehin bereits im Detail bekannt ist. Ich empfehle insbesondere:
  1. Inhalt eines Anforderungsdokuments
  2. Anforderungsanalyse - Wie bekomme ich die Informationen, die ich brauche?
  3. Entstehung eines Anforderungsdokuments
  4. Risikomanagement - Projektrisiken der Anforderungsanalyse
  5. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird?


Vorschläge für IT-Spezialisten


Sie sind IT-Profi und haben noch wenig Erfahrung mit Anforderungsanalysen und Istaufnahmen

Am besten heuern Sie mich an (Kontakt).

Vermutlich kommen Sie (wie ich) aus der Entwicklung und dem Software-Design und Sie wechseln gerade in die Analyse. Am wichtigsten ist es, dass Sie sich mit der fachlichen Materie vertraut machen. Lassen Sie sich also von Ihren Fachanwendern erklären, was sie den ganzen Tag über machen, und lassen Sie sich von den Fachanwendern Literatur empfehlen. Vermutlich haben Sie genügend Vorkenntnisse, um sich nach Bedarf Kapitel aus der Themenübersicht heraus zu suchen. Insbesondere schlage ich folgende Themen vor:
  1. Benutzerkontakt - Interaktion, Kommunikation und Fragetechnik
  2. Inhalt eines Anforderungsdokuments
  3. Anforderungsanalyse - Wie bekomme ich die Informationen, die ich brauche?
  4. Entstehung eines Anforderungsdokuments
  5. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird?
  6. Istaufnahme (falls ein vorhandenes Verfahren umgestellt werden soll)

Sie sind Berufseinsteiger und sollen eine Istaufnahme oder Anforderungsanalyse durchführen

M.E. ist das keine gute Idee und Sie sollten zunächst bestenfalls als Junior-Partner eines Analytikers mitarbeiten. Ihre Unerfahrenheit stellt eine Projektrisiko dar. Einige Jahre Erfahrung als Entwickler und Software-Designer gehören m.E. zur Informatiker-Karriere, ehe man sich mit der Analyse auseinandersetzt. Ihr IT-Hintergrund erlaubt Ihnen, Kapitel aus der Themenübersicht nach Bedarf auszuwählen. Insbesondere schlage ich folgende Themen vor:
  1. Business Analysis als Bestandteil eines Prozess-Modells für IT-Projekte
  2. Benutzerkontakt - Interaktion, Kommunikation und Fragetechnik
  3. Inhalt eines Anforderungsdokuments
  4. Anforderungsanalyse - Wie bekomme ich die Informationen, die ich brauche?
  5. Entstehung eines Anforderungsdokuments
  6. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird?
  7. Prototyping
  8. Istaufnahme (falls ein vorhandenes Verfahren umgestellt werden soll)

Sie sind Software-Entwickler, Architekt oder Designer

Sie merken es als erster, wenn die Anforderungsanalyse ungenügend ist. Die Analyse ist ausreichend, wenn Sie auf Basis des Dokuments Software entwickeln und mit einem guten Gefühl auf dem Heimweg eine Aufwandsabschätzung geben können. Ist dies nicht der Fall, dann fordern Sie beim verantwortlichen Analytiker Nachbesserungen. Werden diese zurück gewiesen, dann eskalieren Sie den Vorfall, nötigenfalls an Ihrem Projektleiter vorbei. Für Sie besteht kein wirklicher Bedarf, diese Seiten zu lesen, bei Interesse schlage ich jedoch folgende Themen vor:
  1. Inhalt eines Anforderungsdokuments
  2. Prototyping
  3. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird
  4. Kosten und Aufwände

Sie sollen einen Testplan schreiben

Zusammen mit den Entwicklern merken Sie es als erster, wenn das Anforderungsdokument nicht ausreichend ist. Reicht die Analyse nicht aus, um einen Testplan zu schreiben, so reicht sie auch nicht, um die Entwicklung voran zu treiben. Fordern Sie beim Analytiker die notwendigen Nachbesserungen ein. Wird diese Forderung abgewiesen, dann eskalieren Sie den Vorfall, nötigenfalls an Ihrem Projektleiter vorbei. Für Sie besteht kein wirklicher Bedarf, diese Seiten zu lesen, bei Interesse schlage ich folgende Themen vor:
  1. Inhalt eines Anforderungsdokuments
  2. Darstellung von Daten, Bildschrimformularen und Prozessen (wenn Sie keinen hinreichenden IT-Hintergrund haben)

Sie sind HTML-Entwickler

Für Sie besteht kein Bedarf, diese Seiten zu lesen. Die Vorgaben Ihres Analytikers haben ausreichend zu sein, er hat die graphischen Entwürfe Ihres Screen-Designers inhaltlich abzunehmen. Sofern dies nicht gegeben ist, fordern Sie dies nach und eskalieren Sie ggf. den Vorfall.

Sie haben andere Interessen oder Sie arbeiten nicht im IT-Projekt mit

Sie wollen sich über das Berufsbild des Business Analysten in der IT orientieren

Zwar gehören Sie nicht zur Zielgruppe dieser Seiten, aber Sie finden in den vorgeschlagenen Kapiteln einige Hinweise.
  1. Einführung zum Thema Business Analysis
  2. Business Analysis und Business Analyst - Sonstiges, Verschiedenes und übrig Gebliebenes
Überfliegen Sie ansonsten die Themenübersicht, um sich nach Bedarf über Details zu informieren.

Sie sollen einen Business Analysten auswählen

Ich hoffe, Sie denken an mich (Kontakt), obwohl ich Ihnen sagen muss, dass Sie nicht zur Zielgruppe dieser Seiten gehören! Für Sie dürfte es problematisch sein, die richtigen Fragen zu stellen und zu beurteilen, ob ein Kandidat geeignet ist, oder nicht. Entscheiden Sie zunächst abhängig von den im Projekt vorhandenen Kompetenzen, wie viel Wissen der Analytiker über das zu untersuchende Fach haben muss. Zu großes Expertentum kann ein Hemmnis zum Projekterfolg werden, da Ihr Kandidat ggf. unter Betriebsblindheit leidet oder aber ohne wirkliche Rücksichtnahme auf die Unternehmensspezifika Ihres Hauses arbeitet. Zu wenig Wissen kann bei trivialen Problemen zum Show Stopper werden. Ich schlage folgende Themen in dieser Reihenfolge vor:
  1. Einführung zum Thema Business Analysis
  2. Business Analysis und Business Analyst - Sonstiges, Verschiedenes und übrig Gebliebenes
  3. Inhalt eines Anforderungsdokuments (damit Sie sehen, worum sich der Analytiker zu kümmern hat)
  4. Benutzerkontakt - Interaktion, Kommunikation und Fragetechnik (damit Sie etwas über die Methodik und Soft-Skills erfahren)
  5. Risikomanagement - Projektrisiken der Anforderungsanalyse (damit Sie sehen, was alles bei der Anforderungsanalyse schiefgehen kann)

Sie manchen gerade eine IT-bezogene Ausbildung und haben irgendeine Projekt- oder Studienarbeit abzugeben

Sie gehören nicht zur Zielgruppe dieser Seiten, aber Sie können gerne bei mir oder im Forum ein paar Rückfragen loswerden. Erwarten Sie jedoch nicht, dass ich Ihre Arbeit für Sie mache!

Vermutlich sollen Sie ein kurzes Anforderungsdokument oder eine Projektdokumentation schreiben, in der auch die Anforderungen an das Programm, das Sie schreiben, aufgenommen werden. Wahrscheinlich reicht es, wenn sie den Inhalt eines Anforderungsdokuments durchsehen und die für Sie wichtigen Punkte an Ihre Bedürfnisse anpassen.

Sie sind fachfremd und wollen etwas über Lastenhefte wissen

Sie gehören nicht zur Zielgruppe dieser Seiten, hier geht es nur um IT-Projekte mit Schwerpunkt bei der Software-Entwicklung. Evtl. sind folgende Kapitel für Sie interessant:
  1. Einführung zum Thema Business Analysis
  2. Inhalt eines Anforderungsdokuments (als Beispiel, das sich von den Formalien abgesehen wahrscheinlich nicht auf Ihr Fach übertragen lässt)
  3. Benutzerkontakt - Interaktion, Kommunikation und Fragetechnik
  4. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird

Sie sind Qualitätsmanager

Als Qualitätsmanager gehört es zu Ihren Aufgaben, die Mitarbeiter der von Ihnen betreuten Abteilungen zu coachen. Sie sollten also über den Software Development Life Cycle Bescheid wissen. Sie gehören nicht zur Zielgruppe dieser Seiten, können aber folgende Seiten lesen:
  1. Inhalt eines Anforderungsdokuments
  2. Qualitätssicherung und Tipps, was man tun kann, damit ein Anforderungsdokument gut wird

Sie wollten eigentlich gar nichts über Business Analysis wissen

Vermutlich sind Sie über eine Suchmaschine direkt auf einer der folgenden beiden Seiten gelandet:

Schwierige Kunden, Situationen und Menschen (falls Sie z.B. mit stark politisierten Arbeitsumgebungen, Mobbing, verbal aggressiven Arbeitskollegen o.ä. zu tun haben)
Arbeitsorganisation

Bitte nehmen Sie direkt mit mir Kontakt auf oder posten Sie im Forum, wenn Sie ein bestimmtes Thema vertiefen wollen.

home - top - Kontakt - letzer Update 4.5.2004 - © Karl Scharbert