Michael Schwarzer | Interim Technical Lead & Systems Architect

Einige Beispiele

Siemens Nixdorf

Zwei Systemwelten zusammenführen

Nach der Zusammenführung von Siemens und Nixdorf gehörten unterschiedliche Verfahren, Daten und Organisationen plötzlich zu einem gemeinsamen Unternehmen. In der Region Ost übernahm ich unter anderem die eigenverantwortliche Zusammenlegung der beiden Verfahren TIS und PERLE – mit Kunden, Verträgen, Gerätestandorten, Garantien und Techniker-Einsätzen, angebunden an das kaufmännische System ADVOKAD.

Dazu kamen die Analyse von Betriebs-, Produktivitäts- und Servicedaten, Entscheidungsgrundlagen für den technischen Service und die Mitarbeit an der Neuorganisation des Supports. Zu dieser Zeit leitete ich rund 25 Mitarbeiter an sechs Standorten.

Maschinenbau

IT trifft Produktion

Als IT- & Digitalisierungsleiter eines Maschinenbauunternehmens mit rund 150 Mitarbeitern gehörten klassische IT, ERP, Produktionssysteme und Maschinen zur gleichen Systemlandschaft.

Dazu zählten zwei eigene Rechenzentren, APplus, ein angebundener italienischer Standort, Produktions- und Logistiksysteme, Paternoster-Lager, Bestückungsautomation, Drehbänke und Maschinensteuerungen. Hinzu kamen Netzwerksegmentierung, Security, externe Systemhäuser, Microsoft 365, mobile Geräte, Budget und Beschaffung sowie die Untersuchung von Alternativen zum bestehenden ERP-System.

Die IT verantwortete ich fachlich und disziplinarisch und organisierte die Betreuung durch externe Systemhäuser neu.

Die interessante Frage war dabei nicht, ob etwas „IT“ oder „Produktion“ ist, sondern wovon es abhängt und was bei einer Veränderung ebenfalls betroffen wäre.

iP4.tv

Internationale Softwareentwicklung

Bei iP4.tv arbeitete ich an einer Embedded-Plattform für Set-top-Boxen. Entwicklung und Koordination verteilten sich über China, Griechenland, England und Deutschland, Kunden unter anderem über Dubai, Australien, China und Russland.

Neben der Softwareentwicklung gehörten Systemanalyse, technische Planung, Anforderungen, kundenspezifische Anpassungen, Integration, Tests und Auslieferung zur Aufgabe.

Produktion

Wenn Produktion möglichst nicht stehen soll

Bei einer Plattform mit zeitweise rund 5.000 gleichzeitigen Zuschauern gehörte später auch der Produktionsbetrieb zu meiner Verantwortung. Die Infrastruktur wurde von Prag nach Amsterdam migriert. Die Unterbrechung betrug dabei ungefähr zwei Sekunden.

Solche Migrationen interessieren mich weniger wegen des Umzugs selbst als wegen der Frage, welche Abhängigkeiten vorher verstanden und welche Schritte vorbereitet werden müssen, damit der eigentliche Wechsel möglichst unspektakulär wird.

Heute

Eigene Systeme

Heute entwickle ich unter anderem eigene Software, Dienste und Werkzeuge nach den Prinzipien von Biocodie: kleine, eigenständige und klar abgegrenzte Systeme mit definierten Verantwortlichkeiten, Schnittstellen und Regeln.

Ein aktuelles Beispiel ist das OpenBookRegister, eine offene und föderierte Infrastruktur für Buch- und Publikationsdaten mit APIs, Datenmodellen, dezentralen Identifikationsverfahren und Schnittstellen für Handels- und Kassensysteme.

Daneben betreibe und entwickle ich eigene Unix-, Linux- und OpenBSD-Infrastruktur.

Wie ich arbeite

Komplexe und schwierige Aufgaben

