0

Die Rolle der IT im Unternehmen oder wer hat denn nun das Budget?

Wer ist für die IT-Kosten verantwortlich? Wem gehört das IT-Budget - der Fach- oder der IT-Abteilung. Oder braucht es gar kein Budget. Diese Frage ist sehr mit der Frage verbunden, was die Rolle der IT in Zukunft ist. Das ein Wandel notwendig ist, hört man überall. Was das konkret bedeutet, möchte ich heute anfangen mit Dir zu diskutieren. Und wieso ich das aus Sicht des IT-Budgets anschneide, erfährst Du auch.

In der letzten Folge habe ich die These, ja vielleicht sogar Forderung, aufgestellt dass das IT-Budget in die Fachabteilung gehört. Zu dieser Folge gab es in den sozialen Netzen sehr viel Reaktion. Der Beitrag wird geliked, geteilt und kommentiert. Insbesondere auf Twitter hat sich eine sehr interessante Diskussion entwickelt

Da 160 Zeichen einfach zu wenig sind, haben wir die Diskussion dann in den slack verlegt und dann ging es richtig ab.

Die Diskussion war deswegen für mich so interessant, weil mir klar geworden ist, dass sich in der letzten Folge viel zu viel vorausgesetzt habe. Oder ich habe viel zu wenig erklärt.

Nein und doch ja

Denn: Das Geld zu nehmen, welches heute die IT hat und den Fachbereichen zu geben, dass ist tatsächlich eine blöde Idee. Und es ist die beste Idee, die Fachabteilungen für das IT-Budget verantwortlich zu machen.

Du bist jetzt verwirrt? Das ist Absicht.

Wir dürfen darüber reden, was ich meine, wenn ich sage, dass das IT-Budget in die Fachabteilung gehört.

Die Kernaussage der letzten Folge lässt sich vielleicht so zusammenfassen: Haben der Lieferant von IT-Leistungen und der Konsument von IT-Leistungen im Unternehmen die Klarheit über die Kosten und die damit verbundene Unterstützung der Geschäftsprozesse, so gewinnen sie Klarheit und Steuerbarkeit über den sinnvollen IT-Einsatz und sie übernehmen die Verantwortung dafür.

Die Fachabteilung weiß welche  IT-Unterstützung sie braucht, wie viel Geld sie für die IT ausgibt und was sie damit erreicht. Die IT-Abteilung weiß was die Erbringung der Leistungen kostet, kennt die Nachfrage und kann Angebot eng an den Geschäftsprozessen kreieren.

Dadurch gewinnst Du das Wechselspiel zwischen Angebot und Nachfrage, welches sich darüber steuert, was sich die Fachabteilung leisten möchte und kann. Du gewinnst ein informiertes, auf Fakten basierendes Miteinander auf Augenhöhe.

Das beutete nicht – und das ist mir ganz wichtig: Das bedeutet nicht, dass Du jetzt den Fachabteilungen Dein IT-Budget gibst und die sich irgendwo irgendwelche Leistungen zusammenkaufen.

Das bedeutet schon gar nicht, dass die IT-Abteilung das IT-Budget nimmt und damit macht was sie für richtig erachtet.

Ja, die Frage spuckt Dir jetzt berechtigterweise durch den Kopf: Was bedeutet es dann?

Um das zu klären, müssen wir uns die Rolle der IT anschauen.

Die Rolle der IT

In meinem Zielbild hat die IT grob drei große Aufgabenblöcke:

1. Regelungsgeber: Unternehmensweite, verbindliche Vorgaben für Compliance, Sicherheit, Datenschutz, Architektur und den Weg, wie IT ins Unternehmen kommt. Und natürlich die IT-Strategie.
2. Innovationskatalysator: Die IT ist Business Analyst, Demand Manager, Berater, Moderator, Ideengeber, Sparringspartner und Prototypenzurverfügungsteller.
3. Service Broker: Sie kennt die Anforderungen des Business und setzt diese mit Hilfe externer und interner Provider in Business-Services um. Sie steht im engen Austausch mit den Fachabteilungen und steuert die Provider.

Die Reihenfolge ist keine Wertung in Bezug auf die Wichtigkeit. Sie ist eher im Sinne, des aufeinander Aufbauens zu verstehen. Und natürlich gibt es Rückkopplung zwischen den drei Kernaufgaben. Sie beeinflussen sich gegenseitig.

Lass uns jetzt mal den ersten der drei Punkte genauer anschauen:

Regelungsgeber

