Infobest-Blog

In den vergangenen Wochen und Monaten hatte ich zahlreiche Gespräche mit Verantwortlichen aus dem Bereich Software-Entwicklung.  Besonders interessant dabei war, daß viele Gesprächspartner ein gemeinsames Problem zu teilen scheinen: Die gängigen Entwicklungsmodelle mit dem klassischen Wasserfall-Ansatz (Analyse, Design, Entwicklung, Test, Implementierung) scheinen oft zu kurz zu greifen. Selbst in “dynamisierter” Form mit entsprechenden Iterationsschleifen lösen sie folgendes grundsätzliches Problem nicht: In der Analyse-Phase sind die zukünftigen Anwender einer Software kaum in der Lage sind, ihre Anforderungen präzise und vollständig zu formulieren. Ihnen fehlt zudem häufig die Vorstellungskraft, “was man so alles mit IT machen kann”. Aus diesem Grund liefert die anschließende Entwicklung auf der Grundlage dieses lückenhaften Anforderungsprofils nur eine mangelhafte Software, die permanent nachgebessert und erweitert werden muß.

Andererseits hat keiner meiner Gesprächspartner Zuflucht in agile Methoden gesucht, was meine erste Vermutung gewesen wäre. Nicht, daß agile Methoden per Definition das Allheilmittel wären, es wäre aus meiner Sicht nur eine naheliegende Antwort auf das Problem gewesen. Ich würde daher sehr gerne die Meinungen von möglichst vielen Betroffenen kennen und würde mich über Gedankenansätze und Anregungen an dieser Stelle freuen.

• Nach welchem Modell entwickeln Sie Software?

• Wie lösen Sie das Problem unzureichender Anforderungsanalysen?

• Oder kennen Sie dieses Problem gar nicht?

• Was halten Sie von Scrum und anderen agilen Methoden?

Vielleicht die spannendste Frage überhaupt: Woran scheitern häufig Nearshore-Projekte? Wir hatten in Teil 1 schon im Groben resumiert, welches die wesentlichen Voraussetzungen für die Machbarkeit und den Erfolg von Nearshore-Projekten sind. Sie erinnern sich: Spezifizierbarkeit des Projektes, Organisationsgrad bzw. Verständnis für Entwicklungsmodelle und Projektmanagement sowie vernünftige Kommunikation stehen sicher ganz weit vorne.

Es gibt jedoch einen weiteren sehr wesentlichen Aspekt, der auch dann extremen Einfluß auf ein Nearshore-Projekt nehmen kann, wenn die besten Voraussetzungen geschaffen wurden und alle Beteiligten guten Willens und froher Natur sind: die Kontinuität.

Aha, was meint er denn damit? Vielleicht am einfachsten ein paar Geschichten aus dem Nähkästchen:

