Informationen für den Projektstart in der Fahrzeugdauererprobung – Teil 3: Dokumentation

Peter Saubert/ April 4, 2018/ Fahrzeugerprobung Grundlagen, Projektsteuerung, Qualität und Effizienz/ 0Kommentare

Warum diese Beitragsreihe?

Das Verständnis von Fahrzeugerprobung und Fahrzeugdauererprobung ist leider immer noch – oder vielleicht wieder mehr – ein Verständnis von wir setzen jemanden in ein Auto und lassen ihn fahren. Damit wird mit viel Aufwand oft wenig bis gar kein Ergebnis erzeugt. Das ist aus der Sicht von Ansätzen wie „grünem Testen“ oder aus der Sicht der Wirtschaftlichkeit natürlich eine Katastrophe. Deshalb habe ich mich entschlossen, eine kleine Serie unter der Überschrift „Welche Informationen benötigt ein Dienstleister für die Fahrzeugdauererprobung vor dem Projektstart?“ bzw. kurz „Informationen für den Projektstart in der Fahrzeugdauererprobung“ zu verfassen.

Man kann diese Serie als Zusammenstellung von Fakten zur Projektvorbereitung aus Sicht eines Dienstleisters lesen oder zur Anleitung Aufbereitung eines Lastenheftes für die Vergabe von Projekten zur Fahrzeugdauererprobung (Fahrzeugdauerlauf, Straßendauerlauf, etc.).

Bereits in dieser Reihe veröffentlicht:

3. Teil: Dokumentation

Bedeutung der Dokumentation

Die Dokumentation wird von vielen nur als unangenehmes Anhängsel der Erprobung gesehen. Was aber ist der eigentliche Sinn der Erprobung? Dazu wird oft über Produktverbesserung und Produktqualität lamentiert. Dies sind aber eher Abfallprodukte aus der Erprobung. Produktverbesserung und Produktqualität ändern sich auch nur, wenn es Schleifen zurück in die Entwicklung gibt. Nur wenn diese Schleifen tatsächlich auch zu Produktanpassung führen, wird sich dies langfristig in Produktverbesserungen auswirken.

In aller erster Linie werden Fahrzeuge nicht erprobt, um die Qualität zu verbessern. Der Hauptgrund für die Fahrzeugerprobung sind gesetzliche Auflagen. Dies soll hier exemplarisch umrissen werden, was natürlich keine Rechtsberatung ist. Für potentiell haftende Führungskräfte empfiehlt sich auf jeden Fall eine anwaltliche Beratung zu den Risiken und Anforderungen.

Ein Beispiel für eine Haftung ist die Haftung aus dem „in den Umlauf bringen“ von „gefährlichen Gegenständen“. Jedes Fahrzeugen ist nach dem Verständnis der Rechtsprechung ein gefährlicher Gegenstand. Aus dieser Haftung heraus kann ein Hersteller auf Schadensersatz verklagt werden, wenn Schäden entstehen, die auf Grund einer Gefährdung vom Fahrzeug ausgehen. Dabei wird es sich primär um Sicherheitsrisiken handeln. Das gängige Beispiel dazu ist die Fehlfunktion der Bremsen. Es kann sich aber in der juristischen Argumentation schnell ein Bedienproblem des Navis zu einer allgemeinen Gefährdung entwickeln.

Darüber hinaus hat der Kunde Anspruch auf eine bestimmungskonforme Nutzbarkeit des durch ihn erworbenen Produkts. Eine begrenzte Anzahl an Nachbesserungen ist sicher immer möglich. Diese sind aber in der Regel teuer. Der Rücktritt vom Vertrag ist eine Möglichkeit, die dem Kunden bleibt, wenn die Nachbesserungen nicht erfolgreich sind.

Für OEM und TIER1 machen also rechtliche Beratungen zur Gestaltung der Dokumentation durchaus Sinn. Dazu sollten dann entsprechende Fachanwälte angesprochen werden.

Neben dem Hauptgrund – der gesetzlichen Forderung – bleiben natürlich auch noch andere Gründe, für die Dokumentation. Diese sind zum Beispiel

  • Nachvollziehbarkeit
  • interne Prozesssteuerung
  • internes Verbesserungswesen
  • Forderungen durch Normen
  • Fehlerreduzierung
  • kaufmännische Dokumentation
  • präventive Unfallvermeidung

Interessant zu diesem Thema sind auch folgende Artikel:

  • Produkthaftung Rechtsanwälte auf anwalt.de

