In den meisten Unternehmen wird die Frage, ob man ein Tool kaufen oder selbst bauen soll, auf die falsche Art beantwortet. Jemand findet eine SaaS-Lösung, die in einer Demo gut aussieht, holt die Genehmigung für die monatlichen Kosten ein, und drei Jahre später ist das Unternehmen an einen Anbieter gebunden, zahlt für Funktionen, die es nicht nutzt, und erledigt die Hälfte der Arbeit immer noch manuell.

Dies ist die Geschichte, wie wir es anders gemacht haben, und warum die wichtigste Entscheidung, die wir getroffen haben, nichts mit Technologie zu tun hatte.

Das Problem, das niemand vollständig benannt hatte

Ich war Teil des Website-Teams eines mittelgroßen E-Commerce-Unternehmens. Unsere Aufgabe war es unter anderem, neue Produkte für Kunden zum Kauf bereitzustellen. In der Theorie simpel. In der Praxis bedeutete es, das letzte Glied in einer Kette zu sein, die Einkauf, Produktentwicklung, Finanzen, Logistik und Marketing umfasste, jede Abteilung mit eigenen Tools, eigenen Tabellen und einer eigenen Definition von „bereit”.

Wenn eine neue Kollektion anstand, verbrachten wir viel Zeit mit der Suche: Wurden die Preise von der Finanzabteilung festgelegt? Hat der Einkauf die Lieferung bestätigt? Hat die Produktentwicklung die technischen Daten bereitgestellt? Die Informationen existierten, irgendwo, aber sie waren über eine fragmentierte Landschaft aus Google Sheets, geteilten Laufwerken und institutionellem Gedächtnis verstreut.

Dazu kamen die Sheets selbst, die zunehmend zum Problem wurden. Große, komplexe Tabellenkalkulationen sind fehleranfällig. Sie frieren auf schwächeren Rechnern ein, brechen zusammen, wenn jemand die falsche Zelle bearbeitet, und skalieren schlecht, wenn Teams und Produktkataloge wachsen. Doppelerfassungen waren an der Tagesordnung. Fehler ebenso. Verantwortlichkeit hingegen nicht.

Logistik und Einkauf hatten sich bereits auf ein ERP (Odoo) konsolidiert, aber alles andere wurde abteilungsweise in Sheets verwaltet. Das Ergebnis: Das Website-Team, mein Team, absorbierte am Ende jedes Launch-Zyklus den Großteil des Chaos.

Die Übergangslösung

Bevor ich ein System vorschlug, unternahm ich einen einfacheren ersten Schritt: die Konsolidierung der Informationen in einem einzigen Google Sheet, das den gesamten Launch- und Kundensupport-Workflow abdeckt. Keine neuen Tools, keine Entwicklungsarbeit. Nur die Einigung auf eine einzige Quelle der Wahrheit.

Die Stabilisierung dauerte etwa sechs bis acht Monate. Die Reibung wurde reduziert, aber das zugrundeliegende Problem wurde dadurch umso klarer. Eine Tabellenkalkulation, egal wie gut gepflegt, war nie das richtige Fundament für diesen strukturierten, abteilungsübergreifenden Datenfluss. Wir brauchten etwas Zweckgebautes. Das endlose Kopieren und Einfügen musste aufhören. Die vermeidbaren Fehler durch menschliche Irrtümer mussten ein Ende haben.

Der richtige Pitch

Hier scheitern viele interne Tool-Projekte. Der Instinkt ist, mit einer Lösung in ein Pitch-Gespräch zu gehen: „Ich habe diese tolle SaaS gefunden” oder „wir sollten ein PIM-System bauen.” Dieser Ansatz scheitert fast immer, weil er Entscheidungsträger bittet, eine Lösung zu bewerten, bevor sie sich über das Problem einig sind.

Ich machte das Gegenteil. Ich dokumentierte die Schwachstellen in betriebswirtschaftlichen Begriffen: verlorene Zeit pro Launch-Zyklus, Fehlerquoten, die nachgelagerten Kosten fehlerhafter Daten auf der Website. Ich machte deutlich, warum das für das Unternehmen relevant ist, nicht als technologisches Problem, sondern als operatives. Die Lösung kam erst danach.

