Projekt-Makro-Management, Teil 2 Datenbasierte Kontrolle und präzise Prognosen mit wenig Aufwand

Anbieter zum Thema

TASKING GERMANY GmbH

Parasoft® Deutschland GmbH

Teil 1 zeigte, warum klassische Scrum- und Projektmanagement-Tools oft keine verlässliche Aussage zur Termintreue eines Projekts liefern. Zur realistischen Einschätzung müssen die hier geschilderten Fragen beantwortet werden, ohne ungenaue Schätzungen zu überschätzen oder in Mikromanagement zu verfallen.

Teil 1 dieses Artikels befasste sich mit der Frage, warum klassische Tools für Scrum und Projektmanagement oft keine zuverlässige Auskunft darüber geben, ob ein Projekt termingerecht abgeschlossen werden kann. Für eine gute Einschätzung müssen die folgenden Fragen beantwortet werden, wobei man akzeptieren muss, dass Schätzungen unvollkommen sind und ein Mikromanagement, wer wann was tut, in der Regel weder machbar noch vorteilhaft ist.

Wann ist ein Projekt im Zeitplan?

• 1. Wer sollte an welchem Meilenstein arbeiten und mit welchem Anteil seiner Zeit, damit das Release-Datum eingehalten werden kann? Dies wird sich im Laufe der Zeit ändern, verschiedene Meilensteine erfordern möglicherweise unterschiedliche Personen, und Feiertage oder andere Abwesenheiten müssen berücksichtigt werden.

• 2. Sind die Fehler der Schätzungen von Aufgaben im Rahmen der gegebenen Zeitpuffer? Mit anderen Worten: Sind die Schätzungen zumindest im Durchschnitt ausreichend genau?

• 3. Arbeiten die Mitarbeiter tatsächlich wie geplant an den zugewiesenen Projekten? Oder sind sie noch mit der Fertigstellung eines anderen Projekts beschäftigt, stecken in einer alten Aufgabe fest oder werden an anderer Stelle zur Hilfe herangezogen?

• 4. Ist die Gesamtzuteilung der Mitarbeiter realistisch? Wenn Tom beispielsweise 70 % seiner Zeit für Projekt A und 70 % für Projekt B eingeplant ist und beide Projekte parallel laufen, dann wird mindestens eines der Projekte nicht rechtzeitig fertig werden.

• 5. Wie viel Arbeit bleibt insgesamt noch zu erledigen? Und wie passt das zur verbleibenden Zeit bis zum Release? Dazu gehört zumindest eine grobe Berücksichtigung für nicht abgeschätzte Aufgaben.

Basierend auf den aktuellen Daten: Wann ist der voraussichtliche Veröffentlichungstermin? Ist der Status grün, gelb oder rot?

In der Regel wird der erste dieser Punkte – der Plan „Wer arbeitet an was?“ – zu Beginn des Projekts erarbeitet. Dabei handelt es sich oft um eine grobe, allgemeine Zuweisung von Mitarbeitern zu den einzelnen Meilensteinen, die auf frühen Schätzungen der Aufgaben sowie der Verfügbarkeit und den Fähigkeiten basiert, die für die Meilensteine erforderlich sind.

Im Folgenden zeigen wir, wie ein Projekt mithilfe eines Ticketsystems (z. B. JIRA) modelliert werden kann und anschließend automatisch Berichte generiert werden, die alle genannten Fragen beantworten, ohne dass dafür umfangreiche zusätzliche Daten verwaltet werden müssen.

Die erforderlichen Informationen im Ticketsystem

Wie in Ticketsystemen wie JIRA üblich, beginnen wir damit, die Tasks aus dem Projektstrukturplan zu erstellen und sie den entsprechenden Meilensteinen zuzuweisen. In unserem Beispielprojekt P1 sind das Alpha und Beta. Wir betrachten auch ein paralleles Projekt P2, siehe Bild 1.

Für jeden Meilenstein erstellen wir eine Fix-Version in JIRA. Tickets, die optional sind (COULDs), sollten deutlich von denen unterschieden werden, die obligatorisch sind (MUSTs), um das Projekt erfolgreich abzuschließen. Je nach Ticketsystem kann man das über Label oder Namenskonventionen machen.

Bis hierher ist das gängige Praxis. Als Nächstes fügen wir strukturierte Informationen zur Teamzuweisung direkt in die Beschreibung der Fix-Version ein, wobei wir Folgendes angeben:

