Pflichtenheft vor Anbieterauswahl: Methodik für Branchensoftware-Projekte

seminarverwaltungssoftware

Ein IT-Verantwortlicher sitzt in der dritten Anbieter-Demo der Woche und merkt, dass er sich kaum noch erinnert, welche Funktion zu welchem Anbieter gehörte. Genau an diesem Punkt zeigt sich, warum es sich lohnt, zuerst ein Pflichtenheft für die Software zu erstellen, bevor überhaupt ein Vertriebstermin vereinbart wird. Ohne eine vorab festgelegte Anforderungsbasis bestimmt am Ende nicht der tatsächliche Bedarf, sondern die überzeugendste Präsentation, welches System ausgewählt wird. Besonders bei spezialisierten Fachanwendungen, etwa für die Verwaltung von Seminaren, Schulungen oder Trainings, rächt sich dieser fehlende Unterbau spätestens im laufenden Betrieb. Der folgende Beitrag zeigt eine nachvollziehbare Schrittfolge, mit der sich Anforderungen an Branchensoftware systematisch definieren lassen, bevor Anbieter überhaupt ins Spiel kommen.

Demo zuerst, Anforderungen danach: Der typische Fehlstart

Der klassische Ablauf bei der Auswahl von Fachsoftware beginnt häufig genau verkehrt herum. Ein Fachbereich meldet Bedarf an, jemand sucht im Netz nach passenden Anbietern, und schon steht der erste Demo-Termin im Kalender. Erst danach, wenn die Entscheidung im Kopf längst gefallen ist, entsteht eine Liste mit Anforderungen, die zur gesehenen Software passt.

Diese Reihenfolge erzeugt ein strukturelles Problem: Statt dass die Software an den Prozess angepasst wird, passt sich die Beschreibung des Bedarfs an die gezeigte Software an. Funktionen, die ein Anbieter zufällig mitbringt, werden im Nachhinein zu vermeintlich wichtigen Anforderungen erklärt, während tatsächliche Schwachstellen im eigenen Ablauf unentdeckt bleiben. Wer beispielsweise eine beeindruckende Automatisierungsfunktion in einer Demo sieht, neigt dazu, sie als zentrales Kriterium zu übernehmen, auch wenn der eigene Betrieb sie kaum nutzen würde.

Das Ergebnis zeigt sich oft erst Monate nach der Einführung: Prozesse, die eigentlich vereinfacht werden sollten, laufen weiterhin parallel in Excel-Tabellen, weil die Software an entscheidender Stelle nicht zum tatsächlichen Arbeitsablauf passt. Der Fehler liegt dabei selten an der Software selbst, sondern an der Reihenfolge, in der sie ausgewählt wurde. Eine fundierte Anforderungsanalyse vor dem ersten Anbieterkontakt verhindert genau dieses Muster, weil sie den Bedarf unabhängig von Verkaufsargumenten beschreibt.

Muss- oder Kann-Kriterium: Anforderungen richtig unterscheiden

Eine belastbare Anforderungsanalyse unterscheidet sich von einer oberflächlichen Checkliste vor allem dadurch, dass sie zwischen zwingend notwendigen und lediglich wünschenswerten Eigenschaften trennt. Eine einfache Liste von Wunschfunktionen beantwortet nicht, welche davon ein System tatsächlich erfüllen muss, um überhaupt in Frage zu kommen, und welche nur den Ausschlag zwischen zwei ansonsten gleichwertigen Kandidaten geben.

Diese Trennung erfordert eine genaue Betrachtung der bestehenden Prozesse, nicht nur eine Sammlung von Wünschen aus verschiedenen Abteilungen. Ein Muss-Kriterium ist typischerweise eine Funktion, ohne die ein zentraler Arbeitsschritt gar nicht abgebildet werden kann, etwa eine automatische Erfassung von Zahlungseingängen bei wiederkehrenden Rechnungen. Ein Kann-Kriterium dagegen verbessert den Ablauf, ohne dass ein Fehlen ihn blockiert, etwa eine zusätzliche Exportfunktion für Statistiken.

