So wählen Sie ein Team für die Softwareentwicklung aus

Was müssen Sie nach dem gescheiterten Projekt klären?

Beginnen Sie mit einer kurzen internen Analyse. Stellen Sie den Vertrag, das Angebot, die technische Dokumentation, die Zugangsdaten, den Code, die Designs und die Liste der zugesagten Funktionen zusammen. Halten Sie fest, was tatsächlich funktioniert, was fehlt und was nicht mehr zu Ihren Prozessen passt.

Gehen Sie nicht davon aus, dass das Problem nur in der Programmierung liegt. Ein gescheitertes Projekt beginnt oft mit einer unklaren Aufgabenstellung, sich ändernden Anforderungen, dem Fehlen eines Ansprechpartners auf Kundenseite oder dem Versprechen eines festen Zeitplans ohne ausreichende Informationen. Manchmal ist der Code gut, aber es gibt keine Integration in die Buchhaltung, das Lager bildet die tatsächlichen Abläufe nicht ab oder die Mitarbeiter können das System nicht bedienen.

Bereiten Sie eine Liste konkreter Fragen vor: Was hat sich während des ersten Projekts geändert? Wer hat die Entscheidungen genehmigt? Wie wurden die Funktionen abgenommen? Wann haben Sie erkannt, dass der Zeitplan nicht eingehalten werden würde? Hatten Sie Zugriff auf den Code und die Daten? Gab es eine Testumgebung und Backups?

Welche Fragen sollten Sie dem potenziellen Team stellen?

Das erste Gespräch sollte keine reine Präsentation des Portfolios sein. Es sollte zeigen, wie das Team denkt. Geben Sie ihm eine Beschreibung des Prozesses, den Sie verbessern möchten, und nicht nur eine Liste von Schaltflächen und Bildschirmen.

• Welche Teile des Prozesses würden Sie untersuchen, bevor Sie eine Technologie vorschlagen?
• Wie werden Sie das Projekt in Phasen aufteilen, die getestet und abgenommen werden können?
• Welche Risiken sehen Sie bereits jetzt und wie werden Sie sie überprüfen?
• Wer wird mein fester Ansprechpartner sein und wer trifft die technischen Entscheidungen?
• Wie gehen Sie vor, wenn sich während der Entwicklung herausstellt, dass eine Funktion komplexer ist als erwartet?
• Was erhalte ich bei der Übergabe: Code, Datenbank, Dokumentation, Zugangsdaten und Anleitungen?
• Wie werden Fehler nach dem Start des Systems bearbeitet?

Die beste Antwort ist nicht unbedingt die technischste. Wenn das Team nur über Programmiersprache und Design spricht, ohne nach Rollen, Genehmigungen, Rechnungen, Lager, API und tatsächlichen Nutzern zu fragen, hat es die Aufgabe wahrscheinlich noch nicht verstanden.

Wie prüfen Sie Erfahrung und Portfolio?

Sehen Sie sich das Portfolio an, aber bleiben Sie nicht bei schönen Startseiten stehen. Suchen Sie nach Projekten mit einer ähnlichen Logik: Anfrageverwaltung, Rollen und Berechtigungen, Dokumentenverwaltung, mobile Teams, Zahlungen, Lager, automatische Rechnungsstellung oder die Verbindung mehrerer Systeme.

Zum Beispiel verbindet LiftexPro — ERP für Aufzugsunternehmen die Planung von Inspektionen, die Verwaltung von Gebäuden, eine mobile App für Techniker und die automatische Rechnungsstellung. Das sagt mehr über ein Team aus, das ein Geschäftssystem entwickeln soll, als ein allgemeines Versprechen einer „einzigartigen Plattform“.

Bei Außendienstprozessen sollten Sie auch Ekovat — individuelles ERP ansehen, bei dem Anfragen, Arbeitsaufträge, Fuhrpark, Lager und Dokumente miteinander verbunden sind. Die Frage ist nicht, ob das Projekt zu Ihrer Branche gehört. Entscheidend ist, ob das Team Probleme mit vergleichbarer Komplexität gelöst hat.

Bitten Sie um eine Demonstration eines funktionierenden Systems und nicht nur um Bilder. In der Demo des ERP für internationale Transporte können Sie Touren, Fahrer, Fuhrpark, Kunden, Rechnungen, Kosten und verschiedene Ansichten für die Rollen im Unternehmen sehen. So erkennen Sie, ob der Anbieter echte Logik oder nur ein visuelles Konzept präsentiert.

