„Ein Berater ist eine Brücke zwischen Technologie und Realität“, sagt ein IT-Berater über Softwareeinführung, Feldarbeit und die Lösung unsichtbarer Probleme
08.09.2025 | 12 min Anasoft
In der Interviewreihe personal<IT> werfen wir einen Blick hinter die Kulissen der IT-Arbeit durch die Augen von Fachleuten bei ANASOFT. Sie enthüllen nicht nur ihre Arbeitswelt, sondern auch ihre persönliche Seite, denn hinter technischen Spezifikationen, Testszenarien und Benutzerschulungen steht immer ein konkreter Mensch – mit seiner eigenen Denkweise, Empathie und der Fähigkeit, die IT-Welt mit der physischen Realität zu verbinden.
IT-Konsultant Marek begleitet die Software durch ihren gesamten Lebenszyklus – von den Tests bis hin zur Implementierung in der realen Umgebung. Im Interview erklärt er, was die Arbeit zwischen Entwicklung und Kunde alles beinhaltet, warum jedes Lager anders ist und wie man Probleme löst, die nicht einmal tausend Tests aufdecken, sondern erst ein Metallschrank in der Halle.
Seine Fähigkeit, die technische Sprache in eine menschliche zu übersetzen und gleichzeitig die Bedürfnisse der Benutzer zu verstehen, erinnert an Karel Čapek – den Schriftsteller, Visionär und Schöpfer des Wortes „Roboter“, der bereits vor hundert Jahren die Beziehung zwischen Mensch und Technologie mit außergewöhnlicher Genauigkeit und Sensibilität zu erfassen wusste. So wie Čapek die Grenzen zwischen Maschine und Mensch aufzeigte, hilft Marek im täglichen Kontakt mit Kunden der Technologie, verständlich, funktional und wirklich nützlich zu sein.
Viele Menschen können sich unter dem Begriff IT-Konsultant nicht genau vorstellen, was dieser Beruf umfasst. Wie würdest du ihn jemandem erklären, der nicht aus der IT-Welt kommt?
Ich erkläre es gerne so: Ein IT-Konsultant ist jemand, der alle Phasen der Softwareentwicklung und deren Einführung in die Praxis berührt. Ich kommuniziere mit dem Kunden, verstehe seine Bedürfnisse, beteilige mich an der Lösungsfindung und beobachte, wie sie umgesetzt wird. Ich teste die Software, optimiere ihre Funktion und helfe schließlich bei der Implementierung in den Betrieb. So sieht der Konsultant das Produkt über seinen gesamten Lebenszyklus und kann die technische Seite mit den tatsächlichen Anforderungen der Benutzer verbinden.
Welche Teile des Projekts fallen als Konsultant in deinen Verantwortungsbereich?
Ich unterteile das Projekt in drei Hauptphasen: Entwicklung, Inbetriebnahme und Produktionssupport. In die allererste Phase – die der Vorentwicklung – greife ich kaum ein. Dort geht es hauptsächlich um den analytischen Teil, also darum, was das System genau leisten soll, welche Anforderungen der Kunde hat, welche Prozesse und technischen Einschränkungen bestehen usw. Diese Phase liegt in der Verantwortung des Analysten zusammen mit dem Projektmanager und dem Kunden.
Ich steige in das Projekt ein, sobald die Spezifikation genehmigt ist – also wenn wir wissen, was entwickelt werden soll, und die Entwicklung beginnen kann. In dieser Phase bereite ich Testszenarien vor, also konkrete Situationen, die wir später prüfen, um sicherzustellen, dass die Software tut, was sie soll. Gleichzeitig beginne ich, mit dem Kunden zu kommunizieren, und wir stimmen Details ab, die zu Beginn noch nicht geklärt werden konnten – zum Beispiel, wie die Datenverbindungen aussehen sollen, welche Geräte angeschlossen werden oder wie die Benutzeroberfläche gestaltet wird.
Darüber hinaus plane ich in diesem Stadium bereits, wie das System in den Echtbetrieb überführt wird – also welche Schritte notwendig sind, damit alles reibungslos abläuft: Wer und wann geschult wird, was in der Infrastruktur vorbereitet werden muss, welche Tests beim Kunden stattfinden und wie wir sicherstellen, dass alles vom ersten Tag an funktioniert. Diese Vorbereitung ist entscheidend, um spätere Probleme, die Ausfälle oder Verzögerungen verursachen könnten, zu vermeiden.
Wie läuft die eigentliche Inbetriebnahme des Systems ab?
Das System wird zunächst in einer sogenannten Vorproduktionsumgebung installiert – im Grunde eine Simulation des Echtbetriebs beim Kunden, jedoch ohne echte Daten und ohne das Risiko, den laufenden Betrieb zu beeinträchtigen. Dort testen wir das System erneut gründlich, überprüfen alle entwickelten Funktionen und passen es an die spezifischen Anforderungen des Kunden an. Das ist eine sehr intensive Phase, denn wir bringen eine fertige Lösung in die reale Umgebung.
In diesem Stadium arbeiten wir direkt mit dem Kunden in dessen Lager oder Produktion zusammen – wir sind physisch vor Ort. Wir testen das System auf den konkreten Geräten, sei es auf Regalbediengeräten, Förderanlagen oder anderen Technologien, die mit dem System verbunden werden sollen. Wir versuchen, alle möglichen Situationen zu simulieren, die im echten Betrieb auftreten könnten, um sie zu erkennen und zu beheben, bevor das System scharf geschaltet wird.
Erst wenn alles abgestimmt ist, alle Verbindungen funktionieren, die Prozesse richtig eingestellt sind und die Mitarbeiter beim Kunden wissen, wie sie das System bedienen, gehen wir in die Produktionsphase über – also in den echten Betrieb.
An diesem Punkt beginnt auch meine Rolle im Rahmen des Produktionssupports. In den ersten Tagen nach der Einführung stehe ich in engem Kontakt mit dem Kunden, beobachte, wie sich das System im Echtbetrieb verhält, helfe bei eventuellen kleineren Problemen, beantworte Benutzerfragen und nehme bei Bedarf Anpassungen vor. Das ist die Zeit, in der wir besonders aufmerksam sein müssen, um den Kunden bestmöglich zu unterstützen und einen reibungslosen Übergang in die neue Realität zu gewährleisten.
Welche Phase ist für dich die intensivste?
Am arbeitsreichsten ist sicher die Vorproduktionsphase. Das ist die Phase, in der wir ein fertiges System in den Händen halten – die Software ist nach Vorgaben programmiert, aber das bedeutet noch nicht, dass alles hundertprozentig funktioniert. Im Gegenteil: In dieser Phase wird alles wie ein Puzzle zusammengesetzt. Wir verfeinern Details, überprüfen, ob die entworfenen Prozesse in der Praxis wirklich funktionieren, und testen sie direkt in der Umgebung des Kunden.
Die große Herausforderung besteht darin, dass wir nicht mehr nur mit Code oder Theorie arbeiten, sondern auch mit realer Technologie – verschiedenen Maschinen, Förderanlagen, Regalbediengeräten, Scannern, Terminals … Jedes Gerät hat seine Eigenheiten und muss korrekt mit dem System kommunizieren. Gleichzeitig stehen wir im Austausch mit ganz unterschiedlichen Menschen – von Technikern über Lagerarbeiter bis hin zum Management. Jeder hat seine eigene Ausdrucksweise und unterschiedliche Erwartungen, daher ist Kommunikation in dieser Phase genauso wichtig wie technisches Wissen.
Wenn wir diese Vorproduktionsphase gut meistern – also alles abstimmen, die Benutzer schulen und der Kunde versteht, was er erhält –, verläuft der Produktionsstart meist ruhig. Das System wird einfach in den Echtbetrieb „umgeschaltet“, und wir sind bereit, nur noch kleinere Dinge zu lösen, die sich in der Praxis zeigen. Im Idealfall geht es dann nur noch darum, verfügbar zu sein – nicht darum, Brände zu löschen.
Mit wem kommunizierst du am häufigsten in den einzelnen Projektphasen?
Während der Entwicklung hauptsächlich mit den Entwicklern. Ich helfe, Fehler zu erkennen – sei es im Code oder solche, die im realen Betrieb auftreten könnten. In der Vorproduktion ist die Kommunikation intensiv sowohl mit den Analysten als auch mit dem Kunden. In der Produktionsphase kümmern wir uns vor allem um Feedback oder Anforderungen des Kunden.
Was umfasst das Testen der Software? Ist das die Aufgabe des Testers, oder testet auch der Konsultant?
Auch das Testen ist Teil der Arbeit des Konsultanten. Wenn der Entwickler eine Softwarefunktion fertigstellt, erhält der Konsultant sie zum Testen. Zuerst prüfen wir sie intern, indem wir Prozesse simulieren, die in der Realität stattfinden. Wir suchen nach Fehlern, prüfen, ob das System wie erwartet funktioniert, und nehmen bei Bedarf Anpassungen vor. Anschließend testen wir direkt beim Kunden, wo wir beobachten, wie das System unter realen Bedingungen arbeitet.
Wie stark unterscheidet sich das Testen im Büro vom Testen im realen Betrieb?
Enorm. Im Büro testen wir die Interaktion innerhalb der Software – Buttons, Datendarstellung, Prozesse. Im realen Betrieb kommen jedoch physische Faktoren ins Spiel. Manchmal stellen wir fest, dass die Software perfekt funktioniert, aber in der Praxis auf Hindernisse stößt. Deshalb ist es so wichtig, direkt vor Ort zu testen.
Kannst du beschreiben, wie die Einführung der Software in die Produktion abläuft?
Nach Abschluss der Tests bei uns und beim Kunden folgt die Phase der scharfen Einführung. Das bedeutet, dass das System im echten Betrieb genutzt wird. Während dieser Zeit sind wir oft physisch beim Kunden vor Ort, beobachten, wie sich das System verhält, und helfen bei der Lösung anfänglicher Probleme. Anschließend bieten wir Remote-Support an, kehren aber bei wichtigen Updates oder größeren Änderungen wieder zurück, um einen reibungslosen Übergang sicherzustellen.
Wie identifizierst du Probleme während der Entwicklung oder beim Testen?
Anhand der Testszenarien gehe ich die Prozesse durch, die in der Praxis ablaufen sollen. Wenn ich einen Fehler entdecke, beschreibe ich ihn und melde ihn dem Entwickler. Ich muss richtig einschätzen, ob es sich um einen Bug oder um ein neues gewünschtes Feature handelt. Das ist ein wichtiger Teil meiner Arbeit.
Wie unterscheidet sich die Kommunikation mit unterschiedlichen Menschen im Projekt?
Jeden Tag löse ich etwas anderes. Am Morgen kann es ein Lagerarbeiter sein, später ein Datenanalyst – Sprache und Form der Kommunikation müssen der Situation angepasst werden. Ein Konsultant muss mit beiden Welten kommunizieren können, der technischen und der nichttechnischen.
Welche Rolle hast du nach der Einführung des Systems?
Ich bleibe gewöhnlich Teil des Projekts – entweder als Hauptkonsultant oder als jemand, der einspringen kann. Wenn neue Anforderungen auftauchen, bearbeiten wir sie. Ich kommuniziere auch mit der Hotline; wenn das Problem schwerwiegender ist, wird es mit mir besprochen.
Was passiert, wenn der Kunde das System erweitern oder neue Funktionalitäten hinzufügen muss?
Solche Anforderungen kommen oft, wenn der Kunde wächst oder seine Prozesse anpasst. Zuerst analysieren wir, was genau benötigt wird, dann konsultieren wir mit dem Analysten und dem Entwicklungsteam, wie man es technisch in das bestehende System einarbeitet. Nach der Entwicklung folgen erneut Tests und die Einführung. Die Herausforderung besteht darin, dass unsere Kunden im Dauerbetrieb arbeiten, daher müssen wir Updates mit minimalen Auswirkungen auf ihren Betrieb durchführen.
Trotz gründlicher Tests treten im Betrieb unerwartete Situationen auf. Was hat dich schon überrascht?
Oft stellt sich heraus, dass das Problem nicht in der Software liegt, sondern in der Umgebung selbst oder im menschlichen Faktor. Wir hatten zum Beispiel ein System zur Zugangskontrolle über Chipkarten, bei dem sich Mitarbeiter über Scanner anmeldeten. Ständig wurde gemeldet, das System funktioniere nicht richtig, doch in unseren internen Tests war alles in Ordnung. Erst beim Vor-Ort-Besuch stellten wir fest, dass jemand in der Produktion einen Metallkasten installiert hatte, der das Signal blockierte. Solche Probleme erfassen Simulationen nicht – vor Ort müssen wir ein wenig wie Detektive vorgehen.
Ist der Konsultant also oft auch ein Detektiv?
Wenn wir eine Meldung bekommen, dass etwas nicht funktioniert, müssen wir den gesamten Prozess Sekunde für Sekunde analysieren, um die Ursache zu finden. Manchmal ist die Lösung sofort klar, wir sehen einen offensichtlichen Fehler. Manchmal handelt es sich um ein komplexes Zusammenspiel von Faktoren, bei dem sich beispielsweise in einer Sekunde mehrere Operationen gleichzeitig überschnitten und die Software unerwartet reagierte. Das lässt sich nur durch detaillierte Analyse und Erfahrung herausfinden.
Wie unterscheidet sich die Arbeit an Projekten mit vollautomatisierten Technologien von jener, bei der viele manuelle Prozesse bestehen?
Bei manuellen Systemen gibt es viel Interaktion mit den Mitarbeitern – wir klären, wie sie das System nutzen werden, schulen sie und passen die Prozesse so an, dass sie für sie funktionieren. Bei vollautomatisierten Systemen müssen wir Integrationen lösen. Viele Probleme entstehen hier durch die Kommunikation zwischen verschiedenen Systemen.
Zum Beispiel kann unsere Software korrekt programmiert sein, aber wenn ein externes System nicht richtig antwortet oder ausfällt, müssen wir eine Lösung auch außerhalb unserer Anwendung finden. Oft passiert es, dass ein externes System ein geplantes Update durchführt, ohne uns zu informieren, und plötzlich erhalten wir Meldungen, dass nichts mehr funktioniert. Das sind Situationen, die man vorhersehen und handhaben können muss.
Was war das Extremste, das du bisher lösen musstest?
Am unvorhersehbarsten sind physische Eingriffe in die Infrastruktur. Zum Beispiel ist es einmal passiert, dass in einer Halle Kabel durchtrennt wurden, die die Kommunikation zwischen dem System und den Servern sicherstellten. Der gesamte Betrieb stand still, und niemand wusste warum. Es dauerte Stunden, bis wir herausfanden, was passiert war, und bis zum Morgen mussten wir provisorische Lösungen schaffen, damit das Unternehmen weiterarbeiten konnte. Auf solche Situationen kann man sich nicht im Voraus vorbereiten – da helfen nur Erfahrung und ein klarer Notfallplan.
Hast du schon nächtliche Zwischenfälle erlebt?
Früher ja, vor allem bei kritischen Implementierungen. Manche Betriebe arbeiten rund um die Uhr, da spielt es keine Rolle, ob es Tag oder Nacht ist. Wenn ein Problem entsteht, müssen wir reagieren. Aber wenn das Projekt gut vorbereitet ist und die Vorproduktion erfolgreich verläuft, lassen sich die meisten Vorfälle minimieren.
Jedes Unternehmen nutzt unterschiedliche Prozesse und Technologien. Siehst du dabei manchmal interessante Unterschiede?
Auf jeden Fall. Zwei Unternehmen mit derselben Art von Produktion können völlig unterschiedliche Technologien einsetzen. Der eine Betrieb nutzt halbautomatisierte Lösungen mit großem Personaleinsatz, der andere hingegen vollrobotisierte Linien. Das ist das Faszinierende an dieser Arbeit – man sieht, wie sich verschiedene Ansätze in der Produktivität und den Ergebnissen widerspiegeln. Bei jedem Projekt lernen wir etwas Neues dazu.
Welche Branche findest du in deiner Arbeit am interessantesten?
Am meisten faszinieren mich Lager- und Logistiksysteme mit großem Warenvolumen. Dort beschäftigen wir uns nicht nur mit Software, sondern auch mit räumlicher Optimierung – wie man Waren effizient anordnet, wie man das Lager strukturiert und welches Layout den schnellsten Warenfluss ermöglicht. Je komplexer das Lager, desto größer die Herausforderung, denn wir müssen nicht nur IT-Prozesse berücksichtigen, sondern auch physische Faktoren wie Temperaturzonen, Materialhandhabung und Sicherheitsvorschriften.
Nimmst du alltägliche Dinge anders wahr als andere Menschen?
Ja, auf jeden Fall. Wenn ich zum Beispiel einkaufe und Selbstbedienungskassen oder Scanner sehe, achte ich sofort darauf, wie das System gestaltet ist – ob es intuitiv ist, wo mögliche Probleme liegen könnten. Oft überlege ich mir, wie ich das System „aushebeln“ könnte – genau wie beim Testen von Software.
Was ist die wichtigste Fähigkeit eines IT-Konsultanten?
Analytisches Denken und Problemlösungsfähigkeit. Ein Konsultant muss in der Lage sein, schnell zu erkennen, wo das Problem liegt – auch wenn er es nicht unbedingt selbst beheben kann. Wichtig ist, genau zu wissen, wo es sich befindet und wer es lösen sollte. Oft ist unsere Rolle eher diagnostisch: Wir suchen nach der Ursache des Fehlers und helfen Entwicklern oder Kunden, die beste Lösung zu finden. Das erfordert Erfahrung, aber auch die Fähigkeit, ständig zu lernen.
Welche neuen Herausforderungen bringt die Arbeit eines Konsultanten mit sich?
Jedes neue Projekt bringt etwas anderes mit sich. Auch wenn sich die Technologien wiederholen, hat jeder Kunde seine eigenen Besonderheiten. Das bedeutet, dass man, selbst wenn man glaubt, etwas zu kennen, immer wieder überrascht werden kann. Und genau das macht diese Arbeit so spannend.
Bei der Prozessoptimierung musst du dich auch auf Details konzentrieren. Welche Faktoren entscheiden über die Effizienz?
Oft sind es Kleinigkeiten, die einen enormen Einfluss auf die Effizienz haben können. Wenn jemand zum Beispiel zehn Stunden am Tag mit einem Scanner arbeitet und ständig auf eine Taste auf einer bestimmten Seite klickt, kann das einfache Verschieben dieser Taste auf die andere Seite seine Leistung erheblich verbessern. Solche Details müssen wir beim Testen erkennen – uns in die Rolle des Mitarbeiters hineinversetzen und ausprobieren, wie das System seine tägliche Arbeit beeinflusst.
Das erfordert viel Kommunikation mit dem Kunden. Wie gehst du mit den Unterschieden zwischen IT- und Nicht-IT-Nutzern um?
Ja, sehr oft ruft ein Mitarbeiter wegen eines Problems an, das ihm ein Kollege beschrieben hat, ohne selbst genau zu wissen, was passiert. Wir müssen also schnell und gezielt die richtigen Fragen stellen. Wenn jemand sagt: „Es funktioniert nicht“, kann das vieles bedeuten – von einem vergessenen Passwort bis zu einem echten technischen Defekt. Deshalb müssen wir Informationen filtern, ruhig bleiben und uns auf eine schnelle Diagnose konzentrieren.
Gibt es Vorurteile über Konsultanten, die du für falsch hältst?
Das häufigste ist wohl, dass ein Konsultant nur am Computer sitzt und testet. In Wirklichkeit ist es eine sehr vielseitige Arbeit: Neben IT-Aufgaben haben wir mit Kunden zu tun, schulen Mitarbeiter, reisen zu Betriebsstätten und analysieren reale Situationen. Wir treffen Menschen, die nicht aus der IT kommen, und müssen unsere Kommunikation so anpassen, dass sie die Lösungen verstehen.
Da du oft mit Kunden in Kontakt bist – hast du manchmal das Gefühl, mit ihnen auf einer Wellenlänge zu sein?
Ja, besonders bei langfristigen Projekten. Jeder Kunde hat jemanden, der für die Implementierung verantwortlich ist, und wenn man ein oder zwei Jahre mit dieser Person zusammenarbeitet, kennt man sich natürlich besser. Dadurch wird die Kommunikation effizienter – wir können Anforderungen schneller klären und gegenseitige Erwartungen besser verstehen.
Ein IT-Konsultant muss gewisse technische Kenntnisse haben, aber inwieweit ist Programmieren wirklich notwendig?
Man muss kein Programmierer sein, aber man muss technische Spezifikationen lesen können und Datenbanken verstehen. Ein grundlegendes Verständnis von Code und die Fähigkeit, logisch zu denken, reichen aus. Wichtig ist, analytisches Denken mit dem tatsächlichen Funktionieren der Software zu verknüpfen. Wenn man keine Spezifikationen lesen kann, erkennt man das Problem nicht, und wenn man die zugrunde liegenden Daten nicht kennt, kann man sie nicht richtig an die Entwickler weitergeben.
Welche Soft Skills sind für einen Konsultanten entscheidend?
Ganz klar Kommunikation. Und dann die Fähigkeit zur schnellen Analyse – zu wissen, was Priorität hat, was sofort gelöst werden muss und was warten kann. Ein Konsultant muss in der Lage sein, ein Problem zu identifizieren, auch wenn es nicht auf den ersten Blick sichtbar ist.
Worin musst du dich als Konsultant ständig verbessern?
Vor allem im Umgang mit verschiedenen technischen Geräten. Jeder Kunde hat etwas anderes – neue Versionen, neue Konfigurationen. Ich muss schnell lernen, wie sie funktionieren und wie man sie korrekt anschließt. Außerdem muss ich die Besonderheiten einzelner Prozesse verstehen, die oft maßgeschneidert sind.
Arbeiten IT-Konsultanten mit Daten, und kommt es vor, dass ihr auch physische Probleme lösen müsst?
Auf jeden Fall. Manchmal müssen wir physisch eingreifen – ein Gerät umstellen, einen Scanner anschließen oder bei der Hardwarekonfiguration helfen. Es kommt auch vor, dass wir Versuche entdecken, das System zu umgehen – etwa wenn jemand versucht, Daten zu manipulieren oder sich die Arbeit auf eine Weise zu „erleichtern“, die nicht mit den Prozessen übereinstimmt. Das System ist so konzipiert, dass es solche Dinge erkennt, und wir helfen den Kunden, auch solche Situationen zu lösen.
Wann hat deine Arbeit den größten Einfluss?
Den größten Einfluss habe ich in der Entwicklungsphase – beim Testen und bei der Fehlererkennung – und dann bei der Einführung, wenn alles funktionieren muss, damit der Kunde zufrieden ist.
Was gefällt dir an dieser Arbeit am meisten?
Die Verbindung von Software und realer Welt. Wir sehen, wie IT-Lösungen physische Prozesse beeinflussen. Die Arbeit ist abwechslungsreich, wir lösen immer neue Herausforderungen – und wenn ich sehe, dass das System, an dem ich gearbeitet habe, wirklich hilft, ist das ein großartiges Gefühl. Natürlich gefällt mir auch der Kontakt mit den Kunden – die Rolle der Brücke zwischen Technologie und tatsächlicher Arbeit.
Und auch die Vielfalt. Einmal befasse ich mich mit Lagerlogistik, ein anderes Mal mit einer Produktionslinie; ich teste Software, schule Mitarbeiter und finde Lösungen für unerwartete Probleme. Es gibt keinen Tag, an dem mir langweilig wäre. Und das Beste ist, wenn ich sehe, dass unsere Lösung dem Kunden wirklich hilft – dass die Abläufe besser und effizienter funktionieren und die Menschen gern damit arbeiten.
Wie sieht für dich ideale Entspannung nach der Arbeit aus?
Da die Arbeit vor allem geistig anspruchsvoll ist, ist körperliche Aktivität für mich die beste Entspannung. Ich gehe ins Fitnessstudio, laufe – das hilft mir, den Kopf freizubekommen und Energie für den nächsten Tag zu tanken.
Was würdest du jemandem raten, der als IT-Konsultant anfangen möchte?
Der Beruf des Konsultanten ist eine großartige Einstiegsmöglichkeit in die IT-Welt, weil man mit vielen Bereichen von IT und Business in Kontakt kommt. Man lernt, wie Entwickler, Analysten, Projektmanager und Kunden arbeiten. Und vor allem: Man hat ständig neue Herausforderungen – wenn man also ein dynamisches Umfeld mag, ist das eine hervorragende Karrierewahl.