Womit beginnt eine PSA-Einführung?

Mit Datenbereinigung statt Konfiguration. Doppelte Kunden, nur in E-Mails vorhandene Sätze und nie archivierte Altprojekte verzögern die Einführung. Eine Woche Bereinigung vor dem Auftakt ist mehr wert als ein Monat nachträgliche Konfiguration.

Wer sollte das Projekt verantworten?

Eine interne Person mit Befugnis über Prozesse und Daten, meist die operative Leitung. Ein Gremium ohne Verantwortung erzeugt Meetings, Verantwortung ohne Befugnis Eskalationen. Der Anbieter konfiguriert, entscheidet aber nicht, was Ihr Unternehmen als aktives Projekt definiert.

Welche Daten werden migriert und welche nicht?

Migrieren Sie, was Sie morgen für Entscheidungen brauchen: aktive Kunden, offene Projekte, aktuelle Sätze, Personen und Verfügbarkeit. Verlauf lohnt sich für echte Vergleiche, andernfalls archivieren Sie ihn separat. Zehn Jahre ungeprüfter Daten übertragen nur Unordnung und erschweren die Nutzung.

Wie sollte der Pilot aufgebaut sein?

Ein Team oder Fachbereich, ein vollständiger Zyklus vom Vertrag bis zur Rechnung, vier bis sechs Wochen und wöchentliche Ausnahmeprüfung. Schreiben Sie das Erfolgskriterium zuerst auf, etwa einen Abschluss ohne manuelle Abstimmung außerhalb des Systems. Ohne schriftliches Kriterium bleibt nur eine Meinung.

Woran erkennt man erfolgreiche Nutzung?

Nicht an gefüllten Feldern, sondern an drei Signalen: Entscheidungen anhand des Systems statt separater Tabellen, manuell korrigierte Ausnahmen und Personen, die das alte Werkzeug nicht mehr nutzen. Der dritte Punkt ist am schwersten und am ehrlichsten.

PSA-Einführung: Checkliste von Daten bis Nutzung

Eine PSA-Einführung verändert das Betriebsmodell mithilfe von Software. Erfolg entsteht, wenn Vertrieb, Projektumsetzung, Finanzen und Personal dieselben Definitionen nutzen und das neue System verlässliche Entscheidungen ermöglicht. Diese Checkliste beschreibt die dafür nötige Reihenfolge, Nachweise und Zuständigkeiten.

Phase 1: Verantwortung und Erfolg definieren

Benennen Sie einen Sponsor aus der Leitung und je kritischem Ablauf einen internen Verantwortlichen: Vertriebsübergabe, Ressourcenverteilung, Zeitfreigabe, Projektwirtschaftlichkeit und Abrechnung. Das Einführungsteam kann die Plattform einrichten; was „korrekt“ bedeutet, entscheiden die fachlich Verantwortlichen.

Wählen Sie vor der Konfiguration wenige Erfolgsmaße. Beispiele sind Rechnungsdurchlaufzeit, Anteil der pünktlich freigegebenen Zeitnachweise, Projekte mit aktueller Prognose und Vorbereitungsstunden für die Besetzungsbesprechung. Halten Sie Ausgangswert und Zieltermin fest.

Phase 2: Entscheidungen und Mindestabläufe abbilden

Beschreiben Sie die zu unterstützenden Entscheidungen statt jeder historischen Ausnahme. Beginnen Sie bei der qualifizierten Verkaufschance und folgen Sie bis zum besetzten Projekt, freigegebenen Stunden, bestätigten Leistungen und der Rechnung. Dokumentieren Sie je Übergabe Eingangskriterien, Verantwortung, Pflichtfelder und Kontrolle.

Trennen Sie Startanforderungen von späteren Verbesserungen. Ein häufiger Fehler ist, jahrelange Tabellenanpassungen nachzubauen, bevor Benutzer einen Standardzyklus abgeschlossen haben. Bewahren Sie ein funktionsfähiges Mindestmodell und ergänzen Sie Ausnahmen erst bei belegter Häufigkeit und Bedeutung.

Phase 3: Daten vorbereiten und migrieren

Erstellen Sie ein Datenverzeichnis mit Quelle, Verantwortung, Felddefinition, Qualitätsproblem, Aufbewahrungsregel und Ziel. Bereinigen Sie Kunden, Personen, Kompetenzen, Sätze, Projekte und Anfangsbestände vor dem Import. Übernehmen Sie keine doppelten oder veralteten Datensätze und keine Daten ohne verantwortliche Person allein zu Archivzwecken.

Führen Sie mindestens zwei Probeläufe durch. Gleichen Sie nach jedem Import Datensatzanzahl und Stichproben betrieblicher Summen ab, etwa aktive Projekte, Vertragswerte, Kostensätze und nicht fakturierte Leistungen. Protokollieren Sie Umwandlungen, damit Finanzen und Betrieb jede Anfangszahl erklären können.

