… Neugier, Wissbegierigkeit sowie Ziel- und Lösungsorientierung bilden immer die Basis …

Das Verstehen von Wertschöpfungsketten und Geschäftsmodellen kombiniert mit den gelebten Erfahrungen in verschiedenen Business Rollen, einer methodischen Heransgehensweise und fundiertes Domain-Wissen definiert die Portfolio-Schwerpunkte.

Problemzonen

  • Services werden vielmals individuell produziert und betrieben – dies führt in der Regel zu sehr hohen Transaktionskosten im Betrieb
  • das Know How, wie der Service sich zusammensetzt, welchen Nutzen er erbringen soll und wie betrieben werden soll, hängt oft an einzelnen Personen – dies führt zu hohen Risiken bei organisatorischen Veränderungen
  • die vorhandenen Prozesse werden meistens von den Tools vorgegeben ohne zuvor definiert worden zu sein
  • Prozesse aus vorhandenen Frameworks werden oft als Einzelprozesse und nicht in Ketten zusammengefasst eingeführt (Bsp.: Incident-Prozess wird ohne den Configuration- und Change-Prozess eingeführt)
  • gelebte Prozesse verhalten sich oft anders als die dokumentierten Prozesse
  • Prozesse im Service-Umfeld müssen das Business mit IT/Infrastruktur/Ressourcen verbinden tun dies aber in vielen fällen nicht bzw. nur halbherzig

Lösung

  1. Etablieren der Rolle des Produktmanagers – verantwortlich dafür, dass ein Service im Sinne der Spezifikation (Nutzen) produziert werden kann
  2. Etablieren der Rolle des Service Managers – verantwortlich dafür, dass der Betrieb des Service im Sinne des SLAs gesteuert wird
  3. Implementieren des Produkt Lifecycle Prozesses, damit das Produkt immer marktfähig ist und bleibt
  4. Implementieren des Service Lifecycle Prozesses, damit der Service immer den mit dem Service Kunden vereinbarten Nutzen bringt
  5. Implementieren von Prozessteilstrecken (aus End-to-End-Sicht), damit eine sehr hohe Wirksamkeit gegeben ist

Anmerkung: in der Regel basieren die Prozesse auf vorhandenen Frameworks (Bsp.: ITIL oder eTOM)

Problemzonen

  • Kennzahlen bilden in der Regel nur die eigene Leistungsfähigkeit (des Service Providers) ab und nicht den Nutzen, den man sich erwartet
  • Kennzahlen werden in der Regel von Kaufleuten oder Rechtsanwälten formuliert und nicht von den Wertschöpfungsverantwortlichen
  • Kennzahlen sind oft zu technisch formuliert und erlauben keine Aussagen über die Auswirkungen auf das Business und die Wertschöpfungsketten
  • oft gibt es  zu viele und kompliziert formulierte Kennzahlen so dass nicht nicht verstanden und auch kommuniziert werden
  • Kennzahlen sind oft nur definiert, werden aber weder gemessen noch zur Steuerung des Business herangezogen
  • fehlende Normierung und Standardisierung führt zu einer geringen Vergleichbarkeit
  • fehlendes Wissen über die Wertschöpfungsketten

Lösung

  1. Definieren, wer ist der Erbringer des Service (Service Provider), wer bezahlt dafür (Service Kunde) und wem nutzt er (Service Nutzer)
  2. Beschreibung des zu erwartenden Nutzens in der Wertschöpfungskette des Kunden sowie der Wertschöpfungsketten im Business
  3. wenige, aussagekräftige Kennzahlen festlegen, die den Nutzen steuerbar machen
  4. Definition der wenigen Prozesse, die zur Nutzensteuerung seitens Service Provider und Service Kunde benötigt werden
  5. Definition von Business Rules zur Standardisierung, Normierung und Wiederverwendbarkeit von Business Kennzahlen
  6. Aufbau eines Glossars zur Vereinheitlichung von Begriffen

Problemzonen

  • es wird versucht, Servicemodelle und Infrastrukturmodelle im gleichen Toolschema mit abzubilden, was aber aufgrund unterschiedlicher Lifecycles und Verantwortlichkeiten fast unmöglich ist
  • in den meisten Fällen findet man bei der Einführung von Prozessen (Bsp.: Service Management) in den Unternehmen die unterschiedlichsten Tools mit unterschiedlichen Maturitäten vor
  • Begrifflichkeiten und die Abbildung übergreifender (Master-)Daten sind nicht standardisiert
  • Tools werden über technische Interfaces miteinander gekoppelt – die Kopplung über Daten wird vernachlässigt
  • die Ownership und das Zusammenspiel Prozess-relevanter Daten ist nicht geregelt – Prozesse kombinieren und verbinden immer ERP-, CRM-, Prozess-, Monitoring- und Infrastrukturdaten

