An alle Mitglieder der IPDT/ASF Arbeitsgruppe im GSE ... - IBM

An alle
Mitglieder der IPDT/ASF
Arbeitsgruppe im GSE
Protokoll der Frühjahrstagung vom 24. - 26.4.2002
24.4.2002:
1. Begrüßung, Organisatorisches
Herr Hobinka in seiner Eigenschaft als neu berufener Chairman begrüßte die Teilnehmer
und stellte die punktuell geänderte Agenda und das organisatorische Umfeld für die Tagung
vor.
Es wurde beschlossen, das Protokoll in Zukunft nicht mehr per Post in Papierform an die
Teilnehmer zu verschicken, sondern per E-Mail inkl. den Vortragsfolien in PDF-Form.
2. Vortrag „Massendruck aus einer Intranet-Anwendung über HTML bzw. XML“
(Bernd Geißelhardt, Allianz, s. File Massendruck-ueber-HTML-Allianz.pdf)
Herr Geißelhardt berichtet, dass es in dem Projekt um Angebote für die Mitarbeiter von
Firmen-Großkunden geht, die pro Mitarbeiter der betreffenden Betriebe erstellt werden. Sie
enthalten sowohl Hoch- wie Querformat als A4. Die Angebote werden paketweise direkt über
den jeweiligen Betrieb verteilt, so dass (vorerst) keine Kuvertierung und kein Postversand
anfällt.
Die Herausforderung war, dass eine bestehende APL-Intranet-Anwendung, die bisher über
den Browser auf dem PC ausdruckte, innerhalb von 3 Monaten durch Umstellung auf HTML-
Output auf Massendruck getrimmt werden musste. Zur Diskussion stand eine reine
dezentrale Lösung und eine zentrale Drucklösung bei der AGIS:
Bei der dezentralen Lösung sind die Kosten pro Druckseite auf dezentralen Druckern höher,
das Handling erfordert entsprechende Personalkapazitäten, um 20.000 Seiten pro Tag (=
120 kg Papier pro Tag) zu bearbeiten, sowie 2-3 kleine, voll ausgelastete Lexmark-Drucker.
Die Formatierung über Browser ist zu langsam (Formatierungszeiten von mehreren Stunden
pro Tag) und zu unsicher (die Überwachung der Formatierung ist nur manuell möglich) und
die Browsereinstellungen (Ränder etc.) beeinflussen das Druckergebnis „bis zur
Unbrauchbarkeit“. Damit schied diese Lösung aus.
Bei der zentralen Druckerlösung, die umgesetzt wurde, wird ein externer Formatierer
benötigt. Das bedeutet zusätzliche Softwarekosten, eine Runtime-Plattform (AIX- oder NT-
Server) und die Bewältigung folgender Probleme: Aus der HTML-Anwendung muss der
Output an den Formatier-Server übergeben werden, der seinen Output wiederum in die JES-
Spool abstellen muss. Außerdem musste die Allianz-Hausschrift Sonoran Sans Serif durch
Arial ersetzt werden und damit auch das Problem möglichst vergleichbaren Aussehens
sowie gleicher Laufweiten.
Dafür wurde die APL-Intranet-Anwendung umgebaut, die Formatierungssoftware
DOPE/Script von Ion und Compart in der AIX-Version installiert und der HTML-Code mit der
Konvertierungssoftware abgestimmt. Über zusätzlich eingerichtete Listennummern wurde die
Zuordnung zum Kunden geregelt.
Das Ergebnis ist nun eine erweiterte HOST-Anwendung mit der Wahlmöglichkeit zwischen
zentralem und dezentralem Druck. Der Output der Anwendung wird per FTP an einen AIX-
Server übertragen, mit DOPE/Script von HTML nach AFP konvertiert und über den HOST-
Spool gedruckt. Über Metatags wird die Übergabe zusätzlicher Infos eingesteuert, wie „längs

und quer drucken“ und auf welchem Drucker gedruckt werden soll. Die Anwendung ist nach
den Worten von Herrn Geißelhardt stabil und flexibel, das Interface zwischen Anwendung
und Konverter einfach anzupassen. Und last but not least: Der Fertigstellungstermin konnte
eingehalten werden.
3. Vortrag „Neues ‚altes’ von IBM“
(Günter Schöllmann, IBM, s. File ASF-News-Schoellmann.pdf)
Herr Schöllmann stellt die neue organisatorische Eingliederung des ASF-Bereichs in den
Bereich WebSphere Solutions und Services vor. Neuer verantwortlicher Manager für ASF
und REXX ist Manfred Schweizer.
Im folgenden berichtet er über den aktuellen Wartungsstand von ASF: Zwingende
Voraussetzung für alle neueren Produktstände, Umstellungen etc. ist UQ47724 und höher.
Die neueren Fixes für Batch-Programme unter DB2 sind FSNBRUL, FSNBRRL und
FSNCEXPI und für die Online-Programme UQ58542, UQ59736 und UQ61024.
Die Problemunterstützung ist nun folgendermaßen organisiert:
Alle Probleme müssen zunächst bei der zentralen Problemannahme über die Tel.-Nr.
0800-426-6201 gemeldet werden. Der zuständige Software-TA sitzt in Mainz. Es handelt
sich in diesem Fall aber nicht um ein spezielles ASF-Team. Das Change-Team für ASF ist
im Labor in Böblingen und dort zuständig für „Telefonseelsorge, Dump-Analyse und den Bau
von Fixes“ und ist dort rund um die Uhr an allen Wochentagen erreichbar.
Zur Selbsthilfe bei Problemen stellt Herr Schöllmann die technische Unterstützung
(„eSupport“) übers Internet vor. Zu finden sind über die ASF Support Page
http://www.ibm.com/software/office/asf die Problemmeldungen (PMR’s), die häufig gestellten
Fragen (FAQ’s), technische Hinweise (HAT’s), APARs, die IBM Literatur zu ASF sowie die
Rubrik „My Software Support“, letztere über eine angepasste Support-Seite erreichbar:
http://www.ibm.com/software/support/mysupport.
4. Vortrag „Weiterentwicklung der grafischen Oberfläche ASF – inkl. Demo“
(Dietmar Somfleth, IBM, s. File ASF-Technologie-und-Entwicklungsstatus.pdf)
Herr Somfleth stellt im ersten Teil seines Vortrags die Technologie des neuen ASF Web
Clients vor:
ASF als Mainframe-Anwendung wurde vor vielen Jahren designed und entwickelt für
Geschäftsvorfall-angepasste, personalisierte Schreiben, bei denen Text und Daten zu
vermischen sind, um als „richtige“ Schriftstücke auf Papier gebracht und mit hohem Output-
Volumen produziert zu werden. Dazu gehört in aller Regel eine enge Integration mit den
Kundenanwendungen. ASF ist daher eine typische „Core Application“ von großen Kunden
(Versicherungen, Banken, öffentlicher Sektor). Als Sprache zur Textformatierung diente
bisher DCF/SCRIPT.
Mit der Weiterentwicklung der Software-Umgebung bei den Kunden ergaben sich einige
neue Anforderungen an ASF bezüglich Modernisierung: Ein GUI für die Anwenderoberfläche
wurde erforderlich – mit Bausteinauswahl, grafischer Darstellung der Dokumentstruktur,
komfortablem Editor für die Texteingabe, Eingabemöglichkeiten von Textplatzhaltern und
einer WYSIWYG-Voranzeige. Weiterhin wurde die Implementierung eines Thin Clients
notwendig. Diese Neuerungen hatten zugleich die bisherigen Grundlagen von ASF, die DCF-
Formatierung und Nachbearbeitung sowie die Dokumentenvorlagen, -bausteine und
Programme, im Sinne eines Kundeninvestitionsschutzes zu berücksichtigen.
Während einerseits die 3270-Funktionen im MVS-Batch-Bereich auf Basis von IMS und
CICS ebenso wie die Formatierung, Nachbearbeitung als auch die Schnittstellen zu den
Kundenprogrammen unverändert erhalten geblieben sind, sind nun neue Elemente
hinzugekommen: Ein Steuerprogramm für die Kommunikation mit dem Server

