Vom Low‑Code zur Teamleitung: Julia Keplinger, IT Team Lead bei Quehenberger Logistics, über Schnittstellen‑Kompetenz im Transportmanagement

Warum diese Story Entwickler:innen anspricht

In „Julia Keplinger, IT Team Lead bei Quehenberger Logistics“ zeichnet Speakerin Julia Keplinger einen klaren, bodenständigen Weg in der Logistik‑IT nach: von der schulischen Basis über Low‑Code‑Arbeit im Transportmanagementsystem bis hin zur Teamleitung eines IT‑Competence‑Centers. Was uns bei DevJobs.at besonders beeindruckt hat, ist, wie konsequent sie ihre Rolle als „menschliche Schnittstelle“ zwischen Logistik, Fachbereichen und Softwareentwicklung versteht – und wie sehr Neugier, Struktur und Kommunikation die Leitplanken ihrer Arbeit bilden.

Die Story liefert handfeste Impulse für alle, die in komplexen Domänen Software bauen, betreiben oder weiterentwickeln. Keplinger zeigt, dass erfolgreiche IT‑Arbeit in der Logistik nicht nur aus Code besteht, sondern aus dem präzisen Verstehen von Anforderungen, stringenter Qualitätssicherung, sauberer Dokumentation und gemeinsamer Sprache zwischen allen Beteiligten.

Eine fundierte Basis: HAC im Zweig Informationsmanagement und Technologie

Keplingers Weg beginnt in der HAC, im Zweig Informationsmanagement und Technologie. Dort verband sie wirtschaftliche Allgemeinbildung mit praxisnahen Einblicken in die digitale Welt:

• Bild‑ und Videobearbeitung
• Webdesign mit HTML und CSS
• Programmierung mit Visual Basic und SQL

Dieser Mix aus wirtschaftlichem Grundverständnis und solider technischer Basis klingt in ihrer heutigen Rolle deutlich nach: Sie bewegt sich selbstverständlich zwischen Fachbereichsthemen und Softwareentwicklung, prüft Geschäftsanforderungen auf Herz und Nieren und übersetzt sie in umsetzbare Arbeitspakete.

Direkter Berufseinstieg: Quehenberger Logistics als passender Startpunkt

Nach der Schule beginnt Keplinger direkt bei Quehenberger Logistics. Ausgeschrieben war eine Stelle, die eine kaufmännische Ausbildung und Programmiergrundkenntnisse verlangte – genau die Kombination, die sie mitbrachte.

Sie startet als IT‑Administratorin im Bereich des Transportmanagementsystems (TMS). Ihre Hauptaufgabe: fachliche Logik in einer Low‑Code‑Umgebung zu modellieren – „mit logischen Entscheidungen und Schleifen“, wie sie beschreibt. Das ist ein wichtiges Detail: Low‑Code heißt nicht „ohne Logik“, sondern verlangt das präzise Abbilden von Regeln und Abläufen in einer Plattform, die diese Logik trägt und mit dem operativen Geschäft verzahnt.

In dieser frühen Phase findet Keplinger einen Platz in einer Abteilung, deren Fokus auf IT‑Organisation und Softwareentwicklung liegt. Sie beschreibt, wie sie dort „im Job wahnsinnig viel dazulernen“ konnte – fachlich getragen von Wertschätzung und Motivation. Aus dieser Lernumgebung heraus baut sie ihre Fähigkeiten in Projektmanagement und Software‑Support kontinuierlich aus.

Vom Low‑Code zur Leitung: Verantwortung im IT‑Competence‑Center

Heute leitet Julia Keplinger ein IT‑Competence‑Center, das „alle Anfragen und Projekte rund um die Abrechnung“ betreut. Quehenberger Logistics ist ein internationales Logistikunternehmen, „in mehrere Länder vertreten“ – entsprechend vielfältig sind die Aufgaben und „spannenden internationalen Projekte“, die auf ihrem Tisch landen.

