Es ist so schön einfach: Excel gestartet und die neu beschlossene Produkt- und Artikelübersicht eingepflegt. Das gestaltet sich viel einfacher, als mit der IT eine Lösung abzustimmen und dann darauf zu warten. So landen jeden Tag landauf, landab auch kritische Geschäftsdaten in selbst gebauten Mini-Applikationen der Fachabteilungen – und die Schatten-IT wächst.

Diese Mini-Anwendungen sind zwar mitunter professionell und individuell hilfreich, bilden aber hinsichtlich der Datenintegrität, Datensicherheit und Verfügbarkeit ein Geschäftsrisiko für die Unternehmen. Wenn die Fachabteilungen eine größere Souveränität bei der internen IT bekommen, lassen sich beide Anforderungen vereinen.

Ein Gespräch mit Projektleiter Thomas Kneist über die Hintergründe von Schatten-IT und mögliche Auswege:

Transkript des Podcast-Gesprächs

Daniel Rasch: Hallo und herzlich willkommen zu einer neuen Ausgabe des mgm-Podcasts. Was ist Schatten-IT? Ist sie gut oder schlecht? Und wie lässt sich sich wieder einfangen? Da sist heute unser Thema. Ich spreche darüber mit meinem Kollegen Thomas Kneist, er ist erfahrener Projektleiter rund um Geschäftsanwendungen und dazu Standortleiter in Leipzig.

Hallo Thomas. Danke, dass wir das Gespräch führen können. Hallo nach Leipzig.

Thomas Kneist: Hallo Daniel. Freut mich.

Mich auch. Ja, wir wollen heute ein bisschen über Schatten-IT sprechen und wie man die Schatten-IT in die Sonne kriegen kann. Vielleicht einmal ganz zum Anfang: Schatten-IT – verbindest du das mit Fluch oder Segen? Und warum?

Es ist beides. Je nachdem aus welcher Perspektive man kommt. Wenn man aus der Perspektive einer Fachabteilung kommt, die vielleicht sehr effizient, sehr schnell ein Problem lösen will, ist Schatten-IT durchaus sinnvoll. Wenn man aus der Perspektive der IT-Abteilung oder des Gesamtunternehmens oder auch der Verantwortung kommt, ist es Fluch. Ganz klar. Weil Schatten-IT einfach an vielen Standards vorbei geht und das ist gefährlich.

Schatten-IT ist alles, was an den IT-Standards eines Unternehmens vorbeigeht.

Da kommen wir gleich bestimmt noch einmal zu. Aber erst einmal eine Grundsatzfrage sozusagen: Was ist Schatten-IT überhaupt und welche Varianten erlebst du so in deinem täglichen Arbeiten bei den Projekten?

Schatten-IT ist alles, was an den IT-Standards eines Unternehmens vorbeigeht. Das fängt an mit Endgeräten und Device. Ich habe ein mobiles Endgerät und habe meine Arbeits-E-Mails oder auch Daten darauf. Das geht über die Nutzung von Social-Media-Themen bis hin zu Applikationen, wo eben Daten verwaltet werden. Und das ist aus unserer Sicht das Kritische. Wir als mgm sind ein Software-Haus, wir machen Geschäftsanwendung. Das heißt, es geht uns um diese Geschäftsanwendungsdaten und wann immer die in Schatten-IT verwaltet werden, wird es schwierig.

 

Größter Teil: Excel – Grund: Pragmatismus

Das heißt, sowohl meine geliebte Excel-Liste, in der ich zum Beispiel meine Margen berechne, als auch eine in der Fachabteilung auf kurzem Dienstweg bestellte Cloud-Lösung, sind beides Schatten-IT-Lösungen?

Richtig. Also der absolut größte Teil sind tatsächlich Excel-Tabellen oder im weitesten Sinne Office-Anwendungen, Office-Dateien, die dann geschäftskritische Daten verwalten. Das sind Preislisten, das sind Kalkulationen, das sind Kundendaten, das sind Konzepte, was auch immer.

Wie entstehen diese Lösungen und warum gibt es die überhaupt?

Das ist eine Frage des Pragmatismus. Also eine Fachabteilung bekommt die Aufgabe, irgendetwas zu verwalten. Das erste, was einfällt, ist Excel. Das ist sehr häufig der Fall. Und dann komme ich mit Excel auch sehr weit. Ich kann meine Daten verwalten, ich kann das irgendwie berechnen. ich kann Makros einbauen, ich kann das visualisieren. Das ist eine sehr schnelle Hilfe. Und dann kommen irgendwann die Probleme.

