Schwarze Löcher im Bestand

Die Realität in vielen Immobilienbeständen: Sanierungsbedarf fällt erst anläßlich einer Wohnungsübergabe, Beschwerde oder eines Schadens auf. Es gibt keine laufende und anlasslose Suche nach Sanierungsthemen. Sind Probleme bekannt, wird verschoben: zu kurzfristig; Mitarbeiter sind gerade von anderen Dingen absorbiert; wegen Vermeidung von Leerstand soll es mit der Neuvermietung schnell gehen;  das Sanierungs-Budget ist bereits ausgeschöpft etc. 

Diese Praxis bringt Probleme mit sich:

• Schäden verschlimmern sich, wenn sie zu spät angegangen werden: was als feuchte Stelle angefangen hat, endet als Schimmel-Sanierung;
• das weiß auch die Versicherung, die unter Umständen nicht zahlt, wenn nicht beizeiten vorgesorgt wurde;
• die Neuvermietung verzögert sich, weil ungeplant saniert werden muß;
• aus demselben Grund sind Mitarbeiter, Handwerker und Material nicht eingetaktet, was für alle Beteiligten Streß bedeutet;
• Sanierungen erfolgen unkoordiniert, so daß Kostensparpotential gleichzeitiger ähnlicher Maßnahmen verschenkt wird mit Mindermengen-Zuschlägen, x-fachen Anfahrts- und anderen Fixkosten;
• sporadische, ungeplante Sanierungen verschleiern die Notwendigkeit, für ein umfassenderes Sanierungskonzept eine günstige Förderung oder Fremdfinanzierung zu suchen, was unwirtschaftlich ist und zu unerwarteten Liquiditätsengpässen führen kann;
• Mieterhöhungspotential bei Modernisierungs- und energetischer Sanierung wird verschenkt;
• eine schleichende Wertminderung des Bestands wird inkaufgenommen;
• schlecht sanierte Wohnungen sind für Mieter unattraktiv, d.h. auch die Zufriedenheit und langfristig die Qualität der Mieterschaft sinkt;
• eine seriöse Liquiditäts- und Wirschaftlichkeitsplanung ist nicht möglich, wenn man nicht weiß, was sich noch da verbirgt – nicht nur, daß man nicht saniert, man kann es nicht einmal beziffern;
• Rückstellungen für unterlassene Instandsetzungen in der Bilanz fallen systematisch zu gering aus, man rechnet sich das Ergebnis schön.
• Für das schöngerechnete Ergebnis zahlt man auch noch Ertragssteuern, statt die abzugsfähigen Sanierungsaufwendungen zu nutzen, um die Steuerlast zu senken. 

Bedürfnisse und Kenntnisstand der Mieter nutzen

Ohne aktive, regelmäßige Suche nach Sanierungsthemen wird sich ein Sanierungsstau nicht vermeiden lassen. Jedoch läßt sich der Aufwand, den man damit hat, erheblich reduzieren, wenn der Mieter in die Suche mit einbezogen wird.

Der Mieter hat an zwei Stellen einen Vorsprung gegenüber der Immobilienverwaltung:

• er nutzt die Mietsache, meist mit allem, was diese bietet, und verbringt jede Menge Zeit vor Ort, meist viele Stunden jeden Tag;
• es sind seine Bedürfnisse, für die die Mietsache gemacht ist, und nicht die der Mitarbeiter der Immobilienverwaltung, so daß der Mieter keine Phantasie braucht, um festzustellen, was nicht paßt.

Diese Kombination aus Anwesenheit und Betroffenheit machen den Mieter zu einem wertvollen Mitarbeiter! Das Ziel besteht darin, den Mieter dazu anregen, Mängel auch dann mitzuteilen, wenn sie ihn (im Moment noch) gar nicht stören, und zwar garniert mit relevanten Details und ggf. Fotomaterial – jeder vom Mieter bereits gut dokumentierte Mangel spart Zeit, dies selbst zu tun!

Die Einbeziehung der Mieter zur Aufdeckung von Instandhaltungs-Versäumnissen ist in Beständen sinnvoll, die im Großen und Ganzen in Ordnung sind. Ist eine Sanierung von Grund auf erforderlich oder der Stau an Kleinigkeiten enorm, bringen die Mieter nicht die nötigen umfassenden und kundigen Informationen bei. Hier empfiehlt sich eine Objektanalyse durch den Experten.

Nebenbei das Verhältnis zu den Mietern verbessern

Im Rahmen eines aktiven Prozesses zum Abbau des Sanierungsstaus nimmt der Mieter nicht nur der Immobilienverwaltung Arbeit ab, sondern bekommt auch etwas zurück. Self Service bedeutet ja zugleich, daß es dem Mieter erleichtert wird, einen Mangel zu melden, und daß er diesen schneller und mit weniger Hin und Her beseitigt bekommt. Der Mieter hat zurecht das Gefühl, daß er mit dem Vermieter kommuniziert, seine Sorgen und Nöte ernst genommen werden und in Handlungen münden. Man kümmert sich um ihn.

Nicht zuletzt wird so laufend die Mängelliste für das Auszugsprotokoll aktualisiert und Konfliktpotential darüber, wer einen Mangel zu verantworten hat, schon bei Auftreten des Problem angegangen.

Prozesse definieren

Man kann mehr tun, als den Mieter bei Gelegenheit zu fragen, ob ihm etwas aufgefallen ist. Lediglich regelmäßig allen Mietern mitzuteilen, daß man sich über Informationen über und Fotos von möglichen Sanierungsthemen freuen würde, endet im Chaos mit entnervten Mitarbeitern und frustrierten Mietern.

Je nach Immobilienbestand und Mieterschaft empfehlen sich unterschiedliche Initiativen:

• Ist ein bestimmter Mangel (vermehrt) aufgetreten, kann man vermuten, daß im Bestand noch mehr gleichartige Probleme lauern – man könnte alle Mieter z.B. gezielt danach fragen, wie die Silikonfugen in ihren Bädern aussehen oder sie bitten, ein Foto davon zu machen. Für speziell dieses Thema wichtige Details werden explizit abgefragt. Beim nächsten mal dann ein ganz anderes Thema mit anderen Fragen
• Ist kein Muster zu erkennen, bietet sich stattdessen ein für alle Problemkonstellationen geeignetes Mängel-Formular an. Wahrscheinlich sollte man trotzdem gezielt nach bestimmten Themen fragen, allein um das Bewusstsein für eine bestimmte Mängelkategorie beim Mieter zu schärfen. Aufhänger ist dann vielleicht der Beginn der Heizperiode oder ein Themenkomplex wie Abfallentsorgung oder Schimmelbildung.

Mit dem Anstoßen eines Prozesses ist die Mitwirkung des Mieters aber noch nicht zuende: Terminkoordination und Erfolgskontrolle können ebenfalls mit Self Service besser und schneller gelingen.

Prozesse digital bereitstellen

Eine kleine, aber bereits sehr effektive digitale Lösung für Mieter-Self-Service zum Abbau des Sanierungsstaus ist ein Web-Formular, in das Mieter einen Mängelbericht eintragen können. Die Immobilienverwaltung kann per Email oder Messenger den Link zum Formular verschicken, und schon fließt die Information. Bleibt es beim Formular, kommt in der Immobilienverwaltung leider nur unstrukturiert Information an, und der weitere Prozess-Ablauf mit Email, Messenger oder Telefon muß manuell strukturiert werden, sprich ist in der Praxis uneinheitlich und fehlerbehaftet.

Dieses Problem läßt sich vermeiden, wenn auch der weitere Ablauf programmatisch erfolgt. Eine kleine App für diesen Teilprozess der Interaktion zwischen Mietverwaltung und Mieter, bei der ein ganz eng umgrenztes Problem der Mietverwaltung angegangen wird, kann den gesamten Prozess einschließlich der Kommunikation mit der Immobilienverwaltung digital abbilden.

Bleibt noch die Frage, wie die Mieter- und Mietobjekts-Stammdaten in die App hineinkommen. Je nach Umfang lohnt es sich, hier statt eines initialen Imports z.B. von Excel oder gar einer manuellen Einpflege eine Integration mit dem bestehenden ERP per Programmierschnittstelle (API) vorzunehmen.

Die Zeiterfassung ist nicht nur zu Abrechnungszwecken von Bedeutung, sondern auch eine zentrale Datengrundlage für das Controlling.

Im Screenshot sind Softwareentwicklungs-Stunden mit den Kontexten des Issues, auf das getrackt wurde und der Aktivitätskategorie abgebildet. Würde man Hausmeistereinsätze in einer Hausverwaltung tracken, wäre als weiterer Kontext z.B. die Mieteinheit von Interesse. Arbeitszeiterfassung zwecks Compliance mit dem Arbeitszeitgesetz (ArbZG) und Berechnung von Überstunden setzt Zuordnung zu Zeitperioden wie Tag, Woche, Monat voraus. All dies ist machbar!

Zeit im Kontext erfassen – direkt am Podio-Eintrag

Warum nicht einfach parallel zur Arbeit mit Podio einen der zahllosen Time Tracker für das Smartphone oder den Desktop laufen lassen? Weil doppelte Datenhaltung unnötig Arbeit macht und fehleranfällig ist. Man will nicht jeden Podio-Eintrag, zu dem man Zeit aufzeichnen will, zusätzlich in der Time-Tracking-Software anlegen — oder, wenn wir uns diese Arbeit nicht machen wollen, nur ingesamt eine Uhr laufen lassen und erfaßte Zeit unseren Einträgen auf Podio nicht präzise zuordnen können.

Wenn man in Podio arbeitet, erfaßt man die Zeit auch direkt in Podio. Die detailliertest-möglichen Stelle dafür ist der Podio-Arbeits-Eintrag, also je nach Architektur das Ticket oder Issue, der Kontakt, mit dem ich spreche uvm. Alle relevanten Daten sollen bei der Arbeit autmatisch mit entstehen! Auf dieser Datengrundlage sollte die Auswertung und Berechnungen direkt in Podio möglich sein. Automatisierungen sollten durch Ergebnisse aus der Zeiterfassung triggerbar sein, Abrechnung direkt aus Podio heraus und Vieles mehr.

Podio-Zeiterfassungs-Extensions und Integration anderer Time Tracker

Verfügbare Extensions von Drittanbietern wie teamdeck, Time Doctor, TMetric, TimeCamp u.s. bieten meist, wie oben gefordert, eine Erfassung direkt am Podio-Eintrag. Das ist besser als eine doppelte Datenhaltung per Hand oder Ex- und Import — aber immer noch doppelte Datenhaltung. Die Extension kostet, erfordert (wenn auch geringe) Einarbeitung und kann auch mal ausfallen oder schlimmstenfalls eingestellt werden.

Die gängigen Time Tracker wie Everhour, Harvest, Toggl etc. haben alle eine API und können über Integrations-Tools wie Zapier oder einem Skript ebenfalls in Podio eingebunden werden. Doch all das kostet Geld in Form von Gebühren und Entwicklung, und es hat Grenzen: ein Teil der Daten sind nur im Time Tracker verfügbar, und das heißt: nicht in Podio. Was trotzdem für eine Schnittstellenintegration eines dedizierten Timetrackers sprechen kann, ist die gleichzeitige Nutzung der Zeiterfassung für Prozesse außerhalb von Podio, d.h. andere SaaS-Software etwa zur Rechnungserstellung.

Zeiterfassung mit Podio-Bordmitteln

Mit Podio-PLUS- oder PREMIUM-Plan kann Zeit erfaßt werden, ohne dafür Podio verlassen zu müssen. Eine separate Lösung dafür, Daten aus der Zeiterfassung in Podio weiterzuverarbeiten, ist deshalb überflüssig.

Manuelle Zeiterfassungsbögen

„Zeit erfassen” heißt nicht zwingend “Zeit loggen/tracken/aufzeichnen”, also mit Beginn einer Tätigkeit einen Timer starten und diesen am Ende stoppen, so daß die Zeit dazwischen automatisch als Arbeitszeit erfaßt wird. Mehr dazu weiter unten. Aber viele Unternehmen halten es für ausreichend oder sogar vorteilhaft, wenn Mitarbeiter ihre Arbeitszeit händisch und nach eigenem Ermessen nachhalten. Das klappt nur, wenn dies zeitnah erledigt wird, also sofort oder wenigstens täglich, und wenn Plausibilitätsüberlegungen einfließen wie die Berücksichtigung von Pausen- und Verwaltungszeiten sowie das Blocken von Überlauf der gesamten Anwesenheitszeit am Arbeitsplatz.

Benötigt wird:

• eine App für Zeiterfassungsbögen/Time Sheets, in der der Mitarbeiter (mit Podio-Kontakt-Feld, dann kann man eine gefilterte Ansicht für nur die eigenen Time Sheets anlegen), das Datum und die Dauer eingetragen werden können, eventuell eine Notiz. Auf jeden Fall sollte es ein Verbindungs-Feld zu den Einträgen der “Action App” geben, an die die Zeit aufgezeichnet werden soll. Sinnvoll ist auch ein Verbindungsfeld zu Kostenstellen/Abteilungen/Aktivitäten, denen man geleistete Arbeit zuordnen möchte, sei es aus Controlling- oder aus Abrechnungsgründen. Zudem noch eine App mit den Mitarbeitern (zu unterscheiden vom Podio-Kontakt oben), in der die Stunden pro Mitarbeiter gesammelt und analysiert werden können (was am Kontakt nicht geht).
• Felder am Referenz-Eintrag, von dem aus das Time Sheet erstellt werden soll, für die Dauer (Zeiteintrag), Kostenstelle/Aktivität (Verbindung) und ggf. Notiz. Und ein Podio-Kategoriefeld, mit dem man dann die Erstellung des Time Sheets “triggert”, d.h. anstößt.
• einen Workflow, der nach Klick auf den “jetzt Zeit erfassen!”-Button ein Time Sheet erstellt und dabei a) die Inhalte der ausgefüllten Felder übernimmt, b) als Referenz das aktuelle Item, c) als Mitarbeiter den Button-Bediener einträgt, d) die restlichen Felder im Time Sheet automatisch ausfüllt, indem er die entsprechenden Informationen vom Referenzeintrag zieht.

Wer keine zusätzlichen Felder im sowieso schon vollen Eintrag will, läßt sich das von uns stattdessen als PopUp über die API programmieren, das mit einem kleinen Button im Menü aufgerufen wird.

Zeit nach “Mitarbeitergefühl” nachhalten funktioniert besser, wenn sich der Mitarbeiter zuvor bereits der Erfahrung ausgesetzt hat, seine Zeiten über einen gewissen Zeitraum wirklich „mitzustoppen“, das bringt oft einen überraschenden Erkenntnisgewinn. 

Ein Timer mit Start- und Stopp-Taste

Es gibt durchaus gewichtige Argumente dafür, grundsätzlich zur Aufwandserfassung eine Uhr zu starten und zu stoppen, statt die Zeiterfassung dem Wunschdenken und anderen Irrationalitäten zu unterwerfen. Also dann: wie kann das mit nichts als Podio gelingen?

Um “nativ” mit Podio Zeit zu loggen, braucht es am Eintrag, von dem aus der Timer gestartet werden soll, nicht wie oben ein Feld für die Dauer. Stattdessen und statt eines Buttons zur Erzeugung eines fertigen Zeiterfassungsbogens wird ein Button zum Starten und einer zum Stoppen der Zeiterfassung benötigt (es könnte auch ein Start/Stopp-Button sein, und der könnte natürlich auch per Skript als Button oben in die Menüzeile gesetzt werden). Der Startknopf tut fast dasselbe wie beim Zeit nachhalten, bloß daß am durch den Workflow erstellten Bogen zunächst nicht die Dauer, sondern nur der Zeitpunkt des Starts eingetragen wird. Klickt man den Stopp-Button, wird auch der Endzeitpunkt eingetragen, so daß die Dauer berechnet werden kann und damit die Operation abgeschlossen ist.

Wenn ein Time Sheet eine Startzeit hat, aber keine Endzeit, läuft das Logging. Das darf nur bei einem Bogen pro Benutzer der Fall sein! Am Zeiterfassungsbogen muß also mit dem Start ein Wert auf “der Timer läuft gerade” o.ä. gesetzt werden, den der Stop-Button wieder herausnimmt. Läuft ein Timer, darf kein anderer gestartet werden; stattdessen erhält der Benutzer eine Benachrichtigung, welcher Timer gerade läuft. In der Time Sheets-App kann ein vergessener Timer später korrigiert werden.

Zeiterfassungsbögen auswerten

Die Bögen sind in der Time-Sheets-App aufgelistet und können nach Mitarbeiter, Zeitraum (Tag, Woche, Monat), nach Projekt, nach referenziertem Ticket, Sprint, Kostenstelle o.ä. gefiltert und in Ansichten gespeichert werden. Mit Reports können an Ort und Stelle Summen bezogen auf referenzierte Einträge gebildet werden. Mit PREMIUM-Plan lassen sich auch einfache Diagramme erstellen. Man kann erfaßte Aufwände vorher gemachten Schätzungen gegenüberstellen, Abweichungen und zukünftige Richtwerte berechnen.

An verbundenen Apps wie Aktivitäten/Kostenstellen/Abteilungen, Mitarbeiter und Projekt können Zeiten aufsummiert werden — auch z. B. an der Mitarbeiter-App aufgeschlüsselt nach Aktivitäten, aber wie das geht, Thema „Fortgeschrittene Kontierung und Kreuztabellen in Podio“, wäre wieder eins für einen anderen Blogpost …

Zeiterfassung in Workflows integrieren

Vor der Zeiterfassung liegt die Projektplanung, d.h. das Erstellen und Zuweisen der Einträge, an die dann die Zeit getrackt wird. Nach getaner und erfaßter Arbeit könnte es etwa so weitergehen:

• Budgeteinhaltung — wie verhält sich der Projektfortschritt zum Kostenstand und zum am Projekt hinterlegten Budget? Bei Überschreitung von Schwellenwerten kann eine Warn-Meldung ausgelöst werden.
• Freigabeprozeß — kann man dem Kunden die Stunden so in Rechnung stellen? Darf der beauftragte Freelancer die Stunden so abrechnen bzw. man ihm das gutschreiben?
• Rechnungsstellung — ist die Abrechnungsperiode vorbei, bekommt der Freelancer sein Geld; ist der Release draußen, stellt man ihn beim Kunden in Rechnung. Der Status der Zeiterfassungsbögen ändert sich entsprechend, die Summe der noch nicht abgerechneten Stunden ebenfalls.

