Über die Aufgaben von Business Analyse

Business Analyse ist eine Disziplin in der Softwareentwicklung, die sich mit der Fachlichkeit einer Softwarelösung beschäftigt. Sie ist zuständig für die umfassende Beschreibung der Geschäftsprozesse und der Anforderungen an die Software, die diese erfüllen soll.

Wird Business Analyse gut gemacht, ist für die Softwareentwicklung ein hoher Grad an Sicherheit vorhanden, dass die Anforderungen (funktional und nicht-funktional) des Kunden getroffen werden. Sie ist um erfolgreich zu sein natürlich auch von der Einbeziehung des Kunden in die Analyse abhängig. Der Kunde ist hier der Informationslieferant und derjenige, der entscheidet, welche Funktionen die Software zur Verfügung stellen soll.

Die Ergebnisse der Business Analyse dienen dem Softwarearchitekten, eine Softwarearchitektur zu definieren, die für die Entwicklung den strukturellen Rahmen vorgibt.

Über den Einsatz von Beratern

Der Einsatz von Beratern ist in der Wirtschaft eine gängige Praxis. Diese hat viele Vorteile aber es gibt auch Dinge die beim Einsatz von Beratern zu beachten sind.

Einige Vorteile sind:

  • Berater bringen Expertenwissen mit, das im Unternehmen evtl. nicht zur Verfügung steht.
  • Sie haben einen umfassenden Überblick über Geschäftsdomänen, der intern nicht zur Verfügung stehen könnte
  • Sie bringen eine Außensicht mit, die Betriebsblindheit bei Problemlösungen vermeiden lässt
  • Sie sind eine zusätzliche Ressource, die ins Spiel gebracht werden kann, wenn intern keine Ressourcen zur Verfügung stehen.

Mit all den Vorteilen ist aber auch zu beachten, dass Berater zumeist temporäre Aufträge haben. Gute Berater werden daher vorschlagen einen Wissenstransfer bzw. –aufbau zu machen für die Zeit nach ihrer Beratertätigkeit.

Geht es bei der Beratung um Analysen, so muss sichergestellt sein, dass die Berater die notwendigen internen Experten bzw. Informationen zur Verfügung gestellt bekommen, um aussagekräftige Analysen durchzuführen. Es muss auch auf die Analysetiefe geachtet werden, damit das Ergebnis in einem realistischen Bezug zur Realität gesetzt werden kann.

Insgesamt stellen Berater eine gute Ergänzung zu internen Ressourcen dar, wenn ihr Einsatz gut geplant ist und je nach Beratungstyp die Ergebnissicherung eingeplant wird.

Architektur

Architektur ist in der IT kein Selbstzweck. Architektur strukturiert die Systeme und schafft Ordnung. Gute Architektur hilft die nicht-funktionalen Anforderungen zu erfüllen (Wartbarkeit, Stabilität, Leistungsfähigkeit, möglichst kleine Änderungsaufwände etc.). Die Qualität der Architektur ist der Grad der Erfüllung dieser Anforderungen.

Schlechte Architektur zeigt sich, wenn Änderungen am System nicht mehr verlässlich abgeschätzt werden können bzw. immer das „gesamte System“ angegriffen werden muss – um zwei Beispiele zu nennen.

Als Manager in der IT ist es daher wichtig gute, zukunftssichere Architektur anzustreben. Das heißt sich mit der Zukunft beschäftigen und Anforderungen vorwegnehmen. Mit dem Ansatz kann man in der IT Aufwände minimieren.

Krisenmanagement mit Scrum

Heute habe ich mich mit einem Kollegen gemeinsam entschieden Scrum als Methodik einzusetzen, um ein ins Strudeln geratenes Projekt wieder auf einen guten Weg zu bringen. Wir werden die Elemente Product Backlog, Sprint Backlog, Impediment Log, Sprint Planning Meetings und das Burndown Chart verwenden, um dem Team Klarheit über die anstehenden Aufgaben zu geben. Zusätzlich wird es tägliche Scrum Meetings geben – strickly time boxed natürlich.

Ich bin schon gespannt wie sich die Sache entwickelt. In jedem Fall bin ich zuversichtlich, da ich bereits die positiven Effekte des Sichtbarmachens der Handlungen in einen Team erleben durfte.

Erfolgsmodell für IT-Systeme

Heute widme ich mich einem IT-Thema. Es geht um die Treiber, die für den Erfolg oder Misserfolg einer IT-System-Implementierung entscheiden. Das Modell ist von DeLeon und McLean.

Die Treiber im Detail:

  • Systemqualität:
    Z.B.: schlechte Antwortzeiten, nicht funktionierende Programme, etc.
  • Informationsqualität:
    durch schlechtes Systemdesign, schlechtes Testen, oder Benutzer, die die Verantwortung für die Datenwartung nicht wahrnehmen
  • Anwenderzufriedenheit:
    Benutzer können das System nicht optimal nutzen. Z.B.: durch unzureichende Einbindung in die Entwicklung, schlechtes Training, Änderung in Prozessabläufen – nicht durch schlechte Software an sich.
  • Individuelle Auswirkungen:
    Benutzer lukrieren nicht den erwarteten Nutzen
  • Organisatorische Auswirkungen:
    Trotzdem Benutzer einen Nutzen vom neuen System haben, ist dieser auf organisatorischer Ebene nicht gegeben.

Das Modell dient als Leitfaden, um wesentliche Kriterien beim Aufsatz eines IT-Systems zu beachten. Wichtig ist in diesem Zusammenhang hier die Benutzer des Systems mit einzubinden.