• Im Verlaufe des Projektes wechselt der Kunden-Projektleiter. Es gibt keine wirkliche Übergabe und kein Briefing auf Kunden-Seite. Der Lieferant weiß nicht so recht, wie er mit der Situation umgehen soll, da der neue Projektleiter ein erklärter Nearshore-Skeptiker ist. Und getreu dem Modell der “self-fulfilling-prophecy” nimmt das Schicksal natürlich seinen Lauf. Der schlaue Lieferant denkt an das Handbuch zur Lösung schwieriger Aufgaben und versucht natürlich, als erstes ein Kennenlern-Gespräch mit dem neuen Verantwortlichen zu führen. Dieser möchte aber nicht, keine Zeit, darum kümmern sich “meine Leute”, ich muß mich erst einarbeiten. Davon steht im Handbuch leider nichts.
• Das Projekt steuert auf seinen Höhepunkt zu, nur noch wenige Tage bis zur ersten Lieferung an den Kunden. Da fällt diesem ein, daß noch “schnell mal eben” eine kleine Änderung gemacht werden muß. Design Freeze hin oder her, dieser Punkt ist für den Business Case unglaublich wichtig, der CIO wetzt schon die Messer und wenn das nicht gemacht werden kann, dann ist der Lieferant wohl zu unflexibel und überhaupt hat man ja gleich bezweifelt, daß Nearshore etwas Gescheites ist wegen der Flexibilität und jeder deutsche Lieferant wäre da sicher einsichtiger…. die Dinge nehmen ihren Lauf, diese kleine Änderung betrifft einen Teil des Codes, der bereits durch den kompletten Funktionstest gelaufen ist und für einen umfangreichen Regressionstest reicht weder Zeit noch Aufwand, denn der Kunde besteht natürlich auf pünktliche Lieferung.
• Zu Beginn des Projektes werden akribisch genau die verantwortlichen Personen, ihre Rollen, Funktionen und Kompetenzen im Projekt definiert und sämtliche Spielregeln für Kommunikation festgelegt. Anstatt aber die ersten CRs wie vereinbart durch den CR-Verantwortlichen im Projektportal gesondert zu protokollieren, schreibt der Kunden-Projektleiter alle Änderungswünsche in einzelne Mails hinein. Anfangs macht sich der Lieferant noch die Mühe, die Punkte herauszukopieren, aber irgendwann wird auch das zu aufwändig. Man spricht den Kunden darauf an, dieser zeigt sich einsichtig, bleibt aber trotzdem bei seinen Mails. Weil eben die Zeit für aufwändigere Dokumentation fehlt. Soll sich der Lieferant darüber beschweren und auf dem vereinbarten Change Management Prozeß bestehen? Und was, wenn es dennoch nichts nützt? Spannend wird ein solches Thema traditionell immer dann, wenn CRs gesondert abgerechnet werden sollen…

Ich denke Sie erkennen, worauf ich hinaus will. Vernünftige Spielregeln zu vereinbaren ist das eine, sie in der täglichen Arbeit auch umzusetzen, das andere. Natürlich stehen hier beide Projektpartner gleichermaßen in der Pflicht, aber es liegt in der Natur solcher Beziehungen, daß sich ein Lieferant schwerer damit tut, seinen Kunden “bei der Stange” zu halten als umgekehrt. Das schöne Sprichtwort gilt letztendlich auch hier: nobody has ever won an argument with a customer…

Aber lassen wir keinen falschen Eindruck entstehen: Ich habe sehr viele sehr gute Projekte gesehen, und wenn das nicht auch die überwiegende Mehrheit der Projekte wäre, würde es wohl kein Nearshoring und keine Nearshore-Lieferanten geben.  Aber glatt laufende Projekte sind wenig spannend und wir wollten ja auch ein wenig über das Scheitern sprechen…

Zum 1. Juni 2009 haben die Unternehmen Continental Automotive und Infobest eine langfristige Zusammenarbeit in verschiedenen IT-Bereichen vereinbart. Kern dieser Kooperation ist die Weiterentwicklung und Pflege der bei Continental Automotive weltweit intern genutzten Anwendungen, die mehrheitlich auf C++ und .Net entwickelt werden.

Im Rahmen dieser Kooperation kommen die IT-Experten der rumänischen Infobest-Gesellschaft zum Einsatz. Bereits in der Vergangenheit konnte sich Continental Automotive von der Qualität und dem hervorragenden Preis-Leistungs-Verhältnis des deutsch-rumänischen IT-Dienstleisters in verschiedenen Einzelprojekten überzeugen.

Infobest gibt den Aufbau eines Experten-Teams für den Bereich Sharepoint bekannt. Das Kernteam wird zunächst am rumänischen Standort in Timisoara eingerichtet und konzentriert sich auf die Aspekte Applikationsentwicklung und administrativer Support für Sharepoint-Technologien. Dabei werden bereits bestehende Erfahrungen und Kenntnisse in diesem Umfeld konsolidiert und als eigenständige Leistungspakete gebündelt. Die schrittweise Erweiterung des Kernteams in den kommenden 3 Monaten ist bereits fest eingeplant und budgetiert.

Lotus Notes und Domino sind weltweit bekannte Email- und Groupware-Plattformen mit einem etablierten Markt in Deutschland, Österreich und der Schweiz. In den vergangenen Jahren wurden tausende von Notes-Anwendungen für diese Plattform entwickelt, von ganz einfach bis extrem komplex, von kunden-spezifisch bis Standard und von Client-only bis Web-Interface. Was es aber seltsamerweise kaum gibt, sind Notes-Entwickler in Nearshore-Destinationen. Das mag allerlei Ursachen haben, über die zu spekulieren müßig ist. Tatsache bleibt, daß man in Osteuropa wirkliche Notes-Fachleute wie die Nadel im Heuhaufen suchen muß.