• Der Puffer für den Meilenstein (in Prozent) wird später auf jedes Ticket aufgeschlagen.

• Die voraussichtliche durchschnittliche Wochenarbeitszeit jedes Teammitglieds für diesen Meilenstein.

Wir formatieren das als einfache, computerlesbare Zeichenfolge. Zum Beispiel:

Wie in Bild 1 dargestellt, läuft der Meilenstein Alpha aus Projekt P2 parallel zu Alpha und Beta aus P1, wobei einige der Entwickler für beide Projekte eingesetzt werden. Die strukturierte Beschreibung erleichtert später die automatisierte Verwendung der Daten für Berichte und Auswertungen.

Für unsere Auswertungen benötigen wir auch die tatsächlich für die Umsetzung eines Tickets aufgewandte Zeit. Diese wird entweder direkt erfasst (Entwickler tragen bei der Arbeit ihre Stunden auf den Tickets ein, z. B. in JIRA durch „Buchen“ auf das Ticket) oder durch Messung der Zeiten, in denen Tickets in einem bestimmten Status einer Person zugewiesen waren.

Visualisierung: Den Status des Projekts verstehen

Wir verwenden das eazyBI-Plug-in für JIRA, um die hier dargestellten Berichte und Grafiken zu erstellen. Bei anderen Ticketsystemen wird ein ähnliches Reporting-Tool benötigt, oder zumindest Lesezugriff auf die Datenbank des Ticketsystems.

Mithilfe einer Confluence-Vorlage erstellen wir für jedes Projekt eine Status-Seite, die auch als Projekt-Plan (ASPICE) fungiert. Diese Status-Seiten fassen die dafür nötigen eazyBI-Berichte zusammen und bieten einen vollständigen Überblick über den Projektstatus, der täglich automatisch aktualisiert wird.

Im Folgenden zeigen wir die damit generierten Berichte, welche dann aus den Daten im Ticketsystem „live“ die Fragen aus dem Abschnitt „Wann ist ein Projekt im Zeitplan?“ beantworten:

1. Wer sollte an welchem Meilenstein arbeiten und mit welchem Anteil seiner Zeit, damit das Release-Datum eingehalten werden kann?

Wir importieren geplante Urlaube aus unserer Urlaubsverwaltungs-App über REST und reduzieren die Kapazität jeder Person entsprechend: In Bild 2 ist hinter den Namen der Personen der Urlaub während des Meilensteins in Tagen angegeben. Wir berechnen die effektive Kapazität, indem wir den Meilenstein-Puffer (im Beispiel 15 %) von der Gesamtzuweisung für diesen Meilenstein abziehen. Dadurch wird sichergestellt, dass Projektmanager genügend Arbeitsstunden zuweisen, um den Puffer abzudecken, anstatt sich auf versteckte Puffer zu verlassen.

Die Team-Kapazität (geplant) wird wie folgt berechnet:

• Effektive wöchentliche Kapazität × verbleibende Wochen im Meilenstein (wobei die verbleibenden Wochen aus den verbleibenden Arbeitstagen abgeleitet werden). Daraus ergibt sich, wie viel Arbeit für den Rest des Meilensteins machbar ist, wenn alle wie zugewiesen arbeiten.

Die Machbarkeit ist farblich gekennzeichnet:

• Grün: Teamkapazität (geplant) ≥ Gesamtumfang (COULD&MUST) der verbleibenden Arbeit.

• Gelb: Teamkapazität (geplant) ≥ verbleibende MUST-Arbeit, aber < verbleibende Gesamtarbeit.

• Rot: Teamkapazität (geplant) < verbleibende MUST-Arbeiten.

• Der Indikator „Gebucht/Geschätzt“ hebt die Qualität der Ticket-Schätzungen innerhalb des Meilensteins hervor.

Empfehlung zu Puffern und Schätzungen

• Puffer für Ungewisses sollten, wo möglich, auf der Ebene der Meilensteine berücksichtigt werden, statt Puffer auf die Abschätzungen einzelner Tickets aufzuschlagen. Die Schätzungen für Tickets sollten so ehrlich und unverfälscht wie möglich sein, damit aus Schätzfehlern gelernt werden kann und der Puffer klar an einer Stelle definiert ist.

