Wir sind

die Spezialisten für die Bereitstellung und den Betrieb der IT-Plattformen.

Mit unseren externen Partnern für die Hardware und Virtualisierung sowie Netzwerkbetrieb verantworten wir den ganzen technologischen Unterbau der technischen Bereitstellung der Systeme auf denen dann die verschiedenen Anwendungen laufen.

Unsere Mission ist es eine IT-Plattform bereitzustellen, in welcher unsere Kunden möglichst eigenständig über Self-Services die Systeme mit hohem Automatisierungsgrad selbst abrufen, nutzen und im Rahmen der gewünschten Möglichkeiten auf ihre Bedarfe hin anpassen können.

Wir arbeiten

als Teams

in den fachlichen Themengebieten

• Datenbanken
• Digital Workplace Management
• Linux Plattform
• Microsoft Plattform
• Network

Dabei unterstützen sich Kollegen fachlich übergreifend – auch in enger Zusammenarbeit in der ganzen IT, um keine Kopfmonopole aufzubauen und so schneller unterstützen zu können, wenn mal was dringendes und wichtiges rein kommt.
Verzichtet daher bitte darauf, Tickets direkt Kollegen zuzuweisen.

mit Tickets

Damit wir in jedem Themengebiet bestmöglich unterstützen können, routen wir eure Anfragen und gemeldeten Probleme als Tickets ins fachlich am Besten passende Team.

Siehe unser agile board.

Warum?

Nur wenn wir anhand von Tickets arbeiten, können wir gewährleisten, dass auch wenn ein Kollege mal nicht greifbar ist, das Thema dennoch im Team weiter betreut werden kann.
Auch können wir nur dann bestmöglich im Sinne der Company priorisieren, wenn wir den Überblick über alle für uns relevanten Themen haben.
Dafür könnt Ihr mithelfen, indem ihr alle zu einem Vorgang relevanten Informationen über das Ticket einsteuert und dort ergänzt. Auch wir machen das, um euch jederzeit transparent über den aktuellen Stand zu informieren.
So ist gewährleistet, dass wir fokussierter arbeiten können, weil wir nicht ständig aus der Arbeit gerissen werden, um „den aktuellen Stand“ mitzuteilen.

Per Email, Telefon oder Teams wäre die Info nur für den gerade darin involvierten Teilnehmerkreis verfügbar und ggf. zur Unterstützung hinzugezogene Kollegen müssen wieder alles von vorn abfragen und ermitteln.

Bitte habt daher Verständnis, dass wir die Tickets brauchen um euch schnell und zielgerichtet helfen zu können. 
Anfragen zu Vorgängen über Nebenkanäle und größere Anforderungen ohne Ticket können wir mangels sinnvoller Steuerungsmöglichkeit daher nicht bearbeiten.

Tickets – aber wie?

Im Bereich des 2nd und 3rd level Supports erhalten wir eure Anliegen über unser Standard Ticketing Tool.
Da wir sehr viel mit Kolleginnen und Kollegen zusammen arbeiten, die Ihre Arbeit ebenfalls in Jira organisieren, haben wir eine zentrale Steuerungsmöglichkeit für uns und können dennoch projektübergreifend zusammen arbeiten.

Aus diesem Grund können haben wir auch unsere Boards so aufgebaut, dass wir Projektübergreifend mit euch zusammenarbeiten können.

Polling statt Dispatch

Tickets die passend auf die Fachlichkeit zugeordnet sind, holen sich die passenden Kollegen sobald sie dafür Ressourcen verfügbar haben.

User Stories

helfen uns, besser zu verstehen, wer (welche Rolle) was benötigt, um einen bestimmten Mehrwert zu erzielen (Business Value). Das ist auch die Basis für unsere Priorisierung. Je klarer die Story aufgebaut ist, desto weniger Rückfragen haben wir und desto schneller können wir zumeist helfen.
Nachdem manchmal der Business Value auch über andere Wege vielleicht sogar geschickter erreicht werden kann, sprechen wir gern mit dir drüber, wie wir dir bei der Erreichung des Mehrwerts helfen können. 

Wir Priorisieren

Es gibt immer viel zu tun.

Die Priorisierung unserer run-the-company (RTC) Themen nehmen wir anhand des Business Value vor, sofern wir keine genaue Vorgabe von PMO oder Anforderungsmanagement erhalten.
Nachdem wir Dienstleistungen für das ganze Unternehmen erbringen, haben wir dabei auch immer das ganze Unternehmen im Blick.
Auch wenn „dein Vorgang“ sicherlich für dich ganz besonders wichtig ist, kann es sein, dass im Gesamtkontext des Unternehmens anderen Themen eine höhere Priorität eingeräumt werden muss, weil z. B. ein ganzes Team, eine Abteilung oder ein Standort nicht arbeiten kann, oder ein Sicherheits- oder Finanzielles Risiko reduziert werden muss.