Infobest hat bereits 2000 ein Notes-Team in seiner rumänischen Niederlassung aufgebaut, zunächst nur mit der Zielsetzung, eigene Standard-Produkte zu entwickeln. Mittlerweile verfügt das Nearshore-Büro über langjährige Expertise und hat zahlreiche Notes-Projekte unterschiedlichster Größenordnungen und Inhalte für diverse mitteleuropäische Kunden wie Philips, Continental, Bosch, Allianz und zahlreiche mittelständische Unternehmen durchgeführt hat.

Ab Anfang April 2009 verstärken wir unser Notes-Team in Rumänien wieder. Wenn Sie in diesem Bereich Projekte zu vergeben haben und die Nearshore-Karte einmal spielen möchten, sollten wir darüber sprechen. Auf Wunsch kann Ihr Projekt auch durch einen erfahrenen deutschen Notes-Projektleiter begleitet werden, ebenso kann das gesamte Projekt in deutscher Sprache abgewickelt werden.

Heute möchte ich ein wenig zu den verschiedenen Gestaltungsmöglichkeiten für Nearshore-Projekte schreiben. Zunächst hängen diese natürlich von der Natur des Projektes ab, ein klassisches Entwicklungsprojekt bietet andere Optionen als z.B. ein Wartungs- oder ein Testprojekt. Nehmen wir also der Einfachheit halber einen Kunden an, der eine Neuentwicklung im Bereich Business Anwendung umsetzen will, mittlere Größenordnung (200 bis 300 PT).

Szenario 1: Die Anforderungen für das Projekt sind schwer zu erfassen und erfordern viel fachliches Knowhow. Die Spezifikation dieser Anforderungen muß daher vor Ort erfolgen und geschieht in mehreren Iterationsschritten mit zahlreichen Workshops, in denen unterschiedliche Anwendergruppen heterogene Anforderungen äußern.
Projektorganisation: Ein “Brückenkopf” wird beim Kunden vor Ort zu Projektbeginn durchgehend eingesetzt, der mit dem Kunden zusammen die Anforderungen sammelt, auswertet und in eine Spezifikation gießt. Dieser Brückenkopf kann entweder ein deutscher Projektleiter / Analyst sein (der natürlich die Nearshore-Kollegen kennt) oder ein Nearshore-Projektleiter /-Analyst, der diese Aufgabe ausfüllen kann. Die Kommunikation findet zwischen Kunde und Brückenkopf sowie zwischen Brückenkopf und Nearshore-Team statt. Diese Gestaltung kann nach Abnahme der Spezifikation auch derart aufgelöst werden, daß der Kunde dann direkt mit dem Nearshore-Team kommuniziert. Das Projekt wird dann entweder als Festpreis umgesetzt oder nach Aufwand, abhängig von Detaillierung und Qualität der Spezifikation und von der zu erwartenden Volatilität im Projekt. Letzteres heißt konkret: Wenn zu erwarten steht, daß der Kunde die Anforderungen nach Abschluß der Spezifikation häufig ändert oder erweitert bzw. viele kleinere Phasen mit neuen Anforderungen unmittelbar anschließend zu erwarten sind, dann würde ein Festpreis einen immensen Overhead produzieren, alleine um die Change Requests zu verwalten. “Time and Material” ist hier erfahrungsgemäß die einfachere und kostengünstigere Variante.

Szenario 2: Der Kunde hat ein hervorragend spezifiziertes Projekt zu vergeben. Funktionale und nicht-funktionale Anforderungen sind sauber definiert, die UI ist entsprechend Standard-Layouts vorgegeben, sämtliche Schnittstellen und andere relevanten technischen Formate liegen auf dem Tisch.
Projektorganisation: Dieses Paket kann z.B. im Rahmen eines Workshops beim Kunden vor Ort an einen Nearshore-Projektleiter übergeben werden, der als zentraler Ansprechpartner für dieses Projekt dient. Er ist dafür verantwortlich, das Projekt mit seinem Nearshore-Team aufzusetzen und durchzuführen. Ein Festpreis bietet sich an, die gesamte weitere Organsiation des Projektes bis hin zur Lieferung und Abnahme kann beim Nearshore-Partner liegen und von diesem verantwortet werden.

