Wie Sie einem IT-Experten Ihre Geschäftsanforderungen beschreiben (ohne IT-Fachjargon)

Warum die Art der Kommunikation wichtig ist

Warum ist gute Kommunikation wichtiger, als Sie denken?

• Schlechtes Briefing = schlechte Lösung. Wenn ein Entwickler ungenaue oder unklare Informationen erhält, wird er improvisieren. Das Ergebnis? Software, die vielleicht technisch funktioniert, aber nicht das löst, was Sie erwartet haben.
• Unklarheiten führen zu Verzögerungen. Je mehr Fragezeichen während der Entwicklung auftauchen, desto mehr zusätzliche Anpassungen und Terminverschiebungen gibt es.
• Jede Entwicklung kostet etwas. Und jede Ungenauigkeit oder Änderung in der Aufgabenstellung bedeutet zusätzliche Kosten.

Gute Nachricht: Sie müssen nicht „ihre“ Sprache sprechen

Der Entwickler braucht vom Kunden keine technische Spezifikation. Er muss die realen Bedürfnisse des Unternehmens verstehen. Und diese können Sie selbst am besten über konkrete Situationen, Probleme und Erwartungen beschreiben.

Stellen Sie sich zum Beispiel diese Fragen:

• Wo entstehen in der täglichen Arbeit die meisten Verzögerungen?
• Welche Tätigkeiten wiederholen sich und könnten automatisiert werden?
• Welche Fehler treten häufig auf und wodurch entstehen sie?
• Welche Informationen müssen Sie immer schnell und zuverlässig zur Verfügung haben?

Technologie löst Probleme, aber nur die, die sie kennt

Software entsteht nicht aus Code, sondern aus Verständnis. Wenn Sie benennen können, was im Unternehmen nicht ideal funktioniert und was anders sein sollte, sind Sie bereit, auch ohne IT-Wörterbuch effektiv mit einem Softwarepartner zu kommunizieren.

Die häufigsten Kommunikationsmissverständnisse zwischen Unternehmen und ITlern

Einer der häufigsten Gründe, warum die Softwareentwicklung nicht reibungslos verläuft, ist die unterschiedliche Wahrnehmung dessen, was gesagt wurde und was verstanden wurde. Das Unternehmen sagt eine Sache, der Entwickler stellt sich eine andere vor, und das Ergebnis erfüllt oft weder die Erwartungen der einen noch der anderen Seite.

Unternehmen: „Wir wollen es wie Excel, nur schöner.“

Entwickler: „Soll es sich um einen visuellen Editor mit Tabellenoberfläche handeln? Oder um eine Datenbank mit Verknüpfungen zwischen Daten? Soll es mit dem bestehenden Excel synchronisiert werden?“

Ergebnis: Die gelieferte Lösung deckt nicht ab, was sich das Unternehmen vorgestellt hat, weil die ursprüngliche Aufgabenstellung zu vage war.

Unternehmen: „Wir wollen ein einfaches CRM.“

Entwickler: „Einfach im Sinne einer Kontaktverwaltung? Oder auch mit Verkaufsprozess, Fakturierung und Support?“

Ergebnis: Das gelieferte System kann entweder nicht das, was das Unternehmen erwartet hat, oder es ist zu komplex und unnötig teuer.

Wo entstehen die häufigsten Missverständnisse?

• Vagheit und Ungenauigkeit: Begriffe wie „einfach“, „schnell“, „wie ein Google-Formular“ können für jeden etwas anderes bedeuten.
• Zu große Technikorientierung: Unternehmen versuchen, „in der Sprache der Entwickler“ zu sprechen, und verwenden Begriffe, die sie nicht verstehen und oft auch falsch einsetzen.
• Fehlender Kontext: Der Entwickler weiß, was die Software tun soll. Aber oft weiß er nicht warum das Unternehmen sie braucht, und genau das kann entscheidend sein.
• Verschwiegene Erwartungen: „Das haben wir als selbstverständlich angesehen.“ Ein Satz, der immer dann auftaucht, wenn es schon zu spät ist.

Wie lassen sich diese Probleme vermeiden?

