Wie bauen Sie ein digitales Produkt, wenn Sie nur 1 Entwicklerteam und 1 Fachbereich haben?

Ein digitales Produkt mit nur einem Entwicklerteam und einem Fachbereich aufzubauen, ist vor allem eine Frage der konsequenten Priorisierung. Entscheidend ist nicht, möglichst viele Funktionen gleichzeitig zu entwickeln, sondern ein konkretes Nutzerproblem zuverlässig zu lösen und daraus zu lernen. Gerade in kleinen und mittleren Unternehmen (KMU) müssen Fachwissen, technische Umsetzung und Produktentscheidungen eng zusammenarbeiten.

Die grösste Herausforderung entsteht häufig nach dem ersten Launch: Das Produkt funktioniert technisch, aber es fehlen strukturierte Erkenntnisse darüber, was Nutzer tatsächlich benötigen und welche Verbesserungen den grössten Nutzen bringen. Deshalb sollte die Produktentwicklung von Anfang an als kontinuierlicher Prozess geplant werden. Ein begrenztes MVP, eine passende Architektur und zwei klar definierte Feedbackkanäle schaffen dafür eine praktikable Grundlage.

Auch die Wahl zwischen Individualentwicklung und Low-Code sowie die Auswahl eines Shopsystems müssen zu den verfügbaren Ressourcen passen. Für Schweizer Unternehmen kommen ausserdem Datenschutzanforderungen und die langfristige Wartbarkeit hinzu.

Warum Ihr digitales Produkt nach dem Launch stagniert, obwohl es fehlerfrei wirkt?

Ein digitales Produkt kann technisch einwandfrei funktionieren und trotzdem stagnieren, wenn das Team nicht erkennt, wie Nutzer es tatsächlich einsetzen. Die entscheidende Frage lautet deshalb nicht nur, ob das System stabil läuft, sondern ob es ein relevantes Problem löst und sich anhand konkreter Erkenntnisse verbessern lässt. Stagnation ist häufig ein Informations- und Priorisierungsproblem, nicht automatisch ein technisches Problem.

Der Unterschied zwischen Launch-Denken und Produktbetriebs-Denken ist dabei wesentlich. Beim Launch konzentriert sich das Team auf Anforderungen, Entwicklung, Tests und Veröffentlichung. Danach beginnt jedoch eine andere Aufgabe: Nutzung beobachten, Probleme verstehen, Hypothesen überprüfen und Änderungen priorisieren.

In kleinen Unternehmen fehlt für diese zweite Phase häufig eine eigene organisatorische Zuständigkeit. Der Fachbereich kennt zwar die betrieblichen Abläufe, die Entwickler verstehen die technische Umsetzung, aber niemand koordiniert systematisch das Lernen nach dem Launch.

**Drei Fragen helfen, eine mögliche Produktstagnation zu erkennen:**

1. **Nutzung der Kernfunktionen:** Wie häufig werden die wichtigsten Funktionen tatsächlich verwendet? Eine Funktion, die nur selten aufgerufen wird, erfüllt möglicherweise nicht die erwartete Aufgabe oder ist schwer auffindbar.
2. **Wiederkehrende Nutzung:** Kommen Nutzer nach ihrer ersten Sitzung zurück? Eine einmalige Nutzung kann für bestimmte Produkte ausreichen, bei regelmässig benötigten Anwendungen ist die Wiederkehr jedoch ein wichtiger Beobachtungspunkt.
3. **Strukturiertes Feedback:** Werden Rückmeldungen dokumentiert, nach Problemen kategorisiert und in konkrete Produktentscheidungen übersetzt?

Diese Fragen sollten nicht isoliert bewertet werden. Eine geringe Nutzung kann beispielsweise bedeuten, dass eine Funktion überflüssig ist, dass der Zugang unklar bleibt oder dass die betreffende Aufgabe nur selten anfällt. Erst der Zusammenhang zwischen Nutzungsdaten und Nutzerbedürfnissen ermöglicht eine belastbare Interpretation.

Der britische Government Digital Service empfiehlt in seiner GOV.UK-Anleitung zur Erfolgsmessung digitaler Dienste, Leistungskennzahlen mit Nutzerforschung zu kombinieren und Verbesserungen auf Erkenntnisse aus beiden Quellen zu stützen. Die Anleitung bezieht sich auf öffentliche digitale Dienste im Vereinigten Königreich, liefert aber eine übertragbare methodische Orientierung für Produktteams. Sie beweist allerdings nicht, dass fehlende Informationen die Hauptursache jeder Produktstagnation sind.