In der eingangs genannten Diskussion wurde darauf hingewiesen, dass es nicht sein kann, dass die Fachabteilung sich einfach am Markt mit IT-Leistungen eindeckt. Wir beide stellen uns das mal kurz vor:

Der Vertrieb findet Microsoft CRM aus der Cloud toll und schließt das Abo ab. Die Marketingabteilung ist vom Kampagnenmanagement in Salesforce so begeistert, dass sie den Dienst bucht.

Natürlich denken beide auch an die andere Abteilung und bestellen die entsprechenden Nutzeraccounts gleich mit. Und nun? Wie kommt Marketing an die Kontaktdaten? Wie kommt der Vertrieb an die Interkationen der Kunden aus den Kampagnen?

Und wie viele Passwörter müssen sich die Nutzer nun merken? Wie kommen die Apps auf die zentral verwalteten Mobiltelefone? Wie wird sichergestellt, dass die Daten des Unternehmens entsprechend den Datenschutzanforderungen gespeichert werden? Wer schließt jeweils eine Vereinbarung zwecks Auftragsdatenverarbeitung?

Blöde Vorstellung, oder wie siehst Du das?

Die Enabler

Das funktioniert nicht. Es braucht den Spielregeln. Es braucht, um jetzt mal mit COBIT zu sprechen, aus der Unternehmensstrategie abgeleitet eine IT-Strategie. Aus den Unternehmenszielen, braucht es abgeleitete IT-Ziele.

Darauf aufbauend braucht es die Prinzipien, Richtlinien und Rahmenwerke, für die einzelnen Enabler, wie sie in COBIT heißen. Konkret sind das:

• Prozesse
• Organisationsstruktur
• Kultur, Ethik, Verhalten
• Information
• Services, Infrastruktur, Anwendungen
• Mitarbeiter, Fähigkeiten, Kompetenz

Noch konkreter ausgedrückt, darfst Du unter anderem über folgende Punkte nachdenken und die Gedanken zu Papier bringen:

• Informationssicherheit – Stichworte ISO27001 oder vds3473 
• Service-Architektur
• IT-Prozesse
• Providermanagement
• Standards in Bezug auf Infrastruktur, Anwendungen und Interoperabilität
• …

Und Du darfst die Frage klären, wie funktioniert das Demand-Management und wer darf was beauftragen. Dazu die Grundsätze für das Financial-Management. Also, wie werden Leistungen im Unternehmen verrechnet.

Die beiden letzten Punkte sind wichtig. Sie sind meiner Erfahrung nach nur selten so ausgeprägt, dass sie Wirkung zeigen können.

So kommt IT ins Unternehmen

Ich erzähle Dir jetzt, wie ich das Demand Management beim mir auf Arbeit handhabe:

Ich bin regelmäßig in den Unternehmen meines Arbeitgebers unterwegs und spreche mit den Fachabteilungen. Über diesen Weg bekomme ich sehr viel mit und kann auch Ideen und Gedanken einbringen.

Formalisiert kannst Du Dir das wie folgt vorstellen:

Gibt es in den Fachabteilungen den Bedarf für eine andere oder neue IT-Unterstützung, so kommen die Kollegen auf die IT zu. Ich  führe dann in der Regel ein erstes Gespräch, damit ich verstehe, worum es geht und was erreicht werden soll.

Ich lasse mir meist da schon erklären, wie die Abläufe heute sind und wie sie zukünftig aussehen sollen. Hier spreche ich bewusst noch nicht von Prozessen. Auch lasse ich mir die Rahmenbedingungen erklären. Häufig tauschen wir Ideen aus, wie es umgesetzt werden könnte.

Das sind meist ausreichend Informationen, um einen Anforderungsworkshop zu gestalten. Das ist der nächste Schritt.

Ich stelle für den Workshop die Agenda auf, gebe Aufgaben für die Vorbereitung und schlage die Ansprechpartner aus der Fachabteilung vor, die unbedingt teilnehmen sollten. Die Fachabteilung entscheidet über die Teilnehmer.

Zusätzlich lade ich Teilnehmer ein, die in angrenzenden Prozessen tätig sind. Damit haben wir auch diejenigen am Tisch, die Inputs liefern oder auf den Output angewiesen sind.

Im Anforderungsworkshop sprechen wir über Prozesse, Input, Output, Rollen und natürlich die Anforderungen an die Lösung. Funktionale und nichtfunktionale Anforderungen. Je nach Umfang können weitere Workshops notwendig sein.

Insbesondere, wenn es um neue Lösungen für bestehende Prozesse geht, dreht es sich in den ersten Workshops vor allem um den Prozess selbst. Denn dann nutze ich die Gelegenheit, um diesen gleich zu dokumentieren.

