Management von Anwendungssystemen

siehe Bild

Unter Help Desk, User Help Desk, Service Desk oder Benutzerservicezentrum wird eine Stelle verstanden, die IT-bezogene Problem- oder Störungsmeldungen oder sonstige Anfragen von organisationsinternen Nutzern entgegennimmt, deren Bearbeitung koordiniert und im Idealfall sofort selbst eine Problemlösung bzw. ein Ergebnis zurückliefert. Ist dies nicht möglich, involviert der Help Desk andere Stellen mit der benötigten Expertise (z.B. Softwarespezialisten) und/oder den benötigten Möglichkeiten (z. B. Servicetechniker, die ein Gerät vor Ort reparieren können). In jedem Fall behält er als Single Point of Contact (SPOC) die Kontrolle über den Prozess bis zur Lösung des Problems und informiert den Anfrager ggf. über den Status seines Anliegens. Für die eventuell nötige fachliche Eskalation der Anfragenbearbeitung bis zur befriedigenden Lösung des Problems haben sich in der Praxis Support Levels als hilfreich erwiesen.

Der Thin-Client-Betrieb stellt die dritte Variante der Versorgung von Netzwerk-Clients mit Software dar. Hierbei handelt es sich allerdings nicht um Softwareverteilung im engeren Sinn, da auf den Clients keine Anwendungssoftware installiert wird. Vielmehr greifen diese auf Anwendungen zu, die zentral auf entsprechenden Servern angeboten werden. Hinsichtlich der Aufgabenverteilung in einer Client/Server-Architektur übernehmen die Clients lediglich die Präsentation, die Verarbeitung und Datenhaltung findet auf Servern statt. Clients können dementsprechend schlank, z.B. ohne eigene Festplatte, ausgestattet werden. Bekannteste Systeme, die einen solchen Betrieb zulassen, sind Windows Terminal Server und Citrix MetaFrame. Dieses zentralistische Vorgehen garantiert homogene Software und begrenzt den Installations- und Updateaufwand auf die Server.

Beim Push-Prinzip wird das Installationspaket zum Client übertragen&dort i.d.R.ohne Eingriff des Endbenutzers ausgeführt. Administrationsrechte auf den Clients besitzt nur der Installationsprozess&der Systemadmin.

Zusätzlich werden häufig Laufwerke sowie USB-&andere Schnittstellen deaktiviert sowie bestimmte Internetadressen blockiert. Eigenmächtige Installationen durch den Endbenutzer sind damit weitgehend ausgeschlossen. Durch den zentral gesteuerten Softwarepush kann man einen hohen Homogenitätsgrad der Software auf den Clients erreichen. Installationspakete lassen sich zielgruppenspezifisch definieren&als Standardkonfiguration automatisch auf die Rechner der Gruppenmitglieder übertragen. Ein Paket für die Einkaufsabteilung könnte z.B.eine Basisausstattung mit Office-Programmen, E-Mail-Client, Internetbrowser, Acrobat Reader sowie Clients von Fachanwendungen wie SAP oder E-Procurement-Systemen umfassen.PP:Schnell gr. Anzahl Rechner auf gew. Softwarestand bringen

Pull-Prinzip:

Das Pull-Prinzip sieht die Bereitstellung zu installierender Programme in Verzeichnissen am Server vor. Der Administrator oder der Endbenutzer selbst startet die Installation vom Client aus. Dieses Verfahren ist einfach und in der Regel ohne spezielle Verteilungswerkzeuge zu realisieren. In diesem Fall sind jedoch Administrationsrechte am Client nötig, die auch andere als die zentral bereitgestellten Installationen ermöglichen. Deshalb sollten Richtlinien regeln, welche Installationsaktivitäten zulässig sind. Da die Initiative zum Update den Benutzern überlassen bleibt, wird eine Harmonisierung der Softwarestände (z. B. gleiche Versionen von Service Packs) erschwert.

- Pull-Prinzip

- Push-Prinzip