Welche zum Beispiel?

Die sind vielfältig. Das erste ist, dass ich natürlich ein Versionsproblem habe. Ich kann nicht arbeitsteilig an einer Excel-Tabelle arbeiten. Ich habe eine Version offen, die ich bearbeite, die ich speichere, die ich dann im Zweifel weitergebe. Dann wird sie bearbeitet. Wenn parallel in zwei Dateien gearbeitet wird, habe ich wieder das Problem, dass ich es nicht synchronisieren kann. Das Ergebnis sieht man dann an den Dateinamen. Dann gibt es Dateinamen, die heißen Kalkulation 2020 Underline, Datum, Underline, Uhrzeit, Bearbeiter, letzter Stand, final irgendetwas. Also je länger diese Dateinamen werden, desto größer ist offensichtlich das Risiko, das ich habe.

Ein Risiko des Datenverlusts oder wie würdest du das beschreiben? Wie kann das noch weitergehen?

In alle Richtungen. Also Datenverlust ist einmal ein Thema. Dass ich natürlich, wenn ich da geschäftskritische Daten bearbeite, einfach sicherstellen will, dass ich auch nach Ausfällen, Hardware-Ausfällen, was auch immer, auf diese Daten zugreifen kann. Also Back-Up, Recovery-Konzepte sind schon einmal das eine. Datenschutz, Datensicherheit ist vielleicht noch viel kritischer. Also zum einen personenbezogene Daten, DSGVO-Vorschriften, die müssen irgendwie alle einhalten. Aber eben auch der Datenschutz für geschäftskritische, für vertrauliche Daten, der ist einfach dann nicht gegeben. Weil die Daten letzten Endes unkontrolliert durch die Gegend gereicht werden, weil die Tabellen, die Dateien per E-Mail im Zweifel durch die Gegend geschickt werden und dann ich nicht mehr kontrollieren kann, wer darauf Zugriff hat.

Also die Beispiele mit den langen Dateinamen und Versionen kennt wahrscheinlich jeder. Aber warum gehen dann Fachabteilungen bei so einer Herausforderung für Aufgaben, die sie haben, nicht zur IT-Abteilung und sagen, wir haben hier diese und diese Anforderungen und bitte löst sie für uns?

Weil das einen größeren Aufwand mit sich bringt. Also ein Office-Programm ist meistens vorhanden. Das habe ich, das kann ich nutzen. Und wie gesagt, das ist auch in vielen Fällen sinnvoll und führt auch zu vernünftigen Ergebnissen. Es gibt Grenzen oder Schwellen. Und wenn ich die überschreite, dann wird es kritisch. Auf der anderen Seite ist eine IT-Abteilung auch häufig sehr beschäftigt. Hat ihre eigenen Prozesse, ihre eigenen Zeitpläne auch, was solche Dinge anbelangt. Und dann kriege ich meine Lösung eben nicht so schnell oder nicht so einfach, wie ich mir das vorstelle

Betrifft das alle möglichen Unternehmen? Also Großkonzerne wie Mittelstand? Und vielleicht sogar Verwaltungen, Public Sector?

Meine Erfahrung sagt, ja.

Letzten Endes ist Schatten-IT ein Problem, das sich durch alle Bereiche zieht und alle betrifft in irgendeiner Form.

Und in besonderen Ausprägungen?

Also breit ist mein Erfahrungsschatz jetzt auch nicht, aber letzten Endes ist Schatten-IT ein Problem, das sich durch alle Bereiche zieht und alle betrifft in irgendeiner Form. Ich habe Preislisten gesehen, die per Excel-Datei durch die Gegend geschickt werden. Wirklich geschäftskritische Preislisten, die die Grundlage eines Geschäftsmodells bilden. Das ist schwer nachzuvollziehen, warum man das macht.

 

Fokussierte Insel-Lösungen – aber besser: Low Code-Plattformen

Kommen wir noch einmal kurz zum Anfang. Bei Wikipedia gibt es natürlich auch einen Eintrag zur Schatten-IT. Da sind ein paar Quellen, Aufsätze zusammengetragen und da sind sogar drei Chancen genannt. Da wird dann zum Beispiel genannt, dass das Positive ist, dass Fachbereiche sich grundsätzlich überhaupt mit IT auseinandersetzen und IT als Lösungsweg sehen. Es wird genannt, dass die selbstentwickelten Lösungen oft sehr viel näher an den wirklichen Bedürfnissen der Abteilungen dran sind. Reicht das nicht, um zu sagen, Mensch, am Ende müssen doch solche Anwendungen genutzt werden, dann ist das der beste Weg?

