ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. RequIREMENTs EngINEERINg Ins Schwarze treffen

Transkript

1 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen OutsourcINg Klare Requirements sind ein Schlüsselfaktor für erfolgreiches Outsourcing BusINEssgETRIEBENE Entwicklung Mit businessgesteuerter Entwicklung zu wegweisenden Produkten MigraTIONEN Requirements Engineering: entscheidende Rolle bei System- und Datenmigrationen TRENDTHEMA Wettbewerbsvorteile dank Nearshoring

2 NEHMEN Sie SiCH ZEIT enables & delivers Das systematische Erheben, Analysieren und Dokumentieren von Anforderungen verursacht Aufwand. Doch die ins Requirements Engineering gesteckte Zeit ist ein gutes Investment. Klare und umfassende Anforderungen garantieren, dass bei Softwareprojekten das von der IT geliefert wird, was vom Business bestellt wurde. Unternehmen, welche diese Disziplin beherrschen, brauchen keine aufwändigen Nachbearbeitungen und sind mit ihren Produkten schneller auf dem Markt. Die am Anfang investierte Zeit wird so mehrfach wieder eingespart. Das ohnehin gute Verhältnis von Investment und Ertrag wird zudem laufend attraktiver. Die zunehmende Komplexität der Produkte und der Trend zum Outsourcing machen das Requirements Engineering noch lohnender und letztlich zur Notwendigkeit. In diesem ERNI Experience stellen wir unsere Erfahrungen zum Thema Requirements Engineering vor. Den Anfang machen wir mit einem Artikel über die Grundlagen des Requirements Engineerings. Der zweite Text erläutert Schritt für Schritt, wie Unternehmen die Prozessreife im Requirements Peter Zuber Business Area Manager bei ERNI Schweiz, Beratungstätigkeit: Process Improvement; Business und IT, Coaching, Workshop-Moderation Engineering erhöhen können, um für Outsourcing gerüstet zu sein. Es folgt ein Bericht mit Erfahrungen und Empfehlungen zur Umstellung von technikgetriebener auf businessgetriebene Entwicklung. Der vierte Artikel widmet sich dem Requirements Engineering bei der System- und Datenmigration. Zu allen Themen des ERNI Experience können Sie seit Juli 2011 noch mehr erfahren. Zu diesem Zeitpunkt hat das Swiss Engineering Institute seinen Betrieb aufgenommen, das wir Ihnen in der Mitte des Heftes vorstellen. Die neue Tochterfirma der ERNI Gruppe bietet Organisationsentwicklungen und Weiterbildungen für Technologieunternehmen und Entwicklungsabteilungen an. Mit seiner Konzentration auf die Bedürfnisse von Ingenieuren besitzt das Institut einen einzigartigen Fokus. Herzlich Peter Zuber

3 EDItORIAl inhalt 2 3 RequIREMENts EngINEERINg Ins SchwaRZE treffen Requirements Engineering: die Grundlagen VON DAVID KuRMANN 4 OutSOuRCINg ScHRITT für ScHRITT zu guten AnfORDERungEN Klare Requirements sind ein Schlüsselfaktor für erfolgreiches Outsourcing VON CéDRIC ESChER und PhilIPP Rey 10 BuSINESSgetRIEbENE EntWICKlung DIE Brücke zwischen Markt und TecHNOlogIE Mit businessgesteuerter Entwicklung zu wegweisenden Produkten VON SIMON ODERMAtt und MARKus RENtSCh 16 MigRAtionen REIBungslos von Alt zu Neu Requirements Engineering spielt bei System- und Datenmigrationen eine entscheidende Rolle VON PetER ZubER und Ugo bonanni 22 Alle Artikel online:

4 Ins SchwaRZE treffen Requirements Engineering: die Grundlagen Im Requirements Engineering werden Anforderungen erarbeitet und über den gesamten Lebenszyklus des Projekts bewirtschaftet. In der Praxis haben sich dabei die Analyse der Anforderungen so wie ein iteratives Vorgehen als besonders wichtig erwiesen. VON DAVID KuRMANN Requirements Engineering ist eine junge Disziplin, die laufend an Gewicht gewinnt. Ihre Bedeutung ist heute erkannt. Es ist klar, dass Anforderungen erhoben, dokumentiert und bewirtschaftet werden müssen, wenn man am Ende von Projekten keine böse Überraschung erleben will. Doch in der Praxis gibt es zahlreiche Herausforderungen, welche die Konsequenz beim Requirements Engineering auf die Probe stellen. Es braucht Zeit und Ressourcen bei den involvierten Stakeholdern. Die Kommunikation muss über verschiedene Grenzen sichergestellt werden. Entscheidungen müssen getroffen werden, was voraussetzt, dass es zu einer Einigung unter den Stakeholdern kommt. Im Verlauf des Projekts ist ein Change Management erforderlich, das die dokumentierten Anforderungen immer auf dem neuesten Stand hält. Um diese Herausforderungen zu meistern, braucht es Wissen und Erfahrung, die in diesem ERNI Experience vermittelt werden. Dieser Artikel stellt zunächst kurz die wichtigsten Begriffe vor und fokussiert dann auf zwei Aspekte des Requirements Engineerings, die sich in der Praxis als zentral herausgestellt haben: die Analyse der Anforderungen und das Durchlaufen mehrerer Iterationen bis zu Anforderungen, die eine stabile Basis für die Entwicklung bilden. Grundsätzlich lässt sich das Requirements Engineering in zwei Teildisziplinen unterteilen: Requirements Management und Requirements Development. Beim Requirements Management geht es um das Bewirtschaften der Anforderungen über den gesamten Lebenszyklus des Projekts hinweg. Zuständig hierfür ist der Projektleiter. Das Ziel ist, Einverständnis zwischen Besteller und Lieferant eines neuen Produkts herzustellen. Das Ergebnis ist eine Art Vertrag, der kontinuierlich überarbeitet und überprüft wird. Das Requirements Management bildet damit die Basis für das Requirements Engineering. Die zweite Teildisziplin ist das Requirements Development, das systematische Erarbeiten der Anforderungen. Verantwortlich ist der Requirements Engineer. Beim Prozess hat sich ein Vorgehen in den vier Schritten Erheben, Analysieren, Spezifizieren und Validieren durchgesetzt (siehe Abbildung 1). Für alle vier Phasen stehen unterschiedliche Methoden zur Verfügung. Beispiel 1 Erhebung und Analyse von Anforderungen in einem Dienstleistungsbetrieb In einem Dienstleistungsbetrieb soll eine neue Version der zentralen Software entwickelt werden. Beim Requirements Development wird mit mehreren Erhebungstechniken gearbeitet. Dazu gehört die Feldbeobachtung. Verschiedenen Nutzern der Software wird bei ihrer täglichen Arbeit über die Schulter geschaut. Dabei wird etwa erhoben, wie sie ihre Aufgaben samt zugehöriger Dokumente organisieren, welcher Arbeitsschritt wie lange benötigt, was der Mitarbeiter selbst erledigt und für welche Aufgaben er Unterstützung in Anspruch nimmt sowie einiges mehr. Mit Vertretern aus verschiedenen Abteilungen, die alle das System benutzen,

