Bedarfsanalyse für Softwareanbieter: So gehen Sie vor

Was eine Bedarfsanalyse für Softwareanbieter leisten soll

Eine Bedarfsanalyse ist ein systematisches Verfahren. Sie ermittelt Lücken zwischen dem aktuellen Zustand und einem angestrebten Ergebnis.

Sie hilft, Verbesserungen zu priorisieren und Ressourcen dorthin zu lenken, wo sie am meisten bewirken. Die Standardliteratur beschreibt sie als Weg, Bedarf zu erkennen, Chancen zu nutzen und Ressourcenlücken im bestehenden Ablauf sichtbar zu machen.

Für Softwareanbieter zählt nicht, welche Features intern wünschenswert erscheinen. Entscheidend sind Probleme konkreter Kundengruppen, ihre Dringlichkeit und die produktrelevanten Entscheidungen daraus.

Eine Sammlung von Feature-Wünschen ist noch keine Bedarfsanalyse. Sie ist bestenfalls Rohmaterial, das nach Kontext, Häufigkeit und Wirkung bewertet werden muss.

Von drei Nachbardisziplinen ist die Bedarfsanalyse abzugrenzen. Die Marktanalyse betrachtet Marktvolumen, Wettbewerb und Trends auf aggregierter Ebene. Die Anforderungsanalyse übersetzt einen bereits eingegrenzten Bedarf in eine technisch prüfbare Spezifikation. Das Verkaufsgespräch erhebt den Bedarf eines einzelnen Interessenten für eine konkrete Entscheidung.

Die Bedarfsanalyse liegt dazwischen: Sie verdichtet viele Einzelbeobachtungen zu einem belastbaren Bild vom Bedarf einer definierten Zielgruppe.

Typischer Auslöser ist eine anstehende Entscheidung – etwa ob ein Modul ausgebaut, eine Integration gebaut, ein Preismodell geändert oder ein neues Segment erschlossen wird.

Eine Bedarfsanalyse ohne Entscheidung endet fast zwangsläufig im Datensammeln. Zu Beginn muss daher feststehen, wer die Ergebnisse nutzt und was danach anders gemacht wird.

In Österreich kommt eine Besonderheit hinzu: Der Bedarf wird stark von Kundengröße und Beschaffungsweg geprägt. Ein Ein-Personen-Unternehmen entscheidet anders als eine Genossenschaft oder ein öffentlicher Auftraggeber mit formalem Vergabeverfahren.

Die Bedarfsanalyse muss diese Unterschiede abbilden. Sonst beschreibt sie einen Durchschnittskunden, den es nicht gibt.

Rechtlicher Rahmen in Österreich: DSGVO, DSG und Data Act

Datenschutz in Österreich ruht auf zwei Säulen. Die DSGVO der EU gilt seit 25. Mai 2018 unmittelbar in allen Mitgliedstaaten. Das nationale Datenschutzgesetz (DSG) ergänzt sie.

Das DSG enthält österreichische Besonderheiten: das Grundrecht auf Datenschutz nach § 1 DSG, die Datenschutzbehörde als Aufsichtsstelle, das Datengeheimnis nach § 6 DSG und Verwaltungsstrafen nach § 62 DSG bis zu 50.000 Euro.

Diese Pflichten treffen Unternehmen unabhängig von ihrer Größe – vom Kleinbetrieb bis zum Konzern.

Für jede Bedarfsanalyse heißt das: Schon die Erhebung selbst ist eine Datenverarbeitung. Sie braucht eine Rechtsgrundlage nach Art. 6 DSGVO, muss den Betroffenen gegenüber transparent gemacht werden und ist im Verzeichnis der Verarbeitungstätigkeiten (Art. 30 DSGVO) zu führen.

Zentral ist die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO. Nicht die Behörde muss einen Verstoß beweisen, sondern das Unternehmen muss belegen können, dass es die Regeln einhält.

Wer Kundeninterviews, Nutzungsdaten und Supportauswertungen durchführt, sollte von Anfang an dokumentieren, wofür Daten erhoben wurden und wie lange sie aufbewahrt werden.

Die Aufsicht ist in Bewegung. Nach Einschätzung aus der österreichischen Rechtsberatung hat die österreichische Datenschutzbehörde ihre Prüftätigkeit 2025 und 2026 deutlich verschärft. Als häufige Schwachstellen gelten fehlende Verarbeitungsverzeichnisse, unbeantwortete Auskunftsbegehren und Auftragsverarbeiter-Verträge, die zwar existieren, aber nicht auffindbar sind.