(FSNWEB1C/I), XML Building Services für das Lesen der ASF-Datenbanken und den
Aufbau von XML-Strukturen, ein Server Command Prozessor für die Verarbeitung der
Server-Befehle sowie Erweiterungen in der Administration zur Unterstützung neuer GUI-
Funktionen.
Diese Komponenten basieren auf dem WebSphere Application Server (WAS) unter zOS
Unix System Services bzw. Windows: Benutzt werden neben statischen Komponenten
Servlets für die Kommunikation zwischen MQSeries, IMS Connect und CICS Universal Client
(„ASFProxy“) und für die Darstellung der auf dem Host erzeugten XML-Objekte
(„ASFObjects“). Daher werden für den WAS in der Version 3.5 bzw. 4.01 eine Servlet-Engine
und ein HTTP-Server benötigt (bei V4.01 als „alternate configuration“ wird keine DB2 V7 und
keine LDAP-Server benötigt). Herr Somfleth betonte, dass der WAS kein portiertes Produkt
ist, sondern auf zOS zugeschnitten neuentwickelt wurde und daher sehr skalierbar ist und
die typischen zOS-Features unterstützen kann.
Der Client basiert auf JavaScript (für die Verarbeitung der Anwenderreaktionen und zur
Speicherung des Verarbeitungsstatus), verwendet Applets zur Server-Kommunikation und
„intelligenten Zwischenablage“ und mit einem Style-Sheet-Prozessor zur Verarbeitung des
XML-Datenstroms und zur Erzeugung von dynamischem HTML (DHTML). Er ist lauffähig auf
dem Internet Explorer ab V5.5 mit den XML-Versionen 3.0 bzw. 4.0 und empfängt XML und
sendet Befehle zurück. Herr Somfleth zeigte ein Beispiel für die Integration von ASF, ASF
Web Client und Kundenprogrammen (s. Folien) und demonstrierte anschließend den
ASF 3.3 Web Client.
Die Portierung des Web Clients von NT auf zOS ist mittlerweise fertig. In Entwicklung sind
derzeit noch eine AFP nach PDF- und eine DCF-von/nach HTML-Konvertierung sowie einige
Besonderheiten beim PDP-Aufruf.
Der Web Client wird als Produkt noch in diesem Jahr verfügbar sein. Mittlerweile gibt es
bereits eine Produkt- und Servicenummern, Formnummer für die neuen Manuals und Preise.
Das Packaging wurde dahingehend geändert, dass nun ASF 3.3 aus dem Vorgänger-
Release 3.2 plus dem DC Feature besteht, also das Feature mit der Basis verschmolzen
wurde und damit kein separates Feature mehr ist. Die Komponenten Document Writing
feature, Application Connectivity feature, die Schnittstelle zu OfficeVision/MVS und zu
DISOSS und der ASF/APF-Client sind nicht mehr verfügbar.
Der ASF Web Client für die Serverplattform zOS (OS/390) wird eine reguläre Produktversion
und als separates ASF-Feature erhältlich sein. Beim Web Client für Windows, der in jedem
Fall auch herauskommen wird und als Einsteigerversion für WebSphere-Newcomer gedacht
ist, ist noch offen, ob er als ASF-Feature oder als separates Produkt angeboten wird. Die
Portierung auf andere Server-Plattformen wie AIX und SUN wird es nur bei entsprechender
Nachfrage bzw. Projektierung geben.
Die Änderungen im klassischen ASF-Umfeld sind folgende:
Es gibt nun bei Datenbank-Listen im DB2-Umfeld eine Cross-Reference-Suche, welcher
Parameter in welchem Baustein und welcher Baustein in welchen Vorlagen (=LTD) zu finden
ist.
Für die GIL-Wartung gibt es neue Felder für den Web-Dialog: Die Definition von
Schlagworten, LTD-Attribute für den ersten bzw. letzten Baustein und eine Formatierinfo im
Textbaustein.
Bei den Benutzerprofilen kommt ein Eintrag für die Benutzung der Web-Oberfläche hinzu.
Bei den Verarbeitungsoptionen gibt es nur noch Multi-Segment LRRs. Beim LRR-Layout
kommen für die SLL zu den unveränderten 3270-LRRs neue Web-LRRs hinzu. Die
Standardeinstellungen der CLL bleiben gleich.

