Wirtschaftsinformatik in der Praxis

Hallo zusammen,

auch die Automatisierung bestehender Arbeitsabläufe gehörte zu meinen Aufgaben. Ziel war es, wiederkehrende Prozesse bei der Verarbeitung von Daten aus verschiedenen Abteilungen effizienter zu gestalten. Dafür beschäftigte ich mich unter anderem mit KNIME und Microsoft Power Automate.

Da ich vor meiner Tätigkeit noch keine Berührungspunkte mit Microsoft Power Automate hatte, musste ich mich zunächst selbstständig in die Funktionsweise und die verschiedenen Möglichkeiten der Plattform einarbeiten. Bei der Umsetzung wurde mir viel Freiraum gelassen. Gemeinsam mit meiner Führungskraft wurden die Ziele definiert, während ich anschließend selbst überlegen konnte, wie sich diese am sinnvollsten technisch umsetzen lassen.

Dabei ging es nicht darum, eine bereits vorgegebene Lösung umzusetzen. Vielmehr musste zunächst der bestehende Arbeitsablauf nachvollzogen werden, um anschließend geeignete Ansatzpunkte für eine Automatisierung zu identifizieren. Dadurch konnte ich mein Verständnis für Prozessanalyse und Prozessoptimierung weiterentwickeln.

Bei der Umsetzung spielte außerdem die Dokumentation eine wichtige Rolle. Nach der Entwicklung der Automatisierung musste ich eine verständliche Anleitung erstellen, sodass meine Führungskraft die Lösung später selbstständig nutzen und bei Bedarf um weitere Funktionen ergänzen konnte.

Auch KNIME kam bei der Verarbeitung von Daten aus verschiedenen Abteilungen zum Einsatz. Hier konnten Datenimporte und wiederkehrende Verarbeitungsschritte strukturierter und effizienter gestaltet werden. Gleichzeitig musste die Projektdokumentation kontinuierlich gepflegt werden, damit auch andere Personen den Aufbau und die Funktionsweise der Lösung nachvollziehen können.

Während die Cybersecurity Policy konkrete Anforderungen an die IT-Infrastruktur stellte, ging es bei der Automatisierung darum, die damit verbundenen Prozesse möglichst effizient zu gestalten. Dabei habe ich gelernt, dass Automatisierung nicht einfach bedeutet, möglichst viele Arbeitsschritte technisch zu ersetzen. Vielmehr muss zunächst verstanden werden, wie ein Prozess tatsächlich funktioniert, welche Anforderungen bestehen und an welchen Stellen eine Automatisierung einen echten Mehrwert bieten kann.

Insgesamt hat mir diese Tätigkeit gezeigt, dass eine erfolgreiche Automatisierung nicht allein von der technischen Umsetzung abhängt. Ebenso wichtig ist es, die bestehenden Prozesse zu verstehen und Lösungen so zu gestalten, dass sie für die späteren Nutzer nachvollziehbar und im Arbeitsalltag tatsächlich hilfreich sind.

Liebe Grüße
Fatmanur

Hallo zusammen,

Ein großer Bestandteil meiner Tätigkeit im Bereich Cybersecurity war die Umsetzung der konzernweiten Cybersecurity Policy der Continental AG. Dafür mussten die Netzwerkendgeräte am Standort inventarisiert und anschließend darauf überprüft werden, ob sie den aktuellen Sicherheitsanforderungen entsprachen. Die Aufgabe bestand somit nicht nur darin, Daten über vorhandene Geräte zu sammeln, sondern auch darum, notwendige Anpassungen gemeinsam mit den jeweiligen Abteilungen umzusetzen.

Eine besondere Herausforderung war die Vielzahl unterschiedlicher Ansprechpartner. Da die Geräte zu verschiedenen Abteilungen gehörten, musste ich regelmäßig mit den zuständigen Mitarbeitenden kommunizieren und teilweise zunächst erklären, welche Informationen benötigt wurden und warum die Erfassung für die Umsetzung der Policy notwendig war. Für die Inventarisierung habe ich unter anderem Excel-Makros eingesetzt, um die Datenerfassung zu erleichtern. Gleichzeitig unterstützte ich die Ansprechpartner bei Problemen oder Unklarheiten beim Ausfüllen der benötigten Informationen.