Für Softwareanbieter ist das relevant, weil sie in der Bedarfsanalyse häufig personenbezogene Daten aus eigenen Systemen auswerten.

Dazu kommt der Data Act (Verordnung (EU) 2023/2854), in Kraft seit 12. September 2025. Er unterscheidet drei Rollen: Nutzer, die ein vernetztes Produkt besitzen oder berechtigt nutzen; Dateninhaber, die Daten technisch oder rechtlich bereitstellen können; und Datenempfänger, also Dritte, die Daten erhalten.

Softwareanbieter sind regelmäßig als Dateninhaber zu qualifizieren, wenn sie Plattformen oder Dienste betreiben, die Nutzerdaten erzeugen oder verarbeiten.

Erfasst sind insbesondere Produktdaten wie Sensordaten und Nutzungsdauer, Daten aus verbundenen Diensten wie Cloud-Nutzung und API-Calls sowie Metadaten wie Zeitstempel und Formatinformationen. Nicht erfasst sind hingegen abgeleitete oder analysierte Daten, die durch zusätzliche Investitionen entstehen. Entscheidend ist, ob sich Daten ohne unverhältnismäßigen Aufwand bereitstellen lassen.

Daraus ergeben sich vier Pflichtenlinien, die schon bei der Bedarfsanalyse mitzudenken sind. Access by Design: Nutzer müssen ihre Daten direkt abrufen können, über ein Dashboard, eine API oder ein Export-Werkzeug.

Vertragsklarheit: Daten dürfen nur auf Grundlage eines Vertrags mit dem Nutzer an Dritte weitergegeben werden. Das schließt Analyse- und Marketingzwecke ausdrücklich ein.

Technische Dokumentation: Es muss festgehalten werden, welche Daten verarbeitet werden, wie sie gespeichert sind und wie der Zugriff erfolgt. Dafür bietet sich eine Art Stückliste für Daten an.

Datenschutz und Sicherheit: Bei gemischten Datensätzen aus personenbezogenen und nicht personenbezogenen Daten bleibt die DSGVO voll anwendbar.

Die Wirtschaftskammer Österreich hat zum Data Act ein FAQ für Unternehmen veröffentlicht. Darin wird betont, dass bei der Datennutzung rechtliche Grenzen zu beachten sind, vor allem bei personenbezogenen Daten nach der DSGVO sowie bei Geschäftsgeheimnissen aus dem Wettbewerbs- und Strafrecht.

Wer Bedarfsdaten aus Kundensystemen auswertet, sollte diese Grenzen kennen und in der Konzeption der Erhebung berücksichtigen.

Ein zweiter Strang betrifft Art. 25 DSGVO, also Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Adressat dieser Pflicht ist primär der Verantwortliche, also das Unternehmen, das die Software zur Verarbeitung einsetzt – nicht der Hersteller.

Der Verantwortliche kann aber vom Hersteller verlangen, dass der Einsatz der Software die Umsetzung dieser Pflichten überhaupt ermöglicht. In Ausschreibungen werden solche Eigenschaften häufig ausdrücklich verlangt.

Für die Bedarfsanalyse folgt daraus: Datenschutzanforderungen sind Kundenanforderungen und gehören in die Erhebung – nicht als nachträgliche Compliance-Aufgabe, sondern als Teil des Bedarfsbilds.

Wer Kundendaten erhebt, sollte nach Zweckbindung und Datenminimierung arbeiten, personenbezogene und nicht personenbezogene Daten getrennt halten, den Datenzugriff dokumentieren und Rollen sowie Berechtigungen festlegen.

Das ist nicht nur Aufsichtsthema, sondern wird zunehmend selbst zum Kaufargument gegenüber öffentlichen Auftraggebern und größeren Kunden.

Zielbild und Entscheidungsfragen vor der Erhebung festlegen

Der erste Schritt einer Bedarfsanalyse ist die Klärung der Ziele und der Fragen, die sie beantworten soll. Ohne diesen Schritt werden Umfang, Methode und Abbruchpunkt beliebig.

Sinnvoll ist, die anstehende Entscheidung in einem Satz zu formulieren. Beispiel: Soll für das Segment der Kleinbetriebe eine vereinfachte Variante mit Self-Service-Onboarding gebaut werden, oder ist das Hauptproblem die Anbindung an bestehende Buchhaltungssysteme?

