Die Kunst der Modellierung 7 Sections64 Lessons6 Quizzes8 Weeks
Ist-Analyse
Etappe 1: Vom Kundenwunsch zur Analyse
Was passiert eigentlich gerade bei Chez Motchi?
Bevor wir irgendetwas Neues planen, müssen wir zunächst verstehen, wie es bei Chez Motchi heute schon abläuft. Diesen ersten Blick auf die bestehende Situation nennt man Ist-Analyse. Sie bildet den eigentlichen Beginn der Analysephase.
📌 Ist-Analyse
Die Ist-Analyse erfasst, wie ein System – hier Motchis Café – aktuell tatsächlich funktioniert, bevor über eine neue Lösung nachgedacht wird.
- Aufgabe: die zugrundeliegenden Geschäftsprozesse kennenlernen, Anforderungen der Nutzerinnen und Nutzer sammeln und strukturieren.
- Ziel: die Ist-Situation erfassen, die Problemstellung formulieren, Grundlage für spätere Änderungen schaffen.
- Methoden: zum Beispiel die ereignisgesteuerte Prozesskette oder die ABC-Analyse, je nach Kontext.
Wichtig ist: In der Ist-Analyse entwerfen wir noch keine Lösung. Wir sammeln zunächst nur Wissen darüber, wie die Dinge heute laufen.
🥐 Praxis bei Chez Motchi
Motchi hat ein kleines Café. Bisher läuft vieles über Notizbücher, Zettel und das Gedächtnis der Mitarbeiter. Bevor eine Software entworfen wird, muss der Auftrag – eine Verwaltungssoftware für ein Café – zunächst besser verstanden werden. Genau das ist das Ziel dieser Phase: Ist-Analyse und spätere Soll-Konzeption.
Fragen zu den Arbeitsabläufen
Ein guter Ausgangspunkt für die Ist-Analyse sind Fragen zu den täglichen Abläufen im Café.
- Was ist das Haupt-, was das Nebengeschäft von Chez Motchi – reiner Café-Betrieb oder auch Backwarenverkauf zum Mitnehmen?
- Wo kauft Motchi seine Zutaten ein?
- An wen verkauft das Café – Laufkundschaft, Stammgäste, größere Gruppen?
- Wie sehen die täglichen Arbeitsroutinen aus, etwa beim Öffnen und Schließen?
- Welche außerordentlichen Prozesse gibt es – zum Beispiel private Feiern oder größere Reservierungen?
- Welche Prozesse könnten zukünftig noch hinzukommen?
Fragen zu den Ressourcen
Neben den Abläufen selbst müssen wir auch die vorhandenen Ressourcen verstehen.
- Wie viele Mitarbeiterinnen und Mitarbeiter arbeiten bei Chez Motchi?
- Wie viele Personen würden die Software später überhaupt anwenden?
- Gibt es nur einen Standort, oder plant Motchi bereits eine zweite Filiale?
- Gibt es externe Mitarbeitende oder externe Unternehmen, die eingebunden werden müssen?
- Welche finanziellen und technischen Mittel stehen für die Software überhaupt zur Verfügung?
Erst wenn diese Fragen beantwortet sind, entsteht ein realistisches Bild davon, was die neue Software überhaupt leisten muss – und was sie leisten kann, ohne Motchis Budget oder sein kleines Team zu überfordern.
Rollenspiel: Kunde und Entwickler im Gespräch
In der Praxis findet die Ist-Analyse häufig im direkten Gespräch statt. Motchi kennt sein Café bis ins kleinste Detail – die Entwicklerin oder der Entwickler kennt dagegen die Möglichkeiten und Grenzen der Software. Erst im gemeinsamen Gespräch entsteht ein vollständiges Bild.
„Welche aktuellen Probleme sind eigentlich relevant? Welche Prozesse, welche Ressourcen, welche Daten spielen wirklich eine Rolle?“
Diese Fragen sollten am Ende der Ist-Analyse beantwortet und schriftlich festgehalten sein – als gemeinsame Grundlage für die nächsten Schritte.
⚠️ Typischer Fehler
Ein häufiger Fehler besteht darin, die Ist-Analyse zu überspringen und direkt mit Wunschvorstellungen zu beginnen. Wird zum Beispiel angenommen, dass Chez Motchi nur einen einzigen Mitarbeiter beschäftigt, obwohl in der Hochsaison mehrere Aushilfen gleichzeitig arbeiten, führt das später zu einem Modell, das an der Realität vorbeigeht.
💡 Merke
- Die Ist-Analyse erfasst die aktuelle Situation, bevor über eine Lösung nachgedacht wird.
- Sie untersucht sowohl Arbeitsabläufe als auch vorhandene Ressourcen.
- Ziel ist es, die Problemstellung klar zu formulieren – nicht, bereits eine fertige Lösung zu entwerfen.
- Die Ist-Analyse gehört zu Etappe 1: Vom Kundenwunsch zur Analyse.
🚀 Ausblick
Aus den Erkenntnissen der Ist-Analyse entstehen im nächsten Schritt konkrete Anforderungen. In der nächsten Lektion lernen wir, wie man diese sauber formuliert – und warum dabei zwischen funktionalen und nicht-funktionalen Anforderungen unterschieden wird.