Die Neunziger Jahre - Teil 1

Der Betrieb ging heftig weiter mit unzähligen Beratungen und Verhandlungen um den Abschluss von Betriebsvereinbarungen. Die Themenbreite umfasste so ungefähr alles, was sich einem Computer nicht in den Weg stellte (sieher hier).

Nach wie vor veranstalteten wir viele Seminare, die meisten davon bei uns in der Speicherstadt. Die karge Innenausstattung war dank des an Romantik grenzenden Flairs der Hamburger Speicherstadt kein wirklicher Nachteil, jedenfalls kein show stopper.

Einigungsstellen hagelte es zu Anfang des Jahrzehnts noch reichlich, darunter ein paar Dauerbrenner, die sich über Jahre hinzogen. Doch im Großen und Ganzen war klar, dass die Auseinandersetzung um die Gestaltung der Technik, genauer der computerunterstützten Arbeitssysteme, nicht mehr erkämpft werden musste. Die Notwendigkeit, eine Betriebsvereinbarung abzuschließen, schien allgemein akzeptiert zu sein. Die Themenpalette beschränkte sich keineswegs nur auf den Schutz vor Überwachung. Es ging, zusammengefasst gesagt, um die Qualität der Arbeit, die Arbeitsbeziehungen, die Ergonomie der Software, die Belastungen und Beanspruchungen und die Qualifizierung der Beschäftigten, gelegentlich sogar um Richtlinien für die weitere Entwicklung der Computeranwendungen und die Beteiligung von Mitarbeitenden an dem Software-Entwicklungsprozess. Die Selbstverständlichkeit, dass dies alles zu verhandelnde Themen waren, hatte sich zu einer Art Standard entwicklelt.

Mit Blick von damals in die Zukunft muss man leider feststellen: das sollte nicht so bleiben - ein Aspekt, den wir für die Fortsetzung dieser Geschichte im Auge behalten. Merksatz: Erstrittene Rechte, die nicht wahrgenommen werden, verlieren ihren Wert.

Die Flughäfen

Meine Tätigkeit für den Frankfurter Flughafen hatte sich schnell herumgesprochen, und ehe ich mich versah, hatte ich es auch mit dem Hamburger und Münchener Flughafen zu tun. Später kam noch Bremen dazu. Aber der Reihe nach.

Frankfurt

Viele Tage im Jahr stand die FAG, so das damalige Kürzel für die Frankfurter Flughafen-AG, auf unserem Arbeitsplan. Jetzt hatte ich mit meinem Kollegen Christoph erstmals auch Unterstützung in der Beratung vor Ort. Christoph war Informatiker und verfügte über die seltene Gabe, über den Tellerrand des studierten Fachs hinaussehen. Er war für mich ein kongenialer Kollege.

Das Computerleben eines Flughafens war ein Tummelfeld für so ungefähr alles, was sich nicht gegen Computer wehren konnte: Flugzeugabfertigung, Gepäckverwaltung einschließlich so spezieller Programme wie Baggage Consiliation (damit das Gepäck auch wieder beim richtigen Passagier landete), unzählige Leitsysteme für allmögliche technischen Gerätschaften. Die Daten fast aller Anwendungen hatten einen mehr oder weniger heftigen Personenbezug: es ging um Arbeitszeiten, Personalbedarfsplanung, Personaleinsatzplanung, alles, was mit Abfertigung zu tun hatte, Instandhaltung, Logistik und die informationstechnische Infrastruktur, erstmals um PC-Anwendungen und auch schon um das später nicht mehr vermeidbare SAP.

Von der Errungenschaft der erfundenen Rahmenvereinbarung sollte gleich der Frankfurter Flughafen profitieren. Hier versprach das Konzept wegen der unzähligen Systeme große Vorteile. Dem Vorstand leuchtete ein, dass auf diese Weise ein Stück Planungssicherheit geschaffen wurde und die chronische Abwehr zurückgefahren werden konnte, gegen alles, was aus der Betriebsratsecke kam, nach dem Motto man kann ja nie wissen, womit die wieder um die Ecke kommen.

Der Vorstand ließ sich auf eine große Veranstaltung ein, bei der den über hundert Führungskräften, Personalern, Projektleitern und Linienvorgesetzten der Inhalt der Vereinbarung vorgestellt und zielgruppenspezifisch erklärt wurde.