Szenario 3: Der Kunde hat eine Vielzahl von kleineren bis mittleren Projekten oder Versionen innerhalb eines Projektes (z.B. typisch bei Produktentwicklungen). Der Aufwand, um für jedes einzelne kleine Projekt oder jede Version eine abnahmefähige Spezifikation zu erstellen, wäre recht hoch und ist aus organisatorischen Gründen nicht zwingend erforderlich.
Projektorganisation: Hier macht es wenig Sinn, mit Pflichtenheften und Festpreisen zu hantieren, das Change Management würde vermutlich mehr Overhead produzieren als das gesamte Projektvolumen nach Aufwand beträgt. Daher ist der Kunde am besten beraten, für den Zeitraum, den er selbst projektseitig überschauen bzw. prognostizieren kann, ein festes Kontingent von Nearshore-Mitarbeitern als “sein” Team einzukaufen. Damit kann er sicherstellen, daß für alle Projekte bzw. Produktversionen immer die gleichen Nearshore-Kollegen zuständig sind, keine permanenten Einarbeitungen nötig sind, zeitraubende Festpreis-Verhandlungen entfallen und der Aufwand, der sonst in die X-te Review einer Spezifikation investiert würde, lieber für die Entwicklung oder Qualitätssicherung zur Verfügung steht. Natürlich liegt das Risiko für die Qualität des Anforderungs- und Projektmanagements annähernd komplett beim Kunden, ebenso trägt er die Verantwortung für eine gleichmäßige Auslastung des Teams. Unter den entsprechenden Voraussetzungen ist das aber tatsächlich eine sehr effiziente Organisationsform, soz. als eine verlängerte Werkbank. Hier muß natürlich vom Nearshore-Partner sichergestellt werden, daß seine Aufwände transparent sind und möglichst im groben Rahmen vorab mit dem Kunden besprochen werden. Ebenso ist eine sehr gute und schnelle Kommunikation der Beteiligten zwingend erforderlich. Unter dem Strich aber bleibt es eine Projektform, die starkes gegenseitiges Vertrauen voraussetzt.

Wir haben in den vergangenen Jahren alle diese Szenarien erlebt und durchgespielt. Und mit allen Szenarien erfolgreich Nearshore-Projekte umgesetzt. Natürlich gibt es noch zahlreiche Nuancen und Facetten, aber im Großen und Ganzen lassen sich mit diesen Spielarten die meisten Fälle abdecken.

Unser Unternehmen ist seit 2000 im Nearshore-Geschäft tätig. Da haben wir einiges an Erfahrungen gesammelt und Interessantem erlebt. Und weil wir auch heute noch bei vielen Unternehmen auf Skepsis und Fragen zu diesem Thema stoßen, möchte ich ein wenig aus unserer Praxis plaudern und verschiedene Aspekte näher beleuchten.
Fangen wir heute mal mit der Frage an, unter welchen Voraussetzungen Nearshore (oder Offshore) Sinn macht und in welchen Fällen man besser die Finger davon läßt.

