IT and BI
IT-Afinität und BI-Know-How
IT und (versus) BI sind zwei ausgeprägte und letztlich spezialisierte Funktionen.
IT (Information Technology)
Zur IT-Funktion werden häufig unter anderem zugeordnet:
- Hardware-Gestaltung und -Verwaltung
- Datenbank-Management
- Netzwerk-Management
- Ansprechpartner für End-User bei Tool-Problemen (HW und SW) inklusive Hotline / Ticket-System
- Service-Dienstleister rund um HW und SW
BI (Business Intelligence)
Zur BI-Funktion können zugeordnet werden (bisher oftmals von der IT stark geprägt und gesteuert):
- Business-Analysen aller Art
- Reporting-Design und -Erstellung
- Festlegung der Reporting-Daten-Quellen
- Analyse-Vorgaben
+ Kalkulations-Formeln (i.d.R. Grundrechenarten und Prozent)
+ Vorzeichen bei Daten-Ausgabe an End-Anwender mit ggfs. definiter Farbe (u.a. rot)
Die exakten Vorgaben in Form eines Lasten-Heftes, das dann in ein professionelles Plichten-Heft oder einen sog. Blueprint umgesetzt wird, sind eine Voraussetzung für ein erfolgreiches IT- oder BI-Projekt. Dazu gehören auch vermeintlich ganz banal anmutende Analyse-Vorgaben.
SW-Entwickler versus SW-Programmierer
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.
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.
IT-Hotline und SW-Programmierung
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.
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.
Know-How ins System
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.
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.
Programmier-Kenntnisse und IT-Afinität erwünscht
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.