• Drei-Punkt-Abschätzungen (schlechtester/bester/mittlerer) haben für uns keine bedeutenden Verbesserungen gebracht, aber sie können verwendet werden, wenn sie im jeweiligen Zusammenhang nützlich sind.

• Bei komplexen Arbeiten lässt sich die Zuverlässigkeit von Schätzungen durch Prototyping/Spikes und das Herunterbrechen der Arbeit in kleinere Aufgaben verbessern. Elemente mit hoher Unsicherheit sind meist leicht zu erkennen, aber ohne Herunterbrechen und praktische Untersuchung lässt sich die Genauigkeit selten verbessern.

Wir berechnen zusätzlich die Prognostizierte Dauer (auf Basis der Abschätzungen und zugewiesenen Mitarbeitern bzw. gebuchter Stunden im Meilenstein) jedes Meilensteins und die Summe der Dauer aller Meilensteine aus den Einzelprognosen (Bild 3). Wenn, wie in Bild 2 gezeigt, ein Meilenstein als verzögert projiziert wird (z. B. Beta wird -3,7 Tage vor dem Enddatum fertig, also 3,7 Tage zu spät nach aktueller Projektion), aber die danach folgenden Meilensteine laut Projektion genügend Zeitpuffer haben, um die Verzögerung auszugleichen (werden projiziert mehr als 3,7 Tage zu früh fertig), dann ist das Projekt als Ganzes noch nicht verzögert. In diesen Projektionen wird auch die bekannte zukünftige Verfügbarkeit der Mitarbeiter berücksichtigt (Zuweisungen zu den verschiedenen Meilensteinen und schon gebuchte Abwesenheiten). So bekommt man eine gute Übersicht über den gesamten Rest des Projekts.

2. Sind die Fehler der Schätzungen von Aufgaben im Rahmen der gegebenen Zeitpuffer?

„Booked/Estimated“ (Bild 2) misst, wie genau das Team die bisherige Arbeit pro Meilenstein abgeschätzt hat. Es wird berechnet als Summe der tatsächlich für alle abgeschlossenen Aufgaben verbuchten Zeit, geteilt durch die Summe ihrer Schätzungen, ausgedrückt in Prozent. Solange die Unterschätzung innerhalb des Puffers des Meilensteins bleibt, ist der Meilenstein „im Plan“ (orange hinterlegt auf Bild 2).

3. Arbeiten die Mitarbeiter tatsächlich wie geplant an den zugewiesenen Projekten?

Die erste Spalte in Bild 4 zeigt die geplante wöchentliche Zuweisung jedes Entwicklers für diesen Meilenstein, gemittelt über die vergangenen vier vollständigen Wochen (von vor fünf Wochen bis vor einer Woche). Wir schließen die aktuelle Woche aus, da die gebuchten Stunden in der Regel erst am Ende der Woche vollständig sind. Die zweite Spalte zeigt die tatsächlich gebuchte Zeit im gleichen Zeitraum.

Die Zeilenfarben zeigen Abweichungen an:

• Grün: fast planmäßig (entspricht in etwa den geplanten Stunden).

• Gelb: über dem Plan (evtl. fehlt Zeit in anderen Projekten).

• Orange: unter Plan (weniger als die geplanten Stunden).

• Weiß: Person war für dieses Projekt nicht vorgesehen, hat aber trotzdem daran gearbeitet

Die Fußzeile fasst den Zeitraum für alle Entwickler zusammen; in dieser Momentaufnahme liegt die tatsächlich gebuchte Zeit etwa 32 % unter dem Plan, was zu einer Verzögerung des Projekts führen kann (falls der Trend anhält und die Aufgaben nicht generell überschätzt sind).

Die übrigen Spalten enthalten zusätzliche Informationen, die bei der Interpretation dieser Abweichungen helfen, z. B. auf welche anderen Projekte der Mitarbeiter in der gleichen Zeit gebucht hat.

4. Ist die Gesamtzuteilung der Mitarbeiter realistisch?

In dieser Fünf-Wochen-Vorausschau zeigen wir die wöchentliche Gesamtzuweisung (Stunden pro Woche) jeder Person für alle gleichzeitig laufenden Meilensteine. Die Zeilen sind nach der höchsten bis zur niedrigsten zugewiesenen Zeit sortiert.

Farbcodierung:

• Rot: Die wöchentliche Zuweisung überschreitet die wöchentlichen Arbeitsstunden multipliziert mit einer Auslastungsgrenze (<1 für Besprechungen, Kontextwechsel usw.). Das bedeutet, dass der Zuweisungsplan für die verschiedenen Projekte in dieser Woche unrealistisch ist.

• Gelb: Die Auslastung liegt unter 50 % der wöchentlichen Kapazität, was auf eine mögliche Unterauslastung hindeutet.

• Grün: innerhalb des akzeptablen Bereichs.

Wir besprechen diesen Bericht alle zwei Wochen mit den Projekt- und Teamleitern. Rote Zellen werden auf ein vernünftiges Maß reduziert, indem die Zuweisung des Mitarbeiters beim am wenigsten kritischen Projekt reduziert wird. Gelbe Zellen zeigen Entwickler an, die vielleicht Kapazitäten haben, um bei Projekten zu helfen, die Probleme haben.

5. Wie viel Arbeit bleibt insgesamt noch zu erledigen? Und wie passt das zur verbleibenden Zeit bis zum Release?

Da wir die Berechnung dieses Diagramms selbst steuern, können wir die Schwächen beheben, die wir beim grundlegenden JIRA‑Versionsbericht festgestellt haben:

Zu konservativ: Wir extrapolieren auf drei verschiedene Arten daraus (optimistisch, pessimistisch und Mittelwert), damit der Graph nicht einfach als „zu pessimistisch“ abgetan wird. Wenn das Projekt selbst in der optimistischen Projektion nicht fertig wird, muss man die Ursachen mittels der anderen Visualisierungen im generierten Projekt-Status weiter untersuchen:

• Die „MS Start End“-Extrapolation ist dieselbe, die auch beim JIRA-Burn-up verwendet wird. Diese Ansicht ist in der Regel die konservativste, da Projekte oft langsam anlaufen und dann an Fahrt gewinnen.

• Die Prognose „schnellste letzten 3 Monate“ (grün) extrapoliert linear aus den „jetzt“ erledigten Stunden. Dabei wird die erledigte Arbeit der letzten drei Monate (Oberkante der grünen Fläche) mit der höchsten Steigung verwendet, ohne diese zu schneiden (die Verlängerung der gestrichelten grünen Linie berührt die Oberkante der grünen Fläche von unten, ohne diese Kante in den vergangenen drei Monaten zu schneiden), um die aktuelle Teamgeschwindigkeit zu schätzen.

• Das blaue Prognosedatum liegt genau in der Mitte zwischen den beiden anderen.

Zu optimistisch:

• Keine geplanten Urlaube/Abwesenheiten berücksichtigt (hoffentlich sind sie in der Durchschnittsgeschwindigkeit enthalten): Diese spezielle Ansicht basiert auf einer Extrapolation aus der Vergangenheit und berücksichtigt keine bekannten zukünftigen Abwesenheiten, d. h., sie zeigt den Fortschritt, wenn es wie „bisher“ weitergeht. Wir beziehen Abwesenheiten jedoch in die Planung/Machbarkeit von Meilensteinen ein (siehe 1. „Wer sollte an was arbeiten …“), sodass geplante Urlaubstage insgesamt berücksichtigt werden und sichergestellt wird, dass auch in Urlaubszeiten genügend Mitarbeiter eingeplant sind, damit es auch „wie bisher“ weitergehen kann.

• Nicht geschätzte Arbeiten haben keinen Einfluss auf das voraussichtliche Release-Datum: Anstatt lediglich die Anzahl der nicht geschätzten Punkte wie beim JIRA-Burn-up zu zeigen, gehen wir davon aus, dass jedes nicht abgeschätzte Ticket der durchschnittlichen Größe vergangener Tickets im Meilenstein entspricht, und addieren diese Arbeit zur Gesamtarbeit hinzu (rote gestrichelte Linie über der hellblauen „noch zu erledigenden“ Arbeit). Die voraussichtlichen Veröffentlichungstermine basieren dann auf der verbleibenden geschätzten Arbeit plus dieser angenommenen nicht geschätzten Arbeit.