5 requirements engineering 4 5 Grundsätzlich lässt sich das Requirements Engineering in zwei Teildisziplinen unterteilen: Requirements Management und Requirements Development. Beim Requirements Management geht es um das Bewirtschaften der Anforderungen über den gesamten Lebenszyklus des Projekts hinweg. Die zweite Teildisziplin ist das Requirements Development, das systematische Erarbeiten der Anforderungen.

6 Beim Requirements Development wird mit mehreren Erhebungstechniken gearbeitet. Dazu gehört die Feldbeobachtung. Verschiedenen Nutzern der Software wird bei ihrer täglichen Arbeit über die Schulter geschaut. Dabei wird etwa erhoben, wie sie ihre Aufgaben samt zugehöriger Dokumente organisieren, welcher Arbeitsschritt wie lange benötigt, was der Mitarbeiter selbst erledigt und für welche Aufgaben er Unterstützung in Anspruch nimmt sowie einiges mehr. Requirements Management Requirements-Listen, änderungsmanagement, Versionsverwaltung, Kundenabnahme Erheben Stakeholderanalyse Interviews/Workshops Feldbeobachtung Kreativitätstechniken Validieren Prototypen (grafisch) Review Entscheidungsfindung Abb. 1: Requirements Engineering Requirements Development Requirements Business Case Business User Requirements System Requirements AnalysIEREN Priorisierung Ebenen von Anforderungen Kano Spezifizieren Textuelle Beschreibung Use Cases Modellbeschreibungen (UML) Businessprozesse (BPMN) System Infrastructure Requirements Technical Requirements Technical Abb. 2: Ebenen

7 requirements engineering 6 7 werden zudem Workshops durchgeführt sowie die zukünftige Nutzung des Systems und die zukünftigen Abläufe besprochen. Erhoben werden sowohl die bestehenden, realen Abläufe in der Praxis als auch die Wünsche der Nutzer in Bezug auf das neue System. Diese Abläufe werden mit Hilfe der Use- Case-Methode dargestellt und mit den verschiedenen Stakeholdern besprochen. Das Vorgehen ist beispielhaft. Eine essenzielle Aufgabe des Requirements Engineerings ist es, zu analysieren, zu welcher der drei Ebenen Business, System oder Technik bestimmte Requirements gehören. Diese Kategorisierung ist notwendig, weil die Stakeholder selbst sie oft nicht berücksichtigen. So äussern Nutzer bei Interviews regelmässig den Wunsch nach einem bestimmten Tool und damit nach einer Lösung und verstehen dies als Anforderung. Technisch versierte Nutzer machen oft Vorschläge, die nicht die Benutzerebene, sondern die Systemebene betreffen. Diese Vermischung ist problematisch, weil für die drei Ebenen verschiedene Verantwortungsträger zuständig sind, verschiedene Stakeholder betroffen sind und sich auch das Umfeld jeweils unterscheidet (siehe Abbildung 2). Zudem sollten nicht vorschnell Entscheidungen auf der technischen Ebene getroffen werden, die dann die Freiheit bei den Systemanforderungen einschränken, und diese wiederum sollten nicht so festgelegt werden, dass sie die Wahl des Business Case einschränken. Die Vermischung lässt sich bereits bei der Erhebung vermeiden. Werden etwa Lösungen von Interviewpartnern genannt, sollte der Analyst nach dem Grund für diesen Vorschlag fragen, bis er zur dahinterstehenden Anforderung vorgedrungen ist.

8 Eine essenzielle Aufgabe des Requirements Engineerings ist es, zu analysieren, zu welcher der drei Ebenen Business, Benutzer oder Technik bestimmte Requirements gehören. Diese Kategorisierung ist notwendig, weil die Stakeholder selbst sie oft nicht berücksichtigen. So äussern Nutzer bei Interviews regelmässig den Wunsch nach einem bestimmten Tool und damit nach einer Lösung und verstehen dies als Anforderung. Technisch versierte Nutzer machen oft Vorschläge, die nicht die Benutzerebene, sondern die Systemebene betreffen. Diese Vermischung ist problematisch, weil für die drei Ebenen verschiedene Verantwortungsträger zuständig sind, verschiedene Stakeholder betroffen sind und sich auch das Umfeld jeweils unterscheidet.

9 requirements engineering 8 9 Für die weitere Analyse hilft die Darstellung der Anforderungen in Modellen wie Aktivitätsgrafiken oder Szenariodiagrammen. Im Beispiel wurden Use Cases benutzt, die den gewichtigen Vorteil besitzen, für alle Benutzer verständlich zu sein. Bei Use Cases ist meist auf den ersten Blick klar, ob der geschilderte Ablauf zur Business-, zur User- oder zur Systemebene gehört. Eine weitere typische Herausforderung besteht darin, dass sich Stakeholder zukünftige Lösungen häufig nicht vorstellen können. Darum sind beim Requirements Engineering Iterationen erforderlich. sondern sich zum Wesentlichen äussern. Je besser man das Requirements Management beherrscht, desto einfacher fallen der Organisation weitere Entwicklungsschritte, um komplexere Vorhaben anzupacken. Auf zwei solche Schritte gehen die folgenden beiden Artikel ein: das Outsourcing von Entwicklungsaufgaben und die Umstellung auf eine businessgetriebene IT. Beispiel 2 Einsatz von Prototypen Ein Industriebetrieb entwickelt eine neue Lösung für die Unterstützung seines Kernprozesses. Das System wird zahlreiche verschiedene Akteure entlang der Wertschöpfungskette unterstützen. Die vielfältigen Erwartungen zu konsolidieren und eine gut abgestützte Entscheidung herbeizuführen, ist nicht ohne Weiteres möglich. In diesem Fall werden die Anforderungen systematisch erhoben, analysiert und spezifiziert. Für die Validierung wird auf dieser Basis ein Prototyp entwickelt. Zu diesem geben die Stakeholder danach Rückmeldungen. Auf diese Weise kann die Qualität der Anforderungen deutlich verbessert werden. Die Beschreibung von grafischen Benutzeroberflächen (GUI) als Prototypen hat sich auch in anderen Projekten bewährt. Wichtig ist in diesem Zusammenhang, dass der vorläufige Charakter des GUI- Prototypen klar ersichtlich bleibt, damit die Stakeholder keine Details kritisieren, ERNI Innovation in Process and Technology DAVID KuRMANN david.kurmann@erni.ch Beratertätigkeit: Training und Coaching, Process Improvement, Requirements Engineering