Für ein kleines Team bedeutet das: Es braucht nicht zwingend eine zusätzliche Produktmanagementstelle. Es braucht aber eine klare Aufgabenverteilung. Der Fachbereich formuliert Nutzerprobleme und fachliche Prioritäten, während die Entwicklung die Nutzungsmuster und technischen Rückmeldungen auswertet.

Wenn nach dem Launch niemand für die Auswertung und Priorisierung zuständig ist, bleibt selbst ein technisch erfolgreiches Produkt stehen. Deshalb muss bereits vor der Veröffentlichung geklärt sein, wie das Team Erkenntnisse sammelt und in Verbesserungen umsetzt. Der nächste Schritt ist ein MVP, dessen Umfang diese Lernphase überhaupt ermöglicht.

Wie schneiden Sie ein MVP so zu, dass es in 8 Wochen echten Nutzen liefert?

Ein MVP sollte genau eine wichtige Nutzeraufgabe so vollständig abbilden, dass sie mit dem neuen Produkt tatsächlich erledigt werden kann. Entscheidend ist nicht die Anzahl der enthaltenen Funktionen, sondern der Nutzen eines durchgängigen Ablaufs. Ein Zeitraum von acht Wochen kann als Planungsrahmen dienen, ist aber abhängig von technischer Komplexität, Teamgrösse, Integrationen und verfügbaren Ressourcen.

Die wichtigste Scoping-Frage lautet: Welche Aufgabe erledigt der Nutzer heute manuell, umständlich oder mit mehreren voneinander getrennten Werkzeugen?

Ein MVP sollte genau diesen problematischen Arbeitsschritt ersetzen. Funktionen, die für den Kernablauf nicht erforderlich sind, werden zunächst zurückgestellt.

Dabei ist zwischen einem Minimum Viable Product und einer Minimum Sellable Version zu unterscheiden. Ein MVP dient dazu, eine Lösung unter realen Bedingungen zu testen und Erkenntnisse zu gewinnen. Eine verkaufsfähige Version benötigt dagegen zusätzlich jene Eigenschaften, die für einen verlässlichen kommerziellen Einsatz erforderlich sind. Dazu können beispielsweise ein stabiler Betrieb, geeignete Zugriffsrechte oder notwendige Abrechnungsprozesse gehören.

Im B2B-Umfeld der Schweiz muss ein MVP nicht jede denkbare Funktion enthalten. Es muss jedoch für den vorgesehenen Anwendungsfall ausreichend funktionieren. Ein klarer Nutzen pro Nutzungssitzung ist wichtiger als eine umfangreiche, aber unvollständige Funktionssammlung.

**Ein möglicher Acht-Wochen-Rahmen sieht so aus:**

Dieser Ablauf ist eine Planungsorientierung, keine durch die bereitgestellten Quellen nachgewiesene Garantie für eine Fertigstellung innerhalb von acht Wochen. Besonders bei externen Schnittstellen, komplexen Berechtigungen oder umfangreicher Datenmigration kann der Aufwand deutlich steigen.

Ein häufiger Fehler besteht darin, den Funktionsumfang zu reduzieren, aber die Nutzerreise nicht zu Ende zu denken. Drei halb fertige Funktionen helfen weniger als ein vollständiger Ablauf, bei dem ein Nutzer eine Aufgabe vom Start bis zum Ergebnis erledigen kann.

Ein Beispiel: Ein Unternehmen möchte interne Bestellungen digitalisieren. Ein MVP muss nicht sofort Lieferantenbewertungen, umfangreiche Auswertungen und automatische Freigabeketten enthalten. Es sollte aber ermöglichen, eine Bestellung anzulegen, die erforderlichen Angaben zu erfassen und den vorgesehenen Bearbeitungsstatus nachvollziehbar zu machen.

**Die Grenze zwischen notwendig und später sinnvoll** lässt sich anhand einer einfachen Frage ziehen: Kann der Nutzer seine wichtigste Aufgabe ohne die betreffende Funktion vollständig abschliessen? Wenn ja, gehört die Funktion wahrscheinlich nicht in die erste Version.

Ein MVP reduziert nicht nur Entwicklungsaufwand. Es begrenzt auch das Risiko, Funktionen zu bauen, deren tatsächlicher Nutzen noch unbekannt ist. Sobald der Kernablauf feststeht, stellt sich die nächste Architekturfrage: Soll das Team ihn individuell programmieren oder mit Low-Code umsetzen?

Individuelle Entwicklung oder Low-Code: Was ist besser bei 3 Kernfunktionen?

Bei drei Kernfunktionen ist weder Individualentwicklung noch Low-Code automatisch die bessere Lösung. Low-Code eignet sich häufig für standardisierte Abläufe wie Formulare, Workflows und Datenanzeigen. Individuelle Entwicklung ist besonders dann interessant, wenn eine Funktion den Wettbewerbsvorteil des Produkts trägt und spezifische technische Anforderungen erfüllt werden müssen. Ein Mischmodell kann beide Ansätze verbinden.

