Wirtschaftsinformatik in der Praxis

Mein Name ist Tijana und ich stelle euch jetzt meine langjährige Arbeit bei der Monsterzeug GmbH vor. Ich studiere zur Zeit meinen Master in der Wirtschaftsinformatik mit großem Interesse an (Online) Marketing.

Im Jahr 2008 entstand die Idee für Monsterzeug. Zunächst auf der Basis, Spielzeug für Erwachsene anzubieten, die sich zum Beispiel im Büroalltag langweilten. Ein Online-Shop für Gadgets, für das Kind im Manne. Das Geschäft begann mit ca. 5 Mitarbeitern, und lief sehr überschaubar. Mit den Jahren wurden die Aufträge mehr und daher der Drang nach mehr Mitarbeitern.

Im Laufe der Zeit wandelte sich auch die Produktpalette. Die Sparte für Geschenke wurde ausgebaut, Gadgets waren und sind auch immer noch vielzählig vertreten, doch das Hauptaugenmerkmal liegt nun doch auf den Geschenkideen.

Im Jahr 2014 wurde dann für eine Stelle im Bereich Online-Marketing ausgeschrieben, da auch dort der Arbeitsaufwand stieg. Das war mein Einsatz. Ich war zu dieser Zeit kurz vor meinem Bachelor-Abschluss und hatte Interesse daran meine Marketing Kenntnisse auszubauen. Nach dem Vorstellungsgespräch war für mich klar: Hier will ich arbeiten! Seitdem arbeite ich auf einer 20h Woche als Online-Marketing Verantwortliche.
Auch meine Bachelor-Arbeit bezog sich auf den Bereich der Suchmaschinenoptimierung. Auch hier hat mir diese Stelle einen Vorteil gebracht, da ich einen guten Einblick hinter die Kulissen hatte und die Suchmaschine mein alltäglicher Begleiter ist.

Nun hat das „kleine“ Start-Up bereits einen eigenen Versand, eine eigene Gravur für die personalisierten Produkte, eine eigene Grafikabteilung, Texter für die Produkttexte, ein ganzes Support-Team, eine IT-Abteilung, Übersetzer, und schlussendlich auch eine kleine, aber feine, Marketing-Abteilung.

Inzwischen werden um die 50 Mitarbeiter beschäftigt – zur Weihnachtszeit, die Umsatzstärkste Zeit – sogar noch mehr. Inzwischen wird die Internetpräsenz auch für Österreich und die Schweiz separat betrieben, und vermarktet.

Nun kennt ihr eine meiner täglichen Aufgaben. Es bleiben aber die Fragen, wie viel Zeit ich mit was aufbringe, ob das nur in meiner aktuellen Abteilung so ist und womit ich speziell arbeite.

Im Zuge meiner Ausbildung bei der VWFS AG habe ich verschiedene Abteilungen durchlaufen, sodass ich den Arbeitsalltag mit verschiedenen Technologien erleben konnte. Grundsätzlich ist der Entwicklungsprozess für Software immer der gleiche. Die Unterscheidungen liegen in den Technologien, den Aufgaben und dem organisatorischen Arbeitsumfeld. An dieser Stelle möchte ich das anhand eines Beispiels verdeutlichen: Aktuell Arbeite ich mit SAP BW. Hier sind alle Schritte um Daten zusammenzuführen und darzustellen in einer Technologie zu finden. Gleichzeitig benötige ich Kollegen, die Speziell dazu da sind, um die Daten zu interpretieren und transformieren. In einer anderen Abteilung habe ich mit C# und Javascript gearbeitet. Durch die Spezialisierungen der Programmiersprachen habe ich das Web Frontend und die dahinterliegende Logik gebaut. Gleichzeitig war beispielsweise die Datenbankentwicklung in einen anderen Bereich ausgelagert, sodass alle Datenbankanpassungen und Operationen von anderen Kollegen erledigt wurden.

Schätzungsweise verbringe ich 30% meiner Zeit damit mich abzustimmen. Hierzu zähle ich Meetings, Telefonate, Mails und zuarbeiten, die direkt aus Abstimmungen resultieren und darauf zuarbeiten. Die tatsächliche Umsetzung und Programmierung (wobei Programmierung nicht gleich Programmierung ist. Das hängt ganz von der Technologie ab) hat die Majorität von ca. 60% der Zeit. Die letzten 10% verbringe ich mit weiteren Aufgaben, die nicht direkt Zielführend für eine der Work Orders sind. Hierzu zählen Abteilungsrunden, organisatorische Aufgaben, Schulungen und für mich, da ich verhältnismäßig noch recht neu in der Abteilung bin, das Erlernen von Sachverhalten, die ich für meine Arbeit benötige.