10

11 OutSOuRCINg Schritt für Schritt zu guten AnfORDERungen Klare Requirements sind ein Schlüsselfaktor für erfolgreiches Outsourcing Viele Unternehmen fragen sich heute, ob ihre Prozessreife ausreicht, um Entwicklungsaufgaben auszulagern. Unsere Checkliste liefert eine Standortbestimmung und gibt gezielte Hinweise zur Erhöhung der Prozessreife. Von CéDRIC ESChER und Philipp Rey Das Auslagern von Entwicklungsaufgaben ist eine bewährte Antwort auf Kostendruck und Ressourcenmangel. Gleichzeitig bringen geografische und kulturelle Distanz Herausforderungen. Bereits im ERNI Experience Nr. 50 wurde darauf hingewiesen, dass die Startphase eine entscheidende Rolle beim erfolgreichen Meistern dieser Herausforderungen spielt. Es müssen eine Reihe von Aufgaben erledigt werden, darunter die Auswahl eines geeigneten Anbieters, die Definition und Einführung von Kommunikationsprozessen oder das Einrichten einer gemeinsamen Infrastruktur. Zu den wichtigsten Erfolgsfaktoren für Outsourcing zählen allerdings unmissverständliche Anforderungen. Die Bedeutung der Requirements ist für Outsourcing-Projekte so gross, weil die Projekte meist nach der Formulierung der Anforderungen übergeben werden (siehe Abbildung 1). Während der Auftraggeber für die Anforderungen zuständig ist, übernimmt der Auftragnehmer das Design und die Implementation. Bei Unternehmen, die einen definierten Requirements-Engineering-Prozess leben, sind die Risiken des Outsourcings deutlich geringer als bei Firmen, in denen dies nicht der Fall ist. Unsere Checkliste ermöglicht eine Standortbestimmung und gibt gezielte Hinweise auf Verbesserungspotenzial. 1. Die Requirements sind detailliert und umfassend dokumentiert In Unternehmen mit internen Entwicklungsabteilungen ist der Detaillierungsgrad von Anforderungen tendenziell eher niedrig. Dies reicht oft aus, weil die fehlenden Details durch die erfahrenen Entwickler ergänzt werden oder es die Möglichkeit zu schnellen, informellen Nachfragen gibt. Bei der Auslagerung von Entwicklungsaufgaben fehlen diese Möglichkeiten. Deswegen müssen die Anforderungen in der Regel umfassender und detaillierter dokumentiert werden. Tipp: Die Stakeholder reviewen die Requirements. Dafür müssen die Anforderungen so formuliert sein, dass sie für alle verständlich sind. 2. Der Scope ist bestimmt Der Schritt in das Outsourcing ist nicht zuletzt deswegen mit umfassenden Vorbereitungen verbunden, weil es nicht möglich ist, mit beliebig kleinen Projekten zu starten. Was ausgelagert wird, muss in sich abgeschlossen sein und getestet werden können. Um die Entwicklung starten zu können, müssen zudem die Schnittstellen definiert sein. Im Projektverlauf müssen dann auch die Umsysteme rechtzeitig bereit sein. Tipp: Der einfachste Weg, ein Teilprojekt mit klar umrissenem Scope auszulagern, besteht darin, auf der Basis der bestehenden Architektur eine Komponente auszuwählen und deren Entwicklung dem Partner zu übergeben. 3. Der Requirements-Engineering-Prozess ist definiert Der Prozess legt fest, wer für welche Dokumente mit welchen Inhalten verantwortlich ist, an wen sich die Dokumente richten und in welchem Zeitrahmen sie zu liefern sind. Die meisten Unternehmen haben heute einen solchen Prozess implementiert. Das Ziel sind reviewte und stimmige Anforderungen als stabile Basis für die Entwicklung. Tipp: Zum Requirements-Prozess gehört auch ein definierter Change-Prozess. 4. Ansprechpartner auf Seiten des Auftraggebers sind für Auskünfte und Entscheidungen verfügbar Outgesourcte Arbeiten brauchen auch beim Auftraggeber Ressourcen. Das Out-

12 Produktrequirements Auftraggeber Auftragnehmer Technische Requirements Software Design Specification Implementation Abb. 1: V-Modell Schnittstelle zu Outsourcing Partner Unittests Integrationstests Systemtests Zu den wichtigsten Erfolgsfaktoren für Outsourcing zählen allerdings unmissverständliche Anforderungen. Die Bedeutung der Requirements ist für Outsourcing- Projekte so gross, weil die Projekte meist nach der Formulierung der Anforderungen übergeben werden. Während der Auftraggeber für die Anforderungen zuständig ist, übernimmt der Auftragnehmer das Design und die Implementation. Bei Unternehmen, die einen definierten Requirements-Engineering-Prozess leben, sind die Risiken des Outsourcings deutlich geringer als bei Firmen, in denen dies nicht der Fall ist. Unsere Checkliste ermöglicht eine Standortbestimmung und gibt gezielte Hinweise auf Verbesserungspotenzial.