Ich finde mich schnell in komplexe Aufgaben und technische Zusammenhänge ein. Dabei kann es um ein neues System gehen, um einen schwer zu findenden Fehler oder um eine Situation, in der bisherige Lösungsversuche nicht zum Ziel geführt haben.

Entscheidend ist zunächst herauszufinden, was tatsächlich passiert und wo die Ursache liegt.

Nicht jede Aufgabe beginnt mit einer klaren Spezifikation. Manchmal gibt es ein gewachsenes System, unvollständige Dokumentation, widersprüchliche Informationen und mehrere Beteiligte mit jeweils einem anderen Blick auf das Problem. Dann beginnt meine Arbeit mit der Untersuchung.

Systeme und Zusammenhänge

Ich betrachte Systeme auf unterschiedlichen Ebenen. Dabei interessieren mich sowohl technische Details als auch Schnittstellen, Abhängigkeiten und das Zusammenspiel mit anderen Systemen und betrieblichen Abläufen.

Je nach Aufgabe kann der Blick deshalb von Software und Infrastruktur bis in Produktion oder Organisation reichen.

Ein technisches Problem ist nicht zwangsläufig allein technisch zu lösen. Entscheidend ist, die relevanten Zusammenhänge zu erkennen.

Unterschiedliche Rollen

Welche Rolle ich übernehme, hängt von der Aufgabe ab. Das kann eine technische Detailfrage ebenso sein wie Systemanalyse, Architektur, Integration, Projektarbeit oder eine zeitlich begrenzte technische Leitung.

Ich muss nicht dauerhaft Architekt sein, nur weil eine Aufgabe Architektur benötigt. Und ich muss nicht dauerhaft führen, nur weil für einige Monate technische Führung gebraucht wird.

Die Aufgabe bestimmt die Rolle.

Bestehendes verändern

Bevor bestehende Systeme verändert werden, möchte ich verstehen, wie sie tatsächlich funktionieren und wie ihre Bestandteile zusammenwirken.

Erst dann lässt sich sinnvoll entscheiden, was erhalten, ersetzt, integriert oder modernisiert werden sollte.

Architektur ist dabei häufig das Ergebnis der Untersuchung und nicht deren Ausgangspunkt.

Angebote

Klar abgegrenzte Aufgaben, die nicht gleich ein Mandat sein müssen. Umfang und Konditionen kläre ich vorab in einem kurzen Gespräch.

IT-Krisenkompass

Orientierung für den IT-Ernstfall

Wenn die IT ausfällt, beginnt die Wiederherstellung oft nicht mit der Reparatur, sondern mit der Suche: nach Ansprechpartnern, Backups, Ersatztechnik und der Frage, was zuerst wieder laufen muss. Der IT-Krisenkompass fasst das Wesentliche auf etwa zehn Seiten zusammen, für den, der von außen kommt und das Unternehmen nicht kennt.

Pilotangebot: die ersten drei Aufträge zum Festpreis von 3.500 € netto, bei klar abgegrenztem Umfang.

Zum IT-Krisenkompass

Dienstleister-Abgleich

Vertrag, Erwartung und Wirklichkeit auf einen Nenner bringen

Verträge und SLAs sagen, was zugesagt ist. Die Geschäftsführung erwartet häufig etwas anderes, und das Systemhaus leistet, was es für vereinbart hält. Im Ausfall zeigt sich die Differenz, meist zu spät.

Dienstleisterverträge und SLA-Definitionen sichten.
Erwartungen der Geschäftsführung getrennt erheben.
Fachgespräch mit dem Systemhaus, ohne Geschäftsführung.
Danach alle Beteiligten zusammenbringen und Abweichungen und Handlungsoptionen klären.

Ziel ist nicht, Schuldige zu finden. Systemhäuser sind Partner; es geht um einen wirtschaftlich tragfähigen gemeinsamen Nenner zwischen Bedarf, Vertrag und operativer Wirklichkeit.

