März 2016
Auch Fortschritt braucht Rückblick!
Vier Navigationsregeln für den Projekterfolg mit ComConsult Structured Scrum
Einleitung ................................................................................................................................................................................. 2
1. Plan-Build-Run: Das ewige Prinzip .................................................................................................................... 3 »Früher war mehr Planung«: Wasserfall »Heute sind wir viel agiler«: Scrum »Das Beste zweier Welten«: ComConsult Structured Scrum »Wähle weise!«: Das Teufelsquadrat
2. Best Practice: Vier Navigationsregeln für den Projekterfolg .................................................................. 7 Navigationsregel I: Beratung Navigationsregel II: Architektur Navigationsregel III: Verantwortung Navigationsregel IV: Dokumentation
3. Projekterfolg: Mit Karte, Kompass und einer Handvoll Regeln ........................................................... 12
Unser Angebot ..................................................................................................................................................................... 13
Die Autoren ........................................................................................................................................................................... 14
Das Motto »Neue Besen kehren gut« ist generell
mit Vorsicht zu genießen – dies gilt auch bei
neuen Methodiken im Projektmanagement. Denn
gerade dann, wenn die neuen Besen bestimmte
Ecken sichtbar besser kehren als die alten,
besteht die Gefahr, dass mit den alten Besen
Bewährtes und Nützliches über Bord geworfen
wird:
Ewige Prinzipien als Parameter, die sich auch mit
der Einführung neuer Methodiken nicht geändert
haben oder ändern werden.
Erfahrung aus vielen Projekten über viele Jahre,
mit denen unsere Berater ein Kundenprojekt
bereits im Vorfeld präzise einschätzen können.
Vier Navigationsregeln als Best Practices, die das
Neue mit dem Bewährten für den bestmöglichen
Projektverlauf verbinden.
Unser Whitepaper beschreibt, auf welche Weise
wir die spezifischen Stärken alter und neuer Projekt
methodiken für den Erfolg unserer Kunden
nutzen.
3 |Auch Fortschritt braucht Rückblick!
März 2016
1. Plan-Build-Run: Das ewige Prinzip
Auslöser für die Entwicklung dieses Whitepapers
war die konkrete Anfrage eines Großkunden nach
»einem Stück Configuration Management« als
Gewerk zum Festpreis. Die Frage nach einem Lasten
heft wurde beantwortet mit dem Hinweis auf die
agile Entwicklungsmethodik »Scrum« und auf unsere
langjährige erfolgreiche Projekterfahrung. Da
wüssten wir ja schon, was gebraucht wird! Um das
Happy End vorwegzunehmen: auch dieses Projekt
wurde von uns erfolgreich abgeschlossen. Aber
nicht so, wie ursprünglich angefragt. Denn entlang
unserer Erfahrung aus mehr als 25 Jahren erfolg
reicher Umsetzung großer Projekte haben sich »vier
Navigationsregeln« als Best Practices herauskris
tallisiert, die wir in diesem Whitepaper illustrieren
möchten. Lassen Sie uns den Hintergrund dieser vier
Regeln durch die Zeit verfolgen: wie früher geplant
wurde, womit heute gesteuert wird, was davon
zukunftssicher ist und warum bestimmte Dinge sich
aus guten Gründen nie verändern werden.
»Früher war mehr Planung«: Wasserfall
Großprojekte stellten zu allen Zeiten ein ernst
zunehmendes Risiko dar, und früher begegnete man
diesem Risiko mit der »Wasserfall«Methodik. Diese
Methodik erforderte es, viel Zeit und Energie in
akribische Planung und Konzeptarbeit zu investieren,
in der die Anforderungen und Abnahmekriterien
vor Beginn der Implementierung genau festgelegt
wurden. Bevor ein Projekt in See stach, wurde jedes
Teil der Bordausrüstung sorgfältig ausgewählt, und
jedem Projektmitglied wurden klar definierte Aufgaben
zugewiesen und die genaue Rudertaktung vorgegeben.
Dies zog sich von Vorplanung, Grobkonzept und
Pflichtenheft zum Lastenheft über den Prototypen
und darüber hinaus immer weiter durch das
gesamte Konzept. Neben dem erheblichen Aufwand,
den diese Methode verursachte, hatte dies auch zur
Konsequenz, dass sichtbare Funktionalität erst spät
im Rahmen der Entwicklung geliefert wurde, wie die
nachfolgende Darstellung zeigt.
»Heute sind wir viel agiler«: Scrum
Abhilfe schaffen für die beiden Nachteile der Wasser
fallMethode sollte die Umstellung auf die moderne
Projekt und Entwicklungsmethode Scrum: mit einer
drastischen Reduzierung der Zeiten und Aufwände
und einer erheblich früheren Sichtbarkeit von Funk
tionalität. Aber auch Scrum hat seine Grenzen und
eignet sich daher nicht für jedes denkbare Projekt.
Scrum eignet sich hervorragend unter den folgenden
Projektbedingungen:
• Die Zielsetzung ist eher unklar und soll
iterativ verfestigt werden.
• Die Aufgabenstellung bleibt im unteren bis
mittleren Komplexitätsbereich.
• Die Anforderungen lassen sich einfach in
kleinere Bausteine zerlegen.
• Marketing oder Politik diktieren, dass Ergeb
nisse schneller als üblich präsentiert werden
müssen.
Scrum ist dagegen weniger geeignet unter den
folgenden Projektbedingungen:
• Sehr große Projekte mit hohem Komplexitäts
grad (bauen Sie mal einen Flughafen mit Scrum
Methodik!).
• Enge formale Rahmenbedingungen, die agilen
Methoden widersprechen.
• Sehr geringer Entwicklungsanteil im Vergleich
zu Abstimmung & Konzeption.
Ein Auslöser der begründeten Begeisterung für die
ScrumMethodik ist unserer Erfahrung nach die
Umstellung auf kleine, sehr kollaborativ und lösungs
orientiert arbeitende Teams. Alle CrewMitglieder
reagieren in ihren Verantwortungsbereichen zügig
und flexibel auf Stromschnellen und halten das
Projekt auf Kurs und über Wasser, ohne entlang
länglicher Verantwortungsketten erst Befehle
vom Steuermann einholen zu müssen. Aus diesen
Gründen finden sich auch viele intrinsisch motivierte
Mitarbeiter, die selbstgesteuert »ihre Arbeit« zum
Erfolg führen. Diese Grundhaltung wird durch Scrum
gefördert, und viele Entwickler empfinden dies als
Befreiung im Vergleich zu klassischen, deutlich
formaleren Methodiken.
5 |Auch Fortschritt braucht Rückblick!
März 2016
Doch auch Scrum nutzt das »ewige Prinzip« des
PlanBuildRun, allerdings aufgeteilt in »Sprints« als
eine Vielzahl kleinerer Zyklen. Auf diese Weise führt
Scrum auch sehr schnell zu sichtbarer Funktionalität.
Ein klarer Vorteil, der jedoch auch seine Schatten
seite hat. Denn mit der deutlich früheren Sichtbarkeit
der Funktionalität kommt eine deutlich spätere
Sichtbarkeit der übergreifenden Anforderungen.
Dies sorgt im Projektverlauf auch für ein deutlich
raueres Fahrerlebnis als im Wasserfallmodell:
Entwicklungsteile müssen mehrfach verworfen
und neu geschrieben werden, wenn sich der volle
Umfang der übergreifenden Anforderungen erst zu
einem späten Zeitpunkt herauskristallisiert.
Unabhängig von der genutzten Projektmethodik
geht es in jedem Projekt darum, die eigentliche
Anforderung zu verstehen, richtig zu interpretieren,
zu spiegeln und gegebenenfalls gar nicht oder
auf eine andere Art zu lösen. Ein Fehler, der sich
häufig bei ScrumProjekten findet, heißt »los
programmieren«. Nach unserer Erfahrung müssen
20 % der ursprünglichen Anforderungen gar nicht
ausprogrammiert werden, wenn diese besprochen
und alternative Lösungsvorschläge erarbeitet
wurden – im Gesamtprojekt ebenso wie in den
Teilprojekten, z. B. vor jedem »Epic« als logischer
Bündelung von Storys.
»Das Beste zweier Welten«: ComConsult Structured Scrum
Das eingangs erwähnte Projekt wurde deshalb ein
Erfolg, weil wir den Kunden von einer vorgeschal
teten Konzeptphase überzeugen konnten. In dieser
Phase wurde das Fachkonzept mit den wesentlichen
Anforderungen und Abgrenzungen erstellt.
Viele Anforderungen konnten in Diskussionen auf
gehoben oder umgewandelt werden, ohne dass
Entwicklungszeit investiert wurde. Aufbauend auf
dieses Fachkonzept wurde das Gewerk in kürzester
Zeit und sehr zielführend mit ScrumMethodik
implementiert. Kleinere Anpassungen ließen wir
reibungslos einfließen, aber der große Rahmen
wurde vorab abgestimmt.
ComConsult Structured Scrum ist unsere hybride
Lösung aus Bewährtem und Neuem, die beide Wel ten
mit den besten Eigenschaften aus beiden Projekt
methodiken für eine gute Kundenlösung und eine
weitere ComConsultSuccessStory verbindet!
»Wähle weise!«: Das Teufelsquadrat
Methodendiskussionen sind eng verknüpft mit der
Idee, durch die Entscheidung für eine bestimmte
Methode oder einen Methodenwechsel Projekt
laufzeiten zu verkürzen und Aufwände zu reduzieren.
Mit anderen Worten: alles soll »schneller« und
»günstiger« werden. Aber natürlich so, dass weder
Funktionsumfang noch Qualität darunter leiden!
Diese Vorstellungen treffen allerdings auf eine
Realität, in der bestimmte »ewige Prinzipien« für
Projekte gelten, die sich nicht durch einen Wechsel
der Methodik verändern oder verbessern lassen.
PlanBuildRun ist ein solches Prinzip, aber auch
das Abhängigkeitsverhältnis der Projektparameter
Qualität, Leistungsumfang, Projektdauer und Preis,
das sich in Anlehnung an Harry Sneeds »Teufels
quadrat« (1987) modellieren lässt.
Das Quadrat verhält sich wie ein Rahsegel. Wenn
Sie an einem Ende ziehen, hat dies Einwirkungen
auf den Kurs, aber die Gesamtfläche bleibt stets
konstant: die anderen Ecken folgen Ihrem Zug, ob
Sie wollen oder nicht. Es ist verständlich, warum
Einkäufer diese Zusammenhänge nur schwer
akzeptieren können. Die Wirklichkeit zeigt jedoch,
dass dieses theoretische Modell in der Projektpraxis
stets wirksam ist.
Unsere Berater von ComConsult zeichnet die
Fähigkeit aus, in kürzester Zeit, oft nur in ein oder
zwei Stunden, bei gegebenem Funktionsumfang
eine belastbare Größenordnung für die Dimensionen
Projektdauer und Preis einzuschätzen. Sogar
wir selbst sind immer wieder positiv überrascht,
wie unsere Schätzungen rückblickend nur in
einem Rahmen von +/ 10 % von der Wirklichkeit
abweichen.
»Erfahrung hat man – oder man muss sie erst noch
machen«: Die beschriebene Fähigkeit unserer
Berater ist das Resultat von Erfahrung aus vielen
Projekten über viele Jahre. Und aus der Gesamt
summe dieser Erfahrungen sind unsere Best
Practices entstanden, die wir Ihnen im Folgenden
vorstellen möchten als »Navigationsregeln für den
Projekterfolg«.
7 |Auch Fortschritt braucht Rückblick!
März 2016
2. Best Practice: Vier Navigationsregeln für den Projekterfolg
Navigationsregel I: Beratung
Was immer eine neue Projektmethodik leistet:
eine gute Beratung kann und wird sie nicht
ersetzen. Das gilt für Scrum ebenso wie für jede
andere Methodik.
Der Schwerpunkt von Scrum liegt, wie beschrieben,
auf der Verbesserung der Software-Entwicklungs-
prozesse. Beratung setzt aber weit früher an und
spart später viel Irritation, Aufwand und Ärger.
Demonstrieren lässt sich das an einem simplen
Beispiel. Die Story des Kunden lautet: »Ich will
eine Bohrmaschine. Damit will ich Löcher bohren
können.«
•Ein Entwickler baut entsprechend dieser Story
einen recht aufwendigen ein- und ausschalt-
baren Motor mit fest verschweißtem Bohrkopf.
Damit kann man Löcher bohren. Nach zehn
Löchern ist der Bohrer stumpf. Über auswechsel -
bare Bohrer stand nichts in der Story. Daher
gibt es bald einen ChangeRequest für die
Erweiterung »Wechselbohrer«.
•Ein Berater von ComConsult fragt als erstes,
wofür die Löcher überhaupt benötigt werden.
Es stellt sich heraus, dass Haken in die Wand
geschraubt werden sollen; hierfür benötigt man
Dübellöcher. Als nächstes fragt unser Berater,
wofür die Haken denn benötigt werden. Die
Antwort darauf lautet, dass es eine Vielzahl von
Mitarbeitern gibt, die ihre Jacken aufhängen
müssen.UnserBeraterempfiehltdaraufhin:
»Links hinter der Tür ist im Standard eine
Garderobe enthalten, die vom Hersteller
laufend erweitert wird. Erfüllt das Ihre Anfor-
derung?« Natürlich erfüllt es die Anforderung,
und der Kunde ist zufrieden. Es war eine
Möglichkeit, von der er gar nichts wusste.
Der Unterschied liegt darin, dass im ersten Fall
Probleme gelöst werden, unter Umständen sogar
brillant und schnell, die im zweiten Fall gar nicht
erst entstehen – ein präzise mit Karte und Kompass
geplanter Projektkurs benötigt weder rasante
Wende- noch spektakuläre Rettungsmanöver.
Ohne Beratung leiden viele Projekte im Umfeld
von ServiceNow unter unpräzisen Storys, deren
Interpretationsspielraum oft so weit gesteckt ist,
dass die verunsicherten Entwickler alles Mögliche
produzieren. Dies wiederum führt uns zur zweiten
Navigationsregel: Architektur.
»Mit ComConsult Structured Scrum spart der Kunde in der Beratungsphase bereits 20 % des Entwicklungsaufwands durch präzise Analyse der Anforderungen.«
Navigationsregel II: Architektur
ComConsult macht kein »klassisches« Scrum – aus
gutem Grund.
Denn im EnterpriseUmfeld muss eine zentrale
Stelle übergreifende Entscheidungen durchdenken,
bewerten und langfristige Vorgaben für die
Projekt entwicklung machen. Diese zentrale Stelle
ist das Architekturboard.
Im Architekturboard werden Erfahrungen gebün
delt und gemeinsam die Vorgaben je Epic oder
sogar Story erarbeitet. Gibt es noch keine Ent
wicklungsrichtlinien, werden diese hier festgelegt.
Häufig sind der ScrumMaster und der Gesamtprojekt
leiter Mitglied oder Berater des Architekturboards,
um den Gesamtüberblick zu behalten.
In großen Projekten hat es sich bewährt, auch
den Hersteller punktuell ins Projekt einzubinden.
ServiceNow bietet »Configuration Reviews« als
DienstleistungspaketPaket an. Spätestens zum
Projektabschluss sollte es den offiziellen Stempel
des Herstellers mit dem »Production Readiness
Service« geben, um vor dem Produktionsstart das
Sicherheitsgefühl zu optimieren.
Dies wiederum führt uns zur dritten Navigationsregel:
Verantwortung.
»Mit ComConsult Structured Scrum spart der Kunde in der Umsetzungsphase weitere 10 % des Entwicklungsaufwands durch Entwicklungs- und Verfahrensstandards: dank ›Lessons Learned‹-Kommunikation und Transparenz führt der Kurs nie im Kreis, sondern immer geradeaus.«
9 |Auch Fortschritt braucht Rückblick!
März 2016
Navigationsregel III: Verantwortung
Große Projekte entwickeln häufig businesskritische
Anwendungen. Damit werden Funktionsfähigkeit,
Verfügbarkeit und Performanz der Plattform zu
extrem wichtigen Faktoren für das Unternehmen.
Aber wer stellt sich auf die Kommandobrücke und
übernimmt die Verantwortung, wenn sich Probleme
einstellen?
Wenn alles gut läuft, fragt zunächst niemand nach
Verantwortungsgrenzen. Bei Problemen oder bei
Release oder Technologiewechseln jedoch sind
Nachfragen nicht selten.
Zunächst gibt es die drei Grundperspektiven von
Hersteller, Kunde und Entwickler, die auf den
ersten Blick zweckmäßig und ausreichend erscheinen:
• Der Hersteller betreibt im Umfeld SaaS die
technische Plattform (Server, Datenbank
usw.) und stellt die BasisSoftware mit Kon
figurations und CustomizingOptionen zur
Verfügung. Für Probleme außerhalb seiner
Zuständigkeit trägt er keine Verantwortung.
• Der Kunde nutzt die Plattform und beauftragt
interne oder externe Entwickler/Projektierer
mit der Konfiguration und dem Customizing
der BasisSoftware einschließlich Entwick lungsrichtlinien. Er trägt die Verantwortung für
die performante und sichere Anbindung an die
Plattform.
• Die Entwickler nutzen Best Practices des
Herstellers, verwenden gängige Lösungen der
Community und halten sich an die Entwick
lungsrichtlinien des Kunden.
So weit ist dies sicher für jeden verständlich. Was
aber, wenn zum Beispiel die folgenden Fragen auf
geworfen werden:
• Wer garantiert den reibungslosen Release
wechsel?
• Wer ist im Rahmen normaler Innovationszyklen
mit Technologiewechsel beim Hersteller
(z. B. AngularJS) für die Umstellung der Ent
wicklungen im Kundenumfeld zuständig?
• Wer pflegt den »Baukasten« der Plattform im
Umfeld des Kunden?
Externer Prüfer Revision
Gesetze KonfigurationCustomizing
gut | böse
Freelancer
inhouseremote
nearshore offshore
Entwicklung
interne Entwickler
Hersteller
Kunde Dienstleister
Kunden des Kunden
SaaS-Plattform
Ver
trag
Ver
trag
Vertrag
Wohl dem, der einen hohen Erfahrungsschatz im
Architekturboard gebündelt hat, damit »Böses Cus
tomizing« frühzeitig erkannt und verhindert oder,
wenn es »nicht anders geht«, auf eine Ausnahmen
liste gesetzt werden kann. Hilfreich sind in diesem
Zusammenhang automatische Validierungen, über
greifende Konsistenzregeln und individuelle Güte/
ComplianceReports, um den aktuellen Zustand
der Lösung überwiegend automatisiert ermitteln zu
können.
Wurden im Problemfall der verursachende Code
oder die Objekte identifiziert, bleibt immer
noch herauszufinden, welche Auswirkungen
eine Änderung oder Deaktivierung haben kann.
Hilfreich wäre auch zu wissen, warum dieser Code
oder diese Objekte damals so entwickelt worden
sind … was uns schließlich zur vierten Navigations
regel führt: Dokumentation.
Navigationsregel IV: Dokumentation
Im Zentrum dieser vierten und letzten Navigations
regel steht ein berühmter Imperativ: »Wehret den
Anfängen!«
Kaum etwas ist so wichtig wie eine zielführende Ent
wicklerDokumentation, und kaum etwas ist bei
Entwicklern so verhasst wie zusätzlicher Dokumen
tationsaufwand. Rationalisiert werden die häufig
empörten Einwände bei Anforderungen nach zusätz
licher Dokumentation mit Argumenten wie »Der
Code ist doch selbsterklärend!« oder »Jeder sieht
doch in ServiceNow, wer das wann ent wickelt hat!«.
Ohne zusätzliche Dokumentation lassen sich aber
Fragen wie diese gar nicht beantworten:
• Im Kontext welcher Anforderungen wurde
dieser Code so entwickelt?
• Warum wurde dieser Code angepasst?
• Wo wird dieser Code überall genutzt und
welche weiteren Auswirkungen kann er haben?
Für die mittel und langfristige Tragfähigkeit der
Gesamtlösung liefert zusätzliche Dokumentation
ohne Medienbruch einen unschätzbaren Nutzen –
bei gleichzeitig geringem Mehraufwand für den
einzelnen Entwickler.
Hinsichtlich der besten Lösung für eine zielführende
Dokumentation ist die Antwort tatsächlich eine
Frage nach der Methodik!
ServiceNow unterstützt vorwiegend den Entwick
lungsprozess (Modul SDLC). Dies kann über das
PPSModul (Project and Portfolio Suite) erweitert
11 |Auch Fortschritt braucht Rückblick!
März 2016
werden, dann kommt Demand Management
und ein einfaches Test Management. Dies wird
noch wenig genutzt und ist häufig zu flach. Die
ComConsult Structured ScrumMethode liefert
sofort die Erweiterung der Entwicklungsmethodik
mit der Dokumentation von Konzept und Anforde
rung bis zum entwickelten Objekt und zugehörigem
Testfall.
Die nebenstehende Darstellung zeigt die bei
ComConsult Structured Scrum gebräuchliche
Struktur im Umfeld ServiceNow:
Mit dieser Methode wird eine Nachvollziehbarkeit
erzielt, die auch von den Entwicklern selbst gerne
und häufig genutzt wird.
• sie ermöglicht eine viel schnellere Analyse der
möglichen Auswirkung einer Anpassung bei
zukünftigen Erweiterungen;
• sie ermöglicht eine viel schnellere Analyse im
Fehlerfall.
Die ist besonders wichtig beim Multiprojekt
management (viele Steuermänner) und in
Entwicklungsteilen, die für Querschnittsfunktionen
zuständig sind und damit gemeinsam genutzt
werden (ein Kombüseneinerlei für alle, das leicht
zur Meuterei führt).
»Die entlang von ComConsult Structured Scrum erstellte medienbruchfreie Doku-mentation ermöglicht eine 30 % schnellere Analyse im Fehler- oder Anpassungsfall.«
Entwicklung
Einfache und schnelle Dokumentation ohne Medienbruch auf Objektebene
Qualitätskontrolle
Compliance Report zur automatisierten Überprü-fung der Dokumentation
Tests
Revisionssichere Durchgängigkeit von des Testfällen bis hin zu den einzelnen Objekten
M N
N
N
N
1
1 1
1
1
Kapitel Story
Entwickelte Objekte
Epic Testfall
Documentation Task
Spezifikationen SDLC QS-Dokumentation
3. Projekterfolg: Mit Karte, Kompass und einer Handvoll Regeln
Marktveränderung erfordert auch Methoden-veränderung.
ComConsult ist ein modernes Unternehmen,
das seine Methoden immer wieder auf den
Prüfstand stellt und anpasst, wenn es zum Projekt
ziel beiträgt.
Aber auch neue Methoden müssen sich »ewigen Gesetzen« beugen.
Parameter wie PlanBuildRun und das »Teufels
quadrat« werden auch in Zukunft Gültigkeit
behalten.
Auf bewährte Verfahren sollte nicht vollständig verzichtet werden.
Beratung, Architektur, Verantwortung und
Dokumentation als Best Practices finden auch in
neuen Projektmethodiken ihren Platz.
Auch und vor allem für entwicklungsintensive Projekte gilt: »Erst denken, dann handeln!«
Mit diesen Leitgedanken und der Kombination
aus Neuem und Bewährten sichern wir für unsere
Kunden seit über 25 Jahren den Projekterfolg.
13 |Auch Fortschritt braucht Rückblick!
März 2016
Unser Angebot
Gerne unterstützen wir Sie bei der ISTAufnahme,
der Analyse und der Empfehlung von Handlungs
alternativen vor dem Hintergrund Ihres individuellen
Umfeldes.
Für jede unserer Leistungen bieten wir Ihnen das
gesamte Servicespektrum moderner ITProjekte:
• Analyse, Zieldefinition, Konzeption,
Produktauswahl
• Customizing, Individualisierung,
Implemen tierung
• Prozessmigration, Inbetriebnahme,
Dokumentation
• Projektmanagement, Projektmarketing,
Reviews
• Produktschulung, Pflege, 24/7 Hotline, Support
Viele unserer Senior Berater und Beraterinnen
sind bereits mehr als zehn Jahre mit an Bord:
Geringe Mitarbeiterfluktuation, die Nutzung des
guten Ausbildungs und Arbeitsmarktniveaus
am Wissenschaftsstandort Aachen sowie eigene
Ausbildungsinitiativen und interne Schulungen
garantieren Ihnen Projektierungsteams auf
höchstem fachlichen Niveau.
Ist Ihr Interesse geweckt? Sprechen Sie uns an!
Wir freuen uns auf ein persönliches Gespräch.
Die Autoren
Roger Jakobs
Dr.Ing. Roger Jakobs ist einer der Strategieberater
der ComConsult Kommunikationstechnik GmbH.
Als gelernter »Raketendoktor« (Promotion in Luft
und Raumfahrttechnik) fühlt er sich im komplexen
MehrprodukteUmfeld bei Großkunden wie
zuhause.
Er sammelte Erfahrung als Ausbilder, Systemberater
und Projektleiter von internationalen Rollouts bei
Großunternehmen. Nach
mehrjähriger Tätigkeit als
ITLeiter und im höheren
Management unterstützt er
seit 2002 das Projekt und
Beratungsportfolio der
ComConsult.
Martin Woyke
Dipl. Kfm. Martin Woyke ist einer der beiden
Geschäftsführer der ComConsult
Kommunikationstechnik GmbH.
Seit der Gründung des Unternehmens 1986
wird er als anerkannter Strategieberater auf
Geschäftsleitungsebene geschätzt.
© Copyright by:
ComConsult Kommunikationstechnik GmbH
Pascalstr. 25
52076 Aachen
Germany
Tel. +49 (0) 2408 149 01
ComConsult Kommunikationstechnik AG
Stapfenstraße 5
3098 Köniz
Switzerland
Tel. +41 (0) 3139 801 41
www.comconsult.de