Qualität der Schätzungen/Puffer unklar definiert: Wir definieren einen expliziten Puffer pro Meilenstein. Der Burn-up ist zuverlässig/korrekt, solange die durchschnittliche Unterschätzung der Tickets innerhalb dieses Puffers bleibt. Der Zeitpuffer (wie früh die voraussichtliche Fertigstellung vor dem Stichtag liegt) kann größer sein als angegeben, wenn Tickets überschätzt werden/schneller fertiggestellt werden als geschätzt, aber er wird nicht kleiner sein.

Geht von einem stabilen Team aus, das sich vollkommen einem einzigen Projekt widmet: Unser Burn-up extrapoliert zwar die bisherige Arbeit, aber wir prüfen auch die Machbarkeit zukünftiger Meilensteine, damit zumindest die MUST-Arbeiten von den zugewiesenen Entwicklern erledigt werden können.

Durch die Kombination mehrerer Prognosen und Blickwinkel erstellen wir ein vollständiges Bild des Projekts, das die Realität nicht beschönigt oder falsche Zuversicht weckt.

Wenn die Status-Report-Visualisierungen alle grün sind und der Projektleiter keine Bedenken hat – das sollte man nie ignorieren, egal was die Daten sagen, – kann man davon ausgehen, dass das Team das Projekt termingerecht fertigstellen wird, zumindest auf Basis der aktuell verfügbaren Informationen.

Ursachenanalyse

Sobald ein Teil des Status-Reports rot wird, zeigen die verfügbaren Daten, dass mindestens die Gefahr einer Verzögerung im Projekt besteht, die dringend untersucht werden sollte. Im Folgenden gehen wir die möglichen Ursachen der vermuteten Verzögerung und Maßnahmen, um diese zu beheben, durch.

1. Zuweisung von Entwicklern pro Projekt: Wenn ein Meilenstein schon vor Projektbeginn rot ist, ist der Projektplan noch nicht machbar, weil entweder zu wenige Entwickler zugewiesen sind oder zu viel Arbeit erledigt werden muss. Die Lösung: Kapazitäten hinzufügen, Aufgaben auf spätere Meilensteine verschieben oder den Umfang reduzieren. Wenn ein Meilenstein während der Bearbeitung rot wird, bedeutet das, dass der ursprüngliche Projektplan nicht mehr realistisch ist. Entweder haben die Entwickler nicht die im Plan vorgesehene Zeit an diesem Projekt zugebracht (siehe 3.) oder die Aufgabenabschätzungen haben den Puffer überschritten (siehe 2.).

2. Die Genauigkeit der Aufgabenabschätzung ist zu gering: Vergleichen Sie den mittleren Fehler der Abschätzungen mit dem zugewiesenen Puffer im Meilenstein (siehe orange hinterlegter Text in Bild 2). Wenn die Schätzungen den Puffer im Mittel relevant überschreiten, sollten die Ursachen untersucht werden. Der Schwerpunkt sollte dabei auf den schlimmsten Ausreißern liegen:

• Systematische Fehler: Das Team oder Teile davon schätzen generell zu gering ab. Zukünftige Schätzungen müssen entsprechend angepasst (besseres Schätzen mit dem Team trainieren/Puffer auf realistisches Maß erhöhen) und das Projekt muss mit dem neuen Puffer/besseren Abschätzungen neu geplant werden.

• inmalige Fehler bei einer spezifischen Aufgabe: Ähnliche Aufgaben (auch in anderen Projekten) sollten mit passendem Puffer neu abgeschätzt werden. Der Puffer sollte erhöht oder ein Prototyp erstellt werden, um die Unsicherheit zu verringern.

• Wirklich einzigartige Verzögerungen sollten als Ausnahmen akzeptiert werden; sie haben in der Regel keine Auswirkungen auf den Rest des Projekts und können nur über ausreichende initiale Puffer abgefangen werden.

Die allgemeinen Anforderungen für gute Schätzungen sind:

• Feedback (Entwickler werden darauf hingewiesen, wenn sie systematisch und konsequent abweichen), Erfahrung (Zugang zum richtigen Wissen)

• Verantwortlichkeit (Schätzer haben echte Umsetzungsverantwortung und werden nicht unter Druck gesetzt, ehrliche Schätzungen zu ändern)

• Anreize (richtiges Verhalten belohnen und eine Kultur des Lernens statt der Schuldzuweisung fördern)

• Realistische Erwartungen hinsichtlich der Genauigkeit (ehrliche Schätzungen anstreben, die nicht durch Fudge-Faktoren und „interne“ Puffer verschleiert werden).

