An alle Mitglieder der IPDT/ASF Arbeitsgruppe im GSE
Transcrição
An alle Mitglieder der IPDT/ASF Arbeitsgruppe im GSE
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 HTMLOutput 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 NTServer) 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 JESSpool 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 AIXServer übertragen, mit DOPE/Script von HTML nach AFP konvertiert und über den HOSTSpool 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 OutputVolumen 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 DCFFormatierung 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 GUIFunktionen. 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ängerRelease 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/IPPort-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-MarkenStrategie. 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 TIFFDokumenten 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 OptiaSystem 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 ASFDirektaufruf 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 BatchBriefanforderungen 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 FaxDatei 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 CapturingSoftware 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 KomponentenGedankens. 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 TextObjekten, • 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 VektorgrafikObjekten, • BCOCA (Barcode Object Content Architecture) für die Darstellung von BarcodeObjekten 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 DruckMö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 VektorSystem 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 BuildinCodepages und frei definierbaren Codepage-Objekten und verwendet Postscript-CharacterNames. 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: [email protected] 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.