Phase 4: Kontrollen und Integrationen einrichten

Richten Sie Rollen nach Aufgaben und minimal nötigen Rechten ein. Testen Sie den Zugriff auf Kostensätze, Kandidatendaten, Vertragsbedingungen und Finanzexporte. Definieren Sie Vertretungen bei Freigaben, Prüfverlauf und Abläufe für Eintritt, Rollenwechsel und Austritt.

Testen Sie Integrationen als vollständige Szenarien statt einzelner API-Aufrufe. Verfolgen Sie eine Verkaufschance bis zu Projektanlage, Besetzung, Zeitfreigabe und Abrechnung, einschließlich Fehler und Wiederholung. Halten Sie je Feld das maßgebliche Quellsystem fest, um unbemerkte Überschreibungen zu vermeiden.

Phase 5: Einen vollständigen Geschäftszyklus testen

Wählen Sie einen repräsentativen Pilot mit genügend Projekten und Vertragsarten zur Problemerkennung, aber überschaubar genug für tägliche Unterstützung. Beziehen Sie eine unterstützende Führungskraft und mindestens einen skeptischen Benutzer ein. Bearbeiten Sie echte Arbeit und proben Sie den Monatsabschluss vor der Ausweitung.

Führen Sie eine sichtbare Problemliste mit Schweregrad, Verantwortlichem, Entscheidung und Frist. Unterscheiden Sie Konfigurationsfehler, schlechte Quelldaten, unklare Regeln und Schulungslücken. Die falsche Problemart durch zusätzliche Softwareanpassungen zu behandeln, schafft dauerhafte Komplexität.

Phase 6: Start, Nutzung und Stabilisierung

Veröffentlichen Sie rollenbezogene Anleitungen zu tatsächlichen Aufgaben. Geben Sie Führungskräften Ansichten für offene Freigaben und Ausnahmen. Bieten Sie in den ersten Zyklen kurze Sprechstunden an, beantworten Sie Fragen im Arbeitsablauf und aktualisieren Sie die gemeinsame Anleitung.

Definieren Sie Abschaltkriterien für Parallelsysteme: zwei abgestimmte Abrechnungszyklen, vereinbarte Datenqualität und keine offene kritische Kontrolle. Prüfen Sie Nutzung und Ergebnisse 30, 60 und 90 Tage nach dem Start. Der PSA-Preisleitfaden hilft, den Einführungsaufwand im genehmigten TCO zu halten.

Abschließende Startcheckliste

Bestätigen Sie vor dem Start Verantwortung, Rechte, migrierte Salden, Integrationsüberwachung, Sicherung und Export, Supportkontakte, Abschlussprobe und Rückfallschritte. Jeder kritische Punkt braucht Belege und einen benannten Freigeber. Die Aussage des Anbieters, alles sei bereit, ist kein Abnahmetest.

Schließen Sie das Projekt erst nach Übergabe an den Regelbetrieb. Halten Sie Verbesserungen in einer priorisierten Liste fest, planen Sie vierteljährliche Datenqualitätsprüfungen und lassen Sie Definitionen zugänglich. Ein PSA wird durch konsequente Betriebsdisziplin wertvoll, nicht durch den Starttag allein.

Frühe Anzeichen einer abdriftenden Einführung

Vier Signale zeigen sich vor dem Problem im Plan. Erstens tauchen wieder parallele Tabellen für bereits unterstützte Entscheidungen auf, weil Daten fehlen oder nicht vertraut werden. Zweitens wächst die Anpassungsliste schneller als ihre Erledigung, fast immer als Symptom ungeklärter Regeln. Drittens finden Projektbesprechungen nur mit externen Beratern und IT statt, ohne Fachverantwortliche. Viertens bleibt der Starttermin fest, während der Umfang wächst.

Zusatzstunden lösen keines dieser vier Probleme. Nötig sind eine fachliche Entscheidung, weniger Startumfang oder eine transparent verschobene Einführung.

Was tun, wenn der Pilot nicht funktioniert?

Ein schlechter Pilot liefert günstig Erkenntnisse, sofern er nicht als endgültiges Produkturteil gelesen wird. Ordnen Sie Probleme zunächst in Konfiguration, Quelldaten, unklare Regeln und Schulung ein und vergleichen Sie die Anteile. Überwiegen Daten und Regeln, ist interne Klärung ohne Systemänderung nötig. Überwiegen echte Defekte, braucht es Gespräche mit dem Anbieter und wahrscheinlich einen späteren Start.

Teuer wird der Mittelweg, trotzdem zu starten und später Korrekturen zu versprechen. Das Altsystem bei offenen Problemen abzuschalten nimmt dem Monatsabschluss das Sicherheitsnetz. Verlorenes Teamvertrauen wiederherzustellen kostet weit mehr als ein Monat Aufschub. Halten Sie den Rückfallplan dokumentiert und getestet, bis zwei vollständige Zyklen sauber abgeschlossen sind.