Die Produktbezeichnung ist weniger wichtig als Nutzer, Prozess, Daten, Nutzungshäufigkeit und Verantwortung für den Betrieb nach dem Start.

Die kurze Antwort

Wählen Sie ein Portal für externe Nutzer mit Zugangs- und Self-Service-Bedarf, eine Webanwendung für interaktive Abläufe, Automatisierung für Systemschritte und Individualsoftware, wenn ein besonderer Prozess eigene Software rechtfertigt.

Der nächste Schritt ist, Entscheidung, Verantwortung und akzeptierte Nachweise zu klären, bevor ein Werkzeug gewählt wird.

Das Entschei­dungs­modell

01. Nutzer

Klären Sie, wer das Produkt wie häufig und mit welchen Rechten nutzt.

02. Prozess

Erfassen Sie Zustände, Regeln, Ausnahmen und Verantwortliche.

03. Integration

Bestimmen Sie die maßgebliche Datenquelle, APIs und den Abgleich.

04. Betrieb

Berücksichtigen Sie Hosting, Sicherheit, Support, Überwachung und Backlog.

Anwendung in der Praxis

01. Ausgangslage

Beschreiben Sie zunächst Nutzer und ihre zu erledigenden Aufgaben. Ein Portal stellt Kunden oder Partnern Informationen und Zustände bereit; eine Webanwendung unterstützt interaktive Abläufe; Individualsoftware kann eigene Regeln, Rollen und Integrationen koordinieren. Die Produktbezeichnung ist weniger wichtig als Anwendungsbereich, Häufigkeit, Komplexität und die Folgen eines Fehlers.

02. Kontrol­lierte Ausführung

Validieren Sie den kritischen Ablauf, bevor Sie das gesamte Produkt entwickeln. Ein Prototyp kann Navigation und Begriffe testen; ein durchgängiger Ausschnitt verbindet Oberfläche, Logik und Daten für einen vollständigen Fall. So werden tatsächliche Abhängigkeiten sichtbar, ohne monatelang isoliert zu entwickeln. Berücksichtigen Sie Authentifizierung, Rollen, Audit und Datenmigration von Anfang an: Sie beeinflussen die Architektur und sind kein bloßer Feinschliff.

03. Aussage­kräftige Nachweise

Messen Sie Erfolg anhand von Aufgabenerfüllung, Fehlern, Zeit, Nutzung und operativer Wirkung. Gelieferte Funktionen oder angelegte Nutzer beweisen keinen Wert. Beobachten Sie Abbrüche, Excel-Exporte und Aufgaben, die außerhalb des Produkts erledigt werden. Diese Umwege weisen auf Lücken bei Prozessen, Vertrauen oder Flexibilität hin, die einfache Analytics nicht erklären.

04. Entschei­dungs­schwelle

Wählen Sie ein vorhandenes Produkt, wenn es den Kernprozess abdeckt und sich konfigurieren lässt, ohne Ihren Wettbewerbsvorteil zu blockieren. Entwickeln Sie individuell, wenn Regeln, Erlebnis, Integration oder Datenhoheit einen Vorteil schaffen und Wartung rechtfertigen. Berücksichtigen Sie mehrjährige Kosten, Betrieb, Sicherheit und die Person, die das Produkt nach dem Start priorisiert, statt nur das Budget der ersten Version.

Szenario und Arbeitsplan

01. Diagnose­beispiel

Ein Unternehmen fragt nach einem Kundenportal, doch Interviews zeigen als Hauptproblem einen uneinheitlichen Status zwischen E-Mail, Tabellen und internem System. Eine neue Oberfläche ohne geklärte Daten verlagert die Verwirrung lediglich in ein neues Design. Der erste durchgängige Ausschnitt kann einen Fall abdecken: Anmeldung, Anzeige einer Anfrage, Dokument-Upload und Bestätigung durch einen Mitarbeitenden. Er testet Datenmodell, Rollen, Benachrichtigungen und Audit vor der Erweiterung um Berichte und Automatisierung.

02. Um­setzungs­plan

Der Plan beginnt mit Discovery und Prototyp, gefolgt von einem technischen Grundgerüst und einer nutzbaren Version für eine kleine Gruppe. Definieren Sie Migration, Sicherheit, Backup, Support und Beobachtbarkeit frühzeitig. Erfassen Sie Bearbeitungszeit, Fehler, Supportanfragen und außerhalb des Produkts erledigte Schritte. Priorisieren Sie neue Funktionen nach Wert und Häufigkeit statt nach der ursprünglichen Liste. Individualsoftware bleibt eine laufende Investition. Ohne Verantwortliche und Betriebsbudget erhöht jede neue Funktion das Risiko, statt den Vorteil zu stärken.

03. Entschei­dungs­protokoll

Damit die Empfehlungen aus „Webanwendung, Portal oder Individualsoftware: das passende Produkt wählen“ nachvollziehbar bleiben, führen wir vor der ersten Änderung ein einfaches Protokoll ein. Es enthält das beobachtete Problem, die Ausgangslage, Hypothese, verantwortliche Person, Bewertungszeitraum sowie die Bedingung für Fortsetzung oder Stopp. Nachweise kommen aus geeigneten Quellen; technische Kennzahlen werden von Geschäftsergebnissen getrennt. Zuerst betrachten wir Nutzung und Aufgabenerfüllung zusammen mit Datenqualität, Gesamtkosten und späteren Auswirkungen. So wird eine Entscheidung erklärbar und wiederholbar, statt nur aus einem günstigen Dashboard abgeleitet.

04. Review und nächste Entscheidung

Am Zyklusende vergleichen wir Ergebnis und Ausgangslage und dokumentieren Änderungen, Unsicherheiten und Nebenwirkungen. Wir prüfen ausdrücklich „Die Standardlösung wurde bewertet“ und „Der kritische Ablauf ist ausreichend stabil“. Reichen die Daten nicht für eine Schlussfolgerung, bleibt die Hypothese offen. Das Risiko „Auswahl nach Funktionsliste“ bleibt im Review sichtbar, damit Fortschrittsdruck die Analyse nicht verdrängt. Den nächsten Schritt wählen wir erst, wenn das Team seine Erkenntnisse und den Vorrang der neuen Priorität gegenüber Alternativen erklären kann.

Checkliste vor der Umsetzung

  • Die Standardlösung wurde bewertet.
  • Der kritische Ablauf ist ausreichend stabil.
  • Nutzer beteiligen sich an Discovery.
  • Daten und Berechtigungen sind bekannt.
  • Ein Betriebsbudget ist vorhanden.
  • Erfolgskriterien sind messbar.

Was wir messen

Kennzahlen werden vor dem Start definiert und unterscheiden technische Signale von bestätigten Ergebnissen.

  • Nutzung und Aufgabenerfüllung;
  • Zeit und Fehler pro Ablauf;
  • Verfügbarkeit und Vorfälle;
  • Gesamtbetriebskosten.

Fehler und Grenzen

  • Auswahl nach Funktionsliste.
  • Alle Rollen gleich zu Beginn entwickeln.
  • Migration und Support ignorieren.
  • Individualsoftware für einen instabilen Prozess.

Fazit

Validieren Sie den kleinsten vollständigen Ablauf, der Wert schafft. Die Produktform ergibt sich, wenn Prozess, Nutzer und Betrieb verstanden sind.