Im Zuge unserer Forschung, aber auch der praktischen Anwendung unserer Ansätze mit Unternehmen, sind wir immer wieder bei der Erkenntnis angelangt, dass es keine one-fits-all-Governance gibt. Schon unsere ersten Untersuchungen im Bereich Schatten-IT zeigten, dass nicht jede Applikation gleich ist und daher Aufgaben und Verantwortlichkeiten von Applikationsklassen abhängen. Wie die Ergebnisse unserer Low-Code Forschung diese Erkenntnis erneut unterstreichen, skizzieren wir in diesem Beitrag.
Der klassische one-fits-all-Governance-Ansatz für IT-Applikationen im Allgemeinen beschreibt die Zusammenarbeit zwischen den Fachbereichen und IT in etwa wie folgt: Das Business sollte für die Betreuung von End-Usern, die Definition von Anforderungen und das Testing zuständig sein. Die IT-Abteilung übernimmt den Second-Level-Support, entwickelt die Applikationen, übernimmt das Deployment und stellt die Infrastruktur bereit. Dieser Ansatz war sicherlich eine ganze Weile sinnvoll, doch die Realität zeigt ein anderes Bild: Fachbereiche sind unterschiedlich stark im Technology Stack einer Applikation involviert. Besonders bei Business-Managed-Applikationen sind sie oft sogar selbst EntwicklerInnen oder betreiben auch gewisse Teile der Infrastruktur, deren Zugang durch den Einsatz von Cloudservices stets vereinfacht wird und durch Infrastructure-as-a-Service-Angebote auch für Anwender zugänglich gemacht wird, ohne dass tiefes Fachwissen erfordert wird. Eine Diskussion über Rollen, Verantwortlichkeiten und Qualitätsstandards – oder wie wir sagen: Governance – muss also viel feingranularer stattfinden. Dies zeigt auch schon unsere frühere Forschung (vgl. Zimmermann et al. 2014).
Adaptive Governance-Stufen schaffen Klarheit bei der Low-Code-Applikationsentwicklung und -betrieb
Diese Erkenntnis schlägt sich auch in unserer Forschung zu Low-Code nieder: Dabei helfen Low-Code-Applikationsklassen für eine erste Aufgabenteilung, ohne sofort über jede Applikation im Einzelnen sprechen zu müssen. Die Einteilung in die verschiedenen Klassen geschieht auf Basis von Kriterien, die die Kritikalität und Komplexität der Applikation widerspiegeln, wie beispielsweise Anzahl der Nutzenden, Datenverwendung, Business Impact oder auch Integrationsgrad. Für diese Applikationsklassen wird ein erstes Modell festgelegt, das beschreibt, wer für welche Aufgabe zuständig ist, wie die grundsätzliche Zusammenarbeit zwischen Fachbereich und IT in diesen verschiedenen Aufgaben definiert ist, und welche Qualitätsstandards für die jeweilige Aufgabe eingehalten werden müssen.
Im Rahmen unserer Projekte haben sich für Low-Code drei verschiedene Applikationsklassen herausgebildet, die auf dem Bild zu sehen sind und im Nachfolgenden beschrieben werden.
Personal Productivity: Hier sind Low-Code-Applikationen angesiedelt, die der Steigerung der Effizienz persönlicher Aufgaben dienen. Das können beispielsweise Applikationen sein, in denen eigene ToDo-Listen (bspw. durch eine Automatisierung zwischen MS Outlook und der eigenen ToDo-Applikation) oder die eigene Zeiterfassung gepflegt wird (bspw. durch eine Automatisierung zwischen dem eigenen Kalender und einer eigenen Zeiterfassung). Bei den Applikationen im Bereich „Personal Productivity“ liegt die meiste Verantwortlichkeit im Fachbereich, es gibt wenige Vorgaben zur Qualität der Aufgaben und der Citizen Developer (siehe auch „Fachbereiche in der Zone der Überforderung?„) hat viel Freiraum.
Team Productivity: Diese Klasse beinhaltet Low-Code-Applikationen, die der Verbesserung der Zusammenarbeit im Team dienen. Dies können beispielsweise Applikationen sein, die dem Vertriebsteam zur Errechnung von Produktpreisen dienen (bspw. durch eine Verbindung von ERP-Daten und eigenen Produktkonfigurationen). In dieser Klasse gibt es erfahrungsgemäß die meisten Diskussionen zu den Verantwortlichkeiten zwischen Business und IT, weil sich hier der Risikoappetit des Unternehmens zeigt (siehe auch: „Low-Code Entwicklungsplattformen – Eine Chance für Business & IT„). Tendenziell liegt bei „Team Productivity“ immer noch viel Verantwortung beim Business, die Qualitätsstandards sind jedoch höher und bei gewissen Aufgaben (z.B. bei der Freigabe der Applikationen) schaltet sich die IT ein.
Organizational Productivity: Diese Klasse beinhaltet Lösungen zur Steigerung der Effizienz ganzer Geschäftsprozesse, die vom Fachbereich entwickelt werden. Low-Code-Applikationen in dieser Klasse werden über Teams hinweg eingesetzt. Ein Beispiel könnte ein Tool sein, dass Daten aus dem ERP-System nutzt, um Angebote zu erstellen, zu qualifizieren und am Ende zur Produktion wieder ins ERP-System zu leiten. Die Qualitätsstandards, nach denen die Aufgaben der Klasse „Organizational Productivity“ zu erledigen sind, auf Grund ihrer hohen Komplexität und Kritikalität und dem Ziel einer Risikominimierung sehr hoch. Sie unterscheiden sich selten von Applikationen, die von der IT-Abteilung entwickelt werden.
Der Grundgedanke der Applikationsklassen spiegelt sich in unseren Forschungsworkshops und Beratungspaketen wider (BITCO³ Low-Code-Maturity-Model). Die Rückmeldungen zu diesem Ansatz sind durchweg positiv und ermöglichen eine strukturierte Diskussion über die benötigte Low-Code-Governance. Wenn Sie dieses Konzept für sich adaptieren und für das nächste Vertriebsgespräch mit einem Low-Code-Anbieter gewappnet sein wollen, dann kontaktieren Sie uns gerne!
Literatur:
Zimmermann, Stephan, Rentrop, Christopher, Felden, Carsten (2014): Managing Shadow IT Instances – A method to control autonomous IT solutions in the business departments; In Proceedings of the 20th Americas Conference on Information Systems (AMCIS) 2014, Savannah, Georgia, S. 1-12.
Bitte zitieren als: Bitco³ – Melanie Huber (2023). LCDP-Governance und angewandte Forschung: Über die Notwendigkeit differenzierter Rollen und Verantwortlichkeiten – 06.10.2023. Online verfügbar unter https://bitco3.com/2023/10/06/lcdp-governance-und-angewandte-forschung-ueber-die-notwendigkeit-differenzierter-rollen-und-verantwortlichkeiten/.