Hamburg

Wie konnte es auch anders sein, hier ging es ebenfalls um alles, was sich computerisieren ließ, darunter auch Kuriositäten wie zum Beispiel Flugzeuge, die zuviel Lärm machten oder zu spät waren. Sie mussten bereits damals dafür Strafe zahlen - natürlich nicht die Flugzeuge, aber die Gesellschaften, die dahinter steckten. Da waren auf dem Gelände Geräte verteilt, die fortwährend die Lärmpegel an verschiedenen Stellen des Flugplatzgeländes maßen und auf eingebauten Speichermedien aufzeichneten. Die Datenträger wurden fußläufig eingesammtelt, von anderen Kollegen im Büro dann die Markierungen auf dem Zeitstrahl der Messgeräte abgeglichen und mit den Informationen verglichen, die die Flight Information-, Air Traffic Control-, Arrival-/Departure Management-Systeme hergaben. Das alles kein bisschen automatisiert, Informationen von Hand heraussuchen und hoffen, dass die Synchronisation der verschiedenen Infos glaubhaft über die Bühne ging. Was sie aber nicht tat, denn die Beschwerden der Fluggesellschaften nach dem Motto das waren wir nicht hatten fast immer Erfolg.

Modernisierung bedeutete auch damals schon tiefgreifende Veränderungen der Arbeitsabläufe. Qualifikationsengpässe traten auf. Die Angst nicht nur vor minuziöser Überwachung der Arbeit vor unbekannten neuen Anforderungen, auch um den möglicherweise drohenden Verlust des Arbeitsplatzes stand spürbar im Raum. Zum Glück war der Flughafenbetrieb eine Wachstumsbranche, aber der soziale und technische Wandel musste organisiert werden, und wenn's geht bitte klug.

Während einer Dauerbrenner-Einigungsstelle und nach einer Intervention des Aufsichtsrats bekam ich den Auftrag, ein Modernisierungskonzept für die komplette EDV - so nannte sich damals die Informationstechnik - zu erarbeiten.

Computerpower

Unser Rechnerpark erfuhr eine beachtliche Aufrüstung, die uns gleich in eine absolute Spitzenposition katapultierte. Nachdem wir uns eine SUN-Workstation zugelegt hatten, erwarben wir einen der ersten 25 in Europa verbreiteten NeXT-Rechner.

Zur Erinnerung: Die junge Firma Apple hatte nach ihren ersten beachteten Erfolgen gemeint, um nicht weiter auf ein paar Prozent Marktanteilen herumzudümpeln, brauche sie eine business-erfahrene Person als Topmanager. Die Wahl fiel auf John Sculley, der es geschafft hatte, als Chef von PepsiCola den damaligen Marktführer CocaCola zu überholen. Sculley hatte 1985 Steve Jobs nach einem verlorenen Machtkampf aus der eigenen Firma rausgeschmissen. Jobs gründete eine neue Firma namens NeXT, und der Name war gleich ein Programm. Er wollte den ultimativ nächsten Rechner bauen. Anfang der Neunziger Jahre war es dann soweit.

Wir, die kleine tse, besaßen also einen der ersten Next-Rechner in Europa. Design und Funktion waren absolut Spitze. Es gab ein Mikrofon für Texteingabe, das wuselig proprietäre Apple-Betriebssystem war durch ein anständiges UNIX-Innenleben ersetzt, auf dem das nach Jobs genialen Ideen weiterentwickelte grafische Interface draufgesetzt war. Das Betriebssystem NeXTStep bot die weltweit erste objektorientierte grafische Entwicklunsumgebung.

Wir verbanden unser Vax-Ungetüm mit den beiden Workstations und natürlich den übrigen Macs, ergatterten kostenlos eine Sybase-Datenbank, die wir damals für die moderste hielten. Dann schafften wir es, die Sybase-Leute dazu zu bringen, unsere Firma als Versuchslabor für die direkte Verbindung mehrerer Datenbanken untereinander zu begeistern, damals absolutes Neuland. Wir hatten mit PageMaker ein leistungsfähiges Layout-System, und mit Data Views konnten wir eindrucksvoll Prozessdaten in Echtzeit visualisieren. Wir waren bestens mit modernster Technik ausgestattet. So waren wir in der Lage, unserer Kundschaft eindrucksvoll darzustellen, wie die Zukunft der Arbeit computerunterstützt aussehen könnte.

