Ein Forecastsystem für Medienunternehmen

Bachelorarbeit von Marcus Franke

Einleitung:

Ziel der vorliegenden Bachelor-Thesis ist es, die Portierung eines bestehenden windows-basierten Forecastsystems auf Web-Technologie – konzeptionell – durchzuführen und zu dokumentieren. Dabei soll die Frage geklärt werden, ob unterschiedliche methodische Ansätze in der Praxis sinnvoll eingesetzt werden können und ob es Schwachstellen gibt.

Im Hinblick auf das Ziel und die damit verbundene Fragestellung lassen sich folgende Aufgaben für die Bachelor-Thesis formulieren.

Einordnung des Projektes in einen betriebswirtschaftlichen und einen softwaretechnischen Kontext, um einen Überblick zu geben, welchem Bereich der Betriebswirtschaftslehre das Forecastsystem zuzuordnen ist und welche Aufgaben es insbesondere im Bereich Controlling erfüllt. Weiterhin soll gezeigt werden, in welche Phasen des Softwareentwicklungsprozesses sich die behandelten Themen der Arbeit einordnen lassen.

- Beschreibung des Ist-Zustandes mit anschließender Analyse der Stärken und Schwächen des bestehenden Forecastsystems.

- Neukonzeption eines web-basierten Systems auf der Basis der Anforderungen des beschriebenen und analysierten windows-basierten Forecastsystems.

Zu diesem Zeck ist die Arbeit wie folgt gegliedert.

Gang der Untersuchung:

Die Arbeit gliedert sich in sieben Kapitel:

Kapitel 1 stellt die Einleitung dar. Innerhalb dieses einleitenden Kapitels werden die Zielsetzung der Arbeit und deren Aufbau beschrieben.

In Kapitel 2, Grundlagen des Controlling in einer Medienunternehmung, wird der betriebswirtschaftliche Kontext beschrieben, in dem sich eine Medienunternehmung der Film- und Fernsehbranche bewegt. Hierbei liegt der Fokus der Betrachtungen auf dem für die Aufgaben und Funktionen des Forecastsystem relevanten Bereich des Controlling. Im Rahmen dieser Betrachtungen wird insbesondere dem Einsatz eines integrierten Controllingsystems beschrieben und dessen Vorteile aufgezeigt. Abschließend werden die Anforderungen an ein effizientes Controllingsystem beschrieben.

Kapitel 3, Softwaretechnische Grundlagen, beschäftigt sich mit den softwaretechnischen Aspekten, die für die Durchführung der Ist-Analyse (Kapitel 4) und der Neukonzeption (Kapitel 5) zu Grunde gelegt werden. Hierbei werden die in der Arbeit durchgeführten Aufgaben zunächst in den Kontext der Software-Technik eingeordnet. Danach werden die relevanten Phasen des Softwareentwicklungsprozesses den entsprechenden Kapiteln der Arbeit zugeordnet. Abschließend erfolgt eine Einführung der verwendeten Notationen.

Das vierte Kapitel, Analyse und Dokumentation des Ist‐Zustandes des Forecastsystems, thematisiert die Evaluation und grafische Modellierung des vorhandenen Systems. Neben der Beschreibung der Use Cases, der Workflows, der Sequenzdiagramme und des Datenmodells richtet sich hierbei das Augenmerk auf die vorhandenen Funktionalitäten des Forecastsystems im Vergleich zu den in Kapitel 3 beschriebenen Anforderungen an ein effizientes System. Aus diesem Vergleich werden Verbesserungsvorschläge abgeleitet.

In Kapitel 5, Neukonzeption und Beschreibung des Soll‐Zustandes des zukünftigen Systems, werden, aufbauend auf den im vierten Kapitel ermittelten Optimierungsbedarf, zunächst ein Grobentwurf und anschließend ein Feinentwurf konzipiert. Letzterer soll die Grundlage für die spätere Implementierung des Systems in einer frei wählbaren Zielsprache sein. Diese ist jedoch nicht Teil dieser Arbeit.