Um die Abstimmung zwischen den verschiedenen Beteiligten zu erleichtern, fanden wöchentliche Meetings statt. Diese wurden überwiegend über Microsoft Teams durchgeführt und dienten dazu, den aktuellen Stand zu besprechen, offene Fragen zu klären und die nächsten Schritte abzustimmen. Zusätzlich konnte ich die Ansprechpartner zwischen den Meetings direkt kontaktieren, wenn beispielsweise Informationen zu bestimmten Endgeräten fehlten.

Dabei habe ich gelernt, wie entscheidend Kommunikation für den Erfolg eines Projekts sein kann. Die technischen Anforderungen allein reichen nicht aus, wenn die notwendigen Informationen nicht rechtzeitig bei den richtigen Personen ankommen. Eine zusätzliche Herausforderung waren unterschiedliche Arbeitszeiten und Schichten der Ansprechpartner. Wenn jemand nicht an einem wöchentlichen Meeting teilnehmen konnte, ließ sich der entstandene Informationsverlust durch das anschließende Protokoll nicht immer vollständig auffangen.

Auch die technische Umsetzung selbst war teilweise komplex. Da bestimmte Geräte und Maschinen für den laufenden Betrieb benötigt wurden, konnten sie nicht einfach abgeschaltet oder kurzfristig ersetzt werden. Deswegen zog sich die Inventarisierung und Anpassung der Endgeräte über mehrere Monate. Geräte, die den Anforderungen entsprachen, konnten anschließend automatisiert an die Hauptstelle übermittelt werden. Bei Geräten, die noch angepasst werden mussten, waren hingegen weitere Schritte direkt vor Ort notwendig.

Für mich war besonders lehrreich zu sehen, dass die Umsetzung von Cybersecurity-Vorgaben in einem industriellen Umfeld immer auch von der bestehenden Infrastruktur abhängig ist. Eine Policy kann klare Anforderungen definieren, die praktische Umsetzung muss jedoch die technischen und betrieblichen Rahmenbedingungen berücksichtigen.

Liebe Grüße
Fatmanur

Hallo zusammen,

ich bin Fatmanur und studiere Wirtschaftsinformatik im Master. In den kommenden Blogbeiträgen möchte ich euch einen Einblick in meine Tätigkeit als Sachbearbeiterin im Bereich Cybersecurity bei der Continental AG geben. Hierbei möchte ich nicht nur meine Aufgaben vorstellen, sondern auch von meinen Erfahrungen und den Herausforderungen berichten, die mir dabei begegnet sind.

Was zunächst nach einer sehr technisch geprägten Tätigkeit klingt, hat sich für mich schnell als deutlich vielseitiger herausgestellt. Neben Aufgaben im Bereich Cybersecurity gehörten auch Prozessoptimierung und Datenaufbereitung zu meinen Tätigkeiten. Somit konnte ich einen Einblick in die vielfältigen Einsatzmöglichkeiten an der Schnittstelle zwischen IT und Unternehmensprozessen gewinnen.

Ein großer Teil meiner Arbeit bestand darin, die Umsetzung konzernweiter Vorgaben im Bereich Cybersecurity zu unterstützen. Hier wurde schnell sichtbar, dass technische Anforderungen in der Praxis häufig mit organisatorischen und betrieblichen Rahmenbedingungen abgestimmt werden müssen. Gerade in einem großen Industrieunternehmen treffen dabei unterschiedliche Interessen, Prozesse und technische Voraussetzungen aufeinander. Dies hat in der Praxis zu Herausforderungen geführt, da technische Lösungen nicht immer so umgesetzt werden können, wie ursprünglich geplant.

Ein weiterer wichtiger Bestandteil meiner Tätigkeit war die Zusammenarbeit mit verschiedenen Abteilungen und Ansprechpartnern. Dabei ging es nicht nur darum, Anforderungen weiterzugeben, sondern gemeinsam Lösungen zu entwickeln, die sowohl den Vorgaben als auch den jeweiligen Gegebenheiten vor Ort gerecht wurden.

Durch meine Tätigkeit konnte ich meine fachlichen Kenntnisse weiterentwickeln und gleichzeitig ein besseres Verständnis für die Verbindung von IT und den Anforderungen verschiedener Fachbereiche entwickeln.