Also auch das hat Vor- und Nachteile. Natürlich hat eine Fachabteilung eine sehr genaue Vorstellung der Fachlogik, die sie da verwaltet und ist sehr gut in der Lage, die auch irgendwie abzubilden. Immer vorausgesetzt, sie hat die Möglichkeiten, das auch exakt so abzubilden. Wenn es diese Möglichkeiten gibt, dann ist das, was da herauskommt tatsächlich sehr ergonomisch, sehr professionell, auch sehr fokussiert auf die Anwendung, die ich eben habe. Aber durchaus auch sehr abgegrenzt für das, was ich da mache.

Und eben mit all den Risiken. Ich habe etwa sicherlich kein ausgefeiltes Berechtigungskonzept dahinter, keine Aktualisierung, wie sie beispielsweise in einem Active-Directory für ein Unternehmen sowieso Standard sind. Und es fehlt eine Strategie, wie ich die Daten in irgendeiner Form sichere. Wie ich eine revisionssichere Archivierung, vielleicht auch Löschung und solche Dinge sicherstelle. Aber um eine Fachlogik abzubilden, hat dieses Vorgehen natürlich eine sehr hohe Relevanz.

Wie kriegen wir so eine Schatten-IT zum Beispiel los? Nehmen wir einmal an, in einer Organisation ist die Erkenntnis gereift, dass es tatsächlich überhandnimmt. Was ist zu tun?

Wir haben jetzt schon zwei Beteiligte identifiziert. Das sind zum einen die IT-Abteilung, die verantwortlich sind für IT-Standards. Die Berechtigungssysteme, Benutzerverwaltungssystem haben, die für Datenhaltung zuständig sind. Die wissen, welche IT-Richtlinien in dem ganzen Kontext wichtig sind, bis hin auch zur Ergonomie, auch Barrierefreiheit und solche Themen. Und wir haben die Fachabteilung, die natürlich sehr genau über ihre fachliche Logik und über den Anwendungsfall Bescheid weiß. Wenn man das kombiniert, wenn man beiden ihre Kernkompetenz gibt, dann hat man die Chance da herauszukommen.

Letzten Endes heißt das, dass man einer Fachabteilung die Möglichkeit geben muss, ihre Fachlichkeit in irgendeiner Form einzubringen in ein Projekt. Und das dann so technisch umzusetzen, dass eine IT-Abteilung zum einen die Standards abbilden kann, zum anderen aber eben nicht überlastet wird.

Das klingt jetzt aber wieder nach einem Großprojekt. Genau das, was die Fachabteilungen vermeiden wollen.

Das kann man jetzt natürlich in verschiedenen Ausprägungen haben. Ich persönlich spreche von einer Low-Code-Anwendung. Idealerweise einer Low-Code-Anwendung spezialisiert auf Geschäftsanwendung. Und in der Form wäre eine Fachabteilung in der Lage, ihre Fachlichkeit, also Daten, Datenmodelle, Strukturen, die Beziehung, aber eben auch die Wertschöpfungsprozesse, die dahinter liegen mit den zugehörigen Oberflächen, Interaktionsmechanismen und so weiter, zu modellieren und diese Modelle, die die Fachlichkeit repräsentieren, die werden dann technisch angewendet, interpretiert. Dafür gibt es eben diese Technologie, die die entsprechenden Artefakte mitbringt, die Interpreter und diese Modelle dann einfach zum Leben erweckt.

Betrifft das nur die Einführung sozusagen so einer Low-Code-Anwendung oder dann auch den Dauerbetrieb auf n Jahre?

Das ist insbesondere für den Dauerbetrieb sehr interessant. Es gibt in der Software-Entwicklung das Konzept der Total-Cost-of-Ownership. Also die Frage, was kostet eine Software denn jetzt eigentlich? Und zwar über ihren gesamten Lebenszyklus hinweg. Und da gibt es drei große Kostenfaktoren. Der erste ist die Erstentwicklung. Das ist meistens sehr transparent, das kann man kalkulieren, das wird vielleicht auch eingehalten.

Aber viel größer als die Erstimplementierung sind zwei weitere Kostenfaktoren. Das ist zum einen die Weiterentwicklung. Und zwar die fachliche Weiterentwicklung. Eine vernünftige Geschäftsanwendung mit einer halbwegs komplexen Fachlichkeit wird sich über die Zeit entwickeln. Sie wird größer, sie wird sich verändern. Es gibt neue Regularien, neue Prozesse, dazu etwa neue Partner im Geschäft als eine von vielen Möglichkeiten der Veränderungen.

