November 2016
Auch 1000 Meilen beginnen mit dem ersten Schritt!
Der Weg zu einem erfolgreichen BMC ITSM Upgrade
Einleitung ................................................................................................................................................................................. 2
1. Der Ruf des Abenteuers .......................................................................................................................................... 3 Die Motivation Die Optionen Das Risiko
2. Der Weg der Prüfungen ........................................................................................................................................... 3 Abenteuer Automotive Abenteuer Produzierendes Gewerbe Abenteuer Öffentlicher Dienst
3. Herr der zwei Welten ............................................................................................................................................... 7 Upgrade-Prozess I: Planung Upgrade-Prozess II: Maßnahmen Upgrade-Prozess III: Vorgehen
Das Staging-Upgrade-Verfahren im Überblick Die User Experience im Überblick
Upgrade-Prozess IV: Produktions-Change
4. Das Ende der Reise? ............................................................................................................................................... 12
Unser Angebot ..................................................................................................................................................................... 13
Die Autoren ........................................................................................................................................................................... 14
Eine BMC ITSM Suite upzugraden oder zu
migrieren ist eine lange und steinige Reise, die
stets mit der Motivation beginnen sollte, warum
man diese Reise unternimmt.
Motivation bildet die Grundlage für Handlungs-
optionen und Risikoeinschätzung, die zusammen
mit Motivation die wichtigsten Parameter für die
Wahl des Lösungswegs darstellen.
Pauschale Aussagen zum »richtigen Weg« für
Upgrades gibt es nicht: der beste Weg ist immer
abhängig vom Unternehmenskontext und wird
von unseren Beratern entlang der individuellen
Kundensituation ermittelt und empfohlen.
Unser Whitepaper beschreibt das Vorgehen für
Upgrades / Migrationen der BMC ITSM Suite auf
dem Hintergrund der Erfahrungen, die unsere
Berater in Kundenprojekten gesammelt haben,
sowie entlang dreier Kundenprojekte und einer
Analyse der BMC-Empfehlungen.
3 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
1. Der Ruf des Abenteuers
Wörtlich übersetzt lautet die im Titel dieses
Whitepapers zitierte Weisheit des chinesischen
Philosophen Laotse: »Eine Reise von tausend Meilen
beginnt unter deinem Fuß«. Nicht der »erste Schritt«
ist der erste Schritt für ein anspruchsvolles Projekt,
sondern die Motivation, die den Fuß überhaupt erst
bewegt.
Etablierte Lösungen wie die BMC ITSM Suite
bestehen oft seit vielen Jahren und genießen
eine hohe Integration in bestehende System- und
Prozesslandschaften. Von einer solchen Lösung
upzugraden oder zu migrieren ist eine lange und
steinige Reise, die ein Höchstmaß an Motivation und
Planung erfordert.
Dies ist die erste Herausforderung für unsere
ComConsult-Berater: die Motivation des Kunden
für ein Upgrade oder eine Migration so präzise zu
ermitteln und zu formulieren, dass Handlungs-
optionen und Lösungsmöglichkeiten sichtbar
werden. Denn nur über den »ersten Schritt« der
Motivation kann der Weg zum Ziel gefunden
werden.
Die Motivation
Zu den häufigsten Gründen, warum Kunden über
ein Upgrade nachdenken, zählen unserer Erfahrung
nach:
• Der Hersteller kündigt das Einstellen des
Supports für die eingesetzte Version an.
• Das Upgrade behebt bekannte Fehler und / oder
Sicherheitslücken der eingesetzten Version.
• Neue Funktionen sind gewünscht, die erst mit
einem Upgrade möglich werden.
• Oberflächen und Technologien der neuen
Version versprechen größere Benutzer-
zufriedenheit.
• Änderungen oder Erweiterungen der verwende-
ten Prozesse führen zu einer Neubewertung der
vorhandenen Lösung.
Die Optionen
Aus der Fülle der vorhandenen Handlungsoptionen
für ein BMC ITSM Upgrade muss diejenige aus-
gewählt werden, die der Motivation des Kunden am
besten entspricht. Folgende Grundformen haben
unsere Berater mit Kunden diskutiert:
• »Never Change a Running System«
Der Kunde entscheidet sich, die eingesetzte
Version beizubehalten. Dies erfordert keinen
Aufwand, führt aber auch nicht zur Verbesse-
rung der Grundsituation.
4 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
• »Direktes Upgrade«
Der Kunde legt einen entsprechenden Daten-
träger ein und initiiert ein »in-place«-Upgrade.
Dieser Migrationstyp ist perfekt vom Hersteller
automatisiert: einlegen, starten, acht Stunden
warten, fertig. Eine Lösung, die wenig Aufwand
erfordert, aber in der Regel nur für Custom
Builds verfügbar ist.
• »Keep Old, Build New«
Der Kunde baut ein neues System neben
dem alten System auf. Alle Funktionen und
Anpassungen der alten Version sind doku-
mentiert und werden in eine Neuinstallation
der Upgrade-Version des gleichen Produkts
vom gleichen Hersteller übertragen; die alte
Umgebung wird »archiviert« und das neue
System übernimmt die Arbeit. Diese Lösung
erfordert einen hohen Aufwand, aber nur
eine kurze Projektlaufzeit. Da die »alten«
Prozessdaten auf dem ursprünglichen System
verbleiben, sind sie dort weiter einsehbar und
es entfällt eine langfristige Datenmigration.
• »Staging Upgrade«
Der Kunde dupliziert die eingesetzte Version
und erprobt das Upgrade an der Kopie; ist die
Funktionsfähigkeit gesichert, schwenkt er die
Produktion nach dem Abgleich aller Daten auf
die aktualisierte Umgebung um. Der Aufwand
ist hoch, aber diese Lösung erfordert in der
Regel nur eine kurze Downtime.
• »Produktwechsel«
Der Kunde löst sein eingesetztes System durch
ein neues ITSM-Produkt eines anderen Her-
stellers ab und implementiert seine Prozesse
in der neuen Umgebung. Der Aufwand für
diese Lösung ist häufig geringer als bei einem
Upgrade innerhalb der eingesetzten Produkt-
familie, erfordert aber User-Schulungen.
Welche Handlungsoption der Kundensituation und
der Motivationslage entspricht, ermitteln unsere
Berater individuell für jeden Kunden.
Kriterien
Alternativen
Aufwand Laufzeit Komplexität Infrastruktur-kosten
Funktionaler Fortschritt
Support Compliance
Never Change a Running System C C – C – C
Direktes Upgrade C C C C A A
Keep Old, Build New B B B A A A
Staging Upgrade A A A B A A
Produktwechsel B A B B A AA = hoch, B = mittel, C = niedrig, – = entfällt
Tabelle ABC Bewertung Alternativen
5 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Das Risiko
Was könnte passieren? welche Auswirkungen
hat die gewählte Option? welche Fragen müssen
gestellt werden? All dies muss in einer begleitenden
Risikoabschätzung geklärt werden. Grundsätzlich
lassen sich zum Beispiel folgende Fragen stellen:
• Wie viele Personentage bindet das Projekt
und werden zusätzliche externe Ressourcen
benötigt?
• Verursacht das Upgrade Infrastrukturkosten?
• Werden zusätzliche Betriebskosten anfallen
und neue »Skills« benötigt?
• Welche negativen Auswirkungen wie
Downtime oder Serviceeinschränkungen fallen
an und wie lassen diese sich minimieren?
• Heben die positiven Auswirkungen des
Upgrades unterm Strich die negativen Aus-
wirkungen auf?
Das Finden der richtigen Fragen und das Abschät-
zen des Risikos sind in diesem Schritt die Aufgaben
unserer Berater. Dort, wo Risikoabschätzungen
pauschal erfolgen, werden ITSM Upgrades schnell
zu »Projektleichen«.
2. Der Weg der Prüfungen
Die unterschiedlichen Wege, die auf der Basis der
Kundenmotivation und der daraus resultierenden
Optionen für einen ITSM Upgradeprozess beschrit-
ten werden können, lassen sich anhand ausgewähl-
ter Kundenbeispiele aus den Branchen Automotive,
Produzierendes Gewerbe und Öffentlicher Dienst
demonstrieren.
Abenteuer Automotive
Die Lage. Ein Kunde aus dem Bereich Automotive
mit umfangreicher BMC ITSM-Umgebung, sehr
vielen Nutzern, einer Vielzahl von Schnittstellen
einschließlich komplexer Prozess-Schnittstellen,
aber nur wenig Customizing.
Der Weg. Kundenmotivation war die Einstellung
des Supports für die eingesetzte Version. Die Alter-
nativen von »Keep Old, Build New« über »Staging
Upgrade« bis »Produktwechsel« wurden erwogen.
Auf der Basis unserer Beratung wurde entschieden,
den Weg eines »Staging Upgrades« zu gehen und
der Herstellerempfehlung für das nächsthöhere
Release 8.1 einschließlich neuer Schnittstellen-
technologien (BMC Orchestration) zu folgen. Die
MidTier Clients werden beibehalten, neue Skills im
Betrieb werden nicht benötigt und das alte System
wird ersetzt ohne mittelfristige Ausweitung der
Infrastruktur.
Die Reise. Das Upgrade verlief erfolgreich,
allerdings mit unerwartet hohen Aufwänden für
die Sicherstellung der ursprünglichen Prozesse,
6 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
wodurch die Personentage auf einen höheren drei-
stelligen Betrag anwuchsen. Verursacht wurde dies
von undokumentierten Applikationsänderungen im
Hersteller-Update, was den Projektaufwand für ein
»einfaches« Upgrade auf die nächsthöhere Version
letztendlich zu hoch erscheinen ließ.
Abenteuer Produzierendes Gewerbe
Die Lage. Ein Kunde aus dem Bereich Produzie-
rendes Gewerbe mit einer umfangreichen BMC
ITSM-Umgebung, vielen Benutzern, einfachen
Prozess-Schnittstellen und nur wenigen Schnitt-
stellen insgesamt, aber einer höheren Anzahl
kundenspezifischer Anpassungen.
Der Weg. Kundenmotivation war zum einen die
angekündigte Einstellung des Hersteller-Supports,
zum anderen der Wunsch nach neuen Funktionen
(Service Request Portal 8.1). Diskutiert wurden die
Alternativen »Keep Old, Build New« und »Staging
Upgrade«, in einem Proof of Concept fiel die
»Staging Upgrade«-Alternative mit Problemen auf.
Folgerichtig war die von unseren Beratern empfoh-
lene Vorgehensweise »Keep Old, Build New«,
d. h. die Migration auf das nächst höhere Release 8.1
auf der Basis der Herstellerempfehlung und die
Re integration der etablierten, umfangreichen
Anpassungen. Die MidTier Clients werden beibehal-
ten, neue Skills im Betrieb sind nicht erforderlich.
Funktionen und Anpassungen der eingesetzten
Version werden dokumentiert und in eine Neu-
installation der Upgrade-Version des gleichen
Produkts vom gleichen Hersteller übertragen.
Die alte Umgebung wird »archiviert« und die neue
Applikation übernimmt die Arbeit. Das Customizing
und die vereinbarten Prozesse werden durch Tests
und Abnahmeverfahren sichergestellt. Zu den
Vorteilen dieser Vorgehensweise gehören kurze
Downtime, eine einfache Fallback-Alternative
sowie Performance-Steigerung durch Datenarchi-
vierung; zu den Nachteilen gehört ein erheblicher
Aufwand an internen Ressourcen sowie eine erwei-
terte Infrastruktur und erhöhte Betriebskosten.
Die Reise. Das Upgrade verlief erfolgreich,
allerdings mit einem unerwartet hohen Aufwand,
ver ursacht von der im ersten Versuch abgebrochenen
Delta Data Migration (Proof of Concept). Das
Verfahren wurde gestoppt, die neue Umgebung mit
der originalen Version der ITSM Suite installiert,
die Anpassungen des Kunden neu integriert und die
Stammdaten geladen. Die erhöhten Aufwände und
Laufzeiten der Migration waren in diesem Fall den
Anpassungen des Kunden geschuldet.
7 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Zu den Hauptbeweggründen der von uns beratenen
Unternehmen gehört zweifelsohne die Verlänge-
rung des Wartungszeitraums der BMC-Lösung
bzw. die Option, Fehler zu melden und Updates zu
erhalten. Grundsätzlich bietet der BMC-Support
Hilfestellung für ein Upgrade oder eine Migration.
Entscheidend für den Aufwand ist, ob eine Remedy
Custom Build-Lösung oder der Einsatz einer ITSM
Suite vorliegt; liegt beides vor, vervielfältigt sich der
Aufwand.
Abenteuer Öffentlicher Dienst
Die Lage. Ein Kunde aus dem Bereich Öffentlicher
Dienst mit einer Custom Build ITSM 7.6 Lösung,
einer Atrium CMDB, dem Einsatz von Schnitt stellen
durch Orchestration-Lösung und Datenbank-Links
sowie geringerem Datenvolumen.
Der Weg. Kundenmotivation war zum einen die
angekündigte Einstellung des Hersteller-Supports,
zum anderen sollten neue Funktionen im CMDB
BSM-Bereich umgesetzt werden. Diskutiert
wurden die Alternativen »Never Change a Running
System«, »Direktes Upgrade« und »Keep Old,
Build New«. Die von unseren Beratern in dieser
Situation empfohlene Vorgehensweise war, auf der
eingesetzten Version weiterzuarbeiten (»Never
Change a Running System«) und die gewünschten
neuen BSM-Funktionen auf eine Alternative zu
verlagern, die per Schnittstelle angebunden wird.
Zu den Vorteilen dieser Vorgehensweise gehört der
geringe Aufwand, da die alten Clients weiterhin
genutzt werden, zu den Nachteilen der Verlust der
Wartung bei Client-Fehlermeldungen.
Die Reise. An diesem Beispiel erkennt man den
Einfluss, den Anwender bei einem Wechsel der
GUI ausüben können: problematisch wird es immer
dann, wenn Weiterentwicklungen des Herstellers
die Anwender der Applikation dazu zwingen, ihre
»User Experience« neu zu finden. Funktionen, die
die Tätigkeiten des Service Desks erheblich verein-
fachen, hätten nur teilweise und auch nur mit
Abstrichen auf eine Web Client-Oberfläche migriert
werden können, während Alternativen zusätzliche
Kosten verursacht hätten. Wenn ein Upgrade für
den Anwender praktisch ein neues Tool einführt, ist
die Entscheidung des Kunden, nach einem neuen
Produkt zu suchen, nur folgerichtig. Der Verzicht
auf den Einsatz der Atrium CMDB und die Verla-
gerung der Funktionen auf eine technische CMDB
sowie die Neukonzeption der Integration brachte
für den Kunden aber auch prozessuale Vorteile.
Teile der Kosten konnten über den Verzicht auf die
Atrium-Wartung ausgeglichen werden.
Aufgrund der Nachteile der Umstellung, ins-
besondere die erforderlichen Anpassungen und der
Wegfall etablierter Funktionen, folgte der Kunde
unserer Beratung und bewertete seine Zielvor-
gaben neu. Statt eines Upgrades auf Version 9
wurde eine kurzfristige Verlängerung der Wartung
für die Remedy Plattform, der fortgesetze Einsatz
der User Clients sowie die Erstellung einer Ent-
scheidungsvorlage zur Ausschreibung einer neuen
ITSM-Lösung beschlossen.
3. Herr der zwei Welten
Auf der Grundlage unserer Erfahrungen möchten
wir speziell anhand des dritten Kundenbeispiels
die BMC-Empfehlung zur Implementierung von
Kunden-Upgrades* näher beleuchten, der auch die
nachfolgenden Diagramme entnommen sind.
In dem genannten Beispiel aus dem Öffentlichen
Dienst setzt unser Kunde eine Remedy Custom
Build-Lösung mit einer BMC Atrium CMDB in der
Version 7.6.04 ein. Der avisierte End of Support-
Termin sowohl für die Remedy Lösung als auch die
Atrium CMDB ist der 28.01.2017. Die Betriebs-
umgebung des Kunden ist Windows SQL und
Server, auf Client-Seite kommt das Tool Remedy
User in Version 7.6 zum Einsatz.
Ziel ist daher ein Umstieg auf die Version 9.x der
BMC, um die Windows-Betriebsumgebung sowie
die Remedy-Lösung nebst Atrium CMDB bis zum
Jahr 2020 in Wartung zu halten.
Der User Client ist End-of-Life und wird nicht
mehr über den BMC-Support in Wartung gehalten,
sodass Fehlermeldungen, die mit dem Client in Zu-
sammenhang stehen, nicht mehr gemeldet werden
können. Ein Punkt unserer Betrachtung muss daher
die Ablösung der User Clients adressieren.
* https://docs.bmc.com/docs/display/public/brid81/Planning+for+upgrade
8 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Upgrade-Prozess I: Planung
Hier werden die Komponenten identifiziert, die
geändert werden müssen: Applikationen, Platt-
form-Komponenten oder die gesamte Suite. Dies
ist jedoch nicht alles. Vielmehr sind Motivation und
Handlungsoption wie beschrieben aufeinander
abzustimmen und der geplante Weg immer wieder
mit Risikoanalysen zu hinterfragen.
Upgrade-Prozess II: Maßnahmen
Für diesen Schritt sind eine Reihe spezifisch techni-
scher Fragen zu Versionen und Upgrade-Optionen
zu klären. Doch auch hier ist dies nicht alles.
Weitere zu klärende Aspekte sind die Eigenschaften
der Zielumgebung, die Veränderung technischer
Grundlagen (zum Beispiel bei einer Migration auf
Remedy 9.x) hinsichtlich Technologie-Plattform,
Clients und anderer Parameter, sowie die Ermitt-
lung der betroffenen Schnittstellen und deren
eventuelle Neukonzeption.
Upgrade-Prozess III: Vorgehen
Die BMC-Empfehlungen beschreiben zwei
Upgrade-Varianten: »Direktes Upgrade« (in-place)
einer Remedy/ITSM-Applikation, also eine Update-
Installation der Software mit dann zwangsläufig
längerer Laufzeit, oder das Erstellen einer neuen,
parallelen Umgebung (»Staging Upgrade«), in
der dieses Update gegen den dann aktuellen
Datenbestand läuft. Bei der zweiten
Variante ist des Weiteren dafür zu sorgen,
dass das Delta der Daten auf beiden
Umgebungen immer kleiner wird, bis
die neue Umgebung samt um gezogener
Schnittstellen aktiv werden kann.
Die erste Variante (»Direktes Upgrade«)
bietet sich an bei einer selbst erstellten Custom
Build-Lösung. Allerdings wird diese Entscheidung
von der Menge der im System gespeicherten Daten
beeinflusst, mit Auswirkungen auf die Laufzeit des
Upgrades.
Betrifft das Upgrade eine ITSM Suite-Installation,
unabhängig ob Standard oder angepasst, kommt
im Grunde nur die zweite Variante in Frage, wobei
deren geringe Downtime jedoch mit sehr hohen
Ressourcenaufwänden bezahlt werden muss.
What is an in-place
upgrade?
Where can I find
the end-to-end steps for
the scenarios?
What is a staging upgrade?
Upgrade path
planning
What planning is needed
for a staging environment?
Can I just upgrade
the platform components?
What are the benefits of
a complete suite upgrade?
Can I just upgrade
the applications?
Upgrade scope
planning
9 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Das Staging-Upgrade-Verfahren im Überblick
Das nebenstehende Diagramm des Staging-
Upgrade-Verfahrens, wie es von BMC empfohlen
wird, bedarf einiger Erläuterungen:
(1.1) Zwei neue BMC Remedy Server werden
erstellt mit Staging und Abnahme.
(1.2) Eine Datenbankkopie der Produktions-
datenbank wird beiden Servern zur Verfügung
gestellt.
(2) Das BMC-System auf dem Staging-Server
wird auf die neue Version gehoben. Die ur-
sprünglichen Funktionen und Schnittstellen
werden getestet und das Delta zur neuen
Codebase ermittelt (Base- und Overlay-Objekte).
(3) Auf Basis der ursprünglichen Lösung und
der neuen Funktionen wird die korrekte Funk-
tionsweise hergestellt und mit Schnittstellen
abgenommen. Alle Anpassungen werden doku-
mentiert und gesichert.
(4) & (5) Das Abnahmesystem wird mit einer
neuen Datenbasis der Produktion versorgt,
das Upgrade wird erneut durchgeführt und
die Anpassungen werden auf das neue System
gebracht.
(6) Per Delta Data Migration wird das Daten-
delta zwischen den beiden Datenbankständen
»behoben«. Hier ist die längere Laufzeit zu
beachten, während der keine Änderungen am
System wie Datenlöschungen oder Codeände-
rungen vorgenommen werden dürfen.
(7) Die »neue« Lösung wird mit ihren Schnittstel-
len produktiv geschaltet.
(8) Die Anwender arbeiten mit dem Upgrade und
dem Look & Feel der »neuen« Applikation (User
Experience).
Fazit. Das Staging-Verfahren ist weder einfach
noch kostengünstig: erfahrungsgemäß bewegen
sich die Aufwände in Bereichen, die der Einfüh-
rung eines neuen Produktes gleichkommt.
10 |
Staging Server QA / Validation Production
CCCurrrrentt Prroduuuctioonn
(11.1) Staaginnng Seerveeer
(1.2) Restore database
Release to client
for validation
Upgrade
Promote to production
CURRENT
((2) UUpggraaddeStaaginnng Seerveeer
((3) VValidattee UUppggraddee
(777) Prroomooote ttoo prrooduuctioonn
Prrepaare desstinna-tiion sseerver annd
rrun thhe Deelta DData MMigraatioon
(888)
Cliient leevveraggeess new immage
(4)
RReestoree pprevvaalidattedd
bbaackupp
Restore database
(55 aand 66)
Cliie
10 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Die User-Experience im Überblick
Upgrades haben Auswirkungen auf die User
Experience: auf die Anwender kommen größere
Umstellungen zu, die ein Änderungsmanagement
und sinnvollerweise auch das Anbieten von
Schulungen erfordern.
Die nebenstehende Tabelle beschreibt die
diskutierten Migrationspfade und die mögliche
Infrastrukturwahl eines BMC Remedy ITSM-
Systems mit Versions-Alternativen für die
Kundenumgebung unseres Beispiels aus dem
Öffentlichen Dienst. Dabei zeigt die Tabelle auch
die verschiedenen Client Versionen / Technologien,
die im Laufe der Zeit für das BMC Remedy-
Produkt vorgesehen waren und dann abgelöst
wurden.
Auch hier liegt das Augenmerk wieder auf der
eingesetzten Applikation:
• Kommt weitgehend eine Standard-ITSM
Suite zum Einsatz, entwickelt der Hersteller
die GUI für uns weiter. Customizing sollte
sich hier in Grenzen halten, da ansonsten
der Einsatz im Standard gefährdet ist und
ein Upgrade umfangreiche Anpassungen
erfordern kann.
• Wird von Anfang an auf Custom Build
gesetzt, wird eine eigene Applikation
vollständig verwaltet und entwickelt.
Änderungen in der Basis-Technologie im
Client-Bereich haben somit weitreichende
Auswirkungen. Beispielsweise lassen sich
clientseitig Prozesse wie Ping oder Remote
Control mit dem Tool Remedy User durch-
führen.
Im beschriebenen Kundenbeispiel wurde das
»Direkte Upgrade« auf einer Testumgebung
gewählt und abgebrochen und schließlich
das Altsystem belassen. Verantwortlich war
insbesondere der Aufwand für die Neugestal-
tung der GUI und der GUI-Funktionen. Viele
Tätigkeiten, die über die Anwender des Service
Desks erfolgen, zum Beispiel die Initiierung von
Remote-Steuerungen vom PC-Arbeitsplatz aus
auf der Basis von CMDB-Funktionen, sind über
den MidTier Web-Client nicht mehr reibungslos
umzusetzen und erfordern neue Produkte. Der
Umstieg auf Smart Clients wurde diskutiert,
doch verwendet der Kunde nur die Atrium
CMDB, nicht die zum Einsatz dieser Technologie
erforderlichen ITSM Suite-Applikationen Service
Request, Change- und Incident-Management.
Die Aufwände, um vom Custom Build auf die
ITSM Suite zu wechseln, wurden als zu hoch
bewertet.
Remedy Version 7.6 Version 8.1 Version 9.1 Version X …
ARS 7.6 8.1 9.1 10, 11, …
MidTier 7.6 Client Client 10, 11, …
OS Server 2003 Server 2008 Server 2008
DBMS MSSQL 2005 MSSQL 2008 MSSQL 2012
Client User 7.6 Smart IT Smart IT Smart IT
User Client & MidTier Betrieb
MidTier Betrieb & Smart IT Betrieb
Smart IT Betrieb?
User Client – nur Custom Build 7.x
MidTier EOL?
11 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Upgrade-Prozess IV: Produktions-Change
Die Planung der Produktionsschaltung der »neuen«
Lösung schließlich führt in vertraute Bereiche
zurück. Zwar steigen die Herausforderungen,
immer komplexere Systeme im Griff zu behalten,
aber die Änderungen bzw. Änderungsverfahren
selbst für eine komplexe Softwarelösung mit ihren
vielzähligen Schnittstellen werden in der Regel
immer gleich ablaufen.
Grundsätzlich stellt sich neben der Frage, wie das
Upgrade technisch zu lösen ist, auch die Frage,
ob es vollständig oder Zug um Zug durchgeführt
werden soll. Prozess für Prozess wäre beispiels-
weise interessant, jedoch könnten längere Projekt-
laufzeiten unter Umständen Parallelbetriebe
erfordern, die weitere Kosten mit sich bringen.
What are the recommendations
for planning down time?
What are the preparations
I do need to do before I begin?
What are the recommendations for UAT planning?
What are the different
upgrade phases?
Where should I maintain
my environment details?
Production planning
Which utilities will I need ?
Where can I find information
about issues I need to be aware of?
12 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
4. Das Ende der Reise?
Der Weg der Migration ist, wenn man die Vorteile
der Smart Clients nutzen will, mit der Einführung
neuer Oberflächen und Applikationen verbunden,
was wiederum eine Ausweitung der Infrastruktur
nach sich zieht.
Änderungen an der unterliegenden Architektur
oder Schnittstellenstruktur einer ITSM-Lösung
haben erhebliche Auswirkungen auf den Betrieb:
der Wechsel auf die BMC ITSM Suite 9.x mit ihren
neuen »smarten« User Clients beispielsweise
erfordert den Einsatz bestimmter Module, um
mit diesen Clients arbeiten zu können. Die alten
MidTier Browser-Clients jedoch werden von BMC
nicht weiterentwickelt, und für die immer noch
genutzten User Client Tools ist das End-of-Life mit
der Version ARS 7.6.04 erreicht.
Für BMC ITSM Upgrades kann es ein abschlie-
ßendes Fazit ebenso wenig geben wie pauschale
Aussagen zum richtigen Lösungsweg: beides ist
kontextabhängig und muss auf den Kunden und
seine Situation zugeschnitten werden.
Auch dürfen die Diskussionen über unsauberes
Arbeiten der Hersteller, Einführung neuer Appli-
kationen über den Client-Pfad oder zu viele An-
passungen, die der Kunde durch »falsche« Nutzung
der Applikation vornehmen musste, nicht von der
eigentlichen Frage ablenken, der sich jeder Projekt-
verantwortliche stellen muss:
Was ist die Motivation für das Upgrade und welche Handlungsoption soll passend dazu ausgewählt werden?
Die Antwort auf diese Frage ist der wahre »erste
Schritt« auf dem langen Weg zu einem erfolgrei-
chen Projektabschluss.
13 |Auch 1000 Meilen beginnen mit dem ersten Schritt!
November 2016
Unser Angebot
Gerne unterstützen wir Sie bei der IST-Aufnahme,
der Analyse und der Empfehlung von Handlungs-
alternativen vor dem Hintergrund Ihres individuel-
len Umfeldes.
Für jede unserer Leistungen bieten wir Ihnen das
gesamte Servicespektrum moderner IT-Projekte:
• Analyse, Zieldefinition, Konzeption,
Produktauswahl
• Customizing, Individualisierung,
Implemen tierung
• Prozessmigration, Inbetriebnahme,
Dokumentation
• Projektmanagement, Projektmarketing,
Reviews
• Produktschulung, Pflege, 24/7 Hotline, Support
Viele unserer Senior Berater und Beraterinnen
sind bereits mehr als zehn Jahre mit an Bord:
Geringe Mitarbeiterfluktuation, die Nutzung des
guten Ausbildungs- und Arbeitsmarktniveaus
am Wissenschaftsstandort Aachen sowie eigene
Ausbildungsinitiativen und interne Schulungen
garantieren Ihnen Projektierungsteams auf
höchstem fachlichen Niveau.
Ist Ihr Interesse geweckt? Sprechen Sie uns an!
Wir freuen uns auf ein persönliches Gespräch.
Die Autoren
Norbert Gies
Norbert Gies ist einer der Leiter des
Competence Centers für Integration der
ComConsult Kommunikationstechnik GmbH.
Er ist Seniorberater und seit über 14 Jahren
erfolgreich als Projektleiter tätig. Zu seinen
Kernkompetenzen gehören zielführende
Prozess-Konzeptionierung, Lösungsarchitektur
und verantwortungsvolle
Projektleitung in nationa-
len und internationalen
Projekten.
Martin Woyke
Dipl. Kfm. Martin Woyke ist einer der beiden
Geschäftsführer der ComConsult
Kommunikationstechnik GmbH.
Seit der Gründung des Unternehmens 1986
wird er als anerkannter Strategieberater auf
Geschäftsleitungsebene geschätzt.
© Copyright by:
ComConsult Kommunikationstechnik GmbH
Pascalstraße 25
52076 Aachen
Germany
Tel. +49 (0) 2408 149 01
ComConsult Kommunikationstechnik AG
Stapfenstraße 5
3098 Köniz
Switzerland
Tel. +41 (0) 3139 801 41
www.comconsult.de