„Wechseln wir doch auf OpenOffice.org statt MS Office. Kostet nichts und wir sparen jede Menge Lizenzkosten. Und in den Funktionen sind beide Programme gleich ...“ So oder so ähnlich habe ich schon häufig die Gründe für eine Migrationsentscheidung gehört – vorgetragen von EDV-Leitern, Abteilungsleitern oder auch Geschäftsführern. Auch wenn viel Richtiges in der Aussage steckt – die Tücken lauern, wie so oft, im Detail, und sie sind nicht ohne. Zwar dürfte der Umstieg auf OpenOffice.org in der Regel für den normalen Arbeitsplatz kaum eine Herausforderung darstellen, sind doch die Funktionen tatsächlich sehr ähnlich, und die Unterschiede auch für nicht so versierte Anwender schnell zu erlernen. Im Verbund mit anderen Applikationen aber sieht es ganz anders aus. Hier erst offenbaren sich die wirklichen Herausforderungen einer Migration – und die wahren Kosten. Vorab: Unmöglich ist nichts und ich unterstütze jede Migration, nur sollte sich jeder Entscheider bewusst sein, auf was er sich einlässt. Ich möchte hier einmal speziell den Einsatz der Textverarbeitung betrachten, die wohl am häufigsten verwendete Komponente, ähnliche Aussagen lassen sich aber natürlich auch für die Tabellenkalkulation und für Datenbanken treffen. Betrachten wir einen heute typischen Migrationskandidaten: eine Organisation mit ungefähr 2 000 Arbeitsplätzen. Diese Organisation besteht seit mindestens 20 Jahren und hat in dieser Zeit jede Menge „EDV-Revolutionen“ erlebt und entsprechend eingeführt. Heute funktioniert das gesamte Gebilde aus einer stark heterogen geprägten Programm- und Rechnerumgebung, aufgeteilt in Fachverfahren und allgemeine Desktop-Software. Bedingt durch die Quasi-Monokultur auf dezentralen Arbeitsplatzrechnern, wurden im Lauf der Jahre auch die Fachverfahren mit passenden Schnittstellen für diese PC-Welt angepasst, wobei man dann oft auf vorhandene Ressourcen auswich und diese direkt mitnutzte. So konnten viele eigentlich auf einem Großrechner laufende Programme dennoch direkt mit dem PC benutzt und Ergebnisse zum Beispiel in Form eines Briefes ausgegeben werden. Gerade für die Textausgabe hat sich hier die Kombination Windows (Betriebssystem) und Word klar durchgesetzt, eine Variante, die auf fast allen gewerblichen PCs zu finden ist. Auch neuere, desktopbasierende Verfahren bedienten sich der Möglichkeiten von Windows und steuerten das immer vorhandene Office-Paket direkt über das Windows-API an.
Fachverfahren nutzen Word als Ausgabemedium
Die Vorgehensweise ist einfach: Das API von Word ist veröffentlicht, via COM und NET, also direkten API-Aufrufen des Betriebssystems (Windows), lassen sich leicht Word-Dokumente erzeugen und manipulieren und so die Ausgabe von Inhalten aus dem Fachverfahren optimal gestalten. Lässt sich doch nun ein Großteil der Arbeit für individuelle Dokumente auf den Kunden (Anwender) abwälzen. Dieser erstellt in seiner Textverarbeitung eigene Vorlagen mit entsprechenden Schlüsselwörtern oder -Feldern und das Fachverfahren ersetzt oder verändert diese dann anschließend. Gleichzeitig lassen sich andere Verwaltungsarbeiten wie Dokumentenmanagement und Ähnliches über die Schnittstellen leicht realisieren. Nur, ändert man jetzt die Textverarbeitung, bricht das komplette System zusammen, API-Aufrufe gehen ins Leere, Feld- und Wortersetzungen funktionieren nicht mehr, das Verwaltungsmanagement war nie auf andere Datentypen ausgelegt, das Fachverfahren versagt. Klar, auch OpenOffice.org bietet ein API, Dokumente können auch hier extern gesteuert und erstellt werden, Felder und Platzhalter können auch in Writer-Dokumenten ersetzt oder manipuliert werden – nur eben anders als in Word.Auch Writer lässt sich „fremdsteuern“
Die Herausforderung für die Migration heißt nun: Wie schaffe ich es, dass die Fachverfahren trotz Wechsel der Textverarbeitung sicher funktionieren? Der erste Weg wäre, zu den Herstellern der Fachverfahren-Software zu gehen und dort um die Anpassung zu bitten. Doch dazu benötigt man „Marktmacht“, und noch ist OpenOffice.org einfach nicht weit genug verbreitet, als dass jeder Hersteller dies sofort und gerne realisiert. Und doch wäre dies der einzig richtige Weg , alle anderen Möglichkeiten sind „Kompromisse“, und die sind oft nur halbherzig. Doch genau damit müssen wir heute meistens leben. Die Lösung der Fachverfahren lautet dann oft: Schreiben eines „Flatfiles“ an einen definierten Ort, darin Feldnamen und Inhalte. Alles andere ist dann der Migration überlassen. Abzuraten ist auf jeden Fall zu versuchen, die Lösungen aus dem MS-Office-Umfeld möglichst exakt auf OpenOffice.org zu übertragen, sind intern die Programme doch einfach zu verschieden. Der bessere Weg ist auf jeden Fall, sich den Arbeitsablauf („Workflow“) genau anzusehen, das gewünschte Endergebnis zu definieren und dann basierend auf den Ausgangsdaten einen eigenen Weg auf den Grundlagen und Möglichkeiten von OpenOffice.org zu realisieren. Auch wenn dieses Vorgehen zunächst mehr Zeit und Kosten in Anspruch nimmt, so zeigt sich immer wieder, dass nur dieser Weg letztendlich zum Ziel und insgesamt auch zu geringeren Kosten führt.Eigene Wege für OpenOffice.org definieren
Um nun diese sinnvoll in eine Writer-Vorlage integrieren zu können, bieten sich mehrere Möglichkeiten an. Immer jedoch sind die entsprechenden Verfahren (Makros) selbst und neu zu schreiben, vorhandene VBA-Makros helfen hier nichts, und auch die dort beschrittenen Wege lassen sich selten übertragen. Die vom Fachverfahren ausgegebenen Daten liegen in der Regel als Liste von Wertepärchen vor: Platzhaltername – Wert. Die Herausforderung ist nun, diese passend in die Vorlage zu bekommen. Dafür bieten sich mehrere Möglichkeiten an, die alle ihre Vor- und Nachteile haben, im Einzelfall hilft nur eine genau Analyse des gewünschten Ergebnisses.-
·
- Maskierte Platzhalter im Fließtext, z.B. abc}: Vorteil: Der Kunde kann individuell die Platzhalter in seine Vorlagen integrieren, diese mit dem Fließtext formatieren und sie auch in Sonderpositionen wie Tabellen, Textrahmen, Kopf- und Fußzeilen unterbringen. Platzhalter können mehrfach innerhalb des gleichen Textes verwendet werden . Nachteil: Einmal ersetzt, kann auf den Text und die Position nicht mehr zugegriffen werden. Ein Dokument kann somit nur erstmalig erstellt werden. Technikintern: Suchen und Ersetzen von Textstellen. Dies ist ein sehr effizientes und schnelles Verfahren, das auch keinen automatischen Fehler bei nicht vorhandenen Platzhaltern liefert.
- Textfelder als Eingabefelder oder individuelle Variablen: Vorteil: können einfach angesprungen, und der Inhalt kann ersetzt werden. Das Feld bleibt erhalten, man kann also mehrfach die Routinen starten und auch Texte wieder auslesen. Nachteil: Die Formatierung ist nicht beliebig, Eingabefelder „poppen“ bei OpenOffice.org als eigener Dialog auf. Ansteuerung über API etwas aufwendiger.
- Platzhalterfelder: Ähnlich wie Textfelder, jedoch mit folgenden Änderungen: Das Feld „verschwindet“ nach Eingabe eines Textes, ist also nicht ein zweites Mal erreichbar. Die sichere Ansteuerung eines bestimmten Platzhalters via API ist nicht ganz einfach. Vorteil: Platzhalter können auch manuell ausgefüllt werden, nicht per Fachverfahren ersetzte Platzhalter sind für den Benutzer somit ersichtlich.
- Textmarken: Als expandierte Textmarken können Sie fast wie Textfelder verwendet werden und sind sehr flexibel. Vorteil: Beliebig platzierbar, einfache Ansteuerung via API, bei expandierten Textmarken können Textinhalte auch ausgelesen und wieder verändert werden. Nachteil: Textmarken müssen eindeutig sein, für gleiche Inhalte an verschiedenen Textstellen werden unterschiedliche Textmarken benötigt. Eventuell etwas mehr Programmieraufwand.
