BiPRO: Modul Postkorb / Störfälle steht zur Verfügung

Transkript

1 1 NKK Newsletter 01/2013 BiPRO: Modul Postkorb / Störfälle steht zur Verfügung oder an Sachbearbeiter, Außendienst, Vermittler oder Mailempfänger) auf den Import folgt. Implementierung der BiPRO Norm 430 / 431 Bereits seit dem OASIS - Release 12.1 steht allen Anwendern durch die Nutzung der lizenzfreien Community Edition des BiPRO-Clients die Authentifizierung beim VU (BiPRO Norm 410) und der direkte Absprung zu den Fachobjekten im Maklerportal der Versicherer (BiPRO Norm 410) zur Verfügung. Im aktuellen OASIS - Release ist jetzt auch der Postkorb implementiert. Diese Norm regelt den elektronischen Transfer von Nachrichten vom Versicherer zum Vermittler. Die Nachrichten sind kategorisiert und beinhalten Zuordnungs Informationen. Dadurch ist sowohl die automatische Zuordnung zu den relevanten Fachobjekten in OASIS, als auch die Konfiguration von Folgeprozessen möglich. Selbstverständlich existiert im Sinne der Nachvollziehbarkeit und der manuellen Nachbearbeitung eine umfangreiche Protokolldatei. Die Einführung dieser BiPRO Norm in Ihrem Unternehmen birgt nach unserer Einschätzung ein enormes Effizienzsteigerungspotenzial. Anstelle der Digitalisierung von Papier, der Zuordnung zu den Objekten und des individuellen Anstoßens der Folgebearbeitung ist nunmehr eine echte prozessuale Verarbeitung im besten BiPRO-Sinne konfigurierbar. Eine aktuelle Übersicht der bereits im BiPRO Client implementierten Versicherer / Normen nebst Vorschau auf anstehende Umsetzungen fügen wir diesem Newsletter als Anlage bei. Die Postkorb Lösung setzt die kostenpflichtige Business Edition des BiPRO Clients voraus. Bei Interesse wenden Sie sich bitte an Ihren Kundenansprechpartner. Im neuen OASIS Werkzeug BiPRO Bearbeitungscenter kann pro Geschäftsvorfall konfiguriert werden, wie die Transferdatei verarbeitet wird und welche Folgeverarbeitung (Vorgang und /

2 2 NKK Newsletter 01/2013 Zeit für Helden Zur Scrum-Einführung in der NKK Die NKK hat sich ein neues Organisationsmodell und einen neuen Software- Entwicklungsprozess gegeben. Ziel ist es, sowohl die Effizienz im Entwicklungsprozess als auch die Qualität in den entstehenden Versionen zu steigern. Die Neuerungen haben insbesondere auch Auswirkungen auf das Releasekonzept der OASIS-Produktpalette. Im letzten Jahr hat die NKK große Anstrengungen unternommen, um ein geeignetes Vorgehensmodell in der Software- Entwicklung zu evaluieren und im Unternehmen zu implementieren. Insbesondere im Zuge der Entwicklung von OASIS.NEU, die Ende letzten Jahres gestartet ist, war es notwendig, das bestehende, an das V-Modell angelehnte Vorgehensmodell durch einen modernen und agilen Ansatz zu ersetzen. Bereits in den 90er Jahren wurde der Ruf nach leichtgewichtigen Prozessen in der Software-Entwicklung laut und die ersten dieser neuen Vorgehensmodelle erlangten durch einen radikalen Perspektivenwechsel hin zu den am Prozess beteiligten Menschen und den zu entwickelnden Artefakten schnell Berühmtheit, wie zum Beispiel das sogenannte Extreme Programming, einer der ersten Vertreter der neuen Prozesswelt. Im Jahr 2001 verständigten sich 17 renommierte Entwicklungs- und Prozess- Experten bei einem Treffen in den USA auf Grundprinzipien für sogenannte agile Software-Entwicklungsprozesse und begründeten damit das bis heute vielzitierte Agile Manifest. Agile Entwicklungsprozesse zeichnen sich dadurch aus, dass sie den Menschen und die Kommunikation in den Vordergrund stellen, den Focus eher auf die Ermittlung der tatsächlichen Kundenanforderungen und auf eine funktionierende Software als auf Auftragsabwicklung und umfassende Dokumentationen richten. Wesentlich für agile Softwareentwicklung ist dabei, im Rahmen von Change-Management jederzeit auf sich verändernde Projektsituationen reagieren zu können. Eines der bekanntesten und weit verbreitetsten Vorgehensmodelle der agilen Welt ist Scrum. Der Begriff wörtlich übersetzt Gedränge deutet an, dass dieses Modell die rastlos sich verändernden Projektsituationen berücksichtigt und mit einbezieht, vor denen schwergewichtige und komplett durchformalisierte Prozesse kapitulieren müssen. Dabei setzt es gemäß dem agilen Manifest auf die Menschen, die gleichberechtigt und soweit wie möglich selbstorganisierend in kleinen Teams ihre Produkte entwickeln und optimieren. Jedes einzelne Projektmitglied trägt hierbei eine große Eigenverantwortung für das Gelingen. Dies hat Boris Gloger, ein Scrum-Master der ersten Stunde, in seinem Buch Scrum: Produkte zuverlässig und schnell entwickeln zu folgender Aussage motiviert: DAS GESAMTE SCRUM-TEAM BESTEHT AUS HELDEN. SIE HABEN DIE AUFGABE, TÄGLICH ENTSCHEIDUNGEN ZU TREFFEN. SIE MÜSSEN TUN, WAS NÖTIG IST, UM EIN ZIEL ZU ERREICHEN, UND DAS ERFORDERT COURAGE. Jedes Scrum-Team wird von einem Scrum-Master koordiniert. Dieser hat vor allem die Aufgabe, die Arbeitsfähigkeit des Teams zu gewährleisten und Hindernisse aus dem Weg zu räumen. Seine Leitungsaufgaben stehen dabei nicht im Vorder-

3 3 NKK Newsletter 01/2013 grund, da Scrum ja auf eigenverantwortliche, sich selbstorganisierende Teams setzt. Diese Teams arbeiten in kurzen Projektzyklen von wenigen Wochen, die Sprints genannt werden. In diesen Sprints werden die Kundenanforderungen, die sogenannten User Stories, entwickelt. Alle vorhandenen User Stories werden dabei im Product Backlog verwaltet. Aus diesem stellt der Product Owner, der als Produktmanager für die strategische Weiterentwicklung verantwortlich ist, für jeden Sprint die Team-Aufgaben im Sprint Backlog zusammen. Im Sprint Planning Meeting werden die User Stories aus dem Sprint Backlog mit allen Team-Mitgliedern besprochen und gemeinsam die Aufgaben verteilt. Das Team trifft sich während eines Sprints täglich zu einer kurzen Besprechung, dem Daily Scrum, in dem maximal 15 Minuten lang die anstehenden Aufgaben und vorhandenen Probleme angesprochen werden. In der NKK wurden vier Scrum-Teams gegründet, die vollständig eigenverantwortlich die ihnen zugewiesenen OASIS- Software-Produkte entwickeln. Jedes Team hat einen eigenen Product Owner, einen Scrum-Master, eigene QS-Mitarbeiter, fachliche Berater und Entwickler: Scrum-Team OASIS.WIN (Bestand und Rechnungswesen) entwickelt unser Backoffice-System OASIS.WIN. Scrum-Team OASIS.NEU ist verantwortlich für unsere neue OASIS-Produktgeneration, die eine vollständig geschäftsprozessorientierte Bearbeitung versicherungstechnischer Anwendungsfälle ermöglichen wird. Scrum-Team Java&Interfaces ist zuständig für Schnittstellen wie OASIS.IFM, aber auch für unsere Web- Anwendungen CMS und IRS. Scrum-Team.Net-Entwicklung betreut unser OASIS.WEB, den Webservice-Host und die BiPRO-Anbindung. Alle Teams erstellen im Rahmen eines Sprints ein prinzipiell auslieferungsfähiges Software-Produkt. Es kann jedoch notwendig sein, dass eine neue Version im Rahmen von zwei Sprints entwickelt werden muss. Scrum zählt zu den sogenannten iterativ inkrementellen Software-Entwicklungsprozessen. Das bedeutet also, dass OASIS schrittweise in sich wiederholenden Projekten (Sprints) weiterentwickelt wird. Zur Unterstützung dieser rein projektorientierten Aufstellung haben wir auch die NKK-interne Organisationsstruktur angepasst und eine klassische Matrix-Organisation eingeführt. Fazit: Wir werden schneller und verbessern dabei auch die Kommunikation bzw. die Abstimmung mit Ihnen.

4 4 NKK Newsletter 01/2013 Bisher wurden für OASIS bis zu vier Releases im Jahr entwickelt, zu denen es jeweils Service-Packs gab, die in einem Neben-Entwicklungszweig zum zugehörigen Release implementiert werden mussten. Dieses Vorgehen machte es notwendig, Änderungen eines Service- Packs in alle später erstellten Releases nachzuziehen. Wir sprechen vom Merge der Änderungen zwischen den sogenannten Entwicklungsbranches. Bei dieser Form des Releasemanagements kann es auch vorkommen, dass ein späteres Release noch nicht alle Änderungen eines früheren Releases beinhaltet. Das folgende Schaubild stellt den Standardfall dar: Altes Release-Konzept Berücksichtigt man zudem die bisher notwendigen Hotfixes, Entwicklungs- und Kundenbranches steigt die Komplexität rapide an, was direkte Auswirkung auf Wartungsintensität, Verwaltungsaufwand und nicht zuletzt auf die Qualität hat. Als Konsequenz aus diesen Erfahrungen und dem iterativen und strikt inkrementellen Ansatz von Scrum wird sich das Releasekonzept für OASIS in Zukunft folgendermaßen darstellen: Wir sprechen nicht mehr von Releases, sondern von Versionen. In jedem Jahr werden ca. zehn OASIS-Versionen bereitgestellt. Diese bauen direkt aufeinander auf, also beinhaltet jede Version die Funktionalitäten der Vorgängerversion. Auf die Entwicklung regulärer Service- Packs wird verzichtet. Durch die kurzen Sprint-Zyklen können Fehlerbereinigungen im nahezu vierwöchigen Rhythmus bereitgestellt werden. Neues Release-Konzept Sie als Kunde müssen selbstverständlich nicht auf jede neue Version upgraden. Nur dann, wenn Sie eine neue Funktionalität nutzen wollen oder eine Fehlerbereinigung benötigen, die in einer zukünftigen Version enthalten ist, setzen Sie diese in Ihrem Unternehmen ein. Wir empfehlen, pro Jahr mindestens zwei Upgrades durchzuführen, damit Sie immer am Puls der OASIS-Zeit bleiben und frühzeitig von neuen Funktionen profitieren können. Der Verzicht auf komplexe, nebenläufige oder parallel laufende Entwicklungsstränge und die damit verbundenen Merges wird spürbar zur Qualitätssteigerung beitragen. In zwei Fällen werden wir jedoch auf das alte Verfahren zurückgreifen: Fehler einer mittleren Kritikalitätsstufe und darunter werden in den nächsten Versionen behoben, auf die dann ein Upgrade notwendig ist. Für kritische Fehler jedoch, die den produktiven Betrieb von OASIS massiv beeinträchtigen, werden selbstverständlich Hotfixes zur Verfügung gestellt, die auf Basis der bei Ihnen eingesetzten Version ohne Upgrade bereitgestellt werden. Außerdem bieten wir den Kunden, die bei Upgrade auf eine neue Version einen besonderen internen Einführungsprozess verfolgen (insbesondere bei Qualitätssicherung in eigenen Test- und Integrationsumgebungen), die Option des sogenannten Extended Test Supports während der Versions-Einführungsphase an: Solange Sie die Version bei sich testen und in die bestehende Systemlandschaft integrieren, erhalten Sie exklusive Fehlerfixes auf Basis der einzuführenden Version, so dass Sie mit dieser stabilisierten

5 5 NKK Newsletter 01/2013 Version produktiv gehen können. Nach dem Produktivgang endet Ihr Extended Test Support für die Version und der Prozess beginnt mit einer aktuelleren Version wieder von vorne. Ihr Ansprechpartner berät Sie gerne bezüglich dieser neuen Support-Option. All diese Maßnahmen werden aus unserer Sicht dazu beitragen, die Bereitstellungsgeschwindigkeit und Qualität unserer Software zu erhöhen und den Weg in die neue OASIS-Produktgeneration zu ebnen. Auf diesen Weg würden wir Sie gerne mitnehmen!