13 OutSOuRCINg sourcing-team wird regelmässig Fragen zu den Requirements haben. Können diese nicht zeitnah beantwortet werden, wird die Zusammenarbeit ineffizienter. Zudem muss dem Team alles kommuniziert werden, was für seine Arbeit von Bedeutung ist. Dies kann insbesondere bei Projekten, an denen mehrere, verteilte Teams arbeiten, zu einem nicht zu unterschätzenden Aufwand führen. Schliesslich werden die outgesourcten Teams mit ihren hoch qualifizierten Mitarbeitenden auch regelmässig Vorschläge für Verbesserungen haben. Über solche Anregungen muss ebenfalls zügig entschieden werden können. Tipp: Auftraggeber, die intensiv mit ihrem Outsourcing-Partner kommunizieren, benötigen weniger detaillierte Anforderungen. Beispiel 1 Weniger Aufwand für Requirements Engineering dank Scrum Ein Unternehmen aus der Medizintechnik entwickelt eine Softwareplattform. Einzelne Komponenten werden extern vergeben. Die Firma, die über gute Erfahrungen mit Scrum verfügt, entschliesst sich, auch beim Outsourcing auf Scrum zu setzen. Scrum Master und Product Owner arbeiten dabei beim Auftraggeber. Das Team dagegen befindet sich in Osteuropa. Die Zusammenarbeit bewährt sich. Trotz der geografischen Distanz arbeitet das Gesamtteam effizient. Der Aufwand und damit die Kosten für das Requirements Engineering sind verhältnismässig niedrig. 5. Der Outsourcing-Partner kennt die Besonderheiten der Domäne Wenn Anforderungen wirklich unmissverständlich sein sollten, würden selbst kleinere Projekte ganze Bücher mit Listen benötigen. Der Grund dafür ist das Hintergrundwissen einer Domäne. Bei unternehmensinternen Entwicklungsabteilungen ist dieses Wissen vorhanden und muss deswegen im Anforderungskatalog nicht explizit aufgeführt werden. Werden Aufgaben outgesourct, muss man dieses Wissen dem externen Team vermitteln. Dabei ist einiger Aufwand erforderlich, bis die Entwickler spüren, wie die Auftraggeber denken. Tipp: Bei der Information ist Offenheit gefordert, so kann auch gleichzeitig das Vertrauen zwischen Auftraggeber und Auftragnehmer verstärkt werden.

14 Wer die Vorteile des Outsourcings nutzen will, muss in Sachen Requirements Engineering zu Beginn nicht wenige Hausaufgaben erledigen. Doch der Aufwand lohnt sich. Nicht nur weil man dank Outsourcing zu zusätzlichen Ressourcen kommt und gleichzeitig die Kosten senkt. Werden alle auf der Checkliste genannten Punkte erfüllt, kann die Zusammenarbeit mit externen Teams einen Grad an Effizienz erreichen, der auch für die unternehmensinterne Kooperation einen Massstab darstellt.

15 OutSOuRCINg In Workshops werden die Anforderungen erklärt und das Verständnis auf Seiten der Outsourcing-Partner kontrolliert Auch wenn die externen Entwickler ein Gefühl für die Besonderheiten der Domäne entwickeln, sind Anforderungen grundsätzlich immer noch erklärungsbedürftig. Ob die Entwickler sie verstehen, muss deswegen kontrolliert werden. Tipp: Bei Requirements Workshops darauf achten, dass die Kommunikation in zwei Richtungen läuft. 7. Während der Entwicklung wird mit Kontrollmechanismen überprüft, ob sich das Projekt noch im Rahmen der Anforderungen bewegt Für die Kontrolle sollte in jedem Fall ein Design Review durch den Auftraggeber durchgeführt werden, bevor die Implementation startet. Bei längeren Projekten sollten Milestones vereinbart werden, an denen periodisch die Übereinstimmung der erreichten Ergebnisse mit den Anforderungen überprüft wird. Bewährt hat sich dazu eine Demo der implementierten Applikation. Beispiel 2 Requirements Engineering für einen asiatischen Outsourcing-Partner Ein traditionsreiches Industrieunternehmen entschliesst sich, einen Teil eines neuen Produkts bei einem Tochterunternehmen in Asien entwickeln zu lassen. Um Missverständnisse zu vermeiden, reist ein Experte aus der Schweiz nach Asien. Dieser führt das Entwicklungsteam dort eine Woche lang in die speziellen Anforderungen der Domäne ein. Darüber hinaus finden Requirements Workshops statt. Hierfür reist der Schweizer Requirements Engineer nach Asien. Er erklärt den externen Softwareingenieuren die Anforderungen. Das Team muss anschliessend zur Kontrolle in eigenen Worten wiedergeben, was von ihm verlangt wird. Der Einsatz lohnt sich: Während der Entwicklung kommt es zu weniger Rückfragen. Das Endprodukt ist sehr nah an den Vorstellungen des Requirements Engineers, so dass auch letztlich weniger Rework anfällt. Tipp: Empfehlenswerte Anbieter von Outsourcing-Dienstleistungen führen von sich aus interne Qualitätsprüfungen durch, bei denen ebenfalls die Übereinstimmung der Arbeitsergebnisse mit den Anforderungen überprüft wird. Wer die Vorteile des Outsourcings nutzen will, muss in Sachen Requirements Engineering zu Beginn nicht wenige Hausaufgaben erledigen. Doch der Aufwand lohnt sich. Nicht nur weil man dank Outsourcing zu zusätzlichen Ressourcen kommt und gleichzeitig die Kosten senkt. Werden alle auf der Checkliste genannten Punkte erfüllt, kann die Zusammenarbeit mit externen Teams einen Grad an Effizienz erreichen, der auch für die unternehmensinterne Kooperation einen Massstab darstellt. ERNI Innovation in Process and Technology Philipp Rey philipp.rey@erni.ch Beratertätigkeit: Requirements Engineering, Project Management, Nearshoring CéDRIC ESChER cedric.escher@erni.ch Beratertätigkeit: Software Engineering, Project Management, Nearshoring