Die Entscheidung sollte nicht anhand der Anzahl der Funktionen getroffen werden. Drei einfache Standardprozesse können mit einer Low-Code-Plattform gut abbildbar sein. Eine einzige komplexe Kernfunktion kann dagegen eine individuelle Entwicklung erforderlich machen.

Für ein kleines Team ist deshalb eine Bewertung nach Funktion sinnvoll.

Der wichtigste Trade-off wird bei der langfristigen Produktstrategie sichtbar. Low-Code kann den Einstieg vereinfachen, verlagert aber bestimmte technische Entscheidungen in die Plattform. Datenmodelle, Integrationsmöglichkeiten, Lizenzbedingungen und verfügbare Erweiterungen beeinflussen, wie weit sich das Produkt später verändern lässt.

Individualentwicklung bietet mehr Gestaltungsfreiheit, verursacht aber ebenfalls Aufwand für Entwicklung, Tests, Betrieb und Wartung. Sie ist daher nicht automatisch günstiger oder flexibler.

Microsoft beschreibt in seiner Dokumentation zur Anwendungsmodernisierung mit Power Platform, dass direkt in Low-Code-Anwendungen eingebettete Geschäftslogik vergleichsweise einfach umzusetzen sein kann, jedoch Einschränkungen bei Wiederverwendung und zentraler Durchsetzung von Regeln mit sich bringt.

Die Dokumentation zeigt ausserdem, dass komplexere Logik über zentrale Dienste oder APIs bereitgestellt werden kann. Eine Kombination aus Low-Code-Oberfläche und individuell entwickelten Backend-Komponenten ist technisch möglich. Diese Aussagen beziehen sich auf Microsoft Power Platform und sind nicht pauschal auf alle Low-Code-Produkte übertragbar.

**Ein pragmatisches Mischmodell für kleine Teams:**

– Low-Code für interne Verwaltungsoberflächen und standardisierte Nebenfunktionen.
– Individuelle Entwicklung für die zentrale Funktion, die das Produkt vom Wettbewerb unterscheidet.
– Zentral bereitgestellte Geschäftslogik, wenn Regeln über mehrere Funktionen hinweg konsistent bleiben müssen.
– Ein Proof of Concept, um kritische technische Anforderungen vor der endgültigen Entscheidung zu überprüfen.

Ein weiterer Faktor ist die erwartete Iterationsgeschwindigkeit. Wenn sich eine Kernfunktion aufgrund von Nutzerfeedback häufig ändern wird, muss die gewählte Lösung solche Anpassungen effizient unterstützen. Das gilt unabhängig davon, ob Low-Code oder klassische Programmierung verwendet wird.

Die Auswahl sollte deshalb nicht nur fragen, was sich heute am schnellsten bauen lässt. Sie sollte auch berücksichtigen, wer Änderungen in zwölf Monaten durchführen kann und welche Abhängigkeiten dadurch entstehen.

Ein kleines Team gewinnt durch eine bewusste Kombination beider Ansätze häufig mehr als durch eine ideologische Entscheidung für eine einzige Technologie. Damit diese Flexibilität erhalten bleibt, muss allerdings auch die interne Architektur stimmen. Besonders wichtig ist dabei der Umgang mit veränderbaren Geschäftsregeln.

Der Architekturfehler im MVP, der spätere Änderungen teuer macht

Ein besonders problematischer Architekturfehler entsteht, wenn veränderbare Geschäftsregeln direkt in der Benutzeroberfläche oder tief in einer Kernfunktion verankert werden. Werden Preise, Freigaberegeln oder Prozessbedingungen später geändert, müssen Entwickler dann möglicherweise mehrere Stellen gleichzeitig anpassen. Eine gezielte Trennung veränderbarer Geschäftslogik reduziert diese Abhängigkeit und erleichtert spätere Iterationen.

Der Fehler entsteht häufig aus nachvollziehbaren Gründen. Ein kleines Team möchte möglichst schnell ein funktionierendes Produkt veröffentlichen. Der Fachbereich erklärt die geltenden Regeln mündlich, und die Entwicklung setzt sie direkt dort um, wo sie gerade benötigt werden.

Das funktioniert zunächst. Problematisch wird es, wenn sich die betrieblichen Anforderungen ändern.

Beispielsweise kann ein Unternehmen neue Kundengruppen einführen, Preisregeln anpassen oder einen zusätzlichen Freigabeschritt ergänzen. Wenn die ursprünglichen Regeln an mehreren Stellen im Code oder in der Oberfläche verteilt sind, müssen diese Stellen einzeln gefunden, verändert und erneut getestet werden.

