IDEACTORY
ErfahrungArbeitsweiseResearchOpen Channel
Jonas Ehlers
PROFILE / RESEARCH / TECHNOLOGIE

Jonas
Ehlers

Technologie · Systeme · Automatisierung

Technik ist gut, wenn sie Arbeit abnimmt. Nicht wenn sie neue Arbeit erfindet.

Jonas hat IT von unten nach oben kennengelernt: erst die Geräte, dann die Netze, dann die Anwendungen und irgendwann die Frage, warum Menschen dieselben Daten eigentlich dreimal eingeben. Seitdem baut er lieber Verbindungen als neue Inseln.

SystemeSchnittstellenAutomatisierungPrototypenBetrieb
„Bevor wir etwas Neues kaufen, würde ich gern wissen, was die vorhandenen Systeme eigentlich schon können.“
EXPERIENCE

Jonas hat Technik nicht als Innovationsfolie kennengelernt. Sondern als etwas, das morgens funktionieren muss.

Drucker, Benutzerkonten, Netzwerke, Server, Fachanwendungen, Datenimporte, Backups und die sehr konkrete Verantwortung, wenn jemand gerade nicht arbeiten kann. Das prägt den Blick auf „digitale Lösungen“ nachhaltig.

Ausbildung
Interne IT · mittelständischer Produktionsbetrieb

Die erste Cloud war ein Serverschrank im Keller.

Jonas machte seine Ausbildung zum Fachinformatiker für Systemintegration in einer internen IT. Rund zweihundert Arbeitsplätze, Produktionsrechner, Drucker, Telefonie, Benutzerkonten und eine Mischung aus moderner Software und Dingen, die „schon immer da“ waren.

Er lernte Support, Netzwerke und Administration – und vor allem: Technik ist für Nutzer genau dann interessant, wenn sie nicht funktioniert.

SupportNetzwerkArbeitsplätzeAdministration
danach
Systemadministration · Unternehmen mit mehreren Standorten

Wenn Standort B Standort A nicht sieht, wird es schnell sehr real.

Später betreute Jonas Infrastruktur über mehrere Niederlassungen: Standortvernetzung, Rechte, Datensicherung, Telefonie, Serverdienste und die Koordination externer Dienstleister. Störungen bedeuteten nicht „Ticket offen“, sondern unter Umständen: ein ganzer Standort arbeitet gerade nicht.

In dieser Zeit wurde er ziemlich konservativ an einer Stelle: Ein System darf spannend gebaut sein. Der Betrieb sollte es möglichst nicht merken.

StandorteBackupBerechtigungenDienstleister
Anwendungen
Anwendungsbetreuung · Warenwirtschaft, CRM & Dokumente

Daten haben die unangenehme Angewohnheit, gebraucht zu werden. Oft woanders.

Jonas wechselte stärker in die Anwendungsseite. Er betreute Warenwirtschaft, CRM und Dokumentenmanagement, baute Importe, Exporte und kleinere Schnittstellen und kümmerte sich um die Fälle, bei denen zwei Systeme unterschiedliche Vorstellungen von derselben Realität hatten.

Viele seiner ersten Automatisierungen entstanden nicht aus Strategie, sondern aus Mitleid mit Menschen, die jeden Freitag dieselben Dateien kopierten. Wenn etwas zuverlässig wiederholt wird, kann ein Rechner es sich zumindest einmal ansehen.

FachanwendungenDatenSchnittstellenAutomatisierung
Entwicklung
Interne Werkzeuge · Automatisierung & Prototypen

Nicht jede Lösung braucht ein neues Produkt.

Mit der Zeit baute Jonas eigene kleine Anwendungen, Skripte und Integrationen: Datentransfers, Prüfungen, Benachrichtigungen, interne Oberflächen und Prototypen, die konkrete Lücken zwischen vorhandenen Systemen schlossen.

Er lernte dabei, dass ein 200-Zeilen-Skript manchmal wertvoller ist als ein sechsmonatiges Plattformprojekt. Und manchmal genau das Gegenteil stimmt. Die Technik ergibt sich aus der Aufgabe, nicht aus der Lieblingswerkzeugkiste.

SkripteAPIsPrototypenIntegrationen
heute
IDEACTORY · Technologieperspektive

Technik darf kompliziert sein. Die Nutzung muss es nicht merken.

Heute prüft Jonas, was technisch schon vorhanden ist, welche Schnittstellen erreichbar sind und wo Automatisierung oder Software wirklich etwas verbessert. Er baut Prototypen schnell genug, um Ideen zu testen, und Systeme solide genug, um sie später nicht jeden Dienstag neu starten zu müssen.

Er mag neue Technik. Er hält Neuheit nur nicht für ein Qualitätsmerkmal.

