Ein kostenloser, monatlicher Newsletter über effektive Produktentwicklung und Freude an der Entwicklungsarbeit, basierend auf den Artikeln und beliebten Workshops von Matthias Bohlen. Frühere Ausgaben sind archiviert auf der Website www.mbohlen.de.
 
Web:
http://www.mbohlen.de
Email:
mbohlen@mbohlen.de
Twitter:
@mbohlende
Telefon:
+49 170 772 8545
 

Lösung ohne das zugehörige Problem?

Manchmal beobachte ich, wie Firmen einen Job ausschreiben:

Gesucht wird ein X, das folgende Aufgaben übernimmt: A, B, C. Sie brauchen als Qualifikationen dazu Q1, Q2 und Q3, idealerweise aus einem Hochschulstudium, und außerdem so und so viel Erfahrung im Job. Senden Sie bitte Ihre Bewerbung an Frau Müller von der Personalabteilung. Mit freundlichen Grüßen: Ihre Firma F, die beste auf dem Gebiet G.

Das hört sich nach einem Job an. Der Begriff “Job” bedeutet: es hat einen voll informierten Architekten gegeben, der ihn entworfen und vor-verpackt hat, so dass ein neuer Mitarbeiter ihn nur noch annehmen und auspacken muss. Kiste drum, Etikett drauf, fertig. Auf diese Weise brauchen Mitarbeiter den größeren Zusammenhang nicht zu kennen – es ist wie eine vorgefertigte Lösung ohne das zugehörige Problem.

Hmmm… Wie wäre es, wenn eine Firma stattdessen den Kontext mitgeben würde? Die Ziele, die sie erreichen will, die Art von Intelligenz, die sie sucht, eine Beschreibung des Systems, in das jemand als neuer Mitarbeiter hineinkommen würde? Die Firma könnte versuchen, das wertvollste an den Menschen zu nutzen, das, was sie von anderen unterscheidet, das was sie einzigartig sein lässt. Wenn wir eine richtig gute Firma sein wollen, sollten wir fragen “Was können Sie uns bringen, um zu helfen?” – und nicht sagen: “Hier ist der Job, tun Sie’s einfach!”.

Zum Schluss noch die Nachricht an die Führungskräfte unter Ihnen:  Wenn Sie einen externen Berater oder Coach suchen, machen Sie es genauso. Geben Sie ihm/ihr den Kontext mit. Sagen Sie nicht “Wir suchen einen Scrum Coach ab 1. April für 5 Tage die Woche, können Sie das?”, sondern fragen Sie “Unsere Teams ersticken in Aufgaben und kriegen manchmal nichts fertig. Was können Sie tun, um uns zu helfen, uns zu fokussieren?”. Es könnte nämlich sein, dass Sie einen wirklich guten Coach erwischen, der Ihnen Vorschläge macht, über die Sie staunen werden und die sogar noch vor dem 1. April mit weniger als 5 Tagen pro Woche umgesetzt werden können.


Relative Feature-Bewertung

Produktmanager, die ein Produkt für einen Markt entwickeln lassen, der von starkem Wettbewerb gekennzeichnet ist, möchten am liebsten wissen, was ein einzelnes Feature wohl wert sein wird. Wenn sie das wüssten, könnten sie ein wichtiges, lukratives Feature zuerst entwickeln lassen, sprich: es gegenüber den anderen Features priorisieren. Dazu muss man quasi eine Net Present Value-Betrachtung anstellen, das bedeutet: Was wäre es heute wert, wenn wir in 3 Monaten dieses Feature hätten?

NPV-Betrachtungen sind nicht einfach, das wusste schon Karl Valentin, als er angeblich sagte: “Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen” (Mark Twain und Niels Bohr sollen sich übrigens ähnlich geäußert haben). Deshalb tendieren alle Entwicklungsorganisationen, die ich bisher gesehen habe, dazu, nur eine relative Bewertung von Features vorzunehmen. Zum Beispiel mit diesem Ansatz:

  • Welches Feature ist eine Ware (commodity), weil es alle Konkurrenten auch haben?
  • Welches Feature ist ein Alleinstellungsmerkmal (differentiator), eines das sonst keiner hat, so dass neue Kunden begeistert zu uns kommen?
  • Welches Feature ist ein Störer (spoiler), weil es besser ist als das, was die Konkurrenz bisher als Alleinstellungsmerkmal hat?
  • Welches Feature ist lediglich nice to have?