Typen von Dokumentationen

Grundsätzlich sollte das Prinzip gelten, dass es für jeden Typ Daten eine Master-Quelle gibt. In der Masterquelle werden die Daten gepflegt und von hier kommen die Daten. Alle anderen Daten sind abgeleitet und werden nicht für sich gepflegt.

Für die Dokumentation gibt es unterschiedliche Ziele. Diese können zum Beispiel sein:

  • Prozesssteuerung
  • Projektsteuerung
  • Dokumentation für externe Leistungen, wie Versicherungen, KfZ-Steuer
  • Dokumentation für Zollbehörden
  • Dokumentation der Verkehrs- und Betriebssicherheit
  • Information der Kunden
  • Information des Managements des Kunden
  • Information des Managements des Dienstleisters
  • Information der Zulieferer
  • Dokumentation der Produkt-Freigabe und der Wahrnehmung der Sorgfaltspflicht
  • Dokumentation der Wahrnehmung der Fürsorgepflichten des Arbeitgebers

Da jeder dieser Gründe unterschiedliche Aspekte hat, ist die Versuchung groß, für jeden Zweck ein eigenständiges Dokumentations- und Reportingwerkzeug aufzusetzen. Das führt zu viel Aufwand bei widersprüchlichen Ergebnissen. Widersprüchliche Ergebnisse sind immer problematisch wenn es um die Dokumentation der Produktfreigabe und der Wahrnehmung der Sorgfaltspflicht geht. Deshalb sollte der Versuchung widerstanden werden und eine durchgängige Dokumentation aufgebaut werden.

In diesem Beitrag wird es primär um die Dokumentation zu den Zwecken Prozesssteuerung, Projektsteuerung und Information des Kunden gehen.

Unfallberichte

Grundsätzlich sind alle Unfälle in der Fahrzeugerprobung zu dokumentieren. In der Regel bestehen alle OEM und TIER1 darauf, dass bei Unfällen mit den OEM oder TIER1 zugelassenen Prototypen die Polizei hinzugezogen wird und den Unfall aufnimmt. Bei Wildunfällen wird in der Regel eine Aufnahme durch einen bestellten Jäger oder Förster bestanden. Damit sind zusätzliche Kosten verbunden. Es macht aber dennoch Sinn, da auf diese Weise bei einem Unfall eine unabhängige dritte Meinung eingeholt wird. Damit kann zum Beispiel Vorsatz bei der Beschädigung des Fahrzeugs ausgeschlossen werden.

In einem Unfallbericht können so gut es geht dokumentiert werden

  • Fahrer: Name, Arbeitszeiten der letzten 3 Tage, unfallstatistische Daten, Nebenbeschäftigungen, Rufnummer
  • Daten Führerschein: Klassen, Ausstellungsdaten, tagesaktuelle Kopie des Führerscheins
  • Daten Fahrzeug: Kennzeichen, interne Kennungen, Versicherungen, Gültigkeit HU (Hauptuntersuchung in Deutschland)
  • Unfallort: Lage, Skizze
  • Unfallzeit: Datum, Uhrzeit
  • Unfallgegner: Namen, Kennzeichen, ggf. interne Kennungen
  • Berichte und Meldungen externer Stellen: Polizei, Förster / Revierjäger, Zoll, Versicherungen
  • Unfallmanager: Name, Funktion, Rufnummer
  • Eskalationskette: im Rahmen der Eskalation informierte Personen – Name, Telefon, Mail-Adresse, Datum, Uhrzeit, weitergegebene Informationen
  • präventive Unfallvermeidung: notwendige Daten im Umfang der praktizierten präventiven Unfallvermeidung
  • Ablauf des Unfalls: Beschreibung im Prozess, besondere Wahrnehmungen im Zusammenhang mit der juristischen Bewertung des Unfalls (zum Beispiel Alkoholgeruch, technischer Zustand, etc.),

Auffälligkeitsreporting

Häufig wird im Bereich des Testing so getan, als wäre klar, was ist ein Fehler und was nicht. Das ist ein großer Irrtum. Was ein Fehler ist und was nicht, erschließt sich nicht zwingend. Vor Jahren gab es von der Firma MicroSoft ein Statement zu einem Fehler. Das Statement war: „It is not a bug, it is a feature“ bzw. auf Deutsch „Es ist kein Fehler, es ist eine Funktion“. Über diese Stellungnahme hat man sich ziemlich ausführlich lustig gemacht. Es ist aber charakteristisch für Testaufgaben. Die Systeme sind in der Regel sehr komplex, so dass innere Widersprüche häufig vorkommen. Wie soll jetzt der Erprober eine Beanstandung bewerten? Er kann es nicht.