• Die Schätzungsqualität pro Entwickler kann auch detaillierter verfolgt werden.

3. Gebuchte und geplante Zeit stimmen nicht überein

• Prüfen Sie, ob die Entwickler die geplante Zeit für das Projekt aufwenden (siehe Bild 4).

• Wenn nicht, sollte überprüft werden, ob die Entwickler die aktuellen Prioritäten verstehen, wissen, auf welche Projekte sie sich konzentrieren müssen, und nicht überbelegt sind (siehe 4.). Oftmals fehlt es Entwicklern einfach an Klarheit hinsichtlich der erwarteten (groben) Zeiteinteilung, oder sie haben vergessen, ihre Arbeitsstunden auf die richtigen Tickets zu buchen.

• Im Idealfall konzentrieren sich Entwickler auf ein einziges Projekt, aber aufgrund von Spezialwissen ist das nicht immer möglich.

4. Überbelegung von Ressourcen

• Wenn einem Entwickler mehr als seine verfügbaren Wochenstunden zugewiesen werden (siehe rot in Bild 5), sollte die Arbeit von überlasteten Entwicklern auf diejenigen mit freien Kapazitäten verteilt werden (niemals 100 % planen, das ist unrealistisch wegen Meetings etc.).

• Wenn eine Neuzuweisung nicht möglich ist, planen Sie die betroffenen Projekte neu mit den verfügbaren Kapazitäten (unwichtigste Features entfernen oder Release-Termine verschieben).

5. Der voraussichtliche Fertigstellungstermin nähert sich dem geplanten Fertigstellungstermin oder überschreitet diesen.

Wenn die Prognosen (Bild 2, 8) darauf hindeuten, dass sich das voraussichtliche Fertigstellungsdatum dem geplanten Fertigstellungsdatum nähert, spiegelt das in der Regel eines von vier zugrunde liegenden Problemen wider:

• Schlechte Planung (siehe 1.);

• Ungenaue Aufgabenschätzungen (siehe 2.);

• Teammitglieder, die nicht an ihren zugewiesenen Projekten arbeiten (siehe 3.); oder

• Entwickler haben sich in mehreren Projekten übernommen (siehe 4.)

Wenn das Projekt mit ausreichenden Puffern und realistischer Planung begonnen hat, werden sich etwaige Probleme durch Ursachenanalyse offenbaren, lange bevor es zu spät ist. Wir sehen meistens nach ein bis zwei Monaten, ob ein Projekt realistisch ist oder ob Anpassungen notwendig sind, also lange vor dem Liefertermin, der typischerweise sechs bis zwölf Monate in der Zukunft liegt.

Längere Urlaubszeiten (z. B. Sommer/Weihnachten) sollten vor Fertigstellung der ersten Version des Projektplans gebucht und damit berücksichtigt werden.

Es kann vorkommen, dass eine Verzögerung des Projekts „fälschlicherweise“ angezeigt wird, weil die Ursache vermeintlich harmlos ist. Z. B. haben die Entwickler ja „nur“ vergessen, ihre Stunden zu buchen, und wenn sie das täten, wäre alles wieder in Ordnung.

Hier läuft man Gefahr, dass die vermeintlich harmlose Ursache echte Probleme verschleiert. Man sollte also auch diesen Dingen nachgehen und sie beheben, um den Statusbericht „grün“ zu halten. Man kann auch die gebuchten mit den geschätzten Stunden vergleichen, um die Fertigstellung von Aufgaben zu schätzen, die noch nicht im Ticketsystem offiziell „zu“ sind. So umgeht man die ganze Diskussion: „Die Aufgabe ist fast erledigt, zeigt aber keinen Fortschritt, weil sie noch nicht abgeschlossen ist“ (unser Burn-up in Bild 6 verwendet diese Methode).

Die hier vorgestellte Methodik hilft uns, unsere Projekte mit minimalem Aufwand und vollständig auf Basis von Jira/Confluence zu verwalten. Komplexe Projektmanagement-Tools können vermieden werden, und der Arbeitsaufwand für das Projektmanagement wird minimiert, da sich unsere Berichte (auch für ASPICE) automatisch aktuell halten.  (sg)

* Dr. Alexander Herz ist Senior Engineering Manager bei TASKING.

(ID:50823331)