- Thin-Client-Betrieb

Softwareverteilung (Deployment) umfasst die automatisierte Installation und Deinstallation von Software (Erstinstallation, Updates, Sicherheits-Patches etc.) auf Arbeitsplatz-PCs. Diese Aufgabe bedarf insbesondere in größeren Netzwerken wohl definierter Vorgehensweisen. Der Service Support nach ITIL sieht dafür die Teilprozesse für Release Management, Change Management und Configuration Management vor.

Bedarfsplanung und Beschaffung bilden die letzte Säule des Lizenzmanagements. Die dazu gehörenden Aktivitäten müssen sich orientieren

• am aktuellen Hardware-, Software- und Lizenzinventar

• an der aktuellen und geplanten Unternehmensentwicklung und der damit verbundenen Entwicklung des Personalstands

• am Softwareangebot (neue Anwendungen, veränderte Nutzungs- und Lizenzierungsformen wie z. B. "Software on de mand")

Beschaffungen sollen nur den echten Bedarf decken, der aus den genannten Fakten ermittelt werden kann. Damit die Transparenz gewährleistet ist und bessere Konditionen durch Bedarfsbündelungen erzielt werden können, müssen sie mit den Lizenzmanagementverantwortlichen abgestimmt werden. Die regelmäßig durchzuführende Bedarfsplanung wird fallweise von Ad-hoc Planungen ergänzt, z.B. bei Firmenübernahmen.

Hard- und Softwareinventar sowie Lizenzinventar und deren regelmäßiger Abgleich zeigen Handlungsbedarfe auf. Beispielsweise kann die Feststellung, dass Mitarbeiter selbsttätig und unautorisiert Service Packs installiert haben, im Bereich der organisatorischen Rahmenbedingungen eine Überarbeitung der Richtlinien nach sich ziehen. Das Erkennen einer Unterlizenzierung kann zur Deinstallation von Programmen führen, während eine Überlizenzierung eine Korrektur der Bedarfsplanung auslöst.

Im Mittelpunkt des Lizenzinventars stehen

• die Ermittlung vorhandener Lizenzen (mit Informationen wie Version, Gültigkeitsdauer etc.),

• die Zuordnung von Lizenzen zu Organisationseinheiten und/oder Nutzern

• die Verwaltung von Lizenznachweisen (spezielle Dokumente der Hersteller oder Kaufnachweise)

Um das Lizenzinventar aktuell zu halten, ist eine Inventur in regelmäßigen Abständen erforderlich.

Eine weitere Säule ist die Inventarisierung der Hard- und Software.

Im Zusammenhang mit dem Lizenzmanagement geht es dabei vor allem um

• die Ermittlung der Rechneranzahl (vernetzte und Stand-alone Rechner)

• die Ermittlung der auf den Rechnern installierten Software

• die Zuordnung der Installationen zu Organisationseinheiten und/oder Nutzern

• das Erstellen von Nutzungsstatistiken

Um das Hard- und Softwareinventar aktuell zu halten ist eine Inventur in regelmäßigen Abständen erforderlich.

Die organisatorischen Rahmenbedingungen beziehen sich auf den Lizenzmanagementprozess & auf damit verbundene Richtlinien & personalbezogene Aktivitäten. Sie umfassen

• die Definition & Dokumentation des Lizenzmanagementprozesses & seiner Teilprozesse

• die Festlegung von Prozessverantwortlichen (Process Owner)

• die routinemäßige Überprüfung der Prozesse (Monitoring)

• die Definition & Kommunikation von Richtlinien bezgl. der Beschaffung, Installation & Nutzung von Software (z.B. Verbot der Beschaffung ohne Involvierung der Verantwortlichen für das Lizenzmanagement oder Verbot der Installation von aus dem Internet heruntergeladener Software)

• die Verpflichtung des Personals auf Einhaltung der Richtlinien mit Sanktionsmöglichkeiten bei Nichtbefolgung (z.B. in Betriebsvereinbarungen)