Fragen Sie, welcher Teil des Gezeigten ein fertiges Produkt ist und welcher Teil speziell für den jeweiligen Kunden entwickelt wurde. Bitten Sie um eine Erklärung Ihrer Rolle, der verwendeten Integrationen und der Einschränkungen. Betrachten Sie fremde Ergebnisse nicht als Beweis, wenn das Team seine eigene Arbeit am Projekt nicht erklären kann.

Wie bewerten Sie den technischen Ansatz?

Der technische Ansatz sollte beim Prozess und bei den Daten beginnen. Für ein CRM werden beispielsweise Kunden, Geschäfte, Angebote, Aufgaben, die Kommunikationshistorie und die Berechtigungen der Mitarbeiter beschrieben. Für ein ERP werden Lager, Verkäufe, Rechnungen, Auswertungen, Rollen und Verbindungen zu anderen Systemen festgelegt.

Bitten Sie um ein Schema der wichtigsten Module und des Datenflusses. Wenn der Onlineshop eine Bestellung annimmt, wie gelangt sie ins Lager? Wann wird ein Frachtbrief erstellt? Wie wird die Zahlung erfasst? Was sieht der Buchhalter? Gibt es darauf keine klare Antwort, wird das Problem später in Form manueller Arbeit und Fehler auftreten.

Prüfen Sie, wie Integrationen geplant werden. Eine API-Anbindung an einen Kurierdienst, Zahlungsdienstleister, eine Telefonanlage oder ein Buchhaltungsprogramm ist nicht nur ein Häkchen im Angebot. Daten, Synchronisierungsintervalle, Fehler, erneutes Senden und die Zuständigkeit für die Überwachung der Verbindung müssen geklärt werden.

Fragen Sie nach einer Testumgebung, Backups, Logs, Zugriffsberechtigungen und dem Verfahren zur Veröffentlichung von Änderungen. Bei einem System mit personenbezogenen Daten sollten Sie klären, wer Zugriff hat, wie Aktionen protokolliert werden und wie der Betrieb im Problemfall wiederhergestellt wird.

Wie erkennen Sie, ob die Kommunikation funktionieren wird?

Kommunikation lässt sich nicht daran messen, wie schnell das Team vor der Vertragsunterzeichnung antwortet. Prüfen Sie, wie Sie nach dem Start zusammenarbeiten werden. Wird es ein wöchentliches Meeting geben? Wo werden die Aufgaben erfasst? Wie werden Sie Design, Prozess und fertige Funktionen genehmigen? Wie sehen Sie, was geplant und was blockiert ist?

Benennen Sie auf Ihrer Seite eine Person, die das Unternehmen kennt und Entscheidungen treffen kann. Wenn jeder Mitarbeiter den Programmierern direkt unterschiedliche Anweisungen gibt, wird das Projekt aus dem Ruder laufen. Das neue Team muss einen einzigen klaren Kanal für Anforderungen und Änderungen haben.

Bitten Sie um einen Beispielbericht zur Arbeit. Ein guter Bericht zeigt, was abgeschlossen ist, was noch ansteht, welche Fragen auf eine Entscheidung warten und was den Zeitplan beeinflusst. Das ist hilfreicher als eine allgemeine Mitteilung, dass „das Projekt läuft“.

Wie vergleichen Sie Zeitplan und Budget?

Vergleichen Sie nicht nur die Endbeträge. Vergleichen Sie, was dahintersteckt. Ein Angebot kann Analyse, Design, Entwicklung, Datenmigration, Tests, Schulung, Veröffentlichung und Support umfassen. Ein anderes vielleicht nur die Programmierung.

Für die Entwicklung einer individuellen Software liegt der ermittelte Angebotsrahmen bei 3.000–29.300 €. Was Ihnen in diesem Rahmen angeboten wird, hängt von der Anzahl der Module, der Komplexität der Rollen, der Datenmigration, der mobilen App, den Integrationen, den Tests und dem Bedarf an kontinuierlichem Support ab. Vergleichen Sie nicht die Untergrenze eines Angebots mit dem vollständigen Leistungsumfang eines anderen.