Die Folge ist eine unnötig hohe Abhängigkeit zwischen fachlichen Entscheidungen und technischen Komponenten.

Eine bessere Lösung besteht darin, **veränderbare Geschäftsregeln bewusst von der Darstellung und der eigentlichen Kernfunktion zu trennen**. Das kann durch klar definierte Module, Konfigurationen oder zentrale Dienste erfolgen. Welche Variante sinnvoll ist, hängt von der Komplexität und der Häufigkeit erwarteter Änderungen ab.

Nicht jede Regel benötigt von Anfang an eine eigene technische Architektur. Bei einem MVP ist eine übermässige Modularisierung ebenfalls problematisch, weil sie Entwicklungsaufwand erzeugt, ohne einen entsprechenden Nutzen zu liefern.

Entscheidend ist deshalb die Wahrscheinlichkeit künftiger Änderungen.

**Der Änderungstest hilft bei der Einschätzung:**

Das Team nimmt drei typische Veränderungen und prüft, welche Komponenten betroffen wären:

– Eine neue Kundengruppe erhält andere Berechtigungen.
– Eine bestehende Preisregel wird angepasst.
– Ein zusätzlicher Prozessschritt wird eingeführt.

Wenn jede Änderung eine umfassende Anpassung der Benutzeroberfläche oder mehrerer voneinander abhängiger Komponenten erfordert, sollte die Architektur überprüft werden.

>

Ein solcher Test muss keine umfangreiche technische Analyse sein. Eine einfache Skizze mit den Komponenten Benutzeroberfläche, Kernfunktion und Geschäftsregeln reicht zunächst aus. Wichtig ist, dass der Fachbereich die fachlichen Änderungen konkret beschreibt und die Entwicklung nachvollziehbar zeigt, welche Teile betroffen wären.

Microsofts technische Dokumentation zur Power Platform beschreibt ebenfalls den Unterschied zwischen direkt eingebetteter Geschäftslogik und zentral bereitgestellten Regeln. Daraus lässt sich die Bedeutung einer bewussten Trennung ableiten, nicht jedoch eine allgemeingültige Regel, dass jede Geschäftslogik ausgelagert werden muss.

Für ein kleines Team ist ein schlanker Architekturansatz sinnvoll: Nur jene Bereiche werden konsequent getrennt, bei denen Änderungen wahrscheinlich sind oder bei denen eine Wiederverwendung erforderlich wird.

Ein MVP benötigt keine komplexe Enterprise-Architektur. Es benötigt aber eine Struktur, die absehbare fachliche Änderungen nicht unnötig teuer macht. Die nächste Voraussetzung für solche Änderungen ist ein verlässlicher Informationsfluss zwischen Nutzern, Fachbereich und Entwicklung.

Wie richten Sie 2 Feedbackkanäle ein, die nicht nur „Feature-Wünsche“ sammeln?

Zwei Feedbackkanäle reichen für einen ersten systematischen Lernprozess: Nutzungsdaten zeigen, was Menschen tatsächlich mit dem Produkt machen, und kurze Problemgespräche erklären, warum sie sich so verhalten. Beide Perspektiven sollten zusammengeführt werden. So priorisiert das Team nicht einfach gewünschte Funktionen, sondern die zugrunde liegenden Nutzerprobleme.

**Kanal 1: Verhaltensdaten aus der Produktnutzung**

Nutzungsdaten zeigen, welche Kernfunktionen aufgerufen werden, an welchen Stellen Nutzer abbrechen und welche Abläufe regelmässig abgeschlossen werden. Sie helfen dabei, Unterschiede zwischen der geplanten und der tatsächlichen Nutzung zu erkennen.

Für ein kleines Team genügt zunächst eine überschaubare Auswahl relevanter Ereignisse. Dazu können gehören:

– Aufruf einer zentralen Funktion.
– Beginn eines wichtigen Arbeitsablaufs.
– Erfolgreicher Abschluss einer Aufgabe.
– Abbruch an einem bestimmten Prozessschritt.

Die Ereignisse sollten bereits bei der Entwicklung des MVP berücksichtigt werden. Eine nachträgliche Instrumentierung kann zusätzliche Anpassungen erfordern.

**Kanal 2: Kurze Problemgespräche mit Nutzern**

Gespräche ergänzen die Verhaltensdaten um den Kontext. Ein Nutzer kann eine Funktion selten verwenden, weil sie schwer verständlich ist, weil sie nicht zum Arbeitsablauf passt oder weil die entsprechende Aufgabe nur gelegentlich anfällt.

Deshalb sollte das Gespräch nicht mit der Frage beginnen, welche neue Funktion gewünscht wird.

