auch 1000 meilen beginnen mit dem ersten schritt!€¦ · build-lösung mit einer bmc atrium cmdb...

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.


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


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,


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.


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

https://docs.bmc.com/docs/display/public/brid81/Planning+for+upgrade

https://docs.bmc.com/docs/display/public/brid81/Planning+for+upgrade


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


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


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?


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?


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.


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

[email protected]

www.comconsult.de

auch 1000 meilen beginnen mit dem ersten schritt!€¦ · build-lösung mit einer bmc atrium cmdb...

Documents