Auch wir sind Menschen und es mag mal sein, dass wir mit unserer Einschätzung daneben liegen. Sprich uns dann gern darauf an. 

Damit wir die richtige Reihenfolge finden gilt 

RUN

Unser Kerngeschäft muss verlässlich laufen

SECURE

Unsere System und Daten müssen sicher sein

SUPPORT

Danach kümmern wir uns gern um alles weitere aus dem Alltagsgeschäft.

Projekte

Werden vom Projektmanagement-Office (PMO) priorisiert. An diese Priorisierung halten wir uns.
Die für Projekte abrufbaren Ressourcen werden von der Leitung des Plattformen-Teams an das PMO gemeldet und sind transparent im Projektmanagement-Tool hinterlegt. 
I. d. R. sind dies zwischen 10% und 40% der Arbeitszeit die neben run, secure und support für Projekte aufgewendet werden können.

Benötigt ein Projektleiter Ressourcen aus dem Plattform-Team, können diese über das Projektmanagement Tool im (PMO) angefordert werden.
Die Teammitglieder sehen ihre jeweils für Projekte eingeplanten Zeiten im Projekt Tool und planen dies entsprechend ein.

Sind die von uns als planbar gemeldeten Zeiten von höher priorisierten Projekten bereits abgerufen, können wir für die niedriger priorisierten Projekte KEINE Aufwände mehr investieren. Bei Fragen dazu verweisen wir ans PMO. Ressourcenkonflikte in Projekten lösen die betroffenen Projektleiter untereinander im Dialog oder wenn keine Einigung möglich ist, über das PMO.

Und machen fertig

Umpriorisierungen bereits in Arbeit befindlicher Tätigkeiten senken die Effizienz durch die Kontext-Wechsel immens.
Dies gilt nicht nur für mehrere Projekte sondern auch innerhalb von Projekten und Themen.

Daher schneiden wir User Stories hinreichend klein, dass eine Person sie innerhalb eines Arbeitszyklus (1-2 Wochen) auch allein abschließen kann. 
Werden für die Umsetzung mehrere Kollegen benötigt, ergibt eine Unterteilung in Sub-Tasks oft Sinn, da hierüber auch die Ressourcen und Commitments auf die Lieferergebnisse eindeutig sind.
Dann erfolgen die Commitments für einen Zyklus auf die Sub-Tasks und nicht zwingend auf die komplette User-Story.

Daraus ergibt sich, dass wir

1. bereits in Arbeit befindliche Themen nicht umpriorisieren
   Ausnahme lediglich, sofern es sich um kritische Incidents (RTC/STC) handelt, die dringend bearbeitet werden müssen um größeren Schaden abzuwenden.
   Wenn doch in einem solchen Fall umpriorisiert werden muss, erfolgt das IMMER im Dialog mit dem Bearbeiter und es wird transparent gemacht, was der Grund für die kritische Umpriorisierung ist.
2. Notwendige Umpriorisierungen zwischen Projekten gern unterstützen, sofern dies dazu beiträgt, dass ein blockiertes Projekt weiter machen kann.
   Die dafür notwendigen Aufwände sind durch die Projektleitenden im Vorfeld untereinander abzustimmen und auch in BCS einzuplanen. (z. B. jour-fixe IAM trotz „vollem Fokus“ auf SO) um die Transparenz in der Projektsteuerung zu schaffen. Wenn wir solche Blockaden erkennen, gehen wir auf die PLs zu und sprechen die in unseren Augen sinnvolle Möglichkeit zur Auflösung aktiv an.
3. Die jeweils gültige Priorisierung anhand des Rangs wird berücksichtigt, wenn ein Thema abgeschlossen ist, und das nächste Thema begonnen wird.
   Dies gilt auch wenn wg. vorher unbekannter Abhängigkeiten ein Thema unterbrochen werden muss und dadurch Kapazität für „das nächste“ frei wird.
4. Abhängigkeiten / Blockaden zwischen Aufgaben machen wir durch die Verwendung des Verknüpfungs-Typs (link type) „is blocked by“ <=> „blocks“ transparent und kommunizieren diese eigenverantwortlich aktiv an die betroffene Projektleitung, so dass diese bei der Auflösung der Blockade unterstützen kann.

Was noch?

Besonders effizient sind wir, wenn wir uns auf unser Kerngeschäft konzentrieren können.

Daher ordnen wir die Aufgaben so zu, jeweils die Service-Owner mit Ihren Teams die Themen bearbeiten, die Sie am Besten können. Natürlich unterstützen wir uns, wenn Bedarf ist, und verschanzen uns nicht hinter „not my job“.