Posts Tagged: ‘teccr’

Am Puls der Welt: Sensoren und das Internet der Dinge

3. Dezember 2014 Posted by Thomas Pohl

Heizungen, die sich nach dem Wetterbericht regulieren, Kühlschränke, die im Supermarkt Käse und Butter bestellen, Autos, die Werkstattbesuche alleine buchen – das Internet der Dinge breitet sich aus. Sensoren spielen dabei eine wichtige Rolle. Sie erfassen Messdaten wie Temperatur, Druck, Stoßbelastung und vieles mehr. Wie sich aus diesen Daten geschäftlicher Mehrwert erzeugen lässt, können Entwickler jetzt anhand eines detaillierten Showcase erleben. 

IT zieht in alle Bereiche unseres Alltags ein, Kühlschränke, Autos, Waschmaschinen, im Prinzip alle beliebigen Gegenstände können damit zu potentiellen Datenquellen werden. Interessant werden diese Daten, wenn es Unternehmen gelingt, aus ihnen Bedeutung abzuleiten. Das geschieht, indem sie sie mit anderen Unternehmensdaten kombinieren. Anlagen, Maschinen und Werkzeuge können dann selbstständig Prozesse ausführen, vor Fehlern warnen, Wartungen anfordern, Gebrauchsdaten für die Abrechnung registrieren und vieles mehr. 

 

Was ist das Internet der Dinge?

Bei der Vernetzung von Smartphones, Autos, Industrieanlagen, Flugzeugturbinen und Gegenständen aus dem Alltag spricht man heutzutage vom Internet der Dinge (engl. Internet of Things, abgekürzt auch IoT). Im Vergleich zum „klassischen“ Internet werden im IoT Inhalte nicht mehr nur von Menschen erstellt und mitgeteilt. Smarte Sensoren, Mikrocontroller und IT-Systeme kommunizieren selbständig, ziehen Schlüsse und lösen Aktionen aus. Dadurch werden mehr Daten als jemals zuvor erhoben, gesammelt, ausgetauscht und verarbeitet. Laut IDC sollen bis 2020 rund 212 Milliarden Objekte mit Sensoren ausgestattet sein – es wird also rund 28 Mal so viele Sensoren geben wie Menschen auf der Welt (siehe Grafik).   

image

Wie die Zusammenarbeit von Sensoren, Geräten und der Unternehmens-IT im Detail funktioniert, lässt sich jetzt an einem Showcase von IBM zum Thema Industrie 4.0 nachvollziehen. Der Showcase beleuchtet speziell die Integration mit Unternehmensdaten im Kontext Hybrid-Cloud genauer.

 

Showcase Industrie 4.0

Ausgangspunkt ist folgendes typisches Szenario: Ein Computerchip-Hersteller produziert Chips in einem Reinraum. Kleinste Staubpartikel könnten die Produkte unbrauchbar machen, daher muss die Luftqualität ständig überwacht werden. Sobald  die Verschmutzung einen gewissen Schwellenwert überschreitet, müssen Gegenmaßnahmen ergriffen werden. 

Um das zu erkennen, wurde in dieser Fabrik ein hochsensibles Sensornetzwerk installiert. Die Sensoren schicken alle 2 Sekunden über das Internet Daten bezüglich Korrosion, Luftfeuchtigkeit und Temperatur an einen Cloud-Service. In der Cloud werden die Daten mit Hilfe von Physical-Analytics-Methoden analysiert und der aktuelle Grad der Luftverschmutzung ermittelt. 

Die Sensordaten werden zusätzlich mit Unternehmensdaten kombiniert: Neben den Daten wird auch der jeweilige Standort der Sensoren aufgezeichnet. Man kann also einzelne Maschinen identifizieren und bei Bedarf auf ihre Log-Daten zugreifen. Weitere Informationen liefert das Enterprise Resource Planning (ERP)-System. Beispielsweise können neben den Wartungsintervallen auch die Art der letzten Wartungsarbeiten ermittelt werden.

Tritt nun ein Fehler in der Produktion auf oder wird ein Alarm durch Luftverschmutzung ausgelöst, können weitere Daten vor Ort gesammelt und an den Cloud-Service zur Überprüfung geschickt werden, wie etwa Webcam-Bilder vom Ort des Geschehens oder genauere Fehlerbeschreibungen durch die Mitarbeiter über Smartphones oder Tablets. Der Cloud-Service analysiert alle vorhandenen Daten und leitet Lösungsmaßnahmen ein, etwa indem er vorbeugende Wartungsarbeiten empfiehlt. Oder er bestellt das Service-Team, um die Arbeiten gleich durchführen zu lassen. 