So schleppten wir eines Tages im März 1992 in einem gemieteten VW-Bus unser halbes Equipment nach Fulda, bauten unsere Macs, eine Sun-Workstation und einen Laser-Drucker mitten im Publikum auf, alle Geräte waren vernetzt. Den Next-Rechner platzierten wir auf der Bühne, um auf einer großen Leinwand vor großem Publikum zu demonstrieren, wie die Zukunft der computerunterstützten Arbeit aussehen könnte. Es war eine faszinierende Show. Alles war schnell aufgebaut und funktionierte aus dem Stand.

Es gab eine Reihe ähnlicher Veranstaltungen. Eine Betriebsräte-Konferenz mit geschätzt 200 Teilnehmern greife ich als Beispiel heraus. Ich lud Vertreter von IBM, aber auch Sun und Apple zu Präsentationen ihrer Kunst ein, köderte sie mit der Ansage: dort sitzen die Leute, die eure Umsätze nach unten korrigieren, wenn es Ärger über den Einsatz eurer Produkte vgibt - also lasst euch etwas einfallen, wie ihr das vermeiden könnt. Die IBM-Leute hatten die Botschaft offensichtlich nicht verstanden und führten mit ihrem damaligen Ad-hoc-Query-Produkt die wildesten Auswertungsmöglichkeiten vor. Das sorgte für Stimmung im Saal.Anders die Sun- und Apple-Leute, sagten mir, unter diesem Aspekt hätten sie die Angelegenheit noch nie gesehen.

Der Technik-Zirkus stellte eine beeindruckende Kulisse dar, vor der wir unsere Idee bestens in Szene setzen konnten, Technik von der Spitze der Entwicklung aus human und klug zu gestalten.

Zwischenstand

Es war die Zeit lange vor Big Data. Christoph und ich entwickelten das Konzept, dass Daten zur Steuerung insbesondere der Produktion im Arbeitsprozess verbraucht und nur für die spätere Verwendung benötigte Ergebnisse gespeichert werden. Dazu war kein Arbeitnehmer-Personenbezug erforderlich. Dieser kleine Kunstgriff in die Daten-Architektur ersparte viele Stunden beschwerlicher Verhandlungen, denn über Daten, die nicht vorhanden waren, brauchte man nicht mehr zu streiten.

Betriebsdaten

Im Vergleich mit heute, dreißig Jahre später, mag das hohe Interesse der Betriebsräte am Computereinsatz in der Produktion verwundern. Das Betriebsverfassungsgesetz sah noch bis zum Jahr 2002 bei den Wahlen zum Betriebsrat die Trennung in Arbeiter- und Angestellten-Listen vor. Es gab eine starke Repräsentanz der „Arbeiter“ in den Betriebsräten, oft auch in den Leitungsfunktionen. Das mag eine Erklärung für das hohe Interesse an der Produktion liefern. Der Streit konzentrierte sich auf die Rückmeldeverfahren über den Arbeitsfortschritt, sozusagen die „gläserne Arbeit“.

Standardisierungsprozesse

Die Softwarelandschaft bestand damals aus vielen Spezialsystemen, mit hohem Eigenentwicklungs-Anteil oder. spezifischen Änderungen und Ergänzungen an eingekaufter Software. Die Firmen verfügten, auch wenn sie klein waren, über eigene EDV-Abteilungen. Zu on premises gab es zunächst überhaupt keine Alternative, später dann bei großen Unternehmen die Auslagerung in firmeneigene Rechenzentren. Hardware as a Service war noch nicht angesagt.

Die Standardisierung von Software betraft zunächst die Buchhaltung und die Personaldatenverarbeitung. Ersteres interessierte die Betriebsräte nicht - es ging ja nur um die Verwaltung der Finanzen. Also sah man keinen Regelungsbedarf.

Personaldaten

Platzhirsch im Software-Wald war Anfang des Jahrzehnts PAISY. Der Chefverkäufer der Firma trat gerne mit dem Spruch auf „Es gibt noch immer welche, die meinen, uns Konkurrenz machen zu müssen“. SAP mit seinem Human Resources-Modul tat sich auf dem Markt noch schwer.