Eine bessere Einstiegsfrage lautet: «Was wollten Sie erreichen, als Sie diese Funktion verwendet haben?»

Anschliessend helfen konkrete Nachfragen:

– Wie haben Sie diese Aufgabe bisher erledigt?
– Was hat dabei am meisten Zeit oder Aufwand verursacht?
– An welcher Stelle sind Schwierigkeiten aufgetreten?
– Was haben Sie gemacht, als das Produkt nicht wie erwartet funktioniert hat?

Der Unterschied ist wesentlich: Ein Feature-Wunsch beschreibt eine vermutete Lösung. Das zugrunde liegende Problem beschreibt den tatsächlichen Bedarf.

**So werden beide Kanäle gemeinsam ausgewertet**

Jede Rückmeldung sollte auf das Problem zurückgeführt werden, das sie lösen soll. Ein Wunsch nach einem zusätzlichen Exportformat kann beispielsweise auf ein tiefer liegendes Problem hinweisen: Nutzer müssen Daten manuell in ein anderes System übertragen.

In diesem Fall ist nicht automatisch ein neues Exportformat die beste Lösung. Möglicherweise ist eine bessere Integration sinnvoller.

Für ein kleines Team kann die Aufgabenverteilung einfach bleiben:

– Der Fachbereich organisiert kurze Gespräche und dokumentiert wiederkehrende Probleme.
– Die Entwicklung wertet Nutzungsereignisse aus und identifiziert technische oder funktionale Auffälligkeiten.
– Beide besprechen regelmässig die Ergebnisse und priorisieren die nächsten Verbesserungen.

Der Government Digital Service empfiehlt, quantitative Leistungskennzahlen und qualitative Nutzerforschung gemeinsam zu betrachten. Dieser Ansatz lässt sich auf kleine Produktteams übertragen, ohne dass dafür ein eigenes Research-Team eingerichtet werden muss.

Wichtig ist, dass Datenschutz und Transparenz bei der Datenerhebung berücksichtigt werden. Gerade bei Schweizer digitalen Produkten sollten nur jene Informationen erhoben werden, die für die Verbesserung des Produkts tatsächlich benötigt werden.

Die beiden Kanäle liefern unterschiedliche Erkenntnisse, die sich gegenseitig ergänzen. Allerdings entstehen nicht alle Probleme direkt in der Produktnutzung. Support-Anfragen können zusätzliche Hinweise liefern, wenn sie systematisch ausgewertet und den gleichen Kernaufgaben zugeordnet werden.

Wie werten Sie 200 Support-Tickets aus, ohne ein Research-Team zu haben?

200 Support-Tickets lassen sich auch ohne Research-Team systematisch auswerten, wenn sie nach ihrer Problemursache statt nur nach Themen oder Funktionen kategorisiert werden. Eine Stichprobe, ein gemeinsames Kategorienschema und ein fester wöchentlicher Auswertungszeitraum reichen für einen ersten Überblick. Die Ergebnisse sollten anschliessend in eine kurze monatliche Priorisierung einfliessen.

Support-Tickets enthalten wertvolle Hinweise auf Schwierigkeiten bei der Produktnutzung. Ihr tatsächlicher Nutzen hängt jedoch davon ab, wie die Informationen ausgewertet werden.

Eine Liste mit Kategorien wie «Login», «Export» oder «Dashboard» zeigt zunächst nur, welche Produktbereiche betroffen sind. Sie erklärt nicht, warum Nutzer Schwierigkeiten haben.

Eine ursachenorientierte Einordnung liefert mehr Erkenntnisse.

**Vier Kategorien bilden einen praktikablen Einstieg:**

Diese Unterscheidung verhindert, dass jedes wiederkehrende Ticket automatisch zu einer neuen Funktion führt. Wenn beispielsweise viele Nutzer dieselbe Funktion nicht finden, muss möglicherweise die Navigation verbessert werden. Eine zusätzliche Funktion würde das eigentliche Problem nicht lösen.

**Warum 200 Tickets nicht das vollständige Nutzerbild zeigen**

Support-Daten haben eine wichtige Einschränkung: Sie repräsentieren vor allem jene Personen, die sich aktiv melden. Nutzer, die Schwierigkeiten haben und das Produkt anschliessend nicht mehr verwenden, tauchen möglicherweise überhaupt nicht in den Tickets auf.

Deshalb dürfen Support-Anfragen nicht als alleinige Datenquelle verwendet werden. Sie ergänzen die beiden Feedbackkanäle aus dem vorherigen Abschnitt, ersetzen sie aber nicht.

