15 Jahre OP² – Das Event zum Jubiläum

Standard

Das Projektleben soll ja nicht immer nur reine Arbeit sein, sondern auch schöne Momente enthalten, die ein Team zusammenschweißen und alle miteinander motivieren. Bei OP² war der ideale Anlass, dass das Planungstool OP² jetzt schon 15 Jahre produktiv bei Continental in der Business Unit VED (vormals EBS) im Einsatz ist.

Der Leiter der Tool Abteilung bei VED, Herr Landgraf, hat das Ganze angeregt, seine Sekretärin Frau Thiel in wunderbarer Weise organisiert. Da können wir uns nur ganz herzlich bedanken.

Begangen wurde das Event abends auf der Saalburg im Taunus, zunächst mit einer Führung durch das rekonstruierte Römerkastell, mit ausführlichen Erklärungen zu dieser „Frühzeit“ unserer Geschichte.

Anschließend mussten wir uns in der Römerschenke stärken und konnten den Abend im gemütlichen Beisammensein ausklingen lassen. So ein bisschen „Verkleiden“ zwischendurch lockerte das Ganze auf und verschaffte Einblicke in das tägliche Leben der alten Römer.

Am nächsten Tag ging es dann sehr produktiv und entspannt im Rahmen eines Workshops zur Sache. Dort wurde die Historie von OP² reflektiert und von allen erarbeitet, welche Schwerpunkte das Tool heute abdeckt, zukünftig abdecken muss und wo seine Stärken und Schwächen momentan liegen. Ebenso waren Zusammenarbeit und Entwicklungsmethoden ein Thema. Vor allem haben sich dabei auch mal Leute persönlich kennen gelernt, die sich nur vom Telefon kannten.

Die Zeit verging dabei im Fluge. Es waren alle meine Kollegen sehr begeistert nach diesem Workshop.

Fazit: ein sehr produktives Teambuilding. Einfach wiederholenswert!

IMG_20171116_091032.jpg

Daher wurde auch beschlossen den Workshop des gesamten Teams, bestehend aus Continental Auftraggeber und Stakeholdern und dem Zoz & Partner Entwicklungsteam regelmäßig zu wiederholen.

 

Advertisements

Nur die übliche Begriffsverwirrung

Standard

Es ist erstaunlich wie sehr in großen Firmen gerade in Entwicklungsabteilungen ein Begriffswirrwarr herrscht. Was in der Produktion in kurzer Zeit zu einem Stillstand führen würde, scheint Entwicklungsabteilungen zu hemmen, aber nicht zum Erliegen zu bringen. Hier wird frei nach dem Motto Glaube und Hoffnung gearbeitet. Hoffnung auf der einen Seite bei den Prozessleuten, dass es einmal besser wird, Glaube in den lokalen Begriffsbrutstätten, dass die eigene Meinung die Richtige ist.

Das fängt bei ganz einfachen Sachen an. Zum Beispiel bei grundlegenden Projektverwaltungsdaten. Da gibt es den eigentlichen Kunden, den Konzern zu dem der Kunde gehört und die Marken, unter denen der Kunde bzw. der Konzern seine Produkte produziert. Man denkt, ganz einfach. Marke, das ist ein Aufkleber.Mehr nicht. Kann man verkaufen, kann morgen zu einem anderen Kunden gehören. Der Kunde, das ist die Firma für die ich etwas tue. Die Firma, mein Kunde, selbst gehört zu einem Konzern. Aber, schon fängt die Verwirrung an: Marke wird zum Kunden oder gar zum Konzern und umgekehrt(seit wann ist PSA, Peugeot Société Anonyme, z.B. eine Marke?) . Über den Namen des Kunden oder gar des übergeordneten Konzerns gibt es verschiedene Meinungen. Diese „Meinungen“ spiegeln sich in den Softwaretools der einzelnen Abteilungen, die sie sich haben entwickeln lassen wieder. Denn jedes dieser Tools hat natürlich eine eigene Datenbasis. Man kommuniziert und versteht sich nicht. Man arbeitet in verschiedenen Tools und überall heißt alles anders. Man baut Schnittstellen und übersetzt die Daten beim Transferieren. Toll!

Hallo! Hat einmal jemand einfach schon mal in dieses neuartige, vielen unbekannte Internet geschaut? Die Seite des Kunden aufgeschlagen und dort nachgesehen wie nennt der sich selbst, für welche Marke(n) produziert er und wie heißen die und wie heißt der Konzern, zu dem der Kunde gehört. Hmm?

Aber jetzt kommt’s. Spätestens mit der Einführung neuer großer Standardtools für Requirementsmanagment, Quellcode- und CAD Verwaltung, PLM und PDM Tools fängt es dann an zu klemmen.

Die Datenbasis muss/sollte vereinheitlicht werden. D.h., einer legt fest wie Dinge heißen und wie sie strukturiert sind. Für einen Bereich, für den er die Kompetenz hat. Für einen anderen Bereich macht das jemand anderes. Daten entstehen an der Stelle an der die Kompetenz dafür liegt. Sie gelten dann für alle. Eigentlich einfach. Die lokalen Tools bleiben, werden für die entsprechenden Daten halt auf die zentrale Datenbasis angepasst. Sicher, ist Aufwand, Arbeit, aber erspart später viel mehr Aufwand und Arbeit.

Was passiert dann aber: Variante 1) diese Vereinheitlichung wird einfach von oben durchgesetzt. Frust und Missmut allenthalben. Nutzungsverweigerung. Kann nicht mehr arbeiten.Finde meine Sachen nicht mehr. Variante 2) Konsens suchen, Besprechungen, Überzeugungsarbeit. Mappinglisten. Migrationsszenarien. Dauer (gefühlt) gegen unendlich . Ergebnis keines, außer Variante 1 wird dann doch in Kraft gesetzt.

Vielleicht hätte man sich das Ganze aber mit etwas Weitsicht ganz am Anfang der Entwicklung der Dinge ersparen können. Leute dazu erziehen, dass Sie andere, die die Kompetenz in einem Bereich haben, fragen, bevor sie etwas für sich selbst definieren. Keine Dateninseln entstehen lassen. Es ist schließlich die Aufgabe der (Fach) IT Informationen zu bündeln und richtig strukturiert abzulegen und keinen Wildwuchs zu erzeugen bzw. zuzulassen. Im Nachhinein bedarf es jeder Menge Anstrengungen, um die vielen gordischen Knoten zu lösen.