16 DIE Brücke zwischen Markt und TecHNOlogIE Mit businessgesteuerter Entwicklung zu wegweisenden Produkten Die Komplexität neuer Produkte lässt sich mit businessgesteuerter Entwicklung beherrschen. Eine Schlüsselrolle spielt dabei das Requirements Engineering. Von Simon Odermatt und MARKus RentSCh Der Spielraum für Innovationen war noch nie so gross wie heute. Die technische Entwicklung ermöglicht immer mehr neuartige Produkte mit einzigartigem Nutzen für die Kunden. Technologieunternehmen mit jahrzehntelanger Tradition beim Einsatz neuester Technologien besitzen gute Voraussetzungen, diese Chance zu nutzen. Ihr technisches Know-how erlaubt es, neue Entwicklungen auf verschiedenen Gebieten zu verfolgen und auf deren Grundlage wegweisende Produkte zu entwickeln. Die Neuentwicklungen sind allerdings auch so komplex wie nie zuvor. Diese Komplexität lässt sich mit einer businessgesteuerten Entwicklung beherrschen. Beispiel 1 Businessgetriebenes Requirements Engineering bei einem Industrieunternehmen Ein Industrieunternehmen entwickelt ein neues System, bestehend aus Elektronik, Mechanik und Software. Um die Entwicklung marktnäher zu gestalten und die Time-to-Market-Spanne zu verkürzen, wird mit dem Projekt ein businessgetriebenes Requirements Engineering eingeführt. Die Einführung beginnt mit der Information der Projektbeteiligten über die Gründe, das Vorgehen und die Dauer des Vorhabens. Anschliessend wird ein massgeschneiderter Prozess für das System Requirements Engineering definiert, wobei insbesondere auf die Interdisziplinarität Rücksicht genommen wird. So werden nach den Ermittlungen der Anforderungen durch das Business etwa interdisziplinäre Anwendungsfälle eingeführt, welche die Systemfunktionen abbilden und gleichzeitig spezifizieren. Die Anwendungsfälle besitzen den Vorteil, dass sie für alle Mitarbeitenden, sowohl aus dem Business wie auch aus den Entwicklungsabteilungen, verständlich sind. Ein wichtiger Vorteil, da die Erarbeitung in Zusammenarbeit von Business und Technik erfolgt. Erst nachdem die einzelnen Anwendungsfälle freigegeben worden sind, erstellen die einzelnen technischen Disziplinen die Designdokumente, wie Konstruktionszeichnungen, Elektroschemas/-Layouts, Softwaredokumente usw. Auf der Basis des neuen Prozesses und mit Hilfe entsprechender Dokumentvorlagen wurde das Requirements Engineering dann durchgeführt. Für die Organisation bedeutete dies einen grossen Schritt, da zuvor pragmatisch aus den Technikabteilungen heraus und somit technikgetrieben entwickelt worden war. Die Umstellung gelang dennoch. Der neue Prozess konnte erfolgreich eingeführt werden und wird von den Mitarbeitenden akzeptiert. Zwei Faktoren sind für den Erfolg einer solchen Umstellung entscheidend. Erstens muss den Beteiligten bewusst sein, dass Initialzeit investiert werden muss und vom effektiven Nutzen erst zu einem späteren Zeitpunkt profitiert werden kann. Im Beispiel nahm allein die Einführung des neuen Prozesses inklusive der Erstellung von Templates vier Monate in Anspruch. Insgesamt dauerte das Projekt rund zehn Monate. Zweitens müssen die Mitarbeitenden von der businessgetriebenen Entwick-

17 BuSINESSgetRIEbene EntWICKlung Die Anwendungsfälle besitzen den Vorteil, dass sie für alle Mitarbeitenden, sowohl aus dem Business wie auch aus den Entwicklungsabteilungen, verständlich sind. Ein wichtiger Vorteil, da die Erarbeitung in Zusammenarbeit von Business und Technik erfolgt. Erst nachdem die einzelnen Anwendungsfälle freigegeben worden sind, erstellen die einzelnen technischen Disziplinen die Designdokumente, wie Konstruktionszeichnungen,Elektroschemas /-Layouts, Softwaredokumente usw.

18 Zwei Faktoren sind für den Start Begriffe und Abkürzungen sammeln Glossar Erfolg einer solchen Umstellung entscheidend. Erstens Business Planung Requirements Engineering erarbeiten Stakeholder, Visionen und Anforderungen ermitteln Requirements- Management-Plan Anforderungskatalog (Basis-Validation) Erfolgt während des ganzen Requirements- Engineering-Prozesses Vision zu Anforderung Nachvollziehbarkeitsmatrix muss den Beteiligten bewusst sein, dass Initialzeit investiert werden muss und vom effektiven Nutzen erst zu einem späteren Zeitpunkt profitiert Zusammenarbeit Business & Development Development System- und Modulspezifikationen darstellen Designdokumente erstellen (technische Dokumentation) System mit Modulen entwickeln Ende System- und Modulspezifikation (Basis-Verifikation) Anforderung zu Spezifikation Hinweis: Zugunsten der Übersichtlichkeit verzichten wir auf die grafische Integration der Iterationspfeile. werden kann. Im Beispiel nahm allein die Einführung des neuen Prozesses inklusive der Erstellung von Templates vier Monate in Anspruch. Insgesamt dauerte das Projekt rund zehn Monate. Abb. 1: Übersicht System Requirements Engineering Beinhaltet: Use-Case-Modell Beschreibung Anwendungsfälle (interdisziplinär) Nicht funkt. Spezifikationen (modulspezifisch) Beinhaltet: Systemübersicht Modulaufteilung Schnittstellenbeschreibung Nicht funkt. Spezifikationen (systemspezifisch) Nicht funktionale Spezifikationen werden an die Module vererbt. Systemspezifikation Modul 1 Spezifikation Modul 2 Spezifikation Modul n Spezifikation Abb. 2: Übersicht Spezifikationsaufteilung

19 BuSINESSgetRIEbene EntWICKlung lung überzeugt werden. Grundsätzlich stehen viele Ingenieure einer solchen Umstellung positiv gegenüber. Denn die Grenzen der technikgetriebenen Entwicklung sind auch ihnen bewusst. Trotzdem müssen sämtliche Mitarbeitenden über die Planung und die Umsetzung des Umstellungsprozesses laufend informiert werden. Insbesondere muss für Verständnis in Bezug auf die grossen Zeiträume bis zum Start der Implementationsphase geworben werden. Bekommen die Techniker diese Information nicht, werden sie in gewohnter Weise von selbst mit der Entwicklung anfangen, ohne auf die Anforderungen des Business zu warten. Zudem gilt es in Firmen, die bisher pragmatisch entwickelt haben, Befürchtungen zu eliminieren, dass das businessgetriebene Requirements Engineering zu einer Papierflut führt. Gleichzeitig kann auf den Nutzen für die Ingenieure hingewiesen werden. So wird zum Beispiel das Testteam entlastet, da das Business nun die Abnahmetests selber durchführen muss. Darüber hinaus sind Anforderungen sauber dokumentiert und bei Weiterentwicklungen oder Folgeprojekten wiederverwendbar; die Nachvollziehbarkeit ist gewährleistet, was auch für Aufsichtsbehörden wichtig ist. Aber auch auf der Businessseite sind Veränderungen notwendig und müssen vom Projektleiter und vom Business Analyst begleitet werden. Bestimmt das Business letztendlich die Anforderungen, müssen die Mitarbeitenden auch bereit sein, die entsprechende Verantwortung zu übernehmen. Vor allem müssen die notwendigen Ressourcen, die das businessgetriebene Requirements Engineering erfordert, eingeplant werden. Beispiel 2 Bessere Kooperation durch Reorganisation Ein Dienstleistungsunternehmen greift nicht auf Standardlösungen zurück, sondern entwickelt seine Kernapplikationen selbst. Auf diese Weise will man sich einen Wettbewerbsvorteil verschaffen. In einem Migrationsprojekt sollen die bestehenden Anwendungen abgelöst werden. Nachdem ein pragmatischer Ansatz nicht zu den gewünschten Ergebnissen geführt hat, wird dem Requirements Engineering Vorlaufzeit gegeben. Gleichzeitig wird eine Reorganisation gestartet. Die Requirements Engineers werden räumlich näher an das Entwicklungsteam gebracht. Dies erleichtert die Kooperation spürbar. Dank Reorganisation und Vorlaufzeit für das Requirements Engineering kann das Projekt erfolgreich zum Abschluss gebracht werden. Der Aufwand, der sich in den ersten beiden Beispielen exemplarisch zeigt, wird kompensiert durch grosse Vorteile. Da das Ergebnis der Entwicklung den Erwartungen des Business entspricht, sind keine Nachbesserungen notwendig. Die Time-to-Market-Spanne verkürzt sich, die Kosten sinken. Darüber hinaus kann der Business Analyst im Prozess auch Gewohnheiten in Frage stellen und damit