Ein weiteres Problem entsteht, wenn Tickets unabhängig von den tatsächlichen Kernaufgaben kategorisiert werden. Dann entstehen drei getrennte Informationssammlungen: Nutzungsdaten, Gesprächsnotizen und Support-Auswertungen. Ohne gemeinsame Zuordnung lassen sich daraus nur schwer Produktentscheidungen ableiten.

>

**Eine schlanke Auswertung neben dem Tagesgeschäft**

Für die Analyse ist keine vollständige Bearbeitung aller Tickets in einem einzigen Schritt erforderlich. Eine praktikable Vorgehensweise besteht darin, eine Stichprobe zu betrachten und die Kategorien gemeinsam mit der Entwicklung abzustimmen.

Anschliessend wird ein fester wöchentlicher Zeitraum für die Sichtung reserviert. Die Ergebnisse können in einer einfachen Tabelle festgehalten werden, die Problemursache, betroffene Kernaufgabe und beobachtete Häufigkeit dokumentiert.

Einmal monatlich entsteht daraus eine kurze Priorisierungsliste. Sie sollte nicht nur die häufigsten Probleme enthalten, sondern auch deren Bedeutung für den Nutzer und den betroffenen Arbeitsablauf berücksichtigen.

Auch ohne Research-Team kann der Fachbereich so regelmässig belastbare Hinweise für die Weiterentwicklung liefern. Diese Vorgehensweise ist ebenfalls für die Auswahl eines Shopsystems relevant: Entscheidend sind nicht nur die Funktionen beim Kauf, sondern auch die Möglichkeiten, ein Produkt nach dem Start kontinuierlich anzupassen.

Wie wählen Sie ein Shop-System mit 8 Praxis-Kriterien statt Feature-Liste?

Ein Shopsystem sollte nicht anhand der längsten Feature-Liste ausgewählt werden, sondern anhand seiner Eignung für den konkreten Betrieb und die Weiterentwicklung des Unternehmens. Acht Kriterien helfen dabei: Anpassbarkeit, Integration, Wartungsaufwand, Gesamtkosten, Wechselmöglichkeiten, Entwicklerverfügbarkeit, Update-Stabilität und rechtliche Anforderungen. Besonders für kleine Teams ist entscheidend, ob das System auch nach dem Go-live beherrschbar bleibt.

Ein Funktionsvergleich zeigt, was eine Plattform heute bietet. Eine fundierte Systementscheidung muss dagegen beantworten, wie sich das Unternehmen in den kommenden zwölf Monaten verändern kann.

Ein Shopsystem kann zum Start überzeugen und später zum Engpass werden, wenn sich Preisregeln nur mit hohem Entwicklungsaufwand ändern lassen, Schnittstellen fehlen oder Updates bestehende Anpassungen beeinträchtigen.

Die folgenden acht Kriterien bilden deshalb eine praxisorientierte Bewertungsgrundlage.

**1. Anpassbarkeit der Kernfunktionen**

Kann das Unternehmen jene Funktionen verändern, die sein Geschäftsmodell ausmachen? Prüfen Sie insbesondere, wie sich Preise, Produktvarianten, Bestellabläufe und kundenspezifische Regeln anpassen lassen.

Testfragen:
– Wie wird eine neue Preisregel umgesetzt?
– Können zentrale Abläufe ohne umfassende Individualentwicklung angepasst werden?
– Welche Anpassungen benötigen externe Entwickler?

**2. Anschlussfähigkeit an bestehende Systeme**

Ein Shop ist selten eine isolierte Anwendung. ERP, Lagerverwaltung, Buchhaltung und weitere Systeme können angebunden werden müssen.

Testfragen:
– Welche standardisierten Schnittstellen stehen zur Verfügung?
– Wie werden Bestände und Bestellungen synchronisiert?
– Wie lassen sich Fehler bei der Datenübertragung erkennen?

**3. Betriebs- und Wartungsaufwand**

Ein kleines Team kann nicht unbegrenzt Zeit für technische Administration aufwenden. Hosting, Updates, Sicherheitsmassnahmen und Fehlerbehebung müssen deshalb realistisch eingeschätzt werden.

Testfragen:
– Wer ist für Betrieb und Wartung verantwortlich?
– Welche Aufgaben bleiben beim Unternehmen?
– Wie aufwendig ist die Behebung eines typischen Fehlers?

**4. Total Cost of Ownership statt Lizenzpreis**

Die monatliche Lizenz ist nur ein Teil der Gesamtkosten. Hinzu kommen Einrichtung, Erweiterungen, Schnittstellen, Betrieb, Wartung und gegebenenfalls externe Unterstützung.

Testfragen:
– Welche einmaligen Einführungskosten entstehen?
– Welche wiederkehrenden Zusatzkosten fallen an?
– Wie verändern sich die Kosten bei mehr Produkten oder Bestellungen?