Wesentlich ist dabei, dass diese Einordnung nicht allein von der IT-Abteilung vorgenommen wird. Wer täglich mit der bestehenden Lösung arbeitet, kennt die tatsächlichen Engpässe meist genauer als diejenigen, die nur für die technische Umsetzung zuständig sind. Eine Anforderungsanalyse, die ohne die Fachabteilung entsteht, läuft Gefahr, technisch saubere, aber praxisferne Kriterien festzulegen. Der strukturierte Auswahlprozess für IT-Systeme erstreckt sich dabei, wie das Fraunhofer-Institut für Materialfluss und Logistik beschreibt, von der Anforderungs- und Prozessanalyse über eine Marktanalyse bis hin zur Erstellung eines Lastenhefts. Diese Abfolge stellt sicher, dass erst der Bedarf feststeht, bevor der Markt überhaupt betrachtet wird.

Kriterienkatalog am Beispiel einer Seminarverwaltung

Wie eine solche Anforderungsdefinition konkret aussieht, lässt sich am Beispiel eines Weiterbildungsanbieters gut nachvollziehen, der eine Verwaltungslösung für seine Kurse und Trainings sucht. Der erste Schritt besteht darin, die bestehenden Abläufe rund um Teilnehmerverwaltung, Terminplanung und Abrechnung einzeln zu beschreiben, bevor überhaupt über Funktionen gesprochen wird.

Bei der Teilnehmerverwaltung stellt sich zum Beispiel die Frage, ob Anmeldungen bislang per E-Mail eingehen und manuell in eine Liste übertragen werden, oder ob bereits ein Online-Formular existiert. Je nachdem, wie dieser Prozess heute funktioniert, ergibt sich daraus ein anderes Muss-Kriterium: Im ersten Fall wäre eine automatisierte Erfassung von Anmeldedaten zentral, im zweiten Fall eher eine saubere Anbindung an das bestehende Formular. Bei der Terminautomatisierung geht es darum, wiederkehrende Seminartermine, Wartelisten und Erinnerungen an Teilnehmende ohne manuellen Zusatzaufwand abzubilden, was besonders bei Anbietern mit vielen parallelen Kursreihen den Verwaltungsaufwand spürbar verändert. Und bei der Schnittstelle zur Buchhaltung entscheidet sich, ob Rechnungen und Zahlungseingänge automatisch mit der Finanzsoftware abgeglichen werden oder ob weiterhin doppelt erfasst werden muss.

Wer als Weiterbildungsanbieter eine Seminarverwaltungssoftware sucht, legt in diesem Schritt fest, ob Teilnehmerverwaltung, Terminautomatisierung und Schnittstelle zur Buchhaltung als Muss-Kriterium oder lediglich als Kann-Kriterium eingestuft werden. Diese Einordnung entscheidet später darüber, welche Anbieter überhaupt in die engere Auswahl kommen, unabhängig davon, wie viele Zusatzfunktionen sie sonst mitbringen. Ein Anbieter mit einer brillanten Oberfläche, aber ohne funktionierende Buchhaltungsschnittstelle, fällt bei dieser Methodik konsequent durch, selbst wenn die Demo überzeugend wirkte.

Pflichtenheft erstellen: Von der Liste zum Vergleichsdokument

Aus der gesammelten Anforderungsliste wird erst dann ein brauchbares Vergleichsinstrument, wenn jedes Kriterium zusätzlich gewichtet wird. Eine reine Aufzählung von Muss- und Kann-Kriterien sagt noch nichts darüber aus, wie stark ein einzelnes Kriterium im Gesamtergebnis zählen soll. Deshalb erhält jedes Kriterium im Pflichtenheft neben seiner Einstufung auch einen Punktwert, der sich an der tatsächlichen Geschäftsrelevanz orientiert.

Ein Beispiel verdeutlicht den Effekt: Vergibt ein Unternehmen für ein geschäftskritisches Muss-Kriterium wie die automatische Buchhaltungsschnittstelle drei Punkte, für ein wünschenswertes Feature wie ein zusätzliches Teilnehmerportal dagegen nur einen Punkt, zeigt die Summe am Ende, welcher Anbieter die wirklich wichtigen Anforderungen am besten abdeckt. Ohne diese Gewichtung könnte ein Anbieter mit vielen kleinen Komfortfunktionen rechnerisch besser abschneiden als einer, der genau die eine entscheidende Schnittstelle sauber löst, obwohl Letzterer im Alltag den größeren Unterschied macht.