20 Gleichzeitig aber werden auch die Vorteile der businessgetriebenen Entwicklung deutlich. Das Business bekommt letztlich genau das Gewünschte und dies innerhalb des vorgegebenen Kostenrahmens. Zudem ist der Prozess sehr robust. Während der Entwicklung kann auf Changes oder Abweichungen optimal reagiert werden. Mit einem solchen Prozess sind Unternehmen deswegen bestens gerüstet für die Entwicklung komplexer Produkte mit einzigartigem Kundennutzen.

21 BuSINESSgetRIEbene EntWICKlung zur Entwicklung innovativer Produkte beitragen. Dies kann etwa Technologien betreffen, mit denen die Techniker bisher keine Erfahrungen hatten. Schliesslich sind die Anforderungen detailliert dokumentiert. Dies erleichtert Tests, aber auch die Weiterentwicklung des Systems sowie diejenige von Umsystemen. Darüber hinaus begrenzen detaillierte Anforderungen auch den Aufwand für das Reverse Engineering bei Migrationen (siehe dazu den Artikel von Ugo Bonanni und Peter Zuber in diesem Experience). Beispiel 3 Businessgetriebene Entwicklung mit hoher Prozessreife In einem Dienstleistungsunternehmen mit hoher Prozessreife steht die Weiterentwicklung eines innovativen Produkts an. Die Gesamtprojektleitung übernimmt ein Mitarbeiter von der Businessseite. Als ersten Schritt legt der Business Owner mit dem Auftraggeber den Funktionsumfang fest und lässt den Aufwand sehr grob abschätzen. Nach dem Projektstart prüft und priorisiert das Business die Features. Danach wird die IT einbezogen, überprüft die Machbarkeit und erstellt eine weitere Aufwandschätzung. Dabei zeigt sich, dass einzelne Features das Projektbudget bei weitem sprengen. Anhand der zuvor festgelegten Priorisierung entscheidet das Business darüber, welche Features realisiert werden sollen und welche nicht. Daraufhin werden die Anforderungen weiter verfeinert. Federführend dabei ist der Business Analyst, der Workshops mit dem Business durchführt und die Anforderungen systematisch dokumentiert. Die IT prüft wiederum Machbarkeit und Kosten. Parallel dazu definiert der Business Analyst bereits die Abnahmekriterien. Gleich zu Beginn der Realisierung erstellt der Business Analyst Abnahmetestfälle. So ist sichergestellt, dass die Abnahme der Software gemäss den festgelegten Anforderungen erfolgt. Während der Realisierung zeigt sich, dass die Umsetzung weniger Ressourcen benötigt als geplant. Der Business Analyst legt mit dem Business fest, was noch zusätzlich realisiert werden soll. Auch bei auftauchenden Changes wird jeweils eine Aufwand-Nutzen-Analyse durchgeführt, bevor jene realisiert werden. Nach der Implementation führt der Business Analyst die Abnahmetestfälle durch und prüft, ob die Applikation den Anforderungen des Business entspricht. Auch in diesem Beispiel brauchte das Erarbeiten der definitiven Anforderungen Zeit und Aufmerksamkeit von vielen Stakeholdern. Dies ist ein mehrstufiger Prozess. Im Beispiel bestimmte man zuerst Projektziele, legte dann Features fest, verfeinerte diese zu Geschäftsprozessen und dann weiter zu Aktivitätsdiagrammen sowie Storybooks, um auf deren Basis schliesslich die Anforderungen zu definieren. Gleichzeitig aber werden auch die Vorteile der businessgetriebenen Entwicklung deutlich. Das Business bekommt letztlich genau das Gewünschte und dies innerhalb des vorgegebenen Kostenrahmens. Zudem ist der Prozess sehr robust. Während der Entwicklung kann auf Changes oder Abweichungen optimal reagiert werden. Mit einem solchen Prozess sind Unter- nehmen deswegen bestens gerüstet für die Entwicklung komplexer Produkte mit einzigartigem Kundennutzen. ERNI Innovation in Process and Technology SIMON ODERMAtt simon.odermatt@erni.ch Beratertätigkeit: Business Unit Leader, Business Analyst, Projektleiter MARKus RentSCh markus.rentsch@erni.ch Beratertätigkeit: Business Analysis, Project Management, Requirements Engineering

22 REIBungslos von ALT zu NEU Das Requirements Engineering spielt bei Systemund Datenmigrationen eine entscheidende Rolle Migrationsprojekte sind komplex und risikoreich. Das Requirements Engineering unterstützt die Realisierung über den gesamten Projektverlauf: vom Reverse Engineering über die Analyse der Anforderungen bis hin zur Planung der Migration und zum Ableiten von Testfällen. VON PetER ZubER und Ugo Bonanni Migrationen gehören heute in Unternehmen zum Alltag. Die Migration eines Systems auf den aktuellen Stand der Technik reduziert die Kosten, erhöht sowohl die Systemverfügbarkeit als auch die Datensicherheit und erlaubt der Firma, sich wieder weiterzuentwickeln. Kurz gesagt: Migrationen stärken die Wettbewerbsfähigkeit. Altsysteme sind dagegen bei der Erweiterungsfähigkeit und Skalierbarkeit eingeschränkt. Hinzu kommen ein aufwändiger Unterhalt und der Betrieb zum Teil obsoleter Hardware. Bei schon länger laufenden Legacy-Systemen ist zudem das Wissen über die Applikation in der Regel unvollständig dokumentiert und falls überhaupt nur in wenigen Köpfen konzentriert. scheidend. Dies gilt erst recht, wenn die neue Version der Software bei einem Outsourcingpartner in Asien oder Osteuropa entwickelt wird. Die systematische Erhebung und Analyse der Anforderungen garantiert, dass das Produkt schliesslich die Geschäftsprozesse wie gewünscht unterstützt. Verzichtet man völlig darauf, besteht die Gefahr, dass erst bei den Abnahmetests Abweichungen entdeckt werden, was unweigerlich zu kostspieligen Anpassungen und zeitlichen Verzögerungen führt. Erfasst werden müssen in jedem Fall nicht nur die neuen Anforderungen, die in die Weiterentwicklung einfliessen sollen, sondern auch die Anforderungen, die mit der bestehenden Applikation erfüllt werden. Deswegen besteht der erste Schritt meist in einem Reverse Engineering. Dementsprechend viel Aufmerksamkeit und Ressourcen werden Anpassungen und Überarbeitungen gewidmet. Dies ist nicht nur wegen deren grosser Bedeutung erforderlich, sondern auch weil Migrationsprojekte komplex sind und wenn sie das Kernsystem betreffen sogar unternehmenskritisch werden können. Wie bei allen komplexen Projekten mit grosser Bedeutung ist auch bei Migrationen das Requirements Engineering ent- Beispiel 1 Reverse Engineering einer Kernapplikation Ein grosses Dienstleistungsunternehmen betreibt im Back Office eine eigens entwickelte Kernapplikation. Diese liest grosse Datenmengen ein, verarbeitet sie mit Hilfe bestimmter Business Rules und verteilt die Ergebnisse an interne Kunden im Unternehmen. Die Anwendung soll weiterentwickelt werden. In einem ers-