**5. Migrationsweg bei einem späteren Wechsel**

Eine Plattform sollte nicht nur beim Einstieg überzeugen. Ebenso wichtig ist die Frage, wie Daten und Prozesse später übertragen werden können.

Testfragen:
– Lassen sich Produktdaten und Kundendaten exportieren?
– Welche Formate stehen zur Verfügung?
– Welche Abhängigkeiten erschweren einen Plattformwechsel?

**6. Verfügbarkeit von Entwicklern im Markt**

Ein Shopsystem kann technisch leistungsfähig sein und dennoch ungeeignet werden, wenn die notwendigen Fachkräfte schwer verfügbar sind.

Testfragen:
– Gibt es externe Entwickler mit Erfahrung auf der Plattform?
– Können mehrere Dienstleister die Wartung übernehmen?
– Ist die Dokumentation für neue Entwickler ausreichend?

**7. Updates ohne Funktionsbruch**

Regelmässige Aktualisierungen sind für Sicherheit und Stabilität wichtig. Gleichzeitig dürfen individuelle Anpassungen nicht bei jeder Aktualisierung neu aufgebaut werden müssen.

Testfragen:
– Wie werden Updates angekündigt und dokumentiert?
– Können Erweiterungen vorab in einer Testumgebung geprüft werden?
– Welche Auswirkungen haben Aktualisierungen auf Schnittstellen?

**8. Rechtliche Anforderungen in der Schweiz**

Das System muss die relevanten datenschutzrechtlichen Anforderungen und die betrieblichen Anforderungen des Schweizer Unternehmens unterstützen. Dabei sollten Datenbearbeitung, Informationspflichten, Zugriffsmöglichkeiten und eingesetzte Dienstleister betrachtet werden.

Testfragen:
– Welche Personendaten werden verarbeitet und zu welchem Zweck?
– Welche technischen und organisatorischen Schutzmassnahmen sind vorhanden?
– Welche Informationen werden für die Erfüllung der Datenschutzpflichten benötigt?

Das Schweizer Datenschutzgesetz (DSG) ist dabei ein zentraler Bezugspunkt. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte erläutert in seinen Erläuterungen des EDÖB zum Schweizer Datenschutzgesetz insbesondere Privacy by Design und Privacy by Default.

Diese Grundsätze bedeuten, dass Datenschutz bereits bei der Konzeption eines digitalen Produkts berücksichtigt werden muss. Bei geplanten Datenbearbeitungen mit potenziell hohem Risiko kann ausserdem eine Datenschutz-Folgenabschätzung erforderlich sein. Ob konkrete Pflichten greifen, hängt von der jeweiligen Datenbearbeitung ab.

Ein wichtiger Punkt: Das Schweizer Datenschutzrecht begründet keine allgemeine Pflicht, sämtliche Daten ausschliesslich in der Schweiz zu speichern. Die konkrete Anbieter- und Hostingwahl muss anhand der tatsächlichen Datenbearbeitung und der einschlägigen Anforderungen geprüft werden.

**Die Kriterien in einer einheitlichen Bewertung zusammenführen**

Für die Auswahl empfiehlt sich eine einfache Bewertungsmatrix. Jedes Kriterium erhält eine Bewertung anhand der praktischen Tests, die der Anbieter oder eine Testinstallation ermöglichen.

Die Bewertung sollte sich auf konkrete Nachweise stützen. Eine allgemeine Anbieterzusage ist weniger aussagekräftig als ein praktisch demonstrierter Ablauf, beispielsweise die Anpassung einer Preisregel oder der Export von Produktdaten.

Die beste Plattform ist nicht zwangsläufig die mit den meisten Funktionen. Für ein kleines Team zählt vor allem, ob die wichtigsten Geschäftsprozesse zuverlässig abgebildet werden und spätere Veränderungen ohne unverhältnismässigen Aufwand möglich bleiben. Besonders konkret wird diese Entscheidung, wenn der Shop innerhalb von acht Wochen mit 200 Produkten online gehen soll.

Welches E-Commerce-Shop-System passt, wenn Sie in 8 Wochen live gehen müssen und 200 Produkte haben?

Bei 200 Produkten und einem geplanten Go-live innerhalb von acht Wochen ist häufig ein standardisiertes Shopsystem sinnvoll, sofern die Anforderungen an Produktdaten, Bestellungen und Zahlungsprozesse überschaubar bleiben. Entscheidend ist jedoch, ob das Geschäftsmodell eine besondere Kernfunktion benötigt oder umfangreiche Integrationen mit bestehenden Systemen voraussetzt. Die Plattform muss sowohl den schnellen Einstieg als auch die anschliessende Weiterentwicklung ermöglichen.