Jetzt kann man sagen: “Eine Ware muss ich haben, um überhaupt Kunden zu bekommen, sonst bin ich sofort aus dem Geschäft. Also ist der Wert eines Waren-Features sehr hoch. Differentiators muss ich haben, damit ich neue Kunden bekomme, sonst bin ich langfristig aus dem Geschäft. Spoiler sind weniger oder mehr wert als Differentiators, je nachdem, wie wahrscheinlich es ist, dass ich meiner Konkurrenz damit Kunden abjage. Mit Spoilern versuche ich lediglich, im Geschäft zu bleiben. Nice to have-Features sind schließlich am wenigsten wert.”

Wie rechnet man das in EUR um? Eine Möglichkeit ist es, die total erwarteten Einnahmen eines Releases nehmen und durch die gewichtete Featurezahl teilen; z.B. zählt man eine Ware als 4, einen Störer als 3, ein Alleinstellungsmerkmal als 2,  und ein Nice to have als einen Punkt. Dann summiert man die Punkte der Featureliste für das Release und kommt auf z.B. 100 Punkte. Es könnte sein, dass der Produktmanager sagt: “Das neue Release bringt uns voraussichtlich Lizenzgebühren von 20 Mio. EUR”. Also ist jeder Punkt 20 Mio./100 =  200.000 EUR wert. Eine Ware „bringt“ demnach 800.000 EUR, ein Störer 600.000, usw.

So bekommen Sie als Produktmanager wenigstens eine ungefähre Vorstellung davon, was die Entwicklung eines Features kosten darf, damit es noch lukrativ wird. Doch wie gesagt: Etwas Lesen in der Glaskugel gehört dazu – Innovation ist niemals zuverlässig.

P.S.: Obwohl eine Ware (commodity) viel bringt, entwickelt man sie besser überhaupt nicht! Wenn alle Konkurrenten die Ware mittlerweile im Produkt haben, ist die Chance groß, sie einfach fertig einkaufen zu können. Und: Differentiators sollte man möglichst spät (im letzten noch verantwortbaren Moment) entwickeln, damit man sie dem anpassen kann, was die Konkurrenz inzwischen herausgebracht hat. Damit erreichen Sie möglicherweise schon wieder einen Wettbewerbsvorteil.


Scrum und seine Nebenwirkung

Scrum ist Mainstream geworden, man kann es nicht anders sagen. Aller Orten, nicht nur in der Softwareentwicklung, hört man, dass Scrum seinen Siegeszug beim Thema “Agiles Projektmanagement” angetreten hat. Zunächst vorausgeschickt: Ich besitze selbst so ein Zertifikat als Gedrängemeister, sogar noch ein altes, nicht das Neue. Und doch: Ich kann nicht umhin, auf eine Nebenwirkung von Scrum hinzuweisen, die mir immer wieder begegnet, wenn ich Scrum-Teams coache: Einseitige Fokussierung auf die Produktionsrate, die velocity.

Velocity = Medikament mit Nebenwirkung

Die Grundidee in Scrum, die ich moniere, ist überspitzt gesagt, folgende: Wir schätzen, wie viel wir tun können. Dann tun wir es. Am Ende stellen wir fest, wie viel wir wirklich tun konnten und nennen das velocity. Mit Hilfe der Velocity rechnen wir hoch, wie viel wir denn in den nächsten Iterationen (Sprints) erreichen können und bis wann das Produkt wohl das erste Mal releasefähig sein wird. Wenn wir in einem Sprint so viel erreichen konnten wie wir geschätzt und geplant hatten, nennen wir den Sprint “erfolgreich”, ansonsten nennen wir ihn “fehlgeschlagen”. Offenbar haben wir dann falsch geschätzt und müssen unsere Schätzungen verbessern.

Die Gefahr dabei ist folgende: Der Product Owner wird in der Regel versuchen, mit dem Team zu verhandeln, ob sie nicht in diesem Sprint ein wenig mehr leisten können als im Sprint davor. Das Team muss ihm sagen, ob es glaubt, das zu schaffen oder nicht. Das Team muss am Ende eines Sprints auch “bekennen”, ob es das, was es wollte, auch geschafft hat. Auf Basis der Erfahrungen aus den letzten Sprints wird das Team die nächste Sprint-Verhandlung führen.

