IT-Kostenwahrheit durch Umlagerechnung oder nach dem Verursacherprinzip?

Teil 3 der Finance & IT-Serie „Was Billigeres können wir uns nicht leisten“.

Ich vermute mal, es gibt keine IT-Organisation, deren Kostenstruktur nicht laufend organisationsintern hinterfragt wird: Warum ist denn die IT so teuer? Der PC aus dem Media Markt ist ja viel billiger!

Die Herausforderung bei vielen IT-Lösungen liegt darin, dass die 1:1 Zuordenbarkeit von Kosten zu bestimmten Usern bzw. Usergruppen schwierig ist. Daher nutzen viele Unternehmen verschiedene Umlageverfahren (siehe Teil 1 dieser Serie), um die IT-Kosten organisationsintern zu verteilen. Dass das mitunter zu Widerständen führt, liegt auf der Hand.

In solchen Debatten gelangt man häufig zum Thema des „Verursacherprinzips“, soll heißen wer IT-Services überproportional nutzt, soll entsprechend die Kosten tragen. Das klingt vielleicht einfach, kann aber leicht nach hinten losgehen.

Ein Beispiel: Eine Organisation entschließt sich, die Kostenverteilung auf Basis der Anzahl und Dringlichkeit der eingemeldeten Tickets der unterschiedlichen Unternehmensbereiche aufzusetzen.

Was wird man in diesem Fall mit hoher Wahrscheinlichkeit beobachten?

  • User werden ihre „Strategie“ anpassen und vermutlich zweimal nachdenken, bevor sie ein Ticket aufgeben. Das könnte zu einer Kommunikationsbarriere zwischen IT und Organisation führen und in weiterer Folge zu Qualitätsverlusten im IT-Betrieb und in Projekten.
  • Fälle werden sich häufen, wo User mehrere Themen in ein Ticket hineinpacken „um Kosten zu sparen“ – mit entsprechendem Aufwand für das IT-Team die einzelnen Issues herauszuschälen und zu kanalisieren.
  • Gerade motivierte Key-User, die es gewohnt sind, augenscheinliche Fehler von IT-Lösungen eigeninitiativ zu melden, werden sich passiver verhalten.

Vielleicht wäre der umgekehrte Weg sinnvoller: User bzw. Organisationseinheiten, die sich überproportional bei der Unterstützung der IT und bei Projekten einbringen oder deren „Einmeldequalität“ bei Tickets eine hohe ist, werden kostenseitig entlastet.

Welchen Weg haben Sie gewählt? Freue mich auf Feedback in den Kommentaren.

Software-Wartung – OPEX oder CAPEX?

Teil 2 der Finance & IT-Serie „Was Billigeres können wir uns nicht leisten“.

Viele IT-Verantwortliche kennen das Ritual, wenn im Zuge von IT-Anschaffungen Controlling und/oder Buchhaltung in der IT-Abteilung anklopfen: Dann geht es stets um eher „trockene“ Themen wie Herstellkosten, Nutzungsdauer oder #Abschreibung. Und irgendwann mittendrin tauscht man sich dann aus, wie mit Software-Wartungskosten umzugehen wäre.

Trotz der allseits forcierten Miet- und Abomodelle gibt es immer noch zahlreiche IT-Lösungen, die auf Kauflizenzen basieren. In solchen Fällen zahlt man in der Regel einmalig den Lizenzpreis und periodisch sogenannte Software-Wartungskosten (maintenance) als Prozentsatz des ursprünglichen Lizenzpreises. In den meisten Fällen umfasst die SW-Wartung das Recht, Lizenzen für die nächsthöhere Version ohne Zusatzkosten zu erwerben.

Die Frage, ob man sich für eine SW-Wartung entscheiden sollte, hängt sicherlich zum einen von der geplanten Nutzungsdauer und nicht zuletzt von den Lizenzbedingungen des Herstellers ab. Die allermeisten Kauflizenzen im Business-Bereich gibt es ausschließlich in Kombination mit dem Abschluss eines Software-Wartungsvertrages.

Aber wann ist nun SW-Wartung als OPEX und wann als CAPEX anzusetzen?

*SW-Wartungsaufwände, die sich auf ein Wirtschaftsjahr beziehen gelten in der Regel als operative Betriebsaufwendungen und werden zur Gänze in die Kosten des Wirtschaftsjahres eingerechnet.