Das sechste Kapitel, Zusammenfassung und Ausblick, resümiert die durchgeführten Aufgaben gemäß der Zielstellung und beantwortet die im einleitenden Kapitel gestellte Frage nach der praktischen Durchführbarkeit der verwendeten Methode. Darüber hinaus erfolgt ein Ausblick auf die sich anschließenden Aufgaben zur Implementierung des betriebsbereiten Forecastsytems, die den Rahmen dieser Arbeit überschreiten.

Kapitel 7 bildet den Anhang. Hier sind alle im Rahmen der Erstellung dieser Arbeit entwickelten Abbildungen und die für die Arbeit relevanten Dokumente angefügt, sofern sie nicht in der Arbeit selbst erläutert wurden.

Inhaltsverzeichnis:

	Inhaltsverzeichnis	ii
	Abbildungsverzeichnis	iv
	Abkürzungsverzeichnis	vi
	Vorwort	1
1.	Einleitung	2
1.1	Zielsetzung	2
1.2	Aufbau der Arbeit	2
2.	Grundlagen des Controlling in einer Medienunternehmung	4
2.1	Einordnung in den betriebswirtschaftlichen Kontext	4
2.1.1	Film- und Fernsehwirtschaft als Teil der Medienbetriebslehre	4
2.1.2	Besonderheiten der Film- und Fernsehwirtschaft	5
2.2	Die vier Phasen der Herstellung eines Film-/Fernsehprojektes	5
2.2.1	Erste Phase - Der kreative Prozess	7
2.2.2	Zweite Phase - Der strategische Prozess	7
2.2.3	Dritte Phase - Der operative Prozess	7
2.2.4	Vierte Phase - Der Verwertungsprozess	8
2.3	Abgrenzung des Controllingbegriffs	8
2.3.1	Strategisches Controlling	9
2.3.2	Operatives Controlling	11
2.3.3	Finanzcontrolling	13
2.4	Die Besonderheiten des Controlling in der Film-/Fernsehbranche	15
2.5	Der Nutzen eines integrierten Systems für das Projektcontrolling	16
2.6	Anforderungen an ein effizientes Controllingsystem	17
2.6.1	Systemseitige Funktionalitäten	17
2.6.2	Betriebswirtschaftliche Funktionalitäten	17
2.6.3	Allgemeine Funktionalitäten	19
3.	Softwaretechnische Grundlagen	21
3.1	Einordnung in die Software-Technik	21
3.1.1	Was ist eigentlich Software-Technik?	21
3.1.2	Konzept von Vorgehensmodellen	22
3.2	Aufgaben der Phase „Analyse und Definition“	23
3.2.1	Anforderungserhebung	24
3.2.2	Lastenheft und Pflichtenheft - Zweck und Aufbau	25
3.3	Aufgaben der Phase „Entwurf“	27
3.4	Notationen	28
3.4.1	Modellierung mit der UML 2	28
3.4.1.1	UML 2.0 - Use Case (Anwendungsfalldiagramm)	28
3.4.1.2	UML 2.0 - Aktivität (Aktivitätsdiagramm)	29
3.4.1.3	UML 2.0 - Sequenzdiagramm	30
3.4.1.4	UML 2.0 - Klassendiagramm	31
3.4.2	(Konzeptionelles) Datenmodell	33
3.4.3	Relationale Datenmodellierung	34
4.	Analyse und Dokumentation des Ist-Zustandes des Forecastsystems	36
4.1	Allgemeine Beschreibung der Funktionsweise des Forecastsystems	36
4.2	Ableitung und Dokumentation der Use Cases, Aktivitäten und Benutzerschnittstellen aus der bestehenden Clientapplikation	38
4.2.1	Gesamtübersicht „System und Akteure“	38
4.2.2	„Login“	40
4.2.3	Subsystem „Benutzerverwaltung“	44
4.2.4	Subsystem „Forecast“	48
4.2.4.1	Teilsystem „Forecast-Abschluss“	48
4.2.4.2	Teilsystem „Projekt-Forecast bearbeiten“	53
4.3	Analyse und Dokumentation des bestehenden Datenmodells und der Datenbankprozesse	76
4.3.1	Analyse und Dokumentation des Datenmodells	77
4.3.2	Analyse und Dokumentation der Datenbankprozesse	84
4.4	Fazit über den Ist-Zustand des Forecastsystems	88
4.4.1	Vergleich der Anforderungen an ein Controllingsystem mit dem evaluierten Ist-Zustand des Forecastsystems	89
4.4.2	Bestehender Optimierungsbedarf des Forecastsystems	90
5.	Neukonzeption und Beschreibung des Soll-Zustandes des zukünftigen Systems	91
5.1	Grobentwurf des Soll-Systems	91
5.1.1	Struktur der Architektur	91
5.1.2	Betrachtung möglicher Technologien zur Umsetzung des Sollzustandes	93
5.1.2.1	Datenbanken	94
5.1.2.2	Webserver	95
5.1.2.3	Webanwendungen / Webapplikationen	96
5.1.3	Benennung der erforderlichen Dialoge	98
5.2	Feinentwurf des Soll-Systems	98
5.2.1	Zukünftiges statisches Modell - Klassen- und Komponentendiagramm	99
5.2.2	Relationales Modell - Mapping der Tabellen	102
5.2.3	Funktionalität - Logik auf der Ebene des Webservers	104
5.2.4	Spezifikation der Dialoge	105
5.2.5	Beispiel - Mögliche Dialoge des Kommentareditors	108
6.	Zusammenfassung und Ausblick	110
7.	Anhang	112
	Literaturverzeichnis	116