Eine auch in Scrum häufig genutzte Möglichkeit, den Umfang des nächsten Sprints festzulegen, ist die Wetter-von-gestern-Regel aus dem Extreme Programming:

Das Wetter von heute wird ungefähr so wie das Wetter von gestern. Will sagen: Die Geschwindigkeit im nächsten Sprint wird so groß wie die im vorherigen Sprint.

Diese Regel kann zu stark schwankenden Werten für die Vorhersage führen, was den Product Owner nicht zufrieden stellt. Daher verwenden viele Scrum Teams gern einen Mittelwert für die Velocity über die letzten “n” Sprints (n=2,3,4,5,… je nachdem). Die Eigenschaft des Mittelwertes ist es jedoch, dass die Hälfte der Messwerte über dem Mittel, die Hälfte unter dem Mittel liegen werden. Das bedeutet: Wenn das Team voraussagt: “wir schaffen im nächsten Sprint 25 Einheiten, weil wir im Mittel halt immer so viele schaffen”, dann muss als Konsequenz davon die Hälfte aller Sprints “fehlschlagen”. Warum? Weil nun mal die tatsächliche Velocity in der Hälfte aller Fälle kleiner ist als deren Mittelwert.

Da es für ein Team unangenehm ist, dem Product Owner zu sagen: “Hallo, Verzeihung, wir werden den Sprint nicht wie vorhergesagt schaffen!”, tendieren nun viele Teams dazu, einen von zwei Auswegen zu wählen:

  1. Sie machen Überstunden, um den aktuellen Sprint eben doch wie vorhergesagt zu schaffen.
  2. Sie verhandeln beim nächsten Sprint über eine niedrigere Zahl für die vorausgesagte Velocity.

Der Ausweg Nr. 1 ist ein klarer Widerspruch zu dem, was Beck und Fowler in ihrem Buch Planning Extreme Programming eigentlich mit der Wetter-von-gestern-Regel erreichen wollten: eine über lange Zeit aufrechterhaltbare Teamgeschwindigkeit, die das Team weder stresst noch unterfordert.

Der Ausweg Nr. 2 (wenn er wiederholt angewendet wird) führt beim Management und beim durchschnittlichen Product Owner zur Befürchtung, dass die Velocity ständig nachlassen könnte. Der Product Owner wird versuchen, “dagegen” zu verhandeln.

Was für ein dummes Spiel! Team und Product Owner geraten so sehr leicht auf verschiedene Seiten des Seils, an dem sie ziehen. Lassen wir das doch besser bleiben.

Ausweg: Das kollaborative Spiel

Was tun wir also stattdessen? Wir hören am besten mit dem Verhandeln auf! Product Owner und Team fangen an, gemeinsam ein kollaboratives Spiel zu spielen, mit dem Ziel, den Wert der funktionierenden Produktes zu maximieren. Und das geht so:

  1. Das Team schätzt die Komplexität der Anforderungen, wie bisher auch (z.B. in Komplexitäts-Punkten 1, 2, 3, 5, 8, 13, usw.).
  2. Das Team macht zunächst keine Voraussage, wie viel sie in den nächsten Wochen schaffen werden.
  3. Das Team beginnt einfach, die wichtigsten Anforderungen zu realisieren und sammelt Erfahrungen.
  4. Der Scrum Master misst, wie lange die Realisierung einer Anforderung der Komplexität 1, 2, 3, 5, 8 oder 13 im Schnitt gedauert hat und bekommt für jede “Komplexitätsklasse” eine Zahl in Kalendertagen heraus, die Durchlaufzeit oder auch cycle time genannt wird.
  5. Wenn der Product Owner das nächste Mal fragt: “Wie lange werden die nächsten 6 Anforderungen zur Realisierung brauchen?”, gibt ihm der Scrum Master diese cycle time-Messwerte und erklärt: “Die nächsten 6 Anforderungen in Deinem Backlog haben die Komplexitätsklassen 1, 3, 2, 8, 5 und nochmal 3. Unsere Erfahrung mit der cycle time ist: Bei Parallelarbeit an 3 Anforderungen (WIP=3) dauern diejenigen aus der 1er-Klasse einen Tag, die 2er und 3er zwei Tage, die 5er und 8er bis zu 10 Tage. Also dauern die nächsten 6 Anforderungen voraussichtlich (1+2+2+10+10+2)/3=9 Tage.”

