EAM-Projekte erfordern vom zuständigen Unternehmensarchitekten eine Menge Erfahrung auf diesem Gebiet, die zu erwerben oft Jahre dauert. Umgekehrt kann ein falsches oder besser gesagt nicht den Anforderungen entsprechendes Metamodell den Projekterfolg sehr erschweren bzw. sogar verhindern. Im iteraplan-Metamodell stecken diese langjährigen Erfahrungen und bisher konnten wir alle kundenspezifischen Wünsche darin abbilden. Damit entfällt ein oft monatelanger Prozess zur Festlegung des Modells, der eines insbesondere verhindert: Quick Wins, mit denen der Architekt das Projekt gegenüber seinem Management am einfachsten rechtfertigt. Ein anderes Problem mit frei konfigurierbaren Modellen sind die sich daraus ergebenden sehr generischen Benutzeroberflächen. Das ist ein großer Nachteil für sporadische Nutzer, wie z.B. Manager oder Controller. Sie haben wenig Zeit für die Einarbeitung, kommen aber gleichzeitig mit wenig intuitiven oder selbsterklärenden Benutzeroberflächen nicht zurecht. Auch das ist ein Grund für die manchmal geringe Akzeptanz von EAM.
FAQ
Im Grunde ist es egal, wann und wo Sie arbeiten. Am Ende zählt das Ergebnis für den Kunden. Sie können also gerne in dem Rahmen, den das Projekt und die Aufgabe zulassen, auch einmal zuhause arbeiten. Da unsere Projekte aber immer Teamarbeit sind und gleichzeitig der Kunde intensiv eingebunden wird, sind der Flexibilität natürlich auch Grenzen gesetzt.
Von Beginn an waren Softwarearchitektur und -entwicklung das bei uns dominierende Thema. In unseren Projekten sind eine methodische Vorgehensweise und die Entwicklung von angemessenen Architekturen essentiell. Architekturzentriertes Arbeiten führt unsere Meinung nach zu stabileren und besser wartbaren Systemen. Schon 1996 haben wir uns mit iterativen, inkrementellen Modellen befasst (der Firmenname iteratec ist schließlich kein Zufall) und ein eigenes Vorgehensmodell entwickelt. Die Agilität in den Kundenanforderungen (wir nennen es Moving Target) fordert schließlich ein entsprechendes Vorgehen in den Projekten. Wir haben auf diesem Gebiet umfangreiche Kompetenz entwickelt, bilden das Team entsprechend aus und verstärken uns permanent mit weiteren erfahrenen Technologen.
Ja und nein. Wir beschäftigen uns permanent mit neuen Technologien, weil unsere Kunden oft mit Anforderungen auf uns zukommen, die innovative Ansätze erfordern. Dazu müssen unsere Mitarbeiter zum einen neuen Ansätzen gegenüber aufgeschlossen sein und sie ausprobieren wollen, gleichzeitig muss die Unternehmensführung dahinter stehen. Beides ist bei uns gegeben. Eine Möglichkeit dazu besteht z. B. bei unserem iterathon (abgeleitet aus Hackathon), bei dem sich mehrere Teams selbst gestellten Aufgaben widmen.
Wir selbst erzeugen aber im Normalfall keine Einzelinnovationen, sondern kombinieren am Markt verfügbare Innovationen mit bewährten Technologien und Methoden zu einer robusten, langfristig tragenden Lösung des Kundenproblems, was aus unserer Sicht in der beschriebenen Synthese durchaus innovativ ist. Für uns ist es sehr wichtig, technische Innovationen zu erkennen und diese hinsichtlich der Einsatzfähigkeit in unseren i. d. R. geschäftskritischen Softwareprojekten für Kunden zu bewerten. Dabei setzen wir nur solche technischen Neuerungen ein, die robust genug sind und die dem Kunden einen deutlichen Nutzen bringen, z. B. die ihm helfen, seine Marktposition zu verbessern.
Selbstverständlich können unsere Mitarbeiter zwischen den Standorten wechseln. Das ist auch schon öfter vorgekommen, wobei in der Regel private Gründe der Auslöser sind. Das braucht dann etwas Vorlauf, um den damit meistens auch verbundenen Projektwechsel zu organisieren. Ein grundsätzliches Problem entsteht damit aber nicht. Im Gegenteil, durch den Wechsel zwischen den Geschäftsstellen wird auch der unternehmensinterne Austausch zwischen den Kollegen gefördert, was wir sehr begrüßen.
Mehrere Gründe sind wesentlich für unsere große Vielfalt in den Projekten: Die sehr hohe Kompetenz der Mitarbeiter, die große Breite des Erfahrungsspektrums der Menschen, die wir neu an Bord holen, die besonders hohe Lernfähigkeit des Teams und die Tatsache, dass wir keine Wissensmonopole haben. Es gibt nicht nur wenige schlaue Berater, die zum Kunden gehen (oder manchmal auch nur in der Projektakquisition sichtbar sind) und noch ein paar Juniors im Gepäck haben. Wir sind sehr breit aufgestellt und schicken unseren Kunden keine Azubis.
Auch wir haben, wie bei vielen IT-Dienstleistern, ein verhältnismäßig junges Team. Aber Jugendwahn gibt es bei uns nicht. Wir haben in den letzten Jahren unser Beratungsangebot stark ausgebaut und uns deshalb auch in erheblichem Umfang mit erfahrenen Beratern verstärkt. Der älteste Kollege, den wir in den letzten zwei Jahren eingestellt haben, war zu dem Zeitpunkt 59 Jahre alt.
Gegenfrage: Kann ein Absolvent einen IT-Manager beraten? Eher nicht. Aber das wollen Sie ja vermutlich auch nicht gleich zu Beginn. Sie können jedoch als Absolvent bei uns sehr schnell die notwendige Ausbildung absolvieren, um in diese Thematik einzusteigen. Wenn Sie ausreichende Technologiekenntnisse und Software-Implementierungserfahrung mitbringen, zeigen wir Ihnen gerne einen Weg auf, der Sie zügig in die IT-Beratung führt.
Das Anfangsgehalt ist branchenüblich. Über die Höhe der in der IT-Beratung bezahlten Gehälter können Sie sich recht gut im Internet informieren (einfach mal nach z. B. „Übersicht Einstiegsgehälter“ suchen). Nachdem wir ein breites Spektrum an Ausbildungs- und Fördermaßnahmen bieten sowie Wert darauf legen, dass nicht zu viele Überstunden gemacht werden (die übrigens extra bezahlt werden), liegen wir finanziell eher in der Mitte. Die weitere Entwicklung des Einkommens hängt dann ausschließlich von Ihnen ab. Ein Rankingverfahren sorgt dabei für unternehmensweite Gehaltsgerechtigkeit. Das besprechen wir aber am besten einmal persönlich.
Wir setzen häufig Open Source Komponenten in unseren Projekten ein (z. B. SPRING-Framework oder Liferay). Sie haben häufig eine vergleichbare, manchmal sogar bessere Reife als Kaufkomponenten namhafter Hersteller. Zahlreiche Antworten auf Support-/Entwicklungsfragen sind vorhanden und öffentlich. Neue Fragen werden von den Communities i. d. R. sehr schnell beantwortet. Beim Einsatz von Open Source müssen aber auch rechtliche Aspekte beachtet/geklärt werden. Wir setzen in Kundenprojekten nur solche Komponenten ein, mit denen man sich später keine Lizenzprobleme einhandelt. Insgesamt sind bei diesem Thema einige Dinge zu beachten, aber bei einem sorgsamen Umgang kann man mit Open Source Komponenten zu stabilen und gleichzeitig preiswerten Lösungen kommen.
Aufgrund unserer zahlreichen Standorte schaffen wir es, viele unserer Kunden aus der Nähe zu betreuen. D. h. unsere Teams arbeiten zu einem sehr hohen Anteil für Kunden in der jeweiligen Region. Das gelingt allerdings nicht immer, so dass vereinzelt iteratec-Kollegen auch reisen müssen. Das gilt für Mitarbeiter aller Laufbahnstufen, wobei die Implementierungsprojekte davon fast nie betroffen sind. Wenn, dann reisen eher unsere Berater.
Genau genommen haben wir uns zuletzt immer innerhalb von vier Jahren in der Größe verdoppelt. Dafür gibt es sicher viele Gründe, aber im Kern ist es unser Team, das außerordentliche Leistungen erbringt und damit diesen ungewöhnlichen Erfolg hat. Allerdings überlassen wir die Zusammensetzung unseres Teams auch nicht dem Zufall. Unser Bewerbungsverfahren sorgt dafür, dass wir die Mitarbeiter finden, die aufgrund ihres überdurchschnittlichen Potenzials die hohe Lerngeschwindigkeit haben, die wir für unsere herausfordernden Projekte brauchen (Dieses Potenzial kann man übrigens nicht in Zeugnissen lesen). Aus einer Kundenbefragung von 2011 wissen wir, dass uns unsere Kunden u.a. mit den Begriffen „hochwertig“ und „maßgeschneidert“ in Verbindung bringen. Aber aus dieser Umfrage stammt noch ein anderer wichtiger Begriff, der uns gut charakterisiert: „menschlich“.
Noch interessanter ist vielleicht, dass wir dieses Wachstum zu keinem Zeitpunkt geplant haben. Es macht aus unserer Sicht auch keinen Sinn, ein Beratungsunternehmen nur nach Zahlen zu führen. Die kann man zwar kurzfristig optimieren, aber für ein nachhaltiges Wachstum benötigen sie besondere Mitarbeiter – und die lassen sich nicht durch Businesspläne herbeizaubern sondern müssen von innen entwickelt bzw. am Personalmarkt gefunden werden!
Weil Größe nur scheinbar hilft und unsere Kunden das sehr wohl erkennen. Zugegeben: In Projekten, bei denen das Team so groß sein muss, dass man es in Bussen zum Einsatzort bringen muss, sehen uns unsere Kunden nicht. Aber das ist auch nicht unserer Ziel. Wir wollen unseren Kunden bei den besonders schwierigen und innovativen Projekten helfen. Dazu braucht es ein besonderes Team und höchst mögliche Kompetenz. Aus diesem Grund haben wir bei der Entwicklung unseres Unternehmens nicht größtmögliches Wachstum im Auge sondern größtmögliche Kompetenzdichte. Gemeint ist das Verhältnis aus Kompetenz zu Teamgröße. Das ist bei uns deshalb besser als bei unseren großen Wettbewerbern.
Weil wir zuverlässig sind und weil wir unsere Kunden entlasten. Und weil für uns jeder Kunde wichtig ist! Das spürt man einfach.
Ja, die Namensähnlichkeit ist kein Zufall. Wir haben iteraplan 2003 als internes Produkt gestartet und über Kundenprojekte weiterentwickelt. Seit Anfang 2008 ist iteraplan sowohl in der Community als auch der Enterprise Edition als erste Open Source EAM-Software überhaupt für ein breites Publikum verfügbar. Siehe weiterführende Informationen und Downloadmöglichkeiten zu iteraplan.
Richtig ist, dass ein starkes Wachstum die Unternehmenskultur verändert. Das muss aber nicht heißen, dass sie schlechter wird. Auch wenn nicht mehr jeder Kollege jeden kennt und nicht mehr genau weiß, welche Projekte insgesamt bei iteratec gemacht werden und schon gar nicht standortübergreifend, definiert sich Kultur ja anders. Es geht dabei insbesondere um Werte wie z.B. Zeit haben für Kollegen, die ein Problem haben, Bereitschaft, sich einzubringen, Umgang mit Knowhow-Unterschieden, usw., aber auch Spaß miteinander haben oder einmal in der Freizeit etwas zusammen zu machen. Dass diese Dinge funktionieren beweisen wir täglich.
Das ist ganz einfach: Wir haben keine Lust auf Feature-Krieg. Damit meinen wir die weit verbreitete Unsitte, Werkzeuge mit Funktionalität anzureichern, die zwar keiner braucht, die aber wettbewerbsdifferenziert sind, zumindest am Anfang. Dadurch, dass alle nachziehen, relativiert sich das dann zwar schnell wieder, aber der Anwender sieht irgendwann den Wald vor lauter Bäumen nicht mehr. Als kommerzieller Anbieter ist man aber mehr oder weniger gezwungen, diesen Wettlauf mitzumachen, weil Produktentscheidungen oft anhand von Featurelisten fallen. Auch die Frage nach dem Geschäftsmodell ist nicht schwer: iteratec gilt in der DACH-Region als führend im Bereich EAM. Viele Unternehmen, die die Community-Edition von iteraplan evaluiert haben, entscheiden sich dann gleich für den Einsatz der Enterprise Edition und bitten uns, Ihnen bei der Einführung im Unternehmen zu helfen. Mit den Einnahmen aus den Beratungsprojekten, den Wartungsverträgen sowie verschiedenen Möglichkeiten, individuelle Anpassungen durch Sponsoring zu gestalten, finanzieren wir die Produktentwicklung.
Dafür gibt es viele Gründe. Der wichtigste: Weil wir allen unseren Mitarbeitern einen sicheren Arbeitsplatz anbieten wollen. Dazu müssen wir, d. h. unsere Aufgaben, die Projekte, unser Team, die Unternehmenskultur usw., und unsere potenziell neuen Mitarbeiter sehr gut zusammen passen. Aus Gesprächen, Lebensläufen und Zeugnissen kann man das leider nicht hinreichend genau ableiten und Assessments helfen auch nur begrenzt, weswegen wir keine machen. Das bei uns eingesetzte Verfahren hilft uns schon seit der Gründungszeit, die richtigen Kollegen zu finden. Wenn man sich unsere Unternehmensentwicklung anschaut, kann das nicht so falsch sein. Fürchten muss sich davor auch niemand. Wir setzen es bei allen Einstellungen ein, auch wenn es sich um Aufgaben im Sekretariat oder im Verwaltungsbereich handelt.
Das ist ein ganzer Strauß von Maßnahmen. Einen guten Überblick gibt ein Interview, das unser Geschäftsführer Klaus Eberhardt im November 2011 der Computerwoche gegeben hat.