Textprobe:

Kapitel 4.2.3, Analyse und Dokumentation der Datenbankprozesse:

Neben der Beschreibung des Datenmodells ist es zum Verständnis des Systems notwendig eine Beschreibung der Funktionsweise der „Stored Procedures“, „Data Transformation Services“ und „Trigger“ zu geben. Diese Datenbankprozesse dienen einerseits dazu, Daten in bzw. aus den Teilsystemen „Import“ und „Export“ zu portieren und andererseits die Verbindung zwischen diesen beiden Teilsystemen und dem Kernsystem „Forecast“ herzustellen und aufrecht zu halten.

Nachfolgend werden die im bisherigen System vorhandenen und in der Datenbank vorgefundenen „Stored Procedures“, „Data Transformation Services“ und „Trigger“ zunächst aufgezählt und dann ihre Aufgaben beschrieben.

Stored Procedures (gespeicherte Prozeduren):

„Stored Procedures“ sind beim Datenbankserver gespeicherte Prozeduren, die bei Aufruf die hinterlegten Tätigkeiten und Befehle ausführen. In der Datenbank sind die folgenden vier Prozeduren hinterlegt:

- „sp_Projektkostenverteilung_4“.

- „sp_Projektkostenverteilung_gesamt“.

- „sp_Rebuild_T_Export_PP_from_T_Basisdaten_Vormonat“.

- „sp_UpdASAP“.

Die Prozedur „sp_Projektkostenverteilung_4“ ist eine neue Version der Prozedur „sp_Projektkostenverteilung_gesamt“ und tritt an deren Stelle im Programm.

Innerhalb der Prozedur „sp_Projektkostenverteilung_4“ werden zunächst alle freigegebenen Kostenträger in der Datenbanktabelle „T_PP_Projekttabelle“, die nicht in die Datenbanktabelle „T_Export_PP“ eingetragen sind, durchlaufen und alle Werte gelöscht, deren Attribut „ZeitID“ größer als das Attribut „ZeitID“ des letzten abgeschlossenen Monats ist.

Danach werden die Feldbezugstypen 'pag' und 'kalk' durchlaufen. Innerhalb dieser Schleife wird zuerst das Attribut „GesamtAnzahlFolgen“ in der Datenbanktabelle „T_Folgen_Prod“ berechnet. Danach wird das Attribut „VerbleibendenFolgen“ in der Datenbanktabelle „T_Folgen_Prod“ unter Berücksichtigung des Feldbezugstyps bzw. des entsprechenden Folgendatums berechnet, um anschließend alle Kostenarten in der Datenbanktabelle „T_Basisdaten_Uebernahme“ für den aktuellen Kostenträger zu durchlaufen.