23 MigRAtionen Wie bei allen komplexen Projekten mit grosser Bedeutung ist auch bei Migrationen das Requirements Engineering entscheidend. Dies gilt erst recht, wenn die neue Version der Software bei einem Outsourcing-Partner in Asien oder Osteuropa entwickelt wird. Die systematische Erhebung und Analyse der Anforderungen garantiert, dass das Produkt schliesslich die Geschäftsprozesse wie gewünscht unterstützt. Verzichtet man völlig darauf, besteht die Gefahr, dass erst bei den Abnahmetests Abweichungen entdeckt werden, was unweigerlich zu kostspieligen Anpassungen und zeitlichen Verzögerungen führt.

24 Zum Reverse Engineering gehören Workshops mit allen Projektbeteiligten, die wiederum in Kontakt zu den Nutzern stehen. Von besonderer Bedeutung als Informationsquelle sind darüber hinaus diejenigen Mitarbeitenden, die an der Wartung der Applikation arbeiten und deswegen über sehr viel implizites Wissen verfügen. Um die Kommunikation zu erleichtern, sollte der Requirements Engineer früh ein Glossar erstellen, um zu garantieren, dass sämtliche involvierten Mitarbeitenden dieselben Begriffe verwenden. Applikation Alt Systemmigration 1:1 Daten? 1:0 0:1? Abb. 1: Datenmigration mittels Requirements Engineering Applikation Neu Daten

25 MigRAtionen Beispiel 2 Reverse Engineering nach einer Änderung der gesetzlichen Rahmenbedingungen Bei einem Unternehmen aus der Versicherungsbranche ändert sich das gesetzliche Umfeld. Die Änderung betrifft die Leistungsabwicklung und damit das Kernsystem. Zuerst wird versucht, die notwendige Anpassung mit einer neuen Business Rule zu erreichen. Dies hat allerdings Nebenwirkungen zur Folge. Daraufhin führt ein erfahrener Requirements Engineer ein Reverse Engineering durch. Mit der Massnahme kann die Änderung schliesslich erfolgreich umgesetzt werden. Zum Reverse Engineering gehören Workshops mit allen Projektbeteiligten, die wiederum in Kontakt zu den Nutzern stehen. Von besonderer Bedeutung als Informationsquelle sind darüber hinaus diejenigen Mitarbeitenden, die an der Wartung der Applikation arbeiten und deswegen über sehr viel implizites Wissen verfügen. Um die Kommunikation zu erleichtern, sollte der Requirements Engineer früh ein Glossar erstellen, um zu garantieren, dass sämtliche involvierten Schritt wird die vorhandene Lösung mit Hilfe eines Reverse Engineerings analysiert. Dabei werden insgesamt 80 Business Rules identifiziert, zwei unbekannte Schnittstellen zu Umsystemen gefunden und erstmals die unterstützten Geschäftsprozesse dokumentiert. Das Beispiel zeigt treffend, wie wenig explizites Wissen über die vorhandenen Anwendungen in den Organisationen greifbar ist. Oft existieren Dokumentationen, doch in der Regel entsprechen sie nicht dem aktuellen Stand. Schon nach wenigen Jahren haben Changes und neu aufgenommene Business Rules die Applikation so weit verändert, dass eine entsprechend alte Dokumentation kaum noch etwas über den aktuellen Stand aussagt. Deswegen kann man bei Migrationen grundsätzlich nicht mit den Anforderungen arbeiten, die vor Jahren für die Entwicklung einer Anwendung erhoben wurden. Auch wenn das Reverse Engineering verhältnismässig grossen Aufwand verursacht, ist es in sehr vielen Fällen empfehlenswert. Bei einer Migration der Kernapplikation sollte es auf jeden Fall durchgeführt werden.

26 Im Fall von Migrationen erschöpft sich die Rolle des Requirements Engineers nicht nur auf das Erheben und Analysieren der Anforderungen. Vielmehr agiert er als Teilprojektleiter. Dies illustriert noch einmal die grosse Bedeutung des Requirements Engineerings bei Migrationsprojekten. Hat man diese Disziplin im Griff, stehen die Chancen gut, die komplexen Migrationsvorhaben erfolgreich abzuwickeln.

