Technologie muss ein Geschäftsproblem lösen – nicht umgekehrt

Warum viele Digitalprojekte nicht den erwarteten Nutzen bringen

Digitalprojekte sind aufwendig, kostspielig und binden interne Ressourcen über Monate. Wenn sie am Ende nicht das leisten, was man sich erhofft hat, liegt das selten an mangelnder technischer Qualität. Es liegt meistens daran, dass das eigentliche Problem nie präzise genug formuliert wurde.

Das ist kein Vorwurf an einzelne Unternehmen. Es ist ein strukturelles Muster, das sich durch nahezu alle Branchen zieht – und das bei KMU genauso anzutreffen ist wie bei grösseren Organisationen.

Dieser Artikel zeigt, warum der Ausgangspunkt eines Technologieprojekts entscheidend ist, wie Unternehmen den richtigen Einstiegspunkt finden und was eine problemzentrierte Herangehensweise in der Praxis bedeutet.

---

Das Muster: Lösung sucht Problem

Ein häufiges Szenario: Ein Unternehmen erfährt auf einer Fachmesse oder über einen Anbieter von einer neuen Softwarelösung. Die Präsentation ist überzeugend, die Features beeindruckend, das Preismodell scheint attraktiv. Man entscheidet sich für eine Einführung.

Monate später stellt sich heraus: Das System wird kaum genutzt. Die Mitarbeitenden arbeiten weiterhin mit ihren bisherigen Methoden. Das Projekt gilt intern als «nicht so gelaufen wie erhofft».

Das Problem war nicht die Software. Das Problem war die Reihenfolge: Zuerst die Lösung, dann – wenn überhaupt – das Problem.

Technologieanbieter kommunizieren aus der Perspektive ihrer Produkte. Das ist verständlich und legitim. Ihre Aufgabe ist es, Features, Vorteile und Anwendungsfälle zu präsentieren. Die Aufgabe der Unternehmen ist es, diesen Blickwinkel aktiv umzukehren.

---

Der richtige Ausgangspunkt: Das konkrete Problem

Bevor eine Technologieentscheidung getroffen wird, braucht es eine ehrliche Bestandsaufnahme. Folgende Fragen helfen, den richtigen Einstiegspunkt zu finden:

Was kostet uns heute konkret Zeit oder Qualität?

Nicht im abstrakten Sinn, sondern ganz konkret: Welche Aufgaben werden manuell erledigt, obwohl sie automatisierbar wären? Wo werden Daten mehrfach erfasst, weil Systeme nicht miteinander kommunizieren? Wo entstehen Fehler, weil Informationen nicht zentral verfügbar sind?

Wo fehlen verlässliche Entscheidungsgrundlagen?

Viele Unternehmen treffen operative Entscheidungen auf Basis von Erfahrung und Bauchgefühl – nicht weil sie das bevorzugen, sondern weil die Datenlage dünn ist. Dashboards, Auswertungen und strukturierte Daten sind keine Luxus, sondern Voraussetzung für fundierte Entscheidungen.

Was soll in sechs oder zwölf Monaten anders sein?

Diese Frage klingt einfach, ist aber oft die schwierigste. Sie zwingt dazu, einen konkreten Zielzustand zu beschreiben – nicht Features, sondern Ergebnisse. «Wir möchten, dass Kundenanfragen ohne manuelle Weiterleitung ins richtige System kommen» ist ein solcher Zielzustand. «Wir möchten eine moderne CRM-Lösung» ist es nicht.

---

Warum Technologie ein Mittel ist – und nicht das Ziel

Diese Aussage ist in der Branche bekannt. Trotzdem wird sie im Projektalltag regelmässig vergessen oder verdrängt.

Der Grund dafür ist menschlich: Technologie ist greifbar. Man kann sie präsentieren, demonstrieren und in einem Angebot aufführen. Der Nutzen – also das gelöste Problem – ist abstrakter und zeigt sich erst nach der Einführung.

