20070506r Rödl & Partner Internationales Beschwerdemanagement (Teil 2)
|
|
|
»manage
it«
als
|
Internationales Beschwerdemanagement (Teil 2) Vielsprachig lamentieren Die Internationalisierung des Beschwerdemanagements darf nicht alleine als IT-technische Aufgabe verstanden werden. Ohne die Betrachtung der damit verbundenen strategischen Aufgaben werden Unternehmen nur einen Teilnutzen erzielen können. Andererseits müssen Mitarbeiter, die fachliche Entscheidungen treffen, auch die technologischen Anforderungen der verschiedenen Standorte mit teils unterschiedlichen IT-Plattformen richtig einschätzen können. Hierzu ist es erforderlich, die Belange und Maßstäbe der IT-Seite zu kennen.
n diesem Beitrag fassen wir deshalb die wichtigsten IT-Aspekte einer internationalen Beschwerdemanagementlösung zusammen. 1 Internationales Beschwerdemanagement als IT-HerausforderungAus IT-Sicht bietet die Internationalisierung einer Software die Möglichkeit zur Homogenisierung und nachgelagert auch zur Kosteneinsparung. Die Homogenisierung oder Vereinheitlichung von Software-Standards vereinfacht die Pflege der Produkte und den Austausch von Daten zwischen den einzelnen Ländern. Gerade der Datentransfer ist ein zentraler Aspekt bei der Einführung eines ganzheitlichen, umfassenden, globalen Beschwerdemanagement-Systems. Er ist Voraussetzung für länderübergreifende Auswertungen und Analysen. Ohne diese im Sinne eines kontinuierlichen Verbesserungsprozesses essenziellen Informationen werden Unternehmen nur operativen Nutzen erzielen, aber den strategischen Vorteil nicht ausschöpfen. Mit der Gleichschaltung von Systemen lassen sich auch Kosteneinsparungseffekte erzielen, indem das Unternehmen weniger Manpower und weniger unterschiedliches Software-Know-how vorhalten muss. Unter Umständen ergeben sich auch günstigere Konditionen bei den Lizenzen, etwa bei Updates. Die Notwendigkeit einer Erstellung und Wartung aufwendiger Schnittstellen zum Datenaustausch entfällt. Die Einführung eines internationalen Beschwerdemanagement-Systems wird Unternehmen, bei denen bereits länderübergreifende Verzahnungen im Geschäftsbetrieb bestehen, naturgemäß deutlich leichter fallen als solchen mit einer weitgehenden Autonomie der Standorte. Im zweiten Fall könnten im Vorfeld des eigentlichen Beschwerdemanagement-Projekts erst einmal schwierige Verhandlungen über einheitliche IT-Standards erforderlich sein, die sich auf die Projektlaufzeit und dementsprechend auch auf die Kosten auswirken können. Eine zentrale Konzern-IT mit globaler Entscheidungskompetenz vereinfacht hier vieles.
2 Die Wahl der geeigneten SoftwareNeben den rein fachlich-funktionalen Anforderungen an ein internationales Beschwerdemanagement-System muss dieses natürlich auch den auf IT-Seite geltenden Maßstäben Rechnung tragen. Bei kleineren Softwareprojekten – meist ein bis fünf Arbeitsplätze – mag es noch möglich sein, Insellösungen im Unternehmen einzuführen. Je größer aber das Projekt, desto wichtiger wird es, mit den Unternehmens-Standards konform zu sein.
2.1 PlattformDie Plattformfrage, also die Frage nach dem Betriebssystem eines Computers, stellt sich in zweierlei Hinsicht: einmal bezüglich der Client-Rechner und ein zweites Mal bezüglich der eingesetzten Server. Ein Beschwerdemanagement-System wird in der Regel auf Client-PCs in Kundenbetreuungsabteilungen genutzt. Im Hintergrund sind dazu – je nach Software-Architektur – noch ein oder mehrere Server erforderlich. Minimal ist dies ein Datenbank- Server, welcher sämtliche Daten des Beschwerdemanagement-Systems verwaltet. Die Clientrechner werden in Unternehmen fast ausschließlich mit Varianten der Microsoft Windows-Produktpalette betrieben. Nennenswerte Verbreitung von Unix-Derivaten (Linux) gibt es derzeit bei Kommunen und im öffentlichen Dienst. Serverseitig gibt es deutlich mehr unterschiedliche Plattformen, oftmals auch bedingt durch die unterschiedliche Nutzung der Server. Unix-Derivate, MS Windows Server und Sun Solaris stellen hier den Großteil der Plattformen. In den meisten Fällen ist der Anbieter von Beschwerdemanagement-Systemen nur indirekt für die Einhaltung der Server-seitigen Plattformstandards verantwortlich, da meist Drittapplikationen zum Einsatz kommen (DBMS, Webserver etc.). Insofern ist eher entscheidend, dass der Hersteller der Drittapplikationen möglichst unterschiedliche Plattformen unterstützt. Im Zuge des Kostendrucks auf die IT kann der Trend zum verstärkten Einsatz von Open Source-Produkten weiter zunehmen. Die Nutzung solcher Software, für die keine Lizenzgebühren gezahlt werden müssen, kann dazu führen, dass auch Linux zukünftig stärkere Beachtung erfährt als derzeit der Fall. 2.2 ArchitekturSoftwarearchitekturen haben sich seit Beginn des EDV-Zeitalters ständig geändert und werden dies wohl auch weiterhin tun. Treibende Elemente dieser Änderung sind, neben Innovationen im Hard- und Softwarebereich, vor allem die zunehmende Vernetzung von Informationen aus den verschiedensten Unternehmensbereichen und Quellsystemen und die damit verbundenen IT-Herausforderungen. Architekturen, die heute im Unternehmensbereich Relevanz haben, sind: ● Client-Server (Zwei-Schicht-Architektur): Mit Einführung der Windows PCs wurde diese Architektur geschaffen. Auf einem Client-PC läuft ein Programm, welches mit einem anderen Programm (Datenbank) auf einem Server kommuniziert. Die gesamte Programmlogik liegt im Clientprogramm, der Server dient der Datenverwaltung. Nachteil dieser Plattform ist zum einen die große Abhängigkeit vom Client-Betriebssystem, die hohe Anforderungen an die Client-Hardware stellt. Zum anderen ergeben sich hohe Kosten für Installation/Wartung der Software auf den Clients. ● Web: Webapplikationen sind in der Regel plattformneutral, d.h. nicht abhängig vom darunter liegenden Betriebssystem. Sie werden über den Internet Browser auf dem Clientrechner gestartet. Die Programmlogik liegt nicht auf dem Client, sondern auf einem Web-Server. Der Vorteil: Meist ist keine Clientinstallation erforderlich, was die Betriebskosten reduziert. Nachteilig ist, dass neben dem Datenbank-Server ein weiterer Server, der Web-Server, erforderlich ist. Webapplikationen sind nicht immer zu allen Web-Servern kompatibel.
●
Terminal Server:
Terminal Server ist eigentlich keine Architektur, sondern eine
Betriebssystemplattform. Meist wird der Begriff jedoch in diesem Kontext
verwendet. Es gibt zwei verbreitete Varianten von Terminal Servern, den
Microsoft Windows Terminal Server (WTS) und den Citrix Presentation Server.
Terminal Server liefern ähnlich wie die Hostrechner der 60er und 70er Jahre nur
Bildschirminhalte an den angeschlossenen Clientrechner. Die Programme laufen
allesamt zentral. Vorteile: Es werden weniger Daten zum Client-PC ● Drei-Schicht-Architektur: Auch diese Architektur ist eine Client-Server-Architektur. Hier wird zwischen dem Client und dem Datenbank-Server eine weitere Ebene eingeführt, die für die Datenverarbeitung zuständig ist. Vorteil dieser Architektur ist die Entlastung des Clients, der hier nur für die Interaktion mit dem Benutzer verantwortlich ist. Ebenfalls positiv ist die leichtere Skalierbarkeit und Wartbarkeit eines solchen Systems. ● SOA: Die Abkürzung SOA steht für Service Oriented Architecture oder serviceorientierte Architektur. Darunter versteht man die Implementierung von Funktionen in Form von wieder verwendbaren, technisch voneinander unabhängigen und fachlich lose gekoppelten Services. Ein Geschäftsprozess im Unternehmen kann dann idealisiert als Aneinanderreihung von verschiedenen Serviceaufrufen verstanden werden. Solche Services können im Prinzip von jeder Applikation genutzt werden. Sie sind dadurch wiederverwendbar. Die Applikationen werden einfacher und kostengünstiger erstell- und pflegbar, weil sie auf vorhandene Services zurückgreifen können und weniger Datenzugriffslogik enthalten. SOA ist die jüngste der aufgeführten Architekturen. Seit etwa 2 Jahren wird dieses Thema in der Fachpresse ausgiebig diskutiert. Jedoch gibt es – auch in deutschen Unternehmen – bereits Implementationen, die weiter zurückgehen. Bereits vor 6 Jahren nahm die Rödl IT-Consulting GmbH in Zusammenarbeit mit einem deutschen Großkonzern die Adaption von Sorry! auf SOA vor. Somit ist Rödl IT Vorreiter / Early Adaptor im Applikationsbereich. Mehrere Tausend User arbeiten mit einem hochintegrierten Sorry! über Serviceaufrufe, die verschiedene Servicegeber wie Kunden-Service, Beschwerde-Service, Kundenhistorie etc., ansprechen. Je nachdem, welche der aufgeführten Architekturen ein Unternehmen präferiert, ergeben sich unterschiedliche Anforderungen an das einzuführende Beschwerdemanagement-System. Einige sind grundsätzliche Systemeigenschaften, die für eine Installation zu erfüllen sind. Beschwerdemanagement-Systeme auf Basis von SOA-Architekturen hingegen sind derzeit wegen noch fehlender SOA-Standards nicht ohne vorhergehende maßgenaue Anpassung an die Gegebenheit des Unternehmens möglich. 2.3 SchnittstellenDa einerseits Insellösungen in einem Unternehmen unerwünscht sind, andererseits der Datenaustausch bei einem Beschwerdemanagement-System einer der wichtigsten Aspekte ist, kommt Schnittstellen bei internationalen Lösungen eine hohe Bedeutung zu. Schnittstellen können für den technischen Betrieb eines Beschwerdemanagement-Systems wichtig sein, beispielsweise die Schnittstelle zu einem vorhandenem Datenbank Management System (DBMS) wie Oracle. Sie können darüber hinaus für den operativen Betrieb notwendig sein: beispielsweise eine Schnittstelle zu MS Word oder Outlook für die Kommunikation mit dem Kunden. Die strategische Nutzung der gewonnenen Daten kann etwa eine Schnittstelle zu einer Business Intelligence Lösung wie Cognos erfordern. Die nachfolgende Aufstellung macht deutlich, dass Schnittstellen zum Beschwerdemanagement-System sehr leicht eine hohe Komplexität erreichen können:
2.4 SkalierbarkeitUnter Skalierbarkeit einer Software versteht man die Anpassbarkeit bei erhöhtem Ressourcenbedarf. Beim Rollout eines zentralen Beschwerdemanagement-Systems von einem Land auf weitere erhöht sich der Ressourcenbedarf, weil mehr Daten verwaltet werden müssen: Es werden mehr Kundenanliegen eingegeben, unter Umständen werden auch zusätzliche Kundenstammdaten importiert. Außerdem arbeiten mehr Anwender mit dem System, was ebenfalls den Ressourcenbedarf steigert. Je nach Architektur des Beschwerdemanagement-Systems kann man die Leistung durch Austausch der verwendeten Server-Hardware oder Hinzufügen zusätzlicher Server-Systeme steigern. Ist nicht das Beschwerdemanagement-System selbst der begrenzende Faktor, sondern die gegebene Netzwerkarchitektur, so mag auch ein Architekturwechsel eine Möglichkeit der Skalierung sein: z.B. weg von einem Zwei-Schicht-Client-Server hin zum Terminal Server. Eventuell kann auch ein Architektur-Mix sinnvoll sein: dezentral Web-Applikationen, zentral Client-Server. 2.5 AnpassbarkeitDa ein Unternehmen kein statisches Gebilde darstellt, sondern sich wie ein Organismus ständig wandelt, müssen diese Änderungen auch im Beschwerdemanagement-System abbildbar sein. Dieses Ändern sollte keine Programmierarbeiten nach sich ziehen, sondern mittels Anpassung der Konfiguration durch den Fach- beziehungsweise IT-Administrator möglich sein. Änderungsbedarf entsteht beispielsweise, wenn sich der Beschwerdebearbeitungsprozess im Unternehmen ändert, oder wenn Layout oder Inhalt der Formbriefe für die Kundenkommunikation neu gestaltet werden. Eventuell soll trotz Speicherung in einer gemeinsamen Datenbank jedes Land nur seine eigenen Kunden- und Kontaktdaten einsehen dürfen. Auch dies muss durch Konfiguration geregelt werden. 2.6 MultilingualitätWenn ein und dasselbe Beschwerdemanagement-System in verschiedenen Ländern betrieben werden soll, so ist die Mehrsprachigkeit der Software unerlässlich. Dabei gilt es zwei Komponenten voneinander zu trennen: die Benutzeroberfläche und die darin auswählbaren Stammdaten. Erstere wird bei einem Rollout durch den Softwareanbieter gewährleistet bzw. es werden entsprechende Module geliefert. Stammdaten fallen in den Bereich der Customizing-Fähigkeit, welche die Applikation bieten muss. So wie beispielsweise neue Kundenanliegen durch den Fach-Administrator ergänzt werden können, soll es auch bei diesen Daten möglich sein, sie zu übersetzen, ohne auf den Softwareanbieter angewiesen zu sein. Komplizierter wird die Situation in Ländern, in denen die Sprache nicht eindeutig festgelegt ist (z.B. Schweiz). Hier muss die Software zusätzlich die Möglichkeit bieten, mehrere Sprachen für die Kundenkommunikation zu verwenden oder noch besser, die Software entscheidet selbst, welche Sprache bei einem bestimmten Kundenbrief zu wählen ist. 2.7 BerichtswesenWährend vom operativen Part eines leistungsfähigen Beschwerdemanagement-Systems nur wenige Abteilungen profitieren – die Kundenbetreuungsabteilungen der Länder – so ist das dazugehörige Berichtswesen für einen weitaus größeren Kreis von Bedeutung. Angefangen vom Vertrieb, über Marketing, bis hin zu Produktion und Service: Im Prinzip sollten alle Abteilungen Nutznießer der Informationen sein, welche Kunden an das Unternehmen liefern. Durch die unterschiedlichen Adressaten solcher Berichte (fachlich und hierarchisch) muss ein Reporting-System einerseits flexibel in der Steuerung sein, andererseits darf es jedoch nicht zu komplex in der Bedienung sein. Hilfreich ist es, wenn einmal erstellte Berichte abgespeichert und mit anderen Datumseinschränkungen erneut abgerufen werden können. Damit Berichte überhaupt im Unternehmen verteilt werden können, müssen sie in einem Standarddateiformat gespeichert werden (z.B. PDF oder MS Excel). Ansonsten würde jeder Mitarbeiter, der den Bericht lesen soll, eine Lizenz für das Reporting-System benötigen. 2.8 Fazit und AngebotRödl & Partner ist seit vielen Jahren international tätig und hat dies auch zu einer seiner Kernstrategien gemacht. Die Fähigkeit, neue Absatzmärkte frühzeitig zu erkennen und erschließen, zeigt sich zum Beispiel daran, dass Rödl & Partner als eines der ersten deutschen Unternehmen nach dem Fall der Mauer flächendeckend in Osteuropa vertreten war, während andere Unternehmen vorwiegend in westliche Länder expandierten. Heute bietet Rödl & Partner in 31 Ländern seinen Kunden umfassende Beratungsleistungen aus einer Hand an. Auch die Rödl IT-Consulting GmbH als Teil des Rödl & Partner-Konzerns verfügt über Erfahrungen aus internationalen Projekten. So wurden sowohl komplette Einzelprojekte und Lösungen als auch multinationale und multilinguale Systeme erfolgreich bei verschiedenen Kunden eingeführt. Dabei unterstützen wir unsere Kunden auch beratend, beispielsweise bei der Analyse der Standorte und Prozesse. Die Standardapplikation Sorry! für aktives Beschwerdemanagement bietet von Haus aus Funktionen, die einen Einsatz im (fremdsprachigen) Ausland ermöglichen. So sind sämtliche Stammdaten (Katalogdaten) innerhalb der Applikation in verschiedene Sprachen übersetzbar. Beim Anmelden am System wird dem Anwender die Möglichkeit gegeben, per Auswahlfeld zu entscheiden, in welcher Sprache Programmoberfläche und Stammdaten angezeigt werden sollen. Ein Betrieb der Applikation in mehreren Sprachen gleichzeitig ist ohne Probleme möglich. Speziell für Länder mit mehreren Sprachen oder mit einer zentralen Bearbeitung von Kundenanliegen für mehrere Länder bietet Sorry! die Möglichkeit, einem Kunden eine Kommunikationssprache zuzuweisen. Multinationalen Einsatz findet Sorry! beispielsweise bei einem großen deutschen Konsumgüterhersteller. Basierend auf einer Terminal Server Farm (Citrix) arbeiten knapp 50 Mitarbeiter in 10 Ländern mit der Applikation. Die Programmoberfläche wird dabei in 4 Sprachen, die Stammdaten in 10 Sprachen zur Verfügung gestellt. Matthias Menneckemeyer ____________________________________________________________
|
|