Ist das nicht schön? Keine “fehlgeschlagenen” Sprints mehr. Kein Verhandeln mehr nötig. Das Team legt seine Daten offen, der Product Owner kann darin lesen wie in einem Buch. Kein Grund mehr, dem Team zu misstrauen und zu fragen, ob es sich nicht etwas mehr anstrengen könnte und ob es nicht meint, im nächsten Sprint doch noch etwas mehr zu schaffen. Die Fokussierung auf die Produktionsrate hört auf.

Hier und Jetzt

Die Menschen im Team können sich nun darauf konzentrieren, die cycle time pro Anforderung zu minimieren. Das tun sie, indem sie einerseits die Zahl gleichzeitig bearbeiteter Anforderungen (work in progress, multi-tasking) minimieren und andererseits den Entwicklungsprozess verbessern. Immer wenn die Realisierung einer Anforderung stockt, fragt sich das Team einfach: “Woran liegt das?” und versucht, dieses Problem jetzt und sofort zu lösen. Die Gedanken der Teammitglieder befinden sich dann in der Gegenwart, im Hier und Jetzt.

Nochmal zum Vergleich: Die Gedanken bei der herkömmlichen Sprint-Planung mit Hilfe der velocity befinden sich meist in der Zukunft (“was werden wir wohl schaffen?”) oder in der Vergangenheit (“was haben wir am Anfang des Sprints vorausgesagt?”). Beides ist weniger gesund und weniger zufriedenstellend als wenn die Menschen gedanklich in der Gegenwart sind.

Sparen Sie also Energie, investieren Sie nicht in die Zukunft, sondern in das Hier und Jetzt: Good bye, good old velocity!


Lean/Kanban 2011 Benelux in Antwerpen


Am 3. und 4. Oktober findet in Antwerpen die Lean & Kanban 2011 Benelux statt – eine  Konferenz für alle, die sich mit schlanker, effektiver Produktentwicklung (insbesondere Software- und Systementwicklung) auseinandersetzen wollen.

Hochkarätige Sprecher wie Don Reinertsen, David Anderson, John Seddon u.a. werden anwesend sein, um über die neuesten Erkenntnisse im Bereich Lean Product Development zu sprechen. Auch mich finden Sie dort mit einem Vortrag über Kanban-Teams und ihre “vertragliche” Beziehung zu den Partnern im Wertstrom – gemeint sind die Partner, die Anforderungen bereitstellen (Fachbereich, Helpdesk, usw.) oder die Ergebnisse des Teams in die Produktion übernehmen (Betrieb, Anwendungsbetreuung, usw.).

Ich freue mich, Sie in Antwerpen zu treffen!


Verhüten oder bekämpfen?

Was sind die wesentlichen Dinge, die Sie und Ihre Produktentwicklungsteams in den kommenden Monaten davon abhalten werden, Erfolg zu haben? Genau! Und welche Maßnahmen ergreifen Sie dagegen? Verhüten Sie diese Ereignisse oder bekämpfen Sie sie erst, wenn sie eintreten?

Sie könnten beispielsweise mit dem Zeitplan ins Hintertreffen geraten – Ihre Teams könnten zu spät ausliefern. Das kommt, weil die Zykluszeit der Teams für die Bearbeitung gewisser Aufgaben schwankt, sagen Sie? Und: Sie planen deshalb Puffer dafür ein? Damit kaufen Sie Zeit ein, indem Sie Zeit ausgeben. Hmmmmmmmm…

Wie wäre es, wenn Sie die Sicherheit dadurch erlangen, dass Sie Ihre Teams herausfinden lassen, was die typischen Ursachen für solche Variabilität sind – zum Beispiel, indem Sie die Dinge, an denen gerade gearbeitet wird, visualisieren. Dann können Sie der Arbeit beim Fließen zusehen und lernen im Lauf der Zeit die Gründe kennen, warum die Arbeit stockt.

Was sind die Ursachen bei Ihnen? Vielleicht unsichtbare Arbeit, die getan werden muss aber auf keinem Plan steht? Oder vielleicht ständiges Umpriorisieren? Oder sind es Dinge, die entwickelt werden aber noch einmal nachbehandelt werden müssen, weil die Aufgabenstellung missverstanden wurde?