*SW-Wartungsaufwände, die zeitgleich mit der Lizenz eingekauft werden und im Voraus – z.B. für 3 Jahre – zu bezahlen sind, könnten durchaus gemeinsam mit der Lizenz (soweit ohnehin kein geringwertiges Wirtschaftsgut) als CAPEX in den Herstellkosten aktiviert und als AfA über die erwartbare Nutzungsdauer abgeschrieben werden. Spannend ist gerade im Software-Bereich immer, (a) welche voraussichtliche Nutzungsdauer für eine Lösung/Version angenommen wird und (b) wie sich diese zur vorab bezahlten Wartungsdauer verhält.

Kommen hardwaregebundene OEM-Lizenzen mit ins Spiel, gilt es bei der Nutzungsdauer auch die anzunehmende Betriebsdauer der HW-Komponenten in die Überlegungen einzubeziehen.

Wie geht es Ihnen bei solchen Fragestellungen?

Das „Gerangel“ um die IT-Kostenverteilung

Teil 1 der Finance & IT-Serie „Was Billigeres können wir uns nicht leisten.“

Wer in IT-Leitungsfunktionen kennt dieses Spiel nicht? Die Budgetplanung im Herbst steht an und idealerweise haben Sie alle erwartbaren absoluten Kosten mal im Plan erfasst. Doch in vielen Unternehmen werden im Folgeschritt die IT-Kosten „umgelegt“, d.h. als Teil der Allgemeinkosten auf die Unternehmensteile verteilt. Dann beginnt nicht selten ein Gerangel darum, welche Units welche Kostenblöcke übernehmen müssen. Zentraler Angelpunkt solcher Diskussionen sind die einzusetzenden #Umlageschlüssel.

Eine beliebte Methode ist die Aufteilung auf „Seats“. Herangezogen werden in der Regel dabei die IT-unterstützten Arbeitsplätze – ein im Dienstleistungsbereich durchaus passables Vorgehen. In solche Kalkulationen können natürlich auch Remote-Arbeitsplätze (sofern vom Arbeitgeber gestellt) einbezogen werden.

Im unmittelbaren Produktionsumfeld hingegen, wo Arbeitskräfte ohne IT-Integration in der Überzahl sind, wird eine Verteilung auf „Seats“ vermutlich weniger aussagekräftig sein. In solchen Umgebungen können integrierte Anlagensteuerungsnetze oder Sensorikteile, die nicht konkret einem IT-Arbeitsplatz zuzurechnen sind, überproportional hohe Kosten verursachen. Außerdem beginnen Firmen ihre Arbeitskräfte am Feld Zug um Zug mit mobilen Endgeräten auszustatten. Diese bieten zwar nur einen Bruchteil der Leistungsfähigkeit eines konventionellen IT-Arbeitsplatzes, erfordern aber trotzdem im Fall eines Mobile Device Managements vollständige Windows-Benutzerprofile.

Eine Lösungsoption besteht darin, User- oder Nutzerklassen zu modellieren. Dann werden die entsprechenden Mengengerüste ermittelt und am Ende diese Mengengerüste mit Komplexitätsfaktoren gewichtet, ein vollständiger PC-Arbeitsplatz zählt z.B. mit Faktor 1, ein reiner Mobile Device Anwender mit Faktor 0,25, komplexe Anlagen erhalten ebenso Faktoren zugewiesen. Daraus ergeben sich für abgrenzbare Unternehmensteile Verteilschlüssel für IT-Kosten.

Aber Vorsicht, komplexere Modelle verursachen in der internen Kommunikation einen entsprechenden Mehraufwand beim Erklären. Und so wie anderswo auch, wird es immer jemanden geben, der über seinen zugewiesenen Kostenanteil jammert.

Was sind Ihre Erfahrungen damit? Wie sind Sie mit solchen „Verteilkämpfen“ um IT-Kosten umgegangen? Freue mich über Statements in den Kommentaren!

Digitales Onboarding im HR

Vor allem in größeren Unternehmen sind mittlerweile immer häufiger Recruiting-Plattformen im Einsatz. Hier liegt der Fokus bei der digitalen Erfassung von Daten und Dokumenten von Bewerber:innen als Grundlage für den HR-Auswahlprozess.

Aber so richtig spannend wird es, wenn idealerweise ein neues Arbeitsverhältnis zustande kommt. Oft gilt es dann die persönlichen Daten der neuen Mitarbeiter:innen in den verschiedenen Backend-Systemen nochmals zu erfassen. Spätestens jetzt wird klar, an welchen Stellen im Unternehmen redundante Personalstammdaten gehalten werden, z.B. im Active Directory, im ERP-System, im HR-Tool, im Zutrittssystem (bei Schlüsselkarten), im MDM & SIM-Kartenmanagement usw.

Gerade beim Umgang mit Personaldaten in verteilten Systemen sind Fragestellungen rund um Primärschlüssel, Leadsystem und Datenänderungsworkflows in der Praxis oft gar nicht so einfach zu beantworten.