• die themenbezogene Sensibilisierung, Motivation & Schulung des Personals

Sämtliche organisatorischen Rahmenbeding. sind regelmäßig zu überprüfen & ggf. anzupassen.

- Organisatorische Rahmenbedingungen

- Hard- und Softwareinventar

- Lizenzinventar

- Bedarfsplanung und Beschaffung

Gegenstand des Lizenzmanagements ist die Sicherstellung der ökonomisch optimalen und rechtlich einwandfreien Lizenzierung der in der Organisation genutzten Fremdsoftware. Im Kern geht es dabei darum, bedarfsgerecht vorzugehen, d. h., weder zu wenige noch zu viele Nutzungsrechte für Programme vorzuhalten. Zielführendes Lizenzmanagement stützt sich auf die 4 Säulen.

Lizenzmanagement involviert als dauerhafter Prozess eine Vielzahl von Organisationseinheiten des Unternehmens. Wesentliche Stakeholder reichen von der IT über den Einkauf, das Rechnungswesen, die Revision und die Geschäftsleitung bis hin zum Betriebsrat, der einzuschalten ist, wenn Systeme eingesetzt werden sollen, welche die Softwarenutzung protokollieren. Umso bedeutsamer sind die bereits angesprochene klare Regelung der Zuständigkeiten und die sorgfältige Gestaltung des Gesamtprozesses. In der Praxis bietet es sich in der Regel an, die Federführung für das Lizenzmanagement der IT zu übertragen.

Inventory Management bezeichnet die Erhebung und Speicherung von Daten über Hard- und Softwarekomponenten der Clientsysteme in einer Netzwerkumgebung (Rechner, Peripheriegeräte etc.). Synonym wird häufig der Begriff Asset Management verwendet.

Typische Parameter, die zur Hardware erfasst werden, sind Seriennummer, Prozessor und dessen Leistung, Festplattentyp und -kapazität, Firmware-Version & Speicherausstattung.

Werkzeugunterstützung

Werkzeuge, die der weitgehend automatischen Abwicklung dieser Aufgaben dienen, werden als Inventory-Management-Systeme bezeichnet.

Zusätzliche Funktionalitäten umfassen je nach Hersteller z.B. die Unterstützung der Vertragsverwaltung (Kauf-, Leasing-, Wartungs-, Support-, Lizenzverträge & Service Level Agreements) oder des Rechnungswesens (z. B. Verwaltung

abschreibungsrelevanter Gerätedaten). Schnittstellen können auch die Integration in ERP- & E-Procurement-Lösungen ermöglichen um z.B. Daten für Beschaffungen zu übergeben.

Das Client Management umfasst alle Aufgaben für Betrieb, Steuerung& Überwachung der Clientsysteme in einer Client-/Server-Architektur (v.a.Rechner, netzwerkfähige Peripheriegeräte). Zur Einschätzung der wirtschaftlichen Bedeutung dieser Aufgaben können folg.Aussagen dienen:

• Ein PC-Arbeitsplatz verursacht über einen Lebenszyklus von 3-4 Jahren Gesamtkosten für Hardware, Software&laufende Wartung&Support in Höhe von ca.13.000€

• Mögliche Einsparungen durch umfassendes, systematisches Client Management können im 1.Jahr 30%, in den 5 Folgejahren jeweils zw. 5-10% betragen

• Auch durch Outsourcing lassen sich Praxiserfahrungen zufolge über den kompletten Lebenszyklus eines Arbeitsplatzes bis zu 30% der Kosten einsparen

• Diese Potenziale werden jedoch unzureichend erschlossen, da nur 10-15% aller Unternehmen optimiertes Asset Management betreiben

• Werkzeugunterstütztes Client Management entfaltet seinen vollen Nutzen ab einer Rechnerzahl von ca.70