Gehen Sie diese Ursachen für Variabilität schon präventiv an. Das wird billiger. Lernen Sie von Ihrem Zahnarzt, von Ihrer Krankenkasse oder gleich von mir! Rufen Sie an – Kontaktdaten gibt es rechts oben, unter dem Foto!


Neues Training: Flow in der Produktentwicklung

Im Herbst des Jahres gibt es ein neues Training von mir: “Flow in der Produktentwicklung”. Sie können sich dort das aktuelle KnowHow abholen, wie man Produktentwicklung zum Fließen bringt und mit Ihren Teams gemeinsam besser werden.

Das können Sie erreichen:

  • Höhere Performance in der Entwicklung
  • Kürzere Zykluszeiten von der Anforderung bis zur Fertigstellung
  • Geringere Kosten
  • Begrenztes Risiko
  • Mehr Feedback
  • Höhere Motivation der Teammitglieder

Zielgruppe:

  • Manager, Projektleiter und interessierte Entwickler

Voraussetzungen:

Als Teilnehmer sollten Sie Erfahrung im Management von Entwicklungsvorhaben besitzen, z.B. als Projektleiter, Abteilungs- oder Bereichsleiter, Scrum Master, Produktmanager oder in ähnlichen Führungsrollen tätig gewesen sein. Sie können am meisten von den Seminarinhalten profitieren, wenn Sie z.B. mit Wasserfall-artigem Vorgehen Probleme hatten oder mit Agilem Vorgehen bereits begonnen haben und dieses noch weiter optimieren wollen.

Bringen Sie auf jeden Fall einen unvoreingenommenen Kopf mit, denn: Viele der Inhalte widersprechen konventionellem Wissen und der Intuition!

Buchen Sie Ihren Platz bei SIGS DATACOM!


Mitarbeiter hoch auslasten – ist das ökonomisch?

Manager, die Probleme mit der Effektivität oder mit der Arbeitsgeschwindigkeit ihrer Abteilung(en) haben, frage ich manchmal ganz naiv: “Wie hoch ausgelastet sind Ihre Mitarbeiter eigentlich?”

Oft kommt eine Antwort wie “Sehr gut! Mindestens 90%!”

Was ist eigentlich Auslastung?

Was heißt das eigentlich, 90% Auslastung. 90% von was denn? Nehmen wir uns die Warteschlangentheorie zu Hilfe (keine Angst, es wird hier nicht großartig mathematisch!). Diese Theorie sagt: Auslastung ist das Verhältnis von Ankunftsrate zu Abarbeitungsrate, mal 100%. Das bedeutet: Wenn einer Ihrer Mitarbeiter 10 “Sachen” die Woche tun kann (Abarbeitungsrate) und Sie geben ihm 9 “Sachen” pro Woche (Ankunftsrate), dann ist er zu 90% ausgelastet.

“Na schön”, sagen Sie, “ist doch gut, oder?” Ist es eben nicht. Warum?

Reaktionsfähigkeit

Nehmen Sie an, es kommt etwas Dringendes – Sie gehen zu dem Mitarbeiter und fragen Ihn: “Kannst Du mal eben dieses hier noch machen?”. Wenn er zu 90% ausgelastet ist, wird er mit 10%iger Wahrscheinlichkeit sagen “ja, mach ich sofort” und in allen anderen Fällen (nämlich 90%) wird er sagen “OK, aber erst demnächst” und wird das Dringende in seine Warteschlange legen. Sie können ihn jetzt drängen und sagen “Moment, das ist aber superdringend”, dann wird er eben die aktuelle Arbeit in die Warteschlange legen und erst das Dringende machen – Sie sind ja schließlich der Boss!

Jetzt nehmen Sie an, Sie steigern die Auslastung des Mitarbeiters noch auf 91% (1% mehr ist ja schließlich nicht viel, oder?). Wenn Sie jetzt mit etwas Dringendem kommen, wird er nur noch in 9% aller Fälle sagen “ja, mach ich sofort” – Sie haben (kurz mal eben) ein Zehntel seiner Fähigkeit, schnell zu reagieren eingebüßt, indem Sie ihn im Durchschnitt 1% mehr auslasten. Wenn Sie jetzt auf 95% Auslastung gehen, sagt er nur noch in 5% aller Fälle “ja, mach ich sofort” – seine Fähigkeit, schnell zu reagieren, ist auf die Hälfte gefallen (am Anfang konnte er wenigstens noch in 10% aller Fälle reagieren).