Es hat sich deshalb folgende Hierarchie als empfehlenswert gezeigt:

  • Der Erprober beschreibt seine Auffälligkeiten. Auffälligkeiten sind zunächst wertungsfrei, auch wenn sie eine persönliche Meinung des Erproben enthalten.
  • Die Fahrzeugbegleiter bzw. Projektkoordinatoren erwirken eine Bewertung der Auffälligkeiten als Beanstandung, Fehler oder Bewertungsnotiz.
  • Beanstandungen und Fehler werden verfolgt. Bewertungsnotizen werden dokumentiert und sofort abgeschlossen.

Daraus folgen folgende Reportings:

  • Erprobungsbericht mit den erprobungsrelevanten Auffälligkeiten
  • Beanstandungsreporting
  • Fehlerreporting
  • technisches Projektreporting

Darüber hinaus gibt es ein Reporting im Rahmen der präventiven Unfallvermeidung.

Der Erprobungsbericht

Zu jeder Erprobungsfahrt muss es einen Erprobungsbericht geben, sonst kann es sich nicht um eine Erprobungsfahrt handeln. Der Erprobungsbericht hat unterschiedlichste Namen. Ich persönlich warne vor Bezeichnungen, die nicht klar machen, worum es geht. In der Praxis findet man häufig Begriffe wie Fahrbericht, Schichtreport, Fahrerreport, Fahrdatenerfassung und Ähnliches. Diese Bezeichnungen machen nicht klar, worum es wirklich geht. Es geht nicht um Fahren. Es geht um Erproben. Das sind zwei unterschiedliche Welten. Deshalb sind folgende Begriffe besser geeignet:

  • Versuchs-report / -bericht / -aufschrieb / -erfassung
  • Test-report / -bericht / -aufschrieb / -erfassung
  • Erprobungs-report / -bericht / -aufschrieb / -erfassung

Der Umfang des Erprobungsberichts muss sich am Erprobungsziel orientieren. Grundsätzlich sollten nur Punkte dokumentiert werden, die erprobungsrelevant sind. Alles andere ist nicht effektiv und verursacht zusätzliche Risiken und Kosten.

Daten, die in einem Erprobungsbericht erfasst werden können, sind zum Beispiel

  • Erprober: Name, Vorname, eventuelle Kennungsnummern, …
  • Fahrzeug: Kennzeichen, eventuelle Kennungsnummern, …
  • Schichtangaben: Früh- / Spät- / Nachtschicht
  • Angaben Erprobungszeiten: Start, Abfahrt, Ankunft, Start / Ende Zusatzbedienprogramm, Start / Ende Zusatzfahrprogramm, Ende, Schichtabweichungen, …
  • Programmangaben: Strecke, Besonderheiten, Zusatzfahrprogramm, Zusatzbedienprogramm, Schichtabweichungen
  • Zusatzfahrprogramm: Anzahlen, Besonderheiten, Einschränkungen, Schichtabweichungen
  • Zusatzbedienprogramm: Anzahlen, Besonderheiten, Einschränkungen, Schichtabweichungen
  • Verkehrs- und Betriebssicherheit: Reifenzustand / -druck, Beleuchtung, Funktion Bremse / Lenkung / etc.
  • Warnmeldungen am Fahrzeug
  • Beschädigungen am Fahrzeug
  • Beanstandungen und Auffälligkeiten aus der Erprobung
  • Tankungen
  • Fahrzeugmaßnahmen
  • Probenentnahmen

Beanstandungsreporting

Wir für eine Auffälligkeit der Status Beanstandung oder Fehler festgelegt, ist ein Beanstandungsreporting zu erzeugen. Es empfiehlt sich, das Beanstandungsreporting modulbar aufzubauen, so dass die einzelnen Beanstandungen im Nachgang in folgenden weiteren Reportings genutzt werden können:

  • Fehlerreporting (beinhaltet oft auch das Projekt-Fortschrittsreporting)
  • Baugruppenreport (Information der Baugruppenverantwortlichen, beinhaltet oft auch das Projekt-Fortschrittsreporting)
  • Baureihenreport (Information der Baureihenverantwortlichenbeinhaltet oft auch das Projekt-Fortschrittsreporting)
  • Fahrzeuglebenslauf (beinhaltet oft auch das Projekt-Fortschrittsreporting je Fahrzeug)

