Facility-Management mit hierarchischen Podio-Apps

, Podio


Neuauflage des Themas auf aussenposten.de:

Facility Management mit Podio


Die Bewirtschaftung von Gebäuden, Anlagen oder sonstigen Objekten ist etwas, wofür Podio sich wegen seiner Konfigurierbarkeit besonders gut eignet. Eine an die jeweiligen Gegebenheiten angepaßte hierarchische Datenstruktur, z.B. (Standort > Gebäude > Wohneinheit > Raum) oder (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.

Genau so 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.

Beispiel I: Liegenschaftsverwaltung

Podio-Screenshot

In dieser Lösung für Gebäudeunterhaltung bzw. Hausmeisterservice sind Mieteinheiten einem Mietobjekt zugeordnet, die zwei Hierarchiestufen reichen bei einem überschaubaren Umfang zur Strukturierung aus. Die Mieteinheiten enthalten Stammdaten wie die Mietfläche und sind, falls vorhanden, mit dem Mieter verknüpft.

Podio-Screenshot

Die Tickets müssen einer Einheit zugeordnet werden (hier “Ort” genannt, weil die Mitarbeiter das besser verstehen als das abstrakte “Einheit”). Vom Ticket aus kann die Zeit getrackt werden (siehe Zeiterfassung mit Podio). Die Summen der erfassten Zeiten werden am Ticket gebildet, an der Einheit über alle verbundenen Tickets sowie am Objekt über die verbundenen Einheiten.

Beispiel II: Wartung einer Biogasanlage

Podio-Screenshot

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 Appetithäppchen kommen wir nun zur Sache.

Theorie I: Hierarchische Systematik(en)

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

gesamter Bestand
  Hardisser Str. 64 (Standort 1)
    Nr. 64 (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)
        
  Ricarda-Huch-Weg (Standort 2)
    Nr. 10 (Gebäude 2.1)
      EG rechts (Wohneinheit 2.1.1)
        
      EG links (Wohneinheit 2.1.2)
        
      
  Nr. 12 (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.) oder monohierarchische Klassifikation. Jede Klasse hat nur eine Oberklasse. 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 eben. 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 sein. Es gibt also nicht den einen Raum “Wohnzimmer”, sondern in der App mit den Räumen muß für jede Wohnung ein Wohnzimmer-Eintrag angelegt werden. Daraus folgt, daß es in der Räume-App exakt ein Feld für die übergeordnete Wohnung gibt und man dort exakt eine Wohnung eintragen kann, nein: muß. Denn es gibt kein Wohnzimmer ohne Wohnung.

Diese Strenge hilft in vielerlei Hinsicht:

Zuvor aber noch einer obendrauf beim Thema Hierarchie: auch eine polyhierarchische 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” der Datenstruktur wird die Konzepte der Vererbung und der Aggregation erst so richtig attraktiv.

Mit Podio und GlobiFlow läßt sich genau steuern, was vererbt wird und was aggregiert. Zum Beispiel:

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, daß 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.

Theorie II: Fokus durch nur eine Action-App

Nun haben wir eine komplexe Stammdatenstruktur aufgebaut — wie nun die Aufgaben zuordnen? Meine Antwort ist immer dieselbe (vgl. etwa Zeiterfassung in Podio oder Sprintplanung in Podio): alles, was zu tun ist, sollte in den Einträgen einer einzigen “Action App” abgebildet werden (die bei uns immer “Tickets” heißt), nicht mit Podio-Aufgaben am Raum, Aufgaben an der Wohnung, Aufgaben am Haus, Aufgaben am Standort, oder mit einer App für Aufgaben am Haus, einer für Aufgaben in Wohnungen usw. 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.

In dieser einen App sollten dann auch nicht Verbindungen zu verschiedenen Hierarchieebenen der Stammdaten-Systematik durcheinander angewendet werden. Eine saubere Lösung erfordert es, die Ticktes nur Objekten auf der niedrigsten, der feinsten Ebene zuzweisen, also in unserem Beispiel den Räumen oder, falls die einem zu fein erscheinen und es dazu keine App gibt, den Wohneinheiten. Für Arbeiten am Haus, die nicht einer spezifischen Wohneinheit zugeordnet werden können, wie Rasen mähen im Gemeinschaftsgarten, wäre demnach eine generische Wohneinheit z.B. mit der Bezeichnung “ganzes Haus” klug.

Wenn man sich dazu durchgerungen hat, jedes Ticket zwingend einem Objekt auf der niedrigsten Ebene zuzuordnen, kann man trotzdem von GlobiFlow automatisch zusätzlich Felder mit den höheren Ebenen ausfüllen lassen — d.h. am Ticket gibt es dann eine Verbindung zur Wohneinheit (von Hand eingetragen) und zum Haus und zum Standort (von GlobiFlow automatisch eingetragen). Für die Aggregation ist das nicht nötig, die Daten können auch stufenweise weitergereicht werden. Aber dann kann man die Tickets nach den höherstufigen Einträgen filtern und gruppieren, also etwa nur Tickets eines bestimmten Hauses oder Standorts fokussieren.

Wenn man dann weitere vornehme Techniken wie ein Kanban-Board per Status und Zuweisung von Team-Mitgliedern am Ticket implementiert, oder gar noch die eben schon genannte Sprintplanung (dort auch mehr zu Kanban), dann ist es vor lauter Fokus auf die gerade anliegenden Arbeiten wirklich schwierig, das gewohnte Ineffizienz-Niveau noch zu halten.

Schlagwörter: Facility-Management, GlobiFlow, Hierarchie, Podio, Stammdaten