Wie das Amt für Digitales und IT arbeitet: wer wofür zuständig ist, was passiert, wenn Sie einen Bedarf melden, und wer an welcher Stelle entscheidet.
Wenn Ihr Amt etwas von DIGIT braucht — eine neue Software, eine Änderung an einem Fachverfahren, Unterstützung bei einem Vorhaben — dann soll klar sein: An wen wende ich mich? Was passiert danach? Und wer entscheidet eigentlich?
Genau das regelt das DIGIT Operating Model, kurz DIGITOM. Es ist die Arbeitsordnung des Amts. Sie beschreibt drei Dinge: welche Bereiche es im Amt gibt und wofür sie zuständig sind, welchen Weg ein Bedarf von der Meldung bis zur Umsetzung nimmt, und welche Runde an welcher Stelle entscheidet.
Das Modell lehnt sich an ITIL 4 an. Das ist ein international verbreiteter Standard dafür, wie IT-Organisationen ihre Leistungen erbringen. DIGIT hat ihn auf die eigene Situation zugeschnitten.
Jedes Amt hat eine zuständige Person im Stakeholder-Management. Sie kennt Ihr Haus, nimmt Ihren Bedarf auf und vertritt Ihre Sicht innerhalb von DIGIT — ausdrücklich als Ihre Interessenvertretung, nicht als neutrale Vermittlung.
Jeder Bedarf durchläuft dieselben Schritte. Sie können nachvollziehen, wo Ihr Anliegen gerade steht und was als Nächstes passiert.
Alle Bedarfe werden nach denselben Kriterien eingeschätzt. Damit lässt sich begründen, warum das eine Vorhaben vorgezogen wird und das andere wartet.
Wer einen Bedarf fachlich bewertet, entscheidet nicht selbst darüber. Bewertung und Entscheidung liegen bewusst in verschiedenen Händen.
Alle Vorhaben laufen über ein gemeinsames Portfolio. So fallen ähnliche Anfragen aus verschiedenen Ämtern auf, bevor zweimal dasselbe gebaut wird.
Auch eine Ablehnung oder Zurückstellung wird begründet und über Ihre Ansprechperson an Sie zurückgemeldet.
Zwei Abläufe hängen zusammen. Zuerst wird aus einem gemeldeten Bedarf eine Entscheidung und daraus ein Projekt. Sobald das Projekt startet, beginnt der zweite Ablauf: Der Service wird aufgebaut, eingeführt, betrieben, unterstützt und regelmäßig überprüft.
An Ihre Ansprechperson im Stakeholder-Management. Sie nimmt den Bedarf auf, bespricht ihn mit Ihnen und sorgt dafür, dass er an der richtigen Stelle landet. Alltägliche Anfragen und Störungen laufen weiterhin über den Service Desk.
Als Erstes wird geprüft, ob das, was Sie brauchen, schon im bestehenden Angebot von DIGIT enthalten ist. Wenn ja, wird es als normale Anfrage bearbeitet und Sie müssen nichts weiter tun. Nur wenn etwas Neues nötig ist oder ein bestehender Service deutlich verändert werden muss, durchläuft Ihr Anliegen den beschriebenen Weg.
Ihre Ansprechperson führt mit Ihnen ein Klärungsgespräch und hält das Ergebnis in einem Bedarfssteckbrief fest. Darin steht, was Sie brauchen, warum, welchen Nutzen es bringt und welche Rahmenbedingungen gelten. Sie müssen das Dokument nicht selbst schreiben.
Das hängt vom Vorhaben ab. Die meisten Bedarfe entscheidet die Demand- und Stakeholder-Runde. Große oder besonders weitreichende Vorhaben gehen an das Mission Board, in dem unter anderem die Amtsleitung und die Abteilungsleitungen sitzen.
Feste Bearbeitungszeiten sind im Modell bisher nicht festgelegt. Geregelt ist, dass Unterlagen mindestens 24 Stunden vor einer Sitzung vorliegen müssen und dass Entscheidungen unmittelbar nach der Sitzung mitgeteilt werden. Das Mission Board tagt alle zwei Wochen.
Die Entscheidung wird begründet und über Ihre Ansprechperson an Sie zurückgemeldet. Möglich sind auch eine Zurückstellung, eine Zusammenlegung mit ähnlichen Anliegen aus anderen Ämtern oder eine Freigabe unter Auflagen.
Das DIGITOM ist als Konzept freigegeben, aber nicht in allen Teilen fertig ausgearbeitet. Offene Punkte sind kein Mangel, sondern der nächste Arbeitsschritt. Diese Übersicht zeigt, wo die einzelnen Bausteine stehen.
| Baustein | Worum es geht | Stand |
|---|---|---|
| Demand-Portfolio-Management | Aufgaben und Zuständigkeiten sowie die Regeln der Demand- und Stakeholder-Runde | Abgenommen |
| Service-Portfolio-Management | Aufgaben, Regeln der Service-Operations-Runde und der Weg eines Service | In Abstimmung |
| Stakeholder-Management | Betreuung der Ämter, Bedarfsaufnahme und Rückmeldung | Teils ausgearbeitet |
| Mission Board | Zusammensetzung, Zuständigkeit und Entscheidungsverfahren | In Abstimmung |
| Projekt-Portfolio-Management | Überführung freigegebener Bedarfe in Projekte | Noch nicht beschrieben |
| Vision Board | Langfristige Richtung und strategischer Rahmen | Noch nicht ausgearbeitet |
| Prozess-Management | Methodischer Rahmen für die Prozesse des Amts | Ausgesetzt |
Ein Zeitplan für die weitere Einführung und ein Ausblick auf die Zusammenführung von DIGIT mit dem Haupt- und Personalamt sind vorgesehen, liegen aber noch nicht in abgestimmter Form vor. Sie werden ergänzt, sobald sie feststehen.
DIGIT gliedert seine Arbeit in Bereiche mit klar abgegrenzten Aufgaben. Wählen Sie einen Bereich aus, um zu sehen, wofür er zuständig ist und wann Sie mit ihm zu tun haben.
Das Stakeholder-Management ist die Schnittstelle zwischen den Ämtern und DIGIT. Jedes Amt, jeder Eigenbetrieb, jedes Referat und jede Stabsstelle hat eine feste zuständige Person.
Diese Person kennt Ihr Haus, pflegt den Kontakt aktiv, nimmt Bedarfe auf, klärt sie mit Ihnen und entscheidet, wohin Ihr Anliegen gehört. In den Entscheidungsrunden vertritt sie Ihre Sicht.
Eine Übersicht aller Ämter und Einheiten mit ihren Merkmalen. Sie dient dazu, die Betreuung sinnvoll zu verteilen — nicht als Selbstzweck.
Eine Anleitung für die Frage „Wohin gehört dieser Bedarf?“. Hier wird entschieden, ob es ein Bedarf ist. Wie dringend er ist, klärt danach das Demand-Portfolio.
Erfahrungen und Kritik aus den Ämtern werden systematisch gesammelt und ausgewertet, damit sie in die Weiterentwicklung einfließen.
Ein System, in dem Stammdaten, Gespräche und Bedarfe je Amt zusammenlaufen. Es ersetzt weder das Ticketsystem noch ein Vertriebswerkzeug.
Die zusammenfassende Aufgabenbeschreibung für diesen Bereich liegt bisher nur als Gerüst vor. Die Einzelkonzepte, die Arbeitsweise und die Rollenbeschreibungen sind dagegen ausgearbeitet. Die Angaben auf dieser Seite stammen aus diesen Unterlagen.
Hier laufen alle Bedarfe aus allen Ämtern zusammen. Der Bereich nimmt sie vom Stakeholder-Management entgegen, ordnet sie ein, analysiert sie, bewertet sie und bringt sie in eine Reihenfolge.
Am Ende steht eine Vorlage, mit der eine Runde entscheiden kann: Was ist das Anliegen, welche Möglichkeiten gibt es, was empfiehlt der Bereich, welche Auswirkungen und Risiken sind zu erwarten.
Ihr Anliegen wird erfasst und im Gespräch geklärt.
Stakeholder-ManagementVollständigkeit, Einordnung, Abhängigkeiten zu anderen Vorhaben.
Demand-PortfolioNutzen, Dringlichkeit und Machbarkeit ergeben die Reihenfolge.
Demand-PortfolioFreigabe, Ablehnung, Zurückstellung oder Weitergabe nach oben.
DSR oder Mission BoardAn das Projekt-Portfolio oder an das Service-Portfolio.
Demand-PortfolioJeder Bedarf wird anhand von vier Fragen eingeordnet. Die Antworten bestimmen maßgeblich, welche Runde entscheidet. Im Zweifelsfall wird immer die kritischere Einstufung gewählt.
| Frage | Was dahintersteckt | Mögliche Antworten, nach Gewicht geordnet |
|---|---|---|
| Woher kommt der Anstoß? | Eine gesetzliche Vorgabe wiegt schwerer als ein interner Verbesserungswunsch. | Gesetzlich vorgegeben · fachlich von außen · strategisch von innen · aus dem Tagesgeschäft |
| Wie tiefgreifend ist die Änderung? | Wird etwas neu aufgebaut oder nur verbessert? | Neugestaltung · Ausbau · Optimierung |
| Wo wirkt sie technisch? | Je breiter die Wirkung, desto mehr Abstimmung ist nötig. | Infrastruktur · Plattform · Fachverfahren · Querschnittskomponente · Daten und Schnittstellen |
| Wie unsicher ist die Lösung? | Gemeint ist nicht die technische Schwierigkeit allein, sondern auch der Abstimmungsaufwand. | Hochkomplex · komplex · moderat |
Immer dann, wenn mindestens eines zutrifft: Der Bedarf ist hochkomplex, er bedeutet eine Neugestaltung, oder er ist gesetzlich vorgegeben und mindestens komplex.
Bei Grenzfällen: Ausbau mit hoher Komplexität, Wirkung auf Infrastruktur oder Querschnittsthemen, oder fachliche Vorgaben von außen, die politisch heikel sein können.
Alle übrigen Bedarfe. Das ist der Regelfall.
Passt das Vorhaben zur Strategie? Welchen Nutzen bringt es? Wirkt es über das eigene Amt hinaus?
Wie wichtig ist es für die Organisation? Wie eilig ist es? Was passiert, wenn nichts getan wird?
Ist es technisch machbar? Ist es organisatorisch umsetzbar? Steht der Aufwand im Verhältnis?
Aus der Bewertung ergeben sich zwei Größen: Wie wichtig ist das Vorhaben und wie eilig ist es. Daraus folgt die Empfehlung.
Kommt in die nächste Sitzung, bei Bedarf auch in eine Sondersitzung.
Wird in die reguläre Planung aufgenommen, die Mittel werden vorgemerkt.
Schnelle Freigabe mit wenig Analyseaufwand.
Empfehlung ist meist Zurückstellung oder Ablehnung.
Jeder Bedarf bekommt außerdem eine Ampel dafür, wie machbar er technisch und organisatorisch ist. Ein Vorhaben, das wichtig und eilig ist, aber auf Rot steht, geht automatisch ans Mission Board.
Sobald ein Bedarf freigegeben ist, übernimmt dieser Bereich. Er führt alle laufenden Projekte des Amts zusammen und sorgt dafür, dass aus einer Entscheidung ein Projekt mit Auftrag, Leitung und Team wird.
Für diesen Bereich gibt es bisher keine eigene Aufgabenbeschreibung. Was hier steht, ergibt sich aus dem, was andere Teile des Modells über die Zusammenarbeit mit diesem Bereich festhalten.
Alles, was DIGIT den Ämtern anbietet, ist ein Service: das Ratsinformationssystem, der Arbeitsplatz, ein Fachverfahren. Dieser Bereich behält das gesamte Angebot im Blick.
Er sorgt dafür, dass jeder Service einheitlich beschrieben ist, dass vereinbarte Qualität gemessen wird und dass Änderungen kontrolliert ablaufen. Und er entscheidet mit, wann ein Service verbessert, neu aufgesetzt oder abgeschaltet wird.
Passt der Service ins Gesamtangebot? Gibt es etwas Ähnliches schon? Sind die Standards eingehalten? Diese Sicht ergänzt die Sicht derer, die einen einzelnen Service verantworten.
Geprüft wird, ob das Verfahren eingehalten und die Dokumentation vollständig ist. Ob ein Service fachlich das Richtige tut, entscheidet die Service-Verantwortung.
Der Bereich stellt Methoden, Vorlagen und Standards bereit. Die eigentliche Arbeit machen die Service-Verantwortlichen und die Betriebsteams. So wird der Bereich nicht zum Nadelöhr.
Einzelne Services sehen nur ihre eigene Lage. Der Bereich fasst die Erkenntnisse aus allen Services zusammen und macht Muster sichtbar.
Für jeden Service gibt es eine klare, aktuelle und vollständige Beschreibung. Alle Beteiligten greifen auf denselben Stand zu.
DIGIT und die Ämter verständigen sich darauf, welche Qualität ein Service haben soll. Diese Zusagen werden gemessen und regelmäßig besprochen.
Änderungen laufen kontrolliert ab, mit abgestuftem Aufwand je nach Risiko. Der Grundsatz: so wenig Formalien wie nötig, so viel wie erforderlich.
Die Steuerung des Gesamtangebots sowie die Überwachung laufender Services sind im Modell angelegt, aber noch nicht abschließend beschrieben. Störungen, Anfragen und wiederkehrende Probleme sind im Bereich Service-Support ausgearbeitet.
Das ist der Bereich, mit dem die meisten Beschäftigten am häufigsten zu tun haben: Etwas funktioniert nicht, oder es wird etwas Standardmäßiges gebraucht. Der Service-Support nimmt diese Fälle entgegen, bearbeitet sie und sorgt dafür, dass wiederkehrende Probleme an der Wurzel angegangen werden.
Der Bereich gehört organisatorisch zum Service-Portfolio. Er bündelt dort die Arbeitsfelder rund um den täglichen Betrieb.
Die Stelle, an der Meldungen ankommen. Sie nimmt auf, ordnet zu und löst, was direkt lösbar ist.
Etwas funktioniert nicht wie vorgesehen. Bearbeitung im ersten und, wenn nötig, im zweiten Level bis zur Lösung.
Standardleistungen, die abgerufen werden können — etwa ein Zugang oder eine Ausstattung.
Häufen sich ähnliche Störungen, wird die Ursache gesucht und, bis sie behoben ist, eine Behelfslösung bereitgestellt.
Dieser Bereich kümmert sich nicht um einzelne Vorhaben, sondern darum, wie im Amt gearbeitet wird. Er gibt den methodischen Rahmen für die übergreifenden Abläufe vor und befähigt die Fachbereiche, ihre eigenen Prozesse selbst zu steuern und zu verbessern.
Der Bereich wurde erprobt und das Konzept liegt freigegeben vor. Die Arbeit ist aber derzeit unterbrochen und wird überarbeitet. Was hier steht, beschreibt also nicht den heutigen Betrieb.
Entscheidungen werden nicht einzeln getroffen, sondern in festen Runden mit benannten Mitgliedern, festem Rhythmus und klaren Regeln. Es gibt drei Ebenen.
| Ebene | Runde | Worüber sie entscheidet | Stand |
|---|---|---|---|
| Langfristig | Vision Board | Setzt die Richtung und den Rahmen, in dem alles Weitere stattfindet. | Noch nicht ausgearbeitet |
| Mittelfristig | Mission Board | Entscheidet über große Vorhaben, verteilt Personal und Mittel und behält Projekte und kritische Services im Blick. | In Abstimmung |
| Laufend | Demand- und Stakeholder-Runde | Entscheidet über die alltäglichen Bedarfe aus den Ämtern. | Abgenommen |
| Laufend | Service-Operations-Runde | Entscheidet über Services: Start, größere Änderungen, Verbesserung oder Abschaltung. | In Abstimmung |
Das Vision Board ist die oberste Ebene. Es setzt die langfristige Richtung und den Rahmen, innerhalb dessen das Mission Board seine Entscheidungen trifft.
Für diese Runde gibt es bisher keine festgelegten Regeln. Zusammensetzung, Rhythmus und Verfahren sind offen. Was hier steht, ergibt sich aus dem, was andere Teile des Modells über das Vision Board sagen.
Das Mission Board ist die zentrale Entscheidungsrunde für IT- und Digitalisierungsvorhaben. Es übersetzt die langfristige Richtung in konkrete Maßnahmen, setzt Prioritäten und greift ein, wenn es irgendwo klemmt.
Sprengt ein Vorhaben den gesetzten Rahmen — etwa durch eine grundlegende Kursänderung oder eine große Investition — gibt das Mission Board es nach oben weiter.
Entscheidet über Freigabe, zeitliche Verschiebung oder Beendigung von Projekten und Bedarfen.
Behält im Blick, welche Kapazitäten verfügbar und gebunden sind, und verschiebt Prioritäten, wenn es eng wird.
Bewertet Projekte und wichtige Services regelmäßig nach einem Ampelsystem und steuert früh gegen.
Prüft, ob laufende Vorhaben noch zur strategischen Richtung passen, und passt sie bei Kurskorrekturen an.
Zieht Informationssicherheit, Datenschutz und das IT-Notfallmanagement hinzu, wenn es nötig ist.
Nimmt politische Initiativen in die reguläre Planung auf, statt sie an ihr vorbeilaufen zu lassen.
| Wer | Rolle in der Runde | Stimmrecht | Wann dabei |
|---|---|---|---|
| Amtsleitung | Vorsitz | ja | Immer. Entscheidet bei Stimmengleichheit. |
| Chief Digital Officer | Mitglied | ja | Immer |
| Abteilungsleitungen von DIGIT | Mitglieder | ja | Immer, Vertretung möglich |
| Chief of Staff | beratend | nein | Immer |
| Informationssicherheit | beratend | nein | Immer |
| Sitzungsleitung | beratend | nein | Immer. Erstellt die Tagesordnung, moderiert und verfolgt die Beschlüsse nach. |
| Demand-Portfolio | beratend | nein | Wenn neue Bedarfe oder Freigaben anstehen |
| Service-Portfolio | beratend | nein | Wenn es um Servicequalität oder Weiterentwicklung geht |
| Projekt-Portfolio | beratend | nein | Wenn es um Projektstände oder Freigaben geht |
| IT-Architektur, Projektleitungen, Stakeholder-Management, IT-Notfallmanagement | hinzugezogen | nein | Bei Bedarf |
Diese Runde entscheidet über die alltäglichen Bedarfe aus den Ämtern. Sie ist die Brücke zwischen der Aufnahme eines Bedarfs und dem Start eines Projekts.
Neben den Entscheidungen dient sie dem Austausch: Welche Bedarfe liegen an, welche Projekte laufen, wo gibt es Abhängigkeiten oder Engpässe.
Vier Bereiche mit Stimmrecht. Zusammen decken sie den gesamten Weg eines Bedarfs ab.
Bereitet vor, moderiert, protokolliert.
Bringt die Sicht der Ämter ein.
Prüft, was das Vorhaben für bestehende Services bedeutet.
Prüft, wie es sich in die laufenden Projekte einfügt.
Vertretungen haben volle Stimmrechte. Zusätzlich können Verantwortliche betroffener Services oder Fachleute beratend dazukommen; eingeladen werden sie vom Demand-Portfolio.
Die Runde arbeitet nach dem Konsent-Prinzip: Das Demand-Portfolio bringt einen Vorschlag ein, offene Fragen werden geklärt, und ohne schwerwiegenden begründeten Einwand gilt der Vorschlag als angenommen.
Wer einen Einwand erhebt, muss die Vorlage überarbeiten und einen konstruktiven Gegenvorschlag einbringen. Auch dieser unterliegt wieder demselben Verfahren. Führen zwei Durchgänge zu keiner Einigung, kann das Demand-Portfolio die Sache ans Mission Board geben.
Beschlussfähig ist die Runde, wenn alle vier Bereiche besetzt sind — durch die Mitglieder selbst oder ihre Vertretungen.
Diese Runde kümmert sich um das, was bereits läuft: die Services. Sie gibt den Start eines neuen Service frei, entscheidet über größere Änderungen und darüber, ob ein Service verbessert, neu aufgesetzt oder abgeschaltet wird.
Daneben ist sie der Ort, an dem sich Service-Verantwortung, Betrieb und Support regelmäßig abstimmen.
Den Start eines neuen Service, größere Änderungen an bestehenden Services sowie darüber, ob ein Service verbessert, neu aufgesetzt oder abgeschaltet wird.
Den Stand von Betrieb und Support, offene Klärungsfragen aus anderen Bereichen und die Zusammenarbeit an den Übergängen im Leben eines Service.
Neue Bedarfe. Die gehen direkt an das Demand-Portfolio.
Die Einschätzung der Service-Verantwortung, ob etwas als laufende Aufgabe, als Änderung oder als neuer Bedarf zu behandeln ist.
| Wer | Rolle | Weshalb |
|---|---|---|
| Service-Portfolio | Vorsitz | Blick auf das gesamte Angebot, Koordination, Verfahren |
| Abteilungsleitung Basis & Cloud | Mitglied | Betrieb der Infrastruktur: Netz, Cloud, Ausrollen |
| Abteilungsleitung Applikationen | Mitglied | Betrieb der Anwendungen und Fachverfahren |
| Leitung Support | Mitglied | Sicht des Supports und Nähe zu den Nutzenden |
| Stakeholder-Management | Mitglied | Sicht der Ämter, bringt offene Klärungsfragen ein |
| Service-Verantwortung | je nach Thema | Geht es um einen bestimmten Service, ist die zuständige Person anwesend und stimmberechtigt |
Infrastruktur und Anwendungen sind gleichwertig vertreten, weil Services meist beides berühren. Die Zusammensetzung nutzt bestehende Leitungsrollen und schafft keine neue Hierarchieebene. Nach sechs Monaten soll sie überprüft werden.
Von der ersten Meldung bis zum Projektstart. Vier Abschnitte, dazwischen drei Prüfpunkte. An jedem Prüfpunkt wird geschaut, ob alles Nötige vorliegt, bevor es weitergeht.
Am Ende dieses Abschnitts steht ein vollständig beschriebener Bedarf — und die Klarheit, dass er nicht schon durch bestehende Angebote abgedeckt ist.
Ein Anlass aus Ihrem Alltag: eine Gesetzesänderung, ein Ablauf, der nicht mehr passt, eine fehlende Funktion.
Über die dafür vorgesehenen Wege, etwa ein Ticket oder direkt bei Ihrer Ansprechperson.
Das Stakeholder-Management schaut, ob die Basisangaben vollständig sind und ob DIGIT zuständig ist.
Gibt es schon einen Service, der das abdeckt? Dann wird Ihr Anliegen als normale Anfrage bearbeitet und ist hier zu Ende.
Ein strukturiertes Gespräch mit Ihnen über Anforderungen, Nutzen und Rahmenbedingungen.
Ihre Anforderungen werden so festgehalten, dass die fachliche Sicht erhalten bleibt. Ergebnis ist der fertige Bedarfssteckbrief.
Ist etwas Neues nötig, geht der Bedarf an das Demand-Portfolio. Geht es um eine Änderung an einem bestehenden Service, an das Service-Portfolio. Ist der Weg unklar, wird er mit der zuständigen Service-Verantwortung geklärt.
Am Ende dieses Abschnitts liegt eine Vorlage vor, mit der eine Runde entscheiden kann.
Wenn nicht, geht der Bedarf zur Nachbesserung an das Stakeholder-Management zurück.
Der Bedarf wird nach den vier Fragen eingeordnet: Anstoß, Tragweite, technische Wirkung, Unsicherheit.
Was hängt mit anderen Vorhaben zusammen? Bei Bedarf werden IT-Architektur, Projekt-Portfolio und Service-Portfolio hinzugezogen.
Nach Nutzen und Wirkung, Druck und Notwendigkeit sowie Machbarkeit und Aufwand.
Wichtigkeit und Dringlichkeit ergeben die Empfehlung, dazu kommt eine Ampel für die Machbarkeit.
Alles wird in einer einheitlichen Vorlage zusammengeführt, inklusive des Vorschlags, welche Runde entscheiden soll.
Am Ende dieses Abschnitts steht eine verbindliche Entscheidung — mit den Bedingungen, unter denen sie gilt.
Letzte Prüfung der Vorlage und Versand an die Mitglieder, mindestens 24 Stunden vorher.
Vorstellung und Entscheidung: Freigabe, Ablehnung, Weitergabe ans Mission Board oder Vertagung.
Wenn das Vorhaben dorthin gehört, wird die Vorlage für die strategische Sicht aufbereitet.
Strategische Diskussion und abschließende Entscheidung.
Bei einer Freigabe werden verbindliche Auflagen festgelegt und eine fachlich verantwortliche Person benannt.
Der Beschluss wird dokumentiert, über das Stakeholder-Management an Sie zurückgemeldet und entweder an das Projekt-Portfolio weitergegeben oder abgelegt.
Am Ende dieses Abschnitts läuft ein Projekt — und der Weg des Bedarfs ist abgeschlossen.
Bedarfssteckbrief, Beschluss und Auflagen werden in einen Projektauftrag überführt.
Möglichst aus dem Umfeld derjenigen, die den Service später verantworten.
Die im Beschluss zugesagten Kapazitäten werden gesichert.
Der Bedarf gilt als in ein Projekt überführt. Die Verbindung zwischen beidem bleibt nachvollziehbar. Damit beginnt der Weg des Service.
Von der Gestaltung bis zur Abschaltung. Fünf Abschnitte mit drei Freigaben dazwischen. Dieser Ablauf betrifft vor allem DIGIT selbst; für die Ämter ist vor allem wichtig, dass jeder Service regelmäßig überprüft wird.
Festlegen, was der Service können muss, und ihn entwerfen.
DesignBauen oder einrichten, testen, ausrollen, in Betrieb nehmen.
TransitionLaufender Betrieb, Überwachung, Qualitätsberichte.
OperationStörungen und Anfragen bearbeiten, Probleme an der Wurzel lösen.
SupportRegelmäßig bewerten: verbessern, neu aufsetzen oder abschalten.
Review| Freigabe | Wann | Wer entscheidet | Mögliche Ergebnisse |
|---|---|---|---|
| 1 · Selbst bauen oder einrichten? | Zu Beginn der Einführung | Service-Operations-Runde | Eigenentwicklung mit vollem Bauzyklus oder Einrichtung einer vorhandenen Lösung |
| 2 · Ist das Gebaute abnahmefähig? | Nach dem Bauen, vor dem Ausrollen | Service-Verantwortung allein | Freigabe · Freigabe mit Nacharbeiten · zurück ans Bauen · Ablehnung mit Eskalation in die Runde |
| 3 · Darf der Service in Betrieb gehen? | Am Ende der Einführung | Service-Operations-Runde | Start · Start mit Auflagen · zurück ans Ausrollen · Abbruch des Vorhabens |
Festlegen, welche Eigenschaften der Service haben muss. Die nötigen Bausteine entwerfen. Beschreiben, wie eingeführt wird, und die Einführung vorbereiten.
Entwickeln oder beschaffen, Komponenten einrichten, Betriebsdokumentation erstellen, testen, formal übergeben, ausrollen und den Start vorbereiten. Hier liegen alle drei Freigaben.
Enge Begleitung in der Anfangszeit, laufende Betriebsaufgaben, Steuerung von Mitteln und Dienstleistern, Überwachung, Qualitätsberichte und das frühe Erkennen von Problemen.
Wissensdatenbank pflegen, Meldungen verteilen, Anfragen bearbeiten, Störungen in zwei Ebenen lösen und abschließen, wiederkehrende Probleme analysieren und Behelfslösungen bereitstellen.
Ursachen auswerten, Leistung und Verbesserungsmöglichkeiten besprechen, in der Runde regelmäßig bewerten und entscheiden: verbessern, neu aufsetzen oder abschalten.
Soll ein Service grundlegend verändert oder abgeschaltet werden, wird daraus wieder ein Bedarf. Der Weg beginnt von vorn — mit Meldung, Bewertung und Entscheidung.
Einzelne Unterlagen zu diesem Ablauf sind noch nicht durchgängig aufeinander abgestimmt. Betroffen sind vor allem die Benennung der Abschnitte, die genaue Verortung der drei Freigaben und der Übergang vom Bedarf in den Weg des Service. Die hier gezeigte Darstellung folgt dem aktuellen Stand.
Eine Rolle ist ein klar umrissener Verantwortungsbereich, der einer Person zugewiesen wird. Rollen sind nicht dasselbe wie Stellen: Eine Person kann mehrere Rollen haben. Diese Übersicht zeigt die Rollen, denen Sie im Modell begegnen.
| Rolle | Wofür sie da ist |
|---|---|
| Stakeholder-Manager:in | Ihre feste Ansprechperson bei DIGIT. Pflegt den Kontakt zu Ihrem Haus, nimmt Bedarfe auf und vertritt Ihre Sicht in den Runden. |
| Service-Verantwortung | Steuert einen oder mehrere Services über deren gesamte Lebensdauer. Oft die fachliche Fürsprache für Bedarfe, die den eigenen Service betreffen. |
| Erste Support-Ebene | Nimmt Meldungen an und löst, was direkt lösbar ist. |
| Zweite Support-Ebene | Übernimmt Fälle, die mehr Fachwissen erfordern. |
| Projektleitung | Führt ein freigegebenes Vorhaben durch die Umsetzung. |
| Rolle | Bereich | Wofür sie da ist |
|---|---|---|
| Leitung Stakeholder-Management | Stakeholder-Management | Führt den Bereich, steuert die Betreuung der Ämter und vertritt deren Sicht auf Leitungsebene. |
| Demand-Portfolio-Manager:in | Demand-Portfolio | Führt die Gesamtübersicht der Bedarfe, bereitet Entscheidungen vor und leitet die Demand- und Stakeholder-Runde. |
| Service-Portfolio-Manager:in | Service-Portfolio | Verantwortet Katalog, Qualitätszusagen und Änderungsverfahren. Leitet die Service-Operations-Runde. |
| Abteilungsleitung Basis & Cloud | Betrieb | Verantwortet den Betrieb der Infrastruktur. Ständiges Mitglied der Service-Operations-Runde. |
| Abteilungsleitung Applikationen | Betrieb | Verantwortet den Betrieb der Anwendungen. Ständiges Mitglied der Service-Operations-Runde. |
| Leitung Support | Service-Support | Verantwortet den Support insgesamt. Ständiges Mitglied der Service-Operations-Runde. |
| Problemverantwortung | Service-Support | Geht wiederkehrenden Störungen auf den Grund. |
| Verteilung im Support | Service-Support | Behält offene Fälle im Blick und leitet sie weiter. |
| Betriebsteam, Support-Team, Projektteam | verschiedene | Die Teams, die die eigentliche Arbeit leisten. |
| Testmanagement, IT-Architektur | unterstützend | Werden bei Bedarf hinzugezogen. |
| Lieferanten und Hersteller | extern | Externe Beteiligte an Entwicklung und Betrieb. |
Diese Rollen gehören zum ausgesetzten Teil des Modells. Sie beschreiben keinen heutigen Betrieb.
| Rolle |
|---|
| Leitung Prozess-Management |
| Verantwortung für den Methodenrahmen |
| Koordination der Prozesslandschaft |
| Prozessberatung |
| Prozessverantwortung |
| Auftraggebende Stelle |
| Key User und Netzwerkkoordination |
| IT-Architektur |
| Informationssicherheit und Datenschutz |
Für mehrere Bereiche gibt es zusätzlich Übersichten, die jedem Arbeitsschritt genau zuordnen, wer ihn ausführt, wer die Verantwortung trägt, wer gefragt und wer informiert wird. Sie sind Teil des Modells und liegen für die Fachbereiche vor.
Im DIGITOM tauchen einige Fachbegriffe auf, oft auf Englisch. Hier stehen sie in Alltagssprache.
Etwas, das ein Amt braucht und das durch das bestehende Angebot von DIGIT noch nicht abgedeckt ist — oder das eine erhebliche Änderung daran erfordert. Ein Bedarf durchläuft einen eigenen Bewertungs- und Entscheidungsweg.
Der Abruf einer Leistung, die es bereits gibt — etwa ein Zugang oder eine Ausstattung. Wird direkt bearbeitet und braucht keine Entscheidung in einer Runde.
Eine Leistung, die DIGIT bereitstellt, damit ein Amt seine Aufgaben erledigen kann — ohne dass das Amt sich um Technik, Kosten und Risiken dahinter kümmern muss.
Die Zusammenstellung technischer und organisatorischer Mittel, mit der ein Service erbracht wird.
Das Dokument, in dem Ihr Bedarf festgehalten wird: was gebraucht wird, warum, welchen Nutzen es bringt und welche Rahmenbedingungen gelten. Erstellt wird es von Ihrer Ansprechperson.
Eine Stelle zwischen zwei Abschnitten, an der geprüft wird, ob alles Nötige vorliegt, bevor es weitergeht.
Das Amt für Digitales und IT der Stadt Freiburg.
Die Arbeitsordnung dieses Amts: wer wofür zuständig ist, wie Bedarfe und Services durch die Organisation laufen und wer entscheidet.
Der Bereich, der die Ämter betreut, Bedarfe aufnimmt und deren Sicht innerhalb von DIGIT vertritt.
Der Bereich, in dem alle Bedarfe zusammenlaufen, bewertet und in eine Reihenfolge gebracht werden.
Der Bereich, der das gesamte Serviceangebot steuert: Beschreibung, Qualität, Änderungen und der Weg eines Service.
Der Bereich, der freigegebene Bedarfe in Projekte überführt und die laufenden Projekte steuert. Im Modell noch nicht ausgearbeitet.
Die Arbeitsfelder rund um Störungen, Anfragen und wiederkehrende Probleme. Teil des Service-Portfolios.
Der Bereich, der den methodischen Rahmen für die Abläufe des Amts setzt. Derzeit ausgesetzt.
Die Runde, die über große Vorhaben entscheidet und Personal und Mittel verteilt. Mit Amtsleitung und Abteilungsleitungen besetzt.
Die Runde, die über die alltäglichen Bedarfe entscheidet. Besetzt mit den vier Portfolio-Bereichen.
Die Runde, die über Services entscheidet: Start, größere Änderungen, Verbesserung oder Abschaltung.
Die oberste Ebene, die die langfristige Richtung setzt. Im Modell noch nicht ausgearbeitet.
Woher der Impuls kommt. Eine gesetzliche Vorgabe lässt weniger Spielraum als ein interner Verbesserungswunsch.
Wie tiefgreifend die Veränderung ist — von einer kleinen Verbesserung bis zur vollständigen Neugestaltung.
Wie unsicher die Lösung ist. Gemeint ist nicht nur die technische Schwierigkeit, sondern auch der Abstimmungsaufwand.
Wo das Vorhaben technisch wirkt: Infrastruktur, Plattform, Fachverfahren, Querschnittskomponente oder Daten und Schnittstellen.
Ein Entscheidungsverfahren: Ein Vorschlag gilt als angenommen, solange niemand einen schwerwiegenden begründeten Einwand hat. Wer einen Einwand erhebt, muss selbst eine Alternative erarbeiten.
Ein international verbreiteter Standard dafür, wie IT-Organisationen ihre Leistungen erbringen. DIGIT hat ihn auf die eigene Situation zugeschnitten.