27 MigRAtionen ten Mitarbeitenden dieselben Begriffe verwenden. Bereits in dieser ersten Phase zeigt sich das umfassende Anforderungsprofil, dem ein Requirements Engineer für Migrationen entsprechen muss. Zunächst erfordert die Aufgabe sehr gute kommunikative Fähigkeiten, denn Mitarbeitende, die mit der bestehenden Applikation vertraut sind, haben vielfach keinen Anreiz, ihr Wissen preiszugeben. Auf der fachlichen Ebene muss der Requirements Engineer in der Lage sein, die Applikation zu verstehen, sowohl von der geschäftlichen als auch von der technischen Seite. Dabei muss er sich auch mit Details beschäftigen, zum Beispiel in Sachen Datenmigration, und gemeinsam mit kompetenten Teammitgliedern Lösungen für Probleme finden. Beispiel 3 Problemlösung bei Datenmigration In einem grossen Dienstleistungsunternehmen entspricht ein älteres System nicht mehr den internen Vorgaben in Sachen Technologie und Sicherheit. Es soll deswegen abgelöst werden. Neu soll eine Lösung zum Einsatz kommen, die für etwas andere Zwecke von anderen Nutzern bereits verwendet wird. Gleichzeitig mit der Applikation müssen auch die Daten migriert werden. Bei seinem Reverse Engineering bemerkt der Requirements Engineer, dass die bestehende und die geplante, neue Applikation unterschiedliche Datenmodelle verwenden. Die Ergebnisse beider Systeme sehen zwar auf den ersten Blick gleich aus. Jedoch zeigt eine detaillierte Analyse auf, dass sie auf unterschiedlichen Datenquellen beruhen, was bei der Einführung des neuen Systems zu kritischen Fehlern führen würde. Der Unterschied ist von Bedeutung, da das Ergebnis juristisch relevant ist. Der Requirements Engineer entwickelt deswegen zusammen mit dem Fachbereich eine Lösung, die sicherstellt, dass beide Applikationen bei derselben Faktenlage zu einem identischen Ergebnis kommen. Das Beispiel schildert ein bei der Datenmigration typisches Problem, nämlich die Unterschiede in der Kardinalität zwischen den Entitäten der neuen und der alten Daten. Doch das Beispiel zeigt nicht nur in Bezug auf die Datenmigration einen wichtigen Punkt auf. Auch allgemein besteht bei Migrationen eine Herausforderung darin, dass Neues auf Altes trifft. Dies gilt auch für die Anforderungen. Die bestehende Applikation soll schliesslich nicht einfach abgelöst, sondern auch verbessert werden. Sämtliche Anforderungen müssen insbesondere auf Konsistenz überprüft werden. Das Verhalten des neuen Systems wird sich vom Verhalten des alten Systems unter Umständen deutlich unterscheiden. Erst wenn die Requirements in ihrer Gesamtheit als konsistente und abgeschlossene Einheit vorliegen, können die nächsten Projektschritte angegangen werden. Erst auf dieser Basis ist es möglich, Testfälle zu schreiben und die Entwicklung der neuen Applikation zu starten. Deswegen sollte der Requirements Engineer in beiden Fällen am Go-Entscheid beteiligt sein. Das vom Requirements Engineer gesammelte Wissen über die bestehende Applikation ist zudem von Bedeutung für die Planung der eigentlichen Migration. Von den bestehenden Möglichkeiten Big Bang, Parallelbetrieb oder gestaffelte Ablösung wird häufig die dritte Variante gewählt, weil sie die Risiken minimiert. Für die schrittweise Ablösung ist es allerdings notwendig, die Abhängigkeiten der neuen Applikation von den Umsystemen zu berücksichtigen. Im Fall von Migrationen erschöpft sich die Rolle des Requirements Engineers nicht nur auf das Erheben und Analysieren der Anforderungen. Vielmehr agiert er als Teilprojektleiter. Dies illustriert noch einmal die grosse Bedeutung des Requirements Engineerings bei Migrationsprojekten. Hat man diese Disziplin im Griff, stehen die Chancen gut, die komplexen Migrationsvorhaben erfolgreich abzuwickeln. ERNI Innovation in Process and Technology Peter Zuber peter.zuber@erni.ch Beratertätigkeit: Process Improvement Business und IT, Coaching, Workshop-Moderation Ugo Bonanni ugo.bonanni@erni.ch Beratertätigkeit: Requirements Engineering, Project Management

28 Trendthema NearsHORINg Wie erfolgreiche Unternehmen zunehmende Herausforderungen und Kostendruck meistern. Die Vorteile der Auslagerung von Entwicklungsausgaben nach Osteuropa sind immer dieselben: günstige Kosten und verfügbares, hochqualifiziertes Personal. Doch wie das Nearshoring gestaltet sein muss, um die Vorteile zu nutzen, dies unterscheidet sich von Projekt zu Projekt. PROJEKT SEtuP Einstieg nach Mass wie sich die HERausfORDERungEN des NearsHORINgs meistern lassen Lesen Sie im ERNI Experience Nr. 50 unterschiedliche Praxisbeispiele, die ein optimales Vorgehen beim Auslagern von komplexen Projektvorhaben aufzeigen. Nearshoring wird für innovative Unternehmen zur Notwendigkeit. Den Chancen stehen allerdings auch Risiken gegenüber. Diese lassen sich durch ein geeignetes Kooperationsmodell und eine bewusst eingeplante Startphase in den Griff bekommen. ERNI Innovation in Process and Technology

29 trendthema nearshoring Flexibilität mit Struktur IntERNAtIONAle PROJEKte Führung ohne Grenzen Nearshoring unter Zeit- und Kostendruck BEI INDusTRIEuNTERNEHMEN ist PragmaTIsmus gefragt Agil, kompetent und günstig NearsHORINg anspruchsvoller ProjekTE Führen auf Distanz am besten mit System TranspaRENZ als Basis für Ver- TRauEN Die Steigerung der Prozessreife erleichtert den Einstieg in das Nearshoring. Doch für aufwändige Prozessverbesserungen fehlen in vielen innovativen Unternehmen Zeit und Ressourcen. Die Lösung ist ein pragmatisches Vorgehen, das sich im engen Zeit- und Kostenrahmen umsetzen lässt und dennoch die Vorteile des Nearshorings zuverlässig erschliesst. ERNI Innovation in Process and Technology Bei der Auslagerung von Entwicklungsprojekten ist man weder bei der Aufgabenstellung noch in der Methodenwahl eingeschränkt. Mit dem richtigen Vorgehen lassen sich auch agile Methoden wie Scrum nutzen und Aufgaben wie das Design einer Komponente outsourcen. ERNI Innovation in Process and Technology Nearshoring spart Kosten. Dies allerdings nur, wenn die Mitarbeitenden im Ausland ähnlich produktiv sind wie diejenigen in der Schweiz. Erreichen lässt sich dies durch die richtige Führung. Sie ist gekennzeichnet durch ein Führungssystem sowie intensive und transparente Kommunikation. ERNI Innovation in Process and Technology

30 enables & delivers IMPREssum Herausgeber ERNI Management Services AG Zürich Bern Baar Lausanne München Frankfurt Barcelona Bratislava Redaktion Adela Papajová ERNI (Slovakia) s.r.o. Tel leserservice@erni.ch Lektorat Stefan Kyora, Mediacontact GmbH, Luzern Ruedi Häuptli, Sprachagentur Bahia, Salvador BR Konzept/Layout Dieter Nafzger Katarína Beinrohrová Produktion von Ah Druck AG, Sarnen Auflage Expl. dt., 2500 Expl. fr. Erscheint quartalsweise Copyright 2011 by ERNI Management Services AG Alle Rechte vorbehalten.

31

32 enables & delivers