Und der dritte große Kostenblock ist die technische Weiterentwicklung, der Support. Also alles, was ich im Hintergrund machen muss, um das Ganze technologisch auf einem aktuellen auch sicheren Stand zu haben. Und gerade diese beiden Blöcke, die werden häufig unterschätzt und werden aber durch dieses Vorgehensmodell, nämlich Fachlichkeit in Modelle zu überführen und damit aus der Technologie herauszuhalten oder von der Technologie zu trennen und damit eben auch eigenständige Technologie zu haben, beantwortet.

 

Mit Low Code schnell zur lauffähigen Anwendung

In meinem Beispiel mit Low-Code-Plattform mit modellierter Fachlichkeit heißt es, dass idealer Weise ein Fachkollege die Modelle verändert und sich das automatisch auf die Anwendung auswirkt.

Heißt dann aber, wenn wir beim Beispiel der Preislisten bleiben, zum Beispiel ein Vertriebler, Vertrieblerin bisher mit Excel unterwegs, wird dann dauerhaft irgendetwas modellieren, entwickeln, coden müssen oder so?

Nein. Er wird einmal, entweder selbst oder unterstützt durch einen Dienstleister, die fachliche Logik modellieren müssen, die dann wiederum umgesetzt wird in eine Anwendung. Das ist eine sehr einfache Beschreibung. Natürlich ist da noch ein bisschen mehr Magie dahinter. Aber mit der entsprechenden Low-Code-Plattform und den entsprechenden Services, die damit verbunden sind, hat man damit eben seine Anwendung.

Das schöne ist, dass die Anwendung dann nicht nur prototypischen Charakter hat, sondern tatsächlich lauffähig ist. Das heißt man hat sehr schnell ein visuelles Ergebnis, mit dem man tatsächlich arbeiten oder auch testen kann. Und das dann iterativ weiterentwickeln kann.

Ich nenne einmal ein Beispiel, das hat jeder in der Vergangenheit erlebt in einem Software-Entwicklungsprozess im klassischen Sinne: Die Erstimplementierung kostet eine Million, dauert ein Jahr. Jetzt ist das System eingeführt und jetzt hat die Fachabteilung drei kleine Wünsche. Da soll noch ein weiteres Feld eingefügt werden und es gibt noch irgendeine Abhängigkeit, irgendeine neue Sicht. Und das kostet jetzt eine halbe Million und dauert ein halbes Jahr. Und das ist eine Relation, die nie jemand versteht, die aber tatsächlich so ist, wenn ich das ganze klassisch mache.

In meinem Beispiel mit Low-Code-Plattform mit modellierter Fachlichkeit heißt es, dass idealer Weise ein Fachkollege die Modelle verändert und sich das automatisch auf die Anwendung auswirkt. Auch das ist sehr einfach formuliert. Vielleicht brauche ich dann doch schon Synchronisationsmechanismen, Migrationsmechanismen. Aber das ist ein deutlicher Unterschied. Das verändert die gesamte Relation, die gesamte Kostenstruktur, die gesamte Wertschöpfung deutlich. Das heißt, mit Blick auf Total-Cost-of-Ownership ist insbesondere die gesamte Laufzeit einer Applikation in dem Ansatz, den ich beschreibe, günstiger.

Das heißt, die Fachexperten sind dann auch für die weitere Pflege zuständig? Wenn zum Beispiel diese Anforderung, wir brauchen jetzt da oben rechts ein Kästchen, wird ebenfalls auch nach einem Jahr nicht ein Entwickler beauftragt, sondern das wird innerhalb der Fachabteilung mit den Modellen und so etwas selbst gemacht?

Richtig. Also noch einmal zurück auf die unterschiedlichen Beteiligten. Wir haben jetzt eine Fachabteilung. Wir nennen diese fachlich Arbeitenden, auch Business-Analyst, und wir haben die Technik, die Software-Entwickler. Bisher war in einem klassischen Projekt eine Fachabteilung vor allem damit beschäftigt war, Konzepte zu schreiben, ihre Fachlogik irgendwie zu dokumentieren und in irgendeiner schriftlichem Form, vielleicht auch ein Stück weit visualisiert, an die Entwicklung zu übergeben, die das dann wiederum interpretiert, liest, verstehen muss, um das dann umzusetzen. Jetzt ist es so, dass die Fachabteilung tatsächlich Teile, gerne auch große Teile der Wertschöpfung selber übernehmen kann, indem sie eben selber modelliert.

