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-System 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ätssicherungssystem 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 Systemlandschaft 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ätsmanager; 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.