Working languages: German to English
|  Rajashree Pathak
Accuracy and On-time Delivery
Mumbai, Maharashtra, India Local time: 12:03 IST (GMT+5.5)
Native in: English  | | |
I.T., Technical, Legal Expert and on-time delivery | | Freelancer | | Translation, Website localization, Software localization, Desktop publishing | | Specializes in: | | Accounting | Computers: Hardware | | Computers: Software | General / Conversation / Greetings / Letters | | Internet, e-Commerce | IT (Information Technology) | | Law (general) | Law: Contract(s) | | Marketing / Market Research | Science (general) |
| Also works in: | | Law: Patents, Trademarks, Copyright | Patents | | Business/Commerce (general) | Tourism & Travel | | Certificates, Diplomas, Licenses, CVs | Printing & Publishing | | Real Estate | Transport / Transportation / Shipping | | Engineering (general) |
More Less | | PRO-level points: 8, Questions answered: 15 | Sample translations submitted: 1 | German to English: Text related to computer system | Source text - German
PROSI/ AB Handbuch
„KRIBON (KRIBS Bonität)“
1 Kurzbeschreibung des Systems 3
2 Repository-Informationen 3
2.1 Systemname 3
2.2 Teilsysteme 3
2.3 Ansprechpartner (Verantwortliche, Stellvertreter) 3
3 Planungsverantwortungen 3
4 Berichtswesen / regelmäßige Kundengespräche 4
5 Grundsätzliches zur Instandhaltungsstrategie 4
5.1 Servicezeiten (Gültig in 2005) 4
5.2 Produktionssicherung 4
5.3 Anwendungsbetreuung 5
5.4 Priorisierungen 5
5.5 Zusammenhang mit Releases / Projekten 5
5.6 Dokumentation 5
6 AB-Strategie 5
6.1 Generelle AB-Festlegungen 5
6.2 Prozessabläufe bei Anfragen, Review, Genehmigung, Test, Abnahme 6
6.3 Nachverfolgung des Fortschritts eines Änderungsauftrages 6
6.4 Informationswege für fremde Systeme 7
6.5 Absprachen mit dem Kunden 7
6.6 Einhaltung Servicelevel bei Beantwortung von Anfragen, Angeboten etc. 7
6.7 Umgang mit Unklarheiten (Anforderungen, Preise, etc.) 7
6.8 Eskalationswege 7
7 Prosi-Strategie 7
7.1 Instandhaltung 7
7.2 Ablauf der Incident / Problem-Bearbeitung 8
7.2.1 Entgegennahme von Incidents / Problems 8
7.2.2 Vorgehen zur Sicherstellung, daß Probleme aus dieser Anwendung kommen 8
7.2.3 Vorgehen bei redundanten Incidents 8
7.2.4 Vorgehen bei Problemen mit Fremdsoftware 8
7.2.5 Vorgehen bei wiederkehrenden Problemen (Taskforce) 8
7.2.6 Umgang mit Irrläufern 9
7.2.7 Zwischenergebnisse 9
7.2.8 Entscheidungen für / gegen Hotfixes durch wen? 9
7.2.9 Vorgehen bei zurückgestellten Problemen 9
7.2.10 Welchem Vorhaben werden die Aufwände belastet? 10
7.2.11 Abnahme/ Freigabe der Änderung 10
7.2.12 Schliessung von Incidents / Problems 10
7.2.13 Dokumentation für "Lessons learnded" 10
7.2.14 Vorgehen bei, vom Benutzer erkannten Problemen 10
7.3 Absprachen mit dem Kunden 10
7.4 Reaktionszeiten/ Servicelevel 10
7.5 Verfügbarkeiten (Anforderungen) 11
7.6 Eskalationswege –und Zeiten (inkl. HVB-Info) 11
7.7 Aufwandsgrenzen 11
7.8 Auswertungen von Incidents (Trends, Häufigkeit) 11
7.9 Vorbeugende Identifikation von Risiken 11
7.10 Vorgehen bei Workarounds 11
7.10.1 Wo werden diese dokumentiert? 11
7.10.2 Wie wird die endgültige Korrektur sichergestellt? 11
7.10.3 Organisatorische Informationen an Kunden, UHD 11
8 Anhang (ProSi-Vereinbarungen je System) 11
9 Change History 12
1 Kurzbeschreibung des Systems
Das System "KRIBON" ist ein "Baustein" in der Prozeßkette von KRIBS (KReditInformations –
und BearbeitungsSystem). Es dient der Erfassung, Bearbeitung und Ermittlung von Bonitäten.
Diese werden durch eine Bonitätsklasse ausgedrückt, die die Ausfallwahrscheinlichkeit eines
Kreditengagements repräsentiert.
Die wesentlichen Funktionen der Anwendung sind:
• Web-basiertes Anwendungssystem, das eine Vielzahl von Anwendungsfunktionen weltweit (in der HVB AB Filiale / Niederlassung) über das Intranet zur Verfügung stellt.
• Bedienung des Systems über eine einheitliche und benutzerintuitive Struktur der Fenster
• Bonitäten, die in dem Anwendungssystem KRIBS-Bonität abgelegt werden, werden in die Risikoanalysen und -berechnungen einbezogen, sowie von div. Risikocontrolling-Systemen verarbeitet und zu bankinternen Steuerungszwecken verwendet.
• Durch diverse Übersichten und Bearbeitungsfenstern in der Anwendung zum jeweiligen Ordnungsbegriff (Engagementverbund, Partner) wird eine benutzerorientierte Darstellung von Bonitäten ermöglicht. Die Bildung von Verbünden i.S. von Bonitätsrisiken ist möglich.
• Es existiert eine Web-basierte Online-Hilfe, in Form einer Fenster-Hilfe, bzw. einer Feld-Hilfe, die aus jedem Fenster von KRIBS-Bonität aufgerufen werden kann
• Die Anwendung kann sowohl aus dem InAp (Integrierter Arbeitsplatz), als auch direkt über das Intranet aufgerufen werden
• KRIBS-Bonität ermöglicht die Funktionen Bonität anlegen, Bonität freigeben, Bonität ändern und Bonität löschen
• Es werden diverse Bonitätsarten im Firmen-, Privat-, Geschäfts- und Immobilienkundenbereich durch die Anwendung KRIBS-Bonität unterstützt.
• Durch Batchprozesse wie eine maschinelle Aktualisierung von Bonitäten, Ermittlung von
Altersrestriktionen und Auswertbeständen wird die manuelle Bonitätsbearbeitung standardisiert unterstützt.
• Schnittstellensysteme, die sich der Daten aus der Anwendung KRIBS-Bonität bedienen, sind Plus, Ariane, KRIBS-Kripo, Frühwarnsystem. Die Anwendung KRIBS-Bonität benötigt als Eingabeschnittstelle die Systeme GeParD, Jahresabschlüsse, SCAMPI, BEWIS
Eine ausführliche Beschreibung zur Handhabung der Anwendung KRIBS-Bonität befindet
sich in der Bedienungsanleitung und dem ZAD, welche über den Einstieg KREDIT Intranet zu
erreichen ist
2 Repository-Informationen
Das System "KRIBS-Bonität" ist im Repository als eigenständiges System abgelegt.
2.1 Systemname
Im Repository ist das Anwendungssystem "KRIBS-Bonität" unter "KRIBON" abgelegt.
2.2 Teilsysteme
Folgendes Teilsystem sind zusätzlich im Repository zu dieser Anwendung verfügbar:
• KVS S907
2.3 Ansprechpartner (Verantwortliche, Stellvertreter)
Kompetenzträger SYS: SYS10CA Peter Driendl (Teamleiter)
Systemverantwortlicher in SYS10CA: Zink, Karsten
Stellvertreter: SYS10CA Meder, Michael; Palatz, Kerstin; Zittergrün, Sylvia
Systemowner: GRC6 Angelika Borchert
Verantwortlicher in GRC6: Seiderer, Sascha (GRC6RT)
Verantwortlich in HVB Info: Gehring, Franz (INF4A3)
3 Planungsverantwortungen
• Qualität der Compass-Rückmeldungen: Vorhabenverantwortlicher, i.d.R. der Teamleiter
• Compass-Planung: Vorhabenverantwortlicher, MPM
• Schätzungsqualität: Systemverantwortlicher nach Rücksprache mit dem Teamleiter
• Zuordnung auf Leistungskategorien: Systemverantwortlicher nach Rücksprache mit
dem Teamleiter
• Erweiterung / Veränderung Rahmenvertrag: Vorhabenverantwortlicher mit MPM
• Kontrolle Prozeßeinhaltung: Teamleiter
• Eskalationsweg: Vorhabenverantwortlicher Teamleiter BB-Leiter GF. Die Einhaltung der Eskalationszeiten werden durch den Teamleiter geprüft (IMPACT-WEB)
• Einhaltung Servicelevelvereinbarung: Sicherstellung durch den Teamleiter
4 Berichtswesen / regelmäßige Kundengespräche
Monatlich wird die Ausnutzung der Prosi –und AB-Vorhaben von dem Teamleiter in Zusammenarbeit mit dem MPM ausgewertet.
Der HAG erhält die verbrauchten Aufwände und bekommt einen Zwischenstand über die noch zu erwartenden Aufwände.
Pro Anwendung wurde im Compass, getrennt nach Prosi und AB ein eigenes Vorhaben angelegt, so daß ein Controlling auf Systemebene möglich ist.
Bei Aufwänden für die reaktive Prosi (Incidentbearbeitung) > 2 PT ist die Genehmigung von dem Systemverantwortlichen auf Kundenseite einzuholen. Die Genehmigung wird formlos per Mail gegeben.
Die Genehmigungen werden unter dem Anwendungssystemordner im Aladin unter "06. Sonstiges" abgelegt.
Aktuelle Themen oder anstehende Systemveränderungen werden regelmäßig 7-tägig mit den Kunden besprochen. Teilnehmer auf Seiten der HVB Systems: BB-Leiter, Teamleiter, MPM. HVB-Info ist ebenfalls durch den Kundenmanager vertreten.
Es werden zudem Budgetauslastungen und Anforderungen an die Systeme besprochen.
5 Grundsätzliches zur Instandhaltungsstrategie
5.1 Servicezeiten (Gültig in 2005)
Die Services der ProSi im Geschäftsfeld GRC werden Montags bis Freitags (ausgenommen bundes –und landesgesetzliche Feiertage) bereitgehalten. Die Störungsbearbeitung beginnt spätestens 3 Stunden nach Eingang der Störungsmeldung und erfolgt im Rahmen der nachfolgend bestimmten Servicezeiten:
1. Standardlevel: Die Services werden in der Zeit von 9-17 Uhr erbracht
2. Standard + Level: Die Servicezeiten des Standards werden auf 9-18 Uhr verlängert
3. Standard ++ Level: Die Servicezeiten des Standards werden auf 8-20 Uhr verlängert. Zeiten nach 18 Uhr sind reine Bereitschaftszeiten, die auch ohne konkrete Fehlerbehebungsmaßnahmen als Vorhaltezeiten abgerechnet werden
4. Feiertag: Die Services werden auch an bundes –und landesgesetzlichen Feiertagen erbracht. Die Feiertagsdienste sind ebenfalls Bereitschaftsdienste, die auch ohne konkrete Fehlerbehebungsmaßnahmen als Vorhaltezeiten abgerechnet werden.
Für dieses System wurde die Servicezeit "Standard" vereinbart.
5.2 Produktionssicherung
Es wird zwischen reaktiver und proaktiver Produktionssicherung unterschieden. Die Prosi
ist in verschiedene Behebungslevel eingeteilt, die der Anlage entnommen werden können.
Die reaktive ProSi beinhaltet die Reaktion auf Störungen (Incidents und Problems).
Eine Störung liegt vor, wenn die Anwendung nicht verfügbar ist oder in reporduzierbarer Weise den in der Systemdokumentation (Fachkonzept bzw. Abnahme –oder Releasedokumentation) niedergelegten Funktionsumfang nicht erreicht und dies zu einer Beeinträchtigung in der Nutzung führt. Bei fehlender Systemdokumentation liegt eine Störung vor, wenn Felder der Benutzeroberflächen nicht oder nicht richtig gefüllt werden.
Die proaktive Produktionssicherung beinhaltet Maßnahmen zur Erhaltung der Funktionstüchtigkeit und Störungsprophylaxe, die durch die HVB Systems festgestellt wurden. Bei Fremdsoftware ist hierin auch die laufende Überwachung und Optimierung der erforderlichen Lizenzen enthalten.
Nähere Informationen zu den vereinbarten Leveln und Regelungen siehe Kapitel 7.
5.3 Anwendungsbetreuung
Zur Bearbeitung von kleineren Änderungen am System wurde ein Anwendungsbetreuungs-budget bereitgestellt.
Nähere Informationen Anwendungsbetreuung siehe Kapitel 6.
5.4 Priorisierungen
Die Priorisierung der Änderungswünsche erfolgt gemeinsam mit dem Kunden. Dieses sind zum Einen ad hoc-Besprechungen für Änderungswünsche, die eine gewisse Dringlichkeit erfordern oder eine besondere Tragweite nach sich ziehen. Zum Anderen finden regelmäßige Abstimmgespräche mit dem Kunden statt.
Die Priorisierung der Incidents / Problems erfolgt ebenfalls gemeinsam mit dem Kunden. Bei gravierenden Problemen mit der Anwendung finden ad hoc-Besprechungen statt.
Zum Anderen finden regelmäßige Anstimmgespräche mit dem Kunden statt
5.5 Zusammenhang mit Releases / Projekten
Grundsätzlich werden Änderungen (CR's, Fehlerbehebung) am System mit dem nächst möglichen Release in den produktiven Betrieb gebracht.
Sollte die Dringlichkeit (bei Incidents) dieses nicht zulassen, wird ein Sonderrelease beantragt und die geänderten Komponenten gehen so schnell wie möglich in Produktion.
Betrifft die Änderung lediglich reine Host-Komponenten, wird im Vorfeld mit dem Kunden der mögliche Einsatztermin besprochen.
Bei geplanten Änderungswünschen wird im Vorfeld mit dem Kunden der Zeitplan besprochen. Dort wird auch entschieden, welches Release für den produktiven Einsatz in Frage kommt.
In Ausnahmefällen werden geänderte Komponenten (aus der Prosi und AB) gemeinsam mit einem Projekteinsatz geplant. Dieses Vorgehen wird im Vorfeld mit dem Kunden besprochen und die Vor –und Nachteile werden aufgezeigt.
5.6 Dokumentation
Für dieses System ist im Anwendungssystemordner in ALADIN die für den laufenden Betrieb erforderliche Dokumentation abgelegt.
Veränderungen am System (z.B. durch Instandhaltungsmaßnahmen) werden dort unter Bezug auf die Auftragsnummer (Impact, AB-Ticket etc.) abgelegt.
6 AB-Strategie
6.1 Generelle AB-Festlegungen
Auf Kundenseite hat der Systemverantwortliche der Anwendung ein AB-Budget zugeteilt bekommen (intern) und hat die Entscheidungskompetenz, den CR zur Umsetzung freizugeben.
Steht nicht genügend Budget zur Verfügung, wird auf Kundenseite geklärt, wie der CR finanziert werden soll.
In vereinzelten Ausnahmefällen kommen die Änderungswünsche in der HVB Systems per Mail zum Systemverantwortlichen. Dieser stellt ggf. nach Rücksprache mit dem Beauftrager einen CR in die CR-Datenbank ein.
CR's aus Projekten heraus werden in die CR-Datenbank des Projektes eingestellt und auch von dem jeweiligen Projekt finanziert.
6.2 Prozessabläufe bei Anfragen, Review, Genehmigung, Test, Abnahme
Die Änderungswünsche an einer Anwendung werden vom Kunden per CR, bzw. Ticketing-Verfahren eingestellt. Die Beschreibung der gewünschten Änderung und die zu erwartenden Ergebnisse werden ausführlich vom Kunden beschrieben.
Anschliessend prüft der Systemverantwortliche die Qualität der Beschreibung und bittet ggf. um detailliertere Ausführungen.
Die Schätzung der Aufwände wird vom Systemverantwortlichen durchgeführt und dem Kunden mitgeteilt. Die notwendigen Maßnahmen für die Umsetzung des Änderungswunsches werden ebenfalls vom Systemverantwortlichen in dem CR (oder PVCS für AB-Ticketing) beschrieben.
Ein Review im klassischen Sinne findet nicht statt. Die Genehmigung zu den beschriebenen Änderungen erfolgt durch das Setzen des Status "Freigabe zur Umseztung"/ "beauftragt", welcher vom Systemverantwortlichen auf Kundenseite gesetzt wird.
Hiermit wird sowohl der Lösungsweg, als auch das Budget genehmigt.
Nach Fertigstellung der Realisierung und internen Tests wird der CR auf den Status "Test"/ "Abnahme" gesetzt und der Kunde informiert.
Der Kunde testet die Umseztung und prüft die Ergebnisse.
Zum Einsatzzeitpunkt werden i.d.R. mehrere CR's für den produktiven Betrieb zu einem Release zusammengefasst.
Der Kunde nimmt alle für das Release bereitgestellten CR's ab und unterschreibt ein Abnahmeformular. Dieses Formular wird im Aladin des Anwendungssystemordners unter "Abnahme / Freigabe" abgelgt.
Der CR wird nach der produktiven Einführung geschlossen.
Für die Anwendung wird die CR-Datenbank genutzt, die für dieses System im Outlook zur Verfügung steht und sowohl, der HVBSystems, als auch dem HAG einsehbar, bzw. änderbar ist.
Die Kunden stellen in die CR-Datenbank die Änderungswünsche ein und informieren den Systemverantwortlichen über den Eintrag.
Dieser analysiert und schätzt die Aufwände und Auswirkungen und trägt in den CR die Aufwände und geplanten Änderungen ein.
Anschliessend entscheidet der Kunde, ob der CR umgesetzt werden soll. Er stellt dazu den CR auf "Freigegeben zur Umsetzung" und nennt einen Wunsch-Releasetermin
Eine parallele Dokumentation im AB-Ticketing-Tool wird durch die HVBSystems übernommen.
Mit AB-Ticketing-Tool (PVCS-Dimensions)
Komplette (korrekte) Nutzung des AB-Ticketing-Tools für KRIBSSI ab 2006.
Das System ist im AB-Ticketing Tool hinterlegt.
Eingehende Tickets werden gemäß den Tool-Vorgaben bewertet und beschrieben und weitergeleitet.
6.3 Nachverfolgung des Fortschritts eines Änderungsauftrages
Für die Nachverfolgung des Fortschritts eines Änderungsauftrages ist der Systemverantwortliche zuständig. Dieser hat mit dem Kunden einen Zeitplan für das Konzept, die Realisierung, Test und Abnahme erstellt und muß diese Termine nachhalten.
Der Systemverantwortliche gibt dem Kunden frühzeitig Rückmeldung darüber, ob der Änderungswunsch im geplanten Zeit –und Budgetrahmen umgesetzt werden kann.
6.4 Informationswege für fremde Systeme
Ob von dem gewünschten Änderungsauftrag Fremdsysteme betroffen sind, analysiert der Systemverantwortliche im Vorfeld der Realisierung. Er klärt mit den Verantwortlichen der betroffenen Fremdsysteme deren geplante Aufwände und prüft, ob die Anpassungen im gesetzten Zeitrahmen umzusetzen sind.
Der Systemverantwortliche informiert den Auftraggeber des Änderungswunsches über die betroffenen Anwendungen und plant für diese entsprechendes Anpassungsbudget ein.
Genehmigt der Kunde den CR, informiert der Systemverantwortliche die Verantwortlichen der betroffenen Fremdsysteme über Inhalt und Zeitplan der geplanten Änderungen.
Nach der Umsetzung der Änderungen informiert der Systemverantwortliche die Fremdsysteme und bitte diese, ihre Anwendung zu testen.
Der Auftraggeber wird aufgefordert, alle geänderten Systeme zu testen und abzunehmen.
6.5 Absprachen mit dem Kunden
Grundsätzlich gelten die Vertragsabsprachen mit dem Kunden, die für beide Seiten bindend sind.
6.6 Einhaltung Servicelevel bei Beantwortung von Anfragen, Angeboten etc.
Die Service- und Reaktionszeiten zu dem System sind jedem betroffenen Mitarbeiter bekannt.
Die Einhaltung des Servicelevels wird durch den Teamleiter sichergestellt.
6.7 Umgang mit Unklarheiten (Anforderungen, Preise, etc.)
Für den Fall, daß sich der Kunde nicht mit dem Systemverantwortlichen einigen kann, wird der Teamleiter und die Führungskraft des Kunden hinzugezogen. Diese entscheiden ggf. über die Umsetzung und die damit verbundenen Preise.
Regelmäßig stattfindende Kundengespräche werden ebenfalls dafür genutzt, Unklarheiten anzusprechen und gemeinsame Lösungen zu finden.
6.8 Eskalationswege
Grundsätzlich läuft die Eskalation über den Teamleiter des Systemverantwortlichen. Ggf. eskaliert das Thema an den BB-Leiter und die GF. Mögliche Eskalationen werden frühzeitig vom Systemverantwortlichen avisiert.
7 Prosi-Strategie
7.1 Instandhaltung
Für das System sind folgende Prosi-Level beauftragt. Für die Inhalte der einzelnen Level s. Anlage
reaktive Produktionssicherung:
x R1 Grundlevel
R2 Ausbaustufe "eigene Hotline"
x R3 Ausbaustufe "fachliche Anfragen"
R4 Ausbaustufe "Vorhaltezei"t
R5 Ausbaustufe "Usermanagement"
proaktive Produktionssicherung:
x P1 Grundlevel
x P2 Ausbaustufe "Behebung drohender Störungen oder selbst erkannter Probleme"
x P3 Ausbaustufe "Passive Releasetests"
x P4 Ausbaustufe "Performanceverbesserungen"
P5 Ausbaustufe "(Fremdsoftware-)Lifecyclemanagement"
Sollten Tätigkeiten nötig werden, die hier nicht vereinbart sind, wird dies mit dem Kunden abgestimmt und auf die richtige Prosi-Kategorie kontiert (auch wenn diese im Vertrag nicht vereinbart wurde)
7.2 Ablauf der Incident / Problem-Bearbeitung
7.2.1 Entgegennahme von Incidents / Problems
Die Entgegennahme von Incidents / Problems erfolgt in der Regel über das Tool "IMPACT-WEB". Jeder Systemverantwortliche überprüft mehrmals täglich den Eingang von möglichen Incidents.
Liegt ein Incident für die Anwendung vor, trägt sich der Systemverantwortliche als Bearbeiter ein und trifft eine erste Analyse des Problems. Ggf. wird der Einsteller des Problems zur Klärung des Problems mit einbezogen um den Fall rekonstruieren zu können. Wird ein Incident weitergeleitet, wird im Incident dokumentiert, welche Ergebnisse die bisherige Fehlerdiagnose erbracht hat und was bisher zur Behebung des Fehlers getan wurde.
In den Incident wird die Compass HS-Nr. für das ProSi-Vorhaben der Anwendung eingestellt, so daß die Aufwände auf den entsprechenden Vorgang gecatst werden können.
Für den Fall, daß ein Anwender direkt bei dem Systemverantwortlichen anruft und ein Problem meldet, wird hierfür von dem Systemverantwortlichen ein Incident eröffnet. Somit wird sichergestellt, daß auch direkt vom Anwender eingehende Probleme mit dem gleichen Medium bearbeitet werden.
7.2.2 Vorgehen zur Sicherstellung, daß Probleme aus dieser Anwendung kommen
Bei Problemen mit der Anwendung wird in einem ersten Schritt von dem Systemverantwortlichen geprüft, ob Änderungen an der Anwendung vorgenommen wurden, die Ursache der Probleme sein könnten.
Ist dies nicht der Fall, wird gemeinsam mit der HVB_Info überprüft, ob die Servereinstellungen oder
andere technische Infrastruktur geändert wurde.
Das Problem wird versucht, im Testumfeld nachzustellen und mit geeigneten Analysetools überwacht.
Bei durchgeführten Programmänderungen wird im Rahmen der proaktiven Produktionssicherung eine erhöhte Überwachung der Anwendung durchgeführt.
7.2.3 Vorgehen bei redundanten Incidents
Sollten mehere Incidents zu dem gleichen Problem vorliegen, wird bei den Folgenden auf den ersten eingegangen Incident referenziert (Angabe des Referenzincidents).
7.2.4 Vorgehen bei Problemen mit Fremdsoftware
Im Falle von Incidents auf Grund fehlerhafter Fremdsoftware wird das Problem an den Hersteller weitergeleitet. Liegen bereits mehere Incidents bei dem Fremdsoftware-Hersteller vor, kann ggf. bereits ein Korrekturzeitpunkt genannt werden.
Im Incident wird von dem Systemverantwortlichen vermerkt, daß eine Bearbeitung außerhalb der HVB Systems notwendig ist.
7.2.5 Vorgehen bei wiederkehrenden Problemen (Taskforce)
Gehen zu einem Problem auffallend häufig Incidents ein, wird ggf. gemeinsam mit der HVB-Info analysiert, wer der Auslöser des Problems ist.
Handelt es sich um technische (Hardware) Probleme, wird eine Taskforce unter der Teilnahme des Systemverantwortlichen, des Teamleiters und der HVB-Info eröffnet, um das Problem gemeinsam zu lösen.
Sind mehrere Systeme betroffen wird eine Taskforce durch die Systemverantwortlichen der betroffenen Systeme gebildet.
Handelt es sich um fachliche Probleme wird ein Gespräch mit dem Systemverantwortlichen auf Kundenseite gesucht um ggf. fehlerhafte fachliche Vorgaben zu analysieren und nach Lösungswegen zu suchen.
Haben die Probleme gravierende Auswirkungen auf die Anwender, wird zudem vom Kunden eine New Bis-Meldung eingestellt und den Nutzern mögliche organisatorische Lösungen angeboten.
Bei Problemen, die trotz Änderungen am System weiterbestehen, wird dieses analysiert und wie oben beschrieben bearbeitet. Ggf. werden erneut Änderungen per Hotfix/Eilcopy in die Produktion eingespielt.
7.2.6 Umgang mit Irrläufern
Incidents, die fälschlicherweise bei einem Systemverantwortlichen eingegangen sind, werden auf den korrekten Zuständen geprüft und über "IMPACT-WEB" weitergeleitet.
Sollte der richte Zuständige nicht ermittelt werden können, wird ggf. bei dem Einsteller des Incidents nachgefragt, welche Anwendung Probleme macht. Über das Repository ist die Anwendung i.d.R. einem korrekten Zuständigen zuzuordnen.
7.2.7 Zwischenergebnisse
Sollte ein Problem nicht unmittelbar behoben werden können, wird der Einsteller des Problems über den aktuellen Zwischenstand informiert. Hierzu wird der aktuelle Stand im Incident beschrieben und der Anwender ggf. telefonisch informiert. Der Incident bleibt so lange geöffnet, bis der Incident endgültig erledigt wurde.
7.2.8 Entscheidungen für / gegen Hotfixes durch wen?
Besteht ein gravierendes Problem in einer Anwendung, oder ist das Problem auch nach Änderung der Komponenten noch nicht behoben, ist möglicherweise ein Hotfix / Eilcopy notwendig.
Die Entscheidung, ob ein Hotfix durchgeführt werden muß, prüft in einem ersten Schritt der Systemverantwortliche. Ist dieser der Meinung, daß ein Hotfix notwendig ist, informiert er den Kunden und holt sich deren Einverständnis.
Ferner wird das Einverständnis der HVB-Info und des Teamleiters eingeholt. Hierfür werden die möglichen Risiken aufgezeigt.
Wird ein Hotfix während der Change-Stopp-Zeiten notwendig, wird zudem die schriftliche Genehmigung des BB-Leiters eingeholt.
Bei "normalen" Problemen, die die Anwendung nicht gravierend beeinträchtigen wird i.d.R. bis zum nächsten geplanten Release mit der Produktivschaltung gewartet.
7.2.9 Vorgehen bei zurückgestellten Problemen
Die Priorisierung von Problemen wird gemeinsam mit dem Kunden vorgenommen. Ist eine sofortige Umsetzung der Änderung auf Grund von Ressourcenengpässen oder des Ausmasses der Änderungen nicht möglich, wird mit dem Kunden eine Zwischenlösung besprochen.
Ist der Kunde mit der Zurückstellung einverstanden, stellt dieser eine New Bis-Meldung ein, um den Nutzern der Anwendung eine organisatorische Lösung anzubieten.
Ggf. werden auf Seiten der HVB Systems Korrekturläufe notwendig, die, wenn möglich, eingeleitet werden.
Ist eine Zurückstellung nicht möglich, muß das Problem eskalieren um ggf. andere Aufgaben zurückzustellen oder Unterstützung anzufordern.
Handelt es sich bei dem Problem um eine korrekte technische Umsetzung von fachlich fehlerhaften Vorgaben, wird gemeinsam mit dem Kunden besprochen, diesem Incident in einen CR umzuwandeln und über die AB abzuwickeln.
7.2.10 Welchem Vorhaben werden die Aufwände belastet?
Es werden die Aufwände demjenigen Vorhaben belastet, in dem das Problem auftritt. Ist das Problem eine Folge von Fehlern im Zuliefersystem, wird auf die Systemverantwortlichen des Zuliefersystems zugegangen mit der Bitte die Fehler in ihrem System zu Lasten der eigenen Prosi zu beheben.
7.2.11 Abnahme/ Freigabe der Änderung
Der Systemverantwortliche in der HVB Systems testet die vorgenommenen Änderungen. Kleinere rein technische Tätigkeiten (z.B. Job nachstarten, …) werden nicht vom Fachbereich abgenommen.
Für Änderungen an der fachlichen Logik (sofern es nicht die Wiederherstellung des ursprünglich abgenommenen Zustands ist) testet der Fachbereich wie folgt:
Der Systemverantwortliche stellt dem Fachbereich die Anwendung im Test zur Verfügung und nennt geeignete Daten für den Test.
Der Fachbereich testet die zuvor von ihm erstellten Testfälle und protokolliert die Ergebnisse. Sollten Fehler oder unerwünschte Ergebniss auftreten, setzt sich der Fachbereich mit dem HVBSystems-Systemverantwortlichen in Verbindung und bittet um Behebung.
Nach Behebung des gemeldeten Fehlers gibt der Systemverantwortliche Feedback an den Fachbereich und bittet um erneuten Test.
Im Anschluß an alle Testdurchläufe und bei Fehlerfreiheit wird vom Fachbereich eine schriftliche Abnahme eingefordert, die im Aladin abgelegt wird.
In den produktiven Betrieb werden nur Änderungen eingespielt, für die eine schriftliche Abnahme seitens des Fachbereichs vorliegt.
7.2.12 Schliessung von Incidents / Problems
Ein Incident / Problem wird erst dann geschlossen, wenn der Fehler bereinigt wurde und die korrigierte Komponente in den produktiven Betrieb eingespielt wurde.
I.d.R. wird der Einsteller des Problems über die Behebung telefonisch informiert.
Die Schließung des Incidents/ Problems erfolgt durch den abschließenden Bearbeiter nach Rücksprache mit dem Systemverantwortlichen.
7.2.13 Dokumentation für "Lessons learnded"
wird von Fall zu Fall entschieden. Grundsätzlich muß die Dokumentation im Aladin ausreichen.
7.2.14 Vorgehen bei, vom Benutzer erkannten Problemen
Stellt ein Benutzer einen Anwendungsfehler fest, ruft dieser i.d.R. die Serviceline bei der HVB-Info an, die einen Incident eröffnen und an den Systemverantwortlichen leiten.
Läuft der Benutzer direkt bei dem Systemverantwortlichen auf, eröffnet dieser einen Incident und bearbeitet diesen, wie unter 7.2.1 beschrieben.
7.3 Absprachen mit dem Kunden
Grundsätzlich gelten die Vertragsabsprachen mit dem Kunden, die für beide Seiten bindend sind.
7.4 Reaktionszeiten/ Servicelevel
Es gelten die im Vertrag vereinbarten Service und Reaktionszeiten. Die Servicezeiten sind im Kapitel 5.1. beschrieben.
7.5 Verfügbarkeiten (Anforderungen)
Für das Anwendungssystem KRIBON wurden die Standard-Verfügbarkeiten vertragliche vereinbart.
7.6 Eskalationswege –und Zeiten (inkl. HVB-Info)
Grundsätzlich läuft die Eskalation über den Teamleiter des Systemverantwortlichen. Ggf. eskaliert das Problem an den BB-Leiter und die GF. Mögliche Eskalationen werden frühzeitig vom Systemverantwortlichen avisiert.
7.7 Aufwandsgrenzen
Nimmt die Behandlung von reaktiven Problemen mehr als 2 Personentage in Anspruch, so erfolgt eine Abstimmung mit dem Auftraggeber. Ist dabei keine Aktivität vom Auftraggeber gewünscht, unterbleiben weitere Behebungsmaßnahmen.
Die Abstimmung mit dem Auftraggeber wird im Anwendungssystemordner in ALADIN unter "06. Sonstiges" dokumentiert
7.8 Auswertungen von Incidents (Trends, Häufigkeit)
Die Auswertungen von Incidents werden monatlich von den Teamleitern in Zusammenarbeit mit dem MPM ausgewertet. Hier werden Trends und Häufigkeit erkannt. Treten für eine Anwendung auffallend oft Probleme auf, werden in den regelmäßigen Kundengesprächen mit dem Auftraggeber mögliche Verbesserungsmaßnahmen besprochen.
7.9 Vorbeugende Identifikation von Risiken
wird über die proaktive Produktionssicherung dargestellt.
7.10 Vorgehen bei Workarounds
7.10.1 Wo werden diese dokumentiert?
Workarounds, die aus einem Incident resultieren, werden dort beschrieben.
Workarounds, die aus der Anwendungsbetreuung resultieren, werden in dem betroffenen CR beschrieben.
7.10.2 Wie wird die endgültige Korrektur sichergestellt?
Der CR, bzw. Incident wird erst dann geschlossen, wenn der Workaround endgültig behoben wurde, bzw. abschließende Maßnahmen definiert und umgesetzt wurden.
7.10.3 Organisatorische Informationen an Kunden, UHD
Sind organisatorische Anweisungen an die Nutzer der Anwendung notwendig, wird die Steuerung und Koordination über den HAG geregelt.
In Einzelfällen werden auch Hinweistexte in die Anwendung implementiert, die die Anwender auf organisatorische Anweisungen aufmerksam macht.
8 Anhang (ProSi-Vereinbarungen je System)
9 Change History
Datum Version Durch wen Änderung
05.04.06 V 0.1 Zink Fertigstellung (reviewfähig)
| Translation - English
PROSI/ AB Manual
“KRIBON (KRIBS Creditworthiness)“
1 Brief Description of the System 2
2 Repository-Information 3
2.1 System name 3
2.2 Sub system 3
2.3 Contact Person (Responsible, Substitute) 3
3 Planning Responsibilities 3
4 Reporting / regular discussions with the customer 4
5 Fundamentals for Maintenance Contract 4
5.1 Service Period (Valid in 2005) 4
5.2 Production Security 4
5.3 Application Support 4
5.4 Prioritisation 5
5.5 Connection with releases / projects 5
5.6 Documentation 5
6 AB-Strategy 5
6.1 General AB-Commitments 5
6.2 Process Cycles in case of Enquiry, Review, Approval, Test, Acceptance 6
6.3 Follow up of Progress of Change Request 6
6.4 Information Path for External Systems 6
6.5 Meeting with the Customer 7
6.6 Compliance to Service Level in case of Response to Enquiries, Offers etc. 7
6.7 Dealing with ambiguities (Demands, Prices, etc.) 7
6.8 Escalation Path 7
7 Prosi-Strategy 7
7.1 Servicing 7
7.2 Procedure of Incident / Problem-Processing 8
7.2.1 Acceptance of Incidents / Problems 8
7.2.2 Procedure for Prevention, that problems are occurred from this application 8
7.2.3 Procedure in case of Redundant Incidents 8
7.2.4 Procedure in case of Problems with External Software 8
7.2.5 Procedure in case of Recurring Problems (Taskforce) 8
7.2.6 Dealing with Defective Run 9
7.2.7 Intermediate Status 9
7.2.8 Decisions for/against patches by whom? 9
7.2.9 Procedure in case of Postponed Problems 9
7.2.10 For which project are man-days charged? 10
7.2.11 Acceptance/ Release of Change 10
7.2.12 Closing of Incidents / Problems 10
7.2.13 Documentation for "Lessons learned" 10
7.2.14 Procedure in case of problems detected by user 10
7.3 Agreements with the customer 10
7.4 Response Time/ Service Level 10
7.5 Availability (Demands) 11
7.6 Path of Escalation and Period (incl. HVB-Info) 11
7.7 Limitation of Man-Days 11
7.8 Estimation of Incidents (Trends, Frequency) 11
7.9 Preventive identification of Risks 11
7.10 Procedure in case of Workarounds 11
7.10.1 Where are they documented? 11
7.10.2 How is the final correction ensured? 11
7.10.3 Organisational Information to Customers, UHD 11
8 Appendix (ProSi-Agreements of System) 11
9 Change History 12
1 Brief Description of the System
The system "KRIBON" is a "module" in the process chain of KRIBS (Credit Information –
And Processing System). It provides a basis for entry, processing and determination of creditworthiness. These are demonstrated through creditworthiness category, which represents the conditional probability of failure of credit obligation.
The salient functions of application are:
• Web-based application system, which is available on Intranet, having multitude of application functions worldwide (in the HVB AB Branch / Subsidiary).
• Handling of the system in a consistent and user intuitive screens
• Creditworthiness, which is stored in the application system KRIBS-Creditworthiness, which is inclusive of risk analysis and risk calculation, as well as processed by different risk controlling systems and used for the purpose of internal control by the bank.
• Through different overviews and processing screens in the application for every evaluation group (Obligated, Partner), a user-oriented display of creditworthiness is possible. The formation of association i.S. of risk of creditworthiness is possible.
• A web-based online help exists in the form of window help, or a field help, which can be accessed from every window of KRIBS-creditworthiness.
• The application can be accessed both from InAp (Integrated Position), and also directly from the Intranet.
• KRIBS-Creditworthiness enables to store the functions of creditworthiness - approve creditworthiness, change creditworthiness and delete creditworthiness
• It supports different types of creditworthiness of company customer group, private customer group, business customer group and immovable customer group through the KRIBS-creditworthiness application.
• Through batch processes like automated updation of creditworthiness, determination of age restrictions and evaluation of balances, the manual processing of creditworthiness is standardised and supported.
• Interface systems, which use the data from the application KRIBS-creditworthiness, are Plus, Ariane, KRIBS-Kripo, Early warning system. The application KRIBS-creditworthiness depends on the systems GeParD, Year-end accounts, SCAMPI, BEWIS as entry interface.
A detailed description for handling of the application KRIBS-creditworthiness is provided in the instruction manual and for ZAD, which is available on intranet by accessing CREDIT.
2 Repository-Information
The system "KRIBS-creditworthiness" is stored in repository as independent system.
2.1 System name
In repository, the application system “KRIBS-creditworthiness" is stored under "KRIBON".
2.2 Sub system
Additionally following sub system is available for this application in repository:
• KVS S907
2.3 Contact Person (Responsible, Substitute)
Key Personnel SYS: SYS10CA Peter Driendl (Team Leader)
System-in-charge in SYS10CA: Zink, Karsten
Substitute: SYS10CA Meder, Michael; Palatz, Kerstin; Zittergrün, Sylvia
System Owner: GRC6 Angelika Borchert
Responsible Person in GRC6: Seiderer, Sascha (GRC6RT)
Responsible Person in HVB Info: Gehring, Franz (INF4A3)
3 Planning Responsibilities
• Quality of Compass-Responses: Project-in-charge, i.d.R. the team leader
• Compass-Planning: Project-in-charge, MPM
• Estimated Quality: System-in-charge after consultation with the team leader
• Classification of performance categories: System-in-charge after consultation with the team leader
• Upgrade / Change in Master Agreement: Project-in-charge with MPM
• Compliance with Control Process: Team leader
• Escalation path: Project-in-charge Team leader BB-Leader GF. The compliance to escalation period is checked by the team leader (IMPACT-WEB)
• Compliance to Service level agreement: Ensured by Team Leader
4 Reporting / regular discussions with the customer
Monthly utilisation of Prosi and AB Projects is analysed by the team leader in co-operation with the MPM.
The HAG maintains the man-days used and gets an intermediate status about the man-days still to go.
For the application in compass, a particular project apart from Prosi and AB was installed, so that controlling at the system level is possible.
In case man-days for the reactive Prosi (Incident processing) > 2 PT, the approval from the customer is obtained by the system-in-charge. The approval is given informally by mail.
The approvals are stored under application folder "06 miscellaneous" in Aladin.
Current issues or pending system modifications are discussed regularly on every 7th day with the customer. Participants on the part of the HVB system: BB-Leader, Team leader, MPM. Likewise HVB-Info is represented by customer manager.
Moreover, budget utilisation and requirements of the system are also discussed.
5 Fundamentals for Maintenance Contract
5.1 Service Period (Valid in 2005)
The services of ProSi in business unit GRC are kept ready from Monday to Friday (except for State and Country regulated holidays). The processing for errors begins at the latest 3 hours after entry of error registration and is carried out subsequently within the scope of the defined service period:
1. Standard Level: The Services are rendered in the period from 9-17 o’clock
2. Standard + Level: The standard service period is extended up to 9-18 o’clock
3. Standard ++ Level: The standard service period is extended up to 8-20 o’clock. Period after 18 o’clock is purely standby time, which is also accounted for without specific measures for trouble shooting as holdback time
4. Holiday: The Services are also rendered on State and Country regulated holidays. The services on holidays are also on-call-services, which are also accounted for without specific measures for trouble shooting as holdback time.
For this system the service period is agreed as "Standard".
5.2 Production Security
There is difference between reactive and proactive production security. The Prosi is divided in different debugging levels, which can be taken from the appendix.
The reactive Prosi includes effects of errors (Incidents and Problems).
An error is occurred, when the application is not available or the scope of function is not achieved in a reproducible manner, which is recorded in the system documentation (Functional specification or acceptance or release documentation) and it causes error while in use. In case of defective system documentation, an error is occurred, when the field on screen is not entered or is not entered correctly.
The proactive production security includes measures for maintaining functional efficiency and error prevention, which is determined by the HVB system. Also in case of new software, continuous monitoring and optimisation of required license is covered.
For particular information regarding agreed levels and controls, see chapter 7.
5.3 Application Support
For processing minor changes in the system, application support budget is prepared.
For particular information regarding application support, see chapter 6.
5.4 Prioritisation
The prioritisation of change request takes place in coordination with the customer. These are ad-hoc discussions for change requests which call for certain urgency or which result in particular implications. For others regular status meetings with the customers take place.
Likewise, prioritisation of incidents / problems takes place mutually with the customer. In case of serious problems in the application, ad-hoc discussions take place. For others regular status meetings with the customers take place.
5.5 Connection with releases / projects
Basically, changes (CRs, defects) in the system are delivered in the next planned release in production.
If the urgency (in case of incidents) does not allow this, a special release is requested and the changed components in the system are included as soon as possible.
If the change is related to merely host-components, possible start date is discussed beforehand with the customer.
In case of planned change requests, the time schedule is discussed beforehand with the customer. There it is also decided which release should be considered for the deployment in production.
In exceptional cases, changed components (from the Prosi and AB) are planned mutually with project use. This procedure is discussed beforehand with the customer and the advantages and disadvantages are highlighted.
5.6 Documentation
For this system, required documentation for the day-to-day business is stored in application system folder in ALADIN.
Changes in the system (e.g. through servicing measures) are stored by reference to the contract number (Impact, AB-Ticket etc.).
6 AB-Strategy
6.1 General AB-Commitments
The system-in-charge gets an AB-budget of the application (internal) allocated from the customer and has the authority to approve CR for implementation.
If sufficient budget is not available, the customer is communicated how the CR should be financed.
In isolated exceptional cases, the change requests in the HVB systems are sent by mail to the system-in-charge. These are placed after discussion with the customer as a CR in the CR-database as the case may be.
CRs from projects are placed in the CR-Database of the project and are also financed by each project.
6.2 Process Cycles in case of Enquiry, Review, Approval, Test, Acceptance
The change requests in an application are placed by the customer per CR or Ticketing-process. The description of desired change and the results to be expected are specified in detail by the customer.
Subsequently the system-in-charge examines the quality of the specification and requests for detailed information as the case may be.
The estimation in man-days is carried out by the system-in-charge and is informed to the customer. Moreover, the necessary measures for the implementation of change request are specified by system-in-charge in the CR (or PVCS for AB-Ticketing).
A review in conventional sense does not take place. The approval to the specified changes takes place through the status set as "Release for implementation” / “authorisation", which is set by system-in-charge of customer.
And the solution approach is also approved.
After completion of implementation and internal tests the status of the CR is set to "Test"/ "Acceptance" and the customer is informed about it.
The customer tests the implementation and examines the outcome.
For the point of assignment i.d.R. more and more CRs are connected to a release for the production.
The customer accepts all CRs for the release of completed CRs and signs an acceptance form. This form is stored under Aladin of application system folder under "Acceptance / Release".
The CR is closed after it goes in production.
For the application the CR-database is used, which is available for this system in Outlook as well as in HVB System, which is visible or changeable by HAG.
The customers place change requests in the CR-database and inform the system-in-charge about the entry.
System-in-charge analyses and estimates the man-days and its impact and enters the man-days and the planed changes in the CR-database.
Subsequently, the customer decides whether the CR should be implemented. For that customer marks the CR as "released for implementation" and calls it a request-release-schedule.
A parallel documentation is initiated in AB-Ticketing-Tool through the HVB Systems.
With AB-Ticketing-Tool (PVCS-Dimensions)
Complete (correct) use of AB-Ticketing-Tool for KRIBSSI from 2006.
The system is stored in AB-Ticketing Tool.
Incoming tickets are evaluated and specified and forwarded as per the Tool-specifications.
6.3 Follow up of Progress of Change Request
System-in-charge is responsible for the follow up of progress of change request. He prepares a time schedule for the conceptualisation, implementation, test and acceptance with the customer and must follow these schedules.
The system-in-charge gives a timely update to the customer about whether the change request can be implemented within planned time and budget.
6.4 Information Path for External Systems
If due to desired change request external systems are affected, the system-in-charge analyses it before implementation. System-in-charge explains the affected external systems to the responsible persons with planned man-days and checks whether the customisations can be implemented in set timeframe.
The system-in-charge informs the customer about the change request in the related application and plans for the corresponding customisation budget.
If the customer approves the CR, the system-in-charge informs the responsible persons about the contents and time schedule of planned changes to related external systems.
After the changes are implemented, the system-in-charge informs about the external systems and requests them to test their application.
The customer is requested to test and approve all changed systems.
6.5 Meeting with the Customer
Fundamentally the contract agreements with the customer are binding on both the sides.
6.6 Compliance to Service Level in case of Response to Enquiries, Offers etc.
The service and response time of the system are known to every concerned associate.
The compliance to service level is ensured through the team leader.
6.7 Dealing with ambiguities (Demands, Prices etc.)
In case the customer cannot agree with the system-in-charge, the team leader and the executive of customer are consulted. They take decision about the implementation and the price associated with it.
Moreover for that, customer discussions, which take place regularly, are used to clear ambiguities and to find out a mutually agreeable solution.
6.8 Escalation Path
Fundamentally the escalation is done by the team leader of system-in-charge. System-in-charge escalates the problem to the BB-Leader and the GF as the case may be. Possible escalations are notified at an early stage by the system-in-charge.
7 Prosi-Strategy
7.1 Servicing
For the system, following Prosi-Level is assigned. For the contents of individual levels, see appendix
Reactive Production Security:
x R1 Ground level
R2 Extended Version "Own Hotline"
x R3 Extended Version "Technical Enquiries"
R4 Extended Version "Hold-Back-Time"
R5 Extended Version "User Management"
Proactive Production Security:
x P1 Ground Level
x P2 Extended Version "Elimination of Threatening Errors or Self Known Problems"
x P3 Extended Version "Passive Release Tests"
x P4 Extended Version "Performance Improvements"
P5 Extended Version "(External Software-)Life Cycle Management"
If the activities, which are not mentioned here, are necessary, it is communicated to the customer and those are assigned to the correct Prosi-category (also when these are not agreed in the contract)
7.2 Procedure of Incident / Problem-Processing
7.2.1 Acceptance of Incidents / Problems
As a general rule, the acceptance of incidents / problems takes place via tool "IMPACT-WEB". Every system-in-charge checks several times in a day the entry of potential incidents.
If for the application an incident occurs, system-in-charge enters it as an authorised user and does the first analysis of the problem. The initiator of the problem is incorporated for the assessment of the problem in order to reproduce the case as the case may be. If an incident is forwarded it is documented in incident, the outcome of which is generated by the present error diagnostic and what has been done up till now for the defect fixing.
In the incident the compass HS-Nr. is set for the ProSi-Project of application, so that the man-days of the corresponding process can be estimated.
In case the user calls the system-in-charge directly and registers a problem, then for this purpose an incident is opened by the system-in-charge. Thus it is ensured that the problems encountered directly by the user are also processed with the equal priority.
7.2.2 Procedure for Prevention, that problems are occurred from this application
In case of problems with the application, it is checked by the system-in-charge in the first step whether the changes in the application were carried out, which can be the cause of the problems.
If this is not the case, it is checked mutually with the HVB_Info, whether the server installations or other technical infrastructure was changed.
The problem is attempted to be replicated in test environment and is monitored with suitable analysis tools.
In case of implemented program changes increased monitoring of the application is carried out within the scope of the proactive production security.
7.2.3 Procedure in case of Redundant Incidents
If more incidents of the same problem occur in case of first occurred incident consequent problem is referred (Indication of reference incident).
7.2.4 Procedure in case of Problems with External Software
In case of incidents on account of defective external software the problem is forwarded to the supplier. If more problems occur in case of external software supplier, a correction period can be allocated as the case may be.
In the incident it is noted by the system-in-charge that apart from the HVB systems a separate processing is necessary.
7.2.5 Procedure in case of Recurring Problems (Taskforce)
If strikingly frequent incidents of a problem occur, it is analysed mutually with the HVB-Info, who is the activator of the problem.
If it deals with technical (Hardware) problems, a taskforce is created with the participation of system-in-charge, team leader and the HVB-Info in order to solve the problem jointly.
If more systems are affected, a taskforce is created by the system-in-charge of the concerned systems.
If it deals with the technical problems, a discussion takes place with the system-in-charge of customer to analyse the defective technical specifications and to look for methods of solution as the case may be.
If the problems have serious implications on the usage of application, a new to-date message is placed by the user additionally and the users are provided with the possible alternative solutions.
In case of problems, which continue in spite of changes in the system, are analysed and are processed as described above. New changes are recorded by patch/express copy in the production as the case may be.
7.2.6 Dealing with Defective Run
Incidents, which are dealt with wrongly by the system-in-charge, are checked in the correct status and are forwarded via "IMPACT-WEB".
If the right status cannot be determined, the initiator of the incident is enquired, which application creates problems. The application i.d.R. assigns a proper responsibility via the repository.
7.2.7 Intermediate Status
If the problem cannot be removed immediately, the initiator of the problem is informed about current intermediate status. Here the current status of the incident is described and the user is informed on telephone as the case may be. The incident remains open as long as it is finally taken care of.
7.2.8 Decisions for/against patches by whom?
If a serious problem occurs in an application, or if the problem is still not fixed after the change of components, possibly a patch / express copy is necessary.
The decision whether a patch must be carried out, is taken by the system-in-charge at the first step. If the system-in-charge is of the opinion that, a patch is necessary, he informs it to the customer and takes their approval.
Further the approval of HVB-Info and of team leader is taken. The possible risk involved is pointed out.
If the patch is necessary during the Change-Stop-Period, additionally the approval of BB-leader is taken in writing.
In case of "normal" problems which do not affect the application seriously, i.d.R. is maintained with the productive control up to the next planned release.
7.2.9 Procedure in case of Postponed Problems
The prioritisation of problems is undertaken mutually with the customer. If an immediate implementation of change is not possible due to lack of resources or degree of changes, an interim solution is discussed with the customer.
If the customer agrees with the postponement, a new to-date message is placed in order to provide an alternative solution to the users of the application.
If from the point of HVB system a corrected run is necessary, it is initiated whenever possible.
If a postponement is not possible, the problem must be escalated in order to postpone other assignments or to demand support.
If it deals with the problem of correct technical implementation of defective functional specifications, it is discussed in coordination with the customer to change this incident in a CR and to process via AB.
7.2.10 For which project are man-days charged?
The man-days are charged for those projects in which the problem is occurred. If the problem is a consequence of errors in delivery system, the system-in-charge of the delivery system is approached with the request to remove the errors in their system at the expense of their own Prosi.
7.2.11 Acceptance/ Release of Change
The system-in-charge in the HVB systems tests the changes carried out. Smaller absolute technical functions (e.g. Job restart, …) are not considered by special department.
For changes in the functional logic, (provided that it is not the regeneration of the originally accepted status) the special department tests it as follows:
The system-in-charge makes the application available in test to special department and specifies suitable data for the test.
The special department tests first of all the test cases provided to them and reports the outcomes. If error or undesired outcome is occurred, the special department contacts the HVB systems system-in-charge and request for its removal.
After the reported error is removed the system-in-charge gives feedback to the special department and requests for the test again.
A written acceptance is demanded from the special department in connection with all test runs and about accuracy, which is stored in Aladin.
Only the changes for which acceptance in writing is available from the special department are brought in production.
7.2.12 Closing of Incidents / Problems
An incident/problem is closed principally, when an error is fixed and corrected components are brought in the production.
I.d.R. the initiator of problem is informed on telephone about the removal.
The closing of incident / problem is carried out by the final authorised person after consultation with the system-in-charge.
7.2.13 Documentation for "Lessons learned"
It is decided from case to case. Fundamentally, the documentation must be complete in Aladin.
7.2.14 Procedure in case of problems detected by user
If a user detects an application error, he calls i.d.R. the service line of HVB-info which initiates an incident and forwards it to system-in-charge.
If the user reports directly to the system-in-charge, he initiates an incident and processes it as described under 7.2.1.
7.3 Agreements with the customer
Fundamentally the contract agreements with the customer are valid which are binding on both the sides.
7.4 Response Time/ Service Level
Agreed service and response time are mentioned in contract. The service time is described in chapter 5.1.
7.5 Availability (Demands)
For the application system KRIBON standard availability is agreed upon contractually.
7.6 Path of Escalation and Period (incl. HVB-Info)
Fundamentally, the escalation takes place via the team leader of system-in-charge. The problem is escalated to the BB-leader and the GF as the case may be. Possible escalations are notified by the system-in-charge at an early stage.
7.7 Limitation of Man-Days
If the handling of reported problems demands more than 2 man-days, then communication is carried out with the customer. If in the process no activity is desired by the customer, further measures of removal are stopped.
The communication with the customer is documented in the application system folder in ALADIN under "06 Miscellaneous".
7.8 Estimation of Incidents (Trends, Frequency)
The estimation of incidents is evaluated monthly by the team leaders in collaboration with the MPM. Here trends and frequencies are identified. If for an application, noticeable problems arise often then possible improvement measures are discussed in regular discussions with the customer.
7.9 Preventive identification of Risks
It is stated in the proactive production security.
7.10 Procedure in case of Workarounds
7.10.1 Where are they documented?
Workarounds, which result from an incident, are specified there.
Workarounds, which result from application support, are specified in the concerned CR.
7.10.2 How is the final correction ensured?
The CR or incident is closed principally, when the workaround is finally removed, or concluding measures are defined and implemented.
7.10.3 Organisational Information to Customers, UHD
If the workarounds are necessary to the user of the application, the control and coordination is regulated via HAG.
In individual cases the legends are also implemented in the application, which call attention of the user to the workarounds.
8 Appendix (ProSi-Agreements of System)
9 Change History
Date Version By whom Change
05.04.06 V 0.1 Zink Completion (capable to be reviewed)
|
More Less | | Other - Mumbai University | | Years of translation experience: 3. Registered at ProZ.com: Jun 2008. | | N/A | German to English (Mumbai University)
| | N/A | | Adobe Acrobat, Adobe Photoshop, Microsoft Excel, Microsoft Word, Abby Fine Reader, Pagemaker, Powerpoint, SDL TRADOS, Wordfast | | English (DOC) | | Rajashree Pathak endorses ProZ.com's Professional Guidelines. | | About me I am a full time professional freelancer having 3 years of experience in the field of German into English translations.
I strongly believe in self-motivation and delivering the job on time. According to me, one's command over the target and source languages counts a lot.
More than degree, experience and quality of the work matters in the end.
My expertise is to translate texts particularly related to Technical, Marketing, Patent, Advertising, I.T., Commercial, Legal.
I have got high speed broadband connection for the faster internet access.
Have worked for translation agencies as well as companies in India and abroad, dealing with variety of texts.
Summery of translation experience :
• I.T. text translation from German into English. This text also includes various
system / user manuals, technical terminologies and varied schedules for the
implementation of new computer systems. It is done for a translation agency.
• Financial Text related to company dealings and transactions for a particular
period.
• Legal text related to various agreements.
• Some correspondence letters, faxes from English into German.
• Menu and Submenu options of Auto-Cad Software from German into English.
Documentation of system design of Post Finance from German into English
including various tables and diagrams.
Educational Qualifications :
• Post Advanced Diploma in Translation and Tourism in the year 2005-06 at university of Mumbai. The course consisted of analysis and translation of texts of various fields, such as
• Information & Technology
• Patent
• Technical
• Advertising
• Legal etc. from German to English
• German Language Courses up to MIII (equivalent to Graduation) from Max
Mueller Bhavan, Mumbai.
• Graduation in commerce
Additionally, I am in the field of D.T.P. for more than 7 years, working for an educational book-publishing house. The work also includes designing Visiting cards, Letterheads, Logos etc.
I can assure of best quality and on time delivery along with Desk Top Publishing skills.
|
|
Keywords: I am freelancer doing German > English Translations - efficient service at reasonable rates in various fields - I.T., Marketing, Technical, Patent, Advertising, Certificates, Tourism. Additionally I am also doing D.T.P. jobs in English as well as in various Indian languages.
 This profile has received 7 visits in the last month,
from a total of 4 visitors
Profile last updated
Mar 28, 2011 |
The translation workplace 
Expertise