Fehlerreporting

Bekommt eine Beanstandung den Status Fehler, ist ein Fehlerreporting notwendig. Das Fehlerreporting beinhaltet

In der Regel kann der Dienstleister das Fehlerreporting nicht übernehmen. Es is also darauf zu achten, dass das Beanstandungsreporting kompatibel zu den entsprechenden internen QM-Systemen angelegt wird.

Im Fehlerreporting ist zumindest zu erfassen

  • Fahrzeugdaten: Kennzeichen, interne Kennung, Datum der Auftretens Laufleistung des Auftretens des Fehlers, relevante Details des Erprobungsprogramms (Laufleistung, Bedienungen, etc.)
  • Datum der Kategorisierung als Fehler
  • Anzahl der Fehler
  • Weibull- oder vergleichbare Statistik
  • Verantwortlicher für die Fehlerbehebung
  • Maßnahmen oder Quelle, an der die Maßnahmen verfolgt werden
  • Termin für die Rückmeldung
  • Termin für die Fehlerabstellung
  • Projektfortschritt und Meilensteine

Verbrauchsreporting

Erprobungsrelevante Verbräuche sind zu dokumentieren. Die Form und der Umfang der Dokumentation hängt vom Erprobungsschwerpunkt ab.

Das Verbrauchsreporting hat bevorzugt grafische Form. Die Grafik wir ergänzt um statistische Werte.

Das Verbrauchsreporting sollte grundsätzlich automatisch erzeugt werden.

Technische Projektreporting

Das technische Reporting wendet sich an die technische Projektleitung. Sie verdichtet alle Reportings und fast diese Zusammen. Hinzu kommen hinzu kommen alle wesentlichen Angaben zum Projekt-Fortschrittsreporing und zum allen Meilensteinen.

Das technische Projektreporting hat bevorzugt tabellarische Form. Abweichungen sollten durch ein Ampelsystem kenntlich gemacht werden.

Interne Bürokratie

Im Interesse der Fehlervermeidung und einer hohen Effizienz sollte sich die interne Bürokratie aus den Steuerungdokumentationen bedienen und keine eigene Dokumentation erfordern. So kann die Arbeitszeit der Mitarbeiter auch aus den Erproobungberichten entnommen werden. Interne Auslastungssteuerung kann auch auf der Basis von Fortschrittsreporting und Arbeitszeiten erfolgen.

Für die interne Bürokratie werden auf Grund gesetzlicher Regelungen in Deutschland zum Beispiel benötigt

  • Führerscheine und Berechtigungen: Der Arbeitgeber ist verpflichtet sicherzustellen, dass nur berechtigte Personen Fahrzeuge führen und bestimmte Aufgaben wahrnehmen. Deshalb muss das Vorhandensein der Führerscheine, Berechtigungen für HV-Fahrzeuge, Nutzung von Prüfgeländen, etc. permanent dokumentiert sein.
  • Fahrtenbuch-Dokumentation: Der Fahrer muss für ein Unternehmen im Bereich Fahrzeugerprobung zu jedem Zeitpunkt ermittelbar sein.
  • Arbeitszeitdokumentation: Lage der Arbeitszeiten, Beginn, Ende, Pausen, Vergütung
  • Dokumentation der Fürsorgepflichten des Arbeitgebers: Arbeitsschutzunterweisungen, Unfallvermeidung, Arbeits- und Ruhezeiten, aktueller Besitz Führerschein, notwendige Qualifikationen, Ernennungen und Berufungen, …

Regeln zum Erstellen von Berichten

Reports  und Berichte werden meist aus der Perspektive des Erstellers geschrieben. Dabei wird aber ein wesentlicher Aspekt vergessen. Egal warum ein Report oder Bericht erzeugt wird, es geht immer um die Information des Empfängers. Der Empfänger soll aus dem Bericht schnell die für ihn wesentlichen Punkte heraus ziehen können, ohne den Fachbereich des Berichterstatters zu verstehen.