Die Kombination aus 200 Produkten und acht Wochen ist eine konkrete Ausgangssituation. Der Produktumfang ist grundsätzlich überschaubar genug, um eine strukturierte Datenmigration und Produktpflege durch einen Fachbereich zu planen. Gleichzeitig ist er gross genug, dass eine saubere Produktstruktur von Beginn an wichtig wird.

Dazu gehören beispielsweise:

– Einheitliche Produktbezeichnungen und Beschreibungen.
– Eindeutige Artikelnummern.
– Konsistente Produktkategorien.
– Vollständige Preise und Produktvarianten.
– Zuordnung von Bildern und relevanten Produktinformationen.

Eine fehlerhafte Datenstruktur kann später zu unnötigem Pflegeaufwand führen. Deshalb sollte der Produktimport nicht als nebensächlicher Arbeitsschritt behandelt werden.

**Die acht Wochen verändern die Auswahlprioritäten**

Bei einem knappen Zeitrahmen sollte die Einführung möglichst viele standardisierte Prozesse nutzen. Eine Plattform, die bereits passende Funktionen für Produktverwaltung, Bestellungen und grundlegende Shop-Prozesse bereitstellt, kann die Einführung vereinfachen.

Das bedeutet allerdings nicht, dass Individualisierung grundsätzlich ausgeschlossen ist. Wenn eine bestimmte Funktion das Geschäftsmodell differenziert, muss sie früh identifiziert werden. Andernfalls droht das Unternehmen, eine Plattform zu wählen, die zwar schnell live geht, aber den entscheidenden Wettbewerbsvorteil nicht unterstützt.

Drei Szenarien helfen bei der Einordnung.

**Produktimport und Datenmigration praktisch prüfen**

Ein Beispiel ist Shopify. Die offizielle Dokumentation beschreibt einen CSV-basierten Produktimport. Dieser kann für die Übertragung zahlreicher Produktdatensätze und für umfangreiche Änderungen genutzt werden.

Die Shopify-Dokumentation zum CSV-Produktimport nennt konkrete Anforderungen an Dateiformat und Importprozess. Dazu gehören eine UTF-8-Kodierung, die korrekte Spaltenstruktur und eine maximale Dateigrösse von 15 MB für den beschriebenen Import.

Shopify empfiehlt ausserdem, Produktdaten vor dem Import zu sichern und bei umfangreichen Vorhaben zunächst einen Test mit einer kleineren Datenmenge in einem Entwicklungs-Shop durchzuführen.

Das ist ein relevanter technischer Nachweis für die Produktdatenmigration, aber kein Beleg dafür, dass ein vollständiger Onlineshop mit 200 Produkten automatisch innerhalb von acht Wochen eingerichtet werden kann. Zahlungsprozesse, Versand, Steuern, Schnittstellen, rechtliche Anforderungen und Qualitätssicherung müssen zusätzlich geplant werden.

**Der Go-live ist der Beginn der Produktentwicklung**

Ein Shopsystem muss nicht nur für die erste Veröffentlichung geeignet sein. Es muss auch danach durch das vorhandene Team betrieben und weiterentwickelt werden können.

Gerade bei einem kleinen Team sollten deshalb vor der Entscheidung folgende Fragen beantwortet sein:

– Wer pflegt Produktdaten und Kategorien?
– Wer bearbeitet technische Fehler?
– Wie werden neue Anforderungen priorisiert?
– Wie werden Schnittstellen und Datenübertragungen kontrolliert?
– Wie können Änderungen vor der Veröffentlichung getestet werden?
– Welche externen Kompetenzen werden dauerhaft benötigt?

Ein häufiger Planungsfehler besteht darin, den gesamten Aufwand auf den Go-live auszurichten. Wenn anschliessend keine Ressourcen für Fehlerkorrekturen und Verbesserungen vorgesehen sind, entsteht genau die Stagnation, die bereits bei digitalen Produkten ohne E-Commerce-Bezug auftreten kann.

Für die Schweiz müssen zudem die relevanten Anforderungen an Datenschutz, Vertragsinformationen und weitere geschäftliche Prozesse geprüft werden. Die Auswahl einer international verfügbaren Plattform ersetzt diese Prüfung nicht.

Bevor die technische Entscheidung endgültig getroffen wird, sollten die 200 Produktdatensätze testweise importiert, die wichtigsten Bestellabläufe geprüft und kritische Integrationen praktisch validiert werden. So entsteht eine realistische Grundlage für einen Go-live innerhalb des vorgesehenen Zeitrahmens. Der entscheidende Erfolg ist nicht nur die Veröffentlichung nach acht Wochen, sondern ein Shopsystem, das dasselbe kleine Team anschliessend zuverlässig weiterentwickeln kann.