Werkzeuge

Ersetzen proprietärer Software, ein Erfahrungsbericht

Im Jahr 2022 musste bei mir einiges an proprietärer Software gehen. Wie und was ersetzt wurde, möchte ich in diesem Artikel aufzeigen.

Mein Arbeitsplatz

Ähnlich wie Ferdinand verdiene ich mein Geld mit IT. Derzeit bin ich für drei Gesellschaften tätig und verwalte dort von Layer 1 bis Layer 8 alles, was irgendwie mit IT, Vertragsmanagement, FiBu oder Controlling zu tun hat. Bedingt durch das Tätigkeitsfeld ist es überhaupt nicht einfach auf Open Source zu setzen, WebEx, Microsoft Office und so manches CRM gehören einfach dazu.

Mein Daily-Driver ist ein MacBook Pro 14″ mit M1 Max Prozessor sowie 32GB RAM und einer 4TB SSD. Wenn ich im Homeoffice bin ist es an ein Thunderbolt Dock angeschlossen das drei WQHD Monitore befeuert. Diverse softwareseitige Bastellösungen mussten her um mit einem Apfel in einer Windows-Domäne sowie DATEV-Umgebung kompatibel zu sein. Ein M1 musste es wegen der guten Akkulaufzeit werden, ein Arbeitstag von 10 Stunden stellt kein Problem dar. Mehr gibt es zu dem Gerät nicht zu sagen, jeder der MacBooks kennt, weiß worauf er sich einlässt.

Passwort-Manager

Wegen Abomodellen, Speicherung bei US-Anbietern und ständigen Datenlecks kommt etwas “cloudiges” für Passwörter nicht in Frage. Da bleibt heutzutage nicht mehr viel übrig, da alles “verzwangsclouded” wird. Enpass wäre einer der wenigen die lokalen WLAN Sync können, aber da gehts in Richtung Abo – noch dazu ist es Closed Source.

Letztendlich wurde es good old KeePassXC mit Sync durch die eigene Cloud. Ein Feature was ich dort schon immer vermisst habe sind verschiedene Einträge wie WLAN’s, Softwarelizenzen, Zahlkarten etc. Nicht alles ist immer eine URL+User+Passwort. Ein Bug Report dazu wird nun endlich zur Version 2.8.0 bearbeitet! Hier bin ich glücklich und werde ich auch bleiben.

Videokonferenzen

Ab einer gewissen Unternehmensgröße kann man seinen Lieferanten die Lösung vorsetzen. Davon bin ich kein Freund und pflege lieber ein freundschaftliches Verhältnis zu allen. In diesem Punkt habe ich allerdings davon Gebrauch gemacht und meinen Dickschädel durchgesetzt. Es war zu Beginn des Lockdowns ein Desaster: Der eine kann nur Teams, schickt man ihm eine WebEx Einladung dreht sein Admin durch, weil er angerufen wird, da es nicht startet (gut so! AppLocker sei dank!). Die Deutsche Telekom hat intern wie Extern nur WebEx und haben ihre Schmerzen mit Teams. Ein Softwarelieferant nutzt einen öffentlichen Jitsi usw. Es herrscht generell Wildwuchs da draußen.

Alle Lieferanten sowie die potentiellen, Nextcloud Talk-en nun mit mir. Bei manchen ging das echt einfach, Größen wie die Telekom tun sich damit etwas schwer. Aber einen Großkunden stößt man ja mit sowas nicht vor den Kopf, sondern macht einfach mit. Also ist der ViKo-Bereich ebenfalls erfolgreich ge-open-sourced.

CRM/ERP/FiBu

Keine Chance, vergesst es. Hört auf zu suchen, spart euch die Zeit. Es gibt gute Ansätze wie z.B. InvoiceNinja. Doch dieses, als auch Eigenentwicklungen, sind nicht GoBD Konform. Kann man machen, weder meine Geschäftsführer:innen noch ich haben Lust darauf, dass uns das Finanzamt “die Bude auseinandernimmt”. Selbes für FiBu, DATEV ist leider unangefochten. Ungern gebe ich es zu, aber deren Rechnungswesen sowie Unternehmen online ist einfach super (aus Anwendersicht). Fraglich ob Open Source das so liefern kann wie es eine DATEV kann. Haftungsfragen sind da auch noch ein Thema. Rechnet das Programm irgendetwas falsch zusammen und der Kunde klagt dagegen wird jeder Endanwender aussagen “Ich hab das mit Tool X gemacht, das benutzen wir immer”. Wird Tool X dann genauer angeschaut… Über den Rest möchte ich garnicht erst nachdenken. So hat man immer noch die Möglichkeit den Softwarehersteller in die Haftung zu nehmen, er hat seine Software schließlich zertifizieren lassen und so verkauft.