Warum mache ich das?

Weil, sich nicht alle Probleme mit einer IT-Lösung erschlagen lassen. Häufig findet sich bei der Auseinandersetzung mit dem Prozess eine andere Lösung und es zeigen sich ganz andere Probleme auf. Oder das Problem ist wo ganz anders im Unternehmen zu verorten, als bisher gedacht.

Du erlebst es sicher auch öfter, dass es mit IT-Lösungen ähnlich wie bei Ärzten ist – es wird am Symptom herumgedoktert anstatt an der Ursache.

Dem möchte ich mit einer Analysephase und der Problemdefinition gern vorbeugen.

Aus dem einen oder den mehreren Workshops entsteht dann das Lastenheft. Oder Anforderungsdokument. Die IT schreibt das Dokument.

Das gibt mir die Möglichkeit, die Fachlichkeit zu reflektieren und besser zu verstehen. Es zwingt die Fachabteilung, mir die Dinge zu erläutern, bis ich sie verstehe. Das hilft der Fachabteilung ebenso.

Das heißt, es gibt ein produktives Hin und Her zwischen IT und Fachabteilung. Die IT bringt hierbei natürlich die ganzen Themen aus der Governance, Security, Architektur, Master Data Management usw. mit ein.

Das ist ein wichtiger Punkt: So stelle ich sicher, dass eine neue Lösung in die Zielarchitektur des Unternehmens passt und allen Spielregeln entspricht.

Am Ende steht ein gemeinsames Lastenheft.

Servicepreis – nicht Projekt

In der Zwischenzeit haben wir uns gemeinsam am Markt umgesehen, welche Lösungen in Frage kommen können. Wir haben vielleicht schon den einen oder anderen möglichen Lieferanten kennengelernt. Wir bedeutet hier Fachabteilung und IT.

Dann geht es in die Phase der Angebotseinholung, der Bietergespräche und letztendlich die Entscheidung.

Teil der Entscheidung ist immer auch die Kalkulation des Servicepreises. Das ist ja unser Ziel – Du und ich, wir wollen dem Business einen Service zur Verfügung stellen.

Das bedeutet, dass in der Bieterphase schon die Servicearchitektur als Grobplanung fertig sein darf. Auch dafür brauchst Du die Informationen über den Geschäftsprozess und das wie und warum. Damit kannst Du einen vernünftigen Business-Service anbieten.

Die Fachabteilung bekommt von mir dann den Servicepreis pro Verrechnungseinheit und Abrechnungsperiode.

In dem Servicepreis habe ich sowohl die Herstellungskosten, die AfA, die internen Projektaufwände, den Betrieb, das Service- und Providermanagement sowie noch einige andere Kostenblöcke eingerechnet.

Neben der Erfüllung der Anforderungen ist dann der Servicepreis für die Fachabteilung ein Entscheidungskriterium.

Nach der Entscheidung übernehmen wir dann die Implementierung. Dazu in einer anderen Folge mehr.

Das liebe Geld

Denn hier bekommen wir den Absprungpunkt für eine weitere, wichtige zentrale Aufgabe: Das Financial Management.

In der letzten Folge habe ich Dir gesagt, dass die IT die Kosten kennen darf – nein in diesem Fall kennen muss.

Aus meiner Erfahrung führt nichts daran vorbei, für die einzelnen Servicekomponenten zu wissen, was sie kosten. Nur so gewinnst Du Transparenz und kannst in die richtige Richtung steuern.

Nur so gewinnt Dein Unternehmen Transparenz über die IT-Kosten. Es ist die Voraussetzung, dass Du die IT-Kosten an die Fachabteilung verrechnen kannst.

Dadurch gewinnt dann wieder die Fachabteilung über ihre spezifischen IT-Kosten die Übersicht und kann diese steuern.

Damit bin ich wieder an dem Punkt aus dem letzten Podcast: Es braucht Kosten-Transparenz in der IT und der Fachabteilung. Beide gewinnen dadurch Steuerbarkeit und treffen informierte Entscheidungen.

Was uns nun wieder zu der Frage bringt: Wo gehört das IT-Budget hin? In die Fachabteilung, wie ich das letzte Mal gefordert habe. Oder in die IT-Abteilung, damit es Transparenz gibt?

Das echte Geld für IT gehört nicht in die Fachabteilung.

Budgets sind unnötig

Ich bin der Meinung, dass gar kein IT-Budget notwendig ist. Über den Satz habe ich lange nachgedacht. Es ist auch eher ein Gefühl. Mit dem Thema „Beyond Budgeting“ habe ich mich noch nicht so detailliert auseinander gesetzt.

