-
Diese
Erfindung bezieht sich allgemein auf die Wartung einer Softwaresystem-Landschaft
und insbesondere auf ein Verfahren zum Ausführen eines Softwaredienstes
in einem System aus einer Softwaresystem-Landschaft und ein Computersystem.
-
Eine
komplexe Software wie etwa SAP R/3 Release 4.5 (SAP) des Anmelders
erfordert eine kundenspezifische Anpassung, d. h. eine Auswahl im
Voraus definierter Funktionalität,
und eine Adaption, d. h. eine Hinzufügung oder eine Änderung
betreffend Funktionalität,
sowie eine weitere Wartung wie etwa Programm- und Datenaktualisierungen,
vergl. "SAP System
Landscape Optimization" von
A. Schneider-Neureither (Hrsg.), SAP Press, 2004, ISBN 1-59229-026-04,
und "SAP R/3 Änderungs-
und Transportmanagement" von
Metzger und Rohrs, Galileo Press GmbH, Bonn, Deutschland, 4. Auflage 2004,
ISBN 3-934358-42-X.
-
Aus "Tivoli Software Distribution
User's Guide 4.1
(GC 32-0715-00)",
IBM Publication Center, Internet Disclosure, [Online], 2001, XP002321301
ist eine Verteilungsumgebung zum Erzeugen von Softwarepaketen und
Verteilen von Software durch einen Anwender bekannt. Es ist ein
Aktivitätsplaner
vorgesehen, der dazu verwendet wird, Bedingungen für Aktivitäten festzulegen.
-
"A tool for managing
change (product review)",
Bawtree H.: Software Development, [Online], August 2000, Seiten
1-4, XP002321302, ist ein Konfigurationsmanagementwerkzeug, das Änderungsanforderungen
von einem Anwender an einen Entwickler und weiter zur Freigabe unter
Verwendung von Tasks verfolgen kann. Es werden zwei Abfrageschnittstellen
verwendet, eine für
die Änderungsanforderungsfelder
und eine für
die Task-Felder. Ein Berichtsgenerator erzeugt ASCII-Dateien.
-
Bevor
eine solche Wartung ausgeführt
werden kann, muss jedoch sichergestellt sein, dass die kundenspezifischen
Anpassungen, Adaptionen, Programm- und Datenaktualisierungen usw. frei
von Fehlern sind und sich einwandfrei in die Software- und Datenumgebung
einpassen. In einem Werk beispielsweise führen Wartungsfehler zwingend
infolge eines Nichtfunktionierens der Software oder einer Datenverfälschung
zu teuren Unterbrechungen des Arbeitsablaufs. Abgesehen von der
Wartungsseite kann eine andere Verwendung der Software wie etwa das
Training neuer oder unerfahrener Anwender ebenfalls zu einer Unterbrechung
des Produktionssystems führen.
-
Eine
solche komplexe Software kann daher in Form von getrennten logischen
Systemen, die zusammen eine Systemlandschaft bilden, implementiert
werden. Eine typische Implementierung der oben erwähnten SAP-Software
kann beispielsweise, vergl. 1, ein Entwicklungssystem 101 für die Kundenanpassungs- und Entwicklungsarbeit,
ein Qualitätssicherungssystem 102 für das Testen
der Funktionalität
anhand repräsentativer
Testdaten, ein Trainingssystem 103 für das Einarbeiten neuer Anwender
und verschiedene Produktiv- bzw. Produktionssysteme 104,
z. B. jedes für
ein anderes Werk, für die
eigentliche produktive Verwendung umfassen. Den besonderen Anforderungen
entsprechend können
andere oder weitere Anwender und Systeme definiert werden.
-
Die
logischen Systeme sind in weiten Teilen identisch, arbeiten autonom
und können
auf einem einzigen Computer laufen. Das Qualitätssicherungssystem 102 beispielsweise
gleicht insofern dem Produktionssystem 104, als es die
gesamte Funktionalität,
seine vorhandenen Daten und zusätzliche
spezielle Testdaten bereitstellt. Neue Kundenanpassungseinstellungen
oder Adaptionen können
somit in dem Qualitätssicherungssystem 102 sorgfältig getestet werden,
ohne das Produktionssystem 104 zu gefährden. Ähnlich gleicht das Trainingssystem 103 dem Produktionssystem 104 insofern,
als es einen Teil der Funktionalität und spezielle Testdaten bereitstellt.
Ein neuer Anwender, der das Trainingssystem 103 verwendet,
kann somit an die Funktionalität
gewöhnt werden
und die Auswirkung seiner Handlungen beobachten, und zwar ohne das
Produktionssystem 104 zu stören.
-
Ein
Transportmanagementsystem verbindet die logischen Systeme und dient
zum Befördern
von Softwarediensten zwischen Systemen der Systemlandschaft über logische
Transportpfade 105. Ein Dienst kann beispielsweise in dem
Entwicklungssystem 101 für den Export erprobt werden.
Es wird dann zu einem Eingangspuffer des Qualitätssicherungssystems 102 geschickt.
Der Import in das Qualitätssicherungssystem 102 wird
von einem Bediener manuell genehmigt oder abgelehnt. Anschließend wird
der Softwaredienst zu dem Qualitätssicherungssystem 102 und
dann zu dem Trainingssystem 103 und den Produktionssystemen 104 geschickt,
wo es im Anschluss an die manuelle Genehmigung durch einen Bediener
importiert wird.
-
Der
Bediener ist verantwortlich für
das manuelle Ausführen
der Wartung. Dies erfordert eine Analyse des Systemlandschaftslayouts,
der Route, die jeder Dienst durch die Systemlandschaft nimmt, der Projektzustandsschalter
in jedem System, die die jeweiligen Veränderbarkeitsoptionen des Systems
definieren, der Attribute in jedem Dienst, die Eigenschaften des
Dienstes definieren, usw. Auf der Grundlage dieser Analyse werden
der Import von Diensten und andere Tasks ausgeführt.
-
Dieser
Prozess ist zeitaufwändig
und birgt die Gefahr von Fehlern, insbesondere in jenen Fällen, die
kein Teil der Routinewartung sind. Im Fall einer Fehlfunktion eines
Produktionssystems muss beispielsweise schnell ein "Hotfix" oder "Programmpatch", der hier als vorläufiger Softwaredienst
bezeichnet wird, implementiert werden. In einem solchen Fall kann
ein nur rudimentäres
Testen des vorläufigen
Softwaredienstes in dem Entwicklungssystem als ausreichend betrachtet
werden, so dass der vorläufige
Softwaredienst nicht in alle Systeme importiert werden muss, sondern
von dem Entwicklungssystem geradewegs zu dem schlecht arbeitenden
Produktionssystem gelenkt werden kann. Der Bediener muss dann die
Systemlandschaft analysieren, entscheiden, bei welchen Systemen
eine Anmeldung erfolgen muss, welche Einstellungen an welchen Systemen
zu verändern
sind usw.
-
Neben
der manuellen Berücksichtigung
des Softwaredienst-Typs sowie des Systemlandschaftslayouts und der
Systemlandschaftskonfiguration muss der Bediener auch darauf achten,
Dienste in der korrekten Reihenfolge, vergl. 2a und 2b, zu importieren. Eine Originalversion 201 der
Software und der Daten wird zuerst durch einen ersten Softwaredienst 202 modifiziert,
was zu einer modifizierten Version 203 führt, und
anschließend
durch einen zweiten Softwaredienst 204, was zu einer modifizierten
Version 205 führt,
vergl. 2a. Wenn jedoch der zweite
Softwaredienst 204 vor dem ersten Softwaredienst 202 importiert
wird, wird die Originalversion 201 durch den zweiten Softwaredienst 204 in
die modifizierte Version 206 verändert und anschließend durch
den ersten Softwaredienst 202 in die modifizierte Version 207,
vergl. 2b. Die modifizierten Versionen 205 und 207 unterscheiden
sich, wobei die Version 207 nicht wie vorgesehen arbeitet.
-
Angesichts
der Tatsache, dass eine SAP-R/3-Implementierung Dutzende von Systemen umfasst
und während Änderungsphasen
Tausende von Diensten pro Monat erfordern kann, wird die erforderliche
Bedienerzeit wie auch das Risiko eines Auftretens von Fehlern beträchtlich.
-
Es
ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren
zu schaffen, das diese Nachteile beseitigt.
-
Eine
weitere Aufgabe der Erfindung ist es, ein Verfahren zu schaffen,
das das Ausführen
eines Softwaredienstes in einer automatisierten und zentralisierten
Weise ermöglicht.
-
Es
ist gleichfalls eine Aufgabe der vorliegenden Erfindung, ein Computersystem
mit einer Softwaresystem-Landschaft zu schaffen, das die Nachteile
des Standes der Technik beseitigt.
-
Eine
weitere Aufgabe der Erfindung ist es, ein Computersystem zu schaffen,
das das Ausführen eines
Softwaredienstes in einer automatisierten und zentralisierten Weise
ermöglicht.
-
In
einem Aspekt der Erfindung wird ein Verfahren zum Ausführen eines
Softwaredienstes in wenigstens einem von mehreren logischen Systemen einer
Softwaresystem-Landschaft geschaffen, wobei die logischen Systeme
durch logische Transportpfade miteinander verbunden sind, wobei
jedem logischen System mehrere Systemaufgaben zugeordnet sind und
der Softwaredienst mit dem Code und/oder den Daten des wenigstens
einen Systems in Beziehung steht, wobei das Verfahren die folgenden Schritte
umfasst: Vorsehen eines Transportweges, der eine Route für Softwaredienste
durch logische Systeme in einer bestimmten Reihenfolge definiert und
ein Quellsystem, benachbarte, damit verbundene Systeme und wenigstens
ein Zielsystem spezifiziert, Erzeugen einer Task-Liste in einem
zentralen Task-System aus dem Transportweg und den Systemaufgaben,
wobei die Task-Liste Tasks zum Lenken eines Softwaredienstes von
einem Startsystem zu dem wenigstens einen System und zum Implementieren
des vorläufigen
Softwaredienstes in dem wenigstens einen System definiert, und Planen
der Ausführung
der Tasks, die in einem zentralen Task-System gespeichert sind,
in dem zentralen Steuersystem und Überwachen von Task-Zuständen von
dem zentralen Steuersystem aus.
-
In
einem weiteren Aspekt wird ein Computersystem geschaffen, das umfasst:
eine Softwaresystem-Landschaft mit mehreren logischen Systemen, die
durch logische Transportpfade miteinander verbunden sind und denen
jeweils eine von mehreren Systemaufgaben zugeordnet ist, einen Transportweg,
der eine Route für
Softwaredienste durch logische Systeme in einer bestimmten Reihenfolge
definiert und ein Quellsystem, benachbarte, damit verbundene Systeme
und wenigstens ein Zielsystem spezifiziert, wobei ein Softwaredienst
mit dem Code und/oder den Daten wenigstens eines Systems in Beziehung
steht, ein zentrales Task-System, Mittel zum Erzeugen einer Task-Liste
in dem zentralen Task-Sys tem aus dem Transportweg und den Systemaufgaben,
wobei die Task-Liste Tasks zum Lenken des Softwaredienstes von einem
Startsystem zu dem wenigstens einen System und zum Implementieren des
vorläufigen
Softwaredienstes in dem wenigstens einen System definiert, ein zentrales
Steuersystem und Mittel zum Planen der Ausführung von in dem zentralen
Task-System gespeicherten Tasks in dem zentralen Steuersystem und
zum Überwachen
von Taskzuständen
von dem zentralen Steuersystem aus.
-
In
einem nochmals weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt
geschaffen, das in einem Speichermedium einen Computercode enthält, der
bei Ausführung
auf einem Computersystem das Verfahren gemäß der Erfindung ausführt.
-
Die
Erfindung schafft somit eine automatisierte Erzeugung einer Task-Liste mit allen Tasks,
die zum Ausführen
eines Softwaredienstes erforderlich sind, sowie ein Steuersystem
für das
automatisierte Planen der Tasks und für das Überwachen ihrer Zustände. Dies
schafft wirksam ein automatisiertes Management aller Tasks zum Ausführen eines
Softwaredienstes, ob dies nun ein regulärer oder ein vorläufiger Softwaredienst
ist, was die Komplexität
des Prozesses wesentlich reduziert.
-
Weitere
Ausführungsformen
der Erfindung können
aus der folgenden Beschreibung und den Ansprüchen abgeleitet werden.
-
1 zeigt
eine Systemlandschaft des Standes der Technik.
-
Die 2a und 2b zeigen
Softwaredienste, die gemäß dem Stand
der Technik in unterschiedlicher Reihenfolge ausgeführt werden.
-
3 zeigt
eine Systemlandschaft gemäß der Erfindung.
-
4 zeigt
eine bevorzugte Ausführungsform
der Hardware eines Computersystems gemäß der Erfindung.
-
5 zeigt
Tasks, die den Systemaufgaben-Typen zugeordnet sind.
-
6 zeigt
eine Task-Liste.
-
Die
in 3 gezeigte Ausführungsform stellt eine SAP-R/3-Release-4.5-Systemlandschaft 300 mit
getrennten logischen Systemen 301 dar, die hier in einen
globalen Teil 302, z. B. auf einer Hauptentwicklungs- und
Produktionsanlage, und lokale Teile 303a, 303b, 303c,
z. B. auf anderen Produktionsanlagen, unterteilt ist.
-
Der
globale Teil 302 umfasst vorzugsweise wenigstens ein Entwicklungssystem 301a für Kundenanpassungs-
und Entwicklungsarbeit, ein Qualitätssiche rungssystem 301b für das Testen
der Funktionalität
anhand repräsentativer
Testdaten und ein Produktionssystem 301c für die eigentliche
produktive Verwendung.
-
Der
lokale Teil 303a umfasst ein Entwicklungssystem 301d für Kundenanpassungs-
und Entwicklungsarbeit von lokalen Adaptionen an SAP, um z. B. verschiedene
gesetzliche Anforderungen zu erfüllen,
falls sich der Teil 303a in einem anderen Land als der
globale Teil 302 befindet. Der lokale Teil 303a umfasst
ferner ein Qualitätssicherungssystem 301e für das Testen
der Funktionalität
anhand repräsentativer
Testdaten, ein Trainingssystem 301f für das Einarbeiten neuer Anwender
und ein Produktionssystem 301g für die eigentliche produktive
Verwendung.
-
Der
lokale Teil 303b umfasst ein Entwicklungssystem 301h,
ein Qualitätssicherungssystem 301j und
ein Produktionssystem 301k, jedoch kein Trainingssystem.
Der lokale Teil 303c ist eine Zweisystem-Landschaft, die
nur ein Entwicklungssystem 301l und ein Produktionssystem 301m umfasst.
-
Die
Systemlandschaft kann den aktuellen Anforderungen entsprechend unterschiedlich
sein. Nach Bedarf können
weniger oder mehr unterschiedliche oder unterschiedlich verbundene
oder gruppierte Systeme 301 definiert sein.
-
Die
logischen Systeme 301 sind in weiten Teilen identisch und
arbeiten autonom. Das Qualitätssicherungssystem 301j beispielsweise
gleicht insofern dem Produktionssystem 301k, als es die
gesamte Funktionalität,
seine vorhandenen Daten und zusätzlich
spezielle Testdaten bereitstellt. Neue Kundenanpassungseinstellungen
oder Adaptionen können
somit in dem Qualitätssicherungssystem 301j sorgfältig getestet
werden, ohne das Produktionssystem 301k zu stören.
-
Jedes
System 301 weist einen Importpuffer 304 für das Puffern
ankommender Softwaredienste und Mittel 305 für die Kommunikation
mit einem zentralen Task-System 307 auf, das mit einem
zentralen Steuersystem 308 verbunden ist. Ein Transportmanagementsystem
verbindet die logischen Systeme 301 und dient dazu, Softwaredienste über logische, richtungsbezogene
Transportpfade 306 durch die Systemlandschaft zu lenken.
Ein Dienst kann sich beispielsweise auf die kundenspezifische Anpassung eines
Systems 301, d. h. eine Auswahl im Voraus definierter Funktionalität in dem
System 301, oder eine Adaption eines Systems 301,
d. h. eine Hinzufügung oder
einen Nachtrag zur Funktionalität,
oder auf Programm- und Datenaktualisierungen oder Hotfixes oder
Patches und dergleichen beziehen. Es sind Transportwege vorgesehen,
die jeweils eine oder mehrere besondere Routen für Softwaredienste längs der
Transportpfade durch die System landschaft definieren. Ein Transportweg
kann beispielsweise die Route von dem System 301a über die
Systeme 301b, 301h, 301j zu dem System 301k definieren.
Ein anderer Transportweg kann die Route von dem System 301d über die
Systeme 301e, 301f zu dem System 301g definieren.
Es können
auch Transportwege mit Verzweigungen, z. B. von dem System 301a zu
dem System 301b und dann in einer ersten Verzweigung zu
dem System 301c und in einer zweiten Verzweigung zu den
Systemen 301l, 301m, vorgesehen sein. Es kann
mehr als einen Transportweg pro Systemlandschaft geben, wobei jeder
Transportweg einem Projektkontext wie etwa einem Entwicklungsprojekt
für lediglich
den lokalen Teil 303a oder einem Dokumentationsprojekt
für lediglich
den globalen Teil 302 zugewiesen sein kann.
-
Die
Systeme 301 jedes Teils 302, 303a, 303b, 303c und
das zentrale Task-System 307 können in einem einzigen Computer
angeordnet sein und in diesem gleichzeitig ausgeführt werden,
jedoch sind sie vorzugsweise über
separate Hardware verteilt. Vorzugsweise laufen der globale Teil 302 und
die lokalen Teile 303a, 303b, 303c jeweils
auf physikalisch getrennten Computersystemen, die ihrerseits verschiedene
Computer umfassen können.
-
Eine
bevorzugte Implementierung des lokalen Teils 303a kann,
vergl. 4, eine Datenbankschicht 401 für das Speichern
und Abrufen von Geschäftsdaten
wie etwa eines Werksinventars, Mitarbeiterdaten, Verkaufszahlen
usw. umfassen. Die Datenbankschicht 401 umfasst einen oder
mehrere Datenbankserver 402 und vier Datenbanken 403,
jeweils eine für
jedes der Systeme 301d, 301e, 301f und 301g.
-
Mit
der Datenbankschicht 401 ist über ein geeignetes Netz 404,
z. B. ein LAN, eine Anwendungsschicht 405 für die Ausführung der
Software der Systeme 301d, 301e, 301f und 301g verbunden.
Die Anwendungsschicht 405 umfasst einen oder mehrere Anwendungsserver 406.
-
Außerdem ist
mit der Anwendungsschicht 405 über ein geeignetes Netz 407,
Z. B. ein LAN, eine Präsentationsschicht 408 für die graphische
Benutzeroberfläche
(GUI) verbunden. Die Präsentationsschicht 408 umfasst
vorzugsweise nicht programmierbare Datenstationen 409,
Personal-Computer 410 und/oder Vorrichtungen 411 für drahtlosen
Zugriff wie etwa PDAs.
-
Jedem
System 301 ist eine Systemaufgabe zugeordnet, die die Funktion
des jeweiligen Systems innerhalb der Landschaft definiert. Die Systeme 301a, 301b und 301c beispielsweise
haben die Aufgaben "Entwicklungssystem
in dem globalen Teil", "Qualitätssicherungssystem
in dem globalen Teil" bzw. "Produktionssystem
in dem globalen Teil".
Die Systeme 301l und 301m haben die Aufgaben "Entwicklungssystem
in dem lokalen Teil 303c" bzw. "Produktionssystem in dem lokalen Teil 303c". Die anderen Systeme 301 haben
entsprechende Aufgaben. Bei SAP sind die Systemaufgaben im Allgemeinen
in dem Lösungsmanager
für Implementierung
(Solution Manager for Implementation) definiert.
-
Gemäß der Erfindung
sind Systemaufgaben-Typen vorgesehen. Systemaufgaben-Typen können das
Folgende umfassen:
- D Quellsysteme: Eine Transportanforderung,
die einen Softwaredienst umfasst, wird in einem System dieses Typs
erzeugt und manchmal getestet, gewöhnlich ein Entwicklungssystem.
- O Folgesystem: Eine Transportanforderung, die einen regulären Softwaredienst
umfasst, wird in ein System dieses Typs importiert und dann zu wenigstens
einem nächsten
System des Transportweges geschickt. Eine Transportanforderung,
die einen vorläufigen
Softwaredienst umfasst, wird nicht in ein System dieses Typs importiert,
sondern stattdessen weitergeleitet.
- P Zielsystem: Eine Transportanforderung, die einen Softwaredienst
umfasst, wird in ein System dieses Typs importiert, jedoch nicht
weitergeleitet. Zielsysteme sind typischerweise Produktionssysteme.
-
Bei
der Ausführungsform
nach 3 sind die Entwicklungssysteme 301a, 301h, 301d und 301l vom
Systemaufgaben-Tpy D, während
die Produktionssysteme 301c, 301k, 301g und 301m vom
Systemaufgaben-Typ P sind und die Systeme 301b, 301j, 301e und 301f zwischen
den Entwicklungssystemen und den Produktionssystemen vom Systemaufgaben-Typ
O sind. Es können
andere und/oder weitere Systemtypen vorgesehen sein.
-
Ferner
sind wenigstens zwei Softwaredienst-Typen vorgesehen. Der erste
Typ ist ein regulärer
Softwaredienst, der im Altgemeinen in im Voraus definierten Intervallen
ausgeführt
wird. Transportanforderungen, die einen Softwaredienst dieses Typs umfassen,
werden in den Importpuffern gesammelt und zur Zeit, zu der ein regulärer Softwaredienst
ausgeführt
wird, importiert, getestet und weitergeleitet. Der zweite Typ ist
ein vorläufiger
Softwaredienst, auch Hotfix oder Patch genannt. Dieser Softwaredienst
muss unmittelbar in einem bestimmten System, im Allgemeinen einem
Produktionssystem mit Fehlfunktion, und nicht unbedingt in allen
Systemen bearbeitet werden.
-
Tasks
sind Systemaufgaben-Typen und Softwaredienst-Typen zugeordnet. Die
Tasks können
als obligatorisch markiert sein und die folgenden beispielhaften
Tasks umfassen:
- für
den Typ D: – melde
dich an fernem System an
– erzeuge
Transportanforderung mit Softwaredienst
– setze Transportanforderung
für Weiterleiten
zu einem oder mehreren Systemen ab
- für
den Typ O: – melde
dich an fernem System an
– lediglich
für regulären Softwaredienst:
importiere Softwaredienst
– leite
Transportanforderung weiter
- für
den Typ P: – melde
dich an fernem System an
– importiere
Transportanforderung, benachrichtige Qualitätsmanagement und warte Freigabe
ab
– lediglich
für regulären Softwaredienst:
ergänze nächsten regulären Wartungsdienst
so, dass er den importierten vorläufigen Softwaredienst umfasst
-
In
dem Beispiel von 5 enthält eine Liste 500 für den Systemaufgaben-Typ D und einen vorläufigen Softwaredienst
eine Task 501 zum Anmelden an einem fernen System, eine
Task 502 zum Erzeugen einer Transportanforderung nach einem
vorläufigen
Softwaredienst und eine Task 503 zum Absetzen der Transportanforderung
an die Systemlandschaft, um sie zu wenigstens einem Produktionssystem
weiterzuleiten. Für
den Systemaufgaben-Typ O umfasst die Liste 500 eine Task 504 zum
Anmelden an einem fernen System und eine Task 505 zum Weiterleiten
der Transportanforderung, ohne sie zu importieren. Für den Systemaufgaben-Typ
P umfasst die Liste 500 eine Task 506 zum Anmelden
an einem Produktionssystem, eine Task 507 zum Bestätigen, dass
das bestimmte Produktionssystem das Ziel für den vorläufigen Softwaredienst ist,
eine Task 508 zum Ausführen
des vorläufigen
Softwaredienstes und eine Task 509 zum Ändern eines nächsten regulären Wartungsdienstes,
so dass er den importierten regulären Softwaredienst umfasst.
Es können
andere und/oder weitere Tasks sowie Attribute wie etwa "obligatorisch" vorgesehen sein.
Beispielsweise eine Task zum Importieren zuerst von Softwarediensten, die
bereits in dem Importpuffer eingereiht sind, jedoch erst während der
nächsten
regulären
Wartung importiert würden,
eine Task zum Prüfen
bestimmter Systemeigenschaften, eine Task zum Prüfen der gegenseitigen Abhängigkeiten
von Softwarediensten in dem Puffer und zum Neuordnen von diesen,
um ein gegenseitiges Überschreiben
zu verhindern, usw.
-
Auf
der Grundlage des Typs und des (der) Ziels (Ziele) des Softwaredienstes
auf den Transportwegen, der Systemaufgaben-Typen und der Liste 500 oder
einer entsprechenden Liste für
einen regulären
Softwaredienst wird eine Task-Liste
automatisch erzeugt, vorzugsweise in dem zentralen Task-System 307.
Die Task-Liste enthält
alle Tasks, die zum Ausführen
des Softwaredienstes in dem (den) Ziel-Produktionssystem(en) erforderlich
sind.
-
Die
Task-Liste besitzt vorzugsweise eine hierarchische Struktur. Die
obere Ebene bzw. das obere Niveau enthält einen Eintrag pro Transportweg.
Die nächste
Ebene enthält
einen Eintrag pro Systemaufgaben-Typ, vorzugsweise auch im Fall,
dass kein System entsprechenden Typs definiert ist. Die nächste Ebene
enthält
einen Eintrag pro Systemaufgabe, vorzugsweise nur dann, wenn diese
Aufgabe von einem System verwendet wird. Die unterste Ebene enthält die Tasks
für jedes
System.
-
In 6 ist
eine beispielhafte Task-Liste 600 gezeigt, die hier eine
Struktur besitzt, die nach dem Transportweg 601, den Systemaufgaben-Typen 602, den
Systemaufgaben 603, den Systemen 604 und schließlich den
Tasks 605 hierarchisch gruppiert ist. Die Tasks sind bestimmten
Systemen zugeordnet. Das Gruppieren ermöglicht das Sperren und Entsperren
von Gruppen von Tasks.
-
Die
Ausführung
der Tasks einer Task-Liste wird von dem zentralen Steuersystem 308 geplant. Das
zentrale Steuersystem 308 enthält zu diesem Zweck einen Plan,
der entsprechend den Tasks der Task-Liste automatisch erzeugt wird.
Das Erzeugen des Plans beinhaltet das Analysieren des Typs jeder Task
und weiterer Systeminformationen und dementsprechend das Kompilieren
im Voraus definierter Planelemente zum Bilden des Plans. Die im
Voraus definierten Planelemente umfassen Verantwortlichkeiten, z.
B. das Zuweisen bestimmter Typen von Tasks für bestimmte Systeme zu bestimmten
Personen oder Gruppen von Personen.
-
Beispielsweise
kann der Plan so zusammengestellt sein, dass er die folgenden Elemente
mit Verantwortlichkeiten umfasst: Erzeuge eine Task-Liste für regulären Softwaredienst-Änderungsmanager; importiere
in Qualitätssicherungssystem-Bediener; übernehme
das Testen und beschreibe Testergebnisse-Testeinrichtung bzw. testende Person;
genehmige oder weise zurück – Qualitäts manager;
falls genehmigt: importiere in Produktionssystem-Bediener; falls nicht
genehmigt: benachrichtige Entwickler-Testeinrichtung bzw. testende
Person.
-
Das
zentrale Steuersystem 308 ist somit geeignet, den gesamten
Dienst bzw. die gesamte Pflege und die mit dem vorläufigen Dienst
zusammenhängenden
Prozesse ab dem Berichten einer möglichen Störung bis zur endgültigen Implementierung der
Korrektur in dem Produktionssystem vollständig zu managen.
-
Das
zentrale Steuersystem 308 ermöglicht vorzugsweise das Anzeigen,
das Managen, das Analysieren und das Dokumentieren der Tasks und
jeder damit zusammenhängenden
Aktivität
sowie das Auslösen
der Ausführung
der Tasks in dem zentralen Task-System 307. Zu diesem Zweck
können
die Tasks Spool-Listen, Zustände,
Anwendungsprotokolle (application logs), Arbeitsprotokolle (job
logs) usw. dem zentralen Steuersystem 308 bereitstellen.
-
Gemäß dem Verfahren
der Erfindung sind Systemaufgaben und Systemaufgaben-Typen vorgesehen,
wobei den Systemen der Systemlandschaft die Systemaufgaben zugeordnet
sind und eine Liste von Tasks, die den Systemaufgaben-Typen zugeordnet
sind, vorgesehen ist. Wenigstens ein Transportweg ist vorgesehen,
der eine Route für
Transportanforderungen durch Systeme in einer bestimmten Reihenfolge
definiert und ein Quellsystem, benachbarte, damit verbundene Systeme
und wenigstens ein End- oder Zielsystem spezifiziert. Aus dem Softwaredienst-Typ,
den Systemaufgaben-Typen, der Liste und den Transportwegen wird
eine Task-Liste, die Tasks zum Ausführen des Softwaredienstes definiert,
erzeugt. Dies beinhaltet das Analysieren der Transportwege, um diejenigen
Systeme zu identifizieren, die durchlaufen bzw. validiert werden
müssen,
das Analysieren von diesen, um deren Systemaufgaben zu identifizieren,
das Analysieren der Systemaufgaben, um deren Typ zu identifizieren,
und das Kompilieren von Tasks für
die betroffenen Systeme entsprechend der Liste. Außerdem wird
in dem zentralen Steuersystem ein Plan entsprechend den Tasks in
der Task-Liste kompiliert. Das zentrale Steuersystem löst dann,
vorzugsweise entsprechend Berechtigungsebenen, die Ausführung der
Tasks durch bestimmte Personen oder eine Gruppe von Personen aus
und überwacht
den Zustand der Tasks. Der komplexe Prozess aus manueller Analyse
und Tätigkeit
gemäß dem Stand
der Technik ist somit durch einen automatisierten, zentral gemanagten
strukturierten Plan ersetzt.
-
Obwohl
das Vorhergehende eine Beschreibung einer bevorzugten Ausführungsform
der Erfindung ist, werden Fachleute nach Durchsicht dieser Offenbarung
erkennen, dass zahlreiche Abwandlungen und Abänderungen an der Erfindung
vorgenommen werden können.
Beispielsweise können,
anstatt SAP R/3 Release 4,5 zu verwenden, andere SAP- und Nicht-SAP-Systeme
einen Nutzen aus der Erfindung ziehen.