So bereiten Sie sich auf ein IT-Projekt vor

Sie haben entschieden, etwas automatisieren oder entwickeln zu lassen. Bevor der Entwickler anfängt, können Sie einiges tun, das Zeit und Geld spart — und das Ergebnis deutlich besser macht.

Ich sage das nicht, weil ich weniger arbeiten möchte. Im Gegenteil: Je besser Sie vorbereitet sind, desto mehr kann ich meine Zeit für die eigentliche Lösung nutzen — statt für Rückfragen, Missverständnisse und Korrekturen.

Die gute Nachricht: Was ich von Ihnen brauche, ist kein technisches Dokument. Sie müssen keine Software kennen, keine Architektur skizzieren und keine APIs recherchieren. Sie müssen mir nur Ihr Problem erklären. Aber das richtig.

Den Prozess aufschreiben

Das Wichtigste, was Sie vor einem IT-Projekt tun können: den betroffenen Prozess aufschreiben. Nicht als technisches Dokument, nicht als Flussdiagramm, nicht als Lastenheft. Einfach als Ablauf in normaler Sprache.

So zum Beispiel:

«Wenn eine Bestellung per E-Mail reinkommt, druckt Frau Müller sie aus, prüft ob der Kunde schon im System ist, legt ihn sonst an, tippt die Bestellpositionen ins ERP, prüft die Verfügbarkeit und erstellt die Auftragsbestätigung. Wenn der Betrag über CHF 5'000 liegt, muss Herr Schmidt die Bestellung freigeben, bevor sie weitergeht.»

Das reicht. Wirklich. Aus diesem einen Absatz kann ich ableiten, welche Systeme beteiligt sind, wo Entscheidungen getroffen werden, welche Sonderfälle es gibt und wo Automatisierung ansetzen kann.

Was mir noch mehr hilft: Wenn Sie den Ablauf nicht nur für den Normalfall beschreiben, sondern auch für die Ausnahmen. Was passiert, wenn die Bestellung unvollständig ist? Wenn der Artikel nicht auf Lager ist? Wenn der Kunde reklamiert? Die Ausnahmen sind meistens der Grund, warum ein Prozess kompliziert ist — und genau dort müssen wir gemeinsam entscheiden, wie die Automatisierung damit umgehen soll.

Tipp: Setzen Sie sich mit der Person zusammen, die den Prozess tatsächlich ausführt — nicht mit dem Abteilungsleiter, der ihn theoretisch beschreibt. Die Person, die es jeden Tag macht, kennt die wirklichen Schritte, die Workarounds und die Sonderfälle, die in keinem Handbuch stehen.

Was soll sich ändern?

Die zweite wichtige Frage: Was genau ist heute das Problem, und was soll danach anders sein?

«Wir wollen schneller Angebote schreiben» ist ein verständlicher Wunsch, aber als Briefing zu vage. Ich weiss nicht, was genau langsam ist. Die Kalkulation? Das Zusammensuchen der Kundendaten? Das Erstellen des PDFs? Das Ganze?

Konkreter wäre: «Die Kalkulation für ein Angebot dauert heute 45 Minuten, weil die Materialpreise manuell aus einer Excel-Tabelle nachgeschlagen werden müssen, die einmal im Monat aktualisiert wird. Wir hätten gerne, dass die Preise automatisch aus dem ERP gezogen werden.»

Aus dem ersten Satz kann ich ein Dutzend verschiedene Lösungen ableiten. Aus dem zweiten genau eine — und die richtige.

Hilfreiche Fragen, die Sie sich stellen können:

• Was genau dauert zu lang oder geht zu oft schief?
• Wie sieht der ideale Ablauf aus — wenn alles perfekt funktionieren würde?
• Was wäre die minimale Verbesserung, die sich schon lohnen würde?
• Was ist das Ergebnis: ein Dokument, eine Benachrichtigung, ein Datensatz im System, ein Dashboard?

Sie müssen nicht alle Fragen beantworten können. Aber je konkreter Ihre Beschreibung ist, desto weniger Rückfragen gibt es — und desto schneller kommen wir zu einem Ergebnis.

Wer ist betroffen?

Jede Automatisierung betrifft Menschen. Die Person, die den Prozess heute ausführt. Die Person, die das Ergebnis bekommt. Vielleicht eine Führungskraft, die Freigaben erteilt. Manchmal auch Kunden oder Lieferanten.

Für mich als Entwickler ist es wichtig zu wissen:

• Wer nutzt den Prozess heute? Eine Person? Ein ganzes Team? Verschiedene Abteilungen?
• Wie technikaffin sind die Betroffenen? Jemand, der täglich mit dem ERP arbeitet, braucht eine andere Lösung als jemand, der hauptsächlich mit E-Mail und Papier arbeitet.
• Was nutzen die Betroffenen heute? Excel, ERP, E-Mail, Papier, ein anderes Tool? Das hilft mir zu verstehen, wo die Lösung andocken muss — und welche Umstellung auf die Leute zukommt.
• Gibt es Widerstände? Nicht jeder freut sich über Veränderung. Wenn jemand seine Excel-Tabelle liebt und nicht loslassen will, muss ich die Lösung so bauen, dass sie einen klaren Vorteil bietet — oder wir müssen vorher reden.