Das passiert mithilfe einer sogenannten Domain-spezifischen Sprache, die man lernen kann. Die sehr formal, sehr standardisiert eben die Fachlichkeit dann beschreibt. Und diese Modelle, die werden dann wie gesagt nur noch angewendet. Das heißt, die IT konzentriert sich ein Stück weit auf die Kernkompetenz oder auf anspruchsvolle Aufgaben. Das sind dann Individualentwicklungslösungen für besonders komplexe fachliche Anwendungsfälle. Und das ist die gesamte Integration, auch der gesamte Standardteil. Also die Anbindung von Benutzerverwaltungssystemen, die Anbindung von Datenhaltungssystemen, von Trittsystemen, Schnittstellen, all das, was da eine Rolle spielt.

 

Neuer Wertschöpfungsprozess ohne Grenzen

Und welche Arten lassen sich von Business-Applikationen damit abbilden? Du hast eben am Anfang ein paar Beispiele genannt, von Excel bis zu den komplizierteren Dingen. Sind dann keine Grenzen gesetzt?

Im Prinzip sind da keine Grenzen gesetzt. Also jede Geschäftsanwendung, die in irgendeiner Form Daten verwaltet, egal ob das Kunden, Preise, Nutzer, was auch immer sind, und diese Daten durch einen Wertschöpfungsprozess führt, lässt sich damit abbilden.

Da es ein neuerer Ansatz ist als klassische Software-Entwicklung, hört sich das nach einem Veränderungsprozess an, also einem Change. Von wem sollte der denn kommen? Kommt der dann aus der Fachabteilung oder aus der IT-Abteilung? Dann haben wir wieder das Problem, dass die IT-Abteilung von oben kommt und irgendetwas will und verordnet.

Das ist unterschiedlich. Also ich habe die Erfahrung gemacht, dass die Anforderungen sowohl aus einer Fachabteilung als auch aus einer IT-Abteilung kommen können. Je nachdem, wer sich eben jetzt des Problems annimmt oder eben eher die Chancen erkennt und das dann umsetzen will.

Gibt es da erfolgskritische Faktoren, was besser ist, eben um die Akzeptanz zu erhöhen?

Nein.

Gut. Kommen wir so langsam zum Schluss. Nehmen wir einmal an, es ist jetzt so modellbasiert umgesetzt, wie sieht denn dann so ein Alltag aus? Was hat sich danach geändert? Sowohl für die beiden Beteiligten, Fachabteilung und IT-Abteilung?

Erst einmal sind die Risiken weg. Also ich habe jetzt eine Web-Applikation, die alle Fragen beantwortet. Die eine Fachlichkeit möglichst vollständig abbildet. Und zwar auch mit Begrifflichkeiten wie Ergonomie oder User-Experience. Das ist auch ein wichtiger Punkt. Also ich habe meine Fachlichkeit abgebildet. Ich habe Datenschutz, Datensicherheit sichergestellt. Das heißt, es gibt ein Berechtigungskonzept und die Kontrolle darüber, wer wann was mit den Daten macht. Außerdem ein revisionssicheres Archivierungskonzept dahinter. Ein weiterer Stichpunkt dazu ist im übrigen ist digitale Souveränität.

Und was haben die Anwender davon? Außer dass sie jetzt nicht mehr Version 83 hinter Dateinamen schreiben müssen?

Eben, dass sie das nicht machen müssen. Sie können sichergehen, dass sie in die Applikation hereinkommen, dass die Daten konsistent sind, dass sie aktuell sind, dass sie immer in der aktuellsten Version arbeiten und dass sie eben im Idealfall Teil eines größeren Prozesses sind. Ein weiterer Nachteil von Schatten-IT ist, dass diese Anwendungen sehr isoliert stattfinden, eben nicht Daten aus Vorsystemen nutzen beziehungsweise Daten an weitere Systeme weitergeben können. Und jetzt bin ich einfach in einem großen Wertschöpfungsprozess eingebunden und kann meinen Beitrag leisten.

Letzte Frage: Sind Unternehmen überhaupt denkbar, in denen es keinerlei Schatten-IT gibt, wo alles in der Sonne ist, denkbar und möglich?

In der Theorie sicher, aber in der Praxis nicht.

Alles klar. Thomas, herzlichen Dank für das Gespräch. Wir werden uns bestimmt noch einmal zu einem ähnlichen Thema und zu Excel und Co weitersprechen. Danke dir.

Sehr gerne.

Share