In den nächsten beiden Beiträgen möchte ich euch noch genauer zeigen, wie sich diese Aufgaben in der Praxis gestaltet haben und welche Erfahrungen ich dabei sammeln konnte.

Hallo zusammen!

Zeitschätzungen der Dauer, bis Projektteile fertiggestellt sein würden, gestalteten sich stets als schwierig. Nicht nur die schiere Größe des Projektes, bedingt durch die zum professionellen Einsatz nötige Tiefe der Anforderungen jedes Projektteils, sondern ebenfalls fehlende Erfahrungswerte bezüglich der Schätzung als Werkstudent trugen maßgeblich dazu bei. Insbesondere dann, wenn man wie ich bei der Bearbeitung universitärer Projekte gerne die Zeit außer Acht lässt und davon unabhängig arbeitet bis ein Projekt einen akzeptablen Stand erreicht. Zusätzlich nahmen etwa Fragen des Deployments in den jeweiligen Produktionsumgebungen, beispielsweise zur Sicherheit und Ausfallsicherheit, viel Zeit in Anspruch, ohne ein für technisch Außenstehende offensichtliches Ergebnis zu erzielen. Trotz dieses intransparenten Fortschritts lohnte sich der Fokus auf das Minimum Viable Product (MVP), auch wenn das Funktionalitätsspektrum bis zur „vollständigen Implementierung“ der Grundfunktionen nicht wuchs. Die letztendlich benötigte Zeit lag meist ein gutes Stück über der ursprünglichen Schätzung, hauptsächlich mit Blick auf die zur Verfügung stehenden Wochenstunden und die daraus resultierende absolute Dauer. Hier lohnte es sich, präventives Erwartungsmanagement mit Bezugnahme auf diese lediglich 10 in der Woche zur Verfügung stehenden Stunden vorzunehmen, um offene und ehrliche Kommunikation zu wahren.

Um grundsätzlich möglichst schnellen Fortschritt zu erzielen, Softwareunterstützung zu erfahren und IT-Sicherheit zu gewährleisten, rentierte sich in allen Fällen eine Recherche nach den aktuellen Best Practices und Standardlösungen, wie der für jede Kommunikation genutzten mTLS-Verschlüsselung. Ebenfalls gaben Industrienormen und technische Standards weiteren Aufschluss über die Handhabe üblicher Problemstellungen, welche sich häufig auch auf andere Bereiche des Systems übertragen ließen. So lieferten etwa standardisierte Datenaustauschmodelle für Energiesystemkomponenten Inspiration für die Modellierung von Zeitreihendatenpunktarten. Typische Anbindungsprotokolle zwischen Gateway und Geräten waren meist von der Industrie genormte, teilweise jedoch proprietäre Protokolle, die eher schlecht als recht dokumentiert waren und keinen Best Practices, wie etwa der Protokollversionierung, folgten, was für deutlichen Zeitaufwand auf meiner Seite sorgte. Falls möglich, lässt sich empfehlen, von der Verwendung proprietärer Schnittstellen abzusehen. In der Architektur etwa ersetzte eine Standardlösung die anfänglich gRPC-basierte Custom-Implementierung eines Persistent-Queue Services. Der eingesetzte Message Broker standardisierte effektiv und zeiteffizient das Protokoll, die Autorisierung und die Zuordnung unterschiedlicher Datenströme zu entsprechenden Services, während gleichzeitig Durability sichergestellt wurde. Wo möglich, lohnte es sich in jeder Situation, Standardkomponenten einzusetzen. Insbesondere in sicherheitsfokussierten Bereichen, wie etwa des Identity & Access Managements, der Zertifikatsverwaltung und auf der Nutzungsseite in der Authentifizierung und Autorisierung. Für diese sicherheitskritischen Systembestandteile sollte wenn möglich immer auf bereits bestehende Software zurückgegriffen werden, um Sicherheitslücken zu vermeiden.

Hallo zusammen!

