Antwort

Historisch gesehen begannen Systemanalytiker häufig mit einer tiefgehenden Analyse der Geschäftsprozesse eines Unternehmens. Dies ermöglichte es zu verstehen, wo und wie ein Informationssystem die Aktivitäten der Organisation automatisieren oder optimieren kann. Oftmals verschwimmen jedoch die Grenzen zwischen der Analyse von Geschäftsprozessen und der technischen Planung.

Schlüsselmerkmale:

• Die Beschreibung von Geschäftsprozessen zielt darauf ab, die Aktivitäten der Organisation als System zu identifizieren und zu formalisieren, ohne die Details der Implementierung mit IT-Mitteln zu berücksichtigen.
• Der Entwurf eines Informationssystems beginnt nach der Festlegung der Anforderungen und umfasst die Ausarbeitung von Architektur, Schnittstellen, Integrationen und Datenformaten.
• Es ist wichtig, diese Phasen zu unterscheiden: Zuerst bestimmt der Analyst "was zu tun ist", dann – "wie es gemacht wird".

Hintergrund der Frage

Früher war die Grenze zwischen diesen Phasen klarer: Der Business-Analytiker war für das Modellieren von Prozessen verantwortlich, der Systemanalytiker für die Übersetzung von Anforderungen in technische Spezifikationen. In der modernen Praxis vermischen sich die Aufgaben häufig.

Problem

Viele Analysten beginnen, ein System zu entwerfen, bevor sie die Prozesse vollständig analysiert haben, was zu falschen Anforderungen und übermäßigen technischen Details führt.

Lösung

Die Analyse des Fachgebiets klar vom Entwurf zu trennen, BPMN und EPC für die Beschreibung von Prozessen zu verwenden und für den Entwurf UML, Datenflussdiagramme (DFD) usw.

Fangfragen.

Was ist wichtiger – Geschäftsprozesse zu analysieren oder ein System zu entwerfen?

Man kann nicht das eine vom anderen abtrennen: Die Analyse von Prozessen ist notwendig, um korrekte Anforderungen zu erarbeiten, der Entwurf ist notwendig, um sie umzusetzen. Dies sind aufeinanderfolgende Phasen.

Kann man die gleichen Diagramme für die Beschreibung von Prozessen und den Entwurf eines Systems verwenden?

Nein, BPMN/EPC sind für Prozesse anwendbar, UML/DFD für die strukturelle oder objektorientierte Analyse und Planung.

Wann kann man auf die Modellierung von Geschäftsprozessen verzichten?

Nur wenn das Projekt klein ist und sie bereits vollständig in Dokumenten oder Standards formalisiert sind. In den meisten Fällen ist eine Modellierung notwendig.

Typische Fehler und Anti-Pattern

• Vorzeitiger detaillierter Übergang zu einem Datenmodell, ohne sich mit den Geschäftsanforderungen auseinanderzusetzen.
• Vermischung von Prozessbeschreibung und technischen Lösungen.
• Ignorieren der Interessen der Endbenutzer.

Beispiel aus dem Leben

Negativer Fall:
Der Analyst begann sofort, das Datenbankschema und die Dienste zu skizzieren, ohne zu untersuchen, wie die Mitarbeiter arbeiten und was sie benötigen. Vorteile: schnelle Implementierung, alle sind mit der ersten Version zufrieden.
Nachteile: Das System löst keine echten Aufgaben, die Benutzer sind unzufrieden, eine Nachbesserung war erforderlich.

Positiver Fall:
Der Analyst führte zuerst eine Reihe von Interviews mit den Mitarbeitern durch, erstellte BPMN, und wechselte dann zur Planung von API und Datenbank. Vorteile: Anforderungen sind klar, das System deckt reale Prozesse ab.
Nachteile: längerer Projektstart, höhere Kosten für die Analyse.