Lösung

  1. Aufbau eines Glossars zur Harmonisierung und Standardisierung von Service Management relevanten Begrifflichkeiten
  2. Etablieren des Servicemodells als Master Data Pool
  3. Implementierung des Servicemodells in einem dafür geeigneten Tool
  4. Implementierung der Prozesse zur Erstellung und Pflege der Servicemodelle
  5. Kopplung von ERP-, CRM-, Monitoring-Systemen und CMDB mit dem Servicemodell

Problemzonen

  • Konfigurationsdatenbanken zur Verwaltung der Infrastruktur (CMDB) haben sich mittlerweile etabliert – die Abbildung von Services in CMDBs haben sich jedoch als sehr schwierig bzw. unmöglich erwiesen
  • Services setzen sich in der Regel aus einer Kombination von Infrastrukturelementen und Dienstleistungen zusammen – diese sind entweder direkt einem Service zuordenbar, genutzt von vielen Services oder auch von einem Zulieferer erbracht (dessen CMDB jedoch unsichtbar ist)
  • die Bewertung der Wirkung von Störungen oder Änderungen von Infrastrukturelementen auf den Service lassen sich nur sehr schwer ermitteln
  • Services und deren Leistungsmerkmale werden durch Verkaufsprozesse festgelegt, die technischen Merkmale der Infrastrukturelemente in der Regel durch Implementierungsprozesse – die Steuerung dieser Prozesse erfolgt in den meisten Fällen in unterschiedlichen Tools und damit sind Inkonsistenzen und Methodenbrüche bei der Abbildung der notwendigen Informationen fast unvermeidbar

Lösung

  1. Modellierung und Verwendung von Servicemodellen zur Abbildung von Wirkketten (aus Sicht des Service und nicht der Infrastruktur)
  2. Einführen einen “Kopplungselements” (Service Asset in ITIL), welche die Infrasturkurtopologien mit den Service Modellen verwendet
  3. Entkopplung der Lifecycles von Infrastruktur und Service – es muss möglich sein, die Infrastruktur auszutauschen, ohne das Servicemodell zu verändern, denn Verändern bedeutet immer eine Vertragsänderung mit dem Service Kunden
  4. Etablieren von spezifischen Prozessen (inkl. Rollen) für die Pflege beider Modelle

Problemzonen

  • Kundenkontakte werden über verschiedenste Kanäle bzw. Touchpoints gepflegt
  • jeder Touchpoint hat eigene Tools, über die die Kontakte und die Kommunikation mit den Kunden abgewickelt werden
  • Transaktion, stimuliert über diverse Touchpoints lassen sich teilweise nicht mehr in einen durch Tools auswertbaren kausalen Zusammenhang bringen (Bsp.: Kunde bringt defektes Gerät in den Shop, wird per Mail über einen Austauschtermin informiert und bekommt per Post Ersatzgerät)
  • die Interaktion mit dem Kunden an jedem Touchpoint sollte die selbe verlässliche Informationsbasis haben, damit Kundenanliegen bearbeitet werden können

Lösung

  1. Verlinkung der verschiedensten Tools mit gemeinsamen Identifikatoren (Master Data)
  2. Aufbau eines Cockpits, welches die verschiedensten Informationen (Störungstickets, Bestellungen, Rechnungen, Kommunikationen, Lieferungen, etc.)  abruft und in einen kausalen und zeitlichen Kontext bringt
  3. Standardisierung der Prozesse, egal über welchen Kanal/Touchpoint Anliegen bearbeitet werden
  4. aufgrund von Mustern proaktiv kritische Kundensituationen vermeiden (Bsp.: Bill Shocks)
Prozesse modellieren und anpassen aber auch Service Management einführen, heisst Menschen zu motivieren und zu mobilisieren. Dazu braucht es verschiedene Arten der Unterstützung und Begleitung:
  • als Mentor – Fürsprecher, Förderer und Ratgeber eines Jüngeren oder weniger Erfahrenen
  • als Guide – Verantwortung und Erfahrung Ziele zu erreichen
  • als Coach – Betreuung von Mitarbeitern und Fördern der Potentiale
  • als Referee – Sachverständiger und Gutachter