Eine wesentliche Funktion für “Nearshore-Fähigkeit” ist die Spezifizierbarkeit der zu entwickelnden Komponenten. Hier reicht die Bandbreite von Extrem zu Extrem. Auf der einen Seite haben wir Projekte erlebt, bei denen irgendwelche Anforderer (also die späteren Anwender der Software) aus irgendwelchen Fachabteilungen ihre konkreten Wünsche und Anforderungen an die Funktionalitäten der Software nur sehr zögerlich, inkonsistent und lückenhaft an Mitarbeiter der IT-Abteilung unseres Kunden übermittelt haben. Diese mußten dann auf Basis dieses Inputs irgendeine Spezifikation zaubern, die für uns als Auftragnehmer sehr schwer zu überprüfen war, v.a. weil wir selbst keinen direkten Kontakt zu den eigentlichen Anforderern herstellen konnten. Eine solche Ausgangsbasis ist natürlich eher problematisch. Auf der anderen Seite des Spektrums gibt es Kunden, die sehr präzise Informationen in einen Spezifikationsprozeß liefern können, so daß wir gemeinsam mit dem Kunden eine solide Ausgangsbasis schaffen, i.d.R. in Form von Anwendungsfällen (neudeutsch Use Cases) und nicht-funktionalen Anforderungen, gelegentlich auch konkreten UI-Spezifikationen. Da wir nicht selten zur Abgabe eines Festpreis-Angebotes “ermutigt” werden, verwenden wir nach Möglichkeit unsere eigenen Dokumentations-Standards für die Anforderungs-Spezifikation. Wenn diese Anforderungs-Spezifikation noch vom “Anforderer” abgenommen wird, ist das die wirklich ideale Ausgangsbasis. Und vorher sollte keine weitere Arbeit im Projekt investiert werden, d.h. vor Klarstellung einer Anforderungs-Spezifikation macht keine Aufwandschätzung, keine Architektur, kein weiteres Design, keine Datenmodellierung, geschweige denn Programmierung Sinn.

Eine andere zentrale Komponente der Nearshore-Fähikeit ist der Organisationsgrad des Kunden. Damit meine ich im Wesentlichen die Prozesse und Standards in der Software-Entwicklung und im Projektmanagement, die angewendet werden - oder eben auch nicht. Um Nearshore erfolgreich zu betreiben, müssen zunächst die Zuständigkeiten klar defniert sein, also wer ist wofür der Ansprechpartner, wer kann was an wen delegieren und wer ist die abschließende Instanz für die Klärung bestimmter Fragen. Binsenweisheit? Hatten wir auch schon häufig gedacht. Aber es ist erstaunlich, wie oft in der Praxis diese einfachen Dinge aufgrund von Kompetenz-Gerangel und der in großen Organisationen permanent stattfindenden Neuorgansiation nicht funktionieren. 
Neben den Zuständigkeiten sollte es einen klar beschriebenen Entwicklungs-Prozeß geben. Es ist nachrangig, ob und wie sehr dieser einer der gängigen Theorien à la RUP, V-Modell, Wasserfall, etc. entspricht oder hausgemacht ist. Jeder mag hier seiner Religion frönen, was zählt ist, daß der Prozeß einigermaßen klar, verständlich, der Aufgabenstellung angemessen ist und auch tatsächlich stattfindet, d.h. nicht nur auf Papier und in tollen Powerpoint-Präsentationen lebt.
Was ich deutlich kritischer sehe sind agile Modelle wie Scrum oder Prototyping, letzteres häufig eine pseudo-wissenschaftliche Ausrede in Fällen, in denen angeblich die Anforderungen nicht modelliert oder spezfiziert werden können (”Der Kunde weiß nicht genau, was er will”). Das kann schon auch mit Nearshore funktionieren, aber der Organisations- und Abstimmungsgrad auf beiden Seiten (Kunde und Nearshore-Partner) muß deutlich höher sein und alle Aktivitäten müssen viel stärker synchron getaktet werden - und zwar von allen Beteiligten. Das übersteigt in der Praxis meistens die Fähigkeiten an Koordination und Kommunikation. Also im Zweifelsfall lieber die Finger davon lassen.
Neben dem Entwicklungsprozeß sollte aber auch das Projektmanagement des Kunden zumindest in zentralen Punkten einheitlich funktionieren. Dazu gehören z.B. frühzeitige Projektbeschreibungen, einheitliche Projektpläne, Risikobetrachtungen, ein Kommunikationsplan und Qualitätsrichtlinien. Auch das muß nicht unbedingt streng katholisch nach PMI oder Prince2 gehandhabt werden und kann bei kleineren Projekten auch überschaubar und einfach gestaltet werden (die Devise heißt nicht, in Schönheit zu sterben). Aber wenn man schon zu Beginn des Projektes nicht genau definieren kann, was im Scope des Projektes liegt und was nicht, sind die Voraussetzungen denkbar schlecht. Das ist natürlich kein Punkt, der nur speziell für Nearshore gilt, sondern der (wie alle anderen Punkte auch) für alle Projekte relevant ist, im Fall von Nearshore aber eine besonders zentrale Bedeutung hat.