Aus der Entscheidungsfrage folgen Hypothesen. Eine Hypothese ist eine überprüfbare Vermutung über den Kundenbedarf, kein Wunsch.

Beispiel: Bestehende Kleinbetriebe brechen das Onboarding ab, weil sie Daten doppelt erfassen müssen. Gute Hypothesen benennen Zielgruppe, Situation, vermutete Ursache und erwartete Wirkung, wenn der Bedarf gedeckt wird.

Zu jeder Hypothese gehören Erfolgskriterien: Woran erkennt man, dass die Analyse eine belastbare Antwort geliefert hat? Das kann eine Mindestzahl geführter Gespräche sein, eine bestimmte Verteilung von Nennungen, ein messbarer Anteil betroffener Bestandskunden oder ein quantifizierbarer Aufwand beim Kunden.

Ebenso wichtig sind Abbruchkriterien: Wann wird die Analyse vorzeitig beendet oder verschoben? Etwa wenn sich nach einer festgelegten Zahl von Gesprächen kein wiederkehrendes Muster zeigt oder wenn die Datenlage für eine Entscheidung nicht ausreicht.

Der zweite Schritt ist die Zielgruppenbestimmung: Für welche konkrete Gruppe wird die Analyse durchgeführt? Eine Bedarfsanalyse für „die Kunden“ ist zu unscharf, um zu einem Ergebnis zu führen. Die Festlegung sollte vor der Datensammlung erfolgen, nicht danach.

Praktisch bewährt hat sich eine kurze Zielbild-Seite: Ausgangslage, Entscheidungsfrage, Hypothesen, Zielgruppen, Erfolgskriterien, Abbruchkriterien, Zeitraum, Verantwortliche und die Regelung, wer die Ergebnisse abnimmt.

Dort werden auch Datenschutzfragen ausdrücklich festgehalten – welcher Zweck, welche Datenkategorien, welche Rechtsgrundlage, wie lange aufbewahrt.

Schritte einer systematischen Bedarfsanalyse für Softwareanbieter in Österreich

Zielsegmente und Rollen für Software richtig schneiden

Bedarfe unterscheiden sich systematisch nach Branche, Unternehmensgröße, Rolle der Gesprächsperson, Nutzungsintensität und Kaufprozess. Wer diese Achsen vermischt, erhält Aussagen, die einander widersprechen und sich nicht priorisieren lassen.

Bewährt ist, zwei bis drei Segmentierungsachsen festzulegen und die Erhebung danach zu schichten.

In Österreich sind einige Kundengruppen besonders prägend. Kleine und mittlere Unternehmen arbeiten oft ohne eigene IT-Abteilung und entscheiden rasch. Ein-Personen-Unternehmen dominieren Preis, Einfachheit und Zeitgewinn.

Genossenschaften und Verbünde versorgen mehrere Mitglieder über ein System, Gremien entscheiden mit. Öffentliche Auftraggeber folgen formalen vergaberechtlichen Regeln; Datenschutz- und Sicherheitsanforderungen stehen oft ausdrücklich in der Ausschreibung.

Neben der Organisationseinheit ist die Rolle entscheidend. Fachbereiche beschreiben ihren Arbeitsablauf und die tägliche Reibung. IT-Verantwortliche fragen nach Integration, Betrieb, Sicherheit und Wartbarkeit. Die Geschäftsführung fragt nach Kosten, Risiko und Wirkung.

Ein und dieselbe Funktion kann für diese drei Rollen unterschiedlich attraktiv sein. Wer die Rollen nicht trennt, hört nur die jeweils lauteste Stimme.

Hilfreich ist außerdem die Unterscheidung nach Nutzungsintensität – Vielnutzer, Gelegenheitsnutzer, ausgestiegene Kunden –, weil daraus unterschiedliche Bedarfe entstehen.

Auch der Kaufprozess gehört als eigene Dimension dazu: Selbstbedienung mit Kreditkarte, Angebot über den Vertrieb, Rahmenvertrag mit Beschaffungsstelle.

Der Kaufprozess bestimmt, welche Nachweise – von Sicherheitsfragen über Auftragsverarbeitungsverträge bis zu Ausschreibungsunterlagen – im Verkaufsfall tatsächlich vorzulegen sind. Damit bestimmt er auch, welche Anforderungen in die Bedarfsanalyse gehören.

Für die Auswertung sollte jedes Segment groß genug sein, um Aussagen zu tragen. Besteht ein Segment nur aus wenigen Betrieben, ist eine qualitative Aussage möglich, eine statistische Verallgemeinerung aber nicht. Diese Grenze sollte im Bericht offen benannt werden.