Sie sehen, wohin das führt: Steigerung der durchschnittlichen Auslastung verlängert die Warteschlangen exponenziell und macht Ihre Mitarbeiter weniger reaktionsfähig, so lange bis diese bei 100% Auslastung überhaupt nicht mehr reagieren können.

Das kostet viel Geld! Warum?

Warteschlangen

Die Warteschlangentheorie sagt (ach Gott, sagen Sie, jetzt kommt der Bohlen schon wieder damit!): “Länge der Warteschlange ist Auslastung zum Quadrat, geteilt durch 1 minus Auslastung”. Klingt kompliziert, ist aber einfach: Wenn ein Mitarbeiter zu 90% ausgelastet ist, ist seine Auslastung = 0,9 (100% wäre gleich 1). Also stehen in seiner Warteschlange 0,9 zum Quadrat geteilt durch 0,1 “Sachen”, also 8,1 “Sachen”. Was heißt das? Das heißt, wenn Sie diesem Mitarbeiter eine neue “Sache” geben wollen, wird er zuerst mehr als 8 andere “Sachen” machen müssen, bis er Ihre machen kann. Bei 95% Auslastung sind es schon 18, bei 99% Auslastung 98 andere “Sachen”, auf die Sie (oder Ihr Kunde oder Ihr Vertrieb) mit Ihrer neuen “Sache” warten müssen.

Kosten von Verzögerungen

Wie teuer ist das Warten auf 8, 18 oder 98 Sachen? Rechnen Sie es in € aus, und Sie werden feststellen, dass es in vielen Fällen teurer ist als einen weiteren Mitarbeiter einzusetzen, der die Warteschlange des hoch ausgelasteten Mitarbeiters verkürzt. Bedenken Sie: Bei 50% Auslastung hat die Warteschlange nur eine Länge von 1, bei 75% Auslastung hat sie etwas mehr als 2. Das sind doch tolle Werte, oder? Bei 75% Auslastung können Ihre Mitarbeiter also 9-mal so schnell auf erfolgskritische Anfragen reagieren als bei 95% Auslastung.

Balancieren Sie also am besten die Kosten von Verzögerung, die Sie (oder Ihre Kunden) beim Warten erleiden, gegen die Kosten von zusätzlicher Kapazität. Ist das nicht ein guter Deal?

Lust auf mehr solche Erkenntnisse?

Wollen Sie mehr über solche Möglichkeiten wissen? (Zum Beispiel, warum es keine gute Idee ist, Mitarbeitern Arbeit zu “geben”?) Rufen Sie mich an. Telefonnummer finden Sie in den Kontaktdaten rechts oben unter dem Foto. Ich verkaufe solche Erkenntnisse. :-)


Kanban Workshop in Köln

Am 13. Oktober gebe ich in Köln einen Workshop zum Kanban-Erfahrungsaustausch.

Als Kanban-Praktizierende können Sie in diesem Workshop Ihre Kaizen-Fähigkeiten erweitern. Erfahren, wie Sie die Veränderungsprozesse in Ihrem Team und seiner Umgebung weiter stärken können. Lernen Sie von Experten und von anderen Kanban-Praktikern.

Die Seminarthemen: Bringen Sie Ihre Themen mit!

Zeigen Sie uns z.B. Ihr Taskboard und Ihre Process Policies, Ihre Typen von Arbeitspaketen, Classes of Service, Taktiken, usw. Wir tauschen im Workshop Erfahrungen aus und finden Verbesserungsmöglichkeiten, z.B. für:

  • Langzeitplanung und -voraussage
  • Richtiges Setzen von WIP-Limits
  • Kontinuierliche Verbesserung
  • “Fallstricke und Tretminen” in Kanban
  • Probleme lösen mit der A3-Methode
  • Einführungsstrategien: Kanban einführen ohne anzuecken
  • Hindernisse im Flow entdecken und beseitigen
  • Messdaten erfassen und interpretieren
  • …und einiges mehr!

Melden Sie sich an bei SIGS DATACOM. Ich freue mich auf Ihr Kommen!