Beschreiben Sie die Probleme, die Sie lösen möchten, nicht technische Lösungen.

• Statt: „Wir wollen eine REST API mit JSON-Output.“
• Versuchen Sie: „Wir brauchen, dass unser Lager Daten aus dem Fakturierungssystem einlesen kann.“

Erklären Sie den Nutzungskontext:

• Wer wird das System nutzen?
• Wann und wie oft?
• Welche Daten sind für Sie am wichtigsten?

Scheuen Sie sich nicht, zuzugeben, was Sie nicht wissen. ITler sind es gewohnt, Zusatzfragen zu stellen. Wichtig ist, dass Sie offen und konkret sind.

Es geht nicht darum, dass Sie lernen, „wie ein ITler“ zu sprechen. Ziel ist es, über Ihr Unternehmen, Ihre Prozesse und Probleme so zu sprechen, dass der Entwickler sie versteht und in eine funktionale Lösung umsetzen kann.

Beginnen Sie mit dem Problem, nicht mit der Funktion

Einer der größten Unterschiede zwischen einem erfolgreichen und einem problematischen Softwareprojekt ist die Art, wie ein Unternehmen seine Anforderungen formuliert. In der Praxis hört man nämlich sehr oft Sätze wie: „Wir brauchen Button X,“ „Wir wollen Modul Y,“ „Machen Sie uns eine Anwendung für Z.“ Das ist jedoch keine Aufgabenstellung, sondern nur eine Vorstellung der Lösung. Und diese kann (oft unbewusst) falsch, ineffizient oder unnötig teuer sein.

SEin erfahrener Entwickler muss nicht wissen, welchen Button Sie wollen, sondern warum Sie ihn wollen.

Warum „Funktionsvorgaben“ eine Sackgasse sind

Wenn ein Unternehmen mit der Beschreibung konkreter Funktionalitäten beginnt, übernimmt es die Rolle des Lösungsdesigners, ohne den technischen oder prozessualen Überblick zu haben. Das Ergebnis ist häufig Software, die zwar die „Wunschliste“ erfüllt, aber das eigentliche Problem nicht oder nur teilweise löst.

Typische Folgen eines solchen Ansatzes:

• die Software ist unnötig kompliziert,
• sie enthält Funktionen, die in der Praxis nicht genutzt werden,
• es entstehen zusätzliche Anpassungen, die das Projekt verteuern,
• Nutzer haben das Gefühl, dass das System „gegen sie“ arbeitet.

Der richtige Anfang: Beschreiben Sie die Realität, nicht die Lösung

Viel effektiver ist es, damit zu beginnen, was heute im Unternehmen passiert und was nicht ideal funktioniert. Ein ITler kann dann eine Lösung vorschlagen, die einfacher, günstiger und oft auch technisch sauberer ist als das, was Sie selbst entwerfen würden.

Vergleich aus der Praxis:

❌ „Wir wollen eine Anwendung zur Mitarbeiterverwaltung.“
✅ „Jeden Monat verbringen wir zwei Arbeitstage mit der manuellen Verarbeitung der Anwesenheit. Die Daten werden von Papier in Excel übertragen und dabei entstehen häufig Fehler. Wir müssen diesen Prozess beschleunigen und übersichtlicher machen.“

❌ „Wir brauchen einen Export in PDF.“
✅ „Wir senden Kunden Angebote manuell und verwenden oft alte Versionen von Dokumenten. Wir möchten sicher sein, dass sie immer ein aktuelles und korrektes Angebot erhalten.“

Im zweiten Fall versteht der ITler das Ziel. Und wenn er das Ziel versteht, kann er eine Lösung vorschlagen, die es nicht nur auf dem Papier, sondern auch praktisch erfüllt.

Hilfestellung für Unternehmen: Stellen Sie die richtigen Fragen

Bevor Sie anfangen, über Software zu sprechen, versuchen Sie, diese Fragen zu beantworten:

• Welcher Prozess nimmt uns heute die meiste Zeit in Anspruch?
• Wo entstehen Fehler, die uns Geld oder Nerven kosten?
• Welche Tätigkeiten erledigen Menschen wiederholt und manuell?
• Wer arbeitet jeden Tag mit dem System und was stört ihn bei der Arbeit am meisten?
• Was müsste sich ändern, damit wir sagen: „Das funktioniert besser als bisher“?