Ergebnis: ein kurzer Bericht mit Risiken, abgestimmten Erwartungen und priorisierten Optionen. Juristische Vertragsauslegung ist nicht enthalten und kann bei Bedarf gesondert hinzukommen.

Umfang: klar begrenzt auf ein Unternehmen und einen wesentlichen Dienstleister, etwa 2 bis 3 Tage. Reise- und Nebenkosten ab Startort Freiburg werden nach Aufwand gesondert berechnet.

Referenz: Im Maschinenbau habe ich IT-Dienstleister bewertet und ausgetauscht, die Betreuung durch Systemhäuser neu organisiert und Verträge geprüft und angepasst.

Anfragen · per E-Mail

Business & Technologie

Der kaufmännische Teil hat bei mir früher begonnen als der technische: Mit zehn habe ich im elterlichen Handelsbetrieb mitgeholfen, lange vor dem ersten Computer.

Seitdem habe ich Unternehmen aufgebaut und geführt, kalkuliert, eingekauft und verkauft, Löhne und Gehälter abgerechnet, Produkte entwickelt, Projekte geleitet, Software geschrieben, Systeme betrieben, Mitarbeiter geführt, Budgets geplant, Verträge vorbereitet und mit Kunden, Lieferanten und externen Dienstleistern gearbeitet.

Deshalb sind meine Analysen nie nur technisch: Technische Entscheidungen betrachte ich immer auch im betrieblichen Zusammenhang. Eine technisch elegante Lösung ist nicht automatisch eine gute Lösung. Sie muss zum Unternehmen, zu den vorhandenen Systemen, zu den Menschen, zu Kosten und Risiken und zur beabsichtigten Entwicklung passen.

Umgekehrt lassen sich betriebliche Entscheidungen häufig nicht sinnvoll treffen, ohne ihre technischen Abhängigkeiten zu verstehen.

Meine Weiterbildung zum Digital Manager (wvib) hat diesen unternehmensweiten Blick noch einmal systematisch über Strategie und Geschäftsmodelle, Produktentwicklung, Produktion, Einkauf und Logistik, Marketing und Vertrieb, Organisation, Personal, IT, Informationssicherheit und rechtliche Rahmenbedingungen geführt.

Zusammenarbeit

Je nach Aufgabe übernehme ich Rollen in Systemanalyse, Technical Discovery, System- und Integrationsarchitektur, technischer Projektleitung oder zeitlich begrenzter technischer Leitung.

Besonders interessant sind für mich komplexe Analyse-, Integrations-, Modernisierungs- und Troubleshooting-Aufgaben, bei denen technische und betriebliche Zusammenhänge zunächst verstanden und belastbare Entscheidungsgrundlagen geschaffen werden müssen.

Ich arbeite projektbezogen und freiberuflich, auch im Rahmen von Interim-Mandaten. Remote-Arbeit ist ebenso möglich wie Vor-Ort-Einsätze und projektbezogene Reisetätigkeit. Auch internationale Projekte sind willkommen.

Wichtig sind ein klarer Verantwortungsbereich und ausreichender Zugang zu den Systemen, Informationen und Ansprechpartnern, die für Analyse und Entscheidung relevant sind.

Systems AnalysisTechnical DiscoverySystems ArchitectureIntegrationTechnical LeadershipProject ManagementLegacy ModernizationTroubleshooting

Und was sonst noch entsteht

Neben der Projektarbeit entwickle ich eigene Software und beschäftige mich mit Betriebssystemen, KI und ihren Möglichkeiten und Grenzen sowie mit Publikationen und Wissensvermittlung.

Hinzu kommen eigene Konzepte zur organischen und systemorientierten Softwareentwicklung und die Beschäftigung mit komplexen Systemen und gesellschaftlichem Zusammenleben.

Dabei entstehen Software, technische Artikel, Bücher, Konzepte und gelegentlich Dinge, für die es noch keine besonders brauchbare Schublade gibt.