Was Migrationsanpassungen angeht, sind bei den Datenbanken folgende Schritte zu
berücksichtigen: Es gibt Migrationsprogramme für GIL und SLL bei VSAM-DL/1-DB und
neue Spalten bei DB2 (ggf. muss reorganisiert werden). Die Exit-Programme müssen kopiert
und angepasst werden: Es betrifft den Plausibility Exit (FSNHPLS), den Termination Exit
(FSNLCME) und den Deferred Print Exit (FSNLCME). Die Logik kann beibehalten werden,
nur die Schnittstellen sind anzupassen. Die SIB 0/1 bleibt unverändert. Es wird zusätzliche
TxCode und Programmnamen geben (FSNWEB1, WEBC, WEBI, WEBR) und Änderungen
in den Kundenprogrammen: In den Kundenprogrammen muss der direkte Aufruf des Web
Clients eingefügt werden (alternativ kann FSNASF1 aufgerufen und der Web Client im
Benutzerprofil eingetragen werden. Als neue SIB-1-Funktionen für die Web-Oberfläche gibt
es einen Einfüge-Dialog für die Vorbelegung von Dialog-Feldern und eine optionale
Unterdrückung im Bausteinauswahlbild bei der Übergabe von Kopf- und Schlussbaustein.
Weiterhin gibt es eine neue SIB-2-(URL-)Schnittstelle für den Aufruf des Web Clients aus
Java-Programmen.
Die Preise sind folgendermaßen gestaltet:
Der Preis von ASF 3.3 ist gleich dem Preis von der Basis 3.2 plus dem DC-Feature.
Die monatlichen Lizenzgebühren für das Web Client Feature (Bezeichnung: Document
Connect für ASF) werden bei 10-15% des DC Feature-Preises liegen und Unlimited bzgl. der
eingesetzten Server sein.
Bei den Performance-Betrachtungen ist die „3-Säulen-Architektur“ (Client – Server – Host
und dazwischen das Netz) zu betrachten. Die ersten Messungen im Labor wurden mit den
AKTools der IBM gemacht, die zur Simulation von Hunderten IE-Anwendern die TCP/IP-
Port-Aktivitäten aufzeichnen und viele Clients simulieren (Diese Tools sind auch
lizensierbar – demnächst auf der „alphaworks“ Website). Die gemessene Netzbelastung war
unerwartet niedrig. Die Antwortzeiten kamen zu einem Drittel vom Host und zu zwei Dritteln
vom Client und Server. Der größte Verbraucher war die XML-Verarbeitung. Berücksichtigt
werden sollte auch, dass die Version 6 vom IE schneller ist als die Version 5.5 und die
Microsoft-XML-Version 4.0 schneller als die Version 3.0.
Bei den anschließenden Fragen hat Herr Somfleth noch folgendes festgestellt:
Es sollen verschiedene Formate in Zukunft unterstützt werden.
Der folgende im ursprünglichen Protokoll gestandende Satz "Die Wartung von ASF Version
3.2 ist gekündigt und tritt nach 12 Monaten in Kraft." wurde von Herrn Somfleth in einer Mail
vom 28.6.2002 wie folgt korrigiert:
"In Ludwigsburg habe ich gesagt, daß die IBM nach Verfügbarkeit von ASF 3.3 das Produkt
ASF 3.2. vom Marketing zurückziehen wird. (Diesen Prozeß hatte ich letztes Jahr auf dem
Guide in Münster erläutert). Ein halbes Jahr danach erfolgt die Ankündigung der
Zurückziehung vom Service, welche wiederum 12 Monate nach Ankündigung wirksam wird.
Ich möchte ausdrücklich betonen, daß vom Serviceende dann nur die Kunden betroffen sein
werden, die heute das ASF DC feature einsetzen.
Umgekehrt bedeutet das auch, daß sich Kunden, die heute das ASF DW feature oder
Application Connectivity einetzen, sich bezüglich eines Service-Endes keine Sorgen zu
machen brauchen. Hier ist überhaupt nicht daran gedacht, die Wartung von ASF 3.2.
einzustellen."
Beim Document Connect Feature sind nicht mehrere Versionen notwendig.
Der Editor orientiert sich an den zugehörigen Bausteinen.
Als AFP-Viewer kann der jeweils gewünschte benutzt werden.
Beim nächsten Guide wird voraussichtlich ein Pilot-Kunde vorführbar sein.

25.4.2002:
5. Begrüßung durch Herrn Michel:
Herr Michel, Wüstenrot Bank, begrüßt als verantwortlicher Ausrichter dieser Guide-Tagung
die Teilnehmer.
6. Vortrag „Der W&W-Konzern stellt sich vor“
(Dietmar Hobinka, Wüstenrot Bank, s. File W&W_Unternehmenspräsentation.pdf)
Herr Hobinka stellt die Wüstenrot & Württembergische AG vor:
Durch den Zusammenschluss der beiden Traditionsunternehmen Wüstenrot und
Württembergische entstand ein neuer Finanzdienstleistungskonzern mit Sitz in Stuttgart. Er
versteht sich als „Vorsorgekonzern“ mit einem in dieser Form in Deutschland einmaligen und
ausgewogenen Produktangebot aus einer Hand: Von der Altersvorsorge und der
Baufinanzierung über die Vermögensbildung bis hin zum Risikoschutz.
Der W&W-Konzern geht davon aus, damit der jungen wie auch der immer älter und
vermögender werdenden Generation gerecht zu werden – mit dem Ziel lebenslanger
Betreuung. Außerdem setzt er auf die Vertrautheit und das Vertrauen in beide Marken.
Nach einem geschichtlichen Abriss, in dem Herr Hobinka den Werdegang der Konzernfirmen
kurz erläutert (s. Folien), geht er auf die fünf Kerngeschäftsfelder des Konzerns ein:
Schaden-/Unfallversicherung, Personenversicherung, Bausparen, Baufinanzierung und
Investmentprodukte sowie auf die aktuellen Geschäftszahlen.
Erklärtes Ziel des Konzerns ist die optimale Marktdurchdringung durch seine Zwei-Marken-
Strategie. Mit 6.000 Außendienstpartnern verfügt er über den fünftgrößten mobilen Vertrieb
in Deutschland. In den drei traditionell starken Kerngeschäftsfeldern (Bausparen,
Baufinanzierung und Schaden-/Unfallversicherung) ist das Ziel, zumindest Marktwachstum
zu erreichen, bei den Kerngeschäftsfeldern Personenversicherung und Investmentprodukte
dagegen ein deutlich stärkeres Wachstum als der Markt.
Dies soll durch Intensivierung des Cross-Sellings (wechselseitiger Verkauf der
Konzernprodukte bei rund 6 Millionen Konzernkunden), Optimierung des
Beteiligungsbestands und Verstärkung der Position in Osteuropa erreicht werden.
7. Vortrag „ALFA (Allfinanzarchitektur bei der Württembergischen)“
(Ralph Seppelt, W&W IT, s. File GSE-Frühjahrstagung 2002 ALFA 2002-04-25.pdf)
Herr Seppelt berichtet über das Entstehen einer Allfinanzarchitektur im W&W-Konzern.
Der Ausgangspunkt für die IT-Strategie des W&W-Konzerns ist die breite Palette von
Finanzprodukten, der Einsatz des Außendienstes, die Umsatzsteigerung durch Cross Selling
und die Offenheit für zusätzliche Partner. Daraus leiten sich als strategische Projekte die
konzernweite Außendienstunterstützung, ein gemeinsames DV-System für das Kerngeschäft
der Bausparkassen, diverse Internet- und Intranetanwendungen, ein komponentenbasiertes
Anwendungssystem Schaden (Leistung), eine Vertragsverwaltung für die
Personenversicherung (Leben) und die Nutzung der Beratungsdaten für Abschluss und
Sachbearbeitung bei der Bausparkasse ab.
Ausgangslage für diese Strategien sind die technische und fachliche Heterogenität der
Einzelunternehmen, das Nebeneinander von Online- und Batch-Betrieb sowie nicht
vorhandene Schichtentrennung und Backend-Services.
Daraus leiten sich die Forderungen nach durchgängigen Geschäftsprozessen, der Einsatz
von Standards und Standardprodukten bei strategischen Aufgabenfeldern, ihre

Skalierbarkeit, das Ziel „time to market“, die 24*7-Verfügbarkeit und ihre
Wiederverwendbarkeit verbunden mit einem orts- und zielgruppenneutralen Zugang ab.
In Projektstufe 1 sollte daher die zukünftige All-Finanzarchitektur ALFA als ausreichend
breite technologische Basis für alle existierenden und künftig zu bauenden Fachsysteme
festgelegt werden.
In Projektstufe 2 soll eine Entscheidungsvorlage zum weiteren Vorgehen erstellt werden.
In der Stufe 1 wurde nach der Festlegung des Projektteams, der Begriffsdefinitionen für das
Architekturmodell und der Ist-Erhebung ein Anforderungskatalog erstellt, der den vier großen
Lösungsanbietern IBM, SAP, Microsoft und Software AG vorgelegt wurde. Nach
ausführlichen Abwägungen der Vor- und Nachteile entschied man sich für die IBM. Das
detaillierte Architekturmodell ist in den Folien dargestellt.
8. Vortrag „Das Dokumentenmanagementsystem (DMS) der Wüstenrot Bank“
(Peter Zibold, Wüstenrot Bank, s. File dms_optia_042002.pdf)
Herr Zibold stellte zunächst den Ausgangspunkt des Dokumentenmanagementsystems
Optia der Wüstenrot Bank vor: Aufgabenstellung war ein Dokumentenarchiv, das zugleich
als Bearbeitungs- und Informationssystem für eine effizientere und kundenorientierte
Sachbearbeitung dienen sollte.
So wurde auf Basis von IBM VisualInfo 1994 im Bereich Einlagen ein Scan- und
Indexsystem unter OS/2 eingerichtet. 1998 wurde das Scan- und Indexsystem auf InputAccel
von Actionpoint als Capture-System und VisualInfo serverseitig auf AIX und clientseitig auf
NT umgestellt. 2001 kam der Bereich Effekten hinzu.
Der InputAccel-Server arbeitet täglich ca. 5.000 Seiten ab, die mit einem Kodak-Scanner
5500 D eingescannt werden. Die mit 5 Index-Clients indizierten Dokumente werden in den
bei der Wüstenrot Bank entwickelten Optia Dokumenten Prozessor (ODP) exportiert.
Der Optia Dokumenten Prozessor bindet Host-Daten ein, verwaltet Stamm- und Kontoordner
und verteilt die Dokumente über eine Arbeitsverteiltabelle maschinell an die Sachbearbeiter.
Der Optia-Client basiert auf dem IBM Content Manager Client V7.1 (dem Nachfolger von
VisualInfo) und enthält eine Workpool- und Gruppenarbeitskorbverwaltung, die eine
Priorisierung der Dokumente erlaubt. Ein Teil der Dokumente kommt als Fax herein und wird
automatisch mit der Lösung FaxPlusOpen von Intercope in das
Dokumentenmanagementsystem integriert. Erreichtes Volumen im Archiv und eine
Übersichtszeichnung sind in den Folien abgebildet.
Dieses Jahr neu hinzugekommen ist die Ausgangspostverarbeitung: Die dort erzeugten
AFP-Dokumentenspools werden mit dem Compart-Produkt DocBridge Mill in
Einzeldokumente getrennt und indiziert. AFP-Rohdaten und –Resourcen werden mit den
bislang existenten Resourcen im Archiv abgeglichen und, falls dort nicht bereits abgelegt, als
neue Resourcen mit den Dokumenten an den Optia Dokumenten Prozessor zur weiteren
Verarbeitung und Ablage im Archiv übergeben. Um neben den eingescannten TIFF-
Dokumenten auch die AFP-Dokumente anzeigen zu können, wurde der bisher vom Optia
Dokumenten Prozessor verwendete Wang-Viewer durch den Compart-Viewr DocBridge
View ersetzt.
Ein wesentliches Element des Optia-Projekts war das Projektmanagement: Ein Projektteam,
in dem alle gleichberechtigt waren, ein monatlich und nach Bedarf tagender
Projektlenkungsausschuss sowie eine sehr intensive Integration aller beteiligten Mitarbeiter
in die Entscheidungsprozesse haben sehr wesentlich zu dem Erfolg dieses Projekts
beigetragen.
Die Erfahrungen und den Nutzen fasste Herr Zibold folgendermaßen zusammen: Das Optia-
System erlaubt mit seiner Priorisierung eine sehr schnelle und genaue Postverteilung

(Irrläufer werden sofort erkannt). Die zu bearbeitenden Vorgänge haben sehr geringe
Liegezeiten, die Auskunftsbereitschaft am Telefon hat sich verbessert; es kommt zu keiner
Doppelbearbeitung mehr. Der Zugriff auf die Kundenakte ist schnell und eben nicht mehr
papierbasiert (Nur Urkunden müssen aus rechtlichen Gründen weiterhin in Papierform
abgelegt werden). Die Mitarbeiterverantwortung wurde ebenso gestärkt, wie die neue
Arbeitsgruppendynamik für mehr Produktivität gesorgt hat. Die Übertragbarkeit des Systems
auf andere Abteilungen ist gegeben.
9. Vortrag „Bürokommunikation CTV bei der Württembergischen“
(Michael Walter, W&W IT, s. File CTV- Württembergische.pdf)
Herr Walter stellt die Entwicklung, Vorgänge und Abläufe sowie die strategische Ausrichtung
des Bürokommunikationssystems CTV (Computer-gestützte Textverarbeitung) bei der
Württembergischen auf Grundlage von ASF vor.
In einem Abriss der Entwicklungsgeschichte zeigt er, wie aus den ersten Entwicklungen
eines Termin- und Nachweissystems bei der ARA (Allgemeinen Rentenanstalt) und einem
Referenzsystem nach demselben Konzept bei der Württembergischen Feuerversicherung
(WF) auf Basis von IPDT über die Einbindung von Zentralinkasso (ZIK), Provision und
Schaden sowie über die Harmonisierung der CTV-Produktion von der Württembergischen
Leben (WL) und Württembergischen Versicherung (WV) die Eingliederung in die
Württembergische Anwendungsarchitektur (WAA) die heutige ASF-Infrastruktur entstanden
ist.
Ziele waren Kundenorientierung, reibungslose Sachbearbeitung und Wirtschaftlichkeit. Die
Kommunikation über Geschäftsvorfälle war die zentrale Aufgabe dieser Implementierung.
Der typische Vorgang und Ablauf von CTV sieht folgendermaßen aus:
Der Sachbearbeiter in den Anwendungen Leben, Zentralinkasso, AIS, Schaden und
Bestandsführung gibt Daten in seinem Anwendungsbildschirm ein oder steigt direkt über
ASF ein, ergänzt die Eingaben im CTV-(ASF-)Dialog oder seiner Anwendung in Kombination
mit der Textanzeige, der Brief wird vom Vorgesetzten gegengelesen und freigegeben und
durch den Sachbearbeiter korrigiert und schließlich ausgedruckt oder herausgefaxt. Zugleich
wird der Brief im Referenzsystem als elektronische Akte abgelegt und ist dann im Klartext
rekonstruier- und druckbar. Im Halbjahresabstand werden die Briefe verfilmt.
Hierbei kommen die folgenden Abläufe zum Tragen:
Soweit der Sachbearbeiter aus den Anwendungen heraus einen CTV-Dialog aufruft, werden
aus dem Tabellensystem TOMAS/PVS Steuerungsparameter wie z.B. Formular-Nr.,
Postweg und Anzahl Kopien als auch WAA-Textbausteine zugesteuert, die wie beim ASF-
Direktaufruf in den ASF-Dialog einmünden, in dem er über Bildschirmmenüs Textbausteine
und Variablen aus dem ASF sowie individuellen Text einsteuern kann. ASF bedient sich
dabei der in der ASF-Bibliothek abgelegten Steuerungsbausteine, DCF-Makros,
Briefdefinitionen und Faksimiles und erzeugt damit, wie es das bei den Batch-
Briefanforderungen via ASF-Batch tut, einen Briefsatz. In den Nachverarbeitungsprogrammen
der Württembergischen werden dann mit dem Batch Output Manager Vollständigkeitsund
Dublettenprüfungen durchgeführt sowie Dokument und Abrechnungsschreiben
zusammengeführt. Weiterhin wird in diesen Programmen die Brief-Freigabe abgeglichen,
Kopien erstellt, die Versandart entschieden, die Poststraßen-Steuerung eingepflegt, sortiert,
Trennblätter erstellt, laufende Nummern vergeben, aus dem Referenzsystem für die
elektronische Akte sowie für den Mikrofilm ein Archivsatz erstellt, Statistiksätze erstellt, eine
Briefsatz-Plausibilisierung durchgeführt und Protokolle und Nachdrucke erstellt.
Anschließend werden die Briefsätze per DCF/Script-Lauf formatiert und entweder als Fax-
Datei auf den Fax-Server oder als Druckdatei in den Versand (Poststraße, Geschäftsstelle,
Agentur oder Fachabteilung) ausgegeben. Das Layout bestehend aus Formularen, Fonts
und Faksimile-Unterschriften wird über AFP-Resourcen zugesteuert.

Die strategische Ausrichtung der Bürokommunikation bei der Württembergischen sieht
folgendermaßen aus: In Bezug auf Workflow und elektronischer Akte werden konzernweite
Architekturen entwickelt, die Imageverarbeitung ausgebaut und E-Mail, Fax und die
Textverarbeitung via MS Word eingebunden. Bezüglich der Textverarbeitung wird eine
Konzernstrategie für Host und dezentrale Systeme entwickelt, ein alternativer Versand per
Post, Fax oder E-Mail für alle Brief angestrebt, Möglichkeiten für den Sofortdruck und
dezentralen Druck geschaffen sowie die neue Rechtschreibung eingeführt.
10. Vortrag „Archivierung Content Management bei der AMB-Generali“
(Udo Hoffmann, AMB Generali Informatik, s. File ECM_AMB Generali_ASFGuide.pdf)
Herr Hoffmann berichtet über das Enterprise Content Management in der AM Generali
Gruppe, die die Firmen Aachener und Münchner, Volksfürsorge, Saarbrücker, Thuringia und
Generali umfasst.
Ausgangssituation bei der AM Generali Gruppe sind ca. 27 Millionen Schriftstücke pro Jahr
der Kernprozesse „Bestandsverwaltung“ & „Leistung“.
Davon werden bis zu 150.000 Seiten NCI (Non-coded Information = Spooldokumente) in der
Prozesskette „spätes Archivieren“ erzeugt und archiviert. Derzeit startet ein Pilotbetrieb
„Scannen vor Bearbeitung“, d.h. Schriftgut wird zunächst nur gescannt, aber nicht indiziert,
sondern nur an die Prozesse weitergeleitet, in denen später bei der elektronischen
Erfassung der Vorfälle die notwendigen Indizes automatisch übergeben werden, bevor diese
Dokumente im Archiv abgelegt werden. Dieses Verfahren soll das „späte Archivieren“, bei
dem die einzuscannenden Dokumente zunächst in Papierform erfasst und bearbeitet und
dabei mit einem Barcode-Label beklebt werden, um später gesammelt eingescannt zu
werden, ablösen. Beim Einscannen wird dann an Hand des Barcodes die Zuordnung der
Indizes zum Dokument hergestellt.
Bei der Aachener und Münchner sind dezentral 12 Kodak-Scanner mit der Capturing-
Software InputAccel von Actionpoint im Einsatz. Die eingescannten Dokumente werden mit
diesem System im Abgleich mit DB2-Daten per Barcode indiziert und letztendlich auf
insgesamt 5 AIX und einem OS/390 Object Server des IBM Content Managers bzw. teilweise
noch des Vorgängersystems IBM VisualInfo abgelegt. Die Object Server verwalten die
physische Abspeicherung der Dokumente auf den IBM Jukeboxen im Gegensatz zu dem
Library Server, auf dem die gesamten Indizes der Dokumente verwaltet werden. Dieser wird
dort auf OS/390-Basis unter CICS/DB2 gefahren.
Die Spooldokumente, die als AFPDS-, PPFA- oder Line-Mode-Dokumente erzeugt werden,
werden nach Bearbeitung durch die ACIF-Bridge über das alte IBM
Spoolarchivierungssystem IAFC auf Hostbasis, von denen es hier drei produktive
Installationen gibt, abgelegt. Auf der Retrievalseite sind dort 870 NT-PCs im Einsatz, die
teilweise über Hybrid-Clients auf die unterschiedlichen Archivsysteme zugreifen können,
sowie etliche 3270-Terminals.
Ähnliche Systeme sind bei den anderen Töchtern ebenfalls im Einsatz. Angestrebt wird in
allen Fällen eine Trennung der Bereitstellung der Dokumente und des Betriebs.
11. Vortrag „Von der PC-Anwendung zur Druckstraße“
(Alfred Prasch, debitel, s. File Debitel-Prasch-Vortrag.pdf)
Herr Prasch, bei debitel für das Qualitätsmanagement verantwortlich, zeigt in seinem
Vortrag, auf welche Weise die Firma debitel ihren Versand optimiert hat. Nach der kurzen
Vorstellung der Historie und Entwicklung von debitel und seiner Stärken als Service-Provider
beschreibt er die Ausgangssituation für sein Projekt: debitel muss ca. 18.000 Blatt
Verbindungsnachweise an 1.500 individuelle Adressen schnellstmöglich verschicken. Diese
Mengen wurden manuell aufbereitet, gedruckt und kuvertiert. Neben dem Aufwand für
Beschaffung und Vorhaltung von Papier und Briefhüllen dauerte der Aufbereitungsausdruck

auf Arbeitsplatzdruckern ca. 15 Stunden und das manuelle Sortieren und Einkuvertieren der
Sendungen ca. 20 Mannstunden. Hinzukam das manuelle Frankieren bei einem Outsourcer.
Es gab damit keine Qualitätssicherung und das Einhalten von CI-Richtlinien war ebenso
wenig sichergestellt.
Nach Einstieg in den automatisierten Output wurden im Druckzentrum ca. 35 Millionen
Schriftstücke pro Jahr verarbeitet, davon 90% Rechnungen. Individualbriefe,
Serienanschreiben, Infoaussendungen und Werbematerialaussendungen werden lokal
erstellt und versendet.
Der Lösungsansatz war, den Output von Individual– und Serienbriefen zu sammeln und an
ein Druckzentrum zum zentralen Druck und Versand zu übermitteln. So werden die aus MS
Access erzeugten Printfiles als PDFs erzeugt und per FTP an das Druckzentrum übertragen.
Dort werden die PDFs zum einen mit dem Compart-Produkt DocBridge Mill nach AFP
konvertiert und per FTP wieder zurück an die Sachbearbeiter bei debitel übertragen. Die
Sachbearbeiter prüfen das Druckergebnis und geben den Brief per E-Mail an das
Druckzentrum frei. Damit wird der Aufbereitungs-, Druck-, Kuvertierungs- und
Versandprozess im Druckzentrum angestoßen.
Das Ergebnis ist; ein einfaches Anstoßen des Druck-/Versandprozesses an beliebig viele
Empfänger, eine nachhaltige Zeitersparnis vom Anstoß bis zum Versand, eine Minderung
der internen Aufwände (die Logistikaufwände in den Fachabteilungen fallen weg) und die
Sicherstellung der Einhaltung von CI-Vorgaben. Neben eingespielten QS-Maßnahmen inkl.
Reporting wird die Kundenzufriedenheit durch zeitnahe Zusendung der Unterlagen
gesteigert, Kosten eingespart und transparent gemacht und eine Basis für weitere
Versandkostenoptimierungen geschaffen.
12. Vortrag „Neues von icon: DOPE-Entwicklung: Status“
(K.-O. Kilgus, icon Systemhaus, s. File Neues-von-icon-25-04-2002.pdf)
Herr Kilgus gibt einen Überblick über Status und Ausblick der DOPE-Produkt-Suite. Die Suite
besteht aus der DOPE/Basis und den Komponenten DOPE/Dialog, DOPE/Editor,
DOPE/Script, DOPE/Utilities, DOPE/DB, DOPE/Batch, DOPE/Admin und DOPE/Correct.
Die DOPE/Basis beruht auf einer Klassenbibliothek zur effizienteren Programmierung von
Anwendungen zur Dokument-Komposition, der Implementierung eines Datenmodells und
spezifischen GUI-Komponenten zur Realisierung von grafischen Oberflächen für die
Dokument-Komposition (Briefgerüst – Baustein – Variable). Sie wurde auf Java umgesetzt,
um plattform-unabhängige, portierbare und skalierbare Lösungen entsprechend
unterschiedlicher Architektur-Ansätze zu ermöglichen. Zur Sicherstellung des
Investitionsschutzes für ASF—basierende Systeme gibt es SIB type 0/1-Interfaces und GIL-,
SLL- und CLL-Datenbankstrukturen.
DOPE/Dialog bietet dem Sachbearbeiter eine grafische Oberfläche analog zu ASF.
Programmiert wird auf Basis von Java/Swing-Klassen, was entsprechenden
Gestaltungsspielraum lässt. Es gibt funktionelle Erweiterungen (z.B. „Endebild“, „PDP kann
Dokumentenstruktur ändern“, „TCP“ und SIB „D“). Die grafische Oberfläche ist bei Bedarf
kundenindividuell anpassbar und änderbar. Die sichtbare Oberfläche ist „nur“ ein Beispiel für
eine mögliche Ausprägung des Dokument-Kompositions-Dialogs hinsichtlich Optik und
Prozess-Modell („dopeRulesForASF“). Herr Kilgus verweist auf realisierte Kundenprojekte,
die die Flexibilität und das Potential des Ansatzes zeigen.
Der DOPE/Editor zeigt Dokumentkontext bausteinübergreifend. Die Zeichenbreite und der
Zeilenumbruch entsprechen den „echten“ AFP-Druckerschriften. Es gibt eine Tag-Erkennung
und Unterstützung u.a. für Hervorhebungen, Aufzählungen, Tabulatoren und reguläre
Tabellen sowie eine Silbentrennung analog zu DCF. Außerdem steht eine
Rechtschreibprüfung mit Standard- und kundeneigenen Wörterbüchern zur Verfügung. In
einem Variablen-Dialog können im bisherigen Dokumentkontext bekannte Variablen mit

„drag & drop“ eingefügt werden. Weiterhin können Bausteine selektiert und deren Testinhalte
als Vorlage übernommen werden.
DOPE/Script ist im Kern der DCF-kompatible Formatierer. Als Eingabedatenstrom kann XML
mit CSS2 (mit DCF-Parser-Erweiterungen und „DCF-Makros“), HTML, partiell MS Word und
pures DCF/Script verwendet werden. Als Ausgabedatenstrom kann AFP, PDF oder PCL
entsprechend den verfügbaren Filtern der Firma Compart verwendet werden.
DOPE/Admin ist eine grafische Oberfläche für die Administration. Dem Trend zur (partiellen)
dezentralen Administration im Fachbereich folgend wird mehr Komfort, mehr Sicherheit, ein
besserer Editor, ein konsistenteres Datenmodell mit Variablen an Bausteinen als Referenz
und zusätzliche Möglichkeiten zur Modellierung des Kompositionsprozesses („Regelwerke“)
geboten. Dies ist unter Nutzung der Basis-Klassen realisierbar und wird im Rahmen
begonnener bzw. vereinbarter Kundenprojekte umgesetzt.
Die DOPE/Utilities bieten Funktionen zum Laden und Entladen von Datenbanken, zum
Import und Export von Dokumenten, Werkzeuge zur Migration und Konfiguration,
Möglichkeiten zur Erstellung von Statistiken (Logging/Tracing/Recording), „submit to batch“
und ein Wörterbuch-Pflegeprogramm.
Perspektivisch nennt Herr Kilgus die Fokussierung auf den Ausbau des Komponenten-
Gedankens. Herausfordernde Lösungsansätze sind hierbei auf MS Word basierende
Konzepte und ISIS Papyrus. Ebenso fließen die aus Kundenprojekten gewonnenen
Erfahrungen und Komponenten kontinuierlich ein. Wenn sinnvoll und möglich, soll auch
zukünftig die ASF-Entwicklung berücksichtigt werden.
Am Schluss gibt Herr Kilgus eine Demonstration der Komponenten. Zusatz von Herrn Kilgus
vom 3.7.2002: "Der graphische Sachbearbeiterdialog wird unter einer WIN 2000 Plattform
vorgeführt; die (ASF-)Ressourcen werden dabei nicht vom Host (zOS), sondern aus einer
portierten Datenbank (GIL) auf einem zweiten WINDOWS-Rechner (‘Datenbank-Server’)
gelesen. Dies illustriert den bereits erreichten Grad der Unabhängigkeit von ASF."
13. Gemeinsame Abendveranstaltung „Am Anfang war der Bausparvertrag“
Ottmar Traber vergnügt die Teilnehmer in historischer Kulisse eines alten Schulhauses in
Hoheneck mit den (un)verständigen Ansichten des kleinen Bausparers.
26.4.2002:
14. Vortrag „Datenströme im Vergleich: AFP / PDF / PCL“
(Harald Grumser, Compart Systemhaus, s. File Datastreams.pdf)
Herr Grumser geht zunächst auf die Gemeinsamkeiten der Datenströme AFP, PDF und PCL
ein. Zunächst sind diese Datenströme nicht durch ein Standardisierungsgremium (DIN,
ANSI, ECMA, ISO, W3C oder ITU) normiert und damit keine Standarddatenströme. Alle sind
Mixed Object-Formate, also Formate, die mehrere unterschiedliche Objekttypen beschreiben
können. Während AFP strukturierte Objektbeschreibungen verwendet, ist PCL stateorientiert
und PDF objekt-orientiert. AFP und PCL sind Stream-Formate, PDF dagegen ein
Random-Access-Format. AFP ist vorwiegend binär codiert, PCL dagegen vorwiegend ASCII
und PDF verwendet beide Codierungen.
Das von IBM festgelegte AFP arbeitet mit Structured Fields mit einleitendem 0x5A-Byte. Die
zugrundeliegenden Datenstrom-Architekturen sind AFP/DS und MO:DCA (Mixed Object:
Document Content Architecture) mit den Unterstrukturen:
• PTOCA (Presentation Text Object Content Architecture) für die Darstellung von Text-
Objekten,
• IOCA (Image Object Content Architecture) für die Darstellung von Image-Objekten in
einem Rasterformat,

• GOCA (Graphic Object Content Architecture) für die Darstellung von Vektorgrafik-
Objekten,
• BCOCA (Barcode Object Content Architecture) für die Darstellung von Barcode-
Objekten und
• FOCA (Font Object Content Architecture) für die Darstellung von Font-Objekten.
In PCL werden die Objekte in ASCII-Linemode mit Escape-Sequenzen dargestellt, ein
Verfahren, mit dem sich bei einfachen Formatierungsansprüchen der Datenstrom sehr leicht
kodieren lässt. Die neuesten Ausprägungen des Formats sind unter den Versionen PCL 5e
bzw. zuletzt PCL6 von HP definiert.
Adobes PDF ist eine entschärfte Form des recht komplexen Postscripts. Als
Austauschformat entwickelt wurde auf eine möglichst gute Viewer-Darstellbarkeit geachtet
(der Acrobat Reader ist der zugehörige, von Adobe kostenlos verteilte Viewer), die Druck-
Möglichkeiten sind hauptsächlich für die Einzeldokumentausgabe geschaffen, werden aber
zunehmend auch von größeren Druckern für Massendrucke verwendet.
Font-Technologien: AFP kennt im Gegensatz zu PCL (mit mehr als 20 residenten Fonts) und
PDF (mit 14 Core Fonts) keine residenten Fonts, also Fonts, die am Ausgabemedium als
vorhanden unterstellt sind und daher nicht mitübertragen werden müssen. Nachdem AFP
zunächst ausschließlich mit Rasterfonts gearbeitet hat, werden in jüngerer Zeit auch die
Postscript Level 1-Fonts als Vektorfonts unterstützt und zunehmend auch benutzt. PCL
kennt neben Rasterfonts die vektorbasierten Truetype-Fonts und die AGFA Intellifonts, PDF
dagegen arbeitet mit Truetype- und Postscript-Fonts.
Images: Während PCL Images nicht skalieren kann und nur eine schwache Skalierung kennt
und drucker-orientiert arbeitet, kennt APF generische Images, kann sie gut komprimieren
und im Drucker skalieren. PDF ist in dieser Beziehung am komfortabelsten ausgebildet: Es
kann im Viewer und im Drucker skalieren, versteht sich auf umfangreiche Arten der
Komprimierung und kennt viele Palettenmodelle.
Farbe: AFP unterstützt OCA und RGB-Farben sowie mit JPEG Echtfarben für Bilder und
kann über PSF Graustufen emulieren. Dagegen arbeitet PCL mit Stiftfarben im HP-GL, ist
treiberlastig und unterstützt Rasterformat (RIP). PDF kennt viele Farbräume, Echtfarben und
Separation und ist Pre-Press-tauglich.
Vektorgrafik: PCL hat eine eigene Vektorsprache (HP-GL), hat ein ausreichendes Vektor-
System und ist plotter-orientiert. AFP besitzt für Vektorgrafiken eine eigene Architektur
(GOCA), die ein vollständiges Grafiksystem abbildet und in mehreren IBM-Systemen zum
Einsatz kommt (z.B. OS/2-Metafile). PDF hat ebenfalls ein vollständiges von Postscript
abgeleitetes Vektorsystem, das nahtlos integriert ist.
Formulare und Overlays: AFP kennt Overlays und Page-Segmente, Copy-Groups und
Suppression sowie eine definierte Reprint-Mimik. PCL dagegen arbeitet mit generischen
Macro-Funktionen, einfacher Overlay-Steuerung und hat eine komplexe Reprint-Mimik. PDF
wiederum arbeitet mit interaktiven Xforms als Objekt, kann auf Einzelobjekte referenzieren,
kennt aber keine Drucksteuerung.
Zeichenunterstützung: AFP arbeitet mit Standard-Codepages und frei definierbaren
Codepage-Resourcen sowie IBM Character Names. PCL kennt über 100 Buildin und
downloadable Codepages sowie Bound-/Unbound-Fonts. PDF arbeitet mit 3 Buildin-
Codepages und frei definierbaren Codepage-Objekten und verwendet Postscript-Character-
Names.
Resourcen: Im AFP gibt es sowohl interne wie auch externe Resourcen sowie eine
Resource-Library, auf die referenziert werden kann. Mit IPDS besitzt es ein intelligentes
Druckertreiberkonzept. PCL kennt zwar auch downloadable Resources, normalerweise wird

aber mit selfcontained Resourcen gearbeitet. Auch bei PDF sind die Resourcen in der Regel
self-contained. Fonts werden referenziert oder sind inline. Es besitzt ein Objekt-Modell.
Druckjobsteuerung: Die Druckjobsteuerung läuft im AFP über Formdefs. Es unterstützt
Endlos und Einzelblattdruck und kennt eine elaborierte N-up-Verarbeitung. PCL dagegen ist
einzelblatt-orientiert, kann simplex, duplex, Bindings und Copies und verwendet PJL als
Jobsprache. PDF hat zur Druckjobsteuerung kein Konzept. Man kann sich über die XEROX
Job-Tickets und Comments als Hilfskonstruktion behelfen.
Generierungstools: Zur Generierung von AFP-Output stehen neben dem Page-Processing
über PSF bzw. IPM und Lösungen wie Prisma das gute alte OGL und PPFA oder ähnliche
Werkzeuge von Zweitanbieter zur Verfügung. Weiterhin sind hier DCF oder ähnliche
Angebote zu nennen. PCL wird über die PC-Drucktreiber von Microsoft und HP erzeugt.
Entsprechend seiner Verbreitung auf Windows-Systemen gibt es eine Unzahl von
Formatierern und Formulareditoren. Adobe sorgt über den Arcobat Writer und Distiller für die
Erzeugung von PDF-Dokumenten. Außerdem gibt zu diesem Zweck APIs wie die PDF-Lib,
allerdings nur relativ wenige spezifische Lösungen zur Generierung.
15. Vortrag „DIN 5008 – neue Gestaltungsrichtlinien“
(Heino Lauer, Karlsruher Versicherungen, s. File DIN-5008.pdf)
Herr Lauer berichtet über die neuen Schreib- und Gestaltungsrichtlinien für die
Textverarbeitung nach der DIN 5008 (im Buchhandel erhältlich unter der
ISBN-Nr. 3-410-15188-5).
Mit den Änderungen im November 2001 wurden gegenüber Mai 1996 folgende Änderungen
vorgenommen:
Die Gestaltung von E-Mails wurde neu festgelegt:
Der Abschluss einer E-Mail enthält den Gruß sowie Kommunikations- und Firmenangaben.
Zwingend sollte er auch die E-Mail- und/oder Internet-Adresse enthalten. Beispiel:
„Freundliche Grüße
Karlsruher Versicherungen
Heino Lauer
Telefon: +49 721 353-4622
Fax: +49 721 353-4626
E-Mail: heino.lauer@karlsruher.de
Internet: http://www.karlsruher.de”
Änderungen bei der elektronischen Signatur bzw. Verschlüsselung:
Da E-Mails eher einer Postkarte als einem Brief entsprechen, sollten wichtige Mitteilungen
durch digitale Signatur und/oder verschlüsseltes Übertragen gegen unberechtigtes Lesen
und Veränderungen geschützt werden.
Kalenderdaten:
Das numerisch angegebene Datum wird in der Reihenfolgen Jahr, Monat, Tag mit
Mittelstrich gegliedert. Tag und Monat werden zweistellig angegeben. Beispiel: 2002-04-24.
Sofern keine Missverständnisse entstehen, darf auch die Schreibung Tag, Monat, Jahr,
gegliedert mit Punkt, verwendet werden.
Telefon- und Telefaxnummer:

Sie werden funktionsbezogen durch je ein Leerzeichen gegliedert (Anbieter, Landesvorwahl,
Ortskennzahl, Einzelanschluss bzw. Durchwahlnummer). Vor der Durchwahlnummer steht
ein Mittelstrich. Zur besseren Lesbarkeit dürfen funktionsbezogen Teile durch Fettschrift oder
Farbe hervorgehoben werden. Beispiele:
Einzelanschluss ohne Durchwahl: 0721 684132, 0175 4666508.
Durchwahlanlage: 0721 353-0, 0721 353-4622.
Sondernummern: 0800 notfon d.
Sondernummern (mit Ziffer für Gebührenzählung): 0180 2 55678.
International: +49 721 353-4622.
Die Gestaltung des Briefes A4 ohne Aufdruck wurde neu festgelegt:
Auslandsanschriften:
Sie müssen in lateinischer Schrift und arabischen Ziffern, Bestimmungsort und
Bestimmungsland mit Großbuchstaben geschrieben werden. Die Anordnung ist – wenn
möglich – der Absenderangabe des Partners zu entnehmen. Der Bestimmungsort ist nach
Möglichkeit in der Sprache des Bestimmungslandes anzugeben. Beispiel: LIEGE, FIRENZE,
BUCURESTI. Die Angabe des Bestimmungslandes steht in deutscher Sprache in der letzten
Zeile der Anschrift. Beispiel:
1
2
3 Mevrouw J. de Vries
4 Poste restante A. Caypstraat
5 Postbus 99730
6 1000 NA AMSTERDAM
7 NIEDERLANDE
8
9
1
2
3 Casio Computer Co., Ltd.
4 6-1, Nishi-Shinjuku 2-chome
5 Shinjuku-ku
6 TOKYO 163-02
7 JAPAN
8
9
Im Auftrag des Europäischen Standardisierungsinstituts (CEN) beschäftigt sich die
Arbeitsgruppe ‚Adress Database’ mit der Erstellung einer 5-teiligen Norm, die alle relevanten
Aspekte von Adressdaten behandelt. Die Norm umfasst Adresskomponenten, die physische
Repräsentation, den elektronischen Datenaustausch, die Validierung und die Interpretation
von Adressdaten. Derzeit ist der erste Teil veröffentlicht, die Arbeit am zweiten, der
physischen Repräsentation, ist in vollem Gange. Dazu das folgende Zitat:
„Um sich einen umfassenden Eindruck von den Möglichkeiten zu verschaffen, wie ...
länderspezifische Adresskomponenten abgebildet werden können, hat die Arbeitsgruppe
eine ausführliche Untersuchungsphase eingeleitet. Die Untersuchung gliedert sich in drei
Teile:
1. Ist das europäische Adressmodell hinreichend detailliert, um alle landesspezifischen
Adressen beschreiben zu können?
2. Welche Komponenten kommen pro Land in welcher Adresszeile vor?

3. Kann die Reihenfolge von Adresskomponenten in allgemeinen Regeln festgehalten
werden?
Besonderes Augenmerk dient der Feststellung, dass es nicht Ziel ... ist, bestehende
Repräsentationskonventionen ... zu ändern. Die Aufgabenstellung zielt vielmehr darauf ab,
Richtlinien zu entwickeln, um die Versendung von Poststücken im internationalen Verkehr zu
vereinfachen.“
16. Erfahrungsaustausch / Aktuelles / Organisatorisches
Auf Anregung aus dem Teilnehmerkreis wurde vereinbart, ähnlich wie beim Enterprise
Printing Guide einen Tagungsordnungspunkt „Was gibt es neues?“ einzurichten, bei dem
jeder Tagungsteilnehmer in möglichst komprimierter Form darstellt, was sich neues in dem
für diesen Guide interessanten Umfeld bei dem Teilnehmer getan hat oder gerade tut, wie
z.B. wir führen gerade das Verfahren „so und so“ ein und sind dabei auf diese oder jene
Probleme gestoßen. Auf diese Weise lässt sich der Gedankenaustausch untereinander über
die aktuellen Fragen und Tendenzen am besten vorwärtsbringen. Gemeint ist hier also nur,
was sich aktuell tut, und nicht was überhaupt in der eigenen Umgebung auf die Beine
gebracht wurde.
Der nächste ASF-Guide findet zusammen mit dem Enterprise Printing Guide vom
6. - 8.11.2002 in Münster bei der LVM statt. Die weiteren Einzelheiten wird Herr Hobinka
demnächst bekannt geben.