Ich erkläre Dir meine Gedanken dahinter: Budget hat für mich immer etwas sehr starres: Es ist die Obergrenze, bis zu der eine Abteilung Geld ausgeben darf.

Wenn sie es nicht ausgibt, dann gibt es im nächsten Jahr weniger. Und in der jährlichen Budgetverhandlung muss auch immer ein bestimmter Prozentsatz nachgelassen werden. Und in der Mitte des Jahres vielleicht auch nochmal ein Prozentsatz, um allgemeine Kosteneinsparungen umzusetzen.

Du kennst das Spiel: Du weißt wie viel Dein Chef streichen wird. Dafür baust Du extra ein, zwei unwichtige Positionen ein, die er rausstreichen kann. Du weißt, wie viel % dann der CFO noch kassiert – die schlägst Du auch drauf.

Die Risiken, die den einzelnen Vorhaben innewohnen, sicherst Du auch mit Aufschlägen ab. Dann noch ein paar Positionen für nicht vorhersehbare Dinge und die Sicherheit, falls zwischendurch noch was gespart werden muss.

So entstehen Budgets in Unternehmen.

Gegen Ende des Jahres wird es dann eng: Das Geld muss ausgegeben werden. Sonst gibt es im nächsten Jahr weniger. Da kann es schon mal vorkommen, dass man Geld beim Lieferanten parkt oder Anschaffungen tätigt, die nice to have sind.

Aber was ist jetzt, wenn aus was für Gründen auch immer, alle Reserven nicht ausreichen? Das Budget muss eingehalten werden.

Der Sinn eines solchen Budgets ergibt sich mir nicht.

Financial Management

Ich handhabe das etwas anders: Ich kenne meine laufenden Kosten. Ich weiß, was ich für die nächste Periode plane und welche Auswirkung das auf die Kosten hat. Vorhaben, die IT-Unterstützung benötigen besprechen und entscheiden die IT und  das Business gemeinsam. Sie werden als Service kalkuliert. Der anfordernde Fachbereich entscheidet letztendlich, ob er dies finanzieren kann und möchte.

Die Verantwortung liegt letztendlich im Fachbereich und damit auch so etwas wie das IT-Budget.

Die Umsetzung des Projektes bzw. Erstellung des Service wird durch das Unternehmen vorfinanziert. Die Kosten landen auf der IT-Kostenstelle. Die Fachabteilung zahlt es monatlich zurück.

In diesem Wechselspiel brauche ich kein Budget. IT ist in unseren Unternehmen so wichtig, dass wir uns die Zeit nehmen dürfen, über einzelne Projekte gemeinsam zu reden und gemeinsam zu entscheiden.

Dazu kommt, dass, fundamentalistisch betrachtet, alle Kosten aus den Umsätzen des Unternehmens bezahlt werden. Wenn wir alle die Verantwortung für die Kosten und die Umsätze übernehmen, dann brauchen wir keine Budgets.

Zum Schluss noch ein Wort zur Infrastruktur. Sinngemäß gilt das Gesagte auch dafür. Allerdings rede ich darüber nur in Ausnahmefällen mit dem Business. Denn jeder Service hat, entsprechend seiner Architektur, anteilig die Kosten für die Infrastruktur. Darüber finanziert sich die Infrastruktur. Dazu kommt dann noch der Service Desk.

Zusätzlich habe ich heute etwas definiert, was Basis-IT heißt. Das beinhaltet alles, was gebraucht wird, damit der Mitarbeiter grundlegend arbeitsfähig ist. Auch dieser Service hat seinen Preis.

Hier diskutiere ich gern mit den Fachabteilungen, was die Basis enthält und was in eigene Services ausgegliedert wird. Mehr aber auch nicht.

 

An dieser Stelle machen wir Schluss für heute. Die Aufgabe als Regelungsgeber habe ich Dir ausführlich beschrieben.

Ich bin für die Diskussionen seit der letzten Podcastfolge sehr dankbar. Sie haben mir geholfen, in meinem Denken noch klarer zu werden. Sie haben mir auch ein paar Baustellen aufgezeigt. Danke dafür – besonders an Thomas.

 

Da wir heute an der Problemdefinition vorbei gekommen sind, wird es in der nächsten Folge ein Interview mit Georg Jocham geben. Mit ihm spreche ich über Probleme und Strategien, diese zu lösen.

Danach geht es dann mit der zweiten Rolle der IT weiter: der Innovationskatalysator