Damit die Konzeption gestartet werden konnte, benötigte ich zuerst ein Verständnis über die Domain und die möglichen Anforderungen. Ich führte dazu Recherchen und Gespräche mit Stakeholdern durch, die entsprechendes Domain-Knowledge besaßen, mit dem Ziel, einen Anforderungskatalog zu erstellen. Gleichzeitig bat ich diese, sowie Personen mit Informatikbackground der Hagen GmbH, um die Niederschrift einiger Anforderungen, die sie persönlich für wichtig erachteten. Es entstand ein ungeordneter Anforderungskatalog, der sich grob in zwei Kategorien untergliedern ließ: Anforderungen auf Basis des Domain-Knowledge und technische Anforderungen an das System. Der Katalog gab mir einen groben Überblick über das Projekt, obwohl er weder komplett noch detailliert genug war, um ein vollständiges System-Design abzuleiten. Dies stellte sich im Nachhinein nicht als Nachteil dar, fehlte dieser Momentaufnahme nicht nur der Blick in die Zukunft, die neue Anforderungen und Prioritätsänderungen brachte, sondern auch mir die zeitlichen Möglichkeiten, bedingt durch die Wochenarbeitszeit, alle Anforderungen umsetzen zu können.

Durch die Änderung der Prioritäten einzelner Anforderungen und dem Hinzufügen neuer Anforderungen über die Zeit in Kombination mit der zur Verfügung stehenden geringen Wochenstundenzahl mussten Designentscheidungen flexibler Natur getroffen werden, um einen anpassungsfähigen Systemkern zu schaffen. Dies möchte ich am Beispiel des Schema-Designs der Datenbank verdeutlichen:

Für den Start des Schema-Designs erwies sich die allseits bekannte ER-Modellierung als sehr nützlich, um erste Ideen zu skizzieren und stets eigene Gedankengänge selbstkritisch beleuchten zu können. Implizit wurde so nach und nach ebenfalls das möglichst kleinste Universe of Discourse festgelegt, um keine unnötige Komplexität einzubringen. Doch trotz guter Modellierung wurden Auswirkungen mancher Abwägungen erst durch die sukzessive Implementierung des Gesamtsystems deutlich. Hierbei musste das Datenbankschema häufiger iterativ angepasst werden, da sich Edge Cases zeigten. So war beispielsweise ein teilweises Redesign des Schemas nötig, um zeitpunktgenaue Neuzuweisungen von Gateways zu Installationen und an den Gateways angeschlossenen Geräten zu diesen Installationen darstellen zu können. Das Problem, dass Geräte und Gateways, die von einer Installation zur anderen wechseln können, deren bereits produzierte Daten jedoch im System mit der korrekten Zuordnung verbleiben sollten, musste abstrakt genug gelöst werden, um auch zukünftigen Gerätetypen, unbekannter Art und Konfiguration, Sorge zu tragen, sowie Daten korrekt zuordnen zu können, die aufgrund von Teilsystemausfällen unbekannter Art noch nicht (vollständig) übermittelt wurden. Diese iterative Entwicklungsarbeit an der Datenbank wurde durch das Führen eines statischen, versionsverwalteten DDL-Skripts zur Erstellung des Schemas beschleunigt. So konnten Änderungen, die das Schema offen für spätere Erweiterungen machten, schneller erprobt werden.

Hallo zusammen!

Mein Name ist Jens, ich studiere Wirtschaftsinformatik im Master und arbeite seit über 2 Jahren als Werkstudent bei der HE – HagEnergy GmbH in Peine. Das auch Hagen Energiesysteme & Gebäudetechnik genannte Unternehmen wurde erst 2023 von Torben und Christian Hagen ausgegründet. Es ist ein Handwerksbetrieb mit etwa 30 Mitarbeitern. Wesentliche Unternehmenszwecke sind die Installation von Solar- und Energiesystemen bis in den Megawattbereich sowie die Bereitstellung weiterer Dienstleistungen innerhalb dieses Gebietes. Die länger existierende Schwesterfirma Hagen GmbH, die Unternehmen bezüglich der Arbeitssicherheit berät, entwickelt bereits seit einigen Jahren eigene digitale Systeme für beispielsweise das technische Prüfmanagement, Unterweisungsmanagement und Gefahrenstoffverzeichnis.
Mit Blick auf immer stärker vernetzte Energiesystemkomponenten und steuerbare Verbrauchseinrichtungen suchte die HE – HagEnergy GmbH einen Werkstudenten zur Entwicklung eines Energiemanagementsystems.