Ist geklärt, dass eine Anforderung umgesetzt werden soll, so wird mit der wie-Frage begonnen. Dies macht dann derjenige, der die Änderung tatsächlich unter seine Fittiche nimmt. Die Umsetzung kann dabei sowohl von einem weiteren Kollegen, als auch vom Applikationsverantwortlichen selbst übernommen werden. – Einschub – Da ich selbst noch relativ neu in der Abteilung und mit der Applikation bin, zähle ich noch zu den weiteren Kollegen ohne Applikationsverantwortung. Der Zeithorizont um Applikationsverantwortlicher zu werden liegt in meinem Fall als Teilzeitkraft bei etwa 2 Jahren. Dies ist allerdings auch sehr abhängig von der Komplexität der jeweiligen Applikation. – Einschub Ende –

Die Klärung der wie-Frage beinhaltet weiteren Austausch mit dem Fachbereich. Es gilt, die Anforderungen aus einer fachlichen Sicht in eine Umsetzungssicht zu transformieren. U.a. gehört dies zu der im Winfo-Studium vielfach angesprochenen Übersetzungstätigkeit zwischen Fachbereich und IT. Einzuplanen sind hier auch die weiteren Kollegen aus dem IT-Bereich. Durch die Vernetzung der verschiedenen Applikationen müssen auch an anderen Applikationen Änderungen vorgenommen werden, um den Änderungsauftrag des Fachbereichs tatsächlich umzusetzen. Am Ende der Klärung, wie die Änderungsanforderungen umgesetzt werden sollen, steht ein Umsetzungskonzept, das die strukturellen Anpassungen an der eigenen Applikation beinhaltet, sowie eine Aufwandsschätzung, wie lange für die Anpassung der eigenen Applikation und zusätzlich die Anpassungen an anderen Applikationen benötigt werden. Die Umsetzungskonzepte schreiben die Mitarbeiter der anderen Applikationen selbst für sich. Anhand der Aufwandsschätzung entscheidet der Fachbereich, ob der Änderungsauftrag tatsächlich umgesetzt werden soll, oder ob er noch einmal angepasst wird.

Bei der Umsetzung des Änderungsauftrages hält man sich an das zuvor geschriebene Umsetzungskonzept. Das Umsetzungskonzept ist so verfasst, dass es die Gesamtstruktur vorgibt, ohne dabei dem Entwickler die einzelnen Codezeilen vorzugeben. In dieser Phase kommt es viel Auf die Abstimmung mit Kollegen an, mit denen man zusammen an der Umsetzung arbeitet. Außerdem werden weitere Detailfragen mit dem Fachbereich geklärt, die zuvor nicht bedacht wurden.

Nach der Umsetzung des Änderungsauftrages testen sowohl die IT, als auch der Fachbereich die Applikation auf ihre Funktionalität. Die IT Testet, dass Abläufe weiterhin reibungslos funktionieren und der Fachbereich achtet auf die Korrektheit der Daten. Funktioniert alles, so wird die Änderung Produktiv geschaltet, sodass der Fachbereich tatsächlich damit arbeiten kann.

Hallo zusammen,

ich heiße Henrik Busche und studiere im zweiten Mastersemester Wirtschaftsinformatik an der TU-BS. Ich habe in den vergangenen 3 Jahren ein duales Studium zum B.Sc. Wirtschaftsinformatik bei der VWFS AG gemacht und dabei verschiedene Bereiche des Unternehmens kennengelernt. Nach meiner Ausbildung bin ich nun im Bereich Business Intelligent Solutions for Riskmanagement eingesetzt.

Nachdem es schon viele Blogeinträge zur Vorstellung verschiedener Applikationen gab, möchte ich euch einen kleinen Einblick in die Arbeit geben, die tagtäglich an den Applikationen verrichtet wird.

Zu meinen täglichen Aufgaben zählt z.Z. die Umsetzung von Work Orders. Also großen oder kleinen Änderungsaufträgen an bestehenden Applikationen. Hierzu muss ich mich mit verschiedenen Kollegen abstimmen, da die Applikationen keine standalone Anwendungen, sondern vielfach vernetzt sind und verschiedene Leute Anforderungen daran stellen. Jede Änderung meinerseits hat auch Einfluss auf Schnittstellen zu Applikationen Anderer. Aber nun lasst uns erst einmal am Anfang beginnen. Im Folgenden werde ich den Ablauf einer Work Order beschreiben.

Im Fachbereich sitzen die Leute, die sich Fachlich mit bestimmten Unternehmensaufgaben auskennen. In meinem Fall beispielsweise das Risikomanagement. Die Leute im Fachbereich arbeiten mit verschiedenen Applikationen. Wenn ihnen nun Verbesserungen für diese Applikationen einfallen, sie neue Geschäftsmöglichkeiten eröffnen wollen oder sie neue gesetzliche Vorgaben erfüllen müssen, verlangen sie Änderungen an den bestehenden Applikationen. Diese Änderungsanforderungen beschreiben sie Fachlich in einem Fachkonzept, welches sie anschließend an den Applikationsverantwortlichen der jeweiligen Software übergeben.