Diese Antworten sind für einen ITler wertvoller als jede Liste technischer Funktionen.

Ein Perspektivwechsel, der Zeit und Budget spart

Wenn ein Unternehmen aufhört zu fragen „welche Funktionen wollen wir“ und beginnt zu fragen „welches Problem wollen wir lösen“, verändert sich der gesamte Projektverlauf. Die Aufgabenstellung wird klarer, die Lösungen werden zielgerichteter und die Entwicklung „bläht sich“ weniger auf.

Software soll dem Business dienen, nicht umgekehrt. Und der erste Schritt dazu ist, das Problem in der Sprache der Realität zu benennen, nicht der Technologie.

Wie Sie die Informationen für den ITler vorbereiten

Ohne gute Aufgabenstellung erstellt auch der beste ITler keine gute Software.

Viele Unternehmen gehen in ein Softwareprojekt mit einer sehr vagen Vorstellung davon, was sie eigentlich brauchen. Anstatt zunächst zu klären, welche Prozesse sie verbessern wollen und warum, beginnen sie mit der Beschreibung „technischer“ Anforderungen, die jedoch oft nicht die tatsächlichen Bedürfnisse des Business widerspiegeln.

Wenn Sie möchten, dass der Entwickler Sie versteht, müssen Sie nicht programmieren können. Sie müssen Klarheit über Ihre Prozesse haben. Und sie verständlich beschreiben können.

Was Sie vor dem ersten Treffen vorbereiten sollten

1. Liste der Prozesse, die Sie lösen möchten

Sie müssen sie nicht ausführlich beschreiben. Es reicht, anzugeben, welchen Zweck sie haben, wie sie ablaufen und warum sie für Sie relevant sind.
Beispiel:

• Erfassung von Kundenbestellungen
• Ausstellen von Rechnungen
• Bearbeitung von Reklamationen
• Lagerverwaltung

2. Wer diese Prozesse ausführt und wie sie heute ablaufen

Oft werden die Menschen vergessen, die täglich mit den Systemen arbeiten. Aus ihrer Sicht zeigt sich, was in der Realität funktioniert und was nicht.

• Wer führt den jeweiligen Prozess aus? (z. B. Vertriebsmitarbeiter, Buchhalterin, Lagerist)
• Worin macht er das heute? (z. B. Excel, Papier, E-Mail)
• Was hält ihn dabei auf, was muss er manuell erledigen?

3. Probleme und Verzögerungen, die Sie belasten

Dies ist der wichtigste Teil der Aufgabenstellung. Konzentrieren Sie sich auf die Realität, nicht auf Hypothesen:

• Wo entstehen Fehler oder Tippfehler?
• Welche Schritte wiederholen sich und nehmen zu viel Zeit in Anspruch?
• Was verursacht am häufigsten Verzögerungen oder Unzufriedenheit bei Kunden?

4. Ziele: Was soll verbessert, beschleunigt oder vereinfacht werden

Hier geht es nicht um die Beschreibung der Lösung, sondern um den erwarteten Effekt:

• Wir möchten, dass die Fakturierung Minuten dauert, nicht Stunden
• Wir möchten die Anzahl der Fehler in Bestellungen reduzieren
• Wir brauchen einen Überblick über den Status von Aufträgen an einem Ort

Warum sich das lohnt

Wenn Sie diese Informationen im Voraus vorbereiten, erhalten Sie:

• einen schnelleren Lösungsvorschlag (der Entwickler muss Details nicht nachträglich klären),
• eine genauere Schätzung von Preis und Zeit,
• ein geringeres Risiko von Missverständnissen und zusätzlichen Kosten,
• ein System, das reale Probleme löst, nicht nur die, von denen Sie „dachten“, dass Sie sie haben.

Die Kommunikation mit dem Entwickler dreht sich nicht um Technologie, sondern um Prozesse. Wenn Sie ihm einen klaren Blick auf Ihre tägliche Realität geben, hilft er Ihnen, eine Lösung zu entwerfen, die funktional, einfach und sinnvoll ist. Die endgültige Software wird dann kein „Technologieprojekt“ sein, sondern ein Werkzeug, das Ihr Unternehmen wirklich voranbringt.

