IT and BI

IT und (versus) BI sind zwei ausgeprägte und letztlich spezialisierte Funktionen.

Zur IT-Funktion werden häufig unter anderem zugeordnet:

Zur BI-Funktion können zugeordnet werden (bisher oftmals von der IT stark geprägt und gesteuert):

SW-Entwickler
Ist ein erfahrener Programmierer mit HW- und SW-Know-How, der auch tiefere Prozess- und End-Anwender-Kenntnisse hat. Idealerweise erworben in vielen verschiedenen Projekten. Ein Spezialist, der sich blind mit Lastenheften, Pflichtenheften oder sog. Blueprints auskennt. Ein echter Know-How-Träger mit Programmier-Kenntnissen, der ausschließlich in Entwicklungs- und Programmierungs-Projekten tätig ist. Kann damit im Projekt auch die Funktion eines reinen SW-Programmierers übernehmen.

SW-Programmierer:
Baut anhand konkreten Vorgaben wie u.a. aus sog. Lasten-Heften (an denen er ggfs. auch unterstützend mitgestaltet hat) die sog. Pflichten-Hefte auf, die die IT- und die BI-Informationen wie Daten-Feld-ID und Prozess-Besonderheiten enthält, die für die finale SW-Programmierung unabdingbar notwendig (mandatory) sind.

Aus einem guten Programmierer wächst im Laufe der Zeit und der guten Projekt-Erfahrung ein neuer Entwickler heran. Diese Zeit muss einfach gegeben werden.

Häufig wird die interne IT als All-Round-Fachkraft-Dienstleister benutzt, die extremes Multi-Tasking betreiben muss, um all die täglich anfallenden Themen abzuarbeiten.

Dadurch konkurrieren Funktionen wie "Routine-Monats-Abschluß" mit Hotline-Funktionen inclusive Ticket-Abarbeitung nach Prio-Hierarchie je Ticket-Ersteller. Wenn dann dazu noch eine notwendige SW-Anpassung adhoc und by the way durchgeführt werden muss, dann ist das Ergebnis schon absehbar.

Auf Grund sich jährlich verschärfender Budget-Vorgaben ist dies mittlerweile ein großes Risiko für Prozess-Stabilität - gerade auch für neue Projekte, die auf die IT-Ünterstützung angewiesen sind.

Da ich selbst aus dem Controlling komme und damit nahe am Budgetierungs-Geschehen dran bin, stelle ich immer wieder fest, dass hier am falschen Ende gespart wird.

Ohne hochwertige IT-Tools und spezialisierten IT-Support geht es heute nicht mehr.
Diese Idee ist schon seit Jahrzehnten bekannt (zumindest in amerikanischen Unternehmen):

            Das Know-How muss ins System = IT- und BI-Tools (HW und SW)

Wie ich an andererer Stelle schon ausgeführt habe, gewinnt die beste Organisation mit hohem Standardisierungs- und Automatisierungsgrad (und damit den besten Prozess-Logiken) am Markt und nicht der Lieferant, mit dem besten Produkt für den End-Kunden.

Ein Programmierer muss mindestens 2/3 seiner Leistungszeit mit Programmierung beschäftigt sein, ansonsten ist das Know-How nicht akkurat genug. Diese Möglichkeit muss dem Programmierer aber auch gegeben werden - von Unternehmensseite bzw. Kunden-Seite. Eine Auslastung von weniger als 60% kann aber keinen Programmierer am Markt erhalten.

Bedenklich sind IT-Spezialisten, die neben Programmierung auch noch die End-Anwender-Sicht einnehmen und ein tolle IT-Lösung vorschlagen und ggfs. selbst programmieren (wollen versus können). Wenn es sich dabei auch noch um eine IT handelt, die regulär zu 80% mit Hotline-Diensten beschäftigt ist, dann ist der (Miß-)Erfolg schon garantiert.

Noch kritischer sind Reporting-Spezialisten, die der Meinung sind, sie könnten nebenbei auch sinnvolle Makros, Skripte oder gar tolle Syntax-Anpassungen (Programmier-Code-Änderungen) vornehmen, wie sie es derletzt (d.h. vor zig Jahren) schon einmal (mehr oder weniger) erfolgreich probiert hatten. Dies geht garantiert in der Kürze der verfügbaren Projekt-Zeit schief. 

Das sog. "Eier legende Woll-Milch-Ferkel" wurde bisher noch nicht erfolgreich gezüchtet oder hat sich sonstwie entwickelt und konnte deshalb auch nicht irgendwo gefunden werden.

Ein erfahrener Programmierer und damit auch ein Tool-Entwickler hat mir schon vor Jahren erklärt, dass selbst bei Office-Versionen je nach Version neue Bibliotheken geliefert werden. Damit einhergehend entsteht auch ein Wechsel der Progammier-Codings (Syntax alt versus neu).

Dies ist ein Grund, weshalb ein SW-Entwickler auch alte Programme ungern anpasst und lieber ganz neuen Programm-Code verwendet, d.h. die SW neu schreibt. Die Grund-Ideen der alten SW kann zum Teil übernommen werden. Aber auch die Modelle zur Programm-Code-Gestaltung ändern sich im Laufe der Zeit.

Eine Progammierung macht also nur Sinn, wenn der Tool-Lifecycle auch noch die Investition rechtfertigt. Durch Compliance-Themen kann es jedoch immer notwendig werden, Anpassungen auch für einen kurzen Rest-Zeitraum (Lifecycle) vorzunehmen.

Weitere Informationen hierzu finden Sie im Register "Compliance & Lifecycle.