Das zu entwickelnde Energiemanagementsystem sollte insbesondere Möglichkeiten der Remote-Datenerfassung bieten. Potenzielle weitere Einsatzfelder lagen in den Bereichen des dynamischen Lastmanagements von Ladepunkten und der Verbrauchs- und Einspeiseoptimierung. Während der gesamten Zeit wurden mir große Lern- und Gestaltungsfreiräume von der Konzeption und dem Anforderungsmanagement über die Systemarchitektur und der Implementierung bis hin zum Minimum Viable Product (MVP) gewährt. Innerhalb dieser Bereiche bot sich mir eine fachliche Breite und Tiefe, die ich bei anderen Unternehmen, aufgrund von Bereichsspezialisierungen und fehlender persönlicher Autonomie, nicht hätte einsehen können. Dies ermöglichte mir eine signifikante und eigenständige persönliche Weiterentwicklung, die mir als eher autodidaktisch veranlagtem Menschen sehr zugute kam. Meine wöchentliche Arbeitszeit belief sich aufgrund eigener Entscheidung, vorwiegend wegen des Zeitaufwands für das Studium, auf verhältnismäßig geringe 10 Wochenstunden, von denen seit einem Jahr auch ein kleiner Teil für Entwicklungen innerhalb der Hagen GmbH aufgewendet wurde. Beide Firmen boten aus meiner Sicht stets ein sehr gutes Arbeitsklima. Die Möglichkeit zum Home-Office, kurze Dienstwege und persönlicher Umgang ließen insbesondere das Vorantreiben des Projektes meist weniger als einsame Arbeit, sondern eher als ein gemeinsames Ziel erscheinen.

In den folgenden zwei Blog-Beiträgen möchte ich euch meine Learnings und Erfahrungen aus der eigenständigen Konzeption und Entwicklung des Systems näher bringen. Dazu findet ihr im nächsten Beitrag Learnings, die das Anforderungsmanagement und die Konzeption betreffen. Der darauffolgende Beitrag beschreibt meine Erfahrungen zu Zeitschätzungen und der Nutzung von standardisierten Elementen.

Moin,

in diesem letzten Beitrag möchte ich darüber sprechen, wie ich das Insolvenzverfahren von Vizavy erlebt habe und wie ich rückblickend meine persönliche Entwicklung einschätze. Ich möchte betonen, dass es sich hier um meine eigene Perspektive handelt – sie ist subjektiv und kann natürlich Lücken haben.

Wir hatten unser Produkt am 15. September 2023 veröffentlicht. Es gab noch ein paar Fehler zu beheben, deshalb wollten wir zunächst einen internen Early Access durchführen, bevor wir das Produkt an Kunden herausgeben. Doch dazu kam es nicht mehr. Am 02.10.2023 stellte Vizavy den Insolvenzantrag. Die Nachricht erreichte uns in einem unternehmensweiten Call. Uns wurde versichert, dass keine Gefahr bestehe, dass das Unternehmen schließen müsse.

Ich war unglaublich stolz auf mein Team. Statt sich entmutigen zu lassen, haben sie die Situation als Chance gesehen, sich zu beweisen. Das Entwicklungstempo blieb hoch, niemand hat nachgelassen. Alle zwei Wochen hatten wir einen Call mit dem Insolvenzverwalter – Herr Walter, ja, wirklich so hieß er – und bekamen Updates zum Verfahren. Leider wurden die Nachrichten jedes Mal schlechter. Die Geschäftsführung versuchte zunächst, Investoren zu finden. Als das scheiterte, sollten die Produkte an andere Unternehmen verkauft werden. Am Ende wurde uns mitgeteilt, dass Vizavy im März schließen würde. Ich selbst bin im Dezember ausgestiegen. Ich war mit einigen Entscheidungen der Geschäftsführung nicht einverstanden und wollte die Zeit lieber für meine Klausuren nutzen.