Im Vorfeld einer digitalen Integration braucht ein erfolgreicher Onboarding-Prozess klar strukturierte Abläufe zwischen allen beteiligten Fachabteilungen, die idealerweise auch DSGVO-konform umgesetzt werden.

Doch da wäre ja auch noch das Offboarding, aber das ist wiederum eine andere Geschichte 🙂

Einen aktuellen Beitrag zu diesem Thema finden Sie auf computerwelt.de.

Agilität macht offenbar nicht alle happy…

Im Standard-Interview verortet der deutsche Psychologe Rainer Bäcker durchwegs Ernüchterung in der Business-Community in Bezug auf #Agilität in #Organisationen und #Projekten. Die „Stichprobe“ von lediglich 21 Tiefeninterviews scheint mir persönlich statistisch nicht gerade aussagekräftig, ein paar „Trends“ kann ich aber aus persönlicher Beobachtung durchaus bestätigen.

* Wenn das Top-Management einem Unternehmen #Agilität verordnet, aber sich selbst dabei ausnimmt, hat es agile Grundsätze nicht begriffen.

* Wer sein Unternehmen in Richtung einer agilen Organisation transformieren möchte mit dem primären Ziel der Kosteneinsparung wird am Ende des Tages enttäuscht sein.

* Agilität ist ungleich #Scrum; da gibt’s durchaus auch andere methodische Agilitätsansätze mit Vor- und Nachteilen

* Agiles Vorgehen fordert Management und Führungskräfte weitaus mehr, der Kommunikationsaufwand steigt.

Mein Fazit:
Ich kann nur jedem empfehlen, sich inhaltlich mit agilen Ansätzen zu beschäftigen und diese vor dem persönlichen (Projekt-)Erfahrungshintergrund zu reflektieren. Die Stärken – aber auch die Grenzen – der Methodik zu kennen hilft durchaus sich im Chor der Kritiker:innen eine eigene Meinung zu bilden.

Projektkomplexität mal anders

In den Medien bin ich auf ein nicht alltägliches #Projekt der Kategorie „komplex“ gestoßen: Seit Jahren arbeiten Luftfahrtenthusiasten an der Restaurierung eines Focke-Wulf 200 „Condor“ Passagierflugzeugs.

Von den ursprünglich rund 270 gebauten Maschinen ist kein einziges vollständiges Exemplar erhalten geblieben. Daher musste man für das Projekt auf geborgene Wrackteile abgestürzter ziviler und militärischer Versionen zurückgreifen. Die Komponenten wurden aufwendig gereinigt und restauriert oder originalgetreu nachgebaut.
Mit Unterstützung von #Airbus#Lufthansa und #RollsRoyce setzt man die einzelnen Bauteile nun Stück für Stück in Bremen wieder zusammen. Hinter dem Projekt steht eine Gruppe pensionierter Flugmechaniker und -techniker, die sich in der Rente ehrenamtlich einbringen.
Nach „#Projektabschluss“ soll die Maschine auf dem früheren Flugplatz Berlin-Tempelhof der Öffentlichkeit präsentiert werden. Leider „nur“ als nicht flugtaugliches, aber beeindruckendes Stück Luftfahrtgeschichte.

Hier geht es zur Webseite des Projekts.

Ein kritischer Blick auf die „Critical Path Method“

Wer kennt sie nicht aus diversen Projektmanagement-Ausbildungen – die Berechnung des „kritischen Pfads“? Diese aus der Netzplantechnik stammende Methode setzt Aufgaben/Vorgänge in logische Abhängigkeit zueinander. Daraus lassen sich – vorrangig auf dem Papier – Mindest-Durchlaufzeiten darstellen.

Dementsprechend setzt CPM voraus, dass der Projektplaner die Durchlaufzeiten der einzelnen Vorgänge möglichst treffgenau darstellen kann. Und das ist in vielen Fällen auch der Haken an der Sache. Wer kennt in der Praxis – gerade im SW-Entwicklungsprozess – genau diese Durchlaufzeiten? Werden diese nur Daumen mal Pi geschätzt, wie belastbar ist dann überhaupt das Ergebnis der CPM?

In der Agilität hat man erkannt, dass man zeitlichen Unsicherheiten in Projekten dadurch begegnen kann, indem die Anforderungen in überschaubare Sprints zerlegt werden. Heißt das im Umkehrschluss, dass die CPM in die Mottenkiste gehört? Nein, keineswegs. Wo Aufgaben aus der Erfahrung heraus gut einzuschätzen sind, macht die Berechnung des kritischen Pfades durchaus Sinn. Bei Hausbauprojekten mit verschiedenen Gewerken kann so der CPM-Profi vorab seinen persönlichen Meilenstein „Einzugstermin“ berechnen 😉