Das verführt dazu, Technologie als Erfolgsmessung zu verwenden: «Wir haben ein neues System eingeführt» klingt nach einem abgeschlossenen Projekt. Ob das System das ursprüngliche Problem gelöst hat, ist eine andere Frage – und sie wird zu selten gestellt.

Ein gesundes Gegengewicht: Technologieentscheide sollten immer an einen messbaren Ausgangszustand und einen definierten Zielzustand geknüpft sein. Nicht «wir führen ein Tool ein», sondern «wir möchten diesen Prozess von X auf Y verändern, und dieses Tool ist das geeignete Mittel dafür».

---

Wie ein problemzentrierter Projektansatz aussieht

Bei Sergenta beginnen Projekte nicht mit einer Toolempfehlung. Sie beginnen mit einer strukturierten Analyse: Was funktioniert gut, was nicht, und wo liegt der eigentliche Engpass?

Daraus entsteht ein gemeinsames Verständnis des Problems – bevor irgendeine Technologie ins Gespräch kommt. Erst in einem zweiten Schritt wird bewertet, welche technischen Ansätze das Problem adressieren können: eine massgeschneiderte Softwarelösung, eine bestehende Plattform, eine Automatisierung, ein Dashboard, eine API-Integration oder eine Kombination davon.

Diese Reihenfolge mag selbstverständlich klingen. In der Praxis erfordert sie Disziplin – insbesondere wenn Anbieter, interne Stakeholder oder Zeitdruck in Richtung einer schnellen Lösung drängen.

Konkrete Beispiele aus dem Projektalltag

Doppelte Datenhaltung: Ein Unternehmen pflegt Kundendaten in drei verschiedenen Systemen, weil diese nicht verbunden sind. Das Problem ist nicht «wir brauchen ein neues CRM», sondern «wir brauchen eine verlässliche, zentrale Datenbasis». Die Lösung kann eine Integration bestehender Systeme sein – oder eine neue Lösung, aber nur wenn die Analyse das ergibt.

Manuelle Reportingprozesse: Ein Team verbringt jeden Montag zwei Stunden damit, Kennzahlen aus verschiedenen Quellen zusammenzutragen. Das Problem ist nicht «wir brauchen ein besseres Excel», sondern «wir brauchen automatisierte Datenflüsse und ein strukturiertes Dashboard». Diese Formulierung eröffnet andere – und oft wirksamere – Lösungsoptionen.

Fehlende interne Kontrolle über digitale Inhalte: Eine Organisation muss für jede Anpassung auf der Website eine externe Agentur beauftragen. Das Problem ist Abhängigkeit und fehlende Eigenständigkeit – und die Lösung ist ein CMS mit einem für das Team geeigneten Redaktionssystem, nicht notwendigerweise das technisch fortschrittlichste.

---

Was sich verändert, wenn der Ausgangspunkt stimmt

Wenn Technologieprojekte beim Problem beginnen, verändert sich die Dynamik auf mehreren Ebenen:

• Akzeptanz: Mitarbeitende, die verstehen, warum ein System eingeführt wird und welches konkrete Problem es löst, nehmen es eher an.
• Scope-Disziplin: Projekte mit klar definiertem Problemfokus neigen weniger dazu, im Lauf der Zeit unkontrolliert zu wachsen.
• Erfolgsmessung: Ein definierter Ausgangszustand ermöglicht es, nach der Einführung zu beurteilen, ob das Projekt sein Ziel erreicht hat.
• Kosten: Wer weiss, was er braucht, kauft nicht, was er nicht braucht.

---

Fazit

Technologie ist leistungsfähig – aber nur im richtigen Kontext. Die Fähigkeit, den Kontext zuerst zu klären und die Technologieentscheidung danach zu treffen, ist eine der wichtigsten Kompetenzen in Digitalprojekten.

Sie erfordert keine besondere technische Expertise. Sie erfordert die Bereitschaft, vor der Antwort die richtige Frage zu stellen.

Für Unternehmen, die Digitalprojekte planen, bedeutet das: Investieren Sie Zeit in die Problemformulierung. Sie ist die beste Vorarbeit, die Sie für ein erfolgreiches Projekt leisten können.