Karl Reder Consulting

Durch die fortschreitende Digitalisierung gewinnt die IT mehr und mehr an Stellenwert innerhalb von Organisationen. Damit steigen allerdings auch die Anforderungen an die IT in Bezug auf Planung, Steuerung und Ergebniskontrolle.

In Zusammenarbeit mit Konsultori habe ich für Sie ein exklusives zweitägiges Seminarprogramm erstellt. Wir behandeln darin ausführlich die Grundlagen des IT-Controllings, analysieren die Ankerpunkte für Kontroll- und Steuerungsmaßnahmen und beschäftigen uns ausführlich mit Kennzahlen (KPIs).

2 Termine stehen aktuell zur Auswahl:

Mi 10. – Do 11. Mai 2022, jeweils 9:00 – 16:00 Uhr
Mo 20. – Di 21. Juni 2022, jeweils 9:00 – 16:00 Uhr

📌 -10% Early Bird Rabatt bei Anmeldung bis 31. März 2022!

Weitere Informationen zu den Inhalten, Terminen und Anmeldemodalitäten finden Sie hier: https://www.konsultori.com/workshop-vom-it-controlling-zum-it-performance-management/

Viele Unternehmen erkennen gerade in Zeiten des stetigen Wandels den strategischen Wert von #Projektmanagement.
Immer mehr gehen den nächsten Schritt und setzen auf #Projektportfoliomanagement.

Dazu passend freue ich mich Ihnen mein neues Consultingangebot zum Fixpreis vorzustellen:
Welcher Trumpf steckt in Ihrem Projektportfolio?

Den Angebotsfolder gibt es hier zum Download.

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.

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?

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!

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.

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.

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.

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 😉

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.