Sie müssen nicht wissen „wie“, es reicht zu wissen „was“ und „warum“
Ihre Aufgabe ist es nicht, Software zu entwerfen, sondern zu erklären, was sie lösen soll und warum das für Sie wichtig ist,

Ein häufiger Fehler in Unternehmen, die Softwareentwicklung beauftragen, ist der Versuch, gleich mit einer eigenen Lösung zu kommen. Sie sagen zum Beispiel: „Wir wollen Modul X mit Button Y, der Dokument Z generiert.“ Ein solcher Ansatz führt jedoch oft zu einem unnötig komplizierten, ineffizienten System, weil der Entwurf der Lösung nicht Ihre Aufgabe ist.

Ihre Aufgabe ist es, die Realität zu beschreiben. Je genauer Sie dem ITler erklären können, was Sie brauchen und warum Sie es brauchen, desto besser kann er eine Lösung für Sie vorschlagen.

Was Sie wissen (und sagen) sollten

Konzentrieren Sie sich auf diese drei Fragen:

Was soll die Software tun?
Zum Beispiel: „Wir möchten einen Überblick über alle eingegangenen Bestellungen haben, wer sie bearbeitet und in welchem Status sie sind.“

Für wen ist sie gedacht?
Zum Beispiel: „Mit dem System werden der Lagerist und die Vertriebsabteilung arbeiten. Sie müssen schnell auf Informationen zur Bestellung zugreifen können.“

Warum ist das wichtig?
Zum Beispiel: „Heute gehen diese Informationen in E-Mails verloren, was Fehler und Verzögerungen verursacht. Die Kunden sind dann unzufrieden.“

Wie erklären Sie es, wenn Sie sich nicht sicher sind?

Wenn Sie bei Formulierungen unsicher sind, müssen Sie nicht in Panik geraten. Eine hervorragende Hilfe ist es, einen konkreten Arbeitstag oder eine typische Situation zu beschreiben.

Versuchen Sie, darüber nachzudenken:

• Was genau macht ein konkreter Mitarbeiter?
• Mit welchen Werkzeugen arbeitet er?
• Was funktioniert für ihn gut und was nicht?
• Wann fühlt er sich frustriert oder aufgehalten?

Beispiel aus der Praxis:
„Unsere Buchhalterin kopiert jeden Monat manuell Daten zu eingegangenen Bestellungen aus der E-Mail in das Fakturierungssystem. Das nimmt ihr den ganzen Tag. Außerdem passiert es häufig, dass etwas falsch übertragen wird und die Rechnung korrigiert werden muss. Wir möchten, dass diese Daten automatisch übertragen werden.“

Eine solche Beschreibung sagt dem Entwickler viel mehr als der Satz: „Wir müssen E-Mail mit dem Fakturierungssystem verbinden.“

Sie müssen keine technologischen Lösungen, Integrationsprotokolle oder Datenbanknamen kennen. Es reicht, wenn Sie wissen, welches Problem Sie lösen, wen es betrifft und warum es Sie beschäftigt. Der Entwickler ist dazu da, einen Weg zu finden, wie er Ihnen helfen kann, aber ohne Ihre Eingaben wird es kein System für Sie, sondern für jemand anderen.

Wie sieht eine gute Aufgabenstellung aus?

1. Benennung des Problems
   Beschreiben Sie, was heute nicht funktioniert, verzögert oder die Arbeit unnötig verkompliziert.
2. Kontext
   Erklären Sie, wie der Prozess heute abläuft, wer damit arbeitet und warum es ein Problem ist.
3. Ziel
   Sagen Sie, was sich ändern soll und welchen Nutzen Sie davon erwarten.

Vergleich: Vagheit vs. Konkretheit

❌ „Wir brauchen digitale Transformation.“
Eine solche Aufgabenstellung sagt nichts darüber aus, was die Software konkret lösen soll.