• Das Mgmt. der Hard- & Softwarekomponenten, die in ihren Kombination die Applikations-&IT-Architektur bilden, entwickelt sich zu einer Kerndisziplin im IT-Mgmt.Annahme:Strategische Infrastrukturentscheidungen bezgl. Hardware & Softwareapplikationen (Rechnerplattform, ERP-System) wurden bereits getroffen. Somit steht die operative Sicht mit dem Mgmt. von Netzwerk, Rechnern, Peripherie & Software sowie dem Support der Anwender im Vordergrund. Die Erledigung dieser Aufgaben koppelt wichtige Infos zurück für Bewertungen & Änderungen der Strategie (z.B. Ablösung einer Rechnerplattform wg. Performanceproblemen, aufgedeckt durch gehäufte Benutzerbeschw. beim Support).

• 70% der Unternehmen mit 500 Arbeitsplatzrechnern (Clients) wickeln das Mgmt. ihrer Hard- & Software über def. Prozesse ab. Meist wird sich dabei an den ITIL-Prozessen zum Incident/Problem/Configuration/Change/Release Mgmt. orientiert. Zusammen mit der Funktion des Service Desks formen diese Prozesse den Service Support.

• Die Abb.setzt den ITIL-konformen Service Support mit den Teilgebieten des Mgmts. von Hard- & Software in Bezg. Letzteres lässt sich gliedern in Netzwerkmgmt. & Client Mgmt., beides begleitet vom Help Desk & den Möglichkeiten der Fernsteuerung (Remote Control) von IT-Systemen z.B. in Support-/Wartungsfällen. Das Netzwerkmgmt. erstreckt sich traditionell auf Server, aktive/passive Komponenten & die drahtgebundenen/drahtlosen Verbindungen in Rechnemetzen. Die Bezeichnung Client Mgmt. verwenden vorwiegend Hard- & Softwarehersteller & Beratungshäuser für Aufgaben & Funktionalitäten im Zusammenhang mit der Verwaltung & Pflege von Arbeitsplatzrechnern & Peripherie.Bsp. für solche Aufgaben sind lnventarisierung, Lizenzmgmt. & Softwareverteilung. Synonyme für Client Mgmt. sind Desktop Mgmt., Desktop Managed Services, Asset/PC Lifecycle Mgmt.

Erfolgreiches und vor allem wirtschaftliches Architekturmanage ment bedarf nicht nur eines praktikablen Vorgehensmodells, sondern auch geeigneter IT-Unterstützung. Vor allem die kosten- und zeitintensive Erstellung, Pflege und Analyse von Architektur modellen sowie deren Kommunikation im Unternehmen lassen sich in Anbetracht häufiger Änderungen nur sinnvoll mit leistungsfähigen Werkzeugen bewerkstelligen. Softwarehersteller haben diesen Bedarf erkannt und entsprechende Lösungen entwickelt.

Die folgende Auflistung zeigt eine Auswahl dieser als Enter prise Architecture Management Tools (EAM-Tools) bezeichneten Systeme. Der Hersteller ist jeweils in Klammem angegeben:

• Adaptive EAM (Adaptive Inc.)

• ADOit (BOC GmbH)

• ARIS IT Architect (IDS Scheer AG)

• Troux (Troux Technologies Inc.)

• planningIT (alfabet AG)

• Telelogic System Architect (Telelogic AB)

Die Architekturkommunikation stellt zusammen mit den Aktivitäten der Architekturvertretung die Serviceorientierung sicher.

Das Architekturmanagement berät bei der Durchführung von (Entwicklungs-) Projekten oder wirkt direkt mit und stellt ggf. Architekturartefakte bereit. Damit können Entwicklungsteams unterstützt und gleichzeitig die Architekturkonformität erhöht werden. Letztere wird regelmäßig bei der Beurteilung von Projekten

erhoben.

Die Kommunikations- und Vertretungsphase liefern Feedback für die Messung der Architekturverbreitung und -effektivität an die Architekturführung zurück. Mit den daraus entstehenden Rückkopplungen für die Identifikation der Anforderungen schließt sich der Kreis.