Was man dem Finanzamt vielleicht in dem Zusammenhang auch mal sagen könnte: Ist eine CRM/ERP/FiBu-Software on Premise, habe ich Zugriff auf die Datenbank. Bei den Meisten sind die Spalten nicht mal verschlüsselt. Ich könnte also bei DATEV Werte ändern. Beispiel DATEV und “pseudo-kopierschutz”, sie liefern einen eigenen, angepassten Microsoft SQL Server aus und ein eigenes Verwaltungstool DATEV SQL Manager. Andocken mit einem SQL Management Studio unmöglich, da das Passwort für den “sa” Benutzer nur auf Antrag mit Verzicht auf jegliche Gewährleistung mitgeteilt wird. Dieser Antrag ist mittlerweile in den Hilfeseiten nicht mehr auffindbar.

Den findigen Admin hält das natürlich nicht auf:

Beispielhaft die Lohnartentabelle aus LODAS, write access 😉 Huhu DATEV 👋🏻

Betriebssysteme

“Hätte ich keine Endanwender, hätte ich nur Linux und keine Probleme” – ein Satz der mir von einem Kollegen auch nach mehreren Jahren noch gut im Gedächtnis geblieben ist. Recht hat er! Allerdings kann man einen Endanwender nicht vor ein Terminal mit SSH setzen. Diese Menschen brauchen Windows bzw. eine bekannte GUI, alles andere produziert der IT einen unglaublichen Mehraufwand und somit Kosten. Bei uns gibt es zwei Ausnahmen: Die Chefin und meine Wenigkeit haben Apfel-Rechner. Funktioniert auch super dank Standards wie Exchange AS, SMB und LDAPS. Diese Geräte sind bewusst nicht Mitglied der Domäne oder eines MDM’s.

Der Rest nutzt Terminal Server, die Thin Clients vor Ort sind Linux-basiert, ein Stück Luxus, den ich mir gönne. Ein Icon doppelklicken und Zugangsdaten eingeben, klappt auch unter einer Linux GUI für alle Anwender ganz gut. Ebenfalls spart man sich eine kostenpflichtige Windows-Lizenz pro Arbeitsplatz. Dafür darf man, wesentlich günstigere, RDS CALs kaufen.

Servermanagement

Es stand mal Baramundi im Raum, habe mich dann aber dagegen entschieden, Ansible kann das genauso gut. Da gab es nichts umzustellen, es war von Beginn an “open”. Wer unter Windows hauptsächlich PowerShell-CMDlets nutzt, muss sich in Kombination mit Ansible nicht groß umgewöhnen. Man kann seine bereits vorhandenen Skripte über Ansible ausführen lassen. Mittlerweile laufen sogar Exchange-CUs in der DAG vollständig automatisiert. An dieser Stelle direkt eine Warnung: Testet jedes Update in einer Testumgebung! Trotz der mittlerweile problemfreien manuellen Ausführung auf Server Core ’22 mit Exchange 2019, hängt der Automat manchmal und benötigt ein manuelles Eingreifen. Da ich dieses Phänomen bisher nur unter Windows gesehen habe, vermute ich das auch als Schuldigen und nicht Ansible. Auf Linux laufen die Aktionen problemfrei.

Microsoft Office

Das leidige Thema, um das man nicht herumkommt, auch nicht dieser Artikel. Meine User würden es nicht benötigen, LibreOffice deckt die Office-Kenntnisse vom Featureset voll ab. Da gibt es aber auch noch Kunden. Manch einer schickt einen sich selbst ausrechnenden PEP, bei dem sogar eingefleischten Excel-Usern schlecht wird, wenn sie die hunderten Formeln sehen. Das schafft LibreOffice irgendwann nicht mehr.

Hin und wieder kommt es auch vor, dass man etwas an Kunden schicken muss, das nicht als PDF verschickt werden kann, da etwas bearbeitet werden soll. Wie sieht das denn bitte aus wenn da ein .odt ankommt, das beim Öffnen mit Office 5 Fehler anzeigt, die Schrift verstellt und das Layout zerschossen ist. Sieht nicht gut beim Kunden aus – Office muss leider bleiben.

Allgemeines und Praxisbeispiele

Sobald etwas Neues ansteht, ist die erste Frage, die sich mir stellt: “Geht das auch Open?”. Genau so sollte es in mehr Firmen laufen. Was teilweise an Geld für schlechte Software oder Fehlentscheidungen verbrannt wird, ist unglaublich. Selbst wenn eine OS-Software meinen Anforderungen nicht entspricht, habe ich “nur” Personalkosten und Infrastrukturkosten verloren und nicht gleich noch Geld für die Lizenzen hinterher. Es gibt solche schönen Lösungen, die Open und somit kostenfrei sind. Klar gibt es da keinen richtigen Support, aber jeder, der einen Hotlineroboter bedienen kann, sollte in der Lage sein, ein GitHub/Gitlab Issue beim Projekt zu eröffnen. Ein Beispiel aus der Praxis:

Wir brauchen eines Tages eine Art Wiki, Prozessbeschreibungen, etwas Dokumentation und Wissen sollte darin abgelegt werden. Wieso sollte ich hier ein kostenpflichtiges Produkt wie QWiki anschaffen, wenn ein BookStack den gleichen Job tut? Dort hat sich viel getan, es fand Anklang in Firmen, was zur Folge hatte, dass nun LDAPS, SSO und AD-Group-Matching eingebaut wurden. Super Sache!

Ein weiteres Praxisbeispiel: Eine Dokumentation der IT-Infrastruktur wäre nicht verkehrt. Es gibt da ja hunderte Tools wie z.B. ITGlue, Docusnap, i-doIT und wie sie nicht alle heißen.

Es wurde schließlich ein Gespann aus 4 Systemen: Zammad, i-doIT Open, check_mk und Material for MKDocs.

Das Ganze zu beschreiben würde definitiv den Rahmen sprengen, dennoch möchte ich es kurz anreißen, wie schön “Open” zusammenarbeitet:

Die Assets sind in i-doIT angelegt und finden so ihren Weg in check_mk, von wo aus sie überwacht werden. Steht nun z. B. ein Exchange Update an, erstelle ich ein Ticket in Zammad (auch als Change Management System missbraucht), das mit beiden Systemen verbunden ist. Dem Ticket wird direkt das Asset zugeordnet und eine Ausführungszeit definiert. Das Ausführen über Ansible sowie das Eintragen des neuen Patchlevels in i-doIT ist derzeit noch Handarbeit. Wer hier einen Tipp hat, um auch das zu automatisieren, gerne ab damit in die Kommentare!

Ein solches System lebt natürlich, wie jedes andere auch, von einer exzellenten Pflege. Nachdem dies nun schon fast ein Jahr so gut zusammenarbeitet, erschließt sich mir der Sinn für ein hochpreisiges Tool wie PTRG, Docusnap usw. nicht. Das wird den Kunden meiner Erfahrung nach von den Systemhäusern aufgedrückt, weil es einfach läuft und man keine Lust hat etwas zu pflegen oder nichts anderes kennt. Ich fände es nicht so toll, wenn mir ständig etwas zum Inventarisieren im Netzwerk rumscannt oder eine extra Software auf den Clients installiert werden muss.

Fazit 2022

Durch die beständige Weiterentwicklung wird es immer einfacher auf Open Source zu setzten, ohne etwas zu vermissen. Man muss sich darauf einlassen und an der ein oder anderen Stelle neu laufen lernen. Gerade im User-fernen Bereich Administration und Backend lassen sich hier tolle Sachen bauen.

Nach wie vor vorsichtig wäre ich mit allem, womit Endanwender Kontakt haben. Manche reagieren extrem empfindlich auf Änderungen, manch einem anderen geht es nicht schnell genug. Hier sollte man seine Mitarbeiter kennen, eventuell Key-User definieren, die Hilfestellung geben können und in einem an die Unternehmung angepassten Geschwindigkeit ausrollen. Vor vollendete Tatsachen wird niemand gerne gestellt, geht auf die Leute zu: “Was hältst du von einem Wiki? Du musst nicht immer Kollegen fragen, gib einfach dein Schlagwort ein und lies dazu. Hier schau dir mal die Demo an”. Das Feedback war “ja will ich”. Nach zwei Tagen lief die Sache in Produktion und wurde ganz fleißig mit Inhalt befüllt. So einfach kann es eben auch gehen, ohne zig Meetings zum Thema, Kostengenehmigungsverfahren u. v. m.

Es bleibt von Unternehmen zu Unternehmen verschieden, ob und wie schnell solche Open-Source Lösungen ausgerollt werden können. Nach 14 Monaten intensivem Ausmisten von Altlasten, was ich jedem raten würde, bevor man neue Baustellen aufreißt, sind unsere Infrastruktur und internen Prozesse so flexibel, dass man das mal in ein bis zwei Tagen ausrollen kann. Leider ist das nicht die Regel. Wann machen sich Admins endlich das Leben einfacher? Keine Ausreden wie “geht nicht weil XY“, einfach mal machen!

Teilt den Beitrag, falls ihr mögt

Abonnieren
Benachrichtige mich bei
21 Kommentare
Most Voted
Newest Oldest
Inline Feedbacks
View all comments