Über Compliance in Projekten

Es hat schon einen schalen Beigeschmack, dass es in Österreich ein Volksbegehren braucht, um (politische) Entscheidungsträger:innen aufzufordern, nach rechtsstaatlichen Normen zu handeln.

Doch wenn wir unsere Sicht auf Projekte fokussieren. Wie ist es dort um die Compliance bestellt?

Ich erlebe in Gesprächen mit Kunden, dass Compliance im Projektkontext in erster Linie als Sicherstellung der Einhaltung der vereinbarten Methodik verstanden wird. Darunter fallen in der agilen Welt etwa verbindliche Scrum-Ereignisse, wie z. B. Sprint Planning oder Daily Scrum. Im Wasserfall-Modell lassen sich ebenso (standardisierbare) Elemente einbauen, die – abhängig von der Unternehmenskultur – Qualitäts- und Berichtspflichten vorsehen. Dass Compliance-Maßnahmen Aufwand verursachen, liegt auf der Hand. Allerdings kann man durchaus Compliance in Projekten auch als Lackmustest für die jeweilige Organisation betrachten, wie ernst man unternehmensinterne „Spielregeln“ nimmt. Zugegeben, manchmal ist es ein schmaler Grat zwischen empfundener Bürokratie und geforderter Transparenz.

Doch Compliance geht noch weiter und wirkt in Projekten dann ein, wenn kaufmännische Entscheidungen zu treffen sind. Hier geht es um die Sicherstellung, dass ein unternehmerisches Wagnis den in der Regel selbst auferlegten Prozessen und Freigaben entspricht (Stichwort 4-Augen-Prinzip). Ich habe solche Phasen immer als sehr spannend erlebt und dann die besten Ergebnisse erzielt, wenn im Verbund mit dem Buying Center nach transparenten Kriterien entschieden wird. Da können durchaus Funken fliegen, aber am Ende des Tages zählt ein gemeinsames Ergebnis.

Das Lastenheft – ein Tool zum effizienten Projektstart

Gerade im Bereich #Unternehmenssoftware ist entscheidend, dass sich der #Projektauftraggeber ein realistisches Bild verschafft, was eine Lösung tatsächlich können muss. Bereits im Vorfeld eines #Projekts ein #Lastenheft zu erstellen, bringt einer Organisation enorm viel:

* Ist der Prozess gut aufgesetzt, sorgt ein Lastenheft für einen konstruktiven internen Dialog über den erforderlichen Leistungsumfang und idealerweise eine Priorisierung der Anforderungen.

* Entscheidend ist, jene Informationen zu verschriftlichen, die Lieferanten benötigen, um ein treffsicheres Angebot zu erstellen. Werden die Anforderungen in Katalogform gesammelt, kann man daraus auch einen Vergleichsraster erzeugen, um Angebote inhaltlich zu vergleichen.

* Wie ein Lastenheft gegliedert werden soll, kann individuell entschieden werden. Im Web gibt es dazu eine Reihe sinnvoller Vorschläge zur Strukturierung (siehe Link).

* Aber Vorsicht: Lastenhefte sollten – sofern es keine bindenden Regulatorien gibt – im Detail keine Umsetzungswege vorgeben. Vergleichen Sie lieber unterschiedliche Lösungsansätze, die Ihnen Ihre Lieferanten vorschlagen und nutzen Sie die Gelegenheit Prozesse neu zu denken!

https://www.business-wissen.de/hb/was-beinhaltet-ein-lastenheft/

The ’new‘ post-Corona work: Back to reality?

#Corona-pandemic is said to have changed our perception of #work in terms of physical location. I don’t think this massive disruption in daily routine is about to vanish and we are going back to pre-Corona procedures. Some thoughts about this topic:

* Certainly, work from home (or #homeoffice) made us more sensitive about communication. Human nature needs some degree of personal interaction that cannot be replaced completely by online tools. Now it’s time to find literally a ‚working balance‘ again.

* Management had to accept less physical control of their employees in terms of checking presence. I assume organisations that strive for regaining the ‚old‘ degree of control once the pandemic flattens will fail. Instead they should more focus on leading by targets and/or agree on quality expectations based upon a climate of trust.

* From legal point of view, major responsibilities of businesses in terms of providing a productive and healthy work environment have to be addressed. Work-from-home is not just about providing a laptop. And there are still many employees who are lacking an own home office space at all…

However, I do hope that we will benefit from a discussion process based upon a broad reflexion about the ’new‘ way of working reality.