Bildquelle: Bildquelle: Pexels / Cleyder Duque – https://www.pexels.com/photo/people-sitting-on-chair-8761328/
SFIA hilft im IT-Betrieb nur dann, wenn Skillprofile, Rollen und Entwicklungspfade zusammenpassen
In vielen IT-Organisationen wird über Fachkräftemangel, Umschulung, Reskilling und Skill-Gaps gesprochen, als ließe sich das Problem mit einem größeren Trainingskatalog lösen. Genau dort beginnt oft der Denkfehler. Die operative Realität in Service Desk, Plattformbetrieb, Informationssicherheit, Entwicklung oder Architektur hängt nicht an einzelnen Kursen, sondern an sauber beschriebenen Rollen, realistischen Verantwortungsniveaus und nachweisbaren Fähigkeiten im Arbeitsalltag. Wenn diese drei Ebenen auseinanderlaufen, entstehen bekannte Symptome: überfrachtete Stellenprofile, unklare Karrierepfade, wechselhafte Qualitätsniveaus im Betrieb und Teams, die zwar Zertifikate sammeln, aber kritische Serviceverantwortung nur unscharf abdecken.
Hier kann SFIA nützlich sein. Das Framework wird international als gemeinsame Sprache für digitale Fähigkeiten und Kompetenzen genutzt. Sein Wert entsteht aber nicht dadurch, dass Organisationen eine neue Skill-Matrix an die Wand hängen. Wirksam wird SFIA erst dann, wenn die Skillbeschreibung an reale Betriebsaufgaben, Verantwortungsgrade und Entwicklungspfade angeschlossen wird. Wer SFIA nur als hübsches HR-Inventar benutzt, produziert mehr Tabellen. Wer es mit Servicearbeit, Rollenarchitektur und Assessments verbindet, bekommt dagegen ein belastbares Steuerungsinstrument.
Gerade für IT-Management ist das interessant, weil sich damit operative Engpässe anders betrachten lassen. Nicht die Frage „Wer war auf welcher Schulung?“ steht im Mittelpunkt, sondern: Welche Fähigkeiten braucht ein Service oder Produkt an welchem Verantwortungsniveau, wo fehlen belastbare Nachweise und wie müssen Rollen zugeschnitten werden, damit Betrieb und Entwicklung nicht an denselben unscharfen Zuständigkeiten scheitern?
Eine Skill-Matrix allein löst noch kein Betriebsproblem
Die SFIA Foundation betont ausdrücklich, dass SFIA keine starre Methodik und keine vorgeschriebenen Organisationsstrukturen definiert. Genau das ist Stärke und Risiko zugleich. Stärke, weil das Framework in klassische Linienorganisationen, agile Teams, Plattformmodelle oder föderierte Betriebsstrukturen übersetzt werden kann. Risiko, weil viele Unternehmen aus dieser Freiheit eine zu grobe Nutzung machen: Sie sammeln Skills, ordnen sie Personen zu und glauben, damit schon mehr Transparenz geschaffen zu haben.
Für den IT-Betrieb reicht das nicht. Ein Service Desk braucht andere Schwerpunktprofile als ein IAM-Team, ein Site-Reliability-Team oder ein Change Enablement Board. Wenn dieselbe Skillliste überall gleich verwendet wird, verschwinden die betriebsrelevanten Unterschiede. Die Folge ist meist eine Scheinvergleichbarkeit, die im Alltag wenig hilft. Dann gelten Mitarbeitende formal als ähnlich qualifiziert, obwohl sie in Autonomie, Einfluss, Risikoübernahme oder Kommunikation mit Fachbereichen auf ganz unterschiedlichen Niveaus arbeiten.
Sinnvoll wird SFIA deshalb erst auf der Ebene sauberer Rollenprofile. Ein Rollenprofil muss beschreiben, welche Fähigkeiten für eine Aufgabe oder Serviceverantwortung tatsächlich ausschlaggebend sind, auf welchem Verantwortungsniveau sie benötigt werden und welche angrenzenden Kompetenzen im Zusammenspiel wichtig sind. Für IT-Leitungen heißt das: Erst Rollen und Services schärfen, dann Skills zuordnen – nicht umgekehrt.
Die sieben Verantwortungsstufen sind wichtiger als viele Zertifikatslisten
Ein zentraler SFIA-Gedanke ist die Kombination aus Fähigkeiten und Verantwortungsgrad. Die Stiftung beschreibt die Levels unter anderem über Autonomie, Einfluss, Komplexität, Business Skills und Wissen. Genau dieser Punkt wird in der Praxis oft unterschätzt. Viele Skillprogramme konzentrieren sich fast ausschließlich auf Fachwissen: Hat jemand Tool X bedient, Methode Y gelernt oder ein Zertifikat Z bestanden? SFIA zieht die Diskussion bewusst breiter.
Das ist für IT-Organisationen enorm relevant. Ein Incident Manager, ein Platform Owner oder eine Serviceverantwortliche unterscheiden sich nicht nur durch Fachthemen, sondern auch durch den Rahmen, in dem Entscheidungen getroffen werden. Wer eskaliert selbstständig? Wer beeinflusst andere Teams? Wer steuert Risiken über Teamgrenzen hinweg? Wer muss technische Sprache in betriebliche Prioritäten übersetzen? Genau diese Fragen entscheiden darüber, ob ein Team unter Last stabil bleibt oder in Übergaben und Abstimmungen steckenbleibt.
Deshalb ist SFIA als Karriere- und Skillmodell nur dann hilfreich, wenn Jobtitel, Verantwortungsstufen und Arbeitswirklichkeit sauber zusammenpassen. Eine Senior-Bezeichnung ohne entsprechende Autonomie und Wirkung hilft niemandem. Umgekehrt entstehen operative Risiken, wenn Menschen faktisch auf einem höheren Verantwortungsniveau arbeiten als ihr Profil, ihre Begleitung oder ihre Entwicklungspfadlogik abbildet.
Assessment muss mehr sein als eine freundliche Selbsteinschätzung
Besonders wertvoll ist SFIA dort, wo Unternehmen nicht nur definieren, sondern auch belastbar bewerten wollen. Die offizielle SFIA-Guidance zu Assessments unterscheidet klar zwischen Selbstbewertung, unabhängiger objektiver Bewertung und formal zertifizierten Assessments. Diese Differenz ist wichtig. Selbstbewertungen haben ihren Platz, vor allem als Einstieg und zur Einbindung der Mitarbeitenden. Sie reichen aber selten aus, wenn es um kritische Rollenbesetzungen, Nachfolgeplanung oder belastbare Entwicklungsentscheidungen geht.
Viele IT-Bereiche kennen das Problem aus eigener Erfahrung. In ruhigen Phasen wirken Skill-Selbsteinschätzungen plausibel. Sobald aber ein Major Incident, ein Audit, eine Migration oder ein Release unter Druck stattfindet, zeigt sich, ob Kompetenz wirklich nachweisbar ist. Wer SFIA ernst nimmt, sollte deshalb Nachweise, Praxiserfahrung, Peer- oder Managementsicht und die Anforderungen einer konkreten Rolle zusammenführen. Erst dadurch wird aus einem weichen Stimmungsbild ein belastbarer Kompetenzbefund.
Für kleinere Organisationen ist das ebenfalls relevant. Gerade sie profitieren laut SFIA davon, kein eigenes Framework entwickeln zu müssen. Aber genau dort sind Fehlbesetzungen besonders teuer, weil einzelne Schlüsselpersonen große Abhängigkeiten erzeugen. Ein leichtgewichtiges, aber sauberes Assessment-Modell ist daher wichtiger als eine besonders große Skilldatenbank.
Guter Einsatz verbindet Personalentwicklung mit Serviceverantwortung
Die SFIA Foundation ordnet das Framework in einen breiteren Human-Capital-Entwicklungszyklus ein: Planung, Gewinnung, Einsatz, Assessment, Analyse, Entwicklung und Vergütung. Für IT-Management ist das mehr als HR-Sprache. Es beschreibt einen praktischen Zusammenhang, der in vielen Organisationen noch zu oft getrennt läuft. Recruiting definiert Wunschprofile, Linienführung verteilt Arbeit, Learning & Development plant Maßnahmen und die operative Leitung kämpft parallel mit denselben Engpässen.
Genau hier kann SFIA helfen, sofern es nicht in einer Abteilung isoliert wird. Wenn Rollenprofile aus Servicezielen abgeleitet werden, Assessments auf reale Einsatzfelder schauen und Entwicklungspläne an künftige Servicebedarfe gekoppelt werden, entsteht ein gemeinsamer Steuerungsrahmen. Dann lässt sich zum Beispiel sauberer beantworten, welche Fähigkeiten für eine geplante Plattformkonsolidierung fehlen, welche Verantwortung im Bereitschaftsbetrieb heute zu stark auf Einzelnen lastet oder wo externe Partner nur deshalb unverzichtbar bleiben, weil internes Kompetenzwachstum nie systematisch geplant wurde.
Der große Vorteil liegt dabei nicht in maximaler Granularität, sondern in gemeinsamer Verständlichkeit. SFIA arbeitet bewusst mit einer klaren, relativ generischen Sprache. Das hilft IT-Leitung, HR, Lernverantwortlichen und Fachbereichen, dieselbe Lage zu besprechen, ohne jedes Mal neue Übersetzungsprobleme zwischen Rollenbildern, Skillkatalogen und Organisationsdesign zu erzeugen.
Worauf IT-Management jetzt konkret achten sollte
- Rollen vor Listen: Zuerst sollten Service- und Rollenprofile geschärft werden, erst danach die Skillzuordnung.
- Verantwortungsniveau sichtbar machen: Autonomie, Einfluss und Komplexität sind für Betriebsstabilität oft wichtiger als einzelne Kursnachweise.
- Selbstbewertungen nicht überdehnen: Für kritische Rollen braucht es mindestens ergänzende objektive Sicht und belastbare Evidenz.
- Skillarbeit mit Servicezielen verbinden: Entwicklungspfade sollten an künftige Betriebs- und Transformationsbedarfe anschließen, nicht nur an individuelle Wunschlisten.
- Klein anfangen, aber sauber: Gerade kleinere Teams profitieren von SFIA, wenn sie ein schlankes Set zentraler Rollen und Fähigkeitsprofile zuerst abbilden.
- Externe Abhängigkeiten transparent machen: Ein gutes SFIA-Modell zeigt, wo kritisches Know-how intern fehlt und wo Partner nur Lücken kompensieren.
Fazit
SFIA ist kein Wundermittel gegen Fachkräftemangel und auch kein Ersatz für gute Führung. Das Framework entfaltet seinen Wert aber dort, wo IT-Organisationen Skills nicht länger isoliert von Serviceverantwortung, Rollenarchitektur und Entwicklungsplanung betrachten. Genau dann wird aus einer abstrakten Kompetenzsprache ein praktisches Steuerungsmodell für Betrieb, Transformation und Nachfolgefähigkeit.
Für CIOs, IT-Leitungen und People-Verantwortliche liegt die eigentliche Chance deshalb nicht in einer neuen Matrix, sondern in einer besseren Verbindung zwischen Können, Verantwortung und Einsatzrealität. Wenn diese Verbindung gelingt, werden Skillprogramme präziser, Karrierepfade glaubwürdiger und operative Risiken früher sichtbar. Wenn sie fehlt, bleibt SFIA trotz guter Absicht nur eine weitere Tabelle im Intranet.