Das Attribut „JahressummeACT“ wird aus der Datenbanktabelle „T_Basisdaten_Uebernahme“ für den aktuellen Kostenträger und die aktuelle Kostenart berechnet.

Nachfolgend erfolgt die Berechnung der „JahressummeVM“ aus der Datenbanktabelle „T_Basisdaten_Vormonat“ (ebenfalls für den aktuellen Kostenträger und die aktuelle Kostenart) sowie die Berechnung der „RunYears“ und der Anzahl der Folgen im Monat für den aktuellen Kostenträger und Feldbezugstyp.

Als letzter Schritt des Schleifendurchlaufes erfolgt die Berechnung des Faktors nach der Formel:

(JahressummeACT – JahressummeVM) / VerbleibendenFolgen.

Mit diesem Faktor wird die „SummeTotalVM“ berechnet, die in die Datenbanktabelle „T_Export_PP“ geschrieben wird.

Danach werden Korrekturbuchungen für Sonderfälle durchgeführt. Falls ein Projekt bereits abgeschlossen ist, jedoch noch Buchungen auf das Projekt durchgeführt werden, wird die Differenz immer in den aktuellen Monat geschrieben.

Zum Ende der Prozedur erfolgen ein Update zum Entfernen aller Freigaben sowie ein Update zum Hinzufügen der Spalte „Feldbezug“ in der Datenbanktabelle „T_Export_PP“ auf Basis der Kostenart und des Views „V_Kostenart2Bezug“.

In Summe dient diese Prozedur also dazu, entsprechend der Rechnungslegungsvorschriften die Projektkosten entsprechend für den Monatsabschluss aufzubereiten.

Die Prozedur „sp_Rebuild_T_Export_PP_from_T_Basisdaten_Vormonat“ ermöglicht das Neubefüllen der Datenbanktabelle „T_Export_PP“ mit den Werten aus den Datenbanktabellen „T_Basisidaten_Vormonat“ und „T_Kostenart_2_Bezug“ abzüglich der Datensätze, für die das Attribut „PPZeitID“ kleiner gleich „0“ ist. Dies erfolgt durch entsprechende Transformierung der Datensätze mittels Views.

Die Prozedur „sp_UpdASAP“ lädt einen auf dem Server „Scope“ hinterlegten und nicht näher definierten DTS-Prozess und führt diesen aus.

Data Transformation Services (Aufträge / DTS-Prozesse):

Die für das Forecastsystem hinterlegten DTS-Prozesse dienen einerseits dem Import der Daten aus den Quellsystemen in bestimmte Tabellen innerhalb der Datenbank als auch der Anpassung der Benutzerdaten. Die DTS-Prozesse werden täglich zu unterschiedlichen Uhrzeiten angestoßen (siehe Abbildung 60).

In der Datenbank sind aktuell die folgenden sieben DTS-Prozesse hinterlegt:

- „ALLKTR“.

- „Delete Kostenarten between 50000 and 59999“.

- „Erstelle_Basisdaten_ACT_VM_V1.0“.

- „Import_codaviewpp2003“.

- „Import_scope“.

- „Importpeps“.

- „Update_KTR_User“.

Der DTS-Prozess „ALLKTR“ legt zuerst die Datenbanktabelle „T_User“ an und stellt die Verbindung zur Datenquelle und dem SQL-Server her. Danach werden die Daten von der Tabelle „usertable“ in die Datenbanktabelle „T_User“ kopiert. Anschließend werden die neuen User aus der Datenbanktabelle „T_User“ in die Datenbanktabelle „T_Allprojects“ eingefügt. User, die alle Projekte sehen dürfen werden aus der Datenbanktabelle „T_Allprojects“ gelöscht und in der Datenbanktabelle „T_KTRUSER“ freigeschaltet.

Der DTS-Prozess „delete Kostenarten between 50000 and 59999“ stellt eine Verbindung zur Datenbank auf dem SQL-Server her und löscht die Kostenarten zwischen 50000 und 59999 aus der Datenbanktabelle „T_Basisdaten_ACT“.

