Die Wahl eines Partners für Edtech-Softwareentwicklung beginnt mit der Arbeit, die Ihr Team bewältigen muss. Das kann eine Agenturbuchung sein, die zwischen Standorten weitergereicht wird, eine Bewerbung, die an einen anderen Berater übergeben wird, oder ein Partner-Update, das in mehrere Systeme kopiert wird.
Bevor Sie Angebote vergleichen, legen Sie fest, wo diese Arbeit ins Stocken gerät und was ein nützliches erstes Release verändern würde. Beurteilen Sie dann jedes Unternehmen anhand desselben Ablaufs, derselben Abhängigkeiten und derselben Abnahmekriterien. Dieser Leitfaden zeigt Sprachschulgruppen, Rekrutierungsagenturen und Edtech-Inhabern, wie das gelingt.
1. Bringen Sie einen Ablauf in das erste Gespräch mit
„Wir brauchen ein Portal“ lässt zu viel offen. Beschreiben Sie, wer den Prozess startet, welche Informationen diese Person braucht, wer als Nächstes handelt und wie der Abschluss festgehalten wird.
Eine Schule mit drei Standorten erhält beispielsweise Agenturbuchungen per E-Mail. In diesem hypothetischen Ablauf prüfen Mitarbeitende die Verfügbarkeit, bestätigen den Preis und tragen die Buchung in ein zentrales System ein. Eine spätere Datumsänderung erreicht einen Standort, lässt den zentralen Datensatz aber unverändert.
Nutzen Sie dieses Beispiel, um ein kurzes Briefing vorzubereiten:
Auslöser: Eine Agentur beantragt eine Buchung oder ändert deren Termine.
Beteiligte: Agentur, Standortadministration und zentrale Buchungsverwaltung.
Datensätze: Kurs, Termine, Verfügbarkeit, vereinbarter Preis und Buchungsstatus.
Ausnahme: Der gewünschte Kurs ist ausgebucht oder das Angebot ist abgelaufen.
Abnahme: Die berechtigte Person bestätigt die Änderung, und beide Ansichten zeigen dieselben aktuellen Termine.
Eine Agentur kann dasselbe für eine Übergabe an einen anderen Berater tun. Ein Edtech-Unternehmen kann die erste Kontoeinrichtung eines Partners abbilden. Bitten Sie jeden möglichen Partner zu erklären, welche Lücken er vor einer Schätzung untersuchen würde.
2. Prüfen Sie, ob Individualentwicklung notwendig ist
Individuelle Software für Bildungsunternehmen ist sinnvoll, wenn ein bestimmter Prozess Regeln, Oberflächen oder Verbindungen braucht, die Ihre aktuelle Umgebung vernünftigerweise nicht bieten kann. Prüfen Sie zuerst, ob Konfiguration, Schulung oder eine schmalere Integration das Problem lösen würden.
Bitten Sie das Team, drei Wege zu vergleichen:
| Weg | Sinnvoll, wenn | Abwägung, die zu prüfen ist |
| Vorhandene Software konfigurieren | Der benötigte Ablauf lässt sich bereits mit den vorhandenen Einstellungen abbilden | Ihr Prozess muss innerhalb dieser Einstellungen funktionieren |
| Ein Modul oder eine Integration ergänzen | Das Kernsystem funktioniert, aber eine Übergabe oder Schnittstelle fehlt | Sie hängen von dessen API, Berechtigungen und künftigen Änderungen ab |
| Ein eigenes Produkt entwickeln | Der Ablauf braucht eigene Regeln und eine eigene Nutzererfahrung | Sie übernehmen die Verantwortung für Wartung, Hosting und laufende Produktentscheidungen |
Eine mobile App braucht eine eigene Begründung. Fragen Sie, welche Aufgabe eine Smartphone-Funktion oder häufigen mobilen Zugriff erfordert. Für gelegentliche Partneradministration kann eine browserbasierte Oberfläche genügen. Vergleichen Sie die tatsächlichen Aufgaben, bevor Sie Plattformen wählen.
Die Seite zur Entwicklung für Bildungspartner ist ein guter Ausgangspunkt, um Portale, Integrationen und Marken-Apps als getrennte Umfänge zu besprechen.
3. Fordern Sie Belege für relevante Problemlösung an
Wenn Sie ein Edtech-Softwareunternehmen beurteilen, schauen Sie über Branchenlabels und Screenshots hinaus. Fragen Sie, wie sein Team Geschäftsregeln geklärt, Ausnahmen behandelt und ein Release getestet hat.
Nützliche Fragen sind:
Welchen Teil der Arbeit hat Ihr Team geliefert?
Welche operative Regel hat den vorgeschlagenen Entwurf verändert?
Wie haben Sie eine fehlgeschlagene Aktualisierung oder eine widersprüchliche Bearbeitung getestet?
Was musste der Kunde liefern, bevor die Arbeit fortgesetzt werden konnte?
Was wurde übergeben, und was erforderte einen separaten Supportvertrag?
Nutzen Sie veröffentlichte Fallstudien, um Umfang und Verantwortung zu prüfen. Respektieren Sie die Vertraulichkeit: Ein Team sollte seinen Ansatz besprechen können, ohne die privaten Daten einer anderen Organisation offenzulegen. Behandeln Sie eine hypothetische Demonstration als Demonstration und nicht als Beleg für frühere Projekte.
Softvery entwickelt individuelle Software und KI-Funktionen für internationale Bildungsunternehmen. Prüfen Sie diese Kompetenz an Ihrem eigenen Prozess und fragen Sie, was für Ihr Projekt noch bestätigt werden muss.
4. Machen Sie den Discovery-Sprint zu einem Kauf, den Sie beurteilen können
Ein Discovery-Sprint sollte definierte Unsicherheiten ausräumen. Vereinbaren Sie vor der Zahlung, welches Szenario er abdeckt, wer teilnimmt, welche Materialien Sie bereitstellen und was Sie erhalten.
Fordern Sie eine schriftliche Liste der Ergebnisse an:
Eine Prozesslandkarte mit Rollen, Übergaben und Ausnahmen.
Skizzen der wichtigsten Screens, die Mitarbeitende prüfen können.
Annahmen, Abhängigkeiten und offene Fragen.
Ein vorgeschlagenes erstes Release mit klaren Grenzen.
Eine erste Schätzung und die Bedingungen, die sie verändern könnten.
Fragen Sie, welche Entscheidung jedes Ergebnis unterstützt. Eine Screen-Skizze kann Mitarbeitenden helfen, den Ablauf zu beurteilen. Sie klärt nicht, ob ein externes System die erforderliche Aktualisierung zulässt. Dafür kann eine separate technische Prüfung nötig sein.
Der kostenpflichtige Discovery-Sprint von Softvery umfasst ein Szenario, die wichtigsten Screens, Annahmen und einen Plan für die nächsten Schritte. Die angegebene Dauer beträgt 5–10 Werktage ab dem vereinbarten Start, nachdem die Ausgangsmaterialien eingegangen sind. Eine funktionierende Anwendung, Produktionscode, Live-Integrationen und Datenmigration sind in diesem Sprint nicht enthalten.
Als Hintergrund lesen Sie was ein Discovery-Sprint umfasst. Bestätigen Sie in Ihrem Angebot die konkreten Ergebnisse und den Prüfprozess für den Umfang, den Sie kaufen.
5. Prüfen Sie Integrations- und Datenannahmen frühzeitig
„Wir können das anbinden“ braucht Details. Fragen Sie, welches System welchen Datensatz führt, in welche Richtung Informationen fließen und was passiert, wenn eine Aktualisierung fehlschlägt.
Bei einem hypothetischen Provisions-Tracker für Agenturen trennen Sie eine erwartete Provision, eine gestellte Rechnung und eine eingegangene Zahlung. Legen Sie fest, wer jeden Status bestätigt. Ein Tracker kann eine überfällige Position anzeigen; die Zahlung hängt weiterhin von der Institution ab.
Klären Sie für jede vorgeschlagene Verbindung:
Zugang: Wer stellt Dokumentation, Testkonten und API-Berechtigungen bereit?
Zuordnung: Welche Kennungen verbinden Datensätze, und wie werden Dubletten behandelt?
Zeitpunkt: Wann sollen Änderungen im empfangenden System erscheinen?
Fehlerfall: Wer sieht einen Fehler, wiederholt den Vorgang und prüft das Ergebnis?
Historie: Welche vorhandenen Daten müssen übertragen werden, und wer prüft ihre Qualität?
Bitten Sie um eine Demonstration mit erfundenen Daten. Beziehen Sie eine wiederholte und eine fehlgeschlagene Aktualisierung ein und prüfen Sie, dass keine davon einen irreführenden Status erzeugt.
Prüfen Sie auch den Zugriff anhand praktischer Beispiele. Kann eine Agentur die Datensätze einer anderen Agentur sehen? Können sich ehemalige Mitarbeitende noch anmelden? Wer darf Informationen exportieren oder löschen? Legen Sie vor der Entwicklung die erforderlichen Kontrollen und die Personen fest, die sie freigeben.
6. Wählen Sie ein Liefermodell, das Ihr Team steuern kann
Ein klar umrissenes Modul passt zu einem Unternehmen mit einem eindeutigen Ziel und einer Person, die das Ergebnis abnehmen kann. Vereinbaren Sie die Grenzen und den Änderungsprozess, bevor die Arbeit beginnt.
Ein dediziertes Team passt zu laufender Produktarbeit, wenn auf Ihrer Seite jemand Prioritäten setzen und Fragen beantworten kann. Die monatliche Kapazität muss dennoch aktiv gesteuert werden. Fragen Sie, welche Rollen enthalten sind und wie unfertige Arbeit berichtet wird.
Eine Teamverstärkung kann zu einem Edtech-Unternehmen passen, das bereits eine technische Leitung hat, aber eine bestimmte Fähigkeit braucht. Legen Sie fest, wer Code prüft, Änderungen testet und Releases freigibt.
Klären Sie für jedes Modell:
Wer trifft Produktentscheidungen und löst widersprüchliche Anforderungen auf?
Wer prüft die Geschäftsregeln gemeinsam mit Ihren operativen Mitarbeitenden?
Wie oft sehen Sie funktionierende Software?
Wie werden Änderungen am Umfang bepreist und freigegeben?
Was passiert, wenn eine Abhängigkeit oder Entscheidung sich verzögert?
Vergleichen Sie neben dem Preis auch die Gesamtverantwortung. Ein niedrigerer Entwicklungsaufwand kann Test-, Migrations- oder Release-Arbeiten ausschließen, die ein anderes Angebot enthält. Bitten Sie jedes Team, Ausschlüsse in einfachen Worten zu erklären.
7. Vereinbaren Sie Abnahme, Eigentum und Support
Formulieren Sie Abnahmeprüfungen als Aufgaben, die Ihre Mitarbeitenden ausführen können. Testen Sie für die hypothetische Änderung einer Schulbuchung, dass ein berechtigter Administrator neue Termine freigeben kann, der zentrale Datensatz sich aktualisiert und eine nicht berechtigte Agentur die Buchung einer anderen nicht ändern kann.
Beziehen Sie eine fehlgeschlagene Verbindung und einen Weg zur Wiederherstellung ein. Legen Sie fest, wer abnimmt, wo getestet wird und wie Fehler erfasst werden. Planen Sie das Release rund um die Menschen, die es nutzen und betreuen müssen, einschließlich Schulung und einer Rückfalllösung, falls die Änderung nicht umgesetzt werden kann.
Fragen Sie vor der Unterzeichnung nach Code-Zugriff, Dokumentation, Hosting-Konten, Drittlizenzen und Übergabe. Besprechen Sie den laufenden Support konkret: Servicezeiten, Prioritäten bei Störungen, Reaktionsvereinbarungen und Verantwortung für externe Dienste.
Bei Softvery gehen Code und geistiges Eigentum per Vertrag auf Sie über. Prüfen Sie die Übertragungsbedingungen und die Lizenzbedingungen Dritter im vorgeschlagenen Vertrag.
8. Vergleichen Sie schriftliche Antworten, bevor Sie entscheiden
Senden Sie dasselbe Briefing an Ihre Shortlist. Halten Sie jede Antwort als klar, teilweise beantwortet oder ungeklärt fest. Nutzen Sie diese Checkliste in Ihrem Auswertungstermin:
Können sie den Ablauf und seine schwierigen Ausnahmen erklären?
Haben sie Konfiguration, Integration und eine separate Eigenentwicklung miteinander verglichen?
Sind Discovery-Ergebnisse und Ausschlüsse schriftlich festgehalten?
Haben sie Abhängigkeiten identifiziert, die untersucht werden müssen?
Sind Entscheidungsbefugnis, Abnahme und Freigabe von Änderungen zugewiesen?
Decken die Schätzungen vergleichbare Verantwortlichkeiten ab?
Sind Eigentum, Übergabe und Supportbedingungen klar geregelt?
Klären Sie die offenen Punkte, bevor Sie eine vollständige Umsetzung beauftragen. Ist die verbleibende Unsicherheit technischer Natur, grenzen Sie eine gezielte Prüfung ab. Betrifft sie Ihre Betriebsregeln, beziehen Sie die Mitarbeitenden ein, die diese Entscheidungen treffen.
Wo Sie anfangen sollten
Bereiten Sie eine Seite vor: den Ablauf, die aktuellen Tools, ein anonymisiertes Beispiel, die wichtigste Ausnahme, eine gewünschte Abnahmeprüfung und die für Entscheidungen zuständige Person. Ergänzen Sie Ihre Budgetgrenze und jede feste operative Frist.
Nutzen Sie die Übersicht zur Softwareentwicklung für Partner, um das erste Gespräch zu strukturieren. Bitten Sie um einen ersten Schritt, der klein genug ist, um ihn zu prüfen, bevor Sie sich auf ein größeres Programm festlegen.
Wenn Sie dieses Briefing besprechen möchten: 30-Min.-Gespräch buchen.