Hat das System einen Servicefall aktiviert, werden automatisch weitere Unternehmensdaten der Fallakte hinzugefügt – wie Kontaktinformationen, Ersatzteil-Nummern und mögliche Zulieferer. So kann entsprechend des Defekts automatisch ein passender Techniker gesucht und benachrichtigt werden. Über ein Webinterface kann dieser alle relevanten Daten einsehen. Dank der Liste von Zulieferern kann er die defekten Teile einfach per Klick bestellen. Gleichzeitig wird die betroffene Fabrik über die anstehenden Arbeiten informieren.

Nach Abschluss die Wartungsarbeiten deaktiviert das System automatisch den Servicevertrag bis zur nächsten Wartung. Die Abrechnungsdaten für die Reparatur werden abschließend automatisch vom ERP-System verarbeitet.

 

Szenario in der Realität

Genau dieses Szenario haben wir im Client Center der IBM Deutschland Research & Development in einem Showcase umgesetzt: Das Sensornetzwerk einer Fabrik in Guadalajara in Mexiko sendet die Sensordaten live an einen Service in die IBM Softlayer Cloud, der von IBM Research in Yorktown, USA, gemanagt wird. Der Cloud-Service verarbeitet dort die Daten unter anderem mittels Physical Analytics-Modellen weiter. Mit geringem Aufwand konnten wir auch einen Prototyp der Mobile Support-App auf IBM Bluemix entwickeln und ausliefern. Als Integrationsplattform dient ein Softlayer Object Storage - dadurch können Daten aus allen unterschiedlichen Quellen transparent gespeichert und ausgetauscht werden. Das Enterprise-Backend bildeten wir über ein IBM System z Mainframe-System ab. Dieses liefert die Unternehmensdaten für den Showcase. Aggregiert werden die Daten in einem Webservice, der dank aller existierenden APIs einfach, schnell und skalierbar auf Softlayer ausgeliefert werden konnte (siehe auf Grafik).

image

Weitere Information zu der Implementierung und dem Showcase gibt es hier (https://ibm.biz/BdEbM2).

Der Showcase zeigt: Die Technologien für neue IoT-Ideen stehen bereit, die Verwirklichung läuft dank offener APIs sehr viel schneller und effizienter, als man vielleicht vermutet. Jetzt kommt es auf den Einfallsreichtum der Entwickler an, ihrer Vorstellungskraft sind keine Grenzen mehr gesteckt. Ich bin sehr gespannt, welche neuen Geschäftsmodelle sich in nächster Zeit etablieren werden.  

Wie erleben Sie das Internet der Dinge und seinen Einfluss auf unsere Geschäftswelt? Diskutieren Sie hier mit! Oder sprechen Sie mich auf Twitter unter @ThomasPohl_ an.

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (7/12)

27. November 2014 Posted by Bernd Kueppers

image

IBM Service Integration Capability Model: Werkzeugunterstützung

In diesem Beitrag aus der Serie zu Service Integration in Multi Sourcing/ Hybrid IT diskutieren wir diesmal die Frage:
Wie verbinde ich die Werkzeuge der einzelnen Service-Provider und des Service Integrators?

In den beiden vorangehenden Blog-Artikeln dieser Serie haben wir diskutiert, wie die Ablauforganisation zwischen dem Service Integrator und den Service Providern koordiniert werden kann und wie die Aufbauorganisation gestaltet sein sollte, damit die Zusammenarbeit gut funktioniert.

In diesem Beitrag widmen wir uns nun der Frage der Werkzeugunterstützung, d.h. mit welchen Service Management Tools wird gearbeitet und wie verbinde ich diese?

Üblicherweise implementiert der Service Integrator die X-Service Management Domäne (siehe vorangehenden Beitrag zu Ablauforganisation) in einem eigenen Toolset.

Ausgehend davon gibt es zwei unterschiedliche Möglichkeiten:
a.)    Der Service Integrator bietet den einzelnen Providern an, dieses Toolset ebenfalls zu nutzen.
b.)    Die einzelnen Service Provider nutzen ihre eigenen Tools und verbinden diese mit dem Service Integrator.

Variante a) hat den Vorteil, dass keine Schnittstellen zwischen verschiedenen Tools bedient werden müssen.
Meistens ist es aber so, dass die Service Provider viel Aufwand zur Automatisierung der Prozesse in eigene Toolsets investiert haben. Die Provider würden somit an Effizienz einbüssen, wenn sie das Service Management Tool des Service Integrators nutzen würden. Somit kommt in der Praxis meistens Variante b) zum Einsatz. Es gibt aber auch Fälle, in denen manche Provider mit Variante a) arbeiten und andere Provider mit Variante b).