Was mir bis heute nachgeht: wie sehr ich dieses Team vermisse. Das System der Vizcademy – ein Team aus Studierenden und Umschülern, das aber volle Verantwortung trägt – hat dazu geführt, dass ich eine enorme persönliche Entwicklung durchlaufen habe. Mit der Unterstützung meines Mentors habe ich Zusammenhänge verstanden, über die ich vorher nie nachgedacht hätte. Ich musste meinen Führungsstil anpassen, je nachdem, was das Projekt gerade brauchte. Ich habe gelernt, mein Team gegenüber Stakeholdern zu vertreten und zu schützen. Die Vizcademy war für mich das Beste, was das Unternehmen geschaffen hat, und ich werde meinem Mentor und meinem Vorgesetzter immer dankbar sein.

Gleichzeitig hatte das Unternehmen auch Erwartungen an uns, die über das Projekt hinausgingen. Persönliche Weiterentwicklung war ausdrücklich gewünscht, genauso wie das Erwerben von Zertifizierungen, die für die eigene Zukunft wichtig sein könnten. Diese würden auch vom Unternehmen finanziert.

Ich bin traurig, weil ich bezweifle, jemals wieder in einem so besonderen Umfeld arbeiten zu können. Aber ich weiß auch: Wenn ich irgendwann die Möglichkeit habe, ein ähnliches System in einem Unternehmen einzuführen, würde ich es ohne zu zögern tun.

Ich hoffe, dass diese drei Blogs euch einen Einblick geben konnten – oder euch zumindest eine angenehme und vielleicht sogar interessante Lesezeit beschert haben.

Viele Grüße,

Jaime

Moin zusammen, in diesem Beitrag möchte ich darüber sprechen, welche Aufgaben ich als Product Owner der Vizcademy übernommen habe und wie ich Schritt für Schritt in diese Rolle hineingewachsen bin.

Ich bin im Mai 2023 bei Vizavy eingestiegen und hatte zunächst zwei Monate Zeit, um alles von meinem Vorgänger zu lernen. Für mich war das eine intensive Phase: Ich musste erst einmal verstehen, wie sich die Aufgaben eines Product Owners von denen eines Scrum Masters unterscheiden, wo die Grenzen liegen und welchen Platz ich in der Unternehmenshierarchie einnehme. Gleichzeitig habe ich Scrum von Grund auf gelernt – nicht nur theoretisch, sondern direkt im praktischen Umfeld. Ausserdem wurde mir ein Mentor zur Seite gestellt, was sich als sehr wertvoll herausgestellt hat.

Im Unternehmen haben wir das Atlassian‑Ökosystem genutzt, vor allem Jira und Confluence. Jira diente uns als Kanban‑Board, über das wir den Status unserer Aufgaben, Abhängigkeiten und Kommentare im Blick behalten konnten. Confluence war unser zentraler Ort für Dokumentation – nicht nur für die Software selbst, sondern auch für interne Prozesse wie unseren Social Contract oder die Erwartungen der Stakeholder.

Mein Team hatte bereits vor meiner Zeit mit Planning Poker gearbeitet, um den Schwierigkeitsgrad von Aufgaben einzuschätzen. In den ersten Wochen habe ich viel Zeit damit verbracht zu verstehen, wo die Grenzen und Herausforderungen meines Teams lagen. Auf dieser Basis habe ich einen Plan entwickelt, wie wir diese Probleme langfristig angehen können.

Als ich die Rolle schließlich vollständig übernommen hatte, bestand mein Alltag aus einer Mischung aus Stakeholder‑Meetings, Board‑Pflege, Sprint‑Planung, enger Kommunikation mit meinem Team und der Abstimmung mit unserer Scrum Masterin. Gemeinsam haben wir Probleme im Prozess identifiziert, Prioritäten gesetzt und die Ziele des Projekts geschärft. Ein größerer Teil meiner Verantwortung war außerdem, die Monetarisierung unseres Produkts komplett neu zu strukturieren – aus meiner Sicht wäre das Produkt ohne diese Anpassung kaum wirtschaftlich tragfähig gewesen.

Gegen Ende meiner Zeit kamen weitere Aufgaben hinzu: die Vorbereitung des Produkt‑Releases, das Setzen eines Meilensteins für den zukünftigen Support der Software und der Besuch von Messen, um unser Produkt vorzustellen.

Neben der Vizcademy war ich außerdem für zwei kleinere Teams verantwortlich. Eines arbeitete an einer internen Softwarelösung, bei der wir klassisches Projektmanagement statt Scrum nutzten. Das andere Team betreute einen Kurs, den wir an Volkshochschulen angeboten haben – eine Art „Schnupper‑Scrum“, bei dem Teilnehmende die Grundlagen des Frameworks kennenlernen konnten.