Auch der Zeitplan muss an ein Ergebnis geknüpft sein. Bitten Sie statt um „in kurzer Zeit fertig“ um einen Zeitplan mit Phasen, Abhängigkeiten und Abnahmebedingungen. Wenn Sie den Zugang, Inhalte oder Entscheidungen verzögern, muss sich der Zeitplan transparent anpassen.

Wie sollte der Arbeitsprozess aussehen?

1. 01
   Audit des bestehenden Projekts

   Sie prüfen den vorhandenen Code, die Datenbank, die Zugangsdaten, die Dokumentation und die noch nicht umgesetzten Funktionen. Das neue Team beschreibt, welche Teile weiterverwendet werden können und welche besser und sicherer neu entwickelt werden sollten.

2. 02
   Beschreibung des tatsächlichen Prozesses

   Sie schildern, wie Vertrieb, Lager, Buchhaltung, Außendienst und Geschäftsleitung arbeiten. Das Team übersetzt diesen Prozess in Rollen, Status, Daten, Benachrichtigungen und Integrationen.

3. 03
   Pilotumfang

   Sie wählen einen wichtigen, aber begrenzten Teil des Systems aus. Dieser muss einen realen Anwendungsfall durchlaufen und zeigen, ob die Lösungen für die Menschen, die sie nutzen werden, praktikabel sind.

4. 04
   Abnahme in Phasen

   Für jede Funktion legen Sie fest, was „fertig“ bedeutet. Sie testen sie mit konkreten Daten, dokumentieren die Anmerkungen und trennen Fehler von neuen Ideen.

5. 05
   Go-live und Schulung

   Sie planen die Migration, Berechtigungen, Backups, Schulung und den Beobachtungszeitraum. Beenden Sie die bisherige Arbeitsweise nicht, bevor Sie wissen, wie Sie bei Problemen vorgehen.

6. 06
   Support und Weiterentwicklung

   Sie legen einen Kanal für Anfragen, Prioritäten, den Umgang mit Fehlern, Updates und die Kosten zusätzlicher Änderungen fest. So beginnt die nächste Phase nicht mit einer erneuten Suche nach einem Anbieter.

Wie vermeiden Sie, alte Fehler zu wiederholen?

Beziehen Sie die Nutzer bereits vor der Entwicklung ein. Der Lagerist, der Disponent und der Buchhalter sehen andere Probleme als die Geschäftsführung. Eine kurze Demonstration anhand eines realen Szenarios aus ihrem Arbeitsalltag kann eine Lücke aufdecken, die eine lange Anforderungsliste nicht sichtbar macht.

Ändern Sie das Ziel nicht ständig, ohne die Folgen zu bewerten. Eine neue Funktion kann die Datenbank, die Rollen, die API-Verbindungen und den Zeitplan beeinflussen. Jede Erweiterung des Leistungsumfangs sollte eine Beschreibung, einen Preis und Angaben zu den Auswirkungen auf den Zeitplan enthalten.

Lassen Sie nichts nur mündlich besprechen. Halten Sie Entscheidungen, Freigaben und Verantwortlichkeiten schriftlich fest. Regeln Sie im Vertrag das Eigentum am Code, den Zugriff auf Hosting und Datenbank, die Vertraulichkeit, die Abnahme und die Bedingungen für eine Beendigung.

Prüfen Sie schließlich, wie der Support nach dem Go-live aussieht. Bei einer bestehenden Website oder einem bestehenden System kann er Updates, Backups, Prüfungen und kleinere Änderungen umfassen. Bei einem komplexeren ERP- oder CRM-System sind zudem die Überwachung der Integrationen, die Benutzerverwaltung und die Weiterentwicklung der Funktionalität erforderlich.

Was ist nach einem gescheiterten Projekt die richtige Wahl?

Das richtige Team ist nicht das, das am schnellsten und günstigsten verspricht. Es stellt Fragen zu Ihrer Arbeitsweise, zeigt ähnliche Systeme, erklärt die Einschränkungen und teilt das große Risiko in kleine, überprüfbare Lösungen auf.

Vor der Vertragsunterzeichnung sollten Sie wissen, wer am Projekt arbeitet, was Sie in jeder Phase erhalten, wie Funktionen abgenommen werden, was mit dem Code und den Daten geschieht und an wen Sie sich bei Problemen wenden. Wenn diese Fragen von Anfang an klar beantwortet sind, ist die Wahrscheinlichkeit deutlich geringer, dass sich das alte Szenario wiederholt.