„Was kostet die Integration unseres Shops mit dem ERP?" ist die teuerste E-Mail, die ein polnisches KMU je verschickt. Nicht weil die Dienstleister teuer sind — sondern weil niemand, dich eingeschlossen, wirklich weiß, wonach du fragst.
Typisches Szenario. Der Inhaber schreibt vier IT-Dienstleister an, die ihm jemand empfohlen hat. Eine Frage: „was kostet das". Eine Woche später kommen vier Angebote zurück. Eines für 24.000 PLN. Das zweite für 48.000. Das dritte für 92.000. Das vierte für 180.000 — mit dem Hinweis, dass „das eine Ausgangssumme ist, weil die Anforderungen zu unscharf sind". Der Inhaber starrt auf den Bildschirm und weiß nicht, was er damit anfangen soll. Jeder Dienstleister hat „Integration" anders verstanden.
Das ist kein Dienstleister-Problem. Das ist ein Problem der Anfrage. Und es lässt sich an einem Nachmittag lösen, bevor irgendjemand das erste Angebot schickt.
Warum eine „Vorlage-Ausschreibung" nicht funktioniert
Google „IT-Ausschreibung Vorlage" und du bekommst ein 40-seitiges Dokument mit Abschnitten zu Firmenhistorie, Mission, Fünfjahresstrategie und RACI-Matrix. Für ein KMU ist das Zeitverschwendung — auf beiden Seiten.
Der Dienstleister braucht nicht deine Firmenmission. Er braucht Antworten auf eine Handvoll sehr konkreter Fragen, die Vorlagen gerade nicht stellen. Eine zweiseitige ehrliche Antwort auf diese Fragen ist mehr wert als eine 40-seitige Vorlage, in der 90% der Felder „offen" stehen.
Eine Fachanforderung für ein KMU muss drei Dinge tun:
- Das Problem beschreiben, das du lösen willst. Nicht die Technologie, die du kaufen willst.
- Dem Dienstleister harte Zahlen geben, damit er den Aufwand kalkulieren kann. Mengen, Beispiele, Szenarien — keine Floskeln.
- Zeigen, wie du beurteilen wirst, ob es funktioniert hat. Was sich im Unternehmen ändert, wenn das Projekt gut ausgeht.
Mehr nicht. Ohne diese drei Punkte gibt es kein Gespräch über Geld — es gibt eine Wunschauktion.
Was mindestens hineingehört
Für die meisten Integrations- und Einführungsprojekte in einem KMU reichen zwei bis vier A4-Seiten locker. Inhalt:
- Heute (ein Absatz). Wie der Prozess, den du ändern willst, heute aussieht. Kurz: wer, in welchem System, wie oft am Tag, wie lange das dauert. Ein Satz dazu, was am meisten weh tut.
- Die beteiligten Systeme. Name, Version, Hersteller oder Betreuer, API vorhanden ja/nein, wer das Admin-Passwort hat. „Comarch Optima 2026, Betreuer: XYZ, API verfügbar, technischer Kontakt: Jan Kowalski (jan@...)". Ohne das rät der Dienstleister.
- Was sich ändern soll. In der Sprache des Alltags, nicht der Technik. „Shop-Bestellungen landen innerhalb von 15 Minuten in Optima, ohne manuelles Abtippen, mit Kundenrabatt und Zahlart." Nicht: „wir bauen einen Integrations-Microservice."
- Mengen. Wie viele Transaktionen pro Tag? Wie viele Artikel? Wie viele Standorte? Wie viele Währungen? Wie viele Belege pro Monat? Diese Zahlen bestimmen die ganze Architektur. Ein Dienstleister mit Zahlen kann kalkulieren. Ein Dienstleister mit „eher viel" verdoppelt sicherheitshalber.
- Randfälle, die du nicht vergessen willst. Was ist mit Vorkasse-Bestellungen? Rücksendungen? Auslandskunden? Fremdwährungsrechnungen? Liste 5–10 Situationen, die bei euch tatsächlich vorkommen — auch wenn selten. Dienstleister kalkulieren vor allem die Randfälle, denn Randfälle fressen 60% der Projektzeit.
- In Scope und Out of Scope. „In Scope: Bestellungen und Lagerstände. Out of Scope: Zahlungsintegration, Treueprogramm, Rücksendungen." Wenn du das nicht hinschreibst, kalkuliert ein Dienstleister zwei Prozesse, ein anderer sieben — und die Angebote sind nicht vergleichbar.
- Woran du erkennst, dass es funktioniert hat. Ein, zwei Sätze, messbar. „Manuelles Abtippen fällt von 2 Stunden pro Tag auf null; Adressfehler sinken um 90%." Das ist keine Formalität — das ist das Abnahmekriterium.
- Deine Rahmenbedingungen. Ungefähres Budget (nicht geheim halten — die Dienstleister fragen sowieso), Zeitplan, Verfügbarkeit deiner Leute, Abhängigkeiten vom externen ERP-Partner.
Wird das Dokument länger als vier Seiten, ist das meist ein Zeichen, dass du Dinge hineinpackst, die ein eigenes Projekt wären.
Ein konkretes Beispiel
Bei einem unserer Kunden — einem 18-köpfigen Großhändler für Sanitärarmaturen aus Niederschlesien — begann es genau mit dieser klassischen E-Mail: „was kostet die Integration unseres Shops mit Comarch Optima?". Der Inhaber schickte sie an vier Firmen. Die Angebote kamen zurück: 24.000, 48.000, 92.000 und 180.000 PLN.
Er rief uns für eine zweite Meinung an, weil er nicht wusste, ob das erste ein Schnäppchen oder eine Falle ist. Wir setzten uns drei Stunden zusammen und schrieben eine 3-seitige Spezifikation. Inhalt:
- Heute: zwei Vertriebsmitarbeiter tippen Bestellungen aus dem Shop in Optima um, etwa 60 Bestellungen pro Tag, insgesamt ca. 2,5 Stunden. Ein Adressfehler pro Woche.
- Systeme: PrestaShop 8.1 (externes Hosting, Admin-Zugang vorhanden), Comarch Optima 2026 (Betreuer: X, API verfügbar).
- Scope: Bestellungen (B2C und B2B), Aktualisierung der Lagerstände im Shop, Kundendaten. Out of Scope: Zahlungen (PayU bleibt wie bisher), Produktkatalog (einseitiger Export aus Optima einmal täglich), Rücksendungen und Reklamationen.
- Mengen: 60 Bestellungen/Tag, 4.500 Artikel, 2 Standorte, 1 Währung, EUR voraussichtlich später.
- Randfälle: B2B-Bestellungen mit kundenspezifischem Rabatt, Nachnahme-Bestellungen, kein Negativbestand, Bestellartikel (kein Lagerabgleich), Lieferadresse abweichend von Rechnungsadresse.
- Erfolg: Vertrieb gewinnt mindestens 2 Stunden pro Tag zurück, null manuelles Abtippen, Adressfehler unter 1 pro Monat, Umsatzsteuer-Abrechnung bleibt unverändert.
- Ungefähres Budget: bis 60.000 PLN, Start Q1, Umsetzung in Etappen.
Der Inhaber schickte dieselbe Spezifikation an dieselben vier Dienstleister. Neue Angebote: 42, 48, 51, 54 Tausend. Streuung 29% statt 650%. Die beiden, die vorher an den Rändern lagen (24 und 180), fielen heraus — einer gab zu, er habe „die Hälfte der Anforderungen übersehen", der andere zog sich zurück. Das Projekt landete bei 51.000 PLN, pünktlich, mit zwei separat beauftragten Scope-Änderungen unterwegs — ohne Streit.
Aufwand für das Schreiben der Spezifikation: drei Stunden. Nettoersparnis: schwer exakt zu beziffern, aber mindestens vier Monate Herumirren und 100.000 PLN auf dem Tisch. Nichts Zauberhaftes — jemand hat endlich konkret gefragt.
Was nicht in die Spezifikation gehört
Eine Spezifikation wird in dem Moment unbrauchbar, in dem sie anfängt, auf Nummer sicher zu gehen.
- „Modern, intuitiv, skalierbar." Diese Wörter sagen einem Dienstleister nichts. Jeder antwortet: „natürlich, unsere Lösung ist modern." Stattdessen: Zahlen, Prozesse, Namen.
- Konkrete Technologien als Ziel. „Wir wollen das in .NET 8 auf Azure" ergibt Sinn, wenn du harte Zwänge hast (ein vorhandenes Team arbeitet in .NET). Es ergibt keinen Sinn, wenn du es aus dem Internet abgeschrieben hast, weil es gerade in ist. Beschreibe das Problem, der Dienstleister schlägt den Stack vor.
- Anforderungen vom Typ „so etwas wie beim Wettbewerb". Der Dienstleister weiß nicht, was genau du beim Wettbewerb siehst. Beschreib zwei, drei konkrete Masken oder Abläufe.
- „Den Rest klären wir in Workshops." Dieser Satz in einer Spezifikation bedeutet, dass du die Denkarbeit abwälzt. Der Dienstleister kalkuliert diese Workshops doppelt so hoch, weil er nicht weiß, was dabei herauskommt.
Wenn du etwas nicht weißt, schreib es offen: „heute wissen wir noch nicht, ob das in den Scope gehört — bitte separat anbieten". Das ist ehrlich und die Angebote werden vernünftig.
Wie du an einem Nachmittag anfängst
Du brauchst kein Werk. Eine Reihenfolge, die funktioniert:
- 90 Minuten mit den Leuten, die tatsächlich im Prozess arbeiten. Nicht die Geschäftsleitung. Zwei Vertriebsmitarbeiter, die Buchhalterin, der Lagerist — je nach Projekt. „Was macht ihr heute von Hand? Wo passieren die Fehler? Was würde euer Leben ändern?"
- 60 Minuten für die Niederschrift auf 2–4 Seiten. Keine Ausschreibungsvorlage. Ein ganz normales Word- oder Markdown-Dokument mit Überschriften: heute, Systeme, Scope, Mengen, Randfälle, Erfolg, Budget. Alltagssprache, kein Jargon.
- 30 Minuten Vorlesen an die Person, die das neue System benutzen wird. „Beschreibt das deine Arbeit?" Antwortet sie „ja, aber X fehlt" — X ergänzen.
- An drei bis vier Dienstleister schicken. Nicht mehr. Fünf und mehr sind eine Last, die du nicht ehrlich verarbeiten kannst.
Und die eine Frage, die man am Ende der Spezifikation stellen sollte, statt einer aus dem Internet kopierten Fragenliste: „Was fehlt in dieser Spezifikation, damit du ein belastbares Angebot abgeben kannst?". Ein Dienstleister, der konkret antwortet, denkt sichtbar mit. Ein Dienstleister, der schreibt „alles klar, Angebot anbei", tut es sichtbar nicht.
Wenn du nicht weißt, wie du dein Projekt so beschreibst, dass die Angebote nicht um eine Größenordnung auseinander liegen — eine halbe Stunde mit jemandem, der Hunderte davon gesehen hat, spart Monate der Wunschauktion.
Eine gute Spezifikation beschreibt nicht das System, das du willst. Sie beschreibt das Problem, das du hast — konkret genug, dass jemand von außen abschätzen kann, was es kostet, es zu beheben.
Reden wir über dein IT-Projekt, bevor du Angebote einholst →