Mein Name ist Jaime Valles Fonseca, ich studiere Wirtschaftsinformatik und befinde mich inzwischen im 6. Master Semester. 2023 hatte ich die Möglichkeit, bei Vizavy zu arbeiten – einem Unternehmen, das manche vielleicht noch unter seinem früheren Namen Codefrog kennen.

In diesem ersten Blog möchte ich genau darüber sprechen: über das Unternehmen und die besondere Atmosphäre, die Vizavy geprägt hatte. Die nächsten beiden Beiträge werden sich dann mit meinen konkreten Aufgaben sowie meiner persönlichen Entwicklung – gerade auch während der schwierigen Phase der Insolvenz – beschäftigen

Vizavy selbst war das Ergebnis einer Fusion zweier Software‑Consulting‑Unternehmen: Moxxco aus Bad Nauheim bei Frankfurt und Codefrog aus Braunschweig. In seiner stärksten Phase beschäftigte Vizavy rund 120 Mitarbeitende und war besonders auf die Digitalisierung von Geschäftsprozessen spezialisiert. Die Mischung aus zwei Standorten und zwei Unternehmenskulturen hat Vizavy zu einem spannenden, auch wenn manchmal komplizierten, Umfeld gemacht. Wichtig dabei ist zu sagen, dass alle die Möglichkeit hatten von Zuhause zu arbeiten.

Eine Besonderheit innerhalb des Unternehmens war die Vizcademy. Diese Abteilung hatte die Aufgabe, nachhaltigen Nachwuchs für Vizavy aufzubauen. Das Team bestand idealerweise ausschließlich aus Studierenden und Umschülern – also Menschen, die noch am Anfang ihrer beruflichen Laufbahn standen. Der Team würde von 8 bis 12 Entwickler*innen, 1 Scrum Masterin und 1 Product Owner (ich) zusammengebaut.
Anders als in vielen anderen Unternehmen war die Vizcademy aber nicht nur ein Ausbildungsprogramm, sondern ein vollwertiges Team mit echter Produktverantwortung. Wir hatten dieselben Aufgaben, dieselben Erwartungen und dieselben Verantwortlichkeiten wie jedes andere Team im Unternehmen. Genau das machte die Arbeit dort so besonders: Man lernte nicht nur theoretisch, sondern trug von Anfang an Verantwortung für ein echtes Produkt.

Hallo zusammen,

zum Abschluss möchte ich ein Fazit zu beiden Tätigkeiten ziehen.

Was ich aus beiden Stationen mitnehme, lässt sich schwer auf einen Nenner bringen, weil sie sich inhaltlich doch stark unterschieden haben. Bei Salzgitter habe ich vor allem gelernt, wie viel Arbeit hinter der Frage steckt, Daten aus einem System wie SAP so aufzubereiten, dass sie für automatisierte Prozesse nutzbar sind. Das klingt technisch und ist es auch, aber es hat mir gleichzeitig gezeigt, wie eng Technik und fachliche Prozesse zusammenhängen. Man kann den Code nicht sinnvoll schreiben, wenn man nicht versteht, was eine Rechnung im Controlling-Kontext bedeutet.

Bei Siemens Mobility hat mich vor allem das Erlebnis geprägt, eine Lösung zu entwickeln, die tatsächlich produktiv eingesetzt wird. Das gibt einem eine andere Perspektive auf die eigene Arbeit. Plötzlich überlegt man anders, wie man etwas umsetzt, weil man weiß, dass andere Menschen damit arbeiten werden.

Rückblickend würde ich beiden Tätigkeiten weiterempfehlen, aber aus unterschiedlichen Gründen. Salzgitter Digital Solutions eignet sich gut, wenn man tief in SAP-nahe Entwicklung und Datenverarbeitung einsteigen möchte. Siemens Mobility war für mich wertvoll, weil ich dort schnell Verantwortung für ein Ergebnis übernehmen konnte, das über meine Zeit im Unternehmen hinaus Bestand hatte.

Ich hoffe, meine Erfahrungen geben euch einen nützlichen Einblick.

Viele Grüße
Iggy