Datenquellen, die in Softwareunternehmen ohnehin vorhanden sind

Der größte Teil des relevanten Materials liegt in Softwareunternehmen bereits vor.

Typische Quellen sind Produktanalytics zu Funktionsaufrufen und Nutzungsverläufen, Support-Tickets mit Fehlermeldungen und Workaround-Beschreibungen, Aufzeichnungen oder Protokolle von Sales-Calls, Churn- und Kündigungsdaten mit Begründungen, API- und System-Logs, Auswertungen der Feature-Nutzung sowie Kundenbefragungen und Feedback von Implementierungspartnern.

Diese Quellen haben unterschiedliche Aussagekraft. Nutzungsdaten zeigen, was passiert, aber nicht, warum. Tickets zeigen Reibung, aber nur bei jenen, die sich melden. Churn-Daten zeigen Verluste, sind aber oft dünn dokumentiert. Sales-Gespräche sind reich an Kontext, aber interessengeleitet.

Die Bedarfsanalyse gewinnt, wenn mehrere Quellen auf dieselbe Hypothese geprüft werden und Widersprüche stehen bleiben dürfen, statt geglättet zu werden.

Sinnvoll ist ein Dateninventar. Es hält je Quelle Zweck, Datenkategorien, mögliche personenbezogene Daten, Rechtsgrundlage, Aufbewahrung, verantwortliche Rolle und Zugriffsberechtigte fest.

Ein solches Inventar ist zugleich Vorarbeit für die Aufzeichnungen nach Art. 30 DSGVO.

Vergleich von Datenquellen in der Bedarfsanalyse für Softwareanbieter

Methodenmix: Interviews, Umfragen, Beobachtung, Jobs-to-be-Done

Qualitative und quantitative Methoden beantworten unterschiedliche Fragen. Qualitative Verfahren erklären Zusammenhänge und liefern die Sprache der Kunden. Quantitative Verfahren zeigen Verbreitung und Gewicht.

Ein Mix aus wenigen tiefen Gesprächen und einer breiteren Erhebung ist meist wirksamer als eine einzelne Methode.

Umfragen und Fragebögen bieten direkten Zugang zu Kundenmeinungen und lassen sich quantifizieren. Ihr bekanntestes Risiko ist die geringe Rücklaufquote, die die Datenqualität beeinträchtigen kann.

Deshalb sollten Fragebögen kurz sein, mit klaren Antwortskalen arbeiten und nach Möglichkeit auf einer Vorstufe aus Interviews aufbauen. So bilden die Antwortoptionen tatsächliche Arbeitsweisen ab und nicht interne Annahmen.

Interviews liefern detaillierte Informationen und erlauben spontane Nachfragen. Allerdings sind sie zeitaufwendig – in der Durchführung wie in der Auswertung.

Ein brauchbarer Leitfaden beginnt mit dem letzten konkreten Vorkommnis statt mit allgemeinen Meinungsfragen. Er fragt nach Auslöser, Ablauf, beteiligten Personen, Hilfsmitteln, Zeitaufwand und Folgen. Er endet mit der Frage, was die Person heute tut, um das Problem zu umgehen.

Hypothetische Fragen nach Wünschen sollten sparsam eingesetzt werden, weil sie selten belastbar sind.

Beobachtung ergänzt das Gespräch, weil zwischen berichtetem und tatsächlichem Verhalten oft eine Lücke liegt. Nutzertests, Shadowing im Arbeitsalltag oder die gemeinsame Durchsicht eines realen Datensatzes zeigen Reibungen, die im Interview nicht erwähnt werden.

Der Aufwand ist höher und die Zahl der Beobachtungen kleiner. Deshalb eignet sich Beobachtung vor allem für die Prüfung zentraler Hypothesen.

Jobs-to-be-Done rückt den Zweck in den Mittelpunkt: nicht das Produktmerkmal, sondern die Aufgabe, die jemand in einer bestimmten Situation erledigen will. Daraus lassen sich Fragen nach Fortschritt und Hindernissen ableiten, nicht nach Funktionen.

Die Kano-Analyse ordnet Merkmale danach, wie stark ihre Erfüllung oder Nichterfüllung die Zufriedenheit beeinflusst. Sie hilft, Basis-, Leistungs- und Begeisterungsmerkmale auseinanderzuhalten, wenn viele Einzelwünsche vorliegen.