Aufgabe der Architekturkommunikation ist es, die Architekturvorgaben und -artefakte den vorher identifizierten Zielgruppen (Entwickler, Anwender etc.) zu kommunizieren.

Ein Instrument der Architekturkommunikation ist üblicher Weise ein Verzeichnis der gültigen Standards (Book of Standards). Es gibt für Architekturelemente in den einzelnen Bereichen des Architekturbaukastens unter anderem Aufschluss über den Standardisierungsstatus, die Erlaubnis der Verwendung und die Unterstützung bei der Verwendung durch die IT-Abteilung.

Ergebnis der Architekturführung sind neue bzw. überarbeitete Architekturprinzipien, die im Rahmen der Architektur(weiter)entwicklung zusammen mit den dort identifizierten operativen Anforderungen in die Gestaltung so

genannter Architekturartefakte einfließen. Solche Artefakte sind Architekturelemente wie Frameworks (z. B. Java EE, Microsoft. NET), Standards (z. B. zur Gestaltung barrierefreier Websites) oder Technology Sets (z. B. Hard- und Softwarekombination eines Außendienst-Notebooks). Sie werden pilotiert, entwickelt und ggf. in die bestehende Landschaft der Architekturartefakte integriert.

In der Phase der Architekturführung verwendet man die aus der IT-Strategie abgeleiteten Anforderungen, beurteilt damit bestehende Architekturen und identifiziert so Handlungsbedarfe. Ergebnis sind neue bzw. überarbeitete Architekturprinzipien.

- Architekturführung

- Architektur(weiter)entwicklung

- Architekturkommunikation

- Architekturvertretung

Abgeleitete Teilziele des generellen Ziels:

• Optimale Ausrichtung von Geschäft & IT (Alignment)

- Adäquate Abdeckung der geschäftl. Anforderungen durch IT

- Höhere Geschäftsprozessqualität

• Flexibilität der IT-Landschaft

- Schnellere Umsetzung (neuer) fachlicher Anforderungen

- Bessere Integrationsfähigkeit (einfachere Anbindung neuer/externer Systeme)

• Homogenität der IT-Landschaft

Konsolidierung durch Standardisierung von

- Hard- & Software

- Prozessen & IT-Funktionalitäten

soweit nicht berechtigte individuelle Anforderungen dagegen stehen

• Beherrschbarkeit der IT-Landschaft

- Komplexitätsreduktion

- Bessere Plan- & Wartbarkeit

- Höhere Sicherheit

• Akzeptanz & Transparenz der IT-Landschaft

- Interessenausgleich unter allen Beteiligten

- Kommunikation an alle Beteiligte

- Verständlichkeit für alle Beteiligte

• Wirtschaftlichkeit der IT-Landschaft

- Nutzen-/Kostenoptimierung

- Nachhaltigkeit

Mit Bezug zum identifizierten Handlungsbedarf werden die Ziele für das Architekturmanagement definiert. Generelles Ziel ist es, mit vorausschauendem, an den fachlichen Bedarfen orientiertem Architekturmanagement die Applikations- und IT-Architektur effektiver und effizienter mit der Geschäfts- und Prozessarchitektur zu koordinieren.

x

Bei der IT-Architektur schließlich illustriert die Abbildung beispielsweise, dass das ERP System unter anderem auf den Technikbündeln "Client-Server Architektur" und "Workflow-Management-System" und das B2B Portal unter anderem auf dem Technikbündel "Webservices" basiert. Ebenso ist erkennbar, dass etwa für die Realisierung des Technikbündels "Client-Server-Architektur" Hardwareelemente wie Prozessoren, Speicher- und Netzkomponenten mit Softwareelementen wie Betriebssystemen, Datenbanken etc. zusammen wirken.