Wie immer bei Podio: findet sich in einem beliebten Time Tracker ein Feature, das man gern hätte, baut man es einfach in Podio nach — Podio ist vor allem eins: anpassbar.

Nicht nur öffentliche Webseiten und CRM-Systeme wie Hubspot speichern personenbezogene Daten, sondern auch Software, die von außerhalb des Unternehmens gar nicht erreichbar ist und nur von Mitarbeitern des Unternehmens genutzt wird. Dabei kann es sich etwa um Projektmanagement-Software oder das zentrale Unternehmens-ERP-System handeln, aber auch ein simpler kollaborativer Terminkalender reicht schon aus, um in puncto Rechtssicherheit geschäftlicher Online-Tools auf dünnes Eis zu geraten.

Da im Bereich der digitalen Geschäftsprozesse zulasten althergebrachter lokaler Excel-Dateien oder selbstgehosteter Systeme zunehmend Online-Tools in Form von Software as a Service (SaaS) Einzug halten, gewinnen zwei Faktoren an Relevanz:

• in den meisten Bereichen dominieren US-Anbieter oder Anbieter mit einer US-Muttergesellschaft – daher in diesem Beitrag ein Fokus auf die USA; das alles betrifft natürlich andere Nicht-EU-Länder gleichermaßen oder sogar noch mehr!;
• viele EU-Anbieter von SaaS nutzen US-Datenspeicher wie Amazon AWS, Google Cloud oder Microsoft Azure.

Auch in letzterem Fall begibt man sich in eine juristisch ungeklärte Situation, denn aus Sicht des Clarifying Lawful Overseas Use of Data Act (CLOUD Act) ist nicht erheblich, ob ich direkt Kunde eines amerikanischen Unternehmens bin – oder Kunde des Kunden.

Zwar kann ich die Einwilligung meiner Kunden, Lieferanten etc. zur Überlassung ihrer Daten an Unternehmen mit Sitz in den USA, Großbritannien und anderen Nicht-EU-Ländern einholen, aber dies ist mit Aufwand verbunden, und mein Vertrieb wird wenig begeistert sein: Aufklärung über das unzulängliche Schutzniveau ist auch nachträglich einzuholen, d.h. nicht nur für Neukunden, und auch etwa für Leads schon vor der ersten Mail! Zudem ist es ein Eiertanz, nicht auf der anderen Seite gleich wieder gegen die europäische DSGVO zu verstoßen.

Ob per Standardvertragsklauseln (SCC) anbieterspezifisch Rechtssicherheit geschäftlicher Online-Tools gewährleistet werden kann bzw. ob ein US-Unternehmen Anfragen nach dem CLOUD Act, die gegen die DSGVO verstoßen, per se nicht umsetzt und mich notfalls per Gerichtsverfahren schützt (wie z.B. Amazon dies verspricht), ist fraglich bzw. es bleibt ein Risiko. Dieses mag je nach Unternehmen als in Kauf zunehmen erachtet werden, als abzuwägendes Gegenargument oder als absolutes No-Go.

Die Hürden für eine Herausgabe personenbezogener Daten allein auf Grundlage von behördlichen Aufforderungen aus den USA auf Basis des CLOUD Act liegen allerdings hoch: sie ist in der Regel unzulässig, wie der Europäische Datenschutzausschuss (EDSA) im Jahr 2019 zum CLOUD Act festgestellt hat: Nur in ganz besonders gelagerten Ausnahmefällen hält der EDSA die Übermittlung für zulässig, etwa zum Schutz lebenswichtiger Interessen einer betroffenen Person (Art. 6 Abs. 1 lit. d i.V.m. Art. 49 Abs. 1 lit. f DSGVO).

EU-US Privacy Shield

Das EU-US Privacy Shield oder EU-US-Datenschutzschild ist der Versuch, auf politischer Ebene die Angemessenheit des Datenschutzes US-amerikanischer Unternehmen mit Bezug auf europäisches Recht unter bestimmten Bedingungen zu gewährleisten. Jedoch erklärte der Europäische Gerichtshof den Durchführungsbeschluss der EU-Kommission über den Datenschutzschild 2020 für ungültig. Datenschutzrechtlich Verantwortliche können sich demnach bei Datentransfers nach dem EU-US Privacy Shield zertifizierter US-Anbietern nicht mehr auf die Angemessenheit des Datenschutzniveaus gemäß DSGVO berufen, so dass die rechtliche Situation so aussieht wie oben dargestellt.

Es könnte jedoch wieder Bewegung in die Sache kommen: Am 25. März 2022 verkündeten EU-Kommissionspräsidentin Ursula von der Leyen und US-Präsident Joe Biden eine „grundsätzliche Einigung“ über ein neues Privacy Shield. Allerdings wurden in den USA bislang keine Überwachungsgesetze geändert, und der Oberste Gerichtshof der USA räumte jüngst der US-Regierung noch mehr Spielraum bei der Berufung auf „Staatsgeheimnisse“ in Spionagefällen ein. Stand heute können US-Bürger und EU-Bürger eine geheime Überwachung in den USA nur sehr schwer vor dortigen Gerichten anfechten.

Eine verbindliche und die sich in ihren Stoßrichtungen grundsätzlich widersprechenden Regelungen von EU und USA versöhnende Einigung steht noch aus – bzw. kommt vielleicht nie. Speziell für die USA existiert zudem ein nicht unbeträchtliches Politikänderungsrisiko: ein Regierungswechsel könnte kurzfristig zu einer weiteren Verschärfung amerikanischer Eingriffsmöglichkeiten und weniger Lust auf Kooperation mit der EU führen.

So ist die Lage mit den USA – jedoch existieren für einige andere Ländern EU-Angemessenheitsbeschlüsse, die aus Sicht eines Unternehmens, das mit Anbietern aus diesen Ländern zusammenarbeiten möchte, wohl alles in Ordnung sein dürfte. Es handelt sich dabei um  Andorra, Argentien, Kanada (kommerzielle Unternehmen), Faroer, Guernsey, Israel, Isle of Man, Japan, Jersey, Neuseeland, Südkorea, die Schweiz , die Vereinigten Königreiche unter DSGVO und Law Enforcement Directive, und Uruguay.

Ganz unabhängig von der Frage, ob man selbst Daten rechtssicher speichert: möchte man seine Geschäftspartner dem Risiko aussetzen, dass deren Daten wegen eigener Nutzung amerikanischer Software von US-Behörden abgerufen werden können? Wissen die Geschäftspartner überhaupt davon?

Strategische Bedeutung des internationalen Datenschutzrechts für die Digitale Transformation

Wenn man über die kurzfristige Gefahr eines DSGVO-Bußgelds oder eines CLOUD-Act-Fiaskos mit Datenzugriff durch US-Behörden hinaus längerfristig denkt, spielen folgende Überlegungen eine Rolle:

Buy local: ganz auf einen „sauberen“ EU-Anbieter-Stack setzen

Gibt es für meine Anforderungen SaaS von EU-Anbietern, die keine Daten außerhalb der EU speichern? Wie wichtig sind ggf. Abstriche gegenüber einer Lösung mit Drittlands-Anbietern? Wie viel teurer ist ggf. eine reine EU-Strategie?

Kann ich dem Problem grundsätzlich ausweichen, indem ich statt SaaS-Angeboten auf selbstgehostete Software setze? Dies geht zum einen mit klassischer Programmierung und gängigen ERP-Systemen; zum anderen ermöglichen auch viele No-Code- und Low-Code-Anbieter die Installation auf eigenen Servern.

Fußnote: Es geht ja um die Datenspeicherung, nicht um den Hersteller einer Software. Kann ich also einfach amerikanische (oder israelische, indische...) Software benutzen, so lange ich sie in der EU hoste einschließlich Massenspeicher? Hier gibt es die (hypothetische) Möglichkeit einer „Backdoor“ in der Software zu bedenken, wie sie bei diversen amerikanischen Soft- und Hardwarehersteller bekannt, bei chinesischen und russischen Anbietern dringend vermutet, bei EU-Anbietern aber verboten ist.

Kann ich die Migration auf ein rechtssicheres System mit einem ohnehin sinnvollen Schritt der Digitalen Transformation meines Unternehmens verbinden, so dass das Herstellen von Rechtssicherheit in die Rubrik „Sowiesokosten“ fällt?

US-Anbieter trotz rechtlicher Probleme nutzen

Kann mein Unternehmen die rechtlichen Risiken der Non-Compliance einschließlich des Politikänderungsrisikos in Kauf nehmen? Sind die Risiken hinsichtlich Finanzen (z.B. Bußgelder) oder auch Reputation empfindlich, kann gar eine betriebsbedrohende Situation entstehen? Wie groß ist der „Hebel“, d.h. sind denkbare Probleme Einzelfälle oder zahlreich?

Alternativ: kann und will mein Unternehmen den Aufwand betreiben, flächendeckend Vereinbarungen mit Standardvertragsklauseln abzuschließen und nachzuhalten? Monitoring sich verändernder rechtlicher Voraussetzungen pro Anbieter? Die Belastbarkeit dieser Vereinbarungen und Anbieter-Zusicherungen auch stellvertretend für meine Geschäftspartner voraussetzen? Ohne mich darüber mit meinen Geschäftspartnern abzustimmen? Kann und will mein Unternehmen ggf. Geschäftskontakte schon im Lead-Stadium und auch Bestandskunden im Nachhinein mit einem obligatorischen Opt-in bei umfassender Aufklärung über unzureichendes Datenschutzniveau konfrontieren? Wenn hier die Antwort „ja“ lautet, steht der Nutzung von Diensten aus Drittländern nichts entgegen.

Falls ich weiterhin US-Anbieter nutze: Kosten eines evtl. im Nachhinein wegen Datenschutz-Compliance vorgenommenen Wechsels zu reinen EU-Anbietern bedenken

Wie viel werde ich in ein bestehendes oder neu aufzusetzendes Nicht-EU-System in Zukunft investieren, und wie stark wachsen dadurch die Kosten der Migration? Wie hoch müsste die Rückstellung für unterlassene Instandsetzung sein, wie viel „technische Schulden“ häufe ich durch die Unterlassung an?

Wie sehr hemmt das Bewusstsein, ein eventuell nicht rechtssicheres Bestands-System zu nutzen, meinen Digitalisierungsfortschritt, mein Vertrauen in mein Werkzeug?

Fazit

Aus rein juristischer Perspektive kann man sich vermutlich auf die Aussage zurückziehen , daß Rechtssicherheit nur mit einer reinen EU-Strategie zu bekommen ist. Es wird aber sicherlich Unternehmen geben, für die aus strategischer Perspektive das rechtliche Risiko der Arbeit mit US-Tools ohne konsequente Standardvereinbarungen und Opt-in nach der Methode „was soll schon passieren?“ als tolerierbar gesehen werden kann. Wer bei den großen, etablierten Anbietern ist, hofft vielleicht zurecht darauf, dass man nicht Millionen von europäischen Nutzern im Stich lassen wird, siehe die Positionierung von Amazon.

Wer nur wenige Geschäftspartner mit entsprechend intensiverem Austausch hat, wird möglicherweise die Vorteile der freien Auswahl auf dem internationalen Software-Markt höher bewerten als den Nerv-Faktor, mit Tool-Anbietern Standardvereinbarungen abzuschließen und allen seinen Partnern ein explizites Opt-in zuzumuten.

Wer jedoch besonders sensible Daten speichert, wer in dieser Hinsicht empfindliche Kunden oder Lieferanten hat, wer so groß ist, so dass sich Bußgelder und andere negative Rechtsfolgen summieren und eine neue Technik von so vielen genutzt wird, dass die Kosten pro Nutzer gering sind (Skaleneffekt), wer seinen Kunden kein Opt-in zumuten oder sich nicht auf Standardvertragsklauseln verlassen will, wer den Reputations-Schaden eines Bußgeldverfahrens scheut, sollte seine internen Tools genauso DSGVO-konform und frei von Zugriff aus Drittländern halten wie seine öffentliche Web-Präsenz und seinen Online-Shop. Wenn ein Unternehmen das europäische Datenschutz-Niveau als Teil seines Markenversprechens kommuniziert und sich demzufolge die DSGVO voll zueigen macht, gibt es zu „EU only“ (inklusive den Ländern mit EU-Angemessenheitsbeschluß) ohnehin keine Alternative.

Es ist klug, eine Umstellung auf einen DSGVO-konformen Stack für alle digitalen Werkzeuge im Unternehmen mit ohnehin anstehenden Schritten der Digitalen Transformation zu verbinden – sei es, dass die Modernisierung den Anstoß gibt oder das Bedürfnis nach Rechtssicherheit, beides ist ein Fortschritt!

In diesem Artikel wir keine Rechtsberatung geleistet. Rechtliche Sachverhalte werden lediglich allgemein dargestellt. Für die Richtigkeit wird keine Haftung übernommen.

Hier können Sie die Original-Ankündigung lesen: Drupal 7's End-of-Life extended to November 1, 2023 - PSA-2022-02-23

Was ist der Grund für die Verschiebung?

Die Kriterien für den zukünftigen EOL-Termin haben auch eine Rolle für die aktuelle Verschiebung gespielt. So ist das Security-Team zu dem Entschluss gekommen, dass die Verbreitung von Drupal 7 und die Unterstützung in der Community noch so groß ist, dass ein abruptes Ende einen zu großen negativen Einfluss gehabt hätte. Immerhin verwenden nach der letzten Erhebung noch immer über 550.000 Websites weltweit diese Version!

Vor einem Jahr wurde der EOL-Termin bereits um ein Jahr verschoben. Damals war Corona der Grund. Den Unternehmen und Teams sollte mehr Zeit für die Umstellung gegeben werden, die deren Arbeit aufgrund der pandemischen Situation teilweise stark eingeschränkt war. Diesem Umstand wollte man mit der damaligen Verschiebung Rechnung tragen.

Wie sich jetzt aber herausgestellt hat, haben viele auch dieses zusätzliche Jahr nicht für die Umstellung genutzt.

Was bedeutet das für mein Drupal-7-Projekt?

Wenn Sie noch ein aktives Drupal 7 Projekt betreuen, können Sie zuerst einmal aufatmen. Sie haben mindestens ein zusätzliches Jahr Zeit, auf Drupal 9 oder eine Alternative umzusteigen. Wie bislang auch, erhalten Sie von der Drupal Community regelmäßige Updates und Patches gegen Sicherheitslücken.

Immerhin hätten Sie ansonsten nur bis Ende November 2022 Zeit gehabt, mit Ihrem Projekt in einen Status ohne Updates und Sicherheitspatches zu rutschen. Mehr Informationen zu Bedeutung und Auswirkungen des End-of-Life können Sie in diesem Beitrag nachlesen: Drupal 7 EOL: Was bedeutet das?

Was sollten Sie jetzt tun?

Unser grundsätzlicher Rat ist: „Aufgeschoben ist nicht aufgehoben“. Wenn Sie sich bereits mit der Umstellung auf Drupal 9 beschäftigt haben, sollten Sie dranbleiben. Immerhin kommt die neue Version auch mit vielen zusätzlichen und verbesserten Möglichkeiten daher – und täglich kommen in Drupal 9 (bzw. auf Sicht in Drupal 10) weitere Verbesserungen hinzu. Sie haben jetzt den Vorteil, dass Sie die Migration etwas entspannter angehen können, da Sie nicht mehr nur ein Dreivierteljahr Zeit haben.

Wenn Sie jedoch das Projekt jetzt erst einmal auf Eis legen, werden Sie irgendwann vor der gleichen Drucksituation stehen. Denn Fakt ist: eines Tages wird der Support für Drupal 7 enden.

Zudem muss berücksichtigt werden, dass die Drupal Association ihre nächste Entscheidung zu dem Support-Ende von Drupal 7 im Juli 2023 treffen wird. Sollte dann verkündet werden, dass es bei dem Support-Ende Anfang November 2023 bleibt, verbleiben nur noch 4 Monate, um die Umstellung auf Drupal 9 oder eine Alternative durchzuführen.

Wie aktiv ist die Entwicklung von Drupal 7 noch?

Bereits seit einiger Zeit beobachten wir, dass es keine aktive Weiterentwicklung mehr gibt. Dies betrifft sowohl Drupal 7 an sich (den „Core“) als auch den Modulen. Die Maintainer machen hier zu einem Großteil nur noch das Nötigste, eine Weiterentwicklung findet nicht mehr statt. Im Endeffekt wird seitens der Maintainer und Drupal Community nur noch der Erhalt des Status Quo betrieben.

Dies ist insbesondere daran festzumachen, wie häufig Updates veröffentlicht werden:

• Während es bei Drupal 7 auch nach Wochen nur ein, zwei Updates von Modulen vorhanden sind (und dies sind meist Sicherheitsupdates),
• gibt es bei Drupal 9 Installationen in selben Zeitraum eine ganze Reihe an neuen Versionen mit Fehlerbehebungen, Verbesserungen und neuen Möglichkeiten.

Dieser Unterschied zwischen Verwaltung des aktuellen Zustands und einer aktiven Weiterentwicklung ist bereits sehr deutlich zu spüren.

Vor dem Drupal Ökosystem macht dieser Umstand auch keinen Halt: Immer mehr Entwickler wenden sich von Drupal 7 ab und fokussieren sich ausschließlich auf Drupal 9 Projekte. Demzufolge wird es in Zukunft immer schwieriger (und damit teurer) werden, auf externe Drupal 7 Expertise zurückzugreifen.

Sie möchten in Zukunft Informationen zu allen Neuerungen zum Thema Drupal 7 und dem End-of-Life erhalten? Dann tragen Sie sich doch jetzt in unseren kostenlosen Verteiler ein! Als Bonus erhalten Sie unser White Paper zur Drupal-9-Migration direkt in Ihr Postfach.

Drupal 7 White Paper erhalten

Lesezeit: ca. 14 Minuten

Der Industriestandard „Tabellenkalkulation“

Bilder: Capterra. Nutzerstudie: CRM Software Trends 2019 in deutschen KMU; Nutzerstudie 2018: Wie Projektmanagement-Software in Deutschland genutzt wird

Excel, OpenOffice und Google Spreadsheets allüberall