Wenn es um die Frage geht, wie man konkret einzelne Tools miteinander verbinden kann, dann gibt es grundsätzlich drei Möglichkeiten:
A)    Man programmiert die Schnittstellen direkt in den beiden Tools, die verbunden werden sollen
B)    Man baut einen Enterprise Service Bus auf und schliesst alle Tools daran an
C)    Man nutzt Middleware, um Tools Point to Point zu verbinden. Die Schnittstellenlogik wird hierbei in der Middleware abgebildet.

In der Praxis wird A) heute selten verwendet, da bei dieser Lösungsvariante mit jeder einzelnen Schnittstelle die Toolkomplexität wächst.
Der Aufbau eines Enterprise Service Bus gemäß Variante B) ist häufig zu finden, allerdings mit relativ hohen Vorlaufzeiten verbunden und nicht für jede Tool-Umgebung geeignet.
Variante C) vermeidet die Nachteile von A) und B) und wird heute in der Praxis vielfach eingesetzt.


Für diese Art der Toolintegration eignet sich zum Beispiel die Software IBM Security Directory Integrator. Diese Software realisiert die Schnittstellen-Logik nach dem Fliessbandprinzip auf Basis zahlreicher vorgefertigter Logikbausteine aus einer Bibliothek.

Für die Leser, die es einmal ausprobieren möchten, besteht unter dem folgenden Link die Möglichkeit, eine kostenlose Testversion der Software herunterzuladen:

http://www-03.ibm.com/software/products/en/directoryintegrator
 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (6/12)

20. November 2014 Posted by Bernd Kueppers

IBM Service Integration Capability Model: Aufbauorganisation.     

In diesem Beitrag gehen wir auf die zweite Dimension des IBM Service Integration Capability Models ein: Die Aufbauorganisation.

Ausgehend von der Darstellung der Ablauforganisation/ der Prozessintegration, die wir im vergangenen Beitrag erläutert haben, wollen wir in diesem Beitrag diskutieren, wie denn die Aufbauorganisationen der einzelnen Provider strukturiert sein sollte.

Ausgangspunkt der Betrachtungen ist die Segmentierung der Prozesse in Anteile, die vom Service Integrator erledigt werden und in Anteile, die von den einzelnen Service Providern erledigt werden.

Die folgende Abbildung verdeutlicht die Aufteilung der Verantwortlichkeiten zwischen Service Integrator und Service Provider.

image

 
Abbildung: Prozessorientierte Aufbauorganisation

In der Praxis hat sich die Strukturierung des betrieblichen Anteils der Aufbauorganisation nach Prozessen bewährt.

Wenn wir bei unserem Beispiel Change Management bleiben, dann gibt es z.B. die Rollen „Change Coordinator“ und „Change Controller“ auf Seiten des Service Integrators und die dazu korrespondierenden Rollen des „Change Administrators“ und „Change Managers“ bei den einzelnen Service Providern.

Neben dem betrieblichen Anteil der Aufbauorganisation, der auch als operationaler Anteil bezeichnet wird gibt es noch die Anteile der Aufbauorganisation, die sich um die taktischen und strategischen Aufgaben kümmern.

Die Aufbauorganisation in diesem Bereich hängt wiederum stark von der gewählten Governance Struktur ab, auf die wir in einem der nächsten Beiträge eingehen werden.  
 

IT Management aus der Steckdose

16. November 2014 Posted by Ingo Averdunk

In meiner Rolle als IT Architekt beschäftige ich mich seit über 20 Jahren mit dem Thema Systems und Service Management. In dieser Zeit gab es diverse Initiativen in diesem Bereich, zum Beispiel Standardisierung der Management-Prozesse durch ITIL (IT Infrastructure Library), Aufstieg und Abstieg von Management Frameworks und unterschiedlichste Management Ansätze von Point-Solutions bis zu integrierten „Umbrellamanagement“-Lösungen. Seit einiger Zeit entwickelt sich ein spannender neuer Aspekt: IT Management as a Service.

In diesem Artikel gebe ich einen Einblick in diesen neuen Trend, beleuchte die Vor- und Nachteile dieses neuen Ansatzes und beschreibe die Position der IBM hierzu.

 

IT Management as a Service – was ist das?

Um Anforderungen wie Verfügbarkeit, Performanz und Sicherheit zu begegnen, haben Unternehmen über Jahre immer größere und mächtigere IT Managementlösungen implementiert. Dies hatte zur Folge, dass ein immer größer werdender Kostenblock für den Betrieb und die Wartung der Managementlösung aufgewendet werden musste. Damit stiegen aber nicht nur die Kosten; auch die Flexibilität und Agilität wurde zunehmend eingeschränkt.