Für die Rekrutierung von Gesprächspartnern sind österreichische Strukturen hilfreich: Fachverbände und Fachgruppen der Wirtschaftskammer Österreich, Branchen- und Interessensnetzwerke, Fachmessen, Anwendergruppen sowie Kooperationen mit Fachhochschulen und Universitäten.

Über solche Kanäle lassen sich auch Betriebe erreichen, die nicht zu den eigenen Bestandskunden zählen. Das ist wichtig, um eine Stichprobe nicht nur aus zufriedenen Kunden zu bilden.

Bei jeder Methode gilt: Teilnahme freiwillig, Zweck offengelegt, Daten sparsam erhoben, Ergebnisse so aufbereitet, dass Rückschlüsse auf einzelne Personen vermieden werden, wo das nicht erforderlich ist.

Vorteile und Risiken verschiedener Methoden in der Bedarfsanalyse

Vom Rohsignal zum validierten Bedarf: Gap-Analyse und Priorisierung

Die Auswertung beschreibt zuerst den Ist-Zustand: Wie arbeiten Kunden heute, welche Hilfsmittel nutzen sie, welche Schritte kosten Zeit, wo entstehen Fehler?

Danach folgt der Soll-Zustand: Was wäre aus Kundensicht ein gutes Ergebnis, unabhängig davon, welches Produkt es liefert? Die Differenz ist die Lücke – der eigentliche Gegenstand der Bedarfsanalyse.

Aus den Lücken werden Bedarfshypothesen formuliert und mit Belegen hinterlegt: Anzahl der Nennungen, betroffene Segmente, Häufigkeit im Support, beobachtete Auswirkungen.

Widersprüche gehören ausdrücklich in den Bericht. Wenn der Fachbereich ein Merkmal verlangt, das die IT ablehnt, oder wenn Vielnutzer und Neukunden entgegengesetzte Anforderungen haben, ist genau das eine entscheidungsrelevante Information – kein Auswertungsfehler.

Für die Priorisierung haben sich einfache Scoring-Modelle bewährt. Impact/Effort stellt erwarteten Nutzen dem Umsetzungsaufwand gegenüber. RICE gewichtet zusätzlich Reichweite, Wirkung, Zuversicht in die Schätzung und Aufwand. MoSCoW sortiert nach Muss-, Soll-, Kann- und Nicht-Kriterien und eignet sich gut, um mit Stakeholdern eine gemeinsame Sprache zu finden.

Entscheidend ist weniger das Modell als die Disziplin, Kriterien vorab festzulegen und für alle Einträge gleich anzuwenden.

Wo öffentliche Stellen Bedarfsanalysen durchführen, ist der Ablauf ähnlich aufgebaut. Beim österreichischen GAP-Strategieplan wurden auf Basis einer vorangegangenen Stärken-Schwächen-Analyse insgesamt 45 Bedarfe ermittelt. Sie verteilten sich auf mehrere Ziele: 11 im Bereich eines intelligenten, krisenfesten und diversifizierten Agrarsektors, 16 im Umwelt- und Klimaschutz, 12 im sozioökonomischen Gefüge ländlicher Gebiete und 6 im Querschnittsziel Modernisierung des Sektors.

Der Entwurf war in die Kapitel Bedarfsermittlung und Bedarfspriorisierung gegliedert. Jede Bedarfsbeschreibung stellte Ausgangslage und Zielzustand dar. Bis 15. Jänner 2021 konnte Stellung genommen werden.

Das Beispiel zeigt zwei übertragbare Prinzipien: erst Lücken systematisch erheben, dann priorisieren – und jede Priorisierung nachvollziehbar begründen.

Ein häufiger Fehler ist die vorzeitige Verdichtung. Wenn aus zwanzig Einzelaussagen drei Etiketten werden, ist die Spur zum Beleg verloren.

Besser ist eine nachvollziehbare Kette von der Rohaussage über die Lücke zur Bedarfshypothese bis zur Prioritätsentscheidung. Sie macht die Analyse überprüfbar und später aktualisierbar.

Priorisierung von Bedarfshypothesen mit dem RICE-Modell

Relevante Kennzahlen aus der GAP-Strategieplan-Bedarfsanalyse (Österreich)

Ergebnisse dokumentieren: Roadmap, Business Case und Compliance-Nachweis

Am Ende steht ein Bericht, der Ergebnisse, Erkenntnisse und Empfehlungen für die Umsetzung festhält. Bewährt ist eine dreiteilige Struktur.

