Systems Engineering Camp Juni 2018 in Erlangen

Das erste Systems Engineering Camp in Erlangen hat am 28.06.2018 stattgefunden und war ein voller Erfolg. In diesem Artikel möchte ich allen Teilnehmern, aber auch allen die verhindert waren, einen Überblick über die Veranstaltung geben.

Die Idee zum Camp

Der Grundgedanke bei der Veranstaltung war es, einen regelmäßigen, regionalen Austausch zum Thema Systems Engineering in der Region Nordbayern zu etablieren. Dazu wurde das Format des Barcamps genutzt. Im Gegensatz zu den bisherigen Systems Engineering Barcamps, wurde anstelle einer ganztägigen Veranstaltung auf eine Abendveranstaltung gesetzt. Damit war es den Teilnehmern möglich die Veranstaltung ohne Urlaub oder Inanspruchnahme des Wochenendes zu besuchen. Die Idee für das Camp ist, wie soll es anders sein, auf einem anderen Systems Camp entstanden. Daniela Kaiser (Krones AG), Jan Vollmar (Siemens AG) und ich (Goran Madzar) wollten uns gerne regelmäßiger austauschen ohne dazu weite Fahrten in Kauf zu nehmen. Gemeinsam haben wir das Event organisiert.

Die Teilnehmer

Mit 23 Teilnehmern war das erste Systems Camp in Erlangen gut besucht. Das Event wurde drei Wochen vorher über den Blog, Newsletter, sozialen Medien sowie über Mundpropaganda und XING angekündigt. Auf einem Flipchart konnten die Teilnehmer Informationen über sich notieren.

Die Agenda

Der offizielle Teil der Veranstaltung ging von 18:00 – 21:00 Uhr. Zur Begrüßung habe ich eine kurze Präsentation gezeigt und bin dabei darauf eingegangen, was Systems Engineering überhaupt ist. Die meisten Teilnehmer waren davor noch nicht auf einem Barcamp. Daher wurde das Format, sowie die Barcamp Regeln vorgestellt. Anschließend gab es noch Informationen zum Programmablauf und organisatorischen Aspekten. Gemeinsam wurden dann die Themen für die Sessions definiert. Die erste Session war dafür reserviert vorzustellen, wie der regelmäßige regionale Austausch zum Systems Engineering gedacht ist. Die anderen beiden Sessions wurden von den Teilnehmern ermittelt. Zum Schluss gab es noch eine Retrospektive und Verabschiedung, wobei der inoffizielle Teil noch bis kurz vor Mitternacht andauerte :-)

Die Location

Das erste Systems Engineering Barcamp in Erlangen wurde in den Räumen unserer Firma veranstaltet. Fleischkäse, Nudelsalat, Brötchen, Brezeln sowie die lokalen Bierspezialitäten wurden gut angenommen :-)

Die Themen für die Sessions

Die Teilnehmer hatten die Gelegenheit Vorschläge zu machen und diese wurden an einer Wand gesammelt und gruppiert. Anschließend konnte jeder Teilnehmer abstimmen, welche zwei Themen am meisten interessieren und so wurden die zwei Sessions ausgewählt.

Session 1 – Arbeitskreis Systems Engineering Bayern Nordost

Ein regelmäßiger Austausch über Systems Engineering ohne weite Anfahrtswege und auf regelmäßiger Basis. Diese Idee stand bei der ersten Session im Vordergrund. Eine solche Veranstaltung könnte 4-6 Mal pro Jahr stattfinden. Die Teilnehmer haben sich für eine Abendveranstaltung ausgesprochen. Als Uhrzeit für den Beginn wurde mehrheitlich 17:00 – 18:00 genannt. Eine Prüfung, ob dieser Arbeitskreis unter der Dachorganisation der GfSE oder des VDI aufgehängt werden soll, ist aktuell in Klärung.

Session 2 – Umgang mit Änderungen / Inkonsistenz Management

Der Themenblock Umgang mit Änderungen am System und Konsistenz-Prüfungen wurde von den Teilnehmern als sehr interessant eingestuft. Deswegen beschäftigten wir uns in Session 2 mit diesem Thema. Zuerst wurde festgestellt, dass es gewollte und ungewollte Änderungen am System gibt. Gewollte Änderungen sind planbar und können somit gut nachvollzogen werden, z. B. durch Test-Cases, Use-Cases und Misuse-Cases, durch das Implementieren von interdisziplinären Teams und eine ausreichend gute Definition des System Engineering Systems. Als gutes Beispiel für interdisziplinäre, agil arbeitende Teams wurde Wikispeed genannt. Ungewollte Änderung sind nicht planbar und müssen somit beherrschbar gemacht werden, um die Auswirkungen auf Prozesse und technische Komponenten sichtbar zu machen. Eine wichtige Vorbereitung darauf ist die Anpassung der Infrastruktur des Unternehmens. Auch sollten die Möglichkeiten zur Traceability genutzt werden und ein gutes Stakeholder-Management aufgebaut werden.