Getrieben durch diese Nachteile suchen Unternehmen nach neuen Ansätzen. So wurde durch IT Outsourcing der Betrieb auf einen anderen Provider übertragen. Für den Fall, dass das Unternehmen aber weiter den Betrieb selbst übernehmen möchte, gibt es aber auch die Möglichkeit die Management-Funktionen als Service zu beziehen – IT Management aus der Cloud.

Als Beispiel sei die Helpdesk-Funktion mit seinen Prozessen Incident, Problem, Change und Config genannt. Anstelle die Helpdesk-Anwendung selbst zu betreiben, wird diese von einem Provoider in der Cloud gehostet. Die Nutzer der Lösung (also die Helpdesk-Mitarbeiter) nutzen die Funktionen über den Browser und merken unter Umständen noch nicht einmal, dass der Service von einem externen Provider geliefert wird.

 

Vorteile von ITSMaaS

Die Vorteile einer solchen Service-basierten Lösung liegen auf der Hand: Sowohl Hardware- als auch Lizenz-kosten können vermieden werden. Ein weiterer Vorteil ist, dass der Kunde nicht schon am Anfang eine große Verpflichtung in die Abnahme von Lizenzen eingehen muss, da die Kosten proportional zum individuellen Nutzungsumfang steigen. Genauso reduzieren sich im umgekehrten Fall die Kosten, sollte der Einsatz der Lösung sinken. Dieser Wandel von fixem Kapital-Expense (CapEx) zu fliessendem Operational-Expense (OpEx) ist ein wesentlicher Treiber von SaaS-Lösungen.

Daneben ist aber auch die Reduzierung der Aufwände für Wartung und Pflege der Lösung ein wichtiger Aspekt. Der Kunde kann sich auf den Einsatz der Lösung konzentrieren, während die Pflege der Lösung dem Service Provider obliegt, der sich um Verfügbarkeit, Performanz, Kapazität, etc. gemäß SLA Verpflichtungen zu kümmern hat. Aufwände und Risiken bei Versionsupgrades werden ebenfalls an den Provider übertragen; auch hier beschreiben klare SLAs die Güte des geleisteten Sevice.

 

Herausforderungen

Die genannten Vorteile bergen jedoch auch Herausforderungen. Als erstes werden häufig Bedenken bezüglich des Datenschutzes und der Datensicherheit genannt: Dürfen die Daten die Unternehmensgrenze verlassen? Wer kann auf die Daten zugreifen? Wo liegen die Daten physikalisch? Neben Unternehmensrichtlienien müssen oft auch rechtliche Rahmenbedingungen berücksichtigt werden

Als nächster Punkt sei der Verlust der Individualität und Flexibilität genannt. Dadurch dass der Service Provider nun die Hoheit über die Wartung und den Betrieb der Lösung hat, übt der Nutzer nur noch bedingten Einfluß auf die Lösung aus. Nicht zuletzt war der Fokus auf die Nutzung der Lösung ja genau die Motivation für das Management as a Service. Auf der anderen Seite kann der Provider nur dann die Lösung kostengünstig anbieten, wenn er Synergieeffekte über viele Kunden hinweg hat.

Damit einhergehend ist sicher auch die Sorge um eine zu starke Bindung an den Service Provider, da zumal ein Wechsel zu einem anderen Provider oft mit hohen Kosten einhergeht.

Die Notwendigkeit der Integration mit Umsystemen ist ein wichtiger Punkt. Modelle wie ITIL beschreiben den integrativen Aspekt von IT Management und wie IT-Prozesse sich auf Daten und Funktionen von andere Prozessen abstützen. So müssen auch Funktionen aus der Cloud integriert werden, sei es mit Lösungen im Unternehmen („on-premise“) oder “ausgelagerten“ Ansätzen, wie beispielsweise in der Cloud („SaaS“). So muss ein on-premise Event Management sich auch mit einem Helpdesk as a Service integrieren.

 

Der IBM Point of View

Auf der Konferenz PULSE hat IBM die Platform „IBM Service Engage“ vorgestellt. Über Service Engage will IBM zunehmend das Portfolio von IT Service Management neben der erfolgreichen On-Premise Lösung als Software as a Service anbieten.