Der Pitch ging an meinen Abteilungsleiter und von dort an die C-Ebene. Er wurde genehmigt.

Warum wir gebaut statt gekauft haben

Sobald das Projekt genehmigt war, war die Frage „Kaufen oder Bauen?” relativ eindeutig, allerdings nicht aus den Gründen, die man üblicherweise nennt.

Ja, ich habe mir SaaS-PIM-Lösungen angesehen. Sie waren deutlich teurer. Aber Kosten allein sind ein schwaches Argument, denn SaaS-Kosten sind vorhersehbar, Entwicklungskosten nicht. Die stärkeren Argumente lagen woanders.

Erstens: Passgenauigkeit. Unsere Anforderungen waren spezifisch: Integration mit Google Sheets (wo unsere Teams bereits arbeiteten), ein Rich-Text-Editor für Texter, eine API-Anbindung an unser TMS für Übersetzungs-Workflows und ein CSV-Export für Magento 2. Kein Standardtool hätte das ohne erheblichen Konfigurationsaufwand abgedeckt, für den man so oder so zahlt.

Zweitens: Kontrolle. Ein schlankes internes Tool muss keine langfristige Verpflichtung sein. Wir haben es so gebaut, dass es ersetzbar ist. Kein Lock-in, kein Migrationsrisiko, keine Anbieterabhängigkeit. Wenn sich der Tech-Stack des Unternehmens ändern würde, könnten wir sauber aussteigen.

Wie sich herausstellte, war das wichtig. Das Unternehmen bewegte sich später in Richtung des Shopify-Ökosystems, was das PIM möglicherweise überflüssig machen wird. Weil wir ohne Lock-in gebaut haben, ist das kein Problem. Wir betrachten es als ein bewusstes Merkmal des ursprünglichen Designs, nicht als Zufall.

Drittens: Eigentümerschaft. Produktinformationen lagen zuvor in verstreuten Drive-Dokumenten. Viel Erfolg beim Finden von irgendetwas in diesem Chaos! Das PIM gab uns eine PostgreSQL-Datenbank mit täglichem automatisiertem Backup auf dem Unternehmens-Drive. 99,99 % Uptime über fast ein Jahr Betrieb. Daten, die tatsächlich auffindbar und wartbar sind.

Was wir gebaut haben

Das MVP benötigte etwa 150-200 Stunden mit einem zweiköpfigen Team. Meine Rolle umfasste Konzept, Architektur, CI/CD-Pipeline und Hosting-Setup. Ich habe das System entworfen und in Produktion gebracht. Mein Junior-Kollege übernahm den Großteil der Feature-Entwicklung. Die End-to-End-Verantwortung vom Whiteboard bis zum Deployment lag bei mir. Das System:

Nutzt SSO zur Authentifizierung
Zieht technische und Finanzdaten aus Google Sheets, wo die Mitarbeiter bereits arbeiten
Bietet einen Rich-Text-Editor für Texter, isoliert von technischer Komplexität
Fordert Produktübersetzungen über die TMS-API (Smartling) an und empfängt sie
Exportiert eine Magento-2-fertige CSV, die den manuellen Kopieraufwand eliminiert, der zuvor etwa 70 % der Launch-Zeit des Website-Teams beanspruchte
Läuft auf einem sehr erschwinglichen, europäischen VPS via Docker, deployed über Bitbucket Pipelines
Sichert die Datenbank täglich per Cronjob auf Google Drive

Im Laufe des vergangenen Jahres wurden kontinuierlich Patches und Erweiterungen eingespielt. Die Gesamtkosten, Entwicklung, Wartung, Hosting, liegen nach wie vor 80-90 % unter dem, was vergleichbare SaaS-Lösungen gekostet hätten.

Das Prinzip dahinter

Ich habe in operativen Rollen genug Zeit verbracht, um eine Sache klar zu wissen: Die beste Lösung ist selten die technisch eleganteste, und nie die ideologisch reinste. Es ist die Lösung, die das eigentliche Problem löst, zu den tatsächlichen Rahmenbedingungen passt und ohne Drama übergeben, gewartet oder verworfen werden kann.