Der Schritt in die Teamleitung wirkt in ihrer Erzählung nicht wie ein Sprung, sondern wie eine logische Folge ihrer Kompetenzentwicklung: Sie hat Anforderungen verstanden, sie kritisch hinterfragt, in die Umsetzung gebracht, getestet, dokumentiert und die Prozesse überwacht. Genau diese Kette prägt auch ihre heutige Führungsperspektive.

Die „menschliche Schnittstelle“ im Transportmanagementsystem

Keplinger beschreibt ihre Rolle im IT‑Projektmanagement des Transportmanagementsystems mit einem Satz, der hängen bleibt:

Was das konkret bedeutet, strukturiert sie klar – über den klassischen Second‑Level‑Support hinaus:

1. Anforderungen entgegennehmen
2. Kritisch hinterfragen und analysieren
3. An die Softwareentwicklung zur Umsetzung übergeben
4. Vor der Implementierung ins Echt‑System umfassend testen
5. Entsprechende Dokumentationen erstellen
6. Prozesse überwachen und kontinuierlich verbessern

Diese sechs Schritte bilden den Alltag vieler Tech‑Teams, werden aber erst durch konsequente Kommunikation und ein gemeinsames Verständnis wirklich wirksam. Keplinger betont genau das: Nur wenn alle Beteiligten dasselbe Zielbild teilen, kann ein Projekt erfolgreich sein.

Qualität als Prozess: Testen, Dokumentieren, Überwachen

Auffällig ist, wie stark Keplinger Qualitätssicherung als geschlossenen Kreislauf denkt. Bevor Funktionen ins „Echt‑System“ gehen, wird „umfassend getestet“. Die dazugehörigen Dokumentationen sind nicht Beiwerk, sondern integraler Teil des Projekts. Und nach dem Go‑Live endet die Arbeit nicht: „Damit sich der Kreislauf dann auch erfolgreich schließt, werden die Prozesse von uns dann auch überwacht und man schaut, dass man sich kontinuierlich verbessern kann.“

Wer Logistik‑IT kennt, weiß: Nur so lassen sich Ketten aus Business‑Regeln, operativen Abläufen und technischen Abhängigkeiten zuverlässig steuern. Keplinger formuliert keine Methodenschemata – sie beschreibt das, was wirkt: iterative Sorgfalt, die sich im Ergebnis bemerkbar macht.

Abwechslung als Antrieb: Lernen am Schnittpunkt

Was motiviert sie? Vor allem die Vielfalt:

• Ein Tag im engen Austausch mit den Fachbereichen – mit Einblicken ins „Daily Business“.
• Am nächsten Tag Gespräche mit Softwareentwickler:innen – neue Erkenntnisse und „Aha‑Momente“.

Diese rhythmische Bewegung zwischen Fachlichkeit und Technik ist nicht nur abwechslungsreich, sie ist ihre Lernmaschine. Keplinger bringt es auf den Punkt: „Das ist das, was mir mitunter so gut gefällt, dass ich mich im Job weiterbilden kann. Und das ist ja die Basis, dass ich irgendwo persönlich wachsen kann. Es ist einfach wichtig, dass ich eine Perspektive habe in meinem Job.“

Herausforderung Komfortzone: Veränderung aktiv treiben

Zur Wahrheit gehört auch: Projektmanagement in der Logistik konfrontiert einen regelmäßig mit neuen Themen. Keplinger macht daraus keinen Hehl. Sie sieht die Herausforderung – und formuliert die Haltung, mit der sie ihr begegnet:

Dieser Satz ist mehr als ein persönliches Bekenntnis. Er ist eine Anleitung für Rollen, die zwischen Stakeholdern vermitteln: Wer Veränderungen gestaltet, statt ihnen hinterherzulaufen, stiftet Orientierung – und schafft Vertrauen.