Genau gesagt verfolgt IBM hier einen „SaaS-First“ Ansatz, bei dem die Produkte zuerst als SaaS angeboten werden, um dann im zweiten Schritt hieraus ein on-premise Produkt zu generieren. Dieser Ansatz bietet klare Vorteile, gerade für den Kunden, der weiter IT-Management Lösungen klassisch on-premise einsetzen möchte: Der Kunde kann sich via SaaS im Vorfeld mit neuen Versionen und Funktionen vertraut machen und Einfluss auf die zukünftige on-premise Version nehmen. IBM betreibt die Produkte produktiv auf Service Engage, Probleme die sich erst im operativen Betrieb herausstellen, können so identifiziert und gelöst werden, bevor das on-Premise Produkt verfügbar wird.

Dieser Ansatz bietet einen weiteren Vorteil: Der Kunde kann sich über SaaS mit dem Produkt vertraut machen, und dann sich für eine Installation im eigenen Rechenzentrum entscheiden. Aufwendige Rüstzeiten zum Aufbau eines PoT / PoC können so reduziert werden, daneben muß keine Hardware für die Infrastruktur zur Verfügung gestellt werden.

IBM Service Engage bietet heute bereits zahlreiche IT Managementfunktionen als SaaS an, unter anderem

  • Asset Inventory Analytics
  • Endpoint Management
  • Enterprise Asset Management
  • Enterprise Mobility Management
  • IT Service Management
  • Performance Management
  • Workload Automation

image

 

IBM plant, sein ITSM Portfolio umfangreich auf Service Engage zur Verfügung zu stellen. Einzelne Funktionen werden untereinander gekoppelt, z.B. Monitoring mit Event Management und Service Desk. Daneben wird aber auch die Möglichkeit von hybriden Managementansätze geboten. Kunden können on-premise Managementfunktionen mit SaaS Funktionen koppeln und so ein integriertes ITSM aufbauen. Auf diese Weise kann sukzessiv auf ein IT Management as a Service gewechselt werden.

Service Engage wird über die IBM Cloud-Infrastruktur „Softlayer“ gehostet. Neben den herkömmlichen Aspekten wie Verfügbarkeit und Performance sei erwähnt, dass es eine Roadmap zum Aufbau von Softlayer-Rechenzentren in unterschiedlichen Ländern existiert. Damit kann der Kunde rechtliche Rahmenbedingungen bezüglich Datenlokation umsetzen.

 

Ausblick

Sicher ist ITSM as a Service noch nicht main stream. Zunehmend fragen Kunden jedoch nach einer SaaS Strategie und berücksichtigen diese in der Bewertung eines Herstellers. Andere Kunden nutzen die Vorteile von SaaS, um neue Versionen und Produkte zu testen.

Es bleibt die Frage, ob dieser Ansatz nur eine Welle ist oder ob er langfristig den ITSM Markt verändern wird. Ich bin überzeugt davon, dass sich der ITSM Markt in Richtung SaaS entwickeln wird. Ähnlich wie dies bereits Email und CRM gezeigt haben. Aspekte wie Integration und Hybrid-Management sind meiner Ansicht nach zentrale Aspekte, um ITSM erfolgreich aus der Cloud anzubieten.

Haben Sie Kommentare zu ITSM as a Service? Nutzen sie die Kommentarfunktion auf dieser Webseite oder kontaktieren sie mich direkt unter averdunk@de.ibm.com und folgen sie mir auf Twitter.

image

 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (5/12)

12. November 2014 Posted by Bernd Kueppers

IBM Service Integration Capability Model: Ablauforganisation.

 

Im vorangehenden Beitrag hatten wir das IBM Service Integration Capability Model als Vorgehensmodell für eine erfolgreiche Service-Integration vorgestellt. In diesem und in den nächsten Beiträgen gehen wir nun auf die einzelnen Dimensionen des Modells ein.

Dieser Beitrag beschäftigt sich mit der Ablauforganisation der Service Integration und somit mit der Frage:
Wie koordiniere ich die einzelnen Ablauforganisationen aller Beteiligten so, dass jeder weiß, was er wann zu tun hat?

Eine wichtige Voraussetzung für Service Integration ist die Prozessintegration. Das folgende Beispiel zeigt einen vereinfachten Change-Management Prozess zur Erläuterung der Prozessintegration in einer Multi-Sourcing Umgebung.

Auf der linken Seite des Bildes sehen wir die einzelnen beteiligten Organisationen, in diesem Fall 3 verschiedene Service Provider, den Service Integrator, das Service Desk und die Kunden-IT Organisation.
Die Service Integrator Funktion und der Service Desk können entweder selbst betrieben oder als Service eingekauft werden.
Alle Beteiligten können Anträge auf Changes (RfC) stellen.
Der Service Integrator managed den Change Prozess Ende zu Ende, vom Request for Change bis zum final „review and close“ des Changes.