ArchitekturAutomatisierungSoftwareIntegration
NOTICES

Technische Schulden machen selten Geräusche. Bis sie es tun.

Jonas interessiert sich für die unscheinbaren Stellen, an denen Systeme seit Jahren irgendwie miteinander auskommen. Dort liegt oft erstaunlich viel Potenzial – oder eine sehr gute Begründung, nichts anzufassen.

01
Die Datei „export_final_neu2.csv“.

Ein Dateiname mit erstaunlich viel Prozessgeschichte.

02
Daten, die aus System A exportiert und in System B wieder eingetippt werden.

Jonas wird an dieser Stelle auffällig still.

03
Die Schnittstelle, die „nur vorübergehend“ gebaut wurde.

2017.

04
Ein Tool, dessen einziger Administrator nicht mehr im Unternehmen ist.

Dokumentation: „müsste irgendwo liegen“.

05
Die monatliche Auswertung, für die jemand vier Stunden Excel spielt.

Meistens ein guter Kandidat für ein kleines Gespräch.

WORKING MODE

Erst Bestand aufnehmen. Dann Technik bauen.

Jonas beginnt nicht mit einem Stack. Er will wissen, welche Systeme da sind, welche Daten wo entstehen, was bleiben muss und welche Risiken real sind. Danach entscheidet sich, ob ein Script, eine Schnittstelle, ein neues Tool oder gar nichts gebraucht wird.

IN PROJECT

So wenig neue Technik wie möglich. So viel wie nötig.

Jonas verbindet vorhandene Systeme, automatisiert wiederkehrende Arbeit und baut Prototypen, wenn eine Idee erst ausprobiert werden muss. Wenn eine bestehende Funktion reicht, nutzt er sie. Wenn eine saubere Neuentwicklung sinnvoller ist, baut er die.

Kein neuer Stack nur deshalb, weil man einen neuen Stack bauen kann.

BORING IS GOOD

Im Betrieb darf Technik langweilig werden.

Jonas mag den Moment, in dem etwas zum ersten Mal funktioniert. Noch lieber mag er den Zustand sechs Monate später, wenn niemand mehr darüber spricht, weil es einfach läuft. Monitoring, Rechte, Fehlerfälle und Rückwege gehören für ihn deshalb zur Lösung und nicht zum Kleingedruckten.

Der Maßstab: weniger Handarbeit, weniger Fehlerquellen und kein neues Hobby für die interne IT.

SEEN BEFORE

Eine Geschichte, die hängen geblieben ist.

Kein „Case“. Eher einer dieser Momente, in denen Erfahrung entsteht.

Schnittstelle ohne API

Das Altsystem konnte keine Schnittstelle. Angeblich.

Ein älteres Fachsystem musste regelmäßig Daten an eine neuere Anwendung liefern. Eine direkte API gab es nicht, ein kompletter Austausch des Systems wäre für diesen Zweck absurd gewesen. Bisher exportierte eine Mitarbeiterin Listen, bereinigte sie manuell und importierte sie weiter.

Jonas baute keinen Ersatz für das Altsystem. Er nutzte dessen vorhandene Exportfunktion, automatisierte Prüfung und Übertragung und ergänzte eine kleine Kontrolloberfläche für die Fälle, die tatsächlich menschliche Entscheidung brauchten.

  • bestehenden Export stabilisiert
  • Datenprüfung automatisiert
  • Übertragung zeitgesteuert
  • Fehlerfälle sichtbar statt unsichtbar gemacht
Was Jonas daraus mitgenommen hat

„Keine Schnittstelle“ heißt manchmal nur: keine schöne Schnittstelle.

Technische Eleganz ist wichtig. Aber sie ist nicht dasselbe wie technische Vernunft. Jonas baut lieber eine überschaubare Brücke mit Geländer als eine neue Autobahn zu einem Ort, an den zweimal am Tag jemand fahren muss.

„Ich ersetze kein funktionierendes System, nur weil ich die neue Lösung interessanter fände.“

↻
OFF DUTY

Jonas baut Gitarreneffektgeräte.

Er spielt genug Gitarre, um zu hören, ob sie funktionieren, aber nicht genug, um damit anzugeben. Der eigentliche Spaß ist das Bauen: Schaltung, Gehäuse, Regler, Fehler suchen und am Ende dieser kurze Moment, wenn aus einem trockenen Signal plötzlich genau das Geräusch kommt, das vorher nur im Kopf war.

Einige Pedale sind sinnvoll. Andere existieren, weil Jonas wissen wollte, was passiert. Beides ist für ihn ein ausreichender Grund.

In seinem Arbeitszimmer gibt es außerdem eine Kiste mit Kabeln, die nach eigener Aussage „definitiv noch gebraucht werden“. Seine Familie führt dazu keine weiteren Gespräche.