Auf der Stufe der Informationssysteme lassen sich Applikations und IT-Architektur unterscheiden. Die IT-Architektur schließlich definiert die Infrastruktur, die sich aus so genannten Technikbündeln zusammensetzt. Diese wiederum bestehen aus Basistechnik (Hard- und Software), die IT-Basisfunktionalitäten (Speicherung, Verarbeitung, Kommunikation) bereitstellt.

Auf der Applikationsebene sind ausgewählte, durch einen Integrationsbus verbundene Anwendungen sichtbar. Das ERP System unterstützt die Teilprozesse der Bedarfsprognose, der Lieferabrufe und des Wareneingangs (Wareneingangsprüfung, Verbuchung etc.). Das B2B-Portal als Informations-, Kommunikations- und Transaktionsplattform mit Lieferanten und Kunden dient der öffentlichen Ausschreibung der vom ERP-System ermittelten Bedarfe sowie der Beschaffung im engeren Sinn in Form einer umgekehrten Auktion (Reverse Auction). Das Lagersteuerungssystem steuert die Einlagerung der eingegangenen Ware mittels eines fahrerlosen Transportsystems.

Auf der Stufe der Informationssysteme lassen sich Applikations und IT-Architektur unterscheiden. Die Applikations- oder Anwendungsarchitektur spezifiziert die Funktionen zur Unterstützung der Geschäftsprozesse. Sie wird ergänzt von der Datenarchitektur zur Beschreibung der statischen Datenstrukturen und der Kommunikationsarchitektur, die den logischen Zusammenhang zwischen den Anwendungen und den Daten herstellt.

Die Teilstrategie für die Beschaffungsfunktion (Supply Chaina Management) aus der Geschäftsarchitektur mündet auf der Ebene der Prozessarchitektur in Prozesse, von denen im Beispiel lediglich ein vereinfachter Beschaffungsprozess von der Bedarfsprognose bis hin zum Eingang der gekauften Waren dargestellt ist.

Die aus der Geschäftsarchitektur abgeleitete Prozessarchitektur umfasst die Aufbau- und Ablauforganisation, die der Entwicklung, der Erstellung und dem Vertrieb des Leistungsangebots dienen. Hierzu zählen unter anderem Stellen- und Ablaufbeschreibungen, Organigramme, Zuständigkeiten etc.

Auf der Ebene der Geschäftsarchitektur wird mit dem Supply Chain Management exemplarisch eine Teilstrategie für die Beschaffungsfunktion gezeigt.

Die Ebene der Geschäftsarchitektur bildet die Geschäftsstrategie mit dem Gesamtzusammenhang der Leistungsverflechtung in einem Wertschöpfungsnetzwerk ab. Aus Unternehmens- bzw. Organisationssicht geht es hier um Abstimmung der Ziele mit den für die Kunden anzubietenden Leistungen (market-based view) und den Kernkompetenzen des Unternehmens (resource-based view). Damit wird die Positionierung am Markt vorgenommen und der Rahmen für den Austausch von Waren, Dienstleistungen und Informationen mit Geschäftspartnern wie Lieferanten und Kunden gesetzt.

Die Geschäfts-, Prozess-, Applikations- und IT-Architektur sind wesentliche Bestandteile der Untemehmensarchitektur (Enterprise Architecture), zu der im umfassenden Sinn noch weitere Ressourcen wie Menschen und

Produktionsanlagen zählen.

Insbesondere in Großunternehmen steht die bewusste Planung und kontinuierliche Entwicklung der IT-Landschaft stark im Fokus. Objekt dieser Managementaufgabe ist die Architektur im Sinne eines Bauplans mit unterschiedlichen Ansichten, die die Komponenten von Systemen und deren Beziehungen beschreiben und auf Konstruktionsprinzipien basieren.

Eine solche Architektur ist also Ergebnis eines Planungsprozesses und stellt selbst einen Masterplan für die Realisierung künftiger Maßnahmen dar.

Architekturmanagement umfasst demnach die Erstellung, Dokumentation, Pflege Kommunikation und Umsetzung von Architekturmodellen in der betrieblichen Praxis.