Wichtige Fragen, die vor dem Reporten zu beantworten sind

  • Welches Ziel verfolgt der Empfänger des Reports?
  • Welche Steuerungsfunktionen benötigt der Empfänger des Reports?
  • Mit welche Schlüsselindikatoren (Key Performance Indicator (KPI)) lassen Ziele und Steuerung am besten verfolgen?
  • Welches Hintergundwissen hat der Empfänger des Reports?
  • Wie wird der Report vorgestellt?
  • Welche Fakten muss er dafür unbedingt wissen?

Es gibt niemanden auf der Welt, der sich über Dinge informieren lässt, die ihn nicht interessieren. Um sinnvoll Reporten zu können, muss also bekannt sein, welche Ziele der Empfänger im Hinblick auf den reporteten Umfang verfolgt. Neben der reinen Kenntnis von Sachverhalten ist für jeden Projekt- bzw. Teilprojektverantwortlichen und jede Führungskraft wichtig, ob steuernd bzw. korrigierend in einen Prozess eingegriffen werden muss.

Um diese sofort sichtbar zu machen wird auf wichtige Kennzahlen, so genannte Schlüsselindikatoren bzw. Key Performance Indicator (KPI), zurück gegriffen. Diese wenigen KPI gehören in die Managementzusammenfassung. Bei den KPIs sind alle positiven und negativen Abweichungen hervor zu heben.

In der Regel wird jemand, der nicht sehr tief in der Materie des Erprobungsprojektes steckt, nicht das nötige Hintergrundwissen haben, um jedes notwendige Detail sofort zu erfassen. Folglich muss der Reportingempfänger so informiert werden, dass er den Report auch verstehen und die für ihn relevanten Zusammenhänge erkennen kann. Das ist bei einem persönlichen Vortrag sehr einfach. Hier kann man gleich auf Fragen eingehen. Erfolgt das Reporting aber unpersönlich oder über ein System, kann dem Empfänger nicht der Zusammenhang erläutert werden. Im Zweifel ist hier die Vorstellung des Reportings zu Anfang des Projekts durchaus sinnvoll.

Reports enthalten oft zu viel oder zu wenig Information. Die Fragen, was muss der Leser wirklich wissen und mit was brauche ich den Leser nicht zu belasten sind deshalb essenzielle Effektivitätsfragen. Reports mit zu viel oder zu wenig Informationen sind deshalb häufig Streitthemen in der Erprobung.

Der grundsätzliche Aufbau eines Reports ist

  • Managementüberblick mit den wesentlichen KPI und Handlungsempfehlungen
  • Projektübersicht mit Einzellaufleistungen, wesentlichen Beanstandungsgruppen und globalem Beanstandungsbearbeitungsstand
  • Beanstandungen je Fahrzeug / je Baureihe mit Bearbeitungsstand (entsprechend Empfänger)
  • chronologische Überblicke

Natürlich lassen sich die Umfänge entsprechend der Zielsetzung erweitern oder kürzen. In jedem Fall empfiehlt es sich, mit den Empfängern des Reportings über das Reporting zu sprechen und Fragen zu stellen wie

  • Welche Umfänge des Reports sind nicht relevant?
  • Welche Informationen werden noch benötigt?
  • Ist der Report verständlich?
  • Was gehört auf die erste Seite?
  • Was gehört nicht auf die erste Seite?

Die Übersichtlichkeit des Reportings ist um so wichtiger, je häufiger berichtet wird. Bei seltener Berichterstattung ist mehr wert auf die Verständlichkeit zu legen.

Mehrsprachige Dokumentation

Da die Projekte zunehmend internationaler werden, kommt es zunehmend zu Projekten mit unterschiedlichen Sprachen. Damit wird die Dokumentation mehrsprachig. Die Projektkommunikation und Projektdokumentation wird durch die Mehrsprachigkeit komplexer. In vielen Fällen lassen sich für internationale Projekte auch die Grundregeln für internationale Projekte übernehmen.

Die wichtigsten Regeln für eine mehrsprachige Dokumentationen sollen an dieser Stelle auf folgende verdichtet werden:

  • Dokumentiert wird zunächst immer in der Muttersprache.
  • Die Originaldokumentation wird immer erhalten und eine Übersetzung erfolgt immer aus der Originaldokumentation.
  • Bei unklaren Übersetzungen wird immer die Unklarheit mit dargestellt. ggf. ist eine wörtliche Übersetzung als Anmerkung beizufügen.

 

Für Fragen, Anregungen und Diskussionen steht Ihnen der Autor gerne zur Verfügung.

Share this Post

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Sie sollten das verwenden HTML Schlagworte und Attribute: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*