Hierzu
-    organisiert der Service Integrator ein Change Advisory Board, in dem die beteiligten Service Provider und der Service Integrator Changes und ihre Auswirkungen auf die Gesamtumgebung besprechen.
-    holt er die Freigabe des Kunden ein, sofern eine Ergänzung der Leistung erforderlich wird
-    Koordiniert er Tests
-    Koordiniert Termine, an dem Changes bei den einzelnen Providern implemetiert werden
-    Reviewed die Ergebnisse und dokumentiert und schliesst den Change

image
 
Bildunterschrift: Change Management Prozess

Ein Teil einer gelungenen Service Integration ist also die Prozessintegration. Aber nicht alle Prozesse müssen vom Service Integrator so eng koordiniert werden wie Change Management. Die folgende Darstellung erläutert den unterschiedlichen Integrationsbedarf der einzelnen Prozesse.

Auf der linken Seite der Abbildung sind drei Provider dargestellt. Der eine kümmert sich um Anwedungen, der andere um Rechenzentren und der Dritte um die IT am Arbeitsplatz. Auf der x-Achse ist eine kleine Auswahl der Prozesse der Ablauforganisation dargestellt.

Wie wir grade gesehen haben, muss der Change Management Prozess aufgeteilt werden: In ein übergreifendes Prozess-Segment, das der Service Integrator verantwortet und Teilprozesse, die von den einzelnen Providern verantwortet werden. Diese sind hier als Change Execution bezeichnet.

Im Gegensatz zum Change Management gibt es auch Prozesse wie z.B. Performance Management oder Bereiche des Operations Management, die komplett in Verantwortung der einzelnen Provider liegen. So interessiert es z.B. den Netzbetreiber nicht, wie der Rz-Betreiber sein Performance Management macht und umgekehrt.

Außerdem ist unserer Erfahrung nach bei manchen Prozessen der Integrationsbedarf von Kunde zu Kunde unterschiedlich. Asset Management kann z.B. wie Change Management aufgeteilt sein, oder aber alleine in Verantwortung des Kunden verbleiben, wenn er z.B. alle Assets weiter in seiner Bilanz führen will. Der letztere Fall ist hier im Bild dargestellt.

image
 
Bildunterschrift: Prozessintegration


Soweit der Überblick zur ersten Dimension des IBM Service Integration Capability Models: Der Ablauforganisation.

Im nächsten Beitrag gehen wir dann auf die Aufbauorganisation ein.

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (4/12)

6. November 2014 Posted by Bernd Kueppers

Aufgaben des Service-Integrators / IBM Service Integration Capability Model :

 

Was tut ein Service Integrator, um Services aus verschiedenen Quellen zu einem Ende-zu-Ende Service zu integrieren?


Im vorangehenden Beitrag hatten wir Service Management als Ausgangspunkt der Service Integration beschrieben. Die Aufgabe des Service Integrators ist es nun, -bildlich gesprochen- aus den verschiedenen Service Management Dreiecken der einzelnen Service Provider ein neues, virtuelles Dreieck zu erzeugen, um ein ganzheitliches Service Management zu erreichen.

 

Typische Fragestellungen dabei sind:

 Ablauforganisation: Wie koordiniere ich die einzelnen Ablauforganisationen so, dass jeder Service-Provider weiß, was er wann zu tun hat?
 Werkzeugunterstützung: Wie verbinde ich die Werkzeuge der einzelnen Service-Provider und des Service Integrators?
 Aufbauorganisation: Wer sind die verantwortlichen Ansprechpartner in den jeweiligen Aufbauorganisationen?

Die Praxiserfahrung hat gezeigt, dass neben den drei Dimensionen des Service Managements drei weitere Dimensionen für das Gelingen der Service Integration relevant sind:
 Information: Definition von Daten und Datenstrukturen, die die Provider und der Service Integrator gemeinsam verwenden, um die Leistung zu erbringen und zu überwachen.
 Governance: Festlegung der Regeln der Zusammenarbeit zwischen Service Providern und Service Integrator
 Business: Festlegung der Regeln des Demand/Supply Managements zwischen Service Integrator und Service Providern

 

Die sechs Dimensionen gemeinsam werden als IBM Service Integration Capability Model bezeichnet:

 

image

 



  Abbildung: IBM Service Integration Capability Model

 
In den kommenden Beiträgen werden wir die einzelnen Dimensionen des Modells näher erläutern.

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (3/12)

29. Oktober 2014 Posted by Bernd Kueppers

Einer für Alle(s) – die Rolle des Service-Integrators

 
Nachdem wir über das Kunden-Feedback zu einer geeigneten Definition von Service-Integration gelangt sind, wird erkennbar, wer der heimliche Held der IT-Service-Integration ist: der Service-Integrator.