Nach der Gewichtung folgt die Testphase, und hier liegt ein häufig unterschätzter Unterschied: Eine Standarddemo zeigt immer die Stärken eines Systems, niemals seine Schwächen. Deutlich aussagekräftiger ist es, wenn Anbieter gebeten werden, ein realistisches Szenario aus dem eigenen Betrieb nachzustellen, etwa die Anmeldung mehrerer Teilnehmender zu einem Termin mit begrenzter Platzzahl und automatischer Warteliste. Erst an einem solchen konkreten Ablauf zeigt sich, ob die Software tatsächlich zum eigenen Arbeitsalltag passt oder ob sie in der Präsentation nur gut aussieht.

Wie lange dauert die Auswahl, und wann lohnt sich Beratung?

Ein strukturierter Auswahlprozess benötigt spürbar mehr Vorlauf als eine spontane Anbieterentscheidung, dafür sinkt das Risiko einer Fehlentscheidung erheblich. Wie viel Zeit tatsächlich eingeplant werden sollte, hängt stark davon ab, wie viele Abteilungen eingebunden werden müssen und wie komplex die bestehenden Prozesse sind. Ein kleiner Weiterbildungsanbieter mit überschaubaren Abläufen kommt mit deutlich weniger Abstimmungsaufwand aus als ein Anbieter mit mehreren Standorten und unterschiedlichen Kursformaten.

Externe Beratung lohnt sich vor allem dann, wenn intern die Zeit oder die methodische Erfahrung fehlt, um Anforderungen strukturiert zu erheben und Anbieter neutral zu vergleichen. Gerade bei Fachsoftware, die tief in bestehende Prozesse eingreift, besteht sonst die Gefahr, dass einzelne Stimmen aus der lautesten Abteilung die Anforderungsliste dominieren, während andere relevante Perspektiven untergehen. Eine außenstehende Moderation kann hier helfen, alle Beteiligten strukturiert einzubeziehen, ohne dass einzelne Interessen das Ergebnis verzerren.

Wer dagegen über ausreichend interne Erfahrung mit Softwareprojekten verfügt und die Prozesse bereits gut dokumentiert hat, kann den Auswahlprozess auch in Eigenregie durchführen. Entscheidend ist weniger die Frage, ob Beratung grundsätzlich sinnvoll ist, sondern ob die Methodik, also die konsequente Trennung von Anforderungsanalyse und Anbieterauswahl, eingehalten wird. Diese Methodik lässt sich sowohl intern als auch mit externer Unterstützung sauber umsetzen.

Häufig gestellte Fragen (FAQ)

Was gehört zwingend in ein Pflichtenheft für Branchensoftware?

Ein Pflichtenheft sollte alle Muss-Kriterien mit ihrer jeweiligen Begründung enthalten, dazu die Kann-Kriterien mit ihrer Gewichtung sowie eine Beschreibung der zugrunde liegenden Prozesse. Ohne diese Prozessbeschreibung bleibt für Anbieter oft unklar, warum ein bestimmtes Kriterium überhaupt gefordert wird.

Warum reicht eine einfache Funktionsliste nicht aus?

Eine Funktionsliste beschreibt nur, was ein System können soll, nicht aber, wie wichtig jede einzelne Funktion für den Betrieb tatsächlich ist. Ohne Gewichtung und ohne Unterscheidung zwischen Muss- und Kann-Kriterien lassen sich Angebote verschiedener Anbieter kaum objektiv miteinander vergleichen.

Sollte die IT-Abteilung die Anforderungen allein festlegen?

Nein, eine alleinige Festlegung durch die IT-Abteilung führt häufig zu technisch sauberen, aber praxisfernen Kriterien. Die Fachabteilung, die täglich mit den bestehenden Prozessen arbeitet, kennt die tatsächlichen Engpässe in der Regel genauer und sollte deshalb von Beginn an eingebunden werden.

 

„Dieser Text wurde teilweise mithilfe einer KI erstellt und redaktionell geprüft.“