Ich muß hier sicherlich niemandem Funktionsweise und Vorzüge einer Tabellenkalkulation näherbringen, wie sie 1979 mit VisiCalc das Licht der Welt erblickte, sich mit Lotus und Quattro Pro weiterentwickelte und schließlich mit Microsoft Excel als Killer-App in allen Arten von Unternehmen allgegenwärtig wurde. Mit OpenOffice liegt eine starke Open-Source-Alternative vor, und Google Spreadsheets brachte das Konzept in den Web-Browser, wohin OpenOffice mit Collabora und Microsoft mit 365 folgten.

Tabellarische Daten mit einfachen Formeln ohne Programmierkenntnisse berechnen zu können, erst recht, wenn man noch Diagramme, Makros und Visual-Basic-Programmierung hinzunimmt, macht die Tabellenkalkulation zu einem mächtigen und universellen Werkzeug mit niedriger Eintrittsbarriere. Scheinbar alles, was mit Daten zu tun hat, läßt sich in der Tabellenkalkulation so einfach und schnell wie möglich umsetzen.

Einsatzbereiche der Tabellenkalkulation

Probleme, die unzählige Unternehmen mit Excel & Co. lösen:

• Daten speichern – Adressen, Preise, Mengen, Datums- und Zeitangaben, Informationen in Textform und vieles mehr, oft in Form von Datensätzen, d.h. einem festen Schema in Zeilen mit jeweils Preis (Dezimalzahl) eines Artikels (Name als Text) zu einem bestimmten Zeitpunkt (Datum).
• Daten analysieren – auf der Grundlage in Tabellen eingetragener Daten Berechnungen anstellen – mit Formeln Zahlen in alle erdenklichen Berechnungen einfließen lassen.
• Daten visualisieren – Rohdaten oder berechnete Zahlen lassen sich komfortabel graphisch darstellen.
• Geschäftsprozesse abbilden – nicht nur Planungsrechnungen und Nachkalkulation, sondern auch ERP, Projektmanagement, Personalwesen: die Erkenntnis, daß Datensatz-Listen mit Zahlen, Datumsangaben und Text sich zur Abbildung praktisch aller Prozesse im Unternehmen eignen, führt dazu, daß dies auch getan wird. Sind nicht Kunden- und Mitarbeiterverzeichnisse, Aufgaben eines Teams, Artikel im Sortiment und deren Lagerbestände allesamt tabellarisch gut darstellbar? Und wenn ich auch noch jede erdenkliche Berechnung damit anstellen kann: wieso nicht dem ganzen Betrieb ein digitales Abbild in Excel geben?

Resultat: Daten werden in etlichen kreuz und quer verknüpften Excel-Tabellen gespeichert, verwaltet und organisiert. Automatisierung wird durch Makros und Visual Basic implementiert. Laut Forrester Q2 2021 Global Digital Process Automation Vision Survey ist „die brutale Realität“, daß es in praktisch allen Unternehmen noch Geschäftsprozesse per „Electronic manual routing“ gibt, d.h. mit geteilten Excel-Dateien, Email etc., die zwar in elektronischer Form erfolgen, aber nicht im engeren Sinne digitalisiert sind. Nur 1% der befragten Unternehmen hatten angegeben, dies gar nicht mehr zu tun, knapp die Hälfte, daß in ihrem Unternehmen „viele“ Prozesse noch auf Excel, Email & Co. beruhen, und ein Viertel, daß es gar „die meisten“ Prozesse sind.

Schwachpunkte der Tabellenkalkulation

Hier lauern Probleme, wenn Geschäftsprozesse mit Excel abgebildet werden sollen:

• Verständlichkeit der Formeln – der Verzicht auf Absätze und gar auf Leerzeichen in Kombination mit vielen Zellbezügen (bei denen man erst nachsehen muß, was in der Zelle überhaupt steht) und nur wenigen fixen Namensbezügen (bei denen man, wie in der Programmierung eigentlich Standard, eine Information über den Inhalt in die Namensgebung einfließen läßt) macht die Formeln schwer lesbar und schwer wartbar.
• Schutz der Programmierungsschicht – es ist ja gerade die Stärke von Excel, daß man einfach in eine Zelle klicken kann und eine Formel ändern. Dies ermutigt jedoch schlechte Programmierpraxis und eröffnet Fehlerpotential, indem ein u.U. versehentlicher Klick in ein Formelfeld zu Fehlern in einer einzigen Zelle führen kann, während alle anderen noch korrekt sind, ohne daß der Fehler auffällt. Dasselbe passiert, wenn Formeln herunterkopiert werden, aber nicht weit genug. D.h. es kann inkonsistente Formeln in einer einheitlich aussehenden Spalte geben, ohne daß man dies bemerkt, was schlimm ist, wenn Formeln ab Zeile x einfach fehlen, aber noch schlimmer, wenn korrigierte Formeln im Zuge der Entwicklung oder des Bug-Fixing nur bis Zeile x kopiert sind, aber dann vergessen wird, abschließend die ganze Spalte zu aktualisieren.
• DRY: Don't repeat yourself – in der zentralen Excel-Praxis, Formeln in einer Spalte herunterzukopieren, manifestiert sich ein Verstoß gegen dieses Grundprinzip der Programmierung. Die Formel, mit der z.B. die Summe zweier Spalten errechnet wird, steht in jeder Zelle der Ergebniszeile erneut, lediglich mit um 1 erhöhten Zeilen-Indizes. Man wiederholt sich am laufenden Band. Die zahlreichen Zellbezüge führen dazu, daß ein mal fertiggestellte Rechenwege nicht mehr angetastet werden, auch wenn man nachher merkt, daß es auch besser gegangen wäre. Änderungen sind durch die Verteilung einer Berechnung auf viele Zellen wesentlich aufwendiger sind als die Änderung einer Funktion, die nur an einer Stelle definiert ist und x-fach benutzt wird.
• Kopplung von Berechnung und Formatierung – der Widerstand, ein mal Programmiertes einer grundlegenden Revision zu unterziehen, wird noch dadurch verstärkt, daß ja zugleich die Formatierung an den Zellen hängt. Auch dies ist ja eine zugleich eine Stärke von Excel, jedenfalls für eine aus der Hüfte geschossene Ad-hoc-Berechnung. Für ein planvoll angelegtes und langfristig weiterzuentwickelndes System ist das ein Scheingewinn. Schnell geschrieben, langsam geändert. Provisorisch hält am längsten.
• Information in einem System – die Verteilung von Daten auf einzelne Dateien statt der Ablage in einem allumfassenden, konsistenten und verbundenen System stellt den Nutzer vor die Herausforderung, gesuchte Daten zu finden. Geschickt eingerichtet, kann dies durch ein streng einzuhaltendes Schema von Dateiordnern und Dateinamenskonventionen erleichtert werden. Die Herausforderung wächst, wenn die Datei-Zuständigkeit auf mehrere Benutzer oder gar auf verschiedene lokale Rechner/Ordnerstrukturen/GDrive-Konten verstreut ist. Die zersplitterten Informationen manuell zu zusammenzuführen, ggf. turnusgemäß, macht viel Arbeit und ist fehleranfällig. Die zersplitterten Informationen durch dateiübergreifend verknüpfte Formeln zusammenzuführen ist auch bei strenger Disziplin aller Beteiligten (Dateien nicht verschieben oder umbenennen! Zellbezüge nicht verändern!) eine wackelige Angelegenheit.
• Mehrbenutzerfähigkeit – bearbeitet jemand eine Tabellendatei auf seinem Rechner, und jemand anderes tut das gleichzeitig auch, entstehen abweichende Versionen. Das paßt nicht mehr mit dem heutigen Arbeitsstil zusammen: Mitarbeiter sollen gemeinsam an denselben Daten arbeiten, und Benutzer sollen von überall auf die Softwarelösung zugreifen können. Dieses Problem wird durch Online-Spreadsheets aus dem Weg geräumt, aber auch hier sehen alle Nutzer immer alle Daten: man kann nicht Nutzern verschiedener Rollen nur die Daten zeigen, die sie gerade benötigen.
• Dokumentation – Änderungen überschreiben schlicht den vorherigen Stand, so daß die vorherige Version verloren ist, wenn niemand mehr eine Kopie hat. Dieses Problem adressiert z.B. Google Spreadsheets mit seiner Versionsgeschichte. Doch auch hier gibt es durch das Fehlen von Rollen kein Protokoll von Änderungen pro Benutzer. Nachvollziehbarkeit, Transparenz und Revidierbarkeit sind jedoch für viele Geschäftsprozesse eine wichtige Anforderung.
• Parallelprozesse – dieselbe komplexe Berechnung für viele analoge Anwendungsfälle: Datei klonen? Dies resultiert in Versionschaos, und jede Verbesserung und jeder Bugfix muß in jeder einzelnen Datei (oder gar Set von Dateien) manuell eingepflegt werden. Die Alternative, eine gigantische Datei für alle zu nutzen, stößt nicht nur wegen der Performance, sondern auch wegen fehlender Mehrbenutzerfähigkeit schnell an Grenzen.
• Performance – je größer die Datenmenge, um so langsamer wird alles. Diesem Problem läßt sich auch mit einem schnelleren Rechner nicht beikommen, denn bauartbedingt lädt Excel die gesamte Datei und damit den gesamten Datenbestand in den Hauptspeicher (während ein Datenbanksystem immer nur die unmittelbar benötigten Daten lädt, siehe unten).
• Skalierbarkeit – nicht nur große Datenmengen begrenzen das Wachstum, sondern auch Komplexität. Diese läßt sich wegen der „freien“ Verknüpfung durch Formeln, die in Zellen „versteckt“ sind, d.h. nur sichtbar, wenn man diese direkt anklickt, und die daher nur schwer und ad hoc testbar sind, wesentlich schlechter beherrschen als mit Verknüpfungen, die einem abstrakten Schema folgen, und einer vom Datenmodell strikt getrennten Geschäftslogik. Zugegeben: wer sehr diszipliniert ist und auf hohem Abstraktionsniveau arbeitet, kann das mit „seinem“ Excel auch schaffen. Gut merken sollte man sich aber, daß eine .xlsx-Datei maximal 1.048.576 Zeilen und 16.384 Spalten haben kann – sonst erlebt man vielleicht so etwas: Excel: Why using Microsoft's tool caused Covid-19 results to be lost.
• Sicherheit – Tabellendateien sind ein Sicherheitsrisiko: sie sind schnell mal aus Versehen an jemanden vermailt, für dessen Augen sie nicht gedacht waren. „Reply to all“. Ein Link zu einer Tabelle in der Cloud erfordert immer noch einen Login, ggf. mit Zwei-Faktor-Authentifizierung.
• Qualifikation der „Excel-Programmierer“ – gerade weil die Tabellenkalkulation so eine geringe Einstiegshürde hat und jeder einfach loslegen kann, laborieren viele Sheets, die tragende Säulen der Datenhaltung und Prozesse in Unternehmen sind, auf bedenklichem Niveau.

Kurzum: Tabellenkalkulationen sind schnell geschrieben, aber je mehr Daten, Benutzer, Parallelprozesse, Dokumentations- und Sicherheits-Anforderungen, vor allem je mehr Komplexität und je mehr Bugs hinzukommen, desto fragiler und wartungsintensiver wird das Ganze. Aber deswegen den Mitarbeitern ihre heiligen Excel-Tabellen wegnehmen?

„Unternehmenskritische Daten in Excel zu halten und unternehmenskritische Prozesse in Excel ablaufen zu lassen ist wie eine OP, während der der Patient ganz normal weiterarbeitet. Als Dauerzustand.“

Die Alternative „Relationale Datenbank“

Eine Datenbank, kurz DB, kann (große) Datenmengen effizient, widerspruchsfrei und dauerhaft speichern. Wie im vorangegangenen Abschnitt deutlich geworden ist, verfügt die Tabellenkalkulation nicht über die Mittel, widerspruchsfreie Daten zu garantieren und ist nur bei kleinen Datenmengen effizient. „Echte“ Datenbanksysteme lösen diese Probleme.

Dies sind, grob gesagt, die Einschränkungen einer Datenbank im Vergleich zu einer Tabellenkalkulation:

• Es ist „nur noch“ eine Datenbank – Jede Spalte hat einen Namen und enthält nur Daten desselben, für die jeweilige Spalte festgelegten Datentyps (nur Datum oder Ganzzahl oder...), und das wird vorab definiert. Also nichts mit mal eben eine Nebenrechnung im Spreadsheet machen oder im Tabellenkopf für den Ausdruck Meta-Informationen eintragen. In der ersten Zeile befinden sich die Spaltenköpfe, keine Ausnahme möglich.
• Erst abfragen, dann rechnen, visualisieren etc. – bevor man eine Berechnung durchführen kann, müssen die Daten dafür erst aus der DB abgefragt werden. Auch deshalb nicht mal eben eine Nebenrechnung (es sei denn, man spricht fließend SQL). Noch weniger als Berechnungen gehört das Anzeigen von Daten in Diagrammen zum Leistungsumfang einer Datenbank!

Dies sind demgegenüber die Fähigkeiten, die die Datenbank der Tabellenkalkulation voraus hat:

• Relationen – dieses Feature ist so wichtig, daß es namensgebend für den etablierten Standard von Datenbanksystemen ist. Eine Tabellenspalte einer DB kann eine Relation, eine Beziehung, eine Verbindung, eine Verknüpfung, einen „Schlüssel“ zu Einträgen einer anderen Tabelle enthalten. Wenn man bei einer Bestellung den Kunden auswählt, trägt man nicht wie in der Tabellenkalkulation schlicht den Namen des Kunden ein, sondern man wählt den passenden Eintrag in der Kundendatenbank aus. Dadurch gibt es kein Vertippen oder abweichende Schreibweisen mehr. Zudem können bei Datenbankabfragen aus beiden Richtungen auch Informationen verbundener Einträge mit ausgelesen werden, also etwa die Kunden-Postleitzahlen aller Bestellungen oder alle Bestellungen eines Kunden. So lassen sich die Daten hervorragend strukturieren. Das Excel/Spreadsheet-Problem der Zersplitterung von Information ist auf äußerst systematische Weise gelöst. In Summe bilden die Tabellen mit ihren Relationen das Datenmodell, auf dem die Unternehmensprozesse ablaufen – dieses zu analysieren, oder überhaupt einmal hinzuschreiben, und bei der Gelegenheit zu verbessern ist allein Grund genug, eine DB einzuführen!
• Saubere Trennung zwischen Datenspeicherung und Anwendung – die Flexibilität von Excel ist für nach einem festen Schema strukturierte Daten und wiederholt ablaufende Geschäftsprozesse, für die die Einhaltung von Standards wichtig ist, eher ein Nachteil. Eine DB wird abgefragt, und dann werden diese Daten in die Geschäftslogik eingespeist, um das Ergebnis schließlich wieder in die DB abzulegen, und an jeder dieser Schnittstellen können Eingaben und Ergebnisse validiert werden und Compliance gesichert. Eine Berechnung wird für alle Datensätze identisch ausgeführt, garantiert! Das DRY-Prinzip („Don't repeat yourself“) kann eingehalten werden. Hier zahlt sich auch der eventuell höhere Aufwand beim Aufbau des Systems aus: statt der Verquickung von Datenspeicherung, Berechnung und sogar Formatierung in der Tabellenkalkulation kann hier an jeder „Schicht“ separat gearbeitet werden. Modularisierung.
  
• Verständlichkeit der Programmierung – auch wenn man hier spontan widersprechen möche – Excel-Formeln sind doch einfach, aber eine Programmiersprache ist kompliziert! –, ist doch das obige Beispiel
• Datentypen – die erste Einschränkung „nur noch DB“, der gemäß man in einer Spalte nur Daten eines vorher definierten Typs eintragen kann, ist ein wichtiges zur Datenkonsistenz beitragendes Leistungsmerkmal: in eine Datumsspalte können nur gültige Datumswerte eingetragen werden; andere Datentypen wie Text oder eine Fließkomma-Zahl werden nicht akzeptiert.
• Abfragen – oben schon als zweite Einschränkung vorgestellt, sind die Abfragen zugleich ein mächtiges Werkzeug. Sie sind nicht nur die Grundlage dafür, daß wesentlich größere Datenmengen mit sehr guter Performance bearbeitet werden können, denn es werden eben nur die benötigten Daten geladen. Mit der Datenbankabfrage oder „query“ kann bereits all das sehr konzise geleistet werden, was man in der Tabellenkalkulation mit Filtern, Pivot-Tabellen, XVERWEIS (früher SVERWEIS) und INDEX unter Beugung und Dehnung dessen, wofür Excel eigentlich mal gedacht war, auf schwer nachvollziehbare und schwer wartbare Weise hinbastelt.
• Redundanzfreiheit – wenn eine Kundennummer oder eine Adresse nur ein mal vorkommen kann, setzt man das entsprechende Feld auf „unique“, und damit ist es nicht mehr möglich, ein Duplikat anzulegen (es sei denn mit unterschiedlichen Schreibweisen...).
• Versionen und Verlaufsdokumentation – alle modernen DB-Systeme eignen sich für automatisierte Backups, ermöglichen das Zurückspielen alter Datenstände, auch in Teilen, und eine Verlaufsdokumentation besteht letztlich nur aus weiteren Tabellen, in denen Änderungen protokolliert werden, d.h. ist gut machbar.

Bis vor nicht allzu langer Zeit war, wer eine relationale DB wollte, vor die Wahl zwischen einer lokalen Installation z.B. von Microsoft Access (über dessen gravierende Schwächen bezüglich Anpassbarkeit, Mehrnutzerfähigkeit und Zugriff von extern oder gar mobil wir hier gnadenhalber schweigen wollen) oder dem aufwendigen Betrieb eines Webservers und der Entwicklung einer auf diese zugreifenden Anwendungssoftware gestellt. Die Lage hat sich mittlerweile deutlich gebessert, wie im folgenden Abschnitt offenbar wird.

No-Code/Low-Code-Datenbank-Generator in der Cloud

Es ist mittlerweile möglich, webbasierte Datenbank-Apps mit einem Datenbank-Generator bzw. DB-Builder zu erstellen. Diese werden in der Regel als Software-as-a-Service (SaaS) in der Cloud bereitgestellt. Mit solchen DB-zentrierten App-Buildern geht das, wenn man die im Vergleich zu Excel auch nicht heftigere Lernkurve hinter sich gebracht hat, durchaus ähnlich schnell wie eine Entwicklung mit Excel! In der Konzeption etwas anspruchsvoller, Stichwort „Datenmodell“, aber durch die „erzwungene Stringenz“ hinterher leichter erweiter- und wartbar.

Wie in einem Website-Builder, bloß nicht für Layout-Elemente, sondern eben für Datenstrukturen: in No-Code-Manier werden per Drag & Drop Datenspalten hinzugefügt, sei es Text-, Zahlen-, Datums-, und sonstige Datenfelder. Unter den Feldtypen gibt es zwei besondere: Relations- und Berechnungsfelder. Fügt man ein Relationsfeld hinzu, kommt die Frage, mit welcher anderen Datentabelle. Man wählt eine aus, und fertig ist die Verbindung! Fügt man ein Berechnungsfeld hinzu, kann darin mit Formeln gearbeitet werden, das fällt dann unter das Stichwort „Low-Code“. 

Mehr dazu: unser White-Paper Digitale Geschäftsprozesse mit No Code, Low Code, Pro Code

Dies sind die Vorteile, die sich bei einer Cloud-DB im Vergleich zu Excel ergeben:

• Schutz der Programmierungsschicht – die meisten DB-Builder haben eine Benutzeroberfläche für die Anwendung und eine andere Benutzeroberfläche für die Einrichtung, also für die No-Code- und Low-Code-Programmierung. Der Wechsel ist meist deutlich markiert und in der Regel auf bestimmte Benutzer(gruppen) eingeschränkt. Andere DB-Builder verfolgen hier eher einen Excel-Ansatz einer einheitlichen Benutzeroberfläche. Aber alle sind natürlich dem Prinzip treu, daß eine Spalte einen Titel und einen Datentyp hat, der sich im Verlauf der Tabelle nicht ändern kann! Das allein ist ein die Konsistenz wesentlich absicherndes Merkmal.
• Mehrbenutzerfähigkeit – dies ist, wenig überraschend, ein zentrales Leistungsmerkmal aller Cloud-Lösungen: gemeinsam an denselben Daten zu arbeiten, ob am Rechner oder mobil, ohne Sorge haben zu müssen, etwas „kaputtzumachen“, ist Standard. Das Konzept einer gefilterten Ansicht, das auch sehr verbreitet ist, ermöglicht es, Nutzern verschiedener Rollen nur die Daten zu zeigen, die sie gerade benötigen.
• Dokumentation – je mehr ein Anbieter in Richtung KMU oder gar Industrie ausgerichtet ist, um so mehr sind Änderungen inklusive „Täter“ protokolliert.
• Parallelprozesse – dieses Problem stellt sich bei Verwendung einer relationalen Datenbank systembedingt nicht; Werte werden einzeln überschrieben. Wer zuletzt schreibt, bleibt.
• Performance, Skalierbarkeit – der Vorteil, nur die Daten auszulesen, mit denen man arbeiten möchte, relativiert sich durch das Online-Merkmal, denn so schnell der Lesevorgang aus der DB auch gehen mag, die Daten müssen ja immer noch über das Netz übermittelt werden! Dieses Manko schlägt jedoch nur zu, wenn man große Mengen roher Daten tatsächlich auf dem Bildschirm sehen möchte, nicht jedoch für Berechnungen – denn die finden ja in der Cloud des Anbieters statt, und die kann sehr schnell sein.
• Sicherheit – alle Anbieter verlangen einen Login, viele ermöglichen Zweifaktor-Authentifizierung, so daß dort ein Standard vorgelegt wird, den man mit Dateien auf lokalen Rechnern nur schwer wird erreichen können (Excel-Fans entgegnen hier, daß eine Datei auf einem lokalen Rechner doch sicherer sei als ein öffentlicher Server, aber hier gebe ich zurück, daß das größte Sicherheitsrisiko bei Dateien nicht technischer Natur ist, sondern der Mensch, der die Datei mit anderen teilt). Erwähnenswert ist an dieser Stelle sicherlich, daß einige namhafte Anbieter ihren Sitz im EU-Ausland haben. Bei solchen Anbietern ist z.B. die DSGVO-Konformität zu prüfen und zu überlegen, ob es für das eigenen Unternehmen ein Problem darstellen könnte, daß die jeweiligen Landesgesetze (USA!) dem Staat dort viel weitreichendere Möglichkeiten des Zugriffs geben als hierzulande.
• Triggern von Aktionen – hier kommt ein Punkt hinzu, den eine reine Datenbank nicht abdeckt (d.h. in der Anwendungs-Schicht eigens zu programmieren wäre), aber der in den meisten Cloud-Datenbanken großen Raum einnimmt: Benutzereingaben führen nicht nur, wie in der Tabellenkalkulation, zur Neuberechnung von Werten in anderen Zellen, sondern können auch einen Ablauf anstoßen. Dies kann z.B. die Erstellung einer Aufgabe sein, etwa durch Klick auf einen Button oder das Erreichen eines Wiedervorlagedatums.
• Schnittstelle/API – während genau wie Cloud-Datenbanken auch Cloud-Spreadsheets regelmäßig über eine Webschnittstelle verfügen (mit [Microsoft Graph](https://developer.microsoft.com/de-de/graph) auch Office 365), ist die Lage bei lokalen Excel-Dateien etwas unübersichtlicher: mit mit Power Query kann Excel Daten von externen APIs konsumieren, z.B. Wetterdaten von openweathermap.org oder Daten des eigenen Online-Shops. Aber Daten vollautomatisch aus lokalem Excel herauszubekommen, ist nicht trivial. Anbieter wie xlwings bauen hier Brücken, aber die Eleganz und Robustheit einer für Datenaustausch ausgelegten Lösung wird man wohl kaum erreichen.
• Künstliche Intelligenz, Maschinelles Lernen – ähnlich wie beim Thema API gibt es hier seit kurzem z.B. in Form des Excel-Add-ins [Azure Machine Learning](https://appsource.microsoft.com/en/product/office/WA104379638?tab=Overview) und schon länger bei Google Spreadsheet per Verbindung mit dem reichhaltigen und weltweit führenden Ökosystem von Cloud-Apps zu KI durchaus Möglichkeiten. Viele Cloud-DBen müßte man über API an KI-Dienste anbinden, was eher mehr Aufwand macht als bei Excel & Co. Jedoch haben einige Cloud-DB-Builder das Thema im Fokus und bieten hier einen deutlich leichteren Einstieg.

Kurzum: die neuen Tools nehmen dem Aufbau eines Datenmodells einer relationalen Datenbank mit No-Code den Schrecken, sie ersetzen den Zellbezugs- und Berechnungsteil von Excel-Formeln durch besser geschützten Low-Code (der übrigens regelmäßig viel besser lesbar ist als die verschachtelten Excel-Formeln!), und machen das Ganze als Web-App mit fertiger Benutzeroberfläche verfügbar.

Das alles lernt man nicht über Nacht, aber es ist keinesfalls schwieriger als Excel! Man wird bei der architektonischen Konzeption auf professionelle Unterstützung nicht verzichten wollen, aber eine leistungsfähige Excel-Lösung ist in dieser Hinsicht nicht weniger anspruchsvoll: es kommt einem nur später in den Sinn, daß man dilettiert an einer Stelle, an der Qualität wichtig wäre. Bei komplexeren Anforderungen stößt man mit Excel früher als bei guten DB-Buildern an Grenzen, die man allein nicht überwinden kann.

Welche DB-Builder-App ist die richtige?

Die Phase, in der wenige Pioniere das Thema angehen, ist mittlerweile übergegangen in eine, in der sich einzelne Paradigmen herauskristallisieren und mehrere Anbieter ihr Produkt ins Rennen schicken. Es würde den Rahmen dieses ohnehin schon sehr, sehr langen Artikels sprengen, hier einen Marktüberblick zu versuchen; dazu später mehr!

Hier also lediglich eine grobe Einteilung. Alle relevanten Produkte fallen in die Klasse der Low Code Applications Plattform (LCAP), also SaaS, die über grundlegende Funktionen zum Entwurf webbasierter Oberflächen sowie über Werkzeuge zum Datenmanagement verfügt.

Nur Listenansicht

Die klassische Ansicht für Datenbank-Daten ist dieselbe wie die in Excel: eine Liste in Form einer Tabelle mit den Datensätzen in Zeilen und den Feldern in Spalten. Anbieter wie Airtable und Rows, aber auch etwa die Datenbank-Funktion von Notion, setzen auf Einfachheit und bauen die gesamte App-Nutzung um die Listenansicht herum auf.

Verschiedene Ansichten im Standard-Layout (Liste, Formular, Karten, Kanban...)

Die meisten Anbieter nutzen für ihre Cloud-App auch andere Ansichten, wie sie, ermuntert durch die Trennung der Datenabfrage von der Datendarstellung, auch in der Vor-Cloud-Zeit bereits in datenbankbasierter Individualsoftware Gang und Gäbe sind. Einschlägige Anbieter sind, ohne Anspruch auf Vollständigkeit und in alphabetischer Reihenfolge, 4D, Caspio, dashjoin, datenbanken24, Honeycode (amazon), kintone, Knack, Ninox, APEX (Oracle), Podio (Citrix), Quickbase, Scopeland, SeaTable, Smartsheet, Zoho Creator. Im nächsten Abschnitt „App-Builder“ tauchen weitere auf, denen keine DB-Features fehlen, sondern die noch andere gewichtige Features haben, so daß der DB-Builder nicht mehr das zentrale Feature ist.

Google AppSheet nimmt einen Sonderstatus ein: die Daten und Kalkulation können in Spreadsheets oder Excel 365 liegen; dann fällt jedoch die „disziplinierende“ Wirkung der Datenbank weg, also die technisch erzwungene Regelkonformität. Doch AppSheet kann auch strukturierte Daten aus einer SQL-Datenbank verarbeiten – die Datenbankstruktur muß jedoch dort traditionell, ohne No-Code, definiert werden, und aus SmartSheet. Das heißt: AppSheet selbst ist gar kein DB-Builder. Zudem sind die Low-Code-Möglichkeiten begrenzt, sofern man nicht auch noch Google Apps Script mit in den Werkzeugkasten nimmt.

Zusätzlich mit frei gestaltbarer Benutzeroberfläche

„Vollwertige“ App-Builder im engeren Sinne Plattformen wie Bubble.io, die auf Startups zielen, die mit einer Web-App an den Markt gehen wollen, und solche wie Outsystems, Appian und Mendix (Siemens), die vor allem die Industrie targetieren, d.h. von einer sehr hohen Nutzerzahl und großen Entwicklungs-Budgets ausgehen, geben sich mit einer nicht gemäß Webdesign-Vorstellungen frei gestaltbaren Oberfläche für den Endbenutzer zufrieden. Für diese Zielgruppen reicht ein Standard-Frontend mit vorgegebenen Bausteinen, die hin- und hergeschoben und höchstens noch in ihrer Größe angepaßt werden können, nicht aus.

Jeder App-Builder enthält technisch gesehen einen Datenbank-Builder, denn eine App ohne Daten wäre nutzlos, und die Daten wollen strukturiert abgelegt werden – und zwar gemäß eines den Funktionen der App dienenden Datenmodells. Demnach ist ein anpassbares Datenmodell auch hier Pflicht-Feature. Diese App-Builder sind dann jedoch nicht mehr „datenzentriert“, d.h. die DB wird zu einer Schicht neben anderen zu gestaltenden Schichten. Komfort der DB-Einrichtung und freie Konfigurierbarkeit des Datenmodells rücken ggf. in den Hintergrund, wenn auch viele der Apps in dieser Kategorie den DB-zentrierten Apps in nichts nachstehen. Jedoch kann man nicht nur, man muß die Benutzeroberfläche gestalten. Für viele interne Geschäftsanwendungen ist das überflüssige Arbeit.

Abgrenzung: dies sind keine Datenbank-Generatoren

Website-Builder

Der Vollständigkeit seien hier auch noch die Website-Builder wie Webflow, Wix, Jimdo, Squarespace etc. eingeordnet: auch diese verfügen natürlich über eine DB, aber hier ist, mindestens bei denen für Endverbraucher, gar kein „Custom Data Model“ möglich, d.h. es gibt keinen DB-Builder, sondern ein vorgegebenes, eben ein für Standard-Webseiten für optimal befundenes, Datenmodell. Hier liegt die Betonung auf der der Anpaßbarkeit der Benutzeroberfläche. Wix & Co. machen es dem Bediener möglichst einfach; Webflow & Co. sind anspruchsvoller in der Bedienung und betonen die Möglichkeit, Webdesign pixelgenau umzusetzen.

Cloud-ERP, -CRM, -PM, -HR

Nicht zu verwechseln: ein DB-Builder ist, genau wie die Tabellenkalkulation, völlig offen für alle erdenklichen Datenmodelle und Geschäftsprozesse, während Cloud-Anbieter von Standardsoftware für Unternehmen keine frei konfigurierbare Plattformen anbieten. Vielmehr ist in Cloud-Software für ERP (SAP S/4HANA, Oracle NetSuite, Bitrix24) , CRM (Salesforce, Hubspot, Mailchimp), PM (Trello, Basecamp, JIRA, Asana) das Datenmodell und die Abläufe durch den Softwarehersteller weitestgehend vorgegeben. Mit einem Datenbank-Generator erstellen Sie hingegen, genau wie mit der Tabellenkalkulation, Ihre eigene Individualsoftware, die genau auf Ihr Unternehmen zugeschnitten ist.

Database as a Service (DBaaS)

Amazon AWS, Google Cloud SQL, Microsoft Azure Cloud und ähnliche Dienste bieten eine Cloud-Datenbank – aber keinen Datenbank-Builder! Hier wird eine „nackte“ MySQL-, PostgreSQL- oder sonstige gängige Datenbank als Cloud-Lösung angeboten, d.h. hier wird lediglich die Cloud-Infrastruktur genutzt, statt die selbe DB auf einem eigenen Server einzurichten und zu hosten.

Fazit / Executive Summary

Gute Bedienbarkeit, vorhandenes (wenngleich oft gar nicht so tiefes) Excel-Wissen, vorhandene Lizenz und die besonders im Bereich Datenvisualisierung leistungsfähigen Features sichern der Tabellenkalkulation einen bleibenden Platz im Unternehmen. Speziell im Bereich Business Intelligence, also in der Auswertung betrieblicher Daten, gibt es Excel-Virtuosen, die die Latte für gleichwertige DB-basierte Lösungen ziemlich hoch legen, vor allem in Sachen Umsetzungsgeschwindigkeit. Da hier i.d.R. nur wenige bis ein Nutzer an den Tabellen arbeitet, fallen hier Excel-Nachteile nicht so ins Gewicht. Dennoch wird jedes komplexere Rechenwerk im Vergleich tendenziell als „Bastellösung“ dastehen.

Das Rollen- und Rechtemanagement, der zeitgleiche Lese- und Schreibevorgang für mehrere Anwender, die Skalierbarkeit und Eignung für große Datenmengen, die Sicherung von Datenqualität durch Unterbindung von Falscheingaben, die explizite Darstellung einer komplexen Datenstruktur im Datenmodell, die Versionierung und automatische Datensicherung, die Integrationsmöglichkeit durch Schnittstellen und das Einbeziehen von Aktionen bzw. Workflows und ggf. KI/ML sind starke Argumente, für die Datenhaltung und die Digitalisierung von Geschäftsprozessen nicht die Tabellenkalkulation zu strapazieren, sondern auf eine solide DB-Lösung zu setzen.

Dieser Beitrag handelt von einer App zur Einsatzplanung im Facility-Management, d.h. zur Organisation von Tätigkeiten wie turnusgemäßen Wartungen und Reparaturaufträgen, der Einsatzplanung für Techniker, Hausmeister, Gärtner, Reinigungskräfte. Geklärter Einsatzort dank Datenmodell – aber wie kann man Mitarbeitern am besten mitteilen, was zu tun ist und wer es wann tun soll? Wo und wie sollen beim Einsatz erhobene Daten hinterlegt werden? Wie dokumentiert man die Abnahme einer Leistung, Objektbegehungen zur Kontrolle von Gebäuden und Außenanlagen, Kontrolle von Dienstleistungen wie Gebäudereinigung und Umbauarbeiten, Kontrolle von Brandschutz, Prüfung von Arbeitsschutz, Einhaltung des Arbeitszeitgesetzes?

In diesem Beitrag kommt Citrix Podio zum Einsatz; alle Features lassen sich aber mit sehr ähnlicher Vorgehensweise gleichwertig auch in Ninox darstellen.

Überblick durch alle Aufgaben an einem Ort

Nun könnte man, wenn man mit Podio arbeitet, versucht sein, das Podio-Feature „Aufgabe“ bzw. „Task“ (jederzeit durch das Tastaturkürzel „T“ aufrufbar) zu nutzen und einfach Podio-Aufgaben am Stammdaten-Eintrag des jeweiligen Einsatzorts zu erstellen . Sprich, wenn in einem Hauskeller ein Zähler ausgetauscht werden soll, geht man zum Eintrag des Hauses und erstellt dort die Aufgabe „Zähler austauschen“ für den, der es tun soll. Dies wiederholt man dann am Eintrag jedes Hauses, in dem auch Zähler ausgetauscht werden sollen.

Nachteil der „Podio-Aufgaben“: sie haben zwar typische Aufgaben-Fähigkeiten wie eine Erinnerungsfunktion und eine Kommentarfunktion, aber sind nicht anpassbar. Im Unterschied zu Einträgen einer App kann man ihnen keine zusätzlichen Felder geben. (Bei Ninox kommt man hier übrigens nicht in Versuchung, weil es dort keine Vergleichbare „Aufgaben-Funktion“ gibt; es wird von vornherein davon ausgegangen, daß Aufgaben „systematisch“ angegangen werden, und das heißt als eigene App)

„Reiche“ Aufgaben-App mit Stammdaten-Kontext

Welche zusätzlichen Felder könnten denn eine Einsätze-App der Gebäudeverwaltung bereichern? Zum Beispiel:

• Fotos, die vom Mieter geschickt wurden oder bei einer Objektbegehung gemacht;
• eine Priorität, so daß der Mitarbeiter weiß, wo er zuerst hingehen sollte;
• Datum und Uhrzeit, wenn es einen verabredeten Erledigungstermin gibt, die Arbeit per Datum geplant wird oder es eine Frist gibt;
• einen den eigenen Prozeß abbildenden Status – die eingebauten Podio-Tasks haben nur zwei Status: „zu erledigen“ und „erledigt“, aber vielleicht benötigt man z.B. einen für die Abnahme des Arbeitsergebnisses vor „erledigt“;
• mehr als eine Beziehung zu einem Stammdaten-Eintrag – die eingebauten Podio-Tasks hängen an einem Eintrag, das war's;
• Zahleneingabe z.B. für geschätzten Zeitaufwand;
• Buttons zum Anstoßen von Aktionen, beispielsweise Start und Ende einer Zeiterfassung
• Berechnungsfelder, die an der Aufgabe selbst „geerbte“ Informationen aus verbundenen Stammdaten-Einträgen darstellen, z.B. Name und Telefonnummer des Mieters.

Alles, was zu tun ist, sollte in den Einträgen einer einzigen “Action App” abgebildet werden. Nur so ist es möglich, den Überblick darüber zu bewahren, was insgesamt zu tun ist, wie weit eine Aufgabenerledigung fortgeschritten ist und so weiter.

Verschiedene Konzepte beim Verbinden mit Stammdaten

Separate Felder für jede Hierarchieebene

Der obige Screenshot zeigt ein Feld „Ort“, das auch „Mieteinheit“ heißen könnte, wenn es nur um Mietwohnungen geht, oder „Maschine“, wenn um einen Produktionsstandort, und ein Feld „Objekt“, d.h. das Haus, in dem sich die Mieteinheit, die Maschine usw. befindet. Dies hat den Vorteil, daß auf beide Felder separat gefiltert werden kann, siehe unten im Abschnitt „Fokus durch gefilterte Ansichten“.

Es gibt aber auch einen Nachteil: um die Verbindungsfelder konsistent zuweisen zu können und in allen gefilterten Ansichten alle relevanten Aufgaben auch zu sehen, dürfen die Verbindungsfelder nie leer sein. Das heißt, auch wenn ein Auftrag das ganze Objekt betrifft (z.B. „Hinweis zu Ablesetermin an der Haustür anbringen“), muß das Feld für die einzelne Einheit mit irgendetwas befüllt werden. Somit benötigt man eine eine generische Pseudo-Wohneinheit z.B. mit der Bezeichnung “ganzes Haus”, was die logische Unterteilung zwischen Objekt und Einheit unterläuft.

Die Verbindung zur Einheit, von Hand eingetragen, kann das automatische Eintragen der Verbindung zum Objekt, zu dem die Einheit gehört, anstoßen. Das beschleunigt das Anlegen eines Auftrags, ein Feld weniger auszufüllen!

Ein Feld für alle Hierarchieebenen

Ebenso schnell auszufüllen ist das Einsatz-Formular, wenn Mieteinheiten bzw. Maschinen und die Objekte, in denen sie sich befinden, in demselben Feld referenziert werden können – auch wenn sie in getrennten Apps gepflegt werden. 

Dies hat den Vorteil, daß die logische Unterteilung zwischen Objekt und Einheit intakt bleibt, d.h. man benötigt keine Pseudo-Einträge für Objekte in der Einheiten App. Sucht man nach dem Namen eines Objekts, z.B. per Straße und Hausnummer, werden einem sowohl alle Mieteinheiten als auch das ganze Objekt in der Autocomplete-Suche vorgeschlagen, wenn man Straße und Hausnummer in die Bezeichnung des Objekts und der Einheit integriert.

Ein kleiner Vorteil besteht darin, daß man die automatische Befüllung eines zweiten Feldes wie bei der anderen Variante nicht programmieren muß – dafür ist die Datenaggregation zwischen den Stammdaten-Apps komplexer: z.B. die Stunden, die man zur Unterhaltung eines Objekts aufgewendet hat, werden nicht nur an den dem Objekt zugeordneten Einheiten, sondern auch am Objekt selbst auflaufen.

Fokus durch gefilterte Ansichten

Ein weiterer Vorzug, für die Aufgaben nicht die Podio-Aufgabenfunktion zu verwenden, sondern diesen eine App zu widmen, besteht darin, daß man dann alle Ansichten-Funktionen von Podio nutzen kann. Dasselbe gilt selbstverständlich für Ninox, das ebenso reiche Möglichkeiten bietet, Ansichten zu erstellen.

Filter, Sortierung, Spaltenauswahl, Ansichtstyp-Auswahl

In der Kopfzeile jeder App finden sich sowohl in Ninox als auch in Podio die Buttons für die Auswahl des Ansichts-Typs (Tabelle und Karten sind meiner Ansicht nach die beiden wesentlichen), Sortierung (nur bei Tabellenansicht), Optionen, d.h. Auswahl der ein- und ausgeblendeten Spalten sowie Filter. Es kann nach jedem Kategoriefeld, jedem Verbindungsfeld, jedem Zahlenfeld und jedem Datumsfeld gefiltert werden, in beliebigen Kombinationen. Dies ist ein mächtiges Werkzeug, um Ansichten für bestimmte Situationen zu schaffen, auf denen nur das zu sehen ist, was für diese Situation wichtig ist. Einige Beispiele:

Mein Kanban-Board

Dies ist eine Übersicht über zu erledigenden Aufgaben gemäß der Kanban-Methode. Dies läßt sich erstellen, indem man die Ansicht „Kacheln“ und in den Optionen bei „Spalten basieren auf“ ein Status-Feld auswählt. Daraus kann man das persönliche Kanban-Board für jeden Mitarbeiter zu machen, indem man

• in einem „verantwortlich“-Feld den Podio-Kontakt der verantwortlichen Person einträgt;
• nach „ich selbst“ filtert – ja, Podio weiß, wer ich bin, denn ich habe mich eingeloggt!

Meine Liste für unterwegs

Man kann in der mobilen App einfach, wie im Screenshot, „Mein Kanban-Board“ aufrufen. Dies hat den Nachteil, daß man auch Aufgaben sieht, die noch im „Eingang“ liegen oder schon in „Abnahme“ sind. Den zusätzlichen Fokus auf tatsächlich anliegende Aufgaben kann man durch weitere Filter schärfen, z.B.

• zusätzlich auf die Status „als nächstes“ und „in Arbeit“ einschränken;
• zusätzlich nach einem Datumsfeld mit „Heute“ filtern.

Um möglichst gut schon im Web-Browser zu sehen, was in der mobilen Ansicht erscheint, empfiehlt sich, den Ansichts-Typ „Tabelle“ zu wählen. Wenn man die Einträge nun noch nach Objekt sortiert, so daß der Mitarbeiter alle Einträge eines Objekts direkt untereinander vorfindet, steht dem effizienten Abarbeiten einer Aufgabenliste nichts mehr im Weg.

Unterschiedlich sortierte Listen

Die Listen-Ansicht mit ihrer Möglichkeit zu sortieren hilft auch bei der Einhaltung von Fristen, indem man absteigend nach Datum sortiert. Alphabetische Sortierungen oder die Sortierung nach Priorität, Status, Objekt etc. haben jeweils ihren Charme. Will man nach mehreren Kriterien sortieren, kann eine Berechnungsspalte für ein Sortierkriterium hier auch komplexe Wünsche erfüllen.

Weitere Beiträge von „Facility-Management mit Low Code“

Im nächsten Beitrag dieser kleinen Gebäudemanagement-Serie wird es darum gehen, Zähler-Ablesungen zu organisieren und nachzuhalten – wenn Abrechnungen zu erstellen sind, ist es wichtig, keinen Zähler zu vergessen, der ablesenden Person das Auffinden des Zählers zu erleichtern, ein „Beweisfoto“ zu dokumentieren, Plausibilitäts-Checks zu erleichtern und daher Zähler und Ablesungen nach Objekt, Einheit, Mieter, Zeitpunkt etc. gruppiert darzustellen sowie die Verbrauchsdaten gleich mit errechnet zu bekommen. Dann fehlt nicht mehr viel zu einer kompletten Nebenkostenabrechnung!

Software-Lösungen, mit denen man Arbeitsprozesse im Unternehmen digital abbilden kann, unterscheiden sich ziemlich grundsätzlich in ihrer Konzeption und Bauart. Um diese Unterschiede verständlich zu machen, werden gern bildliche Analogien bemüht – eine gängige eben gerade von mir: daß Software in „Bauarten“ eingeteilt werden kann, ist eine Analogie zur Architektur von Gebäuden.

Im folgenden werde ich versuchen, architektonische Konzepte von Geschäftsprozess-Software anhand von übertriebenen Vergleichen mit Wirtschaftsgebäuden und -nutzungen plastischer greifbar zu machen. Die dabei entstehenden Bilder (Karikaturen?) sind, so hoffe ich, im Entscheidungsprozess für einen Lösungsweg bei der digitalen Transformation des Unternehmens hilfreich.

Die Analogie

Wer etwas produziert, braucht einen Produktionsstandort mit einem dafür hergerichteten oder eigens dafür gebauten Wirtschaftsgebäude – eine Werkstatt, ein Labor, ein Gewächshaus, eine Fabrik. Auch viele Dienstleistungen und nicht-physische Produkte sind nicht oder nur viel schwierige machbar ohne geeignete Räumlichkeiten – ein Frisiersalon, ein OP, der Newsroom einer Zeitung. Auch bevor Anlagen installiert und Geräte hineingetragen werden, kann man ein Stallgebäude leicht von einer Lagerhalle und einem Konzertsaal unterscheiden. Man kann in einem Stallgebäude ein Konzert geben und in einem Konzertsaal Hühner mästen, aber bei weitem nicht so gut wie in einem Gebäude, das dafür gebaut wurde.

Die Digitalisierung befreit uns von vielen Zwängen der physischen Welt. Kann man ein Laptop nicht überall aufklappen? Jedoch zieht der Bildschirmarbeiter gewissermaßen auch in digitale Immobilen ein. Der für ein Produkt oder eine Dienstleistung optimale digitale Arbeitsplatz besteht nicht nur aus einem ergonomischen Stuhl, Tisch und Beleuchtung, sondern mindestens ebenso in der richtigen Software-Umgebung. Diese muss, genau wie bei physischen Produktionsstätten, bereits auf der architektonischen Ebene zum Arbeitsprozess passen, bevor man „die Geräte hineinträgt“, also sich Gedanken über benötigte Software-Features macht.

Aber nun genug der Vorrede, viel Spaß bei den Hausbesichtigungen!

Begriff unklar? Alle in diesem Beitrag vorkommenden Fachausdrücke werden erläutert in unserem brandneuen White Paper No Code, Low Code, Pro Code? Wie Sie mit neuen Tools Ihre Geschäftsprozesse digital abbilden können.

Standardsoftware: Büroanwendungen

„Email/Excel/Word ist wie ein Hobbyraum im Einfamilienhaus“

Hobbyräume unterscheiden sich je nach Hobbies und Persönlichkeit des Besitzers. Manche ähneln einer Werkstatt, in manchen ist eine Eisenbahn aufgebaut, manche sind vor allem Abstellraum. Zum Malen gibt es nicht genug Tageslicht, beim ersten größeren Auftrag steht der Flur voller Kartons und man kommt weder rein noch raus, und wenn man im Hobbykeller Burger brät oder Hühner hält, stinkt das ganze Haus. Kein Kunde kommt vorbei. Und wenn doch, schämt man sich zu Tode. 

Aber billig ist das Ganze, denn das Zimmer ist ja sowieso da.

In einem Hobbyraum kann man so ziemlich alles machen – zu Anfang, irgendwie, im Hobby-Maßstab. Professionalisierung heißt Umzug in professionelle Räumlichkeiten.

Standardsoftware: Vertikale Spezialisten

„Branchensoftware ist wie eine Burgerketten-Filiale“

Wenn man Burger braten und verkaufen will, geht es nicht besser: optimal funktional im Mainstream-Chic. Die Filiale ist konkurrenzlos kostengünstig in der Herstellung, denn es gibt bereits tausende praktisch gleich aufgebaute Gebäude. Draußen ist eine Rampe für LKW-Anlieferung. Innerhalb des Gebäudes sind die Wege für Waren und Informationen kurz. Alles ist schön standardisiert.

Eine Burger-Bräterei für alles andere als Schnellimbiß nicht zu gebrauchen. Was tun mit der Bestell-Säule und den Schaltern und Fahrspuren für Drive-In? Dann reißt man lieber ab und baut ganz neu.

Sie wollen genau das eine machen, was viele andere genau so jetzt schon machen? Auch in 10 Jahren noch? Kostenmäßig mithalten zu können entscheidet über Sein oder Nicht-Sein? Dann ist dieses Architektur-Konzept Ihr Ding.

Standardsoftware: Generalisten

„Ein ERP-System ist wie ein Krankenhaus“

Für jedes medizinische Fachgebiet gibt es einen eigenen Trakt mit dem genau dafür benötigten allerneustem Stand der Technik, alles genügt den Bestimmungen. Der Besucher- und Patientenverkehr ist ebenso einheitlich geregelt wie die Material- und Informationsströme, nicht nur im Gebäude, sondern auch für Anlieferungen. Das Architekturbüro baut seit Jahren nur Kliniken und braucht kaum spezifischen Input, es setzt weitgehend ein bewährtes Schema um, was man dem seelenlosen Zweckbau trotz der Mosaik-Gebrauchskunst im Foyer und dem Springbrunnen im Innenhof auch ansieht.

Trotz der Standardisierung sind die Herstellungskosten überraschend hoch – jedenfalls im nachhinein: durch vermeintlich gar nicht so große Extra-Wünsche kommt es zu einer regelrechten Kostenexplosion. Leseemfehlung Handelsblatt: Wie SAP und Lidl Hunderte Millionen Euro versenkt haben, als sie von einem Architektenhaus in ein Systemhaus umziehen wollten.

Sie haben ein komplexes Produkt-Portfolio und sind darauf angewiesen, daß Lieferanten gemäß Branchenstandards angebunden sind und sich neue Mitarbeiter schnell zurechtfinden, weil alles so ist wie da, wo sie herkommen? Budget ist vorhanden? Dann ist das hier für Sie erwägenswert.

Standardsoftware: Stack horizontaler Spezialisten

„Integrierte SaaS-Apps sind wie eine Just-in-Time-Lieferkette“

Am schlanken Produktionsstandort gibt es eine Rampe für Anlieferung und Abholung und eine hochmoderne Montagehalle. Aber darum geht es hier nicht: die Teile, die für die Montage benötigt werden, kommen von verschiedenen Lieferanten. Die über die ganze Welt verstreuten Lieferanten verfügen Ihrerseits über hochmoderne, spezialisierte Anlagen, so ist jedenfalls zu vermuten, und sind so in der Lage, Qualität zu einem günstigen Preis termintreu zu liefern. Die Lieferanten arbeiten noch für viele andere Abnehmer und sind meist „große“ Unternehmen, d.h. man kommunizieren mit dem Vertrieb, nicht mit der Chefetage.

Wenn alles läuft, ist die Produktion unschlagbar günstig und schnell. Aber wenn auch nur einer der Teilehersteller Lieferschwierigkeiten hat oder es Engpässe bei den Logistik gibt (Verweis: Just in Time Prinzip), steht das Band. Was, wenn ein Lieferant die Produktion eines kritischen Teils ganz einstellt? Vielleicht sind manche Teile gar nicht so günstig, sondern wären bei der hohen Stückzahl viel kostengünstiger selbst herzustellen.

Sie haben Stützprozesse, die unkritisch genug sind, um sie externen Dienstleistern zu überlassen? Das Angebot externer Dienstleister reicht Ihnen aus? Dann sollten Sie sich vielleicht einen App-Zoo zulegen und in das Thema Integration einarbeiten.

Individualsoftware: No Code / Low Code

„Eine No Code App ist wie ein Lego-Haus“

Bei Burgerketten-Filialen und Kliniken beruht ein Gutteil der geringen Baukosten auf dem Einsatz von Fertigbauteilen. Was, wenn es Fertigbauteile wie riesige Lego-Steine gäbe, mit denen man selbst, ohne Kran und Fachausbildung, ein Haus bauen könnte, und wieder auseinander- und neu zusammenbauen, wenn man es sich anders überlegt hat? Jede Konstruktionsidee ist viel einfacher umzusetzen als mit anderen Baumaterialien: nichts zu mauern, kein Beton zu gießen, nichts zu fliesen, nichts anzustreichen.

Man wird dem Gebäude ansehen, daß es aus Bauklötzen zusammengesteckt ist, aber das muss im Vergleich zur Fertigbauweise nicht unbedingt schlechter aussehen und funktionieren. Lego ist ist wasserfest und erstaunlich belastbar, und wenn nicht so kugelsicher wie ein Haus aus Stein oder Beton, dann würde es doch ein Erdbeben wohl besser überstehen.

Sie wollen einen Prozess digital abbilden, der zu speziell für existierende Lösungen ist? Sie wollen über mehrere Orte verteilte einfache Prozesse zusammenführen, indem Sie sie in Lego nachbauen? Sie wollen ausprobieren, aber nicht zu viel ausgeben? Dann sollten Sie hier unbedingt etwas ausprobieren.

Individualsoftware: klassische Programmierung

„Eine eigene Software ist wie ein Sterne-Restaurant vom Architekten“

In diesem Gebäude wurden keine Kompromisse gemacht, sondern ein Statement. Hier gibt es keinen Fertigbauteil-Klon wie in der Burger-Bräterei, keine an Sonderwünsche angepassten Standard-Komponenten wie im Krankenhaus, hier gibt es kein Lego. Die optimale Funktionalität wurde mit Naturstein aus dem nahen Steinbruch von Hand gemauert, und auch die Ausstrahlung ist so, wie es sich für eine Spitzenmarke gehört. Der Besucher soll das Gebäude als Erlebnis wahrnehmen, es ist Teil der Markenidentität und integraler Teil des Produkts.

Es versteht sich von selbst, das so etwas seine Preis hat, aber je individueller die Anforderungen, desto eher ist das Architektenhaus auch kostengünstiger als der Versuch, sich dieselbe Funktionalität mit eigentlich nicht passenden Standardlösungen zusammenzuschustern. Auch wenn mit einem Baukastensystem dieselbe Funktionalität machbar ist, wird man mit einer maßgeschneiderten Lösung immer einen Unterschied machen können.

Schade nur, wenn das Budget oder der Mut nicht zum Star-Architekten gereicht hat. „Besser gut kopiert als schlecht selbst gemacht“: dann ist das handgefertigte Ergebnis schnell schwächer als ein weise gewählter Fertigbau oder ein durch Ausprobieren optimierter Lego-Bau. Letzterer hat auch noch den Vorteil der Änderbarkeit, während die schönste und beste Konstruktion mit sich wandelnden Anforderungen unpraktisch werden kann. Häßliche, verwinkelte Anbauten, es hilft nur noch der Abriß.

Sie wissen, was Sie brauchen, weil Sie das mit Lego ausprobiert haben oder weil Sie in einer funktionierenden Immobilie arbeiten, die aber jetzt zu klein wird und ein paar Neuheiten vermissen läßt? Sie haben die finanziellen Mittel, um was Richtiges zu machen? Sie zielen auf Kundschaft, die etwas Besonderes erwartet? Dann könnten Sie durchaus mal beim Architekten anrufen und sich überraschen lassen, wie kostenoptimal unter diesen Voraussetzungen eine maßgeschneiderte Lösung sein kann.

(Das Beitragsbild ist übrigens der Schnürboden einer Theater-Probebühne)

Aber was steckt eigentlich hinter diesen Buzzwords? Was sind die Folgen und vor allem, was hat das für Auswirkungen auf meine Branche, mein Unternehmen?

All diese Aspekte möchten wir in diesem Artikel beleuchten. Den feststeht, das Thema Digitale Transformation ist heute aus keinem Geschäft mehr wegzudenken. Und das nicht nur, weil sich die Welt immer weiterentwickelt, sondern auch, weil die Bedürfnisse der Kunden diesen Wandel geradezu voraussetzen. Der Wandel ist also notwendig, um auch in Zukunft wettbewerbsfähig zu sein.

Daraus ergibt sich jedoch eine große Herausforderung, insbesondere für KMU. Wie Sie in diesem Artikel feststellen werden, ist der Wandel tiefgreifend und sehr individuell. Allgemeingültige Lösungen gibt es nicht, da jedes Unternehmen ein eigenes Geschäftsmodell verfolgt und andere Kunden anspricht. Das ist auch ein Hauptgrund, warum sich viele Unternehmer damit schwertun.

Die zu berücksichtigenden Aspekte sind jedoch immer gleich.

Was bedeutet Digitale Transformation und worin unterscheidet sie sich zur Digitalisierung?

Auch wenn manchmal die Begriffe „Digitale Transformation“ und „Digitalisierung“ synonym verwendet werden, bedeutet dies mehr, als nur die bestehende Arbeitsweise digital nachzubilden.

Bei der Digitalen Transformation geht um eine Veränderung, welche durch digitale Technologien sowohl ausgelöst wie auch begleitet wird. Es geht um den Wandel, hin von einer Unternehmens-zentrierten Sicht- und Denkweise hin zu einer Fokussierung auf den Kunden, seiner Probleme und Bedürfnisse.

Die Digitalisierung ist in diesem transformativen Prozess enthalten und stellt quasi eine Art Fundament dar. Denn um die Kunden heute zu begeistern, werden integrierte digitale Prozesse benötigt, und die intelligente Auswertung und Nutzung von Daten.

Demzufolge ist die Umwandlung eines Unternehmens auch ein Prozess, der nicht nur an eine Abteilung delegiert werden kann, mit der Erwartung, dass im Anschluss das Unternehmen die Digitale Transformation gemeistert hat. Im Gegenteil: Die Transformation ist interdisziplinär zu betrachten und benötigt eine Strategie, welche alle Unternehmensbereiche und Ebenen einbindet.

Digitale Transformation gibt es schon lange

Für viele Unternehmen ist die Digitale Transformation eine Herausforderung, die erst in letzter Zeit an Dringlichkeit gewonnen hat. Dabei existiert sie bereits seit über 30 Jahren: Angefangen mit dem Computer und dem Internet, Mobiltelefonen, Smartphones und neuen Kommunikationswegen über Social Media und Smartphone Geräten, wie Smart Speakern. All die einzelnen Schritte haben zu einer fortwährenden Veränderung unserer in unserer Kommunikation und Gewohnheiten geführt, und diese Transformation dauert weiter an.

Entscheidend für die Zukunft des eigenen Unternehmens ist dabei die Fähigkeit, diese Veränderungen zu adaptieren und in der eigenen Firmenidentität zu integrieren. Es gibt verschiedene Beispiele aus der Vergangenheit, wo Unternehmen zwar innovativ waren, diese jedoch nicht in der entscheidenden Konsequenz vorangetrieben wurde. Eines von diesen Beispielen ist Kodak, noch heute stark verbunden mit der analogen Fotografie. Was viele nicht wissen: Kodak hat damals die digitale Fotografie erfunden. Jedoch haben sie nicht auf diese Technik gesetzt und forciert, um ihr bestehendes, damals sehr gut laufendes Geschäft mit der analogen Fotografie nicht gefährden wollten.

Das Ergebnis ist allen bekannt: Kodak ging insolvent und den Markt für die Fotografie übernahmen andere, insbesondere Nikon und Canon. Die Entwicklung hat jedoch auch nicht vor ihnen halt und die Smartphones haben diesen Markt weiter disruptiert.

Und so brauchen wir nur einige Zeit zurückdenken und werden feststellen, dass die Digitale Veränderung schon sehr lange unsere Wirtschaft und Gesellschaft prägt:

• Postkarte und Brief → E-Mail
  
• analoges Telefon → Mobiltelefon
  
• SMS → WhatsApp und andere Messenger
  

Die Notwendigkeit zur Veränderung

Durch die sich ständig verändernden Rahmenbedingungen erhöht sich der Druck auf die Unternehmen und deren bisherigen Geschäftsmodellen immer weiter. Wertschöpfungsketten verändern sich, neue Mitbewerber betreten den Markt und bedrohen das eigene Kerngeschäft und Rentabilität. Gleichzeitig müssen neue Kompetenzen erworben werden, während die Halbwertzeit dieses Wissens sinkt. So war in den 80er Jahren das angeeignete Wissen 30 Jahre lang anwendbar, so ist diese Zeit inzwischen auf 5 Jahre abgesunken.

Im Ergebnis werden Unternehmen von verschiedenen Seiten herausgefordert. Das zeigt auch eine Studie von McKinsey, nach der nur 8 Prozent der befragten Führungskräfte davon überzeugt sind, dass ihr derzeitiges Geschäftsmodell auch in der Zukunft weiterhin tragfähig ist.

Die Digitalstrategie als Verbindungsstück

Damit die Digitale Transformation gelingt, ist eine formulierte Strategie notwendig. Diese soll nicht nur allen Beteiligten den Weg aufzeigen, sondern auch eine Verbindlichkeit schaffen. Die erarbeitete Strategie darf jedoch nicht als fix betrachtet werden, sondern sie wird auf dem Weg immer wieder überarbeitet und verfeinert werden. Solche Anpassung ist völlig normal, da sich die Anforderungen und Lösungen mit den gemachten Erfahrungen ändern werden.

Halten Sie Ihre Vision, die IST Situation und das Ziel unbedingt schriftlich in Ihrer Digitalstrategie fest. Formulieren Sie dabei die notwendigen Schritte und legen Sie die Verantwortlichkeit fest.

Diese Strategie ist die Grundlage für die Kommunikation gegenüber Ihren Stakeholdern, Partnern und Mitarbeitern, damit sich eine digitale Denkweise entwickeln kann.

Diese Fragen sollten Sie sich stellen:

• Wie sieht unser Ziel Ökosystem aus / wo wollen wir hin?
  
• Gibt es eine konsistente Vision und Strategie für die Digitalisierung?
  
• Was ändert sich in Bezug auf Lieferanten, Partnern, Wettbewerbern und Kunden?
  
• Werden mögliche Herausforderungen am aktuellen Geschäftsmodell berücksichtigt?
  
• Werden Daten bei Entscheidungen herangezogen und in Geschäftsprozessen genutzt?
  
• Wird an neuen, experimentellen Modellen gearbeitet oder neue Elementen mit bestehenden Geschäftsmodellen kombiniert?
  
• Werden neue Kooperationen eingegangen, um das Unternehmen digitaler aufzustellen?
  
• Können die eigenen digitalen Fähigkeiten durch neue Partner oder Übernahmen ergänzt werden?
  

Berücksichtigen Sie dabei, dass sich nicht nur der Weg immer wieder ändern, sondern dass die Transformation nie abgeschlossen sein wird. Gehen Sie diesen Weg mit Offenheit, einer großen Experimentierfreude und Neugierde, mit dem Willen zu Veränderungen.

Digital Leadership und Unternehmenskultur

Die Einführung von Digitalisierung und die Transformation umfasst alle Bereiche und macht auch vor dem Management und Hierarchien keinen Halt. Für einen erfolgreichen Wandlungsprozess ist es entscheidend, dass die Entscheidungsträger als Leader vollständig hinter dem Ziel und der Vision stehen und auch entsprechend vorangehen und die Digitalisierung leben.

Die Eigenschaften von guten Digital Leadern sind Offenheit für neue Konzepte und Ideen, Bewusstsein für agile Arbeitsweisen und neue Führungsmethoden.

Dabei steht im Vordergrund, dass die Hintergründe, Ziele und Visionen allen Beteiligten nachvollziehbar kommuniziert werden. Dies schließt auch ein, dass die Mitarbeiter mitgenommen und digital befähigt werden müssen: Das betrifft sowohl die Einstellung (Digital Mindset), als auch deren Qualifikationen (Digital Empowerment).

Der Erfolg von Projekten zur Digitalisierung und Transformation entscheidet sich sehr oft an der Akzeptanz der Mitarbeiter, ob diese erfolgreich verlaufen. Demzufolge kann die größte Herausforderung in der Befähigung der Mitarbeiter stecken. Hierbei tut sich häufig das mittlere Management und ältere Mitarbeiter schwerer, die Veränderungen und neuen Tools zu adaptieren.

Gleichzeitig müssen bisherige Strukturen der Zusammenarbeit aufgebrochen und neu zusammengestellt werden: Weg von der klassischen Aufteilung in Abteilungen, hin zu flexiblen Teams, die bereichsübergreifend arbeiten. Dadurch kann das kostbare Wissen der einzelnen Mitarbeiter viel besser im Unternehmen ausgetauscht werden.

Wichtig ist, bei der ganzen Digitalen Transformation eine Kommunikation auf Augenhöhe, die Motivation und Einbindung der Mitarbeiter in diesen Prozess. Wenn sich die Mitarbeiter nicht nur als ausführende Kraft verstehen, sondern zu einem echten Teil des Unternehmens werden, dann sind sie automatisch viel motivierter.

Fragestellungen:

• Wie können Bedenken unserer Mitarbeiter gegenüber Digitalisierungsvorhaben sein?
  
• Wie können wir unsere Vision vermitteln und vor allem den Nutzen und die Vorteile für die Mitarbeiter herausstellen?
  
• Mit welchen Maßnahmen kann die Führungsebene mit gutem Beispiel bei der Digitalisierung vorangehen?
  
• Gibt es Teams und Mitarbeiter, die bereits über digitale Fähigkeiten und Fertigkeiten verfügen und in die Transformation eng eingebunden werden können?
  

Veränderte Kundenbeziehungen und Interaktionen

Machen Sie sich die Daten zu einem Freund, um mit ihnen ein tieferes Verständnis für die Bedürfnisse Ihrer Kunden zu entwickeln. Denn diese stehen im Fokus all Ihrer Bemühungen.

Der dritte wichtige Aspekt sind die Kunden: Das Stichwort ist hier eine verbesserte Customer Journey (Kundenerfahrung) zu gestalten. Hierbei wird der Kunde und seine Bedürfnisse in den Vordergrund aller Bemühungen gestellt.

Die Ansprache der potenziellen Kunden findet heute vermehrt nach dem Pull- statt Push-Prinzip statt. Zudem wird der Fokus auf die Betreuung von bestehenden Kunden immer wichtiger, um die Customer Lifetime Value zu steigern. Um dies zu gewährleisten, ist die intelligente Verknüpfung und Auswertung von Daten wichtig, um den Kunden zum richtigen Zeitpunkt, die richtigen Informationen liefern zu können.

Vor lauter Möglichkeiten durch veränderte Technologien, steht die Verbesserung der Kundenzufriedenheit und der Nutzen immer im Vordergrund - nicht die Technologie.

Dazu müssen erst die Kundenbedürfnisse und die dahinterliegenden Anforderungen und Prozesse verstanden und modelliert werden. Dabei helfen Ansätze des Design Thinking, wie Prototypen, damit erste Tests und Ergebnisse möglichst schnell in den weiteren Prozess eingearbeitet werden können.

Fragestellungen:

• Werden Technologien eingesetzt, nur weil sie möglich sind oder weil dahinter ein echter Nutzen für den Kunden steht?
  
• Wird das Werteversprechen in den digitalen Angeboten und dem Marketing berücksichtigt und vermittelt?
  
• Ist die Erfahrung für den Kunden konsistent, über die verschiedenen Kanäle und Plattformen hinweg?
  

Prozesse im digitalen Wandel

Für viele verbirgt sich hinter dem Begriff der Digitalisierung und Digitalen Transformation die Überfügung von bislang analogen Arbeitsweisen in die digitale Welt. Wenn die Informationen und Prozesse digital abgebildet sind, können im weiteren Verlauf einzelne Schritte automatisiert werden.

Vor allem das Management verspricht sich davon häufig eine Steigerung der Effizienz, Flexibilität und Geschwindigkeit. Die Prozessdigitalisierung ist allerdings kein Selbstzweck, sondern muss immer in einem größeren Kontext eingebunden und einem Kundennutzen verbunden werden:

• Machen die Prozesse Sinn? Werden noch Arbeitsweisen verwendet, weil es schon immer so gemacht wurde?
  
• Generieren Sie einen Nutzen für den Kunden? Welchen?
• Können Prozesse vereinfacht werden? Sind alle Schritte wirklich notwendig?
  
• Von welchen vorherigen Schritten und Materialien ist eine Tätigkeit abhängig?
  

Schließlich wird ein Ineffektiver Prozess nicht dadurch besser, dass er jetzt digital abgebildet wird.

Beispiele von Prozessdigitalisierungen:

• Kommunikation und Kollaboration im Unternehmen: Einführung von Tools für das Projektmanagement und Kanban Boards
  
• Dokumentenmanagement: Überführung von bislang papiergebundenen Informationen, Prozessen und Eingängen in die digitale Welt
  
• Administrative Prozesse: Automatisierung der Rechnungsstellung, Prüfung der Zahlungseingänge und dem Mahnwesen
  
• Marketing: Nutzung von CRM Systemen und Marketing Automation Tools
  

Fazit

Von der Digitalen Transformation sind alle Bereiche und Ebenen eines Unternehmens betroffen: Strukturen, Prozesse, dem Management und jedem einzelnen Mitarbeiter. Dabei ist es elementar, dass eine digitale Sicht- und Denkweise in die DNA der Unternehmen ausgebaut wird.

Wenn Sie dabei die einzelnen Aspekte berücksichtigen und sowohl mutig, als auch behutsam vorgehen - um alle mitzunehmen - können Sie Ihr Unternehmen nachhaltig für die Zukunft fit machen.

Statt sich auf die Suche nach einer standardisierten Facility-Management-Branchensoftware zu machen, kann man sich mit Datenbank-Generatoren wie Citrix Podio oder Ninox eine App für die Liegenschaftsverwaltung auf den Leib schneidern. Statt dass man sich einer gegebenen Software anpassen muss, bekommt man eine digitale Lösung, die sich den eigenen Prozessen anpasst – also einerseits „lean“ ist, d.h. keine Features hat, die man nicht braucht, und andererseits die benötigten Fähigkeiten hat und sich an sich ändernde Anforderungen leicht anpassen läßt. Dabei ist auch ohne Programmierkenntnisse schon einiges erreichbar, denn Podio und Ninox sind No-Code- und Low-Code-Apps.

Herausforderungen im Bereich Gebäudemanagement

Professionelles Facility-Management umfasst heute weit mehr als die reine Hausmeistertätigkeit. Facility-Manager sorgen dafür, dass Gebäude optimal bewirtschaftet, Außenanlagen kontrolliert, Gewerke und Dienstleister betreut, Begehungen durchgeführt, Sicherheitsstandards im Brandschutz und Arbeitsschutz eingehalten werden u.v.m.. Dasselbe gilt für die Betreuung von Anlagen, Maschinen, Fahrzeugen.

Reibungslose Abläufe, Effizienz und Zuverlässigkeit verlangen maximalen Überblick. Prozesse nicht mehrfach auszuführen, nichts zu vergessen und alles lückenlos im Blick zu behalten, ist der Kernprozess des Facility-Management. Dazu tragen individuelle Checklisten wesentlich bei, die für jedes zu betreuende Objekt angelegt werden können. Dazu aber braucht man zunächst einmal eine differenzierte Ordnung der Gegenstände, also eine Systematik der Stammdaten.

Die Herausforderungen meistern mit einer individuellen Datenbank

Die Bewirtschaftung von Gebäuden, Anlagen oder sonstigen Objekten ist etwas, wofür datenzentrierte Low-Code-Tools wie Ninox und Podio wegen ihrer Konfigurierbarkeit besonders gut eignen. Ein an die jeweiligen Gegebenheiten und Ihre Bedürfnisse individuell angepasstes hierarchisches Datenmodell, z.B. Standort > Gebäude > Wohneinheit > Raum oder Standort > Halle > Sektor > Maschine erleichtert nicht nur die Datenpflege. Eine systematische und den Gepflogenheiten vor Ort entsprechende Bezeichnung von Objekten macht es absolut eindeutig und leicht zu verstehen, wo eine Aufgabe zu erledigen ist.

Genauso wichtig: damit ist auch die Grundlage geschaffen, den Erledigungs-Status von Aufgaben, Erledigungs-Zeitpunkt, benötigte Zeitdauer, verbrauchtes Material, Zustand vor und nach der Maßnahme und viele andere Daten direkt am Objekt auf unterster Ebene (Raum, Maschine etc.) zu planen und nachzuhalten. Die Zusammenfassung für höhere Ebenen ist dann in Echtzeit möglich.

Zwei Beispiele

Liegenschaftsverwaltung

In dieser Ninox-Lösung für Gebäudeunterhaltung bzw. Hausmeisterservice sind ist jede Mieteinheiten einem Gebäude zugeordnet, jedes Gebäude einem Grundstück, jedes Grundstück einer Wirtschaftseinheit und jede Wirtschaftseinheit einem Mandanten. Diese vielstufige Hierarchie steht im Einklang mit  der Richtlinie zum Immobilien-Daten-Austausch gif-IDA, und anders als viele marktgängige Immobilien-ERP-Systeme verfügen die Low-Code-DB-Generatoren über eine Schnittstelle (API), so daß einer einfachen, fehlerfreien und automatisierbaren Datenintegration mit anderen modernen Immobiliensoftware-Produkten nichts im Wege steht.

Die Mieteinheiten enthalten Stammdaten wie die Mietfläche und sind gegebenenfalls mit dem Mieter verknüpft. Die Aufgaben können dann einer Einheit zugeordnet werden. Mehr zur Aufgaben- bzw. Tickets-App im Folgebeitrag, Link siehe ganz unten.

Biogasanlage

Facility-Management ist nicht nur Gebäudeunterhaltung: jede technische Anlage der Vollgas Bioenergie GmbH & Co. KG steht auf einem der drei Standorte, auch die Fahrzeuge des Fuhrparks haben einen Standort. Neben der Verbindung mit einem Standort gibt es noch eine Unterteilung nach Kategorien, um die Datenverwaltung zu vereinfachen.

Nach diesen Beispielen steigen wir nun etwas tiefer in die Strukturierung der Stammdaten ein.

Hierarchisches Datenmodell

Eine etwas tiefere hierarchische Datenstruktur zur Hausverwaltung könnte so aussehen:

• gesamter Bestand
• Parkallee 10-12 (Standort 1)
• Parkallee 10 (Gebäude 1.1)
• EG (Wohneinheit 1.1.1)
• Wohnzimmer (Raum 1.1.1.1)
• Küche (Raum 1.1.1.2)
• …
• 1. OG (Wohneinheit 1.1.2)
• …
• Bahnhofstr. 1 (Standort 2)
• Vorderhaus (Gebäude 2.1)
• EG rechts (Wohneinheit 2.1.1)
• …
• EG links (Wohneinheit 2.1.2)
• Hinterhaus (Gebäude 2.2)
• …

Eine solche Systematik bezeichnet man als Baumstruktur (es gibt nur einen Stamm, jeder dicke Ast kommt aus dem Stamm, jeder dünne Ast aus einem dicken etc.). Vielleicht ist eine Systematik nach einzelnen Räumen völlig übertrieben — dann baut man eben wie in Beispiel I oben eine mit der Einheit als unterster Ebene, je nach Bedürfnislage. Aber um bei dem Baum zu bleiben: Ein Haus kann nicht zugleich an zwei Adressen stehen, und ein Raum kann nicht zugleich in zwei Wohneinheiten liegen. In der Räume-App gibt es exakt ein Feld für die übergeordnete Wohnung, und man kann dort exakt eine Wohnung eintragen kann, nein: muss. Denn es gibt kein Wohnzimmer ohne Wohnung.

Diese Strenge hilft in vielerlei Hinsicht:

1. so kann man seine „Stammdaten“ besser strukturieren, in Ordnung halten und Objekte finden;
2. so gibt es für Mitarbeiter, die in einem Raum etwas tun sollen, kein Vertun darüber, in welcher Wohnung, in welchem Haus an welchem Standort sich dieser Raum befindet;
3. so kann der Raum Informationen von der Einheit, dem Haus oder dem Standort „erben“ und umgekehrt Informationen zur Aggregation für höhere Hierarchieebenen bereitstellen — mehr darüber gleich.

Zuvor aber noch einer obendrauf beim Thema Hierarchie: auch eine komplexe Klassifikation ist möglich und oft sinnvoll. Z.B. kann eine Wohnung nicht nur einem Standort zugeordnet sein, sondern zugleich auch einem Mieter wie in Beispiel I, einem Eigentümer, einem Energieversorger oder einem zuständigen Mitarbeiter. Mit diesem zusätzlichen „Reichtum“ des Datenmodells werden die Konzepte der Vererbung (vom Eltern-Eintrag auf den Kind-Eintrag usw.) und der Aggregation (von allen Kind-Einträgen zum Eltern-Eintrag usw.) erst so richtig attraktiv.

Viele Unternehmen verwalten ihre Daten noch in der Tabellenkalkulation statt in einer Datenbank. Speziell beim Thema dieses Abschnitts, nämlich der Abbildung eines hierarchischen Datenmodells, sind Excel & Co. viel schwächer als ein DB-Builder. Ausführlich dazu in diesem Artikel: Excel durch einen Datenbank-Generator mit Low-Code in der Cloud ersetzen.

In einer Datenbank lässt sich genau steuern, was vererbt wird und was aggregiert

Zum Beispiel:

• am Wohnungs-Eintrag steht an gut sichtbarer Stelle, wer der Mieter ist und/oder welcher Energieversorger oder Heizungsinstallateur für die Wohnung zuständig ist, inklusive Telefonnummer. Die Information, wer Installateur ist, wird vom Haus geerbt, man muss nicht erst aktiv zum Haus navigieren, um die Informationen zu erhalten. Die Telefonnummer erbt wiederum das Haus vom Installateurs-Eintrag in der Kontakte-App, die Telefonnummer wird dann vom Haus an die Wohneinheit durchgereicht.
• am Haus werden die m2 Wohnfläche und die Soll- und Ist-Monatsmieten aller Einheiten aufsummiert, und am Standort die m2- und Mietsummen der Häuser.
• am Mitarbeiter-Eintrag werden die Stunden und die Anzahl der erledigten Tickets aggregiert. Und die Anzahl der Tickets, bei denen es hinterher etwas zu monieren gab.

Wie wir sehen, hilft die Vererbung nicht nur bei der praktischen Anzeige von Eltern-Informationen an Kind-Einträgen, sondern auch bei der Datenpflege: doppelte Datenhaltung wird dadurch vermieden, dass es für jede Information (Telefonnummer etwa) nur exakt einen Ort gibt, an dem sie eingegeben und gepflegt wird, überall sonst taucht sie automatisch auf.

Wie wir weiterhin sehen, hilft die Aggregation der Daten von Kind-Objekten in den Objekten einer oder mehr Hierarchiestufen weiter oben, Kennzahlen automatisch und in Echtzeit zu berechnen. Aggregation ist Controlling.

Weitere Beiträge von „Facility-Management mit Podio“

Im nächsten Beitrag dieser kleinen Low-Code-Gebäudemanagement-Serie, Facility-Management mit Podio (2): Einsätze planen, durchführen, dokumentieren, wird es darum gehen, die Stammdaten-Struktur als Datengerüst einer App zur Organisation von Tätigkeiten wie turnusgemäßen Wartungen und Reparaturaufträgen zu verwenden. Geklärter Einsatzort dank Datenmodell, geklärter Zeitpunkt, geklärte Zuständigkeit, einschließlich Abnahme auch bei Objektbegehungen zur Kontrolle von Gebäuden und Außenanlagen, Kontrolle von Dienstleistungen wie Gebäudereinigung und Umbauarbeiten, Kontrolle von Brandschutz, Prüfung von Arbeitsschutz. Aufgaben und Einsätze planen und einteilen, Auftragserledigung dokumentieren, Controlling durch Echtzeit-Informationen.

Eine solche EOLA Ankündigung hat oft nicht nur Auswirkungen auf das eigentliche Produkt, sondern kann ebenso Auswirkungen auf das angeschlossene Ökosystem haben. Die Nachfolger von Drupal 7, also ab Drupal 8, bieten hierzu ein sehr gutes Beispiel: So wird das Supportende von Drupal 8 vom EOL Datum des zugrundeliegenden PHP Frameworks „Symfony“ bestimmt. Sobald der Support von Symfony 3 im November 2021 eingestellt wird, endet auch die Unterstützung von Drupal 8 und es wird ein Wechsel auf Drupal 9 (Symfony 4) erforderlich.

Dies betrifft jedoch nicht nur Drupal, sondern auch viele andere PHP Projekte, die Symfony als Basis verwenden.

Die nächsten EOL Termine für Drupal

Bedingt durch das Ende von Symfony 3 wird für Drupal 8 der Support im November 2021 eingestellt. Zu diesem Zeitpunkt ist die aktuelle Version Drupal 9. Wer bereits Drupal 8.9 verwendet, für den ist der Wechsel auf Drupal 9 in den meisten Fällen kein großer Aufwand.

Für Drupal 7 sollte das Supportende ebenfalls im November 2021 sein. Aufgrund der Coronapandemie wurde entschieden, das EOL für Drupal 7 um ein Jahr zu verschieben, um Unternehmen und Organisationen mehr Zeit für die Umstellung zu geben. Für Drupal 7 ist jetzt der offizielle EOL Termin der 1. November 2023 (EOL Termin wurde erneut verschoben).

Welche Auswirkungen hat das „End of Life“ Datum?

Kur gesagt: Mit dem Erreichen dieses Datums wird vom Hersteller für das Produkt kein Support mehr angeboten. Bei physischen Produkten bedeutet dies auch, dass keine Ersatzteile mehr offiziell verfügbar sind. Bei Softwareprodukten betrifft dies die Updates einschließlich Sicherheitsupdates, die es ab diesem Datum nicht mehr gibt.

Ist die Software damit unsicher?

Mit dem Erreichen des EOL Datums werden zwar keine Updates mehr veröffentlicht, sollte eine Sicherheitslücke gefunden werden. Das bedeutet jedoch nicht, dass die Software sofort unsicher wird oder ist.

Jedoch steigt natürlich mit zunehmender Zeit das Risiko, dass ein Sicherheitsproblem entdeckt wird, welches offen bleibt und die eigene Installation damit dann verwundbar ist. Je mehr solcher Lücken entdeckt werden, desto problematischer wird dies natürlich für die eigene Installation dieser Software.

Aus diesem Grund ist es sehr ratsam, eine End of Life Ankündigung ernst zu nehmen und die Auswirkungen auf das eigene Unternehmen zu prüfen, dafür notwendige Ressourcen einzuplanen und einen Zeitplan zu erstellen.

Was ist, wenn ich eine Software nach dem EOL weiter verwende?

Wenn Sie sich dazu entscheiden, ein Produkt auch nach dem angekündigten End of Life weiterzuverwenden, können Sie das tun. Sie sollten sich jedoch der Tatsache bewusst sein, dass die Risiken mit jedem Tag steigen.

Security: Sicherheitslücken und fehlende Updates

Wenn eine Software das Ende ihres Lebenszyklus erreicht hat, sind in dieser Zeit oft die meisten Sicherheitslücken bereits geschlossen worden. Diesen Umstand sollten Sie jedoch nach dem EOL nicht dauerhaft herausfordern.

Mit dem Einsatz der Software nach dem End of Life riskieren Sie eine steigende Verwundbarkeit und damit der Gefahr, dass Sie Opfer eines Cyberangriffs werden. Dabei können die Auswirkungen erheblich sein und nicht nur auf die Software selbst beschränkt bleiben. So können sensible Firmen- und Kundendaten in die falschen Hände geraten. Ein solcher Vorfall kann das Vertrauen sehr stark belasten.

Höhere Kosten

Um eine veraltete Software weiterzubetreiben müssen mit der Zeit immer mehr Ressourcen aufgewendet werden: die Kosten steigen. Zudem wird die weitere Entwicklung und Integration in sich verändernde Unternehmensprozesse und Kundenanforderungen erschwert. So wird es immer schwieriger werden, Entwickler für diese Software bzw. der eingesetzten Softwareversion zu finden. Dies betrifft sowohl externe Freelancer, aber auch die Kompetenzen von inhouse Mitarbeitern, wenn diese einmal das Unternehmen verlassen sollten.

Bei Software, die auf einem Server betrieben wird (z.B. alle PHP basierten Projekte), steigt auch hier der Aufwand. Zudem ist das Hosting wiederum eingebunden in verschiedene Produktintervalle: sei es bei den PHP Versionen selbst, dem Betriebssystem oder der Serverhardware.

Viele Hoster gehen auch dazu über, veraltete PHP Versionen (die Programmiersprache in der Drupal geschrieben ist) mit der Zeit abzuschalten. Dies gilt auch für Software, die in einer anderen Programmiersprache entwickelt wurde oder angrenzende Software (z.B. Datenbanken).

Compliance Risiken

Die regulatorischen Rahmenbedingungen für Unternehmen nehmen immer weiter zu und werden strenger. Dies gilt nicht erst seit Einführung der DSGVO. Erst recht für Unternehmen, die auch international sehr stark engagiert sind.

Die Anforderungen dieser Regularien beinhalten sehr oft auch den Schutz von Daten nach dem Stand der Technik. Der Einsatz von Software, bei welcher der Support abgelaufen ist, entspricht dieser Anforderung natürlich nicht.

Von Innovationen abgeschnitten

Jede neue Hauptversion einer Software kommt mit einer Reihe von Verbesserungen, Weiterentwicklungen und neuen Möglichkeiten einher. Zudem werden ständig neue Standards und Best Practices etabliert, welche Unternehmen und deren Software adaptieren muss, um weiter wettbewerbsfähig zu bleiben.

Von diesen Verbesserungen und Integrationen neuer Standard und Entwicklungen werden Sie in Zukunft abgeschnitten sein und das Risiko besteht, dass sie beim Wettbewerb immer weiter zurückfallen können und inflexibel werden. Die Alternative ist, dass Sie die Entwicklungen und Adaptionen inhouse nach dem EOL selbst entwickeln. Dies kann jedoch mit sehr großen Kosten verbunden sein.

Was also tun?

Für den einen oder anderen kann es sehr verlockend sein, ein funktionierendes und eingespieltes System weiterhin zu behalten, auch wenn der Hersteller das Ende der Unterstützung von dieser angekündigt hat oder sie bereits vorüber ist. Jedoch dürfen dabei die direkten und indirekten Risiken und Kosten nicht übersehen werden.

In allen Fällen werden dabei mittelfristig diese Risiken die möglichen Vorteile bei weitem übersteigen. Auch, wenn die Migration auf eine neue Softwareversion selbst mit gewissen Risiken und Kosten verbunden ist.

1. Gründen Sie eine Projektgruppe, die sich mit dem EOL auseinandersetzt.
2. In dieser Gruppe werden die Auswirkungen auf das eigene Unternehmen, dessen Prozesse, Integrationen und anderer Software evaluiert.
3. Dazu gehört ebenso die Prüfung, der vom Hersteller vorgeschlagene Lösungsweg, wie eine neue Version oder alternatives Produkt. Gegebenenfalls können auch weitere Alternativen (z.B. von anderen Herstellern) mit einbezogen werden.
4. Auf Basis der recherchierten Informationen können die Vor-/Nachteile und Risiken abgewogen werden. Im Anschluss dessen kann von der Arbeitsgruppe der Umstieg konkret geplant und mit einem Zeitplan versehen werden.

Berücksichtigen Sie dabei, dass eine solche Vorplanung und Durchführung der Umstellung je nach Komplexität mehrere Monate in Anspruch nehmen kann. Bedenken Sie dabei auch, entsprechende Ressourcen bereitzustellen und Investitionen einzuplanen.

Von den drei identifizierten Gründen, warum Kunden sich abwenden, haben allein zwei einen Bezug auf die Verarbeitung von Daten:

• Intransparente Datenverarbeitung (44 Prozent): Ich habe das Gefühl, das Unternehmen beobachtet mich die ganze Zeit. Ich erhalte E-Mails, obwohl ich mich nicht daran erinnern kann, mich angemeldet zu haben. Ich weiß nicht genau, was mit meinen Daten passiert oder warum sie erfasst werden.
• Nervig (43 Prozent): Ich bekomme zu viele E-Mails oder Benachrichtigung, die für mich keine Relevanz haben.
• Enttäuschung (38 Prozent): Die angebotenen Produkte erfüllen nicht meinem Anspruch, sie sind zu teuer oder die Qualität ist schlecht.

Insbesondere bei den jüngeren Generationen ist das Bewusstsein für die persönlichen Daten stark ausgeprägt: In dieser Gruppe sind es 72 Prozent (Gen Z) bzw. 64 Prozent (Millennials), die sich bei Datenmissbrauch vom Unternehmen abwenden.

Für diese Wahrnehmung der Käufer spielt die eigene Website und die digitalen Services, mit denen der Kunde in Berührung kommt, eine wesentliche Rolle. Die Folgen: Wer an der Datensicherheit spart oder intransparent mit Daten umgeht, der schadet langfristig seinem Geschäft und das mühsam aufgebaute Vertrauen leidet erheblich.

Gleichzeitig steigen damit die Risiken für die Marke immer mehr, weil IT-Strukturen immer komplizierter und kleinteiliger werden. Aus diesem Grund ist es wichtig, ein Bewusstsein für die Sicherheit der Infrastruktur und gespeicherten Daten zu entwickeln und rechtzeitig Maßnahmen zu ergreifen, um diese möglichst umfassend zu schützen. Auch in dem Hinblick, ob alle erfassten Daten überhaupt benötigt werden. Denn Daten, die nicht gespeichert werden, können auch nicht bei einem Datendiebstahl entwendet werden.

Der sichere Betrieb einer Website: Prävention gegen Datenmissbrauch

Die Sicherheit einer Website ist ein komplexes Thema, in dem verschiedenste Bereiche eine Rolle spielen:

1. das verwendete Content-Management-System (CMS) und daran angeschlossene Systeme, wie z.B. das CRM (Customer-Relationship-Management),
2. genutzte Bibliotheken und Drittkomponenten, wie z.B. Javascript Libraries für bestimmte Effekte oder Funktionen auf der Website,
3. Passwörter und Zugänge,
4. Zuverlässigkeit des Hostings und die auf dem Server genutzte Software.

Dabei gilt immer: Die Sicherheit des Gesamtsystems wird vom schwächsten Glied in der Kette bestimmt.

Weniger ist mehr

Eine moderne Website bietet heutzutage eine Vielzahl an Funktionen und Möglichkeiten. Oft ergänzt mittels Modulen, Plugins und anderen Drittkomponenten. Dies wirkt sich jedoch nicht nur negativ auf die Sicherheit, sondern oft auch auf die Performance aus. Demzufolge profitieren Sie mehrfach davon, wenn sie diese möglichst sparsam einsetzen.

Eine WordPress Website mit 20 verwendeten Plugins ist im Durchschnitt 3x anfälliger für einen Sicherheitsvorfall, als eine Installation, die mit nur 5 Plugins auskommt. Dies betrifft jedoch nicht nur auf das CMS zu, sondern alle Bereiche, die im Zusammenhang mit der Website stehen. Ein Klassiker sind hier auch die unzähligen Javascript-Bibliotheken, welche heutzutage bei einem modernen Website-Design zum Einsatz kommen.

Daher gilt: Verwenden Sie möglichst wenige Plugins, Module und Drittkomponenten wie möglich.

Knackpunkt: Erweiterungen für mehr Sicherheit

Sowohl für Drupal als auch WordPress gibt es verschiedene Module bzw. Plugins, welche eine Website automatisch auf bestimmte Schwachstellen hinsichtlich der Sicherheit und Konfiguration aufmerksam machen.

Hier sollte jedoch der Nutzen immer mit den Kosten (jedes Modul erhöht das prozentuale Risiko) individuell abgewogen werden.

Sicherheitsupdates zügig einspielen

Je weniger Plugins oder Module verwendet werden, desto geringer ist auch die Trefferfläche von möglichen Sicherheitslücken und damit dem Bedarf an Sicherheitsupdates. Denn diese sind elementar wichtig für den sicheren Betrieb einer Website.

Insbesondere wenn gängige und beliebte Systeme oder Plugins eingesetzt werden, dauert es - nach Entdeckung einer Sicherheitslücke - meist nicht lange, bis diese Lücken aktiv und automatisiert ausgenutzt werden.

Aus diesem Grund ist es wichtig, sich aktiv über mögliche Sicherheitslücken bei den eingesetzten Systemen zu informieren und bereitgestellte Updates zeitnah einzuspielen. In manchen Fällen können Stunden darüber entscheiden, ob Ihre Website sicher ist oder bereits gehackt wurde.

Einige Content-Management-Systeme geben direkt einen Hinweis in der Administrationsoberfläche, wenn ein Sicherheitsupdate verfügbar ist. Hier im Beispiels das CMS Drupal.

Tipp: Abonnieren Sie am besten auch eine Mailingliste oder Newsletter, um über aktuelle Sicherheitsprobleme von den verwendeten Systemen informiert zu bleiben. So bietet beispielsweise das Drupal Security Team einen eigenen Newsletter an, indem über alle Sicherheitsupdates informiert wird.

Passwörter und Zugänge

Diesen Ratschlag werden Sie sicherlich nicht das erste Mal bekommen haben: Es unterstreicht jedoch, wie wichtig auch sichere Passwörter für den Betrieb einer Website sind.

Die meisten Websites bzw. dahinterliegenden Content-Management-Systeme kommen mit einem Benutzerkonto daher, welches mittels Benutzername und Passwort gesichert ist. Wer dieses kennt oder erraten kann, ist bereits drin. Besonders großer Schaden kann natürlich angerichtet werden, wenn Accounts mit entsprechend großzügigen Berechtigungen, wie von Administratoren oder Redaktion, betroffen sind.

• Verwenden Sie ein möglichst langes und komplexes Passwort.
• Das Passwort sollte keinen Bezug zu Ihrer Person oder Ihrem Unternehmen enthalten (z.B. der Name, Ort, Geburtsdatum etc.).
• Verwenden Sie für jeden Dienst ein eigenes Passwort. Jedes Passwort sollte einmalig sein. Dadurch ist der mögliche Schaden viel geringer, wenn ein Passwort einmal kompromittiert wird.
• Geben Sie keine Passwörter weiter oder teilen Sie sich ein Konto mit mehreren Personen. Jeder Mitarbeiter sollte sein eigenes Benutzerkonto (für die Verwaltung der Website) haben. Dies gilt auch für Praktikanten oder Externe. Nur so ist gewährleistet, dass Zugänge widerrufen werden können, wenn ein Mitarbeiter das Unternehmen verlässt.

Die Sicherheit weiter steigen können Sie, indem Sie den Zugriff auf die Administrationsoberfläche weiter einschränken: Zum Beispiel, indem Sie den Login und auch die Administration selbst nur innerhalb des eigenen VPN (Virtual Private Network) zugänglich machen.
Dies funktioniert jedoch nicht mit allen Content-Management-Systemen bzw. ist manchmal mit Funktionalitäten der Website nicht kompatibel.

Denken Sie auch an Ihren Computer

Vergessen Sie bei aller Sicherheit der Website nicht Ihren Computer. In einigen Fällen erlangen Angreifern den Zugang nicht über eine Sicherheitslücke Ihrer Website, sondern aufgrund Ihres Computers.
Wenn Ihr Computer von einem Virus infiziert wurde und Sie auf Ihrer Website zugreifen, kann es bereits sein, dass darüber die Website übernommen wird. Manchmal wird auf dem Computer auch eine Keylogging-Software abgelegt, die all Ihre Tastatureingaben aufzeichnet und an den Angreifer übermittelt. Dann helfen auch keine besonders sicheren Passwörter mehr etwas.

Von daher ist der Schutz Ihres Computers, Firmen-Netzwerks und aller angeschlossenen Computer genauso wichtig, wie der Ihrer Website.

Nutzen Sie SSL-Zertifikate

Zu einer Website gehört heutzutage auch ein SSL-Zertifikat. Mithilfe des Zertifikats wird die Verbindung zwischen Ihrem Browser oder die Ihres Websitebesuchers und des Servers verschlüsselt. Das sorgt u.a. dafür, dass das Passwort für den Benutzerlogin auch verschlüsselt übertragen und somit nicht mitgelesen werden kann.

Erkennen tun Sie eine verschlüsselte Verbindung natürlich über das „https://“ am Anfang der Internet-Adresse und dem entsprechenden Symbol am Anfang der Adresszeile von Ihrem Internetbrowser.

Überblick über die erfassten Daten

Für das Vertrauen ist es auch wichtig, dass Sie sich regelmäßig einen Überblick darüber verschaffen, welche Daten Sie erfassen. Dazu gehören auch mögliche Tracker und Analysedienste wie Google Analytics, Matomo (ehemals Piwik) & Co.
Prüfen Sie, ob Sie die Dienste bzw. Daten wirklich noch benötigen und dass Sie dies entsprechend in den Datenschutzbedingungen ausweisen bzw. das entsprechende Einverständnis vom Besucher erfassen und diesen entsprechend aufklären.

Auch hier gilt, wie bei den Plugins, weniger ist mehr: Wenn Sie schon Matomo einsetzen, werden Sie wahrscheinlich kein Google Analytics mehr benötigen bzw. andersherum.

Kommunizieren Sie offen und verständlich

Es macht bei dem Besucher Ihrer Website keinen guten Eindruck, wenn Sie schreiben, dass Sie den Schutz der Daten sehr ernst nehmen und möglichst sparsam erfassen. Gleichzeitig haben Sie aber fünf verschiedene Tracker installiert, um das Besucherverhalten zu erfassen und auswerten zu können.

Daher ist es immer vertrauenerweckender, wenn Ihre Aussagen hinsichtlich der Datenverarbeitung auch mit der Realität übereinstimmen. Nicht nur wegen der DSGVO ist Datensparsamkeit angeraten, sondern auch für ein besseres Gefühl bei Ihren Kunden.

Sorgen Sie vor

Auch bei den größten Anstrengungen lässt sich ein Datenvorfall nicht vollständig ausschließen. Sorgen Sie für diesen Fall vor.
Dies betrifft auch die Zusammenarbeit und Abstimmung mit Ihrer IT

Wenn Sie proaktiv und aufrichtig kommunizieren, dabei offen sind, können Sie den möglichen Vertrauensverlust gering halten. Damit dies gelingt, sollten Sie sich auf diesen Vorfall vorbereiten und eine entsprechende Strategie in der Schublade haben:
So sollten Sie beispielsweise klären, wer für die Kommunikation gegenüber den Betroffenen und der Öffentlichkeit verantwortlich ist. Dieser Personenkreis sollte so klein wie möglich sein und möglichst auch Entscheider umfassen, damit die Botschaft einheitlich und stark ist.

Versuchen Sie die möglichen Fragen der Presse und Kunden vorauszusehen, damit bereits im Vorfeld mögliche Antworten vorbereitet werden können. Im Ernstfall können Sie dadurch sehr schnell und effektiv kommunizieren, ohne selbst zu sehr unter Druck zu geraten. Bereiten Sie die Antworten auf verschiedene mögliche Cases vor und prüfen Sie regelmäßig, ob Ihre Annahmen und Antworten noch aktuell sind.

Übernehmen Sie in Ihrer Kommunikation Verantwortung. Versuchen Sie sich möglichst nicht als Opfer eines Angriffs (was technisch sogar stimmt) darzustellen, da dies meist negativ wahrgenommen wird. Wer offen, ehrlich kommuniziert und zu seinen Fehlern steht, der wirkt sympathisch und der Vorfall lässt sich einfacher verzeihen.

Der verantwortungsvolle Umgang mit Daten ist ein Gewinn für Ihr Unternehmen

Bei Datenpannen können Sie nicht nur Vertrauen und Kunden einbüßen, sondern im Optimalfall auch neue Kunden dazugewinnen. Der verantwortungsvolle Umfang wird sich in einer langfristigen und vertrauensvollen Kundenbeziehung auszahlen:

• Wiederholte Einkäufe (65) Prozent
• Empfehlung an Freunde und Bekannte (63 Prozent)
• Teilnahme am Treueprogramm (40 Prozent)
• Positive Bewertungen und Kommentare in sozialen Medien (28 Prozent)

Was ist No Code, was ist Low Code?

Wer programmieren will, muss programmieren können – so einfach bzw. so kompliziert ist es heute nicht mehr! Immer mehr Geschäfts-Software setzt auf eine zusätzliche Schicht zwischen dem Quellcode und der Oberfläche für den Endanwender. Die Begrifflichkeiten in dieser Zwischenschicht klingen dann nicht mehr nach Code, sondern entstammen der Sprache der Geschäftsprozesse, die abgebildet werden sollen, sind also „domänenspezifisch“, sodass der Endanwender sie ohne Weiteres versteht. Grafische Elemente ermöglichen es dem Benutzer, per Drag-and-drop, Strukturen und Abläufe zu „programmieren“.

„No Code“ beschreibt hierbei ein Paradigma, bei denen gar keine Programmierkenntnisse nötig sind, man aber auch nicht programmiertechnisch eingreifen kann, wenn das, was die Software bietet, an irgendeiner Stelle erweitert oder abgeändert werden soll.

Demgegenüber erlaubt „Low Code“ den Einsatz textbasierter Programmierung – in aller Regel nicht ausschließlich, sondern in Ergänzung einer No-Code-Schicht, also gewissermaßen als noch eine weitere Schicht unterhalb des grafischen No Code und oberhalb des Quellcodes. Dabei wird manchmal auf gängige Programmiersprachen wie JavaScript, Java oder C# zurückgegriffen, oft aber auch auf eine eigens entwickelte Skriptsprache. Letzteres hat einerseits den Nachteil, dass man wiederum diese Skriptsprache erst erlernen muss, was andererseits jemandem, der programmieren kann, kaum schwerfallen wird, weil sich solche Skriptsprachen idealerweise an gängigen Sprachen orientieren.

Wem helfen No Code und Low Code?

Für den Profi bringt No- bzw. Low Code an Vorteilen eine erhebliche Beschleunigung der Entwicklung, da viel bereits „fertig“ ist, und günstigstenfalls auch eine erwünschte Vereinheitlichung, die modellgetriebene Entwicklung unterstützt. Nachteilig ist die Beschränkung auf das, was die Plattform einschließlich Low-Code-Möglichkeiten nun mal bietet.

Wer die Logik und Anforderungen der eigenen Geschäftsprozesse gut kennt und sich in Software gern und tief einarbeitet, genannt Power User, in dem steckt möglicherweise ein fähiger Citizen Developer, also ein qualifizierter Entwickler von Geschäftsanwendungen trotz fehlender Programmierfähigkeiten.

Der Benutzer profitiert von mehr Flexibilität in Form schnellerer Umsetzung von Feature-Wünschen. Wegen der geringeren Entwicklungskosten (s.u. „Unternehmer“) profitiert er auch davon, dass Feature-Wünsche überhaupt umgesetzt werden! Nachteilig ist manchmal (so auch bei Podio), dass die Struktur und Optik der Benutzeroberfläche nur eingeschränkt angepasst werden kann.

Tiefere Einblicke über No- und Low Code aus Sicht des Unternehmens, der IT-Abteilung etc. gewährt unser White Paper „Der große Sprung nach vorn: digitale Konzepte für Ihre Geschäftsprozesse“, das im Januar 2022 erscheinen wird.

Podio als No-Code-Plattform

Eine App in Citrix Podio ist, technisch gesprochen, eine Sammlung mehrerer Ansichten auf eine Datenbanktabelle: Einzeleintrags-Formular, Tabelle, Board mit Karten. Eine App anzulegen heißt, eine Datenbanktabelle anzulegen.

Die Felder bzw. Spalten dieser Tabelle erstellt man auf einem No-Code-Bildschirm namens „Vorlage“. In der linken Seitenleiste befinden sich „Bricks“ für alle verfügbaren Feldtypen, die mit der Maus an die gewünschte Stelle der App-Vorlage im Hauptfenster gezogen werden können. Die Feldbezeichnung kann angepasst und im Dropdown spezifische Einstellungen vorgenommen werden. Beim Feldtyp „Kategorien“ werden einer nach dem anderen mögliche Werte eingetragen.

Neben den üblichen Feldtypen (Text, Zahl, Datum, E-Mail etc.) sind zwei von besonderem Interesse: Berechnungsfelder (auf die wir gleich im Low-Code-Abschnitt eingehen) und Verbindungsfelder.

Ein Verbindungsfeld ermöglicht die Auswahl eines oder mehrerer Einträge aus anderen Apps bzw. Datentabellen. So lässt sich z.B. ein Ticket-Eintrag einem Projekt-Eintrag zuordnen oder eine Mitarbeiterin einem Standort.

Mit den beschriebenen Funktionen bietet Podio eine No-Code-Umgebung für beliebig komplexe relationale Datenbankanwendungen – man kann ein Projektmanagement-Board oder ein CRM erstellen ohne eine einzige Zeile Code! Im App-Markt finden sich unzählige schlüsselfertige Apps, die dann den eigenen Bedürfnissen angepasst werden können.

Podio als Low-Code-Plattform

Das Berechnungsfeld nun ist der Punkt, an dem der Low-Code-Bereich beginnt. Tippt man ein @-Zeichen ein, erscheint ein Dropdown mit verfügbaren Feldern, und das nicht nur aus der App, in der man sich gerade befindet, sondern auch aus verbundenen Apps. Diese Verbindung kann zwei Richtungen haben: der Eintrag referenziert (ein Ticket, an dem man das Projekt auswählen kann) oder wird referenziert (das Projekt, zu dem das Ticket, aber auch andere, gehören). Die Werte all diese Felder können nur für Berechnungen genutzt werden.

Berechnungsfelder enthalten Code-Schnipsel der Programmiersprache JavaScript (jedenfalls wesentlicher Teile davon), sodass von einfachen Summen bis hin zu komplexen Kalkulationen hier der Fantasie keine Grenzen gesetzt sind.

Berechnungsfelder können, wie der Name schon sagt, allerlei Werte ausrechnen, aber sie können keine Schreibvorgänge anstoßen, so weit geht die Fantasie nicht! Ein Ticket vom Status „in Arbeit“ auf „erledigt“ setzen? Einen Kommentar schreiben? Das ist keine Berechnung mehr, das ist ein Prozessablauf oder Workflow.

Neben den im „Plus“-Plan für momentan $ 11.20 monatlich pro User enthaltenen grundlegenden „Automated Workflows“, auf die hier nicht weiter eingegangen werden soll, gibt es im „Premium“-Plan für momentan $ 19.20 die „Advanced Workflow Automation“. Früher ein externes Plugin namens GlobiFlow, greifen sie von außen auf Podio zu und „hören“ auf Änderungen des Nutzers, auf das Datum und ggf. auf Aktionen in verbundenen anderen Systemen, und „agieren“ nach Podio hinein, d.h. schreiben Kommentare, ändern Werte oder legen gleich ganze neue Einträge an.

Genau wie im No-Code-Bildschirm von Podio unter „Vorlage anpassen“ wird hier mit „Bricks“ Vieles mit rein grafischen Methoden ermöglicht: soll der Flow ausgeführt werden, wenn ein neuer Eintrag in Podio angelegt wird? Wenn ein Wert geändert wird? Auf welchen Wert? Im „Action“-Bereich können Daten aus allen Podio-Apps verwendet, komplexe Logiken abgebildet und zahlreiche externe Lese- und Schreibvorgänge initiiert werden, wie z.B. das automatische Versenden eine E-Mail, der Export einer Excel-Datei oder ein HTTP-Aufruf an die API eines anderen Dienstes.

Wie bei Podio, so sind auch hier Berechnungen in Low-Code-Manier möglich – wegen der Abstammung von einem anderen Hersteller jedoch nicht wie bei Podio mit JavaScript, sondern mit PHP.

Als wäre das noch nicht genug – und es ist noch nicht genug! – gibt es Plugins von Drittanbietern, die für den professionellen Entwickler weitere, den Rahmen von Podio Workflows sprengende Möglichkeiten eröffnen. Hervorzuheben ist hier ProcFu aus derselben Schmiede, die zuvor GlobiFlow hervorgebracht hat.

ProcFu mutet dem Low-Code-Entwickler eine eigene Skriptsprache zu, eine Mischung aus JavaScript und PHP aber entschädigt durch zahlreiche fertige Skripte, die das Low-Code-Versprechen einer erheblichen Beschleunigung und Vereinfachung der Entwicklung einlösen.

Fazit

Die durch ziemlichen Wildwuchs entstandenen vielen Ebenen von No- und Low Code sind kritikwürdig, und in puncto Test- und Wartbarkeit müssen entsprechend Abstriche gemacht werden. Die Einstiegshürde für Citizen Developer und solche, die es werden wollen, ist jedoch extrem niedrig, und die Grenzen des Machbaren liegen ziemlich weit außen.

Es gibt Anforderungsprofile, für die Citrix Podio unter den unzähligen Konkurrenzprodukten eine hervorragende Wahl ist. Die ausgereiften Kollaborationswerkzeuge und der nicht übertriebene Preis leisten dazu einen Beitrag.

Die Hintergründe, was sich mit Drupal 9 alles ändert und warum sich ein Wechsel nicht nur wegen dem sich zu Ende neigenden Supports lohnt, haben wir auf 22 Seiten aufgeschrieben.

Drupal 7 White Paper herunterladen 

Was Sie in dem Paper finden

1. Was Drupal 7 End-of-Life (EOL) bedeutet
2. Wieso noch nicht alle umgestellt haben
3. Weshalb der Wechsel auf Drupal 9 der letzte große Umstellung ist
4. Wie Sie, Ihre Besucher und Redakteure von Drupal 9 profitieren
5. Die Schritte auf dem Weg zu Drupal 9
6. Ausblick auf Drupal 10

Weitere Informationen finden Sie unter www.d7-migration.de