Relationale Datenbanken waren noch etwas schrecklich Modernes. Doch unverkennbar war, dass sie sich durchsetzen würden. Sie waren - bei strenger Betrachtung - ein absolutes NoGo für Datenschützer. Denn die Verarbeitung von persönlichen Daten hatte dem Gebot der strikten Zweckbindung zu folgen - ein Grundsatz, der - jedenfalls nach Papierlage - noch heute gilt. Demnach dürfen personenbezogene Daten nur gespeichert und verarbeitet werden, wenn ihr Verwendungszweck vorher genau festgelegt ist.

Sinn und Zweck vor allem einer relationalen Datenbank ist es aber, Daten zu speichern und für beliebige später festlegbare Zwecke wieder herauszurücken, schlimmer noch: für beliebige Kombinationen mit anderen Daten verfügbar zu machen.

Die technisch nicht gewährleistete Zweckbindung musste also mit anderen Mitteln hergestellt werden. Dazu hatten wir die Methode entwickelt,

  • erstens alle verarbeitbaren Daten in einem Datenkatalog und
  • zweitens die erlaubte Verwendung durch je ein Muster der erstellbaren Auswertungen in einem Ausgabenkatalog

verbindlich festzulegen. Das artete im Laufe der Zeit in immer umfangreicher werdende Arbeit aus. Bekannt war das Drei-Haufen-Prinzip für die Auswertungen. Die Dokumente der damals rund dreihundert von den Systemen ausgespuckten Reports wurden buchstäblich in drei Haufen sortiert:

  • der linke Haufen: alle „unverfänglichen“ Reports: Auswertungen, die keinerlei Personenbezug erkennen ließen und auch sonst keine Belange der Beschäftigten zu betreffen schienen,
  • der rechte Haufen: Auswertungen, die man - aus Sicht der Betriebsräte - auf keinen Fall oder zumindest nicht in der vorliegenden Form haben wollte und
  • der mittlere Haufen: Dokumente, die man nicht verstand, hauptsächlich wegen der verwendeten Abkürzungen in den Tabellen-Kopfzeilen.

Der linke Haufen war zum Glück der größte, um ihn musste man sich nicht weiter kümmern. Der rechte Haufen enthielt oft nur ein knappes Dutzend von Dokumenten. Um die wurde dann in den Verhandlungen gestritten. Der mittlere Haufen führte dazu, dass man sich erst einmal die Abkürzungen erklären ließ. Dann wanderten die Dokumente entweder auf die linke oder rechte Seite. Mein Kollege Lars beschwerte sich des öfteren über die Tage ziemlich öder Arbeit, die er mit der Sortiererei verbringen musste. Die Kolleginnen und Kollegen der Betriebsräte fanden das Geschäft ebenso ätzend langweilig. Mir wurde klar, dass wir uns etwas anderes einfallen lassen mussten. Aber die Haufenwirtschaft florierte noch ein paar Jährchen. Der Augenblick, die Reißleine zu ziehen, war für mich gekommen, als bei einem größeren Pharma-Unternehmen die Anlage 3 Ausgabenkatalog zum System PAISY mehrere Etagen Regalbretter mit Hängeordnern ausfüllte. Mir war klar: Eine neue Idee musste her, eine Veränderung der Spielregeln war angesagt.

Neue Spielregeln

Wir begannen damit, die Personaldaten nach dem Grad ihrer Überwachungseignung zu sortieren, wohl wissend, dass man das als Datenschützer nicht tun sollte. Wir hatten selber eindrucksvoll demonstriert, wie schnell „harmlose“ Adress-Informationen hochsensibel werden konnten, wenn die Adresse mitten im Epizentrum kravallartiger Auseiandersetzungen um Hausbesetzungen lag. Trotzdem sorgten wir dafür, dass die Haufenwirtschaft für die im einzelnen zu regelnden Auswertungen auf solche über Bearbeitungszeiten für einzelne Arbeiten, Fehlzeiten aller Art, Überstunden, Beurteilungen, besondere Qualifikationen und ähnliches begrenzt wurden. Insbesondere legten wir Wert darauf, dass keine bewertenden Daten über Charaktereigenschaften und das Verhalten der Beschäftigten erhoben und verarbeitet werden durften. Somit war die eingedampfte Haufenwirtschaft wieder für ein paar Jahre gerettet.auf dem Markt