Wie im vorherigen Beitrag gezeigt, ist Service-Integration in ITIL V3 nicht definiert. Allerdings  hat der Markt selbständig ein einheitliches Verständnis entwickelt, was Service Integration bedeutet. Das IBM Technical Expert Council hat auf Basis von mehreren Kundendefinitionen Service-Integration definiert als:
 

 “IT Service Integration establishes End-to-End services based on independent IT services from various sources”

 

Gehen wir von dieser Definition aus – was folgt als nächstes? Dazu ist es wichtig zu verstehen, wie ein Service-Provider seinen Service produziert: mittels Service Management. Der Ausgangspunkt der Service-Integration ist also das Service Management.

Jeder einzelne Service wird von einer Aufbauorganisation mit Hilfe einer Ablauforganisation und Werkzeugen produziert. Das kann ein interner Service-Provider sein, d.h. eine IT-Abteilung im Unternehmen, oder ein externer Service-Provider, die beide mit eigenen ITIL-basierten Prozessen und einem Service-Management-Werkzeug einen Service produzieren. Prozesse und Werkzeuge sind dabei in der Praxis sehr unterschiedlich.

 

imageAbbildung: Drei Dimensionen hat das Service-Management – und daraus entspringt eine Vierte: die Service-Integration.

 

Wenn ein Unternehmen seine Services aus verschiedenen internen und externen Quellen bezieht, kommt zu den drei Dimensionen des Service Managements eine vierte Dimension dazu: eben die der Service-Integration. Service-Integration sorgt dafür, dass der Endnutzer nicht mehr davon „gestört“ wird, dass die Services aus verschiedenen Quellen stammen, auch wenn alle Services von verschiedenen Organisationen mit individuellen Prozessen und Werkzeugen produziert werden.

 

image

Abbildung: Die Service-Integration sorgt idealerweise für nahtloses und für den Nutzer unsichtbares Ineinandergreifen der verschiedentlich gesourcten Services.

 

Die Funktion, die Service-Integration leistet, nennt sich „Service-Integrator“. Dieser heimliche Held der gelungenen Service-Integration kann auf verschiedene Weise verkörpert werden:

1.) Service-Integration durch Kunden: Der CIO beschließt, eine Abteilung in seiner Organisation mit den Aufgaben des Service-Integrators zu beauftragen.

2.) Service-Integration durch Prime-Provider: Der CIO vergibt die Service-Integrator-Funktion im Rahmen einer Gesamtvergabe an einen Generalunternehmer.

3.) Unabhängiger Service-Integrator: Der CIO beauftragt einen erfahrenen externen Partner mit der Service-Integrationsleistung. Dieser Partner liefert ansonsten keinen der zu integrierenden Services.

4.) Service-Integration durch Main-Provider: Der CIO beauftragt denjenigen Provider mit der Service-Integration, der auch den Hauptteil der zu integrierenden Services leistet.

 

image

Abbildung:  Möglichkeiten zur Realisierung der Service-Integrator-Funktion

Alle vier Arten sind am Markt zu finden.

Organisationen, die bereits seit längerem Erfahrungen mit dem Bezug von Services aus verschiedenen Quellen haben und daher das notwendige Know-How zur Service-Integration bereits erworben haben, tendieren dazu, die Funktion des Service Integrators in der eigenen Organisation zu realisieren (Nr. 1). Organisationen, die dieses Know-How noch nicht erwerben konnten, können externe Unterstützung bei der Service-Integration erhalten (Nr.2-4).

Soweit unsere Erfahrungen zur Praxis der Funktion des Service-Integrators – für uns der heimliche Held der Service-Integration. Oder gibt es hier andere Meinungen?

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (2/12)

22. Oktober 2014 Posted by Bernd Kueppers

 

 

 

image
Service-Integration ist definiert als…ups
Was ITIL V3 vergessen hat

 

 

 

©iStockphoto.com
 

Ja, so ist es: Wenn man die 1400 Seiten der fünf Bücher von ITIL Version 3 durchsucht, findet man keine Definition von „Service Integration“. Ohne geht es aber nicht. Wie eine Lösung aussehen könnte, das zeigen interessante Definitionsversuche der Anwender.

Durchstöbert man IT Infrastructure Library (ITIL) nach einer Definition des Begriffs „Service-Integration“, wird man nur an einer einzigen Stelle fündig: In den Service Design Principles. In Kapitel 3.11.3.2 Off-the-shelf solutions der Service Design Principles steht geschrieben: “A framework for selecting, customizing and implementing these off-the-shelf packaged solutions is needed and includes the need to: Define service integration requirements”...