Mindset vor Zertifikat: IT‑Verständnis, Neugier, Lernbereitschaft

Keplinger betont, „ganz unabhängig von der Ausbildung“, worauf es für sie ankommt:

• ein „gewisses IT‑Verständnis“
• Offenheit für Neues
• echte Lernbereitschaft

Am Puls der IT zu bleiben, sei „leichter gesagt als getan“. Deshalb der vielleicht zentrale Rat aus ihrer Story: „Man darf auch einfach seine Neugierde nicht verlieren.“ Lernen passiert dabei nicht nur in Kursen – „man kann sich auch in seinem Umfeld wahnsinnig viel abschauen und sich auch gegenseitig wo antreiben und pushen.“

Die Soft‑Skills, die Projekte tragen

Zu den klassischen Soft‑Skills zählt Keplinger:

• eine strukturierte und eigenständige Arbeitsweise
• analytisches Denken „als Basis vom Projektmanagement“
• klare Kommunikation und funktionierende Zusammenarbeit

Besonders der letzte Punkt ist ihr wichtig: „Man kann eben nur erfolgreich sein im Projektmanagement, wenn alle das gleiche Verständnis haben.“ Und ihr Schlussbild ist einprägsam:

Praktische Takeaways für Tech‑Teams in der Logistik

Was lässt sich aus Keplingers Weg konkret in den Alltag übertragen? Aus unserer Sicht bei DevJobs.at vor allem diese Punkte:

• Anforderungen sind Hypothesen – bis sie analysiert sind. „Kritisch hinterfragen“ bedeutet: Problem, Wirkung und Ziel klar voneinander trennen.
• Low‑Code braucht Logik. Entscheidungen und Schleifen korrekt zu modellieren ist Handwerk – unabhängig davon, ob man Code schreibt oder Bausteine konfiguriert.
• Second‑Level‑Support ist Wissensdrehscheibe. Wer hier Muster erkennt, kann Anforderungen präziser formulieren und Prioritäten begründen.
• Testen ist Teil der Umsetzung, nicht der Abnahme. Umfassende Tests vor dem „Echt‑System“ schützen Fachbereiche und Entwicklung gleichermaßen.
• Dokumentation ist Produktpflege. Sie reduziert Abhängigkeiten von Einzelpersonen und schafft Anschlussfähigkeit für neue Kolleg:innen.
• Prozesse überwachen, um zu lernen. Monitoring liefert die Basis für „kontinuierliche Verbesserung“ – nicht als Buzzword, sondern als Arbeitsroutine.
• Kommunikation schafft gemeinsame Sprache. Ohne geteiltes Verständnis verpuffen die besten Umsetzungen im Alltag.

Ein Karrierepfad, der Mut macht

Keplingers Weg zeigt: Ein Einstieg über Low‑Code‑Plattformen kann ein kraftvoller Hebel sein, Domänenlogik schnell zu verstehen und Verantwortung zu übernehmen. Entscheidend ist weniger, welche Technologie im Vordergrund steht, sondern wie konsequent man Anforderungen erfasst, Qualität sichert und den Dialog zwischen Fachbereichen und Entwicklung moderiert.

Wer sich in dieser Schnittstellenrolle wohlfühlt, baut automatisch die Kompetenzen auf, die später in der Teamleitung gefragt sind: Priorisieren, Entscheidungen vorbereiten, Risiken antizipieren, Erwartungen synchronisieren – und Ergebnisse so dokumentieren, dass sie tragen.

Leitfragen für den Anforderungs‑Check

Aus Keplingers Beschreibung des Arbeitsflusses lassen sich einfache Leitfragen ableiten, die jedes Ticket, jede Anforderung und jedes Change‑Request strukturieren:

• Was ist das konkrete Ziel des Fachbereichs? (Nicht: Welche Lösung wird gewünscht?)
• Welche Auswirkungen hat die Änderung auf angrenzende Prozesse?
• Welche Regeln, Entscheidungen und Schleifen müssen modelliert werden?
• Wie wird die Umsetzung getestet, bevor sie ins Echt‑System geht?
• Welche Dokumentationen braucht es, damit das Wissen nachhaltig bleibt?
• Welche Metriken oder Beobachtungen nutzen wir, um den Erfolg zu prüfen und Verbesserungen anzustoßen?

Diese Fragen sind nicht neu – aber sie wirken, wenn man sie konsequent stellt. Genau das klingt in Keplingers Vorgehen an.

Alltag mit Perspektive: Lernen als Dauerlinie

Keplinger beschreibt ihren Arbeitsalltag als Abfolge von Kontakten mit Fachbereichen und Entwickler:innen, unterlegt mit Aha‑Momenten. Dieser Wechsel schafft nicht nur Abwechslung, sondern garantiert kontinuierliches Lernen. Und Lernen ist für sie Voraussetzung für persönliche Entwicklung – sowie ein Kriterium, das sie in ihrem Job unbedingt sehen will: „Es ist einfach wichtig, dass ich eine Perspektive habe in meinem Job.“

Für Teams ist das eine Einladung, Lerngelegenheiten sichtbar zu machen: Anforderungen gemeinsam sezieren, Entscheidungen begründen, Ergebnisse reviewen, Wissen dokumentieren – all das verankert Lernen im Arbeitsfluss, nicht nur in Trainings.

Veränderung aktiv treiben: Ein Kompass für Projektleiter:innen

Veränderung ist in der Logistik Dauerzustand – neue Länder, neue Kunden, neue Prozesse. Keplingers Haltung, Veränderungen „aktiv anzutreiben und zu pushen“, liefert einen Kompass: Proaktivität heißt, Erwartungen zu synchronisieren, Risiken früh zu benennen, Spielräume zu nutzen und Feedback schnell in Verbesserungen zu überführen.

Wer das lebt, zieht Vertrauen nach sich – bei Fachbereichen genauso wie in der Entwicklung. Vertrauen, das braucht, was Keplinger immer wieder betont: das „gleiche Verständnis“ und die „gleiche Sprache“.

Fazit: Die gleiche Sprache sprechen – nicht nur in Code

„Julia Keplinger, IT Team Lead bei Quehenberger Logistics“ lässt wenig Zweifel: Erfolg in der Logistik‑IT entsteht dort, wo Menschen Domänenlogik ernst nehmen, sauber zwischen Problem und Lösung unterscheiden und technische Umsetzung als Teamleistung verstehen.

Keplingers Karriere zeigt, wie weit man mit Neugier, strukturierter Arbeitsweise und analytischem Blick kommt – von den ersten HTML/CSS‑ und Visual‑Basic‑Zeilen in der HAC über Low‑Code‑Workflows im Transportmanagementsystem bis zur Teamleitung eines IT‑Competence‑Centers.

Oder in ihren eigenen Worten: Es geht darum, sich „auf sein Gegenüber einzulassen“ und „die gleiche Sprache“ zu sprechen – „und da rede ich jetzt nicht von einer Programmiersprache.“ Genau das macht aus wechselnden Anforderungen nachhaltige Ergebnisse.

• 

  

  Alexander Reichl, Product Owner bei Quehenberger Logistics

  Product Owner bei Quehenberger Logistics Alexander Reichl erzählt im Interview über die Organisation der Teams im Unternehmen, auf was bei neuen Bewerbungen geachtet wird und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen
• 

  

  Bernhard Kriechbaum, Team Lead IT Project Management bei Quehenberger Logistics

  Team Lead IT Project Management bei Quehenberger Logistics Bernhard Kriechbaum gibt im Interview Einblicke in den Aufbau der IT Abteilung, an welchen technologischen Challenges dort gearbeitet wird und wie das Recruiting und Onboarding abläuft.

  Jetzt ansehen