Und da aller guten Dinge drei sind, hier noch ein dritter Baustein für erfolgreiches Nearshore-Geschäft: Kommunikation. Das gehört natürlich streng genommen in das allgemeine Projektmanagement hinein. Aber da für Nearshore die Kommunikation wirklich einer der absolut zentralen und wichtigsten Aspekte ist, sei ihm ein Logenplatz gegönnt. Und damit diese funktioniert, sollten ein paar Spielregeln gleich zu Beginn des Projektes festgelegt werden: welche Inhalte / Dokumente werden z.B. in einem Projekt-Portal abgelegt; welche Themen sollten per Mail behandelt werden; wann und wofür werden Chat und Telefon eingesetzt; gibt es einen Jour Fix z.B. für wöchentliche Statusbesprechungen; wie häufig und in welcher Form erfolgt die Rückmeldung über den Projektverlauf, reicht ein wöchentlicher Bericht, welche Themen müssen ad hoc kommuniziert werden; wann wird was wohin eskaliert?
Bei all diesen Fragestellungen müssen sich beide Partner darüber im Klaren sein, daß vereinzelt Sprachbarrieren bestehen können und kulturelle Unterschiede zu unterschiedlichen Interpretationen von Sachverhalten führen können. Hier bietet sich das oft zitierte (und von mir persönlich erlebte) Beispiel an, daß ein Inder eine Frage, auf die er eigentlich mit Nein antworten müßte, aus Gründen des Gesichtsverlustes häufig doch mit Ja beantwortet oder hartnäckig ignoriert. Mit unseren rumänischen Kollegen sind die kulturellen Unterschiede natürlich weit kleiner als im beschriebenen Fall. Aber es ist z.B. so, daß ein Rumäne bei Fragen oder Problemen viel schneller ein persönliches Gespräch sucht und gemeinsam mit anderen Beteiligten mögliche Lösungen bespricht, als sich stundenlang in Einsamkeit zu quälen oder über unpersönliche Kanäle wie Email zu kommunizieren. Und noch ein kleiner Beitrag zum Thema Vorurteil: Neulich sagte ein Kunde zu mir nach einem ersten Telefonat mit einem unserer deutsch-sprachigen rumänischen Projektleiter: “Das ist unglaublich, der Mensch ist wirklich super fit. Man glaubt gar nicht, daß das ein Rumäne ist”. Klar, die leben sonst alle in Erdlöchern und fressen kleine Kinder…

Um es gleich vorweg zu nehmen: Das hat jetzt mal nichts mit dem Thema IT oder Nearshoring zu tun. Hier geht es um die menschliche Kommunikation im allgemeinen und Networking-Plattformen im Besonderen.

Wie jeder gute Erdenbürger bin ich in der einen oder anderen Plattform wie Xing, LinkedIn oder Facebook präsent. Bislang kenne ich das auch als einigermaßen seriöse Plattform, in der man private oder geschäftliche Kontakte suchen und idealerweise auch finden kann. Keine Vertriebs-Keilerei in eigener Sache (außer auf den Foren, die extra dazu da sin), sondern einfaches und höfliches Erfragen von Interessen, Erfahrungen und Meinungen.

Seit kurzem habe ich mich auf der Plattform Ecadamy auf Einladung eines Geschäfts-Bekannten angemeldet. Und komme seither aus dem Staunen kaum heraus. Binnen 10 Minuten nach meiner Anmeldung habe ich rund 1 Dutzend Kontaktersuche und Meldungen gehabt, ein Mensch aus Indien hat sogar simultan versucht, mich in Skype und per Telefon (Hallo !!!) zu erreichen. Da müssen wohl etliche Progrämmchen laufen, die sofort sämtliche neuen Mitglieder anzeigen und eine automatische Kontaktanfrage verschicken. Denn personalisiert war von diesen Anfragen natürlich keine.