Der Begriff wird also verwendet, ohne dass er dort definiert wird. Das wäre an sich kein Problem, wenn er denn anderswo einheitlich definiert wäre. Aber das ist leider nicht so. Es gibt derzeit keine allgemein akzeptierte Definition von „Service-Integration“.

Und so kommt es, dass die meisten Unternehmen eine eigene Definition von „Service-Integration“ entwickelt haben. Diese Definitionen finden sich dann zum Beispiel in Angebotsaufforderungen, die uns erreichen. In den letzten zwei oder drei Jahren haben wir auf diese Weise viele dieser Bestimmungen kennengelernt. Aus ihnen lässt sich recht gut ableiten, welche Aspekte von Service-Integration für den Anwender wesentlich sind:

- der Ende-zu-Ende-Charakter von Services (d.h. Es gibt nur einen Ansprechpartner für einen Service und nicht mehrere) und
- der Ursprung der Services aus verschiedenen internen oder externen Quellen.

Diese beiden Aspekte kommen in allen uns vorliegenden Kunden-Definitionen von „Service-Integration“ vor. Damit sind diese beiden Merkmale der „Service-Integration“ für uns das Maß aller Dinge und wir schlagen daher folgende Definition vor:

 “IT Service Integration establishes End-to-End services based on independent IT services from various sources.”

Wenn wir nun noch einmal das Beispiel aus dem ersten Beitrag dieser Serie ansehen, dann erkennen wir die verschiedenen Quellen der Services, interne wie externe. Und wir erkennen, dass es nur einen Ansprechpartner für den Nutzer geben darf: Einen Service-Integrator, der sich darum kümmert, dass ihm geholfen wird. Und über seine Rolle mehr im nächsten Beitrag.

 

image


 

 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT

1. Oktober 2014 Posted by Bernd Kueppers

image

 

Mit den immer breiter am Markt verfügbaren Cloud- und IT-Service-Angeboten schreitet der Trend zur Kommodisierung von Services zügig voran. Doch auf welche IT-Service-Bereiche soll ich mich als IT-Verantwortlicher konzentrieren? Für welche Services nutze ich Partner? Welche kann ich einfach mit Cloud-Services abdecken?

In diesem Blog suchen wir Antworten auf diese und viele anderen Fragen rund um das Thema Service-Integration in Multi-Sourcing/Hybrid-IT.

 

©iStockphoto.com/lim_Isk

 

Das Angebot für Cloud- und IT-Services wird immer breiter, Services sind auf dem besten Weg, zu Commodities zu werden. Damit wachsen aber auch die Anforderungen an die IT-Abteilungen, denn sie müssen dafür sorgen, dass die vielen verschiedenen Services reibungslos ineinandergreifen. Schließlich soll das Endprodukt beim Nutzer „ganzheitlich“, also wie aus einem Guss, ankommen.

Damit das gelingt, reicht es nicht aus, dass jeder Service für sich einwandfrei funktioniert. Auch und vor allem das Miteinander muss stimmen, sprich die Integration der einzelnen, oft aus unterschiedlichen Quellen stammenden Services in einer hybriden IT-Landschaft.

Erreichen lässt sich das durch das richtige Vorgehen bei der Auswahl der Services und der Service-Integration. Und genau das werden wir hier im Blog diskutieren. Wir werden zeigen, wie sich geeignete Sourcing-Bereiche systematisch und nachvollziehbar identifizieren und zu einem ganzheitlichen Service integrieren lassen.

In regelmäßigen Beiträgen werden wir uns hier mit der Technologie der Service-Integration befassen, d.h. mit der Frage, wie ich es schaffe, dass Services aus verschiedenen Quellen so wirken, als kämen sie aus einer Hand. Geplant sind hier Beiträge zu Themen wie Definitionen, Ablauforganisation, Werkzeuge, Aufbauorganisation, Informationen, Governance, Cloud-Services und Hybrid-IT und nicht zuletzt zu kaufmännischen Aspekten.

Außerdem wollen wir erläutern, wie IT-Verantwortliche geeignete Sourcing-Kandidaten identifizieren können und welche Services in einer konkreten Unternehmenssituation sinnvoll gesourced werden können. Dabei werden wir Fragen nachgehen, wie: Woher kommt der aktuelle Trend zu Multi Sourcing/ Hybrid IT? Oder: Wie finde ich systematisch heraus, welche Services ich sourcen könnte?

Auf Diskussionsbeiträge, Tipps und Themen-Anregungen freuen wir uns natürlich sehr!

 

image

Das Ganze ist mehr als die Summe der Teile:

Services werden heute mehr und mehr zur Commodities – nur sollten sie richtig integriert sein, damit sie beim Nutzer auch so ankommen.