✅ „Wir möchten die Genehmigung von Bestellungen automatisieren, die heute per E-Mail abläuft und manchmal bis zu 3 Tage dauert. Wir brauchen, dass der Genehmiger eine Benachrichtigung erhält und mit einem Klick entscheiden kann, ob er die Bestellung genehmigt.“
Das sagt dem ITler bereits, welchen Prozess die Software ersetzen soll, wer damit arbeiten wird und was das Ergebnis sein soll.

Weitere Beispiele gut formulierter Aufgabenstellungen:

✅ „Heute müssen wir Rechnungen manuell auf Grundlage von Daten aus Excel ausstellen. Wir hätten gern ein einfaches Formular, in dem der Vertriebsmitarbeiter die Daten ausfüllt und das System die Rechnung automatisch generiert.“

✅ „Wir möchten, dass das Vertriebsteam an einem Ort Zugriff auf eine Übersicht aller aktuellen Aufträge hat. Momentan sind sie in E-Mails verstreut und jeder führt sie auf seine eigene Weise.“

✅ „Wir brauchen, dass Mitarbeiter über das System Urlaub beantragen können und der Vorgesetzte ihn ohne E-Mails hin und her genehmigen kann.“

Praktische Hilfe: Einfache Struktur der Aufgabenstellung

1. Was lösen wir?
   Kurze Beschreibung des Problems oder Hindernisses im aktuellen Prozess.
2. Wer arbeitet damit?
   Wer sind die Nutzer? Welche Fähigkeiten haben sie? Was erwarten sie vom System?
3. Wie funktioniert es heute?
   Worin ist das aktuelle System oder die aktuelle Vorgehensweise ungeeignet?
4. Was möchten wir erreichen?
   Was ist das Ziel, idealerweise auch in Zeit oder Arbeitsersparnis ausgedrückt.

Sie müssen keine Spezifikation wie für eine öffentliche Ausschreibung vorbereiten. Es reicht, wenn Sie klar erklären können:

• was Sie heute bremst,
• wen es betrifft,
• und was das Ergebnis sein soll.

Der ITler hilft Ihnen, diese Anforderungen in eine technische Lösung zu übersetzen, aber eine gute Aufgabenstellung ist Ihre Eintrittskarte dafür, dass das Ergebnis wirklich funktioniert.

Klare Kommunikation spart Zeit, Geld und Nerven

Eine gute Softwarelösung entsteht nicht nur an der Tastatur des Programmierers. Sie beginnt im Unternehmen mit einer klaren Benennung von Problemen, offener Kommunikation und konkreten Zielen. Sie müssen keine technische Terminologie beherrschen, Spezifikationen schreiben können oder den Unterschied zwischen Backend und Frontend kennen. Was Sie jedoch brauchen, ist, Fragen wie diese beantworten zu können:

• Was verursacht uns heute Verzögerungen oder Fehler?
• Wo geht in Prozessen Zeit oder Überblick verloren?
• Was würde uns bei der Arbeit deutlich helfen?

Wenn Sie diese Antworten kennen, können Sie ein hervorragender Partner für den ITler sein. Nicht, weil Sie ihm sagen, wie er etwas tun soll, sondern weil Sie ihm sagen, warum Sie es brauchen. Genau darin liegt der Schlüssel zu einem hochwertigen Ergebnis.

Zusammenfassung der wichtigsten Punkte:

• Beginnen Sie nicht mit der Lösung, sondern mit dem Problem.
• Beschreiben Sie nicht die Funktionalität, sondern die Realität Ihrer täglichen Arbeit.
• Bereiten Sie Ihre Informationen vor: Prozesse, verantwortliche Personen, wichtigste Hindernisse.
• Seien Sie konkret und sachlich, nicht technisch.
• Führen Sie während der Entwicklung einen laufenden Dialog.

Ein guter ITler wird Sie nie danach beurteilen, ob Sie die „richtige IT-Sprache“ sprechen. Im Gegenteil: Er wird es schätzen, wenn Sie Ihr Unternehmen kennen, benennen können, was Sie bremst, und eine klare Vorstellung davon haben, wohin Sie sich entwickeln möchten. Dadurch wird auch die Software selbst nicht nur funktional, sondern wirklich nützlich.