Aufgabe des Applikationsverantwortlichen ist die grobe Bewertung der Änderungsanforderung. Sprich: Ist die Anforderung überhaupt umsetzbar? Zu klärende Fragen sind beispielsweise „Ist die Änderungsanforderung überhaupt realistisch?“ und „Wann hat die IT Zeit, die Änderung umzusetzen?“. Geklärt wird hier also nicht „Wie“, sondern „Ob“ die Änderung umgesetzt wird.

Zu guter Letzt möchte ich euch im dritten und letzten Blogeintrag mein persönliches Fazit zu der Zeit bei der VWFS AG als Werkstudent und als Praktikant mitteilen.

Für Studenten ist es enorm wichtig parallel zum Studium auch bereits erste Berufserfahrung zu sammeln. Viele Unternehmen verlangen dies heutzutage und daher habe ich mich bemüht auch von Anfang an so viel Erfahrung wie möglich zu sammeln.

Dies hat auch wunderbar funktioniert. Jedoch kann ich rückblickend nun sagen, dass am Ende meines Bachelors ich schon ab und an das Gefühl hatte, nur noch zu arbeiten und das Studium in den Hintergrund stellte. Sodass sich mein Bachelorabschluss in die Länge gezogen hat und ich erst später mit dem Bachelor in der Berufswelt voll durchstarten konnte. Von daher würde ich allen Studenten empfehlen Berufserfahrung zu sammeln, dennoch sollte man ein gesundes Mittelmaß finden und nicht seine Prioritäten vom Studium auf den Nebenjob verlagern.

Beste Grüße,

Alexander

Im ersten Teil meines Blogeintrages habe ich euch erzählt, wie genau ich zu dem Praktikum bei der VWFS AG gekommen bin und möchte euch nun gerne in dem zweiten Blogeintrag etwas näher erläutern, was genau meine Tätigkeiten waren.

In dem freiwilligen Praktikum habe ich an den Prototypen aus der Bachelorarbeit weiter gearbeitet und meine Kollegen aus der Abteilung unterstützt. Ich konnte so sehen wie sehr es auf Teamarbeit ankommt, jedes Projekt wurde in viele einzelne Arbeitspakete mit unterschiedlichen Deadlines aufgeteilt, welche dann von unterschiedlichen Kollegen in der Unterabteilung bearbeitet wurden. Damit wurde eine übersichtliche Strukturierung der einzelnen Arbeitspakete und Kommunikation unter den Kollegen unerlässlich. Weil das Team auch parallel Aufgaben bearbeiten konnte, war es besonders wichtig bereits von Beginn an beim Programmieren des Quellcode übersichtlich und gut strukturiert vorzugehen und auch mit vielen Kommentaren zu versehen. So konnte der nachfolgende Mitarbeiter sich in den Quellcode ohne viel Aufwand einlesen und verstehen. Deswegen war eine meiner Aufgaben damals den Quellcode unterschiedlicher Methoden oder Applikationen zu testen, zu kommentieren und anschließend eine Dokumentation anzufertigen. Darüber hinaus habe ich zu der Zeit auch kleinere ABAP Methoden, welche die Kollegen aktuell benötigt haben, geschrieben umso mein Wissen im SAP bzw. ABAP zu steigern.

Ansonsten konnte ich während meines Praktikums viel über die Systemlandschaft der VWFS AG lernen und einen guten Einblick in einige der unterschiedlichen Applikationen im SAP Business Warehouse kennen lernen.

Hallo zusammen,

mein Name ist Alexander und ich möchte euch in den folgenden drei Blogeinträgen meine Erfahrungen mit der VWFS AG erzählen. Angefangen hat alles im Jahre 2012 mit einer zwei jährigen Werkstudententätigkeit, danach habe ich zum Ende meines Bachelors auch meine Bachelorarbeit bei der VWFS AG schreiben können. Als diese dann abgeschlossen war, habe ich mein Praktikum verlängert um dadurch noch mehr Erfahrung in der IT Welt und bei der VWFS AG während des Masterstudium sammeln zu können.

Meine Bachelorarbeit befasste sich mit der Stammdatenverteilung in verteilten SAP Business Warehause Systemen. Bei der VWFS AG gab es zu dem Zeitpunkt unzählige SAP Systeme mit enormen Summen von Stammdaten für die verschiedensten Objekte. Diese mussten gepflegt und natürlich bei Änderungen auf allen Systemen des SAP Business Warehouse aktualisiert werden. Das ist extrem aufwendig und verbraucht jede Menge Ressourcen. Um diesen Prozess zu optimieren und zu automatisieren habe ich mich in der Bachelorarbeit damit beschäftigt. Das Resultat war dann ein in SAP mit Hilfe von APAP realisierter Prototyp, welcher in einer SAP Testumgebung Stammdaten zwischen unterschiedlichen SAP Systemen verteilt hat.

Danach hatte ich die Chance ergriffen und konnte in derselben Abteilung ein freiwilliges Praktikum absolvieren.