Seither bekomme ich jeden Tag mehrere derartige Anfragen, alle unpersönlich und bei denen völlig klar ist, daß der Absender sich nicht einmal die Mühe gemacht hat, mein Profil zur Kenntnis zu nehmen. In den meisten Fällen geht es ohnehin nur um die primitivste und dümmlichste Vertriebs-Nummer: Teilnahme an unerträglich teuren Seminaren, Bewerbung von Produkten und Dienstleistungen, Mitgliedschaft in Clubs oder Foren, die am Ende nur den Initiator reich und glücklich machen.

Hm…. da stellt sich irgendwie schnell die Sinnfrage: welchen Zweck haben solche Netzwerke, wenn sie nichts anderes als die Zielscheibe von Kontakt-Spammern sind?

Falls jemand dazu eigene Erfahrungen hat, freue ich mich über einen Kommentar. Und keine Angst: Ich versuche Ihnen ganz bestimmt nichts zu verkaufen…

Neue Kunden und Projekte gewinnt man immer gerne. In der aktuellen Situation ganz besonders. Daher hat es uns auch sehr gefreut, daß wir Ende vergangenen Jahres eine neue langfristig angelegte Partnerschaft mit einem der größten Reiseanbieter der Republik beschließen konnten. Kern der Zusammenarbeit bilden unsere Nearshore-Dienstleistungen im Bereich .Net Entwicklung. Dabei konnten wir dem Kundenwunsch entsprechen und einen deutschsprachigen Nearshore-Projektleiter zur Verfügung stellen, der sämtliche Kunden-Kommunikation und Projekt-Dokumentation ausschließlich in deutscher Sprache sicherstellen kann. Das mag nicht in jedem Projekt gehen (Deutsch-sprechende Rumänen sind eine endliche Ressource), aber es stellt unserer Ansicht nach doch einen erheblichen Vorteile dar, derartiges überhaupt anbieten zu können. Als Ergebnis erhält der Kunde einen erfahrenen Projektleiter seines Lieferanten als zentralen Ansprechpartner, mit dem er dank üblicher Kommunikationsmedien (Telefon/VOIP, Skype, etc.) in seiner Muttersprache kommunizieren kann und der bei Bedarf jederzeit mit einem zweistündigen Flug Workshops und sonstige Meetings einfach und unkompliziert auch vor Ort wahrnehmen kann. Da macht es keinen wirklichen Unterschied mehr, ob der Lieferant in Berlin, München oder eben Timisoara sitzt. Außer beim Thema Rechnungsstellung.

In den vergangenen Wochen hat uns eine Frage umgetrieben, die so ungewöhnlich gar nicht ist: Wie sehen uns unsere Kunden wirklich? Was würden Sie sagen, wenn sie ihre Meinung anonym abgeben können? Schneiden wir positiv ab? Oder erleben wir eine unliebsame Überraschung? Oder gibt es ein Wechselbad mit gemischten Antworten?

Wir haben also vergangene Woche eine Kundenbefragung unter unseren Nearshore-Kunden durchgeführt, die online und anonym beantwortet werden konnte. Zunächst hat uns dabei überrascht, daß es durchaus einige Kunden gibt, die keine Anonymität in Anspruch genommen haben, sondern gerne unter ihrem Namen ihre Meinung aussprachen. Danach hat uns - positiv - überrascht, daß es keine wirklich negativen Ausschläge gab. Leichte Kritik in der einen oder anderen Disziplin, die wir auch sehr gerne zur Kenntnis genommen haben. Aber durchweg würden uns  alle Kunden weiterempfehlen und betrachten die mit uns durchgeführten Projekte in einem positiven Preis-Leistungs-Verhältnis. Und sehr interessant war auch, daß durchweg die Tatsache als sehr hilfreich und wichtig angesehen wurde, daß Infobest seine Nearshore-Projekte auch durch deutsche Mitarbeiter in deutschen Niederlassungen unterstützen kann. Da ist vielleicht doch die “gefühlte Nestwärme” ein nicht zu unterschätzender Faktor.

Wir werden derartige Kundenbefragungen nun regelmäßig durchführen, um auch längerfristige Trends erkennen zu können.