Herkunft: Das Wort Mentor findet seinen Ursprung in der griechischen Mythologie. Vor Auszug in den Trojanischen Krieg übertrug König Odysseus seinem Vertrauten namens Mentor die Verantwortung dafür, während seiner Abwesenheit die Erziehung seines Sohnes Telemachos zu übernehmen. Mentors Aufgabe war es in dieser Zeit, sowohl ihn in die Gesellschaft einzuführen als auch für ihn väterlicher Freund, Lehrer, Vertrauter und Berater zu sein.
Schulung und Training:
  • Einführen und Etablieren agiler Arbeitsmethoden
  • Einführung ins Service Management und dessen Grundbegriffe
  • Prozesse des Service Managements (eTOM, SID, ITIL, ISO20010) in ihrer praktischen Wirkung
  • Verwendung von Daten und Tools
Begleitung/Betreuung von Mitarbeitern
  • Review von Arbeitsergebnissen
  • gemeinsame Bearbeitung von Fragestellungen im Umfeld von Services
  • individuelles Training

pensa tu! versteht sich im Sinne der Herkunft als verlässlicher und vertrauensvoller Partner, um den anvertrauten Mitarbeitern die gewünschten Fähigkeiten zu vermitteln.

Analogie: Ein Ziel zu erreichen gleicht einer Bergbesteigung. Der Weg zum Ziel ist mit Herausforderungen, Risiken, Ängsten, Unwägbarkeiten und oft auch Gefahren verbunden. Insbesondere auf neuem oder unbekanntem Gelände reduzieren selbst geübte Bergsteiger ihr persönliches Risiko, indem sie sich zeitweise einem erfahrenen Bergführer anvertrauen.

Schwerpunkte hierbei sind:
  • Konzeptuelle Erarbeitung spezifischer Strategien beim Prozessdeign und -modllierung
  • Unterstützung bei der Erstellung von nutzenorientierten Kennzahlensysteme, Service Level Agreements (SLA) und Operational Level Agreements (OLA)
  • Unterstützung bei Outsourcing- und Insourcingvorhaben durch Abbildung geeignerter Kennzahlen, Modellierung relevanter Prozesse (Incident, Change, etc.) unter Betrachtung des gewünschten Nutzens

pensa tu! versteht sich in dieser Analogie als erfahrener und zuverlässiger Bergführer, der die Aufgabe und das Ziel hat, Sie und Ihr Unternehmen sicher zum Gipfel zu bringen.

Herkunft: Der Begriff Coach bezeichnet sowohl eine Kutsche, als auch den Kutscher, der die Pferde lenkt und betreut.  Als Ur-Form des Coaching kann somit jene Tätigkeit gesehen werden, die ein Vorgesetzter im Rahmen seiner Führungsarbeit an seinen Mitarbeitern leistet.
Betreuung spezifischer Rollen 
  • Projektleiter
  • Business Owner
  • Prozess Owner
  • Service Manager / Service Level Manager
  • Produkt Manager
  • Business Analisten
Troubleshooting
  • Interims Projektleiter
  • Interims Process Owner
  • Interims Service Manager / Service Level Manager
  • Interims Produkt Manager
Begleitung von Implementierungen
  • Aufbau einer serviceorientierten Systemarchitektur (Datenarchitektur, Datenflüsse, Rollen und Verantwortlichkeiten, Toolunterstützung, Produktdesign)
  • Tool-Auswahl (Erstellung von Ausschreibungsunterlagen, Durchführung des Bewertungs- und Evaluationsprozesses)
  • Unterstützung bei der Modellierung und Implementierung von Service Management Prozessen

pensa tu! versteht sich als verlässlicher und vertrauensvoller Partner, um ihre Potentiale zu fördern und zu stärken.

Definiton: Der Sachverständige ist eine unabhängige integre Person, die auf einem oder mehreren bestimmten Gebieten über besondere Sachkenntnis sowie Erfahrung verfügt. Der Sachverständige trifft aufgrund eines Auftrages allgemeingültige Aussagen über einen ihm vorgelegten oder von ihm festgehaltenen Sachverhalt. Er besitzt ebenfalls die Fähigkeit, die Beurteilung dieses Sachverhaltes in Wort und Schrift nachvollziehbar darzustellen.
Erstellung von Gutachten:
  • Risiken von SLAs/OLAs
  • Maturität im Service Management
  • Wirksamkeit von Prozessen
  • Prozess-Analyse
Durchführung von Audits:
  • Service Management Prozesse
  • SLA / OLA
  • Tool- und Datenarchitektur
  • Process Mining zur Erfassung der IST-Situation
pensa tu! bringt als Referee die Kompetenz und Erfahrung von 15 Jahren Service Management in verschiedensten Branchen und Unternehmen ein.