Als PDF, PPTX herunterladen
Hochgeladen vonStefan ROOCK
Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?
Der Vortrag erörtert die Anwendung der Lean-Startup-Prinzipien in der Unternehmens-IT und beleuchtet die Herausforderungen, die klassische Unternehmen wie Banken bei der Implementierung dieser Methodik haben. Es wird argumentiert, dass zwar ein Potenzial zur Verbesserung der Reaktionsfähigkeit auf Marktbedürfnisse besteht, jedoch ein umfassender Kulturwandel und die Bereitschaft zur Überprüfung bestehender Annahmen notwendig sind. Die Diskussion hebt hervor, dass Lean Startup nicht nur für die Softwareentwicklung, sondern auch für den Innovationsprozess insgesamt von Bedeutung ist.
Weitere ähnliche Inhalte
Ähnlich wie Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?
Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?
- 1. LEAN STARTUP IM UNTERNEHMEN Wirdder IT-Leiter zum Entrepreneur? Stefan Roock stefan.roock@it-agile.de Twitter: @StefanRoock Mittwoch, 6. November 13 Abstract: Lean-Startup ist eine akzeptierte Vorgehensweise in Startups und verbreitet sich schnell in alle Bereiche, in denen innovative Produkte entwickelt werden. Aber eignet sich der Ansatz auch für die klassische Unternehmens-IT? Können klassische Unternehmen wie Banken und Versicherungen schneller und besser auf den Markt reagieren, wenn ihre interne IT Lean-Startup benutzt? Ist gar die Verwendung von Lean-Startup über die IT hinaus sinnvoll? Der Vortrag diskutiert nach einer kurzen Einführung in die Lean-Startup-Prinzipien die Chancen und Einsatzmöglichkeiten von Lean-Startup für die Unternehmens-IT und darüber hinaus. Dabei wird neben der reinen „Mechanik“ auch der notwendige Kulturwandel adressiert.
- 2. Dieser Vortrag • Lean-Startup imUnternehmen für interne IT-Projekte? • Können größere Unternehmen wie Banken und Versicherungen von Lean-Startup für die Entwicklung ihrer internen Software profitieren? Mittwoch, 6. November 13
- 3. Die Kernaussage zuerst •Lean-Startup im Unternehmen anzuwenden ist logisch und naheliegend, • und gleichzeitig total bescheuert. • Die Frage ist nicht, ob die Unternehmen von Lean-Startup profitieren können, sondern ob sie bereit sind, die Voraussetzungen dafür zu schaffen. • Aber vielleicht kann Lean-Startup eine Perspektive für 2025 sein. Mittwoch, 6. November 13
- 4. Aber der Reihenach.... Mittwoch, 6. November 13
- 5. Manni der IT-Leiter Mittwoch,6. November 13 Manni ist IT-Leiter in einem größeren Unternehmen. Seine Abteilung entwickelt Software für die Fachabteilungen, damit die ihre Arbeit besser erledigen können. Manni ist unglücklich. Die Fachabteilungen wollen mehr, als seine Abteilung leisten kann.
- 6. Mehr Druck Mittwoch, 6.November 13 Zunächst hat er versucht, mehr Druck auf seine Mitarbeiter auszuüben und sie damit zu mehr Leistung zu bewegen. Das hat die Entwicklung leicht beschleunigt, aber leider die Qualität reduziert, so dass die Entwicklung inkl. Fehlerbeseitigung am Ende sogar länger dauerte als vorher.
- 7. Scrum und Kanban Mittwoch,6. November 13 Dann hat Manni von Scrum und Kanban erfahren und Ansätze daraus in seine Abteilung gebracht. Der Stress bei den Mitarbeitern reduzierte sich, es wurde stärker kooperiert und die Produktivität und Qualität stieg. Außerdem konnte er jetzt die Leistungsfähigkeit seine Abteilung explizit benennen und dadurch professioneller mit den Anforderungen der Fachabteilungen umgehen.
- 8. Manni, your softwaresucks! Mittwoch, 6. November 13 Jetzt wurde sichtbar, dass die entwickelten Systeme häufig gar nicht so nützlich waren und auch die Fachabteilungen mit den Systemen nicht richtig glücklich waren. Obwohl Mannis Mannen (und Frauen) ja entwickelt hatten, was die Fachabteilungen sich gewünscht hatten.
- 9. Lean Startup Mittwoch, 6.November 13 Irgendwann stieß Manni zufällig auf Lean-Startup und las das Buch „The Lean Startup“ von Eric Ries. Manni war fasziniert. Konnte Lean-Startup ihm helfen, Software zu entwickeln, die für die Fachabteilungen wirklich nützlich wären?
- 10. „A startup isa human institution designed to create a new product or service under conditions of extreme uncertainty.“ Eric Ries Mittwoch, 6. November 13 Mannis IT-Abteilung ist sicherlich kein klassisches Startup. Aber Eric Ries hat eine deutlich breitere Definition eines Startups. Manni dachte daran, wie häufig die entwickelte Software wenig oder keinen Mehrwert schaffte. Seine Abteilung entwickelte also auch unter Bedingungen großer Unsicherheit. Folglich müsste Lean-Startup auch für ihn anwendbar sein.
- 11. Entrepreneur Mittwoch, 6. November13 Wenn seine Abteilung ein Startup ist, dann wäre er wohl ein Entrepreneur. Manni ließ diesen Gedanken ein wenig auf sich wirken und betrachtete ihn aus verschiedenen Richtungen. Manni der Entrepreneur. Das fühlte sich gut an.
- 12. Können wir dieSoftware entwickeln? Sollten wir die Software entwickeln? Mittwoch, 6. November 13 Klassisch sah man das Hauptrisiko bei der Software-Entwicklung bei der Umsetzung. Konnte man die Software überhaupt bauen und wenn ja in welcher Zeit zu welchen Kosten? Laut Lean-Startup sollte heute die vorherrschende Frage sein, ob man die Software überhaupt bauen sollte. Adressiert die Software echte Kundenbedürfnisse, so dass sich daraus ein Business entwickeln kann. Das mit den Kundenbedürfnissen leuchtete Manni sofort ein. Sie hatten so oft an den eigentlichen Bedürfnissen der Fachabteilungen vorbei entwickelt.
- 13. Manni, your softwaresucks! Check assumptions! Mittwoch, 6. November 13 Lean-Startup sagt, dass wir ständig Annahmen darüber treffen, was die Systembenutzer wirklich brauchen und wie diese Bedürfnisse am Besten adressiert werden können. Wir sollten auf Basis dieser Annahmen keine großen Systeme entwickeln. Stattdessen sollten wir unsere Annahmen explizit machen und dann prüfen.
- 14. Check assumptions! Build Learn Measure Mittwoch, 6.November 13 Lean-Startup nutzt die wissenschaftliche Methode, um Annahmen zu überprüfen. Man beginnt mit der Annahme also dem, worüber man etwas lernen möchte. Jetzt überlegt man sich, wie man feststellen/messen kann, ob die Annahmen stimmt oder nicht. Und jetzt überlegt man sich, was man minimal bauen muss, um die Annahme zu überprüfen.
- 15. Check assumptions! Ideas Build Learn Data Code Measure Mittwoch, 6.November 13 Und dann wird der Build-Measure-Learn-Zyklus vorwärts durchlaufen, um das Experiment auszuführen und zu lernen.
- 16. Check assumptions! Build-Measure-Learn Ideas Build Learn Data Code Measure Mittwoch, 6.November 13 Also erzählte Manni den Fachabteilungen von Lean-Startup. Er sagte Ihnen, dass sie ihre Annahmen überprüfen müssten und dass er ihnen dabei helfen würde.
- 17. Check assumptions! Build-Measure-Learn Ideas Build Learn Data Code Measure Mittwoch, 6.November 13 Aber die Fachabteilungen fragten sich nicht, welche Annahmen, sie überprüfen sollten. Sie fragten sich, was der IT-Leiter geraucht hätte. Schließlich würden sie ihre eigene Arbeit verstehen und wüssten sehr genau, was ihre Probleme wären. Warum sollten sie vorher nochmal mit wissenschaftlichen Experimenten prüfen, ob ihre Probleme real wären.
- 18. Henry Ford: „Wennich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt: ,schnellere Pferde‘.“ Mittwoch, 6. November 13 Manni war ratlos. Dann stieß er auf ein interessantes Zitat von Henry Ford. Das bedeutet doch, dass die Kunden selbst nicht unbedingt mit innovativen Ideen ankommen.
- 19. Kano-Modell Mittwoch, 6. November13 Manni erinnerte sich an das Kano-Modell der Kundenzufriedenheit. In diesem Modell werden drei Arten von Anforderungen/Features unterschieden. Die Leistungsfeatures („performance“) sind die, die die Kundenzufriedenheit linear steigern. Je mehr, desto besser. Für diese Features können die Kunden direkt Anforderungen formulieren. Dann gibt es noch die Basisanforderungen. Diese werden im System erwartet, häufig aber gar nicht explizit formuliert. Wenn sie fehlen, ist der Schaden aber sehr groß. Und dann gibt es noch die Begeisterungs-Features (delight). Diese werden von den Kunden nicht erwartet und können daher von ihnen auch nicht angefordert werden. Fords Zitat bezog sich auf Begeisterungsfeatures.
- 20. Kano-Modell Lean Startup häufige Produktdemos, z.B. Scrum Mittwoch, 6.November 13 Und Manni erkannte: Für Leistungsfeatures ist es in der Tat nicht besonders nützlich. Man würde seine Annahmen vermutlich zum überwiegenden Teil bestätigt finden. Und bisher hat man mit den Fachabteilungen in erster Linie auf der Ebene von Leistungsanforderungen interagiert. Häufige Produktdemos können helfen, sicherzustellen, dass die Leistungsanforderungen in geeigneter Form umgesetzt wurden.
- 21. Kano-Modell Lean Startup häufige Produktdemos, z.B. Scrum Lean Startup häufige Produktdemos Mittwoch, 6.November 13 Bei den Basisanforderungen ist ebenfalls nicht das Hauptproblem, dass Annahmen nicht zutreffen würden. Das Problem ist, dass sie nur unterbewusst vorhanden sind und daher nicht genannt werden. Wenn sie erstmal explizit gemacht wurden, ist i.d.R. sofort klar, ob und in welcher Form sie benötigt werden. Fehlende Basisanforderungen können gut durch frühe und häufige Produkt-Demos (ggf. mit Prototypen) entdeckt werden, z.B. indem man Scrum verwendet.
- 22. Kano-Modell Lean Startup Lean Startup häufige Produktdemos, z.B. Scrum Lean Startup häufige Produktdemos Mittwoch, 6.November 13 Die Ideen für Begeisterungsanforderungen müssten aber woanders oder auf andere Art entstehen als heute. Und dann könnte man Lean-Startup vermutlich sehr gut einsetzen, um zu prüfen, ob die generierten Ideen etwas taugen.
- 23. Lean-Startup != Innovation Mittwoch,6. November 13 Allerdings ist Lean-Startup kein Ansatz, um innovative Ideen zu generieren. Lean-Startup hat lediglich den Anspruch, schlechte Ideen, schnell als solche zu entlarven. Zunächst müsste man also herausfinden, wie man zu diesen innovativen Ideen/Begeisterungsfeatures kommt. Also vertiefte sich Manni wieder in Bücher und das Internet.
- 24. Design Thinking, InnovationGames, Participatory Design „Group Genius“ Mittwoch, 6. November 13 Und er fand neue Ansätze wie Design-Thinking und Innovation Games sowie deutlich ältere Ansätze wie Participatory Design. Was allen diesen Ansätzen gemein ist, ist die enge Kooperation zwischen verschiedenen Disziplinen wie Fachabteilungen und Entwicklern. Und er las das Buch „Group Genius“, das mit vielen Studien erklärte, warum die Kooperation für Innovation so wichtig ist.
- 25. Innovation Mittwoch, 6. November13 Also erklärte Manni den Fachabteilungen und den Entwicklern kooperative Innovationstechniken und brachte Fachabteilungen und Entwickler zusammen, in der Hoffnung, dass sie dann Ideen für Begeisterungsfeatures entwickeln würden. Tatsächlich entwickelten sich viele neue Ideen, viel mehr als man jemals umsetzen könnte. Also beschloss Manni, Lean-Startup-Techniken zu verwenden, um die schlechten Ideen auszusieben.
- 26. MVP: Minimum ViableProduct VP M „The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.“ Eric Ries Mittwoch, 6. November 13 Um Ideen zu testen, bietet Lean-Startup das Konzept des Minimum Viable Product (MVP).
- 27. hoch MVP-Typen Das Produkt Concierge MVP Produkttreue SoftwarePrototyp Beta Video Papier-Prototyp Papier-Skizze niedrig Feature Fake Interview AdWords-Anzeige wenige Reichweite viele Stefan Roock Mittwoch, 6. November 13 Manni fand heraus, dass es viele verschiedene MVP-Typen gibt. Einige sind sehr schnell und einfach herzustellen und haben daher vielleicht kaum Ähnlichkeit mit dem späteren Produkt (z.B. Papier-Prototyp). Mit anderen kann man sehr viele potenzielle Kunden erreichen (z.B. AdWords). Dafür wird der Feedback-Kanal dünner. Mit MVPs, die eine sehr große Reichweite haben, kann man nur herausfinden, ob Kunden auf den MVP ansprechen oder nicht. Wenn sie nicht ansprechen, kann man aber nur schlecht herausfinden, warum nicht. Insbesondere die MVPs mit hoher Reichweite bei geringer Produkttreue schienen Manni für sein Vorhaben wenig geeignet. Er hat eine prinzipiell überschaubare Menge von Kunden/Anwendern. Diese können in die hunderte gehen, aber selten in die zig-tausende. Und er hat die E-Mail-Adressen und Telefonnummern der potenziellen Kunden/Anwender.
- 28. Manni, your softwarestill sucks! Mittwoch, 6. November 13 Mannis Entwickler arbeiteten mit Interviews und Papier-Prototypen, um ihre Ideen/Begeisterungsfeatures zu validieren. Die Fachabteilungen sprachen darauf an und die Entwicklung begann. Erstaunlicherweise waren die Anwender mit dem dann gelieferten System immer noch nicht richtig zufrieden.
- 29. ? Mittwoch, 6. November13 Manni war verwirrt. Nun hatten sie alle ihre Annahmen mit MVPs validiert und trotzdem war die Software kein Erfolg. Was hatte er übersehen? Da erinnerte sich Manni an eine Problem-Klassifikation von Lehman aus seinen Studienzeiten.
- 30. Lehman: S-Probleme (S= Specification) Problem z.B. QuadratzahlBerechnung Specification formaler Korrektheitsbeweis möglich Program formaler Korrektheitsbeweis möglich Mittwoch, 6. November 13 S-Probleme (sogenannte Spezifikationsprobleme) sind welche, zu denen man eine vollständige Spezifikation erstellen kann. Die Spezifikation kann man dann in ein Programm überführen. Man kann formal beweisen, dass die Spezifikation korrekt ist und dass das Programm der Spezifikation entspricht. Mathematische Berechnungen wie die Quadratzahl-Berechnung sind S-Probleme.
- 31. Lehman: P-Probleme (P= real world Problems) Heuristik notwendig Problem Specification Program z.B. Schach formaler Korrektheitsbeweis unmöglich formaler Korrektheitsbeweis möglich Validierung unter Laborbedingungen Mittwoch, 6. November 13 P-Probleme (sogenannte Real-World-Problems) unterscheiden sich von S-Problemen dadurch, dass der Problembereich zu umfangreich ist, um ihn komplett in einer Spezifikation auszudrücken. Daher muss man beim Erstellen der Spezifikation Heuristiken anwenden. Ein Beispiel ist ein Schach-Programm. Theoretisch könnte man eine vollständige Spezifikation erstellen, die alle möglichen Zug-Kombinationen durchrechnet. Das würde für die Praxis aber zu lange dauern und daher nimmt man bestimmte Abkürzungen vor und rechnet nur die erfolgsversprechendsten Züge durch. Für die Überführung der Spezifikation in das Programm kann man einen formalen Korrektheitsbeweis durchführen. Der ist aber nur von begrenztem Wert, weil man nicht theoretisch prüfen kann, ob die Spezifikation ein angemessenes Modell des Problems darstellt. Das gelingt nur dadurch, dass man das Programm ausführt und darüber validiert, dass Spezifikation und Program angemessen sind. Diese Validierung kann unter Laborbedingungen stattfinden (z.B. indem man gegen das Schachprogramm spielt).
- 32. Lehman: E-Probleme (E= Embedded problems) Problem z.B. Software zur Optimierung interner Sachbearbeitung Specification Program ung im li dier Va etrieb Echtb Mittwoch, 6. November 13 E-Probleme (sogenannte Embedded Problems) teilen mit den P-Problemen die Unsicherheit bei der Erstellung der Spezifikation. Im Gegensatz zu P-Problemen, reicht eine Validierung unter Laborbedingungen aber nicht mehr aus. Das Program wird in der Problemdomäne eingesetzt und verändert sie. Die dadurch entstehenden Effekte kann man nicht sicher vorhersehen. Daher kann die endgültige Validierung immer erst im Echtbetrieb erfolgen.
- 33. System einsetzen frühund häufig Mittwoch, 6. November 13 Jetzt fiel es Manni wie Schuppen von den Augen. MVPs sind gut und schön. Bei E-Problemen (und damit hat Manni es fast ausschließlich zu tun) müssen zusätzlich möglichst früh echte Systemversionen in den Echtbetrieb gebracht werden - und sei es nur für einen Teil der Anwender. Nur so kann man abschätzen, welche Effekte auftreten werden und welche Modifikationen an der Software noch notwendig sind. Lean-Startup ergibt also nur mit einer kurzzyklischen Entwicklungsmethode wie Scrum Sinn und auch nur dann, wenn Produktinkremente häufig eingesetzt werden. Jetzt hatte Manni ein rundes Bild. Er war zufrieden.
- 34. hoch einige MVPs können Feedbackaus dem Produktivbetrieb liefern Das Produkt Concierge MVP Produkttreue Software Prototyp Beta Video Papier-Prototyp Papier-Skizze niedrig Feature Fake Interview AdWords-Anzeige wenige Reichweite viele Stefan Roock Mittwoch, 6. November 13 Neben dem echten Produkt sind insbesondere Concierge MVP und Beta-Versionen sind geeignet, um Feedback aus dem Produktivbetrieb zu erhalten.
- 35. Der Traum istaus... ...die Vision treibt an! Mittwoch, 6. November 13 Und dann wachte Manni aus seinen Tagträumen auf. Jetzt hatte er eine Vision: Fachabteilungen und Entwickler würden kooperieren, um Software zu entwickeln, die echte Bedürfnisse adressierte und für das Unternehmen einen merklichen Unterschied ausmachen würden. Die Fachabteilungen würden sich über neue Software freuen und die Entwickler Stolz auf ihre Arbeitsergebnisse sein. Und der Vorstand würde die IT nicht mehr als Kostenfaktor sehen, sondern als wichtigen Faktor der Wertschöpfung. Und neben dieser Vision hatte Manni und einen sehr, sehr langen Weg vor sich. Und je mehr er über die Vision nachdachte, desto länger erschien ihm der Weg.
- 36. Wir müssten uns ernsthaftfür den Kunden interessieren. Vertrieb Dev Abteilungszweck (KPI) Marketing Wert für Kunden Mittwoch, 6. November 13 Test ...
- 37. Ein langer Weg... •Kulturwandel • Kulturwandel • Kulturwandel • Strukturen anpassen • Prozesse anpassen Mittwoch, 6. November 13 Fachabteilungen und Entwickler würden nicht einfach so miteinander kooperieren. Dafür wäre ein Kulturwandel notwendig. Fachabteilungen und Entwickler würden ihre eigenen Ideen nicht einfach so in Frage stellen und mit Experimenten überprüfen. Dafür wäre ein Kulturwandel notwendig. Die Wertschöpfung für das Unternehmen müsste einen größeren Stellenwert haben als lokale Optimierung von Abteilungen und politische Spielchen. Dafür wäre ein Kulturwandel notwendig und vermutlich müsste man auch Strukturen anpassen. Fachabteilungen und Entwickler müssten zunächst kooperativ miteinander arbeiten, um zu innovativen Ideen zu kommen - bevor es Fachkonzepte oder Lastenhefte gibt. Das müsste möglich sein, ohne den heute üblichen schwerfälligen Budget-Bewilligungsprozess zu durchlaufen. Dafür wären Änderungen an den internen Unternehmensprozessen notwendig.
- 38. Ein langer Weg... •Kulturwandel • Kulturwandel • Kulturwandel • Strukturen anpassen • Prozesse anpassen „Um das Mögliche zu erreichen, müssen wir das Unmögliche versuchen.“ Hermann Hesse Mittwoch, 6. November 13 Diese ganzen Änderungen... Das schlug Manni gewaltig auf die Stimmung. Aber dann erinnerte er sich an ein Hermann-Hesse-Zitat: „Um das Mögliche zu erreichen, müssen wir das Unmögliche versuchen.“ Das gab ihm wieder Mut und er entschloss, sich der Aufgabe zu stellen.
- 39. Entrepreneur Change Agent Mittwoch, 6.November 13 Manni wurde klar: Er würde absehbar kein Entrepreneur im Unternehmen werden. Zunächst müsste er ein Change Agent werden, um die Änderungen im Unternehmen zu bewirken, die notwendig sind, um Lean-Startup überhaupt einsetzen zu können.
- 40. „Veränderungen? Kann ichschon!“ Mittwoch, 6. November 13 Glücklicherweise war das keine ganz neue Aufgabe für Manni. Mit der Einführung von Scrum und Kanban für die Entwicklung hatte er bereits Veränderungen der Strukturen und Kultur in seiner Abteilung eingeleitet. Prinzipien von Scrum und Kanban auf der nächsthöheren Ebene sollten beispielsweise geeignet sein, um die Kooperation zwischen Fachabteilungen und Entwicklern noch weiter zu stärken - auch schon vor der eigentlichen „Auftragserteilung“ durch die Fachabteilung. Und wenn Manni mit einen Portfolio-Kanban-Board für Transparenz auf Ebene ganzer Projekte oder Initiativen sorgen würde, könnte damit weiteres Vertrauen zu den anderen Managern im Unternehmen aufgebaut werden. Und auf Basis dieses Vertrauens könnten Änderungen am Budget-Prozess doch möglich werden. Aber das ist eine andere Geschichte...
- 41. Die Erlaubnis zumAndersein Mittwoch, 6. November 13 Ein Weg, den Unternehmen erfolgreich gehen, läuft über Inkubatoren: Es wird eine Kapsel im Unternehmen etabliert, die die Erlaubnis hat, anders zu sein als der Rest des Unternehmens. In unserem Fall würde man also ein Startup im Unternehmen gründen. Das damit verbundene Risiko kann man über Sandboxing begrenzen: es werden Randbedingungen gesetzt (z.B. in Form von Budget, Team, verfügbarer Zeit und Ziel) und die Akteure in der Sandbox könnten in diesem Rahmen vollkommen frei entscheiden. Das kann man auch dauerhaft installieren, z.B. in Form eine Agile Software Studios.
- 42. Fazit • • • Man muss dieSoftware produktiv nutzen, um die Auswirkungen seriös bewerten zu können (E-Probleme). • Das sollte man bei der Wahl der konkreten MVPs beachten. Lean-Startup ist keine Innovationstechnik, sondern eine effiziente Ideen-Vernichtungsmaschine. Die ergibt nur Sinn, wenn man auch innovative Ideen hat (Begeisterungsanforderungen). Lean-Startup muss mit geeigneten Innovationstechniken kombiniert werden (z.B. Design-Thinking). Die Innovationstechniken funktionieren nur kooperativ. Letztlich führt wohl kein Weg an Organisationsentwicklung vorbei. • Kooperation stärken. • • • Mittwoch, 6. November 13
- 43. Lean Startup imUnternehmen charmant einleuchtend Mittwoch, 6. November 13 totaler Unsinn vielleicht in 10 Jahren?
- 44. Vielen D ank für dieAufm erksamk eit Stefan Rooc k stefan.roock @it-agile.d e Tel. 0172/4 29 76 17 @StefanRo oc k Mittwoch, 6. November 13 Wir beraten Sie gerne in den angesprochenen Techniken: Scrum, Kanban, Portfolio-Kanban, Unternehmensentwicklung, Kulturwandel, Lean-Startup, Design-Thinking, Innovation Games, etc. Sprechen Sie uns an: stefan.roock@it-agile.de, Tel. 0172/429 76 17, http://www.it-agile.de, http:// www.stefanroock.de