Der Management-Teil enthält Entscheidungsfrage, Kernergebnis und Empfehlung. Der Analyseteil enthält Segmente, Datenquellen, Methoden, Lücken und Widersprüche. Der Anhang enthält Interviewleitfäden, Fragebögen, Auswertungslogik und Dateninventar.

Daraus entsteht ein priorisierter Anforderungskatalog. Er trennt sauber zwischen Kundenanforderung (was gelöst werden soll), Produktanforderung (welche Funktion das leistet) und technischer Umsetzung.

Diese Trennung verhindert, dass im Gespräch genannte Lösungsvorschläge ungeprüft zu Spezifikationen werden.

Die Roadmap verbindet den Katalog mit Zeiträumen und Verantwortlichkeiten. Sie enthält je Eintrag den zugrunde liegenden Bedarf, die Prioritätsstufe, die Erfolgskriterien sowie die Annahme, die sich ändern müsste, damit der Eintrag neu bewertet wird.

Ein Business Case ergänzt den erwarteten Nutzen – Zeitgewinn beim Kunden, Reduktion von Supportaufwand, Zugang zu einem Segment, Preisgestaltungsspielraum – und die zu erwartenden Kosten. Wo Schätzungen unsicher sind, sollte die Unsicherheit benannt und nicht in einer einzelnen Zahl versteckt werden.

Die Dokumentation hat zugleich eine Compliance-Funktion. Wegen der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO muss das Unternehmen belegen können, wie es mit Daten umgeht.

Ein Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO, klare Rechtsgrundlagen nach Art. 6 DSGVO und ein nachvollziehbarer Umgang mit Betroffenenrechten gehören daher zur Grundausstattung. Ob ein Datenschutzbeauftragter zu bestellen ist, richtet sich nach den einschlägigen Bestimmungen.

Damit die Unterlagen im Alltag nutzbar bleiben, sollten sie in der Form gepflegt werden, in der Produkt- und Vertriebsteams ohnehin arbeiten – etwa als versionierte Seite im Produkt-Wiki mit klarer Verantwortlichkeit und Datum der letzten Aktualisierung.

Nach der Analyse: Umsetzung, Messung und laufende Bedarfskontrolle

Eine Bedarfsanalyse ist kein Projekt mit einem Enddatum. Bedarf verändert sich mit Kundengröße, Marktlage, Technologie und Rechtsrahmen.

Deshalb gehört zu jeder Analyse ein Rückkanal: Wie kommt neues Kundensignal künftig in die Produktplanung? Wer sammelt es, wer bewertet es, in welchem Rhythmus?

Sinnvoll ist ein festes Set an Metriken, das die ursprünglichen Hypothesen überprüft: Nutzung der neuen Funktion, Abbruchstellen im Onboarding, Supportaufwand je Kunde, Anteil der Kunden mit abgeschlossenem Datenexport, Bindungsrate im Zielsegment.

Diese Messgrößen sollten bereits bei der Planung festgelegt werden, nicht erst nach der Einführung.

Als Rhythmus hat sich eine Zweiteilung bewährt: ein quartalsweiser Produktcheck, in dem neue Signale, Rechtsänderungen und laufende Kennzahlen durchgesehen werden, und ein jährlicher Strategie-Review, der Grundsatzfragen behandelt – Zielsegmente, Preismodell, Plattformentscheidungen, Compliance-Roadmap.

Der Jahresreview lässt sich gut im Jänner ansetzen, weil dann Erfahrungen aus dem Vorjahr, Budgetplanung und anstehende Regulierungsfristen zusammenkommen.

Zu beobachten sind die weitere Aufsichts- und Anwendungspraxis zum Datenschutz und zum Data Act sowie die Nachfrageseite: Anforderungen an Datenexport, Zugriffstransparenz und Datenschutzfunktionen werden zunehmend in Ausschreibungen abgefragt.

Damit sind sie Teil des Produktbedarfs, nicht nur eine Rechtsfrage.

Ein einfacher Test für die Wirksamkeit des Prozesses: Kann das Team für jede Position der Roadmap sagen, welcher Kundenbedarf, welcher Beleg und welches Erfolgskriterium dahinterstehen?

Wo diese Kette fehlt, hat die Bedarfsanalyse ihre Aufgabe noch nicht erfüllt – dort ist sie wieder zu einer Wunschliste geworden.

Rhythmus der laufenden Bedarfskontrolle nach der Analyse