Der DTS-Prozess „Erstelle_Basisdaten_ACT_VM_V1.0“ löscht zunächst die Werte aus der Datenbanktabelle „T_TempErw_BUD“. Danach werden die Werte für das Budget und die Erwartungen aus der Datenbanktabelle „T_Basisdaten_ACT“ in der Datenbanktabelle „T_TempErw_BUD“ zwischengespeichert. Die Datenbanktabelle „T_Basisdaten_ACT“ wird gelöscht und neu angelegt. Danach werden die Indexe „IX_T_Basisdaten_ACT“ mit den Parametern (KTR, Herkunft) und „IX_T_Basisdaten_ACT_1“ mit den Parametern (KTR, Kostenart) erzeugt. Anschließend wird eine Verbindung zur Datenbank auf dem SQL-Server erstellt und die Datenbanktabelle „T_Basisdaten_ACT“ mit aktuellen Daten aus den Quellsystemen über den View „V_erst_Basisdaten2“ gefüllt. Im Anschluss werden die „Haben“-Buchungen der Datensätze aufbereitet, bei denen die Werte des Attributes „Konto“ größer als 79999 und kleiner als 90000 sind. Es erfolgt ein Vorzeichenwechsel. Als letzter Schritt werden die Datensätze aus der Datenbanktabelle „T_TempErw_BUD“ an die Datenbanktabelle „T_Basisdaten_ACT“ angefügt.

Innerhalb des DTS-Prozesses „Import_codaviewpp2003“ wird zunächst die Datenbanktabelle „quelldaten_coda1“ gelöscht und anschließend neu angelegt. Nach Herstellen der Verbindung zur Tabelle „codaprod9“ auf dem Server „172.23.5.71\\sql02“ werden die Daten transformiert. Dies ist jedoch nicht näher ausgeführt, da die zur Verfügung stehende Datenbank nur eine Replik der sich im Einsatz befindlichen Originalen ist. Weiterhin wird eine Verbindung zur Datenbank auf dem Server „Scope“ erstellt.

Anschließend werden die Folgen in der Datenbanktabelle „quelldaten_coda1“ gesetzt und eine Kostenartenkorrektur in der Datenbanktabelle „quelldaten_coda1“ mittels der Datenbanktabelle „T_Kostenartenmapping“ durchgeführt. Danach wird eine weitere, nicht weiter definierte Kostenartenkorrektur durchgeführt. Im Anschluss werden alle Datensätze mit dem Wert „9998“ für das Attribut „Periode“ aus der Datenbanktabelle „quelldaten_coda1“ gelöscht. Als letzter Schritt werden die Datensätze mit dem Wert „9999“ für das Attribut „Periode“ und dem Wert „JA-GUV“ für das Attribut „doccode“ aus der Datenbanktabelle „quelldaten_coda1“ gelöscht.

Der DTS-Prozess „Import_scope“ löscht zuerst die Datenbanktabelle „quelldaten_scope1“ und legt sie dann neu an. Anschließend wird eine Verbindung zur Datenbank „wfUser_SCOPE“ auf dem Server „172.23.5.71\\sql02“ erstellt. Danach werden die Daten von vom View „view_scope1“ in Datenbanktabelle „quelldaten_scope1“ kopiert und dazu eine Verbindung zur Datenbank auf dem Server „Scope“ erstellt.

Der DTS-Prozess „Importpeps“ löscht die Datenbanktabelle „T_PEPS“ und legt sie danach neu an. Danach stellt er eine Verbindung zur Datenbank „PQM4DB“ auf dem SQL-Server her und kopiert die Daten vom View „view_scope1“ in die Datenbanktabelle „quelldaten_scope1“, nachdem die Verbindung zur Datenbank auf dem SQL-Server erstellt wurde.

Der DTS-Prozess „Update_KTR_User“ stellt eine Verbindung zum SQL-Server her und führt ein Update der Kostenträgeranzeige in der Datenbanktabelle „T_KTRUSER“ durch.