Ihr Ansprechpartner:

Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer 
E-Mail: madzar@medtech-ingenieur.de
Tel.:  +49 9131 691 240
 

Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf.

Kontakt aufnehmen

Um die Änderungen handhaben zu können, ist das A&O, zu Beginn eines Projektes Anforderungen aufzunehmen und zu validieren und verifizieren. Eine Änderung kann sich auf verschiedene Systeme des Unternehmens auswirken – auf technisch-physikalische oder organisatorische Systeme.

Session 3 – Entwurfstechniken des Systems Engineerings

In der Session 3 wurden Entwurfstechniken für System Modelle diskutiert. Es bestand bei den Teilnehmern der Wunsch nach einem Baukasten für Modelle mit bewährten Lösungsansätzen. Eine gute Möglichkeit solche Pattern zu visualisieren und in dem Unternehmen zu etablieren sind Poster, auf denen die Baukasten-Bestandteile gesammelt werden. Ein wichtiger Aspekt war es, dass die Modelle nicht nur in den Tools (z.B. Enterprise Architect) bleiben dürfen, sondern als Ausdruck auf die Wände gehören.

Modelle raus aus den Tools und rauf auf die Wände.

Modelle sind kein Selbstzweck und am besten, wenn Sie im Team entstehen und vom Team genutzt werden. Es gibt dazu auch Methodiken den Kunden einzubinden, ohne dass dieser einen SysML-Hintergrundwissen benötigt.

Es wurde aber auch festgestellt, dass ausführliche Modelle eine Gefahr beinhalten. Der Architekt verliebt sich in seine Architektur und empfindet den Kunden oder die Entwickler als Störgröße, wenn diese Änderungen vorbringen, die die Architektur betreffen. Die Gefahr besteht darin, dass das Modell als die „Wahrheit“ angesehen wird und ungern hinterfragt wird.

Diskutiert wurde auch der Zusammenhang von Architektur und Agilität. Insbesondere bei agilen Projekten ist die Architektur sehr wichtig. Denn auch bei einem agilen Vorgehen muss man sicherstellen, dass sich die Architektur möglichst nicht ändert. Denn dann beginnt man in der Entwicklung ggf. von vorne (z.B. Flugzeug statt Auto). Daher ist es wichtig, dass sich die Architektur mit den Aspekten befasst, die nur schwer wieder geändert werden können.

In der Session gab es zwei Literaturempfehlungen:

  • Design It!: From Programmer to Software Architect von Michael Keeling
  • arc42 in Aktion: Praktische Tipps zur Architekturdokumentation von Gernot Starke und Peter Hruschka

Das Feedback der Teilnehmer

Das Feedback der Teilnehmer wurde mit Hilfe eines Starfish Diagramms eingesammelt.

Mein persönliches Fazit

Es war ein tolles Event, für welches ich viel Zuspruch von den Teilnehmern bekommen habe. Zudem haben mich viele Leute darauf angesprochen, dass Sie gerne beim nächsten Mal dabei sein möchten. Daher wird es mit Sicherheit in nicht allzu-ferner Zeit ein weiteres Event geben. Darüber werde ich rechtzeitig auf dem Blog, im Newsletter und bei Xing informieren. Ich freue mich bereits darauf.

Viele Grüße

Goran Madzar

Kontaktieren Sie uns!

Autor

  • Goran Madzar

    MEDtech Ingenieur aus Leidenschaft! Mein Team und ich helfen Medizintechnik-Herstellern mit Engineering-Dienstleistungen dabei, Produkte zu entwickeln und in Verkehr zu bringen! Sprechen sie mich gerne an, ob bei LinkedIn oder per Mail. Ich freue mich Sie kennenzulernen.

Auch interessant:

BLE – Ein kurze Einstiegshilfe in die Welt von Bluetooth Low Energy

Als die ersten Bluetooth Low Energy Geräte in den Markt kamen, hatte BLE geradezu etwas Mystisches. Jeder wollte diese Technologie nutzen, auch wenn kaum jemand so richtig verstand wie es funktioniert. Hinzu kam, dass die Integration von BLE damals harte Arbeit war. Um mit BLE zu arbeiten, musste man sich in…
Getagged mit: , , ,