Ich baue nicht für Systeme, ich baue für Menschen. Je besser ich verstehe, wer die Lösung nutzen wird, desto besser wird sie.

Welche Systeme sind im Spiel?

Eine einfache Liste der beteiligten Systeme hilft mir enorm bei der Planung. Zum Beispiel:

• ERP: Weclapp
• Webshop: WooCommerce
• Buchhaltung: Bexio
• E-Mail: Microsoft 365
• Sonstiges: diverse Excel-Tabellen auf dem Netzlaufwerk

Das muss keine technische Dokumentation sein. Ich brauche nur zu wissen, welche Systeme Daten liefern, welche Daten empfangen und wo die Grenzen sind.

Daraus kann ich ableiten, welche Schnittstellen es gibt (oder nicht gibt), wie die Systeme miteinander kommunizieren können und wo der Aufwand liegt. Manche Systeme haben offene APIs und sind in einer Stunde angebunden. Bei anderen muss man kreativ werden — oder feststellen, dass eine direkte Verbindung nicht möglich ist und ein Umweg nötig wird.

Bonus-Tipp: Wenn Sie Zugangsdaten zu Testsystemen bereithalten, spart das Tage. Ich muss nicht warten, bis jemand mir den Zugang einrichtet. Ich kann sofort schauen, wie die Daten aussehen, welche Felder es gibt und wie die API funktioniert. Ein Testsystem — nicht das Produktivsystem — reicht völlig. Falls Sie kein Testsystem haben, ist das auch kein Problem. Dann klären wir das gemeinsam.

Budget und Zeitrahmen

Das ist das Thema, über das niemand gerne redet. Aber es hilft — wirklich.

Haben Sie eine Vorstellung, was das Projekt kosten darf? Gibt es einen Termin, bis wann es laufen muss? Gibt es externe Abhängigkeiten — zum Beispiel ein ERP-Update, das in drei Monaten kommt, oder eine Messeteilnahme, für die alles fertig sein soll?

Es ist völlig okay zu sagen: «Keine Ahnung, was das kosten darf.» Dann mache ich einen Vorschlag und Sie entscheiden. Aber wenn Sie ein Budget im Kopf haben, hilft es mir bei der Lösung realistisch zu bleiben. Mit CHF 3'000 kann ich eine solide Automatisierung für einen Prozess bauen. Für CHF 15'000 kann ich drei oder vier Prozesse abdecken, inklusive Error-Handling und Dokumentation. Und für CHF 1'000 kann ich Ihnen sagen, ob sich das Projekt überhaupt lohnt.

Beim Zeitrahmen ist es ähnlich: Wenn Sie wissen, dass es dringend ist, priorisiere ich anders als bei einem Projekt ohne Deadline. Und wenn der Termin unrealistisch eng ist, sage ich Ihnen das lieber vorher als nachher.

Transparenz beim Budget ist keine Schwäche — sie ist der schnellste Weg zu einer realistischen Lösung.

Was Sie NICHT tun müssen

Zum Schluss das Wichtigste: Was Sie getrost dem Entwickler überlassen können. Denn ich erlebe immer wieder, dass Kunden sich stundenlang in Dinge einarbeiten, die gar nicht ihre Aufgabe sind.

Sie müssen keine technischen Lösungen vorschlagen. «Wir brauchen eine REST-API mit Webhook und OAuth2» — das ist nett gemeint, aber oft nicht das, was wirklich gebraucht wird. Beschreiben Sie das Problem, nicht die Lösung. Die Lösung ist mein Job.

Sie müssen keine Software-Architektur skizzieren. Kein Diagramm, kein Datenmodell, kein Flowchart. Wenn Sie eins haben, schaue ich es gerne an. Aber es ist keine Voraussetzung.

Sie müssen keine APIs recherchieren. Ob Ihr ERP eine API hat und wie sie funktioniert — das finde ich heraus. Dafür bezahlen Sie mich.

Sie müssen kein Lastenheft schreiben. Ein Lastenheft ist gut für grosse IT-Projekte mit mehreren Anbietern. Für ein Automatisierungsprojekt mit einem einzelnen Entwickler reicht eine klare Problembeschreibung.

Was Sie tun müssen: Das Problem und den Kontext beschreiben. Wer macht was, wie oft, mit welchen Systemen, und was soll besser werden. Den Rest mache ich.

Die beste Vorbereitung auf ein IT-Projekt ist nicht technisches Wissen — es ist Klarheit über das eigene Problem. Wenn Sie mir in fünf Minuten erklären können, was Sie nervt und was Sie sich wünschen, haben Sie alles getan, was nötig ist.

Und wenn Sie sich nicht sicher sind, ob Ihre Beschreibung reicht: Schicken Sie sie mir einfach. Lieber eine unvollständige Beschreibung, auf die ich Rückfragen stellen kann, als wochenlang an einem perfekten Briefing zu arbeiten, das nie fertig wird.