Business Intelligence für Prozesscontrolling: Konzeption eines Business-Intelligence-Systems für subjektorientierte Geschäftsprozesse unter Beachtung strategischer Controlling-Instrumente [1 ed.] 9783896446053, 9783896736055

Citation preview

Peter Singer

Business Intelligence für Prozesscontrolling Konzeption eines Business-Intelligence-Systems für subjektorientierte Geschäftsprozesse unter Beachtung strategischer Controlling-Instrumente

Verlag Wissenschaft & Praxis

Business Intelligence für Prozesscontrolling

Peter Singer

Business Intelligence für Prozesscontrolling Konzeption eines Business-Intelligence-Systems für subjektorientierte Geschäftsprozesse unter Beachtung strategischer Controlling-Instrumente

Verlag Wissenschaft & Praxis

Bibliografische Information der Deutschen Bibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN 978-3-89673-605-5 © Verlag Wissenschaft & Praxis Dr. Brauner GmbH 2011 D-75447 Sternenfels, Nußbaumweg 6 Tel. +49 7045 93 00 93 Fax +49 7045 93 00 94 [email protected] www.verlagwp.de Druck und Bindung: Esser Druck GmbH, Bretten

Alle Rechte vorbehalten Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Vorwort Es war mein Wunsch eine Arbeit zu schreiben, die meinen Interessen für Bereiche der Wirtschaftsinformatik, wie z. B. Geschäftsprozessmanagement, Unternehmensarchitektur, ERP oder SOA entspricht und damit auch eine Fortsetzung meiner vorausgegangenen beruflichen Tätigkeiten darstellt. Hierbei hat mich Dr. Albert Fleischmann, Gründer der Metasonic AG (ehemals jCOM1) unterstützt. Er arbeitet als Autor von Fachbüchern und wissenschaftlichen Publikationen, sowie in seinem Unternehmen an einigen solchen Themen, besonders an der Erforschung subjektorientierter Geschäftsprozesse. Durch diese übereinstimmenden Interessen hat sich bereits im Vorfeld zu dieser Arbeit ein Kontakt zwischen Herrn Dr. Fleischmann und mir ergeben. Die Idee der vorliegenden Arbeit entstand aus zwei Richtungen. Zum einen hatte ich die Idee, dass die Software von Metasonic, welche die Einführung subjektorientierter Geschäftsprozesse in einem Unternehmen ermöglicht, um eine Controlling-Unterstützung erweitert werden könnte. Zum anderen hatte mir Herr Dr. Fleischmann dieselbe Idee vorgeschlagen. Konkrete Richtungen und Formulierungen entstanden dann bei meiner Einarbeitung und Erstellung einer Disposition, sowie bei der Entstehung der Begriffsabgrenzungen. Ich danke Herrn Dr. Fleischmann und Herrn Professor Dr. Frank Herrmann für die Unterstützung bei der Entstehung dieser Arbeit.

5

Inhaltsverzeichnis Abbildungsverzeichnis .......................................................................................... 9 Tabellenverzeichnis............................................................................................. 11 Abkürzungsverzeichnis: ...................................................................................... 13 1. Einleitung ...................................................................................................... 15 1.1 Relevanz ................................................................................................ 15 1.2 Ziel ........................................................................................................ 16 1.3 Vorgehensweise .................................................................................... 16 2. Grundlagen .................................................................................................... 19 2.1 Darstellung des subjektorientierten Geschäftsprozess-Management (S-GPM) ................................................................................................ 19 2.1.1 Formale Abgrenzung von Prozessbegriffen ............................... 19 2.1.2 Allgemeines Geschäftsprozess-Management (GPM)................. 20 2.1.3 Subjektorientiertes Geschäftsprozess-Management (S-GPM) ... 22 2.1.4 Klassifizierung von Unternehmen nach GPM-Einsatz............... 27 2.2 Überblick über Business-Intelligence (BI), Controlling und artverwandte Bereiche........................................................................... 29 2.2.1 Definitionen benötigter Begriffe................................................. 29 2.2.2 Abgrenzung und Zusammenhänge zwischen den benötigten Begriffen ............................................................ 34 2.3 Strategische Controlling-Instrumente ................................................... 40 2.3.1 Prozess-Outsourcing ................................................................... 41 2.3.2 Prozess-Benchmarking ............................................................... 42 2.3.3 Prozessorientierte SWOT-Analyse ............................................. 45 2.3.4 Szenarioplanung und Prozessvarianten ...................................... 48 2.3.5 Prozessorientierte Gap-Analyse.................................................. 49 2.3.6 Prozessorientierte Potenzialanalyse............................................ 50 7

2.3.7 Wertschöpfungskettenanalyse .................................................... 52 2.3.8 Prozessbündelungsanalyse.......................................................... 55 2.3.9 Spezielle Controlling-Instrumente.............................................. 56 2.4 Prozesskostenrechnung (PKR).............................................................. 57 2.4.1 Einordnung der PKR................................................................... 57 2.4.2 Besondere Aufgaben der PKR.................................................... 58 2.4.3 PKR-Verfahren im BI-System.................................................... 58 3. Systemerstellung ........................................................................................... 71 3.1 Systemanforderungen............................................................................ 71 3.2 Datenerhebung ...................................................................................... 71 3.3 Festlegung der Prozess-Sichten ............................................................ 72 3.4 Zuweisen von Prozessabhängigkeiten .................................................. 76 3.5 Integration der PKR in das BI-System.................................................. 78 3.6 Integration der Controlling-Instrumente in das BI-System .................. 83 4. Ausblick ........................................................................................................ 91 Literaturverzeichnis:............................................................................................ 93 Stichwortverzeichnis ........................................................................................... 97

8

Abbildungsverzeichnis Abbildung 1: Übersicht über ausgewählte Diagrammsprachen ....................... 21 Abbildung 2: Subjektorientiert dargestellter GP Reisekostenantrag ............... 24 Abbildung 3: Subjektverhalten Mitarbeiter zum GP Reisekostenantrag.......... 25 Abbildung 4: Subjektverhalten Kompetenzträger zum GP Reisekostenantrag ....................................................................... 26 Abbildung 5: Subjektverhalten Sachbearbeiter zum GP Reisekostenantrag .... 27 Abbildung 6: Begriffliche Zusammenhänge nach Aufgabenbereichen............ 40 Abbildung 7: Wertschöpfungskette zu einem Erzeugnis aus Prozesssicht....... 53 Abbildung 8: Grundstruktur der Prozesskostenrechnung ................................ 59 Abbildung 9: Festlegung der Sichten als Grundlage für das BI-gestützte Prozess-Controlling..................................................................... 75 Abbildung 10: Beispiel zur Schnittstelle der Prozessabhängigkeiten in der Prozessabhängigkeiten-Untersicht zur SID-Sicht ............ 77 Abbildung 11: Beispiel für eine PKR-Sicht........................................................ 82 Abbildung 12: Festgelegte Sichten im BI-System nach Integration der Prozessabhängigkeiten, der PKR und der strategischen Controlling-Instrumente.............................................................. 89

9

Tabellenverzeichnis Tabelle 1:

Schwerpunkte ausgewählter Modellierungssprachen und Konsequenzen für die Implementierung von Software/Workflows ....................................................................... 23

Tabelle 2:

Unterschiede zwischen Controlling und Business-Intelligence ..... 35

Tabelle 3:

Bestandteile des Benchmarking-Prozesses..................................... 43

Tabelle 4:

Neue Aufgabenaufteilung zwischen BI-System und Controller .... 45

Tabelle 5:

Beispiel für eine prozessorientierte SWOT-Analyse, als Argumentation........................................................................... 46

Tabelle 6:

Beispiel für eine prozessorientierte SWOT-Analyse, mit Vergleichszahlen ...................................................................... 47

Tabelle 7:

Prozessmengen................................................................................ 61

Tabelle 8:

Beispiel zur Ermittlung der Prozesskosten ..................................... 64

Tabelle 9:

Bestimmung des Hauptprozesskostensatzes................................... 68

Tabelle 10: Strategische Produktkalkulation ..................................................... 69

11

Abkürzungsverzeichnis BI:

Business-Intelligence

BPMN:

Business-Process-Modeling-Notation

BPR:

Business-Process-Reengineering

CPM:

Corporate-Performance-Management/Business-PerformanceManagement

CRM:

Customer-Relationship-Management

DDS:

Decision-Support-System

DWH:

Data-Warehouse

eEPK:

Erweiterte Ereignisgesteuerte Prozesskette

EIS:

Executive-Information-System

EPK:

Ereignisgesteuerte Prozesskette

ERP-System: Enterprise-Resource-Planning-System EUS:

Executive-Information-System

GP:

Geschäftsprozess

GPM:

Geschäftsprozess-Management

IKT:

Informations- und Kommunikationstechnologie

KPI:

Key Performance Indicators

KR:

Kostenrechnung

lmi:

Leistungsmengeninduziert

lmn:

Leistungsmengenneutral

LVS:

Lagerverwaltungssystem

MIS:

Management-Information-System

MSS:

Management-Support-System 13

OLAP:

Online Analytical Processing

PKR:

Prozesskostenrechnung

PLM:

Produkt Lifecycle Management

POKR:

Prozessorientierte Kostenrechnung

PWH:

Process-Warehouse

RFID:

Radio-Frequency Identification

S-GP:

Subjektorientierter Geschäftsprozess

S-GPM:

Subjektorientiertes Geschäftsprozess-Management

SCM:

Supply Chain Management

SID:

Subjektinteraktionsdiagramm

SVD:

Subjektverhaltensdiagramm

SWOT:

Strengths/Weaknesses, Opportunities/Threats

UML:

Unified Modeling Language

14

1. Einleitung 1.1

Relevanz

Die S-BPM-Suite (S-BPM steht für subjektorientiertes Business-ProcessManagement, wobei dies, von diesem Eigennamen abgesehen, in dieser Arbeit als S-GPM, also subjektorientiertes Geschäftsprozess-Management, bezeichnet wird) von Metasonic ermöglicht es einem Unternehmen, Prozesse zu abstrahieren und in einem Modell darzustellen. Solche Modelle können von beliebigen verantwortlichen Mitarbeitern des Unternehmens erstellt und dann optimiert werden. Bei der Durchführung eines Prozesses stößt die S-BPM-Suite das jeweilige Subjektverhalten eines Mitarbeiters an. Der Mitarbeiter loggt sich ein und erfährt dort seine nächsten Arbeitsschritte. Sobald der Mitarbeiter das Subjektverhalten durchgeführt und beendet hat, gibt er diese Information in die S-BPM-Suite ein. Diese stößt daraufhin das nachfolgende Subjektverhalten eines Mitarbeiters, oder auch mehrere Subjektverhalten an. Dadurch wird das Prozessmodell umgesetzt und gesteuert. Die S-BPM-Suite dokumentiert dabei automatisch die Daten zur Prozessführung, wie z. B. Einloggzeiten und Ausloggzeiten. Es wäre auch möglich, auf diesen und weiteren Daten ein System aufzubauen, welches das Controlling und das Management bei Ihren Entscheidungen und Vorgehensweisen unterstützt. Ein System, das dem Controller Transparenz zu den Prozessen und auch geeignete Instrumente liefert, mit denen er strategische Verbesserungen und damit höhere Wettbewerbsfähigkeit erzielen kann. Dies könnte im Rahmen eines auf das S-GPM spezifisch abgestimmtes und integriertes Business-Intelligence-Systems (BI-Systems) geschehen. Der Vorteil von BI bei S-GPM im Vergleich zu BI bei GPM liegt an den zwei Modellierungsebenen, der SVD (d. h. Subjektverhaltensdiagramm) und der SID (d. h. Subjektinteraktionsdiagramm), bei denen Subjekte eigenständig verwaltet werden. Dadurch ist die Zuordnung und Auswertung der objektbezogenen Daten besonders einfach. 15

1.2

Ziel

Ziel dieser Arbeit ist es, die angesprochenen Möglichkeiten im Rahmen einer BI (siehe 1.1) herauszuarbeiten. Sie soll ein Bindeglied sein, zwischen dem subjektorientierten Geschäftsprozess-Management (S-GPM) und der BusinessIntelligence (BI). Dabei sollen folgende Fragestellungen beantwortet werden: • Welche strategischen Controlling-Instrumente gibt es? • Wie kann der Controller durch Automatisierung strategische ControllingInstrumente im Rahmen eines BI-Systems entlastet und unterstützt werden? • Welche Daten und Datenstrukturen sollen für das BI-System erhoben werden? • Welche Berechnungsverfahren sollen im BI-System realisiert werden? • In welchen Sichten soll das BI-System mit dem Controller interagieren? Das hierbei entstehende BI-System soll auch Grundlage sein für die weitere Ausarbeitung einer BI-Erweiterung für die S-BPM-Suite von Metasonic. Durch die enge Verknüpfung ergeben dabei das BI-System und die S-BPM-Suite zusammen ein Gesamtsystem.

1.3

Vorgehensweise

Zu Beginn (siehe 2.1 bis 2.2) wird diese Arbeit in die Begrifflichkeit des fachliterarischen Umfeldes eingebettet. Dazu werden zunächst die für die jeweiligen Themen relevanten Begriffe auf Basis verschiedener Fachbücher definiert. Darauf aufbauend werden dann die Relationen der Begriffe zueinander herausgearbeitet. Im darauffolgenden Teil (siehe 2.3) werden strategische Controlling-Instrumente vorgestellt. Nach jeder Vorstellung folgt die Prüfung, ob und zu welchem Grad das jeweilige Instrument von dem BI-System dieser Arbeit automatisiert werden kann, welche Aufgaben in der Hand des Controllers bleiben, und wie das BISystem den Controller bei seinen verbleibenden Aufgaben unterstützen kann. 16

Außerdem wird die Prozesskostenrechnung als Grundlage für die strategischen Controlling-Instrumente und für das BI-System vorgestellt (siehe 2.4). Im letzten Teil (siehe 1.) erfolgt die Erstellung des BI-Systems. Dazu werden zunächst die Rahmenbedingungen des BI-Systems geschaffen, auf denen die Controlling-Instrumente aufbauen können. Diese sind die Festlegung der Sichten und der Schnittstellen für die Zuweisung der Prozessabhängigkeit, sowie der Prozesskostenrechnung (PKR). Darauf aufbauend werden nun die Teile der Controlling-Instrumente konkret in das BI-System integriert, die bereits im vorhergehenden Teil herausgearbeitet wurden.

17

2. Grundlagen 2.1

Darstellung des subjektorientierten Geschäftsprozess-Management (S-GPM)

2.1.1

Formale Abgrenzung von Prozessbegriffen

In der Literatur findet man eine Vielzahl von teilweise sogar widersprüchlichen Definitionen von Geschäftsprozessen (GPs), sowie für deren weitere Differenzierung. In dieser Arbeit soll für die Begriffe Prozess, GP, die Differenzierungen von GP, sowie GPM folgende Abgrenzung gelten: Ein Prozess ist noch etwas ganz allgemein Gehaltenes: eine Menge von Aktivitäten mit Input und Ergebnis (vgl. [HaCh94]). Ein GP ist eine Abfolge von Aufgaben, die von mehreren Organisationseinheiten ausgeführt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen (vgl. [Gada08] S. 46). Laut [Gada08] (S. 49f) ist eine weitere Differenzierung von GPs üblich: 1.

Steuerungsprozesse (Führungsprozesse) Sie verantworten das integrative Zusammenspiel der Gesamtheit der Geschäftsprozesse.

2.

Kerngeschäftsprozesse (Primärprozesse) Sie kennzeichnen sich damit, dass sie beim Kunden beginnen und beim Kunden enden. Sie haben einen hohen Wertschöpfungsanteil im Unternehmen und sind in der Regel wettbewerbskritisch.

3.

Unterstützungsprozesse (Querschnittsprozesse) Das sind GPs mit keinem oder nur geringem Wertschöpfungsanteil. Sie sind in der Regel nicht wettbewerbskritisch.

19

GPM ist ein integriertes Konzept von Führung, Organisation und Controlling, das eine zielgerichtete Steuerung der Geschäftsprozesse ermöglicht und das Unternehmen auf die Erfüllung der Bedürfnisse der Kunden und anderer Interessengruppen (Mitarbeiter, Kapitalgeber, Gesellschafter, Lieferanten, Partner) ausrichtet (vgl. [ScSe02] (S.5)). 2.1.2

Allgemeines Geschäftsprozess-Management (GPM)

In diesem Abschnitt soll zunächst der Sinn des GPM im Unternehmen hergeleitet und dann die verschiedenen Möglichkeiten angesprochen werden, mit denen Prozesse dargestellt werden können. Damit soll die Rolle der Subjektorientierung innerhalb der GPM-Thematik vermittelt werden: Ein Betrieb bearbeitet eine Vielzahl von GPs, beispielsweise eine Kundenbestellung oder einen Dienstreiseantrag. Bei kleineren Betrieben ist es möglich, diese GPs ohne spezielle Methoden und informationstechnologischer Unterstützung zu bewältigen. So kann ein Mitarbeiter den Dienstreiseantrag einfach dem Firmenchef vorlegen, und bekommt ihn sofort, mit der zugehörigen Entscheidung, wieder zurück. Je größer ein Unternehmen ist, desto komplexer werden im Allgemeinen die Wege, welche Informationen oder Business-Objekte zurücklegen. Laut [Sche05] (S. 29) sind 300.000 zu verarbeitende Prozesse und mehr als 25 Millionen gespeicherte Prozessinstanzen keine Seltenheit. Je höher diese Komplexität, umso unübersichtlicher werden die GPs im Einzelnen und in ihrer Gesamtheit im Betrieb. Mit der Komplexität und der Unübersichtlichkeit steigt auch die Schwierigkeit der Optimierung. GPM ist daher eine Notwendigkeit. Deutsche Unternehmen investieren trotz oder gerade in Phasen, die von Kostendruck und geringerer Budgets geprägt sind, viel Geld in das GPM. Mit schlanken und wertschöpfenden Prozessen wird versucht, Erfolge zu erzielen (vgl. [Gada08] (S. 1)). Dies kann Kosten reduzieren und dazu beitragen, strategische Ziele rascher zu erreichen (vgl. [FiFO06] (S. 1)).

20

Das Modellieren eines GPs kann in verschiedenen Notationen erfolgen. Dafür gibt es eine Vielzahl von Diagrammsprachen, mit denen Prozesse dargestellt werden können. Hier eine Übersicht über ausgewählte Diagrammsprachen:

Diagrammbasierte Methoden

DatenflussOrientiert

Kontrollflussorientiert

Objektorientiert

IDEFDiagramme

Petri-Netze

Erweiterte EPK

Activity Diagramm (UML)

VorgangsereignisSchema (SOM)

DatenflussDiagramme (SSA)

Struktogramme

AufgabenkettenDiagramm (PROMET)

Use Case Diagramm (UML)

StatechartDiagramm

Fluss-Diagramme (SADT)

SwimlaneDiagramme

GPM-Diagramme

InteraktionsDiagramm (SOM)

ActivitychartDiagramm

Folgestruktur und Folgeplan

Business Process Modeling Notation (BPMN)

Objektorientierte EPK

Abbildung 1: Übersicht über ausgewählte Diagrammsprachen (siehe [Gada08] (S. 81))

Darüber hinaus gibt es noch die subjektorientierte Darstellung.

21

Die beiden in Abbildung 1 grau markierten Felder bilden zusammen mit der subjektorientierten Darstellung die drei wichtigen Notationen, mit denen aktuell gearbeitet wird und auf denen die GPM-Software aufbaut: • EPK bzw. eEPK (erweiterte ereignisgesteuerte Prozesskette) • BPMN (Business-Process-Modeling-Notation) • Subjektorientierte Darstellung (Metasonic) Dieses Arbeit befasst sich mit der subjektorientierten Darstellung, also dem S-GPM. 2.1.3

Subjektorientiertes Geschäftsprozess-Management (S-GPM)

In diesem Abschnitt wird die Entstehung und dann die Funktionsweise von S-GPM beschrieben. Danach folgt ein Beispiel für die Modellierung eines GPs mit der S-BPM-Suite von Metasonic. Bereits in den 90er Jahren wurde festgestellt, dass die streng flussorientierte Beschreibung von Prozessen an ihre Grenzen stößt und nicht immer der betrieblichen Realität entspricht (vgl. [Wahl98]). Im Rahmen der objektorientierten UML (Unified Modeling Language) wurden zu diesem Zweck Activity Diagramms (siehe auch Abbildung 1) eingeführt. Diese Beschreibungsform taucht in der Folgezeit zwar immer wieder in der GP Modellierung auf, hat sich aber in der Praxis nicht durchgesetzt. Die subjektorientierte Beschreibungsform vereint die Vorteile der flussorientierten mit der objektorientierten Beschreibungsform. [FiFO06]. Laut [ScFG09] (S. 54) beruht die subjektorientierte Methodik auf einer Prozessalgebra zur Modellierung paralleler Prozesse mit Subjekten, elementaren Aktionen und Kommunikationsbeziehungen, wie sie in den 1980er Jahren ursprünglich in der Informatik von [Miln80] und [Hoar85] vorgestellt wurde. Im Hinblick auf die praktische Verwendbarkeit der theoretischen Konzepte hat [Flei94] unter anderem eine graphische Notation ergänzt und Aspekte der Objektorientierung integriert.

22

Ausgewählte Modellierungssprachen

Entwicklungsparadigma

Natürliche Sprache

Betrachtung von

Erläuterung

Konsequenzen für die Implementierung von Software/Workflows

-

Sachverhaltsbeschreibung i. d. R. durch ganze Sätze (wer tut was woran?), Ausnahme Passivstil

Automatische Umsetzung in Code bisher nicht möglich

Kontrollflussdiagramm (z. B. Programmablaufplan, Struktogramm)

Funktionsorientierung

Algorithmik (Schrittabfolge), Integration von Subjekten und Objekten i. d. R. nur durch natürlichsprachliche Ergänzungen

Ereignisgesteuerte Prozesskette (EPK)

Funktionsorientierung

Kontrollflussorientierte Prozessdarstellung (Funktionen, Ereignisse)

Fehlende oder nicht ausreichende Beobachtung eines oder mehrerer Sprachelemente führt zu unzulänglichen Anforderungsdefinitionen mit der Folge

Erweiterte ereignisgesteuerte Prozesskette (eEPK)

Funktionsorientierung

Ergänzung der EPK um Organisationseinheiten als Subjekte und Daten als Objekte

Entity Relationship Model (ERM)

Datenorientierung

Integration von Subjekten und Prädikaten nur indirekt durch disziplinierte Bezeichnung der Beziehungen

Unified Modeling Language (UML)

Objektorientierung

Ursprünglich nur Betrachtung von Methoden (Prädikat) und Daten (Objekt), Beachtung der Subjekte erstmals als Akteure (in Anwendungsfalldiagrammen) und Swim Lanes (in Sequenzdiagrammen), die aber nicht weiter detailliert werden

Calculus of Communicating Systems (CCS)

Subjektorientierung

Prozessalgebra zur Modellierung paralleler Prozesse mit Subjekten, elementaren Aktionen (Senden, Empfangen) und Kommunikationsbeziehungen

Business Process Modeling Notation (BPMN)

Funktionsorientierung

Enthält mit Poolkonzept und Nachrichten subjektorientierte Aspekte, der Schwerpunkt liegt jedoch auf Funktionen

Parallel Activity Specification Schema (PASS) mit Subjektinteraktionsdiagramm (SID) und Subjektverhaltensdiagramm (SVD)

Subjektorientierung

Kombination des Calculus of Communicating Systems mit der Objektorientierung und Einführung von zusätzlichen Operationen neben Senden und Empfangen

Subjekt

Prädikat

Objekt

- häufiger Fehlinterpretationen bei der Implementierung, - hohen Aufwands für das Hinzufügen der fehlenden Aspekte und - beschränkter Möglichkeiten der automatischen Umsetzung von Modellen in Code

Ausgewogene Beachtung aller Sprachelemente führt zu vollständigen Anforderungsspezifikationen und ermöglicht automatische Umsetzung von Modellen in Code

Tabelle 1: Schwerpunkte ausgewählter Modellierungssprachen und Konsequenzen für die Implementierung von Software/Workflows (siehe [ScFG09] (S. 55))

Aus Tabelle 1 ist ersichtlich, dass nur bei dem subjektorientierten Entwicklungsparadigma alle Betrachtungen der natürlichen Sprache (Subjekt, Prädikat und Objekt) erfüllt sind. Im Gegensatz zu Abbildung 1 erfolgt hier die Betrachtung im Vergleich zur natürlichen Sprache. Da im Sprachlichen ein Satz aus Subjekt, Prädikat und Objekt besteht, um eine vollständige Beschreibung zu formulieren, wird auch bei der subjektorientierten Prozessbeschreibung im Vergleich zur objektorientierten Beschreibung das Sprachelement „Subjekt“ ergänzt. Die Subjekte sind dabei aktive, handelnde Elemente, z. B. Akteure (vgl. [FiFO06] (S.79)).

23

Bei der subjektorientierten Beschreibung von GPs werden die an einem Prozess Beteiligten ins Zentrum der Betrachtung gestellt (vgl. [Flei94]). Hierzu ein GP, der beispielhaft mit der S-BPM-Suite von Metasonic modelliert wird: Ein Mitarbeiter stellt einen Reisekostenantrag an den betreffenden Kompetenzträger. Dieses prüft den Reisekostenantrag. Das Ergebnis soll dem Mitarbeiter mitgeteilt werden. Im Fall einer Genehmigung soll außerdem der Sachbearbeiter informiert werden, der die Reisekosten an den Mitarbeiter ausbezahlt und auch verbucht. Im ersten Schritt wird dieser GP als Subjektinteraktionsdiagramm (SID) modelliert:

Abbildung 2: Subjektorientiert dargestellter GP Reisekostenantrag (Darstellung an Metasonic-Software angelehnt)

24

Im zweiten Schritt wird zu jedem Subjekt, in diesem Fall Mitarbeiter, Kompetenzträger und Sachbearbeiter, ein Subjektverhaltensdiagramm (SVD) hinterlegt, d. h. es werden die konkreten Subjektverhalten modelliert. Subjektverhalten zum Mitarbeiter:

Abbildung 3: Subjektverhalten Mitarbeiter zum GP Reisekostenantrag (Darstellung an Metasonic-Software angelehnt)

25

Subjektverhalten zum Kompetenzträger:

Abbildung 4: Subjektverhalten Kompetenzträger zum GP Reisekostenantrag (Darstellung an Metasonic-Software angelehnt)

26

Subjektverhalten zum Sachbearbeiter:

Genehmigung erhalten

(von Kompetenzträger) Genehmigung

Auszahlen und buchen

Auszahlen und Buchen erledigt

Prozessende

Abbildung 5: Subjektverhalten Sachbearbeiter zum GP Reisekostenantrag (Darstellung an Metasonic-Software angelehnt)

Jeder Mitarbeiter kann einen solchen GP modellieren. Er wird dann allen Prozessbeteiligten zugänglich gemacht, die ihr persönliches Subjektverhalten online abrufen können. Die Durchführung der GPs wird dabei von der S-BPM-Suite aus gesteuert, wie unter 1.1 beschrieben. 2.1.4

Klassifizierung von Unternehmen nach GPM-Einsatz

Man unterscheidet folgende Unternehmensklassifizierungen, je nach Einsatz von GPM und Organisation: Funktionsorientierte Unternehmen: In rein funktionsorientierten Unternehmen wird GPM nicht betrieben. GPs existieren zwar trotzdem, aber ein gesamter GP wird nicht betrachtet. GPs laufen hier auf verschlungenen Wegen durch viele Funktionseinheiten. Diese Funktionswechsel sind gleichzeitig auch Wechsel in den zuständigen Verantwortun27

gen. Funktionsorientierte Unternehmen kennzeichnen sich damit, dass die Ressourcen für ihre GPs von einer Aufbauorganisation nach Personal, Gebäude, Maschinen, etc. bereitgestellt werden. Funktionsverantwortliche können z. B. Abteilungsleiter für Versand oder für Buchhaltung sein (vgl. [AhKn06] (S. 69)). Prozessorientierte Unternehmen: „Sie verzichtet ganz auf prozessunabhängige ressourcenführende Kostenstellen. Hier besteht die Organisationsstruktur aus den GPs. Sie bilden die Struktureinheiten und tragen damit auch vollständig die von ihnen genutzten Ressourcen. […] In dieser Organisationsform gibt es keine Aufgaben der Verwaltung der Ressourcen außerhalb der Prozesse. Diese müssen also im Rahmen der operativen Ausführung auch die Ressourcenverwaltung übernehmen.“ (Siehe [AhKn06] (S. 71)). Gemischte Prozessorganisation: „In der gemischten Prozessorganisation bleiben funktionale Einheiten grundsätzlich bestehen. Sie bündeln die verschiedenen Ressourcen wie menschliche Kapazitäten, Gebäude, Maschinen, Material, etc. in Ressourcenpools und stellen sie den Prozessen zur Verfügung. Die Leiter der Ressourcenpools sind für die optimale Menge und Qualität der Ressourcen verantwortlich. Für den Ablauf der Prozesse in gestalterischer oder operativer Hinsicht tragen sie jedoch keine Verantwortung. […] Die verantwortlichen Prozessmanager bilden zukünftig im Wesentlichen das Managementteam des Unternehmens (Leiter von bedeutenden Ressourcenpools gehören zusätzlich dazu).“ (Siehe [AhKn06] (S. 71)). Die Systemkonzeption dieser Arbeit geht von einer gemischten Prozessorganisation aus.

28

2.2

Überblick über Business-Intelligence (BI), Controlling und artverwandte Bereiche

2.2.1

Definitionen benötigter Begriffe

Business-Intelligence (BI): „Business Intelligence beschreibt […] einen integrierten Gesamtansatz, welcher es durch die Integration von Strategien, Prozessen und Technologien ermöglichen soll, aus verteilten und inhomogenen Unternehmens-, Markt- und Wettbewerberdaten erfolgskritisches Wissen über Status, Potenziale und Perspektiven zu erzeugen und für die Entscheidungsträger nutzbar zu machen.“ [SLFB06] BI ist „ein integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung.“ [Kem06] BI ist ein Sammelbegriff „zur Kennzeichnung von Systemen […], die auf der Basis interner Kosten- und Leistungsdaten sowie externer Marktdaten in der Lage sind, das Management in seiner planenden, steuernden und koordinierenden Tätigkeit zu unterstützen.“ [ChGl04]. Sie sehen BI nicht als neues Konzept oder Produkt, sondern eher als einen Sammelbegriff für eine Vielzahl unterschiedlicher Ansätze zur Analyse und zum Verständnis von geschäftsrelevanten Prozessen. Der Begriffsteil „Intelligence“ wird in diesem Zusammenhang als Einsicht, Verständnis oder Aufklärung interpretiert (siehe [Gary08] (S. 14f)). Diese Definitionen sind inhaltlich sehr ähnlich und sollen mit folgender Zusammenfassung für diese Arbeit gelten: BI ist ein IT-basierter Gesamtansatz, der Entscheidungsträger in ihrer planenden, steuernden und koordinierenden Tätigkeit durch Integration von Strategien, Prozessen und Technologien unterstützt. BI gilt auch als Sammelbegriff für MSS (Management-Support-System), zu denen MIS (Management-Information-System), DDS (Decision-Support-System) und EUS (Executive-Information-System) gehören (vgl. [Gary08] (S. 19)).

29

Aufgaben der BI (vgl. [Metr02]): • Entscheidungsorientierung • Datensammlung • Datenaufbereitung • Informationsdarstellung • Geschäftsrelevante Information Controlling: Da eine einheitliche Definition nicht existiert, sollen hier einige genannt werden: „Das Controlling ist ein umfassendes und integriertes Koordinations- und Steuerungssystem zur Unterstützung der Entscheidungsträger durch eine zielorientierte Informationsversorgung sowie durch die Koordination von Planungs-, Kontroll- und Informationssystemen. Neben der Beschaffung, Aufbereitung, Analyse und Kommunikation entscheidungsrelevanter Informationen umfasst das Controlling insbesondere Planungs-, Steuerungs- und Koordinationsaufgaben.“ (Siehe [Horv03]). „Controlling verstehen wir als betriebswirtschaftlich fundierte normen-, strategie-, finanz-, markt-, prozess-, informations- und verhaltensorientierte Regelung in Unternehmen. Zweck des Controllings ist das Leisten von Führungsunterstützung, um gemeinsam vereinbarte Unternehmensziele zu erreichen (transparentes Monitoring).“ (Siehe [EsSi09] (S. 40)). Laut [Link04] gibt es keine einheitliche Definition des Controllings. Jedoch findet sich demnach ein Minimalkonsens in der Wissenschaft darin, dass die zentrale Aufgabe des Controllings in dem Einsatz, der Verbesserung und der Koordination von Planungs-, Kontroll- und Informationssystemen liegen sollte. Informationsaufgaben des Controllings (siehe [EsSi09] (S. 84)): • Ermittlung des Informationsbedarfs • Beschaffung der Informationen • Analyse und Aufbereitung

30

• Weiterleitung an jene Adressaten, für die sie von Nutzen sind und denen sie einen Wissenszuwachs bringen. Prozess-Controlling: Die Entwicklung des Prozessmanagement im Controllingumfeld wird noch stark vernachlässigt (vgl. [AhKn06] (S. 22)). Es gibt zu diesem Thema noch relativ wenig Fachliteratur. [Beck07] (S. 49) schreibt: „Das Prozess-Controlling, das die [Aufgaben des Controllings] im Hinblick auf Prozesse als Controlling-Gegenstand erfüllt, stellt ein System zur Verfügung, das die Prozessverantwortlichen und -beteiligten bei der Planung und Kontrolle der Geschäftsprozesse unterstützt und die dafür erforderliche Informationsversorgung und Koordination durchführt.“ Enterprise-Resource-Planning-System (ERP-System): „Bezeichnung für die am meisten verbreitete Art von Standardsoftware, mit der Unternehmen Funktionen wie z. B. Einkauf, Produktion, Vertrieb, Buchhaltung, Finanzbuchhaltung oder Controlling abwickeln können. Prominentester Hersteller ist die SAP AG.“ ([Kell07](S. 272)) Monitoring: „Aus Sicht des IT-Managements im Unternehmen ist Monitoring eine Teilaufgabe des IT-Controllings. [Ziel ist die] Beschaffung, Erhebung und Auswertung von Daten zur Vorbereitung zielorientierter Entscheidung bei der Anschaffung, der Entwicklung und dem Betrieb von IT-Lösungen.“ (Siehe [BVWB07]). „Unter Monitoring verstehen wir die laufende, systematische Beobachtung und Überwachung bestimmter Ziele, Pläne, Prozesse und Ereignisse. Das hat transparent zu erfolgen, d. h. alle Akteure sind in einem Entscheidungsfeld über die normative, strategische und operative Position des Unternehmens informiert. (Siehe [EsSi09] (S. 49)).

31

Neben standardisierten Routinetätigkeiten fällt ein hoher Anteil der anfallenden Aufgaben aus Projekttätigkeiten mit stets individuellen Rahmenbedingungen an (siehe [Wink10] (S. 1)). Prozess-Monitoring: Prozess-Monitoring sind Funktionalitäten innerhalb dem GPM, die relevante Prozessinformationen in laufenden Prozessen messen und darstellen. Allgemein ausgedrückt liefert das Prozess-Monitoring die Daten zur Berechnung und Beurteilung der Prozessleistung und bildet somit die Voraussetzung für ein effektives Prozess-Controlling (vgl. [AhKn06] (S. 225)). Data-Warehouse (DWH): „Als Data Warehouse wird die themenorientierte, vereinheitlichte, beständige, zeitbezogene Sammlung von Daten zur Unterstützung von Managemententscheidungen bezeichnet.“ (Siehe [Inmo96]). Process-Warehouse (PWH): Das PWH ist ein spezielles DWH zur Analyse von Geschäftsprozessen und demnach zur Unterstützung des Prozessmanagements. Das PWH ist auf zwei Säulen aufgebaut: Zum einen auf Prozessmanagement, zum anderen auf BI und DWH (vgl. [Beck07] (S.50)). Prozesskostenrechnung (PKR): Die Kostenrechnung ist ein wesentliches Instrument des Controllers. „Die Prozesskostenrechnung stellt eine Ergänzung der Basiskostenrechnung dar. Als Basissystem wird in Deutschland verbreitet die flexible Plankostenrechnung eingesetzt. Mit der Prozesskostenrechnung wird bei der Verrechnung der Kosten aus indirekten Bereichen die dispositive Verrechnungsmethodik durch eine analytische ersetzt. Prozesse werden als Einfluss- und Bezugsgrößen verwendet und können auf diese Weise direkt in der Kalkulation und Ergebnisrechnung einzeln den Kostenträgern und Sparten zugerechnet werden. Durch die Prozesskostenrechnung findet also eine Verschiebung der Gemeinkosten zu den Einzelkosten

32

statt. Die Prozesskostenrechnung erhält ihre Informationen aus der Prozessdokumentation. (siehe [AhKn06] (S. 180ff)). Prozesskostenrechnung bedeutet im Wesentlichen die Ermittlung und Optimierung der Ablaufkosten durch Analyse, Planung und Prozessmanagement in den indirekten Unternehmensbereichen sowie verursachungsgerechte Verrechnung der indirekten Gemeinkosten auf Produkte, Aufträge, Kunden o. Ä. (siehe [Reme05]). Prozessorientierte Kostenrechnung (POKR): Die PKR kann einerseits als Ergänzung zum bestehenden Kostenrechnungssystem dienen. Dies ist bei Unternehmen mit gemischter Prozessorientierung der Fall (siehe 2.1.4). Andererseits kann die PKR auch im Rahmen einer POKR eingesetzt werden, d. h. dass die gesamte Kostenrechnung eines Unternehmens auf PKR angepasst wird. Dies trifft auf prozessorientierte Unternehmen zu (siehe 2.1.4) (vgl. [AhKn06] (S. 184)). Da die Systemkonzeption dieser Arbeit von Unternehmen mit gemischter Prozessorganisation ausgeht, wird PKR in dieser Arbeit nicht als POKR, sondern ergänzend zum bestehenden Kostenrechnungssystem verwendet. Corporate-Performance-Management (CPM): Synonym lt. [Bilg08] (S. 61) dazu sind Business-Performance-Management, Enterprise-Performance-Management und Business Performance Measurement: Zwar gibt es Fachbücher zu CPM, jedoch sind selbst dort klare und auch übereinstimmende Definitionen noch selten. Das Entstehen von Verständnis für CPM wird nach Ansicht des Verfassers in den nächsten Jahren in der wissenschaftlichen Literatur weiter stattfinden, was nicht Ziel dieser Arbeit sein soll. Dennoch sollen einige der wenigen Ansätze kurz beschrieben werden: Auf einer Entwicklungslinie, die ihren Ursprung in einem frühen MIS (Management-Informations-System) hat, welches Ende der 60er Jahre entstanden ist, und dem Entwicklungen wie BI und DWH folgen, stellt CPM eine der neuesten wissenschaftlichen Entwicklungen dar (vgl. [Oehl06] (S. 13)). 33

CPM ist ein umfassender Ansatz zur prozessorientierten und strategiekonformen Planung, Messung und Steuerung der Unternehmensleistungen, ausgerichtet nach den Unternehmenszielen. [Bilg08] (S. 62). Laut [AhKn06] (S. 225) widmet sich BI dem CPM. CPM beschränkt sich dabei im Unterschied zu klassischem BI nicht nur auf die taktische und strategische Ebene. Es operationisiert BI und greift dadurch zur Datenbeschaffung in konkret ablaufende GPs bzw. deren unterstützende IT-Systeme zurück und bereitet diese Daten zu Steuerungsinformationen auf. CPM ist also einerseits Bestandteil der BI, andererseits erweitert es die BI auch. 2.2.2

Abgrenzung und Zusammenhänge zwischen den benötigten Begriffen

Die unter 2.2.1 definierten Begriffe sind oft eng miteinander verwoben. Die Zusammenhänge, sowie die gegenseitigen Abgrenzungen sollen im Folgenden erarbeitet werden. Grundsätzlich gibt es laut [Oehl06] (S. 2) zwei verschiedene Ansatzrichtungen: „Auf der einen Seite dominieren relativ technische Abhandlungen wie Data Warehouse, Data Mining, Reporting oder OLAP (Online Analytical Processing). Auf der anderen Seite stehen betriebswirtschaftliche Konzepte zur Planung, Steuerung und Kontrolle, allerdings weniger mit konkretem Bezug auf DVSysteme. […] Zur Unterstützung der Fachabteilungen (Controlling, Vertrieb, Logistik, Risiko-Management) wird immer häufiger Business-Intelligence als anwendungsnahe Technologie eingesetzt.“ Zunächst soll eine Abgrenzung zwischen BI und Controlling erfolgen. Hierzu gibt es in der Fachliteratur einige relationsbildende Aussagen, aus denen der gebräuchliche Umgang beider Begriffe zueinander abgeleitet werden kann: Ein Großteil der heutigen IKT (Informations- und Kommunikationstechnologie) gestützten Controllingsysteme basiert auf einer oder mehreren BI-Technologien (vgl. [Horv03]). Das Controlling koordiniert das Zusammenspiel von betriebswirtschaftlichen Instrumenten und BI-Instrumenten (vgl. [Gary08] (S. 50)).

34

Instrumente der BI-Prozesse machen Controlling effizienter und zielgerichteter (vgl. [Gary08] (S. 24)). Die erfolgreiche Umsetzung einer Controllingkonzeption ist sowohl von betriebswirtschaftlichen Instrumenten als auch von den Instrumenten des BI (überwiegend Datenverarbeitungstechnischen Instrumenten) abhängig. Nur durch das Zusammenspiel beider Instrumente, denen des Controllings (betriebswirtschaftlichen) und denen des BI (Datenverarbeitungstechnischen), kann das Controlling effektiv unterstützt werden. Dabei greift das BI Aufgaben des Controllings auf, sorgt aber für eine neue, bessere Lösungsqualität (vgl. [Gary08] (S. 49)). Als gemeinsamen Kern enthalten diese Aussagen, dass BI-Instrumente im Controlling genutzt werden, um die Aufgaben des Controlling zu unterstützen und zu verbessern. Bei Betrachtung der Aufgabenaufzählungen von Controlling und von BI im Rahmen der Begriffsdefinitionen unter 2.2.1, wird eine Übereinstimmung in vier der fünf Aufzählungspunkte deutlich. Das heißt per Definition sind die Aufgaben von BI und Controlling sehr ähnlich. Unterschiede zwischen Controlling und BI bestehen jedoch bei der Datenbeschaffung und bei der Auswertung. Dazu soll folgende Tabelle Aufschluss geben:

Auswertung

Datenbeschaffung

Controlling

Menschliche Kreativität, vergleichsweise wenige formale Methoden.

Primär aus dem Rechnungswesen (vgl. [EsSi09] (S. 87)

BI

Automatisierte Methoden

Protokolle, Datenbanken, Anwender

Tabelle 2: Unterschiede zwischen Controlling und Business-Intelligence

BI kann als Grundlage für Controlling fungieren, welches wiederum das Management unterstützt. Allerdings könnte das BI selbst ohne den Umweg über das Controlling direkt als Managementunterstützung eingesetzt werden.

35

Man muss daher von drei Mengen ausgehen: 1.

Eine Menge von Eigenschaften bzw. Funktionen, die nur vom BI ausgefüllt wird.

2.

Eine Menge von Eigenschaften bzw. Funktionen, die nur vom Controlling ausgefüllt wird.

3.

Eine Menge von Eigenschaften bzw. Funktionen, die sowohl von BI als auch von Controlling ausgefüllt wird.

Die 3. Menge bedeutet, dass es Eigenschaften bzw. Funktionen gibt, bei denen BI und Controlling zueinander in Konkurrenz stehen. Das Controlling bezieht die Daten, wie aus Tabelle 2 zu entnehmen, aus dem Rechnungswesen. Dies kann durch den betriebswirtschaftlichen Charakter des Controllings begründet werden. Das Vorgehen im Controlling hat mit Masse kreativen Charakter. Dabei ist immer ein Controller beteiligt. Das BI kann den Controller bei diesem Vorgehen unterstützen. Dies trifft bei der 2. der drei genannten Mengen zu, aber auch bei der 3. Menge bei den Eigenschaften bzw. Funktionen, bei denen die Umstellung von Controlling auf BI als ausführende Instanz nicht vollzogen wurde. Da, wie oben festgestellt, die Aufgaben des Controllers und des BI sehr ähnlich sind und eine Teilmenge von ihnen zueinander in Konkurrenz steht, lässt das die Sichtweise zu, dass automatisierbare Tätigkeiten des Controllers in die BI übergehen können, und somit ohne (weiteren) menschlichen Produktionsfaktor auskommen können. Die automatisierte Tätigkeit verliert dabei ihre Zugehörigkeit zu Controlling. Allerdings kann man sie innerhalb ihrer neuen Zugehörigkeit zum BI auch als Instrument bezeichnen, welches aus dem Controlling übernommen ist. Mit steigendem Grad der (scheinbaren) Intelligenz von BI (Business-Intelligence) vergrößert sich auch die Menge an Eigenschaften bzw. Funktionen, die das BI anstelle des Controllers automatisiert übernehmen kann. (Hierbei ist zu beachten, dass es zu qualitativen Verbesserungen und Verschlechterungen kommen kann, die im Vorfeld überprüft werden sollten.) Da die Intelligenz von BI nur scheinbar abläuft (es gibt keine echte künstliche Intelligenz), bleibt immer auch eine Teilmenge an Eigenschaften bzw. Funktio-

36

nen, die nach kreativer Kompetenz verlangt und somit Aufgabe des Controllers bleiben kann. Es soll davon ausgegangen werden, dass BI mit Masse auf der IT-Seite anzusiedeln ist, und Controlling primär von Menschen, nämlich dem Controller, durchgeführt wird. Dabei kann nicht völlig ausgeschlossen werden, dass IT zur direkten Unterstützung des kreativen Denkens außerhalb von BI hinzugezogen werden kann, was aber für diese Arbeit formal ausgeschlossen werden soll. Kernaussage dieser Herleitung ist, dass BI das Controlling zum einen unterstützen, zum anderen aber auch Aufgaben abnehmen und damit entlasten kann. Dies stellt gleichzeitig das gewünschte Ergebnis dar, welches die Zusammenhänge zwischen BI und Controlling verdeutlicht. Es soll nun eine weitere Erarbeitung von Zusammenhängen und Abgrenzungen der Begriffe aus 2.2.1 erfolgen, übergehend von Controlling und BI zu Relationen von DWH: Laut [Metr02] stellen DWH und Data-Mart-basierte Controlling-Anwendungen einzelne Bereiche des gesamten BI-Ansatzes dar. Der Begriff „Anwendung“ soll als IT-Anwendung angenommen werden. Ein Controlling-Bereich, der in eine IT-Anwendung übergeht, gehört nach oben beschriebenem Ansatz zur Abgrenzung der Begriffe Controlling und BI, zur 1. Menge, also die Menge an Eigenschaften bzw. Funktionen, die IT-seitig, demnach von BI durchgeführt werden soll. Damit wird diese Aussage, eine Controlling-Anwendung sei ein Bereich der BI, in diesem Modell korrekt. DWH wird ebenfalls als Teil von BI beschrieben. DWH ist ein Teil von BI (vgl. [Gent03]). DWH hat eine Überschneidung mit ERP-Systemen dahingehend, dass sie mit dem Teilbereich Datenhaltung die gleiche Aufgabe erfüllen müssen. Dennoch besteht ein Unterschied in der Art der Datenhaltung, die sich stark voneinander unterscheidet. Dies ergibt sich daraus, dass DWH der Entscheidungsunterstützung dient, das ERP-System der Transaktionsverarbeitung (vgl. [Oehl06] (S. 19)).

37

Einbinden der begrifflichen Relationen von Monitoring zu anderen Begriffen aus 2.2.1: Die für das Controlling benötigten Informationen müssen möglichst zeitnah und empfängerorientiert bereitgestellt werden. Dafür wird Monitoring eingesetzt. Die Informationen dafür können durch GPM, ERP, CRM (CustomerRelationship-Management) oder Analysesysteme wie DWH bereitgestellt werden (vgl. [AhKn06] (S. 147)). Monitoring wird also für Controlling eingesetzt. Außerdem ist Monitoring ein Teil des Controllings (siehe [BVWB07]). Lt. Definition von Monitoring (siehe 2.2.1), hat Monitoring sowohl standardisierte Routinetätigkeiten als auch Projekttätigkeiten mit individuellen Rahmenbedingungen (siehe [Wink10] (S. 1)). Demnach wird Controlling auch standardisiert. Soweit dies von der IT übernommen werden kann, entsteht hier, ebenso wie in der obigen Herleitung zur Abgrenzung zwischen BI und Controlling, aus einem Teilbereich des Controlling ein Teilbereich von BI. Bei der Umsetzung, Monitoring automatisiert von der IT übernehmen zu lassen und damit BIZugehörigkeit zu erlangen, verliert der betreffende Monitoring-Teilbereich seine Zugehörigkeit zum Controlling, kann aber als Teilbereich bezeichnet werden, der aus dem Controlling übernommen wurde. Klärung des Zusammenhangs und der Abgrenzung zwischen den Begriffen Prozess-Controlling und Prozess-Monitoring: Sowohl das Prozess-Monitoring als auch das Prozess-Controlling sollen ein kontinuierliches Prozess(änderungs-)management (d.h. steuernde Eingriffe, schnelle und flexible Anpassung und ständige Verbesserung und Weiterentwicklung der Prozessabläufe) ermöglichen und unterstützen. Das Prozess-Controlling will GPs langfristig weiterentwickeln und verbessern. Im Gegensatz dazu ist das Prozess-Monitoring weitgehend kurzfristig ausgerichtet und will laufende Prozesse zeitnah überwachen, um diese zielgerichtet und schnell zu beeinflussen und auf auftretende Probleme und Engpässe reagieren zu können (vgl. [Beck07] (S.49)). Auch in dieser Prozess-Betrachtung wird deutlich, dass Monitoring und BI ähnliche Aufgaben haben, die vom Monitoring in das BI übergehen können. Das Prozess-Controlling ist Teil des Controllings. Es gibt im Prozess-Controlling 38

ebenso wie im Controlling Bereiche, die dem Controlling oder der BI zugeordnet werden können. Je nach Realisierung kann ein Teilbereich des ProzessControllings diesen Bereich verlassen: Wird er von der IT automatisiert, verlässt es den Bereich des Prozess-Controllings und wird zu BI. (Wobei in diesem Fall der jeweilige Teilbereich als aus dem Controlling übernommener Teilbereich bezeichnet werden kann). Solange dies aber nicht vollzogen wird, ist ProzessControlling Teilbereich von Controlling. Prozess-Controlling verhält sich also diesbezüglich genauso wie Controlling selbst. Die Zuordnung der Kostenrechnung ist bereits in der Definition unter 2.2.1 beschrieben: Sie ist ein Teilbereich des Controllings (vgl. [AhKn06] (S. 180)). Allerdings ist die Kostenrechnung auch Teil anderer Bereiche, z. B. dem Rechnungswesen, dem hier keine weitere Beachtung geschenkt werden soll. Ebenso wie das Controlling selbst, ist die Kostenrechnung so lange Teilbereich des Controllings, wie sie nicht von der BI automatisiert wurde, wie oben in der Herleitung zur Abgrenzung zwischen BI und Controlling beschrieben. (Im Fall einer Automatisierung kann der betroffene Bereich, der damit die Zugehörigkeit zum Controlling verloren hat, als aus dem Controlling übernommener Bereich bezeichnet werden). Damit sind die Abgrenzungen und die Zusammenhänge zwischen den einzelnen Begriffen herausgearbeitet. Die folgende Grafik soll die einzelnen Ergebnisse zusammenführen und gemäß Aufgabenbereichen veranschaulichen:

39

Abbildung 6: Begriffliche Zusammenhänge nach Aufgabenbereichen

Ergänzung zu Abbildung 6: Wie in den Herleitungen oben beschrieben, können die Bereiche aus der Schnittmenge zwischen BI und Controlling auf IT-Ebene automatisiert, und damit zu BI werden. In diesem Fall verlieren sie ihre Zugehörigkeit zu Controlling, können aber als Bereiche bezeichnet werden, die aus dem Controlling übernommen sind.

2.3

Strategische Controlling-Instrumente

Der Eingriff eines Controllers kann erfolgen, wenn kreative Intelligenz erforderlich ist. Dies ist z. B. der Fall bei Prozessstörungen oder wenn Plangrößen nicht erreicht werden, und gleichzeitig das BI-System keine automatisierte Lösung finden kann. Außerdem soll der erforderliche Eingriff eher strategischer Natur sein. Das BI-System bereitet alle erforderlichen Arbeitsschritte vor, die vor diesem Eingriff erfüllt werden müssen, und unterstützt damit den Controller. Dem Controller stehen hier eine Reihe von Instrumenten zur Verfügung, gegebenenfalls auch als Vorschlag an das Management. Diese werden nun aufgezählt 40

und beschrieben. Nach der jeweiligen Beschreibung erfolgt zu jedem Instrument eine Prüfung, ob es in das BI-System dieser Arbeit aufgenommen werden kann, d. h. ob eine Automatisierung sinnvoll ist. Bei nicht automatisierten Aufgaben, die beim Controller verbleiben, wird geprüft, wie der Controller durch das BISystem unterstützt werden soll. 2.3.1

Prozess-Outsourcing

Beim Prozess-Outsourcing wird z. B. eine externe Firma mit einem Prozess, mehreren Prozessen oder einem Teilprozess beauftragt, der vorher intern bearbeitet wurde. Dies kann dann erforderlich sein, wenn unsere Prozesskostenrechnung (siehe 3.5) höhere Kosten für den Prozess ermittelt hat, als das Angebot der externen Firma beträgt. Dieses Ergebnis kann ggf. auch durch externes Benchmarking ermittelt werden. Das BI-System dieser Arbeit gibt dem Controller die Möglichkeit für Benchmark-getriebenes Outsourcing, erzeugt aber keine direkte Verlinkung. Durch Outsourcing entsteht außerdem eine höhere Transparenz. An den externen Prozess angeschlossene, interne Prozesse werden dadurch übersichtlicher, was z. B. das Business Process Reengineering (BPR), d. h. eine Verbesserung der Prozesse und Prozessstrukturen, vereinfacht. Laut [AhKn06] (S.119) kann ein Outsourcing auch darin bestehen, dass Kunden mit in die Leistungserstellung einbezogen werden. Ein Beispiel dafür ist Ikea. Hier tragen Kunden die gewünschten Artikel eigenständig aus dem Lager zusammen, und bauen sie zu Hause auf. Prüfung ob die Entscheidung im Rahmen des BI-Systems automatisiert werden kann, ob Outsourcing bei dem jeweiligen Prozess an Firmen vorgenommen wird: Um festzustellen, ob ein Prozess extern ausgeführt werden kann, hätte das BISystem z. B. folgende zwei Möglichkeiten: 1.

Möglichkeit: Aus der Prozesskostenrechnung (PKR) werden die gesamten Kosten zu einer Prozessgruppe ausgelesen. Der Controller lässt Angebote möglicher Firmen einholen, die für das Outsourcing geeignet sind, und gibt die Angebotsbeträge ein. Diese Arbeiten des Controllers eignen sich nicht

41

für eine Automatisierung. Das BI-System unterstützt den Controller aber mit den Prozesskosten, sowie einem Eingabefeld bei den einzelnen Prozessen, in dem der Angebotspreis eingetragen werden kann. 2.

Möglichkeit: Die Überprüfung über das externe Benchmarking würde erfordern, dass das BI-System die Benchmarking-Datensätze den eigenen Datensätze zuordnen kann. Da dies für eine Automatisierung nicht geeignet ist, bleibt es Aufgabe des Controllers. Das BI-System unterstützt den Controller bei dieser Aufgabe mit der Lieferung der Prozesskosten.

Prüfung, ob die Entscheidung im Rahmen des BI-Systems automatisiert werden kann, ob Outsourcing bei dem jeweiligen Prozess an Kunden vorgenommen wird: Um festzustellen, ob ein Prozess von Kunden ausgeführt werden kann, müsste das BI-System die Akzeptanz bei den Kunden überprüfen, z. B. im Rahmen von Befragungen. Außerdem müsste der Prozess insofern dafür geeignet sein, dass keine Fachkenntnisse und Sorgfältigkeitsanforderungen an den Bearbeiter gerichtet werden, die Kunden nicht einheitlich erfüllen können. Beides ist für eine Automatisierung ungeeignet und wird somit nicht von dem BI-System übernommen. Es bleibt Aufgabe des Controllers. 2.3.2

Prozess-Benchmarking

Zielsetzung des Benchmarking ist ein Vergleich mit besseren oder den besten Unternehmen oder internen Unternehmenseinheiten, um schnellere Effektivitätsoder Effizienzgewinne zu erzielen. Dafür sind klare Vergleichsgrundlagen notwendig. Hinsichtlich des Unternehmensbezuges kann zwischen internen oder externen Benchmarkings unterschieden werden. Ein externer Bezug benötigt die aktive Suche nach einem geeigneten Unternehmen. Prozessvergleichen kann hinsichtlich einer tatsächlichen Verbesserung durch ein Benchmarking aufgrund der direkten Beeinflussbarkeit eine sehr hohe Bedeutung beigemessen werden (vgl. [AhKn06] (S. 123)).

42

Der Benchmarking-Prozess hat folgende Bestandteile:

Planen

Erheben

Analysieren

Verbessern

Benchmarkingziel bestimmen

Prozessdaten erheben

Prozessdaten vergleichen

Verbesserungsaktivitäten auswählen

Vergleichsprozesse auswählen

Plausibilität prüfen

Abweichungen herausfinden

Verantwortlichkeit bestimmen

Messwerte für Prozesse festlegen

Daten auswerten

Ursachen für Abweichungen ermitteln

Aktivitäten planen und ausführen

Verbesserungsaktivitäten vorschlagen

Wirksamkeit prüfen

BenchmarkingPartner oder Vergleichseinheit wählen Projektteam einsetzen

Vergleichstest wiederholen

Methoden für Datenerhebung determinieren Tabelle 3: Bestandteile des Benchmarking-Prozesses [AhKn06] (S. 125)

Wie schon festgestellt (siehe oben) erfordert das Benchmarking die manuelle Zuordnung zwischen zwei oder auch mehreren Vergleichsprozessen. Dies ist ein Vorgang, der sich nicht zur Automatisierung eignet. Sind die zu vergleichenden Prozesse direkt miteinander verbunden, und nicht etwa die Daten der Vergleichsprozesse nur einmalig als Kopie eingespielt, so kann das BI-System eigenständig einen kontinuierlichen Vergleich durchführen. Es ist z. B. ein Prozess denkbar, bei dem eine Bank ihren Kunden einen Umzugsservice bei Wohnortwechsel anbietet, bei dem sie alle Konten, Karten, sonstige Produkte, Unterlagen und Daten an die andere Filiale derselben Bank überträgt. Beim Benchmarking könnte z. B. auffallen, dass die eine Filiale derselben Bank oder auch einer anderen Vergleichsbank, im Vergleich zu den übrigen Filialen besonders gute oder besonders schlechte KPI (Key Performance Indicators) aufweist.

43

Bei besonders guten KPIs kann der Controller nachprüfen, welche Umstände zu diesem Unterschied geführt haben, und ggf. diese als Verbesserung bei den übrigen Filialen umsetzen. Bei besonders schlechten KPIs kann der Controller feststellen, ob es z. B. eine Behinderung oder Störung des Prozesses in dieser Filiale gibt, und diese abstellen. Um dies zu unterstützen, muss das BI-System dem Controller die Möglichkeit anbieten, Prozesse zum Vergleich einander zuzuordnen. Für die Datenbank bedeutet dies eine zusätzliche Relation als Attribut zur Prozess-Relation, welches den jeweiligen ID-Schlüssel beliebig vieler Vergleichsprozesse beinhalten kann. Das BI-System kann nun global angewiesen werden, in bestimmbaren Zeitabständen das Benchmarking für alle vom Controller hinterlegten Prozessvergleiche automatisiert durchzuführen. Dies kann z. B. zu Zeiten geringer Netzbelastung erfolgen, beispielsweise werktäglich um 1.00 Uhr. Verglichen werden sollten nicht nur die KPIs des vergangenen Tages, sondern auch Mittelwerte, z. B. der letzten Woche und des vergangenen Monats. Kommt es zu einer Überschreitung einer vom Controller festgelegten Differenzgrenze, so teilt das BI-System das dem Controller mit, z. B. per eMail, der dann wie beschrieben verfährt. Beim Benchmarking wurde damit festgestellt, dass einige Aufgaben, die bisher als Aufgaben des Controllers betrachtet wurden, nun automatisiert von dem BISystem übernommen werden und den Controller mit den Ergebnissen unterstützt. Die in Tabelle 3 aufgeführten Bestandteile des Benchmarking-Prozesses werden verwendet, um die neue Aufgabenaufteilung zwischen dem BI-System und dem Controller darzustellen. Dabei gilt: • Grün: Jetzt Aufgabe des BI-Systems • Gelb: Immer noch Aufgabe des Controllers • Orange: BI-System und Controller erfüllen diese Aufgabe

44

Planen

Erheben

Analysieren

Verbessern

Benchmarkingziel bestimmen

Prozessdaten erheben

Prozessdaten vergleichen

Verbesserungsaktivitäten auswählen

Vergleichsprozesse auswählen

Plausibilität prüfen

Abweichungen herausfinden

Verantwortlichkeit bestimmen

Messwerte für Prozesse festlegen

Daten auswerten

Ursachen für Abweichungen ermitteln

Aktivitäten planen und ausführen

Verbesserungsaktivitäten vorschlagen

Wirksamkeit prüfen

BenchmarkingPartner oder Vergleichseinheit wählen Projektteam einsetzen

Vergleichstest wiederholen

Methoden für Datenerhebung determinieren Tabelle 4: Neue Aufgabenaufteilung zwischen BI-System und Controller, auf Basis von Tabelle 3

Aus der Tabelle 4 ist ersichtlich, dass der Controller durch das BI-System jetzt nur noch zu Beginn des Benchmarking die Vorgaben für das BI-System durchführen muss, und im Fall einer Abweichung eingreift. Das tägliche Benchmarking übernimmt jetzt das BI-System. 2.3.3

Prozessorientierte SWOT-Analyse

SWOT steht für Strengths/Weaknesses, Opportunities/Threats, d. h. Stärken/ Schwächen, Chancen/Risiken (vgl. [Oehl06] (S. 335)). Zielsetzung einer SWOT-Analyse ist die gezielte Betrachtung von Unternehmen hinsichtlich der Marktposition im Vergleich zu den Kundenanforderungen und der verfügbaren Ressourcen. Prozesspotenzial soll dadurch ermittelt werden. Werkzeuge können unter anderem sein: Befragungen, Checklisten, Zufriedenheitsanalysen und Studien. Aus Sicht der Prozessorientierung ist die konsequente Betrachtung der Prozesse im Rahmen der SWOT-Analyse von höchster Prio-

45

rität für die strategische Steuerung und deren Erfolg (vgl. [AhKn06] (S. 130, 131)). Hinweis: Bei der SWOT-Analyse kommt es zu Überschneidungen mit der Potenzialanalyse. Genauere Ausführungen hierzu sowie die Abgrenzung zwischen den beiden Instrumenten werden dort beschrieben (siehe 2.3.6). Die Gegenüberstellung der Stärken und Schwächen, sowie den Chancen und Risiken erfolgt für verschiedene Strategien, zwischen denen entschieden werden soll. Die Gegenüberstellung erfolgt dabei ähnlich wie bei einer Pro/Contra Aufstellung. Zum Beispiel bei der Fragestellung, ob ein Prozessteil automatisiert ablaufen soll oder manuell:

Stärken

Automatisiert

Manuell

Niedrige Prozesskosten Geringe Fehlerquote

Mitarbeiter reagieren flexibel

Schwächen Hohe Anfangskosten

Hohe Personalkosten

Chancen

Schneller als die Konkurrenz

Persönliche Betreuung: Kundenbindung

Risiken

Kunden lehnen System ab

Kunde kauft billiger bei Wettbewerbern

Tabelle 5: Beispiel für eine prozessorientierte SWOT-Analyse, als Argumentation

Alternativ kann die SWOT-Analyse aber auch in Zahlen anstelle der Argumentation aus dem Beispiel (siehe Tabelle 5) durchgeführt werden. Auch hier muss der Wettbewerb mit berücksichtigt werden.

46

Legende zur Tabelle 6: A: Generelle Anforderung, B: Eigenes Unternehmen, C: Wettbewerb Priorität für Anforderung (A): 1 (sehr hoch) – 5 (sehr niedrig) Erfüllung (B, C): 1 (sehr gut) – 5 (sehr schlecht) Anforderungen

Fehlerrate

Durchlaufzeit

Kosten

Prozesse

A

B

C

A

B

C

A

B

C

Vermarktung

3

2

4

2

2

1

2

3

1

Produktentwicklung

4

3

3

3

3

3

1

2

3

Auftragsabwicklung

2

3

3

1

2

1

2

2

3

Kundenservice

2

3

2

2

2

2

4

2

3

Tabelle 6: Beispiel für eine prozessorientierte SWOT-Analyse, mit Vergleichszahlen (vgl. [AhKn06] (S. 133))

Aus Tabelle 6 können nun Stärken und Schwächen der einzelnen Prozesse durch die Spalten B im Verhältnis zu Spalten A und C, sowie Chancen und Risiken durch die Spalten C im Verhältnis zur Spalte B erkannt werden. Prüfung, ob die prozessorientierte SWOT-Analyse durch das BI-System automatisiert werden kann: Die SWOT-Aufstellung mit Argumentationen (siehe Tabelle 5) ist ein kreativer Vorgang und eignet sich nicht zur Automatisierung. Eine indirekte Unterstützung durch das BI-System kann aber über die Prozesskostenrechnung geschehen. Die SWOT-Aufstellung mit Vergleichszahlen kann mit Hilfe des BI-Systems umgesetzt werden. Das oben gezeigte Beispiel (siehe Tabelle 6) erfordert folgende Vorgänge: • Erfassung der Fehlerraten zu den vier genannten Beispielprozessen, durch die Prozessbeteiligten bzw. das BI-System. • Erfassen der Durchlaufzeiten aus den Prozessmessungen, d. h. aus dem BI-System.

47

• Die Kosten liegen in der Prozesskostenrechnung bereits vor. Sie werden für die SWOT-Aufstellung abgefragt. • Festlegen der generellen Anforderungen zu den vier Beispielprozessen, z. B. durch einen Controller. • Einschätzung der Fehlerrate, Durchlaufzeiten und Kosten anderer am Markt befindlicher Unternehmen, z. B. durch Marktanalyse, Kundenbefragung, Zusammenarbeit oder Datenhändler. Für die SWOT-Aufstellung mit Vergleichszahlen werden dem BI-System zu den Prozessen eine zusätzliche SWOT-Ansicht hinzugefügt, die der Controller bei Bedarf öffnen kann. Sie enthält beim Aufruf der SWOT-Ansicht, z. B. zum Prozess Kundenservice, die zugehörigen Zahlen zur Fehlerrate, Durchlaufzeit und Kosten (siehe Tabelle 6). Eine gesammelte Auflistung der SWOT-Ansichten mehrerer Prozesse ist durch das BI-System ebenfalls möglich. Die Zahlen liegen jetzt noch nicht wie in Tabelle 6 in Bewertungsnoten von 1 bis 5 vor, sondern in konkreten Messwerten. Dies ist bereits für die SWOTAnalyse ausreichend, es fehlt aber noch die Übersichtlichkeit zwischen den Prozessen zueinander, wozu die Bewertungsnoten benötigt werden. Um die Bewertungsnoten zu erhalten muss der Controller nun in einer zweiten Maske zu jeder Prozess-Anforderungs-Kombination eine Abstufung definieren, auf deren Basis die BI dann in einer dritten Maske die SWAT-Aufstellung nach Bewertungsnoten erzeugen kann. Die Interpretation der so entstandenen SWOT-Analysen ist eine kreative Aufgabe und bleibt in der Hand des Controllers. 2.3.4

Szenarioplanung und Prozessvarianten

Der Controller kann hierbei Alternativen zu bestehenden Prozessen, oder auch völlig neue Prozesse erstellen. Diese sind aber nicht sofort aktiv, sondern bestehen nur zu Testzwecken für den Controller. Er kann dabei mehrere Varianten direkt miteinander vergleichen, ohne reale Ressourcen des Unternehmens dafür abziehen zu müssen.

48

„Die Szenario-Betrachtung von Geschäftsprozessen ist insbesondere für die Analyse strategischer Lücken für das Prozess-Controlling von Interesse. Durch die Projektion der erwarteten Prozessveränderungen können im Zusammenspiel mit den vorhandenen Potenzialen wirksam Kompetenz- oder Umsetzunglücken [!] aufgezeigt werden oder im Gegenteil dazu Hinweise für die Intensivierung einer strategischen Zielsetzung erfolgen.“ (Siehe [AhKn06] (S. 136)). Das BI-System soll dafür einen eigenen Modus haben. In diesem Modus stehen alle Mitarbeiter und Services sowie der volle Umfang des BI-Systems zur Verfügung. Dabei erscheint ein ausgewählter Mitarbeiter zwar im Prozess, er wird aber nicht im Ablauf hinterlegt, sondern ein spezieller Controlling-Account. Wenn sich der Controller über diesen Account einloggt, erhält er sämtliche Subjektaufgaben für den Testprozess, die gerade anfallen, anstelle der jeweiligen Mitarbeiter. Dieses Vorgehen erlaubt es auch, einen getesteten Prozess zu aktivieren. Löst der Controller die Aktivierung aus, so ersetzt das BI-System den Controlling-Account durch die Accounts der Prozessmitarbeiter. Dadurch muss der Controller einen Testprozess nicht erneut eingeben, sondern kann direkt den Testprozess aktivieren. Bei diesem Instrument ist also weiterhin die Beteiligung des Controllers erforderlich. Das BI-System wird zu seinem primären Werkzeug, das ihn unterstützt und ihn wie beschrieben durch das Übernehmen aller automatisierbaren Aufgaben stark entlastet. 2.3.5

Prozessorientierte Gap-Analyse

„Die Gap-Analyse zählt zu den klassischen Instumenten der strategischen Unternehmensanalyse. Für den strategischen Planungshorizont (z. B. zehn Jahre) wird der Zielwert einer Beobachtungsgröße (z. B. Gewinn) mit dem Prognosewert für dieselbe Beobachtungsgröße verglichen. Bei der Ermittlung des Prognosewerts wird unterstellt, dass keine Änderungen an der derzeitigen Strategie vorgenommen werden. Als Differenz aus Ziel- und Prognosewert ergibt sich die sog. strategische Lücke, die durch geeignete strategische Maßnahmen geschlossen werden muss.“ (Siehe [Joos06] (S. 15)). Für die Gap-Analyse von Prozessen können prozessrelevante Zahlen verwendet werden, wie zum Beispiel die Häufigkeit der monatlichen Prozessdurchläufe. So

49

kann z. B. für einen Prozess, der Kundenbeschwerden abwickelt, als Ziel festgelegt werden, dass sich die Häufigkeit der monatlichen Prozessdurchläufe in den nächsten 12 Monaten um 30 Prozent reduziert. Das BI-System kann den Controller dabei unterstützen, indem es Felder für ZielTermine und Ziel-Werte vorgibt. Wird der Ziel-Termin erreicht, so wird der Controller vom BI-System darüber informiert, z. B. per eMail. Er kann dann den Prozess aufrufen und die hinterlegten Ziel-Werte mit den aktuell angezeigten Prozesswerten aus den Prozessmessungen oder der Prozesskostenrechnung vergleichen. Das BI-System übernimmt hier also die Datenhaltung für die Ziel-Werte und die Überwachung der Ziel-Termine für den Controller. 2.3.6

Prozessorientierte Potenzialanalyse

„Die Potenzialanalyse untersucht die im Unternehmen eingesetzten Ressourcen und vergleicht sie mit der Ressourcenausstattung der stärksten Konkurrenten. […] Ziel der Potenzialanalyse ist es festzustellen, welche Ressourcen die spezifischen Stärken und Schwächen des Unternehmens ausmachen. Da eine Ressourcenanalyse schon aus Aufwandsgründen nicht alle Ressourcen umfassen kann, müssen in einem ersten Schritt sog. kritische Erfolgsfaktoren ermittelt werden, von denen der Erfolg des Unternehmens mutmaßlich abhängt. Als zweites muss die Ressourcenausstattung ermittelt werden. Drittens müssen „Noten“ oder „Punkte“ für die Ressourcenausstattung vergeben werden.“ (Siehe [Joos06] (S. 16)). Die Potenzialanalyse ähnelt damit der SWOT-Analyse (siehe 2.3.3), allerdings beschränkt sie sich auf die Stärken/Schwächen. Außerdem werden die generellen Anforderungen und der Wettbewerb nicht direkt beziffert. Die Potenzialanalyse ist also weniger ausführlich als die SWOT-Analyse. Dennoch kann es dazu kommen, dass sie für einen Prozess geeigneter ist, z. B. wenn der Aufwand der Datenbeschaffung über Wettbewerb oder die zusätzliche Bewertung der generellen Anforderungen nicht im Verhältnis zum Nutzen steht. Das Ergebnis der Potenzialanalyse bietet dem Controller bereits ohne die umfassendere SWOTAnalyse eine gute Übersicht zu den bewerteten Prozessen, aus der die Stärken und Schwächen der Prozesse abgelesen werden können.

50

Wegen der Überschneidungen zwischen der Potenzialanalyse und der SWOTAnalyse soll nur eines dieser beiden Instrumente in das BI-System aufgenommen werden. Bei einer prozessorientierten Potenzialanalyse ist folgendes Vorgehen möglich: Es werden Anforderungen zu einem Prozess definiert (siehe Tabelle 6) wie z. B. Fehlerrate, Durchlaufzeit und Kosten. Diese erhalten dann vom Controller eine subjektive Bewertung. Daraus wird für den Prozess die Gesamtnote errechnet. Diese kann den anderen Prozessen gegenübergestellt werden, wodurch der Controller einen Überblick über seine Bewertungen erhält, und somit darüber, wo Handlungsbedarf besteht. Die prozessorientierte Potenzialanalyse kann ebenso wie die SWOT-Analyse mit Hilfe des BI-Systems umgesetzt werden. Die drei genannten BeispielAnforderungen (Fehlerrate, Durchlaufzeit und Kosten) erfordern dafür folgende Vorgänge: • Erfassung der Fehlerraten zu den vier genannten Beispielprozessen, durch die Prozessbeteiligten bzw. das BI-System. • Erfassen der Durchlaufzeiten aus den Prozessmessungen, d. h. aus dem BI-System. • Die Kosten liegen in der Prozesskostenrechnung bereits vor. Sie werden für die SWOT-Aufstellung abgefragt. • Festlegen der generellen Anforderungen zu den vier Beispielprozessen, z. B. durch einen Controller. • Einschätzung der Fehlerrate, Durchlaufzeiten und Kosten anderer am Markt befindlicher Unternehmen, z. B. durch Marktanalyse, Kundenbefragung, Zusammenarbeit oder Datenhändler. Dem BI-System werden zu den Prozessen eine zusätzliche Ansicht für die Potenzialanalyse hinzugefügt, die der Controller bei Bedarf öffnen kann. Sie enthält beim Aufruf die zum jeweiligen Prozess zugehörigen Zahlen zur Fehlerrate, Durchlaufzeit und Kosten. Eine gesammelte Auflistung der Potenzialanalyse zu mehreren Prozessen ist durch das BI-System ebenfalls möglich.

51

Die Zahlen liegen jetzt noch nicht in „Noten“ oder „Punkten“ vor, sondern in konkreten Messwerten. Dies ist bereits für die Potenzialanalyse ausreichend, bietet aber noch nicht die Übersichtlichkeit, die Prozesse zueinander zu vergleichen. Das in dieser Arbeit konzipierte BI-System soll hier mit Bewertungsnoten arbeiten. Um die Bewertungsnoten zu erhalten muss der Controller nun in einer zweiten Maske zu jedem Messwert zu den einzelnen Anforderungen eine Abstufung definieren, auf deren Basis die BI dann in einer dritten Maske die Potenzialanalyse nach Bewertungsnoten erzeugen kann. Die Interpretation der so entstandenen Potenzialanalyse ist eine kreative Aufgabe und bleibt in der Hand des Controllers. 2.3.7

Wertschöpfungskettenanalyse

„Die Wertschöpfungskettenanalyse zerlegt ein Unternehmen in strategisch relevante Aktivitäten. […] Die Wertschöpfungskette stellt das Unternehmen, ausgehend vom Gesamtwert eines Erzeugnisses (Marktpreis), als eine Kette wertsteigernder Aktivitäten dar. Die Differenz zwischen den Kosten der Wertschöpfungsaktivitäten und dem am Marktpreis gemessenen Kundennutzen stellt die vom Unternehmen erzielte Gewinnspanne dar. Ziel der Wertschöpfungskettenanalyse ist es, die einzelnen Unternehmensaktivitäten im Hinblick auf ihren Beitrag zur Befriedigung der Kundenbedürfnisse hin zu untersuchen. Zu diesem Zweck werden ‚primäre‘ und ‚unterstützende‘ Aktivitäten unterschieden. Primäre Aktivitäten befassen sich mit der physischen Herstellung des Produktes und dessen Vertrieb. Dazu gehören die Eingangslogistik, die Produktionsaktivitäten, die Ausgangslogistik, Marketing und Vertrieb sowie der Kundendienst. Unterstützende Aktivitäten umfassen alle Aktivitäten, die Versorgungs- und Steuerungsleistungen für die primären Aktivitäten erbringen.“ (Siehe [Joos06] (S. 18)). Die Wertschöpfungskettenanalyse stellt also von Natur aus einen prozessorientierten Ansatz dar. Zahlen zur Ermittlung von Kennzahlen der Wertschöpfungskettenanalyse liegen in einer modernen Prozesskostenrechnung bereits vor.

52

Unterstützende Aktivitäten

Primäre Aktivitäten

Unterstützende Aktivitäten

Kosten

Kosten

Kosten

Prozess 5 Kosten

Prozess 2

Prozess 4

Prozess 1

Prozess 3

Kosten Schnittstellen, Abhängigkeiten

ErzeugnisMarktpreis Summe Kosten

Abbildung 7: Wertschöpfungskette zu einem Erzeugnis aus Prozesssicht

In Abbildung 7 wird eine Wertschöpfungskette zu einem Erzeugnis aus Prozesssicht veranschaulicht. Die Kosten zu jedem einzelnen Prozess werden ermittelt. Die Summe aller Prozesskosten werden vom erzielten Marktpreis abgezogen. Dadurch entsteht der kalkulatorische Gewinn auf Prozesskostenbasis. Diese Kennzahlen stehen ebenfalls bereits in der Prozesskostenrechnung zur Verfügung. Durch diese Betrachtung der gesamten Wertschöpfungskette mit allen beteiligten Prozessen wird ersichtlich, welchen Beitrag die einzelnen Prozesse am Erzeugnis haben. Die unterstützenden Aktivitäten aus Abbildung 7 sind die in dieser Arbeit bereits definierten (siehe 2.1.1) Unterstützungsprozesse, aber auch die Steuerungsprozesse, welche – wenn auch indirekt – ebenfalls zur Wertschöpfung beitragen. Die primären Aktivitäten wurden in diesem Zusammenhang als Kerngeschäftsprozesse definiert.

53

Damit das BI-System die Wertschöpfungskette als solche verarbeiten kann, ist es zunächst notwendig, die beteiligten Prozesse zuzuordnen und zu kennzeichnen. Dazu wird jeder Prozess als Unterstützungsprozess, Steuerungsprozess oder Kerngeschäftsprozess deklariert. Jede dieser Deklarationen erfordert nun zusätzliche Informationen bezüglich der Schnittstellen. So benötigen die einzelnen Kerngeschäftsprozesse den Identifizierungsschlüssel des jeweils folgenden Kerngeschäftsprozess innerhalb dieser Wertschöpfungskette. Die Unterstützungsprozesse und Steuerungsprozesse benötigen den Identifizierungsschlüssel des jeweils folgenden Prozesses und am Ende des Kerngeschäftsprozess, den sie begünstigen. Dabei kann es vorkommen, dass ein Unterstützungs- oder Steuerungsprozess mehreren Kerngeschäftsprozessen oder gar verschiedenen Wertschöpfungsketten zugewiesen werden müssen. Der Controller vergibt hierzu einen Verteilungsschlüssel, der zeigt, zu welchem Anteil der jeweilige Prozess dem verknüpften Kerngeschäftsprozess zugeordnet ist. Das Feld für den Verteilungsschlüssel folgt also unmittelbar auf das Feld für den Identifizierungsschlüssel des Folgeprozesses. Lediglich der letzte Kerngeschäftsprozess hat keinen Folgeprozess. Dadurch liegen dem BI-System nun alle Schnittstelleninformationen vor, um die Zusammenhänge der einzelnen Prozesse innerhalb der Wertschöpfungskette, wie in Abbildung 7 beispielhaft dargestellt, verarbeiten zu können. Ab diesem Moment ist es auch möglich, die einzelnen Prozesskosten dieser jetzt verknüpften Wertschöpfungskette zu den Gesamtkosten dieser Wertschöpfung, d. h. dieses Erzeugnisses, zu summieren. Dies kann Aufgabe der Prozesskostenrechnung sein, was im Rahmen des BI-Systems auch umgesetzt wird, und liefert gleichzeitig die Kosten für ein Produkt gemäß Prozesskostenrechnung. Nach der Strukturierung des betrieblichen Wertschöpfungsprozesses erfolgt in einem nächsten Schritt die Detailanalyse der einzelnen Aktivitätsbereiche. Dabei wird nach gegenseitigen Abhängigkeiten sowie Rationalisierungs- bzw. Differenzierungspotenzialen innerhalb und außerhalb des Unternehmens gesucht. Durch Neuorganisation bzw. Verlagerung von Aktivitäten innerhalb einer kombinierten Wertschöpfungskette lassen sich Ansatzpunkte für die Entwicklung neuer Strategien herausarbeiten (siehe [Webe04] (S.525f)). Dieser Bereich ist der Teil der Wertschöpfungskettenanalyse, der über die Prozesskostenrechnung hinausgeht, da die vorhergehenden Methoden und Kennzah54

len bereits in der Prozesskostenrechnung stattfinden. Diese eigentliche Wertschöpfungskettenanalyse auf Basis dieser Prozesskostenrechnung bleibt Aufgabe des Controllers. Die vorbereitenden Methoden und Kennzahlen wurden wie beschrieben in das BI-System aufgenommen. 2.3.8

Prozessbündelungsanalyse

Die Recherche hat ergeben, dass dieses Vorgehen und der Begriff in der Literatur noch nicht geprägt wurden. Die Idee, die hier zugrunde liegt ist, dass der Controller erkennt, an welchen Stellen ähnliche Prozessschritte erfüllt werden. Diese Prozessschritte können sowohl eine Menge wiederkehrender Durchläufe des gleichen Prozesses sein, als auch Prozessschritte ganz unterschiedlicher Prozesse, die aber an dieser Stelle Ähnlichkeiten aufweisen. Findet der Controller einen solchen Prozess, so kann er eine Bündelung vornehmen, indem er dem Mitarbeiter die gleichbleibenden Arbeitsschritte abnimmt. Dies kann wie folgt ermöglicht werden: Als Beispielprozess soll der Umzugsservice einer Bank dienen, bei dem der Kunde eine neue Adresse hat, und die Bank alle Konten, Karten, sonstige Produkte, Unterlagen und Daten an die andere Filiale derselben Bank überträgt. Der Kundenberater der Bank gibt den Adresszettel des Kunden über die interne Post an die Abteilung Marktfolge weiter (hier wäre alternativ auch automatisierende Unterstützung durch das BI-System möglich, indem es die Adressänderung dem Kunden direkt zur Verfügung stellt). Es sei dass der Mitarbeiter der Marktfolge täglich eine Vielzahl solcher Adresszettel erhält. Er startet dann alle Prozesse in der S-BPM-Suite, die im späteren Verlauf auch wieder in den einzelnen Filialen bearbeitet werden. Der Mitarbeiter der Marktfolge müsste nun immer wieder einen neuen Prozess starten. Dies kann der Controller durch Prozessbündelung verändern, indem er für diesen speziellen Prozess eine gesonderte Maske erstellen lässt. Mit ihrer Hilfe kann der Mitarbeiter mit einem Klick und der Eingabe einer Zahl, welche die Anzahl der benötigten Prozesse darstellt, alle Prozesse auf einmal starten. Dadurch erhält er alle benötigten Felder, nämlich die für alle neuen Adressen und den Kundenschlüssel mit dem der Kunde identifiziert werden kann (z. B. in Form einer Kontonummer), auf einmal. Ein Prozessschritt der einmal auf diese Weise gebündelt wurde, spart bei jedem Durchlauf Arbeitszeit und damit Kosten ein. 55

Die Suche nach Prozessschritten, die für die Prozessbündelungsanalyse geeignet sind, ist zum einen deswegen Aufgabe des Controllers, weil zum Zeitpunkt der Porzesserstellung nicht unbedingt überblickt werden kann, welche Prozesse sich bei einem Mitarbeiter mit ähnlichen Aufgaben kreuzen. Zum anderen da die Einarbeitung in die Prozessbündelungsanalyse dann nur beim Controller erfolgen muss. Findet ein Mitarbeiter bei der Prozesserstellung bereits geeignete Prozessschritte, so kann diese Information an den Controller weitergegeben werden. Um geeignete Prozessschritte zu finden benötigt der Controller die Möglichkeit einer Auflistung der in der S-BPM-Suite eingebunden Subjektverhalten eines einzelnen Subjektes. Diese überprüft der Controller auf der Suche nach ähnlichen Prozessschritten und bündelt sie. Die Erstellung der Masken innerhalb der S-BPM-Suite (oder auch innerhalb eines betroffenen ERP-Systems) für die Prozessbündelung wie beschrieben, kann vom Controller individuell bei der Softwareentwicklung beauftragt werden. Die Maske mit dem gebündelten Prozessschritt ist Teil der S-BPM-Suite und wird nicht Teil des BI-Systems, da es den Prozess und nicht den Controller unterstützt. Das BI-System hilft dem Controller bei der Suche nach geeigneten Prozessen. Es ermöglicht es dem Controller, die Prozessmitarbeiter wie beschrieben zu entlasten. 2.3.9

Spezielle Controlling-Instrumente

Ergänzend soll noch erwähnt werden, dass es eine Vielzahl von speziellen Instrumente gibt, die individuell auf die jeweiligen Bedürfnisse von speziellen Prozessen angepasst sind. Sie sollen nicht Bestandteil des BI-Systems dieser Arbeit sein. Drei der häufig in der Literatur anzutreffenden speziellen Instrumente sollen jedoch beispielhaft genannt werden: • SCM, d. h. Supply Chain Management. Der Supply Chain Prozess beginnt mit den erteilten Kundenaufträgen und endet mit den installierten und von Kunden abgenommenen Produkten, bzw. mit den von den Kunden bezahlten Rechnungen (vgl. [ScSe02] (S. 129)).

56

• CRM, d. h. Customer Relationship Management. Customer Relationship Prozesse sind Prozesse aus den Bereichen Marketing, Beratung, Verkauf und Service (vgl. [Schu00]). • PLM, d. h. Produkt Lifecycle Management. Produkt Lifecycle ist ein Konzept mit dem der Lebenszyklus eines Produktes in die Phasen Einführung, Wachstum, Reife und Sättigung zur theoretischen Begründung der Relevanz des Marktwachstums gegliedert wird (vgl. [EsSi09] (S. 186)).

2.4

Prozesskostenrechnung (PKR)

(Definition siehe 2.2.1.) 2.4.1

Einordnung der PKR

„Die Prozesskostenrechnung ist als Vollkostenrechnung konzipiert.“ (Siehe [WöDö10] (S. 1011)). Die Prozesskostenrechnung kann als eigenständiges Kostenrechnungssystem oder aber auch ergänzend zur traditionellen Vollkostenrechnung gesehen werden (siehe [Olfe10] (S. 339)). Die eigenständige Prozesskostenrechnung wird in dieser Arbeit als prozessorientierte Kostenrechnung (POKR) bezeichnet und definiert (siehe 2.2.1). Welche der beiden Varianten ein Unternehmen wählt, sollte damit übereinstimmen, ob das Unternehmen funktionsorientiert, prozessorientiert oder gemischt strukturiert ist (siehe 2.1.4). Da die PKR unabhängig von der Einsatzweise des Unternehmens eine Vollkostenrechnung ist, wird diese Arbeit sie auch so vorstellen. „Ebenso wie die klassische Kostenrechnung durchläuft auch die Prozesskostenrechnung die Teilgebiete der Kostenarten-, Kostenstellen- und Kostenträgerrechnung. In der Kostenartenrechnung bestehen keine wesentlichen Unterschiede zwischen der Prozesskostenrechnung und der herkömmlichen Vollkostenrechnung. Von der Kostenstellenrechnung an geht die Prozesskostenrechnung jedoch einen anderen Weg.“ (Siehe [WöDö10] (S. 1011)).

57

2.4.2

Besondere Aufgaben der PKR

Die PKR soll dem allgemein zu beobachtenden Anstieg der Gemeinkosten in den Unternehmen und der zunehmenden Prozessorientierung in den Unternehmen Rechnung tragen (vgl. [WöDö10] (S. 1010)). Durch sie soll eine möglichst frühe Information im Hinblick auf Chancen und Risiken ermöglicht werden, so dass im Rahmen des Kostenmanagements frühzeitig geeignete Maßnahmen ergriffen werden können. Auch dient sie der Steuerung des Ressourcenverbrauches und der Kapazitätsauslastung unter den Gesichtspunkten von strategischer Kalkulation, Kostentransparenz und Steuerung der Gemeinkosten. Mit der Prozesskostenrechnung steht ein Kostenrechnungskonzept zur Verfügung, das den traditionellen Kostenrechnungssystemen im Hinblick auf die Kostenverrechnung überlegen ist (siehe [Olfe10] (S. 339)). 2.4.3

PKR-Verfahren im BI-System

Um die Durchführung der PKR im BI-System umsetzen zu können, soll die Vorgehensweise aufgeführt werden. Dieses Verfahren soll folgenden vier Schritten erfolgen: • Schritt 1: Grundstruktur der Prozesse • Schritt 2: Prozessmessungen • Schritt 3: Ermittlung der Prozesskosten • Schritt 4: Umlage der Prozesskosten auf die Kostenträger Dabei wird nach jedem Schritt die Eignung für das BI-System geprüft.

58

Schritt 1: Grundstruktur der Prozesse

Abbildung 8: Grundstruktur der Prozesskostenrechnung (siehe [WöDö10] (S. 1011))

„Basierend auf einer Tätigkeitsanalyse in den einzelnen Kostenstellen werden die anfallenden Einzelaktivitäten bestimmt. Diese werden zu sinnvollen Tätigkeits-/Aktivitätsbündeln, zu Teilprozessen (TP), zusammengefasst. Die Häufigkeit der Prozessdurchführung (als Basis für die zunehmende Prozesskalkulation) wird über sog. Maßgrößen erfasst. Der Kostenträgerbezug ist auf dieser Ebene noch sehr vage. Aus diesem Grunde erfolgt eine weitere Zusammenfassung der Teilprozesse zu (kostenstellenübergreifenden) Hauptprozessen. Über diese soll die Umlage der Gemeinkosten auf die Kostenträger erfolgen. Das Bindeglied zum Kostenträger stellen die sog. Kostentreiber (cost driver) dar. Es ist zu ermitteln, wie viele cost driver-Einheiten pro Kostenträger benötigt werden. Gleichzeitig stellen die cost driver auch den Maßstab für die Messung der Prozesshäufigkeit der Hauptprozesse dar. Betrachtet man hingegen die Prozesse als Kostenträger, so dient die Bildung von Hauptprozessen der Bewertung von zusammenhängenden, meistens abteilungsübergreifenden Arbeitsabläufen.“ (Siehe [WöDö10] (S. 1011f)). Die in Abbildung 8 aufgeführten Tätigkeiten werden vom GPM innerhalb der SBPM-Suite erstellt und für diese Arbeit als gegeben betrachtet. Die entsprechenden Subjektverhalten liegen dort als Subjektverhaltensdiagramm (SVD) vor.

59

Ebenso liegen die Teilprozesse als Subjektinteraktionsdiagramm (SID) in der SBPM-Suite vor. Bei der Verdichtung zu den Hauptprozessen muss das BI-System eine geeignete Struktur kennen. Diese wird im Zusammenhang mit der Wertschöpfungskettenanalyse (siehe 2.3.7) beschrieben. Dort ist nachzulesen, dass jeder Prozess einem Prozesstyp, nämlich als Unterstützungsprozess, Steuerungsprozess oder Kerngeschäftsprozess deklarierbar sein muss. Diese Unterscheidung ist zwar für den Schritt 1 des Verfahrens zur PKR, nämlich die Grundstruktur, noch nicht erforderlich, sie wird aber noch in späteren Schritten der PKR (verlinken, anpassen) gebraucht. Sie wird trotzdem schon an dieser Stelle genannt, weil sie in der Beschreibung der Wertschöpfungskettenanalyse die Beschreibungen der Schnittstellen nach sich zieht, welche für die Hauptprozesse aus Abbildung 8 ebenfalls benötigt werden. Diese Beschreibung besagt, dass die einzelnen Kerngeschäftsprozesse den Identifizierungsschlüssel des jeweils folgenden Kerngeschäftsprozess innerhalb der Wertschöpfungskette, bzw. in diesem Fall der Hauptprozesse, benötigen. Auch die Unterstützungsprozesse und Steuerungsprozesse benötigen den Identifizierungsschlüssel des jeweils folgenden Prozesses. Diese Schnittstellen ermöglicht es, eine Prozessstruktur zu hinterlegen, die sowohl den Anforderungen der Wertschöpfungskettenanalyse als auch der PKR gerecht wird. Für die PKR heißt das, dass dadurch dem BI-System die Verdichtung zu den Hauptprozessen gemäß Abbildung 8 ermöglicht wird. Dem Controller bleibt die Aufgabe überlassen, die Verknüpfungen der Prozesse zueinander sowie den Prozesstyp innerhalb der Schnittstellen zu hinterlegen.

60

Schritt 2: Prozessmessungen Hauptprozess

Material beschaffen

Kostentreiber

3600 Materialbeschaffungen

Teilprozesse

Kostenstelle

Prozessparameter

Maßgröße Teilprozess

Angebote einholen

Einkauf

1/3

1.200 Angebote

Bestellungen aufgeben

Einkauf

1

3.600 Bestellungen

Reklamationen bearbeiten

Einkauf

1/36

100 Reklamationen

Material annehmen

Warenannahme

1

3.600 Annahmen

Material prüfen

Prüfstelle

0,5

1.800 Prüfungen

Material einlagern

Lager

1

3.600 Einlagerungen

Tabelle 7: Prozessmengen (siehe [WöDö10] (S. 1012))

In Tabelle 7 „sind der Hauptprozess ‚Material beschaffen‘ und die dazu notwendigen Teilprozesse dargestellt. Der Prozessparameter gibt die Anzahl der notwendigen Teilprozesse je Hauptprozess an. Ein Prozessparameter kleiner (größer) als eins bedeutet, dass ein Teilprozess weniger (häufiger) als einmal durchgeführt werden muss, um den Hauptprozess abzuschließen. So muss z. B. nicht bei jedem Wareneingang eine Materialprüfung durchgeführt werden, sondern es reicht eine stichprobenweise Untersuchung. Unter Nutzung des Prozessparameters lässt sich rechnerisch ermitteln, wieviele Teilprozesseinheiten anfallen. Dieser Wert wird in die die Teilprozesse bereitstellenden Kostenstellen, im Beispielfall der [Tabelle 7] die Kostenstelle ‚Einkauf‘, übernommen. Nach Zuweisung der Planprozessmengen über die Maßgrößeneinheiten wird festgelegt, welche Ressourcenbeanspruchung durch die jeweiligen Teilprozessmengen in der Kostenstelle auftritt. Entsprechend werden die Gesamtkosten der Kostenstelle auf die Teilprozesse verteilt, so dass die Kosten pro Teilprozessdurchführung ermittelt werden können. Denkbar wäre im vorliegenden Fall z. B. eine Kostenzuweisung über die zeitliche Beanspruchung der Mitarbeiter der Kostenstelle 61

‚Einkauf‘. Die Maßgrößen sind damit als Maßstab der Kostenverursachung zu verstehen. Sie sind allerdings deutlich von den Bezugsgrößen der traditionellen Kostenrechnung abzugrenzen: Anders als in der traditionellen Kostenrechnung wird keine Proportionalität zwischen Kostenanfall und Maßgröße gefordert.“ (Siehe [WöDö10] (S. 1012)). Kostentreiber: „Als Haupteinflussgrößen der Kostenentstehung und Kostenentwicklung stellen sie die bestimmten Faktoren für die einem Kostenträger zurechenbare Prozessmenge dar, anhand derer die verursachungsgerechte Zurechnung von Gemeinkosten auf Kostenträger möglich wird.“ (Siehe [Oehl06] (S. 349)). D. h. das BI-System ermittelt den Wert des Kostentreibers durch Messung der Durchlaufzahlen des zugehörigen Prozesses. Im Beispiel der Tabelle 7 würde das BI-System zählen, dass 3.600 mal Material beschafft wurde. Zusammengehörige Prozesse kann das BI-System durch die oben beschriebenen Schnittstellen durch die hinterlegten Identifizierungsschlüssel erkennen. Diese können Wertschöpfungsketten oder auch Hauptprozesse darstellen. Für diese zusammengehörigen Prozesse soll das BI-System ebenso die Kostentreiber protokollieren, wie für die einzelnen Prozesse, bzw. zu den Teilprozessen. Zur Ermittlung der Kostenstellen prüft das BI-System, von welchem hinterlegten Subjekt oder auch Subjekten innerhalb des in der S-BPM-Suite vorliegenden Prozesses der Teilprozess bearbeitet wird. Jedes Subjekt ist einer Kostenstelle zugeordnet, die über diesen Weg vom BI-System ermittelt werden kann. Entstehende Diskrepanz und deren Behebung: Es kann auch vorkommen, dass ein Prozess von Subjekten verschiedener Kostenstellen durchgeführt wird. Da dieses PKR-Verfahren davon ausgeht, dass jeder Teilprozess genau einer Kostenstelle zugeordnet werden kann, können hier nur Prozesse verarbeitet werden, die entweder einen entsprechenden Umbruch aufweisen, d. h. nur Prozesse, die von Subjekten derselben Kostenstelle durchgeführt werden, können verarbeitet werden. Oder indem davon ausgegangen wird, dass der Begriff „Teilprozess“ Synonym für den Begriff „Subjektverhalten“ verwendet wurde. (Der Verfasser dieser Arbeit schließt nicht aus, dass es zu dieser Diskrepanz durch eine unterschiedliche Auffassung des Begriffes „Teil62

prozess“ gekommen ist, was aber nicht nachgeprüft werden kann.) Der weitere Verlauf des Verfahrens, das mit der Verdichtung zu Hauptprozessen anschließt, wird davon nicht berührt. Da der Urheber des zitierten PKR-Verfahrens keine explizite Definition von „Teilprozess“ macht und nur so die geforderte Zuweisung der Teilprozesse auf eindeutige Kostenstellen möglich ist, soll in dieser Arbeit der Begriff „Teilprozess“ als Synonym für „Subjektverhalten“ gebraucht werden. Der Verfasser dieser Arbeit sieht die Ursache für diese Diskrepanz darin, dass an dieser Stelle die prozessorientierte Unternehmenssichtweise auf die traditionelle funktionsorientierte Unternehmenssichtweise trifft. Dem konnte begegnet werden, indem die PKR auf eine granularere Ebene, nämlich dem Subjektverhalten aus der Prozessorientierung gebrochen wird, in der sie den Subjekten aus der Funktionsorientierung und damit der Kostenstellenrechnung zugeordnet werden kann. Die Prozessparameter sind erforderlich, da ein Teilprozess nicht immer genau einmal pro Gesamtprozess durchlaufen wird. Manche Teilprozesse laufen seltener oder öfter ab. Im Beispiel aus Tabelle 7 wird zum Beispiel nur bei jedem dritten Einkauf ein neues Angebot angefordert. Dies ergibt einen Prozessparameter von 1/3. Das BI-System kann vor dem Erstdurchlauf eine geschätzte Plangröße vom Controller erhalten. Da es die Durchläufe der Prozesse wie oben beschrieben protokolliert, ist es möglich, die Prozessparameter automatisiert zu berechnen. Dies wird zur Aufgabe des BI-Systems. Die Maßgröße Teilprozess aus Tabelle 7 berechnet sich durch die nun im BISystem vorhandene Messung der Kostentreiber zum Hauptprozess, welche mit den ebenfalls vorliegenden Prozessparametern multipliziert werden. Für jeden Teilprozess ergibt sich so eine Maßgröße Teilprozess. Es stellt sich nun die Frage, welche Kosten für den jeweiligen Teilprozess anfallen. Dies wird im folgenden Schritt geklärt.

63

Schritt 3: Ermittlung der Prozesskosten Kostenstelle Einkauf Planprozessmenge (MGEinheiten)

Planprozesskosten EUR

Prozesskostensatz lmi (EUR/ Einheit)

Umlage lmn (EUR/ Einheit)

Gesamtprozesskostensatz (EUR/ Einheit)

Teilprozesse

Art

Maßgröße (MG)

Angebote einholen

lmi

Anzahl Angebote

1.200

300.000

250

25

275

Bestellungen aufgeben

lmi

Anzahl Bestellungen

3.600

72.000

20

2

22

Reklamationen bearbeiten

lmi

Anzahl Reklamationen

200

100.000

500

50

550

Abteilung leiten

lmn

-

-

47.200

-

-

-

Tabelle 8: Beispiel zur Ermittlung der Prozesskosten ([WöDö10] (S. 1013))

„Die von [Tabelle 8] abweichende Prozessmenge ergibt sich dadurch, dass der Teilprozess ‚Reklamationen bearbeiten‘ annahmegemäß auch Bestandteil anderer Hauptprozesse ist. Nicht für alle Teilprozesse lassen sich Maßgrößen finden, die mit dem zu erbringenden Leistungsvolumen (gemessen in Tätigkeiten) einer Kostenstelle variieren. So fällt der Prozess ‚Abteilung leiten‘ unabhängig von dem Leistungsvolumen der Kostenstelle an. In diesem Fall spricht man von leistungsmengenneutralen Prozessen (lmn-Prozesse). Variieren hingegen die Maßgrößeneinheiten eines Teilprozesses mit dem Leistungsvolumen der Kostenstelle, so spricht man von leistungsmengeninduzierten Prozessen (lmi-Prozesse). Wie das Beispiel zeigt, bestehen die Maßgrößen i. d. R. aus der Anzahl der jeweils durchzuführenden Teilprozesse (Anzahl der eingeholten Angebote, Anzahl der aufgegebenen Bestellungen, Anzahl der bearbeiteten Reklamationen). Der Pro-

64

zesskostensatz der lmi-Teilprozesse, d. h. die Festlegung der Plankosten pro Teilprozess, errechnet sich durch Division der spezifischen Prozesskosten durch die Prozessmenge. Da es sich bei der Prozesskostenrechnung um eine Vollkostenrechnung handelt, sind auch die leistungsmengenneutralen Kosten auf die Kostenträger zu verrechnen. Dies geschieht durch eine proportionale Umlage der leistungsmengenneutralen auf die leistungsmengeninduzierten Kosten. Der Anteil der lmn-Kosten an den lmi-Kosten der Kostenstelle beträgt 10 Prozent (47.200 : 472.000 • 100). Folglich wird jeder lmi-Prozesskostensatz um 10 Prozent erhöht, um zu den jeweiligen Gesamtprozesskostensätzen zu gelangen. Dieses Vorgehen entspricht dem Wesen nach einer Zuschlagskalkulation. Anschließend werden die bewerteten Teilprozesse eines Hauptprozesses addiert, so dass man als Ergebnis den Prozesskostensatz des Hauptprozesses erhält.“ (Siehe [WöDö10] (S. 1013)). Die Planprozesskosten werden bei diesem Verfahren ursprünglich als Gegeben angenommen. Das BI-System soll diese Zahlen aber im Rahmen der PKR übernehmen. Daher soll die Herkunft dieser Zahlen im Folgenden ermittelt werden. Die Planprozesskosten stellen die gesamten Kosten dar, die bei allen Durchläufen des betreffenden Teilprozesses für einen bestimmten Hauptprozess anfallen. Der Teilprozess „Material annehmen“ aus Tabelle 8 soll hierzu beispielhaft betrachtet werden. Diesem Prozess könnten folgende Abläufe unterstellt werden: Ein Mitarbeiter des Lagers zeichnet den Empfang der Lieferung ab und nimmt das Material entgegen. Beim Durchschreiten des Eingangstores zur Lagerhalle wird der Eingang von einem RFID-System (Radio-Frequency Identification) automatisch registriert und eine automatische Buchung bei der doppelten Buchführung veranlasst, sowie an das Warenwirtschaftssystem (bzw. ERP-System) gemeldet. Der Mitarbeiter übergibt das Material einer Ladeeinheit, die es LVS (Lagerverwaltungssystem) gesteuert zu seinem Stellplatz befördert. So fallen also direkt dem Teilprozess zuzuordnende Kosten für den Mitarbeiter, für die Nutzung des RFID Systems und die Nutzung des LVS an. Die Kosten für den Mitarbeiter sollen vom BI-System automatisiert bezogen werden. Hierbei könnten folgende Kosten unterstellt werden: Lohnkosten, Lohnnebenkosten. Weitere Kosten wie Raumnutzung über die z. B. Raummiete, Heizung und Reinigung auf den Teilprozess umgelegt werden können sind dann sinnvoll, wenn der Mitarbeiter ein Büro hat, da die Lagerhalle Kosten, wie be-

65

schrieben, an anderer Stelle verursacht. Sollte der Mitarbeiter regelmäßig einen hauseigenen IT-Support in Anspruch nehmen, so kann dies als Unterstützungsprozess und somit als Kostenfaktor für den Teilprozess gesehen werden, sofern der Support die IT-Systeme im Büro des Mitarbeiters und nicht das Lager betrifft. Er kann über den Prozessparameter (siehe Tabelle 7) mit einkalkuliert werden. Das IT-System im Büro des Mitarbeiters kann über einen Schlüssel auf die kalkulatorischen Kosten des Mitarbeiters pro Stunde umgelegt werden. Aus PKR-Sicht können die Kosten für die externe Herstellung des Lagers als Prozess gesehen werden. Der Lagerstellplatz kann zwar ebenfalls als Kostenfaktor aufgenommen werden, jedoch ist zu diesem Zeitpunkt noch nicht bekannt, wie lange das Material den Lagerstellplatz benötigt und wie viele Kosten somit anfallen. Dieser Kostenfaktor müsste daher in regelmäßigen Abständen, z. B. täglich neu berechnet werden. Hinzu kommt die Tatsache, dass für die Materialbeschaffung zwar bei der Materialannahme Ressourcen aus dem Lager benötigt, aber zu diesem Zeitpunkt noch keine Lagerhaltung in Anspruch genommen wird. Hier Lagerhaltungskosten auf den Prozess der Materialbeschaffung zu verrechnen, würde zu Fehlentscheidungen führen. Daher bietet es sich an, die Kosten für das Lager nicht dem Prozess der Materialbeschaffung, sondern direkt dem Kostenträger zuzurechnen. D. h. dass die Lagerkosten beim Hauptprozess der Materialbeschaffung nicht berücksichtigt werden. Weitere Kosten, die einer kalkulatorischen Mitarbeiterstunde zugeordnet werden müssen, sind unbegrenzt vorstellbar und von den jeweiligen Situationen abhängig. Es ist auch möglich, diese Kosten nicht einzeln direkt dem Prozess zuzurechnen, sondern zunächst in den Kostenstellen aufzurechnen. Das bedeutet, dass wir die Prozesssicht für diesen Schritt verlassen und auf die traditionelle KR (d. h. Kostenrechnung) zurückgreifen. Nach Ermittlung der gesamten Kosten für eine Kostenstelle können daraus die Kosten pro Mitarbeiter abgeleitet werden, z. B. pro Stunde. Dies hat den Vorteil, dass nicht für jeden Mitarbeiter einer Kostenstelle für jeden Kostenfaktor neue Kostenverteilungsschlüssel eingegeben werden müssen, sondern nur ein Satz pro Mitarbeiter. Daher soll für diese Arbeit diese Variante gelten, bei der die traditionelle Kostenstellenrechnung wie beschrieben zum Einsatz kommt. Die von der Kostenstellenrechnung so errechneten Kosten können nun mit einem Kostenverteilungsschlüssel für den Mitarbeiter im Lager, der die Material66

annahme im Hauptprozess Materialbeschaffung durchführt, im BI-System dem Prozess zugerechnet werden. Die Zahlen sollen soweit möglich vom BI-System direkt aus der Datenbank beschafft oder selbst errechnet werden. Aufgrund der Vielzahl der möglichen Kosten soll das BI-System hier individuelle Einstellungen zulassen: Eine Maske für die Eingabe der Kosten zu einem Prozess soll aufrufbar sein. Hier soll der Controller eine Bezeichnung für die Kosten wählen können und direkt Zahlen in der Datenbank, also z. B. direkt die Kontensalden aus der doppelten Buchführung angeben können die das BI-System dann automatisiert abrufen kann. Auch Berechnungsformeln sollen für den Controller hinterlegbar sein. Bei dem oben beispielhaft verwendeten Teilprozess „Angebote einholen“ wurde die Ermittlung für die Planprozesskosten wie sie hier herausgearbeitet wurde, in Tabelle 8 mit 300.000,- Euro als gegeben betrachtet. Das ist der Wert aus der Kostenstellenrechnung, der sich wie oben beschrieben für dieses Subjekt, also diesen Mitarbeiter ergibt, für den gesamten Zeitraum, den der Mitarbeiter für diesen Prozess investiert. Nun erfolgt die Umlage auf die Kostentreibersicht, die es ermöglicht, die Prozesskosten pro Durchlauf zu ermitteln. Dafür werden die Prozessplankosten auf die Planprozessmenge von 1.200 Durchläufen aufgeteilt. Es ergeben sich ein Prozesskostensatz von 250,- Euro pro Einheit, d.h. pro Durchlauf. Der Teilprozess „Abteilung leiten“ wird noch auf diesen Teilprozess mit 25,- Euro pro Durchlauf umgelegt und ergibt in diesem Beispiel den Gesamtprozesskostensatz von 275,- Euro pro Durchlauf. Den gesamten Berechnungsvorgang kann das BI-System übernehmen. Die Kostenverteilungsschlüssel müssen hierzu vom Controller hinterlegt werden. Um nun die Kosten für den Hauptprozess auf Basis der Gesamtprozesskostensätze der Teilprozesse zu ermitteln, sind diese mit dem Prozessparameter zu relativieren. Daraus wird die Summe gebildet, welche den Hauptprozesskostensatz, d. h. die Kosten für einen Durchlauf des Gesamtprozesses, darstellt:

67

Teilprozess

Gesamtprozesskostensatz

Prozessparameter

Kostenzuweisung Hauptprozess

Angebot einholen

275,00

1/3

91,67

Bestellungen aufgeben

22,00

1

22,00

Reklamationen bearbeiten

550,00

1/36

15,28

Material annehmen

15,00

1

15,00

Material prüfen

51,00

0,5

25,50

Material einlagern

30,00

1

30,00

Hauptprozesskostensatz:

199,45

Tabelle 9: Bestimmung des Hauptprozesskostensatzes (siehe [WöDö10] (S. 1014))

„Sowohl der (aggregierte) Hauptprozesskostensatz als auch die (detaillierten) Teilprozesskostensätze dienen als Informationsgrundlage für die Prozessoptimierung. Diese Informationen lassen erkennen, was die einmalige Durchführung eines Haupt- oder Teilprozesses kostet. Der Hauptprozesskostensatz dient darüber hinaus als Kalkulationssatz im Rahmen der anschließenden Kostenträgerrechnung.“ (Siehe [WöDö10] (S. 1014)). Damit wurde der Hauptprozesskostensatz, d. h. die Kosten für einen Durchlauf sowohl für den Hauptprozess als auch für die Teilprozesse ermittelt. Die Hauptprozesskosten für den Hauptprozess werden im Folgenden und letzten Schritt den Kostenträgern zugerechnet:

68

Schritt 4: Umlage der Prozesskosten auf die Kostenträger Hauptprozesskostensatz „Material beschaffen“ (199,45 EUR/Einheit) Produkt

A

B

Anzahl Materialbeschaffung pro Einheit

0,8

1,5

Prozesskosten pro Einheit

159,56

299,18

Tabelle 10: Strategische Produktkalkulation (siehe [WöDö10] (S. 1014))

„Bei dieser sog. strategischen Produktkalkulation werden jedem Kostenträger entsprechend seiner Prozessinanspruchnahme die Gemeinkosten der indirektproduktiven Bereiche zugeordnet. Hierzu wird der Hauptprozesskostensatz mit der Anzahl der Prozesswiederholung, die zur Erstellung einer Kostenträgereinheit notwendig sind, multipliziert. Diese Vorgehensweise wird als direkte Prozesskalkulation bezeichnet.“ (Siehe [WöDö10] (S. 1014)). Nach Umlage aller Prozesskosten, die an dieser Wertschöpfungskette beteiligt sind (siehe 2.3.7 und siehe oben Schritte 1 und 2), auf den Kostenträger, sind alle Kosten zu diesem Erzeugnis bekannt und können als Grundlage für die Berechnung unseres Listenpreises zum Angebot an die Kunden einsetzen. Das beschriebene BI-System kennt bereits die Wertschöpfungskette. Die Zuweisung zum Kostenträger erfolgt durch die Vergabe eines Namens für eine Wertschöpfungskette durch den Controller.

69

3. Systemerstellung 3.1

Systemanforderungen

Das System hat folgende Anforderungen: • Dem Controller neue strategische Instrumente zur Verfügung stellen und ihn unterstützen • Neue und bestehende Instrumente soweit wie möglich automatisiert durchführen und dadurch den Controller entlasten • Den Controller bei seiner kreativen Tätigkeit unterstützen • Dem Controller eine möglichst transparente und dennoch umfassende Sicht in die Prozesse des Unternehmens ermöglichen

3.2

Datenerhebung

Daten zu einem S-GP können auf folgende Weise erhoben werden: • Eingabe durch Prozessmitarbeiter • automatisierte Erfassung durch die S-BPM-Suite • Nutzung bereits vorhandener Daten aus anderen Prozessen, z. B. Lohnbuchhaltung • Beschaffung von Vergleichsdaten aus anderen Unternehmen oder anderen Unternehmensteilen • Eingabe durch Kunden (Kundenbefragung) oder Lieferanten Bei der Datenerhebung ist zu beachten, dass zu viel Kontrolle des einzelnen Mitarbeiters zu verminderter Motivation führen könnte, was aber in dieser Arbeit nicht weiter behandelt wird. Bereits im Unternehmen vorhandene Daten sollen genutzt werden. Hierzu ein Beispiel:

71

Um später den Wert der Arbeit beurteilen zu können, werden die festgestellten Arbeitszeiten der Prozessmitarbeiter mit Zahlen aus der Buchhaltungsdatenbank verknüpft. Hierbei sollte nicht nur der Bruttolohn zuzüglich Arbeitgeberanteile, sondern auch Raumkosten einbezogen werden.

3.3

Festlegung der Prozess-Sichten

Zunächst sollen die Prozess-Sichten festgelegt werden. Diese dienen als Basis für das BI-gestützte Controlling. Dabei soll von jeder Sicht aus zur jeweils niedrigeren oder höher liegenden Sicht gewechselt werden können. Prozessinstanzen-Sicht: Die Liste der Prozessinstanzen ist die oberste Sicht. Hier können alle einzelnen Durchläufe von Prozessen betrachtet werden. Wichtig ist dabei die Selektierbarkeit der Auflistung. So soll es sowohl möglich sein, sämtliche Prozessinstanzen auflisten zu lassen, als auch nach bestimmten Kriterien selektieren zu können. Die Selektierung soll nach allen Attributen der Prozessinstanzen-Sicht möglich sein. Also z. B. Anzeige aller Prozesse, die von einem bestimmten Subjekt bzw. von einem bestimmten Service (=Programm) oder einem bestimmten Mitarbeiter bearbeitet werden. Die Prozessinstanzen-Sicht wird als Tabelle im BI-System dargestellt. Ihre Attribute können beliebig erweitert werden. Außerdem soll es möglich sein, eine Detailansicht zu jedem einzelnen Prozess aufzurufen. Diese beinhaltet alle Informationen, der Prozessinstanzen-Sicht zu dem gewählten Prozess, sowie alle Informationen die zu dem Prozess bei der ProzessinstanzenSicht durch Anklicken als Untersichten erscheinen oder als Dropdown-Menü zur Verfügung stehen. Es folgt eine Auflistung der möglichen Attribute, zusammen mit je einem Beispiel bzw. einer Inhaltsangabe. • Prozessmodell-Nummer: 257 • Prozessinstanz-Nummer: 1.359 • Prozessmodell-Name: Reisekostenantrag • Prozess-Modellierer: H. Mustermann • Prozess Owner: J. Mustermann

72

• Alle Prozessmitarbeiter und Services: Pop-Down-Menü • Beteiligte Abteilungen und Server: Pop-Down-Menü • Aktuell bearbeitende Prozessmitarbeiter/Services: Pop-Down-Menü • Instanzmessungen: Verlinkung zu einer Instanzmessungen-Untersicht, welche Zeitmessungen zu den einzelnen Subjekten, sowie zur Gesamtinstanz beinhaltet • Prozessstart: Datum • Prozessende: Nein oder Datum • Prozessmodelle-Sicht: Verlinkung (mehr zu dieser Sicht siehe unten ) • Störungen: Ja/Nein, Verlinkung zur Störungen-Untersicht die z. B. stark verlängerte Zeitabweichungen bei einem Mitarbeiter anzeigt (z. B. wenn keine Urlaubsvertretung eingesetzt wurde), oder bei Fehlermeldungen die von Kunden gemeldet wurden. Hinweis: Die Mitarbeiter können hierbei ebenso eingeplant werden wie die Services, d. h. die automatisierbaren Subjektverhalten können auch von Programmen durchgeführt werden. Moderne Unternehmensarchitekturen ermöglichen sowohl den substitutiven wie auch den komplementären Einsatz zwischen Mitarbeiter und IT. Prozessmodelle-Sicht: Die Prozessmodelle-Sicht zeigt eine Übersicht über alle im Unternehmen angelegten Prozessmodelle. Auch hier soll die Auflistung, ebenso wie bei der Prozessinstanzen-Sicht beschrieben, nach allen in der Prozessmodelle-Sicht verfügbaren Attributen selektierbar sein. Die Prozessmodelle-Sicht kann in Tabellenform abgerufen werden. Die Zahl der Attribute ist beliebig erweiterbar. Die von hier aus aufrufbare Detailansicht zu einem einzelnen Prozessmodell entspricht der Subjektinteraktionsdiagramm-Schicht (SID-Schicht) (siehe auch 2.1.3). Es folgt eine Auflistung der möglichen Attribute, zusammen mit je einem Beispiel, bzw. einer Inhaltsangabe: • Prozessmodell-Nummer: 257 • Prozessmodell-Name: Reisekostenantrag 73

• Alle Prozessinstanzen: Pop-Down-Menü mit Verkinkung zu den einzelnen Prozessinstanzen zu diesem Prozessmodell. (Eine Liste aller Prozessinstanzen zu diesem Prozessmodell kann in der Prozessinstanzen-Sicht wie oben beschrieben selektiert werden.) • Prozessmessungen: Verlinkung zu einer Prozessmessungen-Untersicht. Diese beinhaltet die Durchschnittswerte zu den Zeitmessungen zu den einzelnen Subjekten für alle Durchläufe oder eine selektive Menge an Durchläufen des zugehörigen Prozesses. Ebenso werden die Durchschnittswerte zum gesamten Prozess für alle Instanzen oder eine selektive Menge an Instanzen ermittelt und hier angezeigt. Sie beinhaltet auch die maximalen und minimalen Durchlaufzeiten und eine aufrufbare Liste der einzelnen Messungen zu allen Instanzen in einer tieferliegenden GesamtinstanzenMessungen-Sicht. • Gesamtzahl Durchläufe: 1.359 • Gesamtzahl aktiver Instanzen: 3 • Ältester aktiver Durchlauf: Start am 01.01.2011, Prozessinstanz-Nummer 1.357. Oder „keine“ wenn keine Instanz aktiv ist. • Störungen: Ja/Nein, Pop-Down-Menü mit den Prozessnummern bei denen Störungen aufgetreten sind (z. B. stark verlängerte Zeitabweichungen oder von Kunden gemeldete Fehlermeldungen). Dort direkte Verlinkung zur Detailansicht einzelner Prozesse. Subjektinteraktionsdiagramm-Sicht (SID-Sicht): Beschreibung und Beispiel siehe 2.1.3. Die SID-Sicht stellt gleichzeitig die Detailansicht der Prozessmodelle-Sicht dar. Wie unter 2.1.3 beschrieben, dient sie der Modellierung von GPs bei der SBPM-Suite. Bei der Auswahl eines Prozesses aus der Prozessmodelle-Sicht die alle Prozessmodelle auflistet, wird die SID-Sicht zu dem gewählten Prozess angezeigt (siehe Abbildung 2: Subjektorientiert dargestellter GP Reisekostenantrag). Von der SID-Sicht aus können die Subjektverhalten in Form der Subjektverhaltensdiagramm-Sicht (SVD-Sicht) durch Anklicken des zugehörigen Subjektes aufgerufen werden.

74

Subjektverhaltensdiagramm-Sicht (SVD-Sicht): Beschreibung und Beispiel siehe 2.1.3. Die SVD-Sicht beschreibt innerhalb der S-BPM-Suite die jeweiligen Subjektverhalten zu den zugehörigen Subjekten (siehe Abbildung 3: Subjektverhalten Mitarbeiter zum GP Reisekostenantrag). Die so festgelegten Sichten, die als Grundlage für das BI-gestützte Controlling dienen sollen, stehen damit wie folgt in Verbindung:

Sichtebene 1

Sichttiefe 1

Sichttiefe 2

ProzessinstanzenSicht

Detailansicht einzelner Prozesse

Sichttiefe 3

InstanzmessungenUntersicht StörungenUntersicht Sichtebene 2

ProzessmodelleSicht

Sichtebene 3

SID-Sicht

Sichtebene 4

SVD-Sicht

ProzessmessungenUntersicht

GesamtinstanzenMessungenUntersicht

Abbildung 9: Festlegung der Sichten als Grundlage für das BI-gestützte Prozess-Controlling

75

3.4

Zuweisen von Prozessabhängigkeiten

Da eine Reihe von Controlling-Instrumenten und auch die Prozesskostenrechnung es erfordern, nicht nur einen einzelnen Prozess, sondern auch eine Gruppe von Prozessen zu betrachten, wird nun die Möglichkeit geschaffen, diese Gruppen einander zuzuweisen. Die Grundlagen hierfür wurden bereits im Zusammenhang mit der Wertschöpfungskettenanalyse (siehe 2.3.7) erarbeitet und soll nun in die definierten Sichten für das BI-System (siehe 3.3) integriert werden. Zunächst müssen die einzelnen Prozesse die Deklarationsmöglichkeit nach Unterstützungsprozess, Steuerungsprozess oder Kerngeschäftsprozess erhalten. Dieses soll als Prozessabhängigkeiten-Untersicht zur SID-Sicht dargestellt werden. Hier wird ein entsprechendes Auswahlfeld eingefügt. Nun werden die Schnittstellenkonfigurationen platziert. Diese werden ebenfalls in die Prozessabhängigkeiten-Untersicht zur SID-Sicht eingefügt. Sie setzt sich aus folgenden Feldern zusammen: • Eine Betrachtungsnummer, die es ermöglicht, dass derselbe Prozess in verschiedenen Strukturen, d. h. mehrmals aufzutauchen. Dies würde heißen, dass ein Prozess einen Nutzen von größer 1 in der Summe der Verteilungsschlüssel ergibt, was nicht möglich ist, denn die Wertschöpfung eines Prozesses ist auch nur einmal erfolgt. Es dient also ausschließlich der Möglichkeit der Simulation bzw. der abstrakten Auswertung. Der Begriff „Prozessgruppe“ wird an dieser Stelle daher durch den Begriff „Betrachtung“ ergänzt. • Ein Betrachtungsname zu jeder Betrachtungsnummer, aus der der Controller erschließen kann, zu welchem Zweck die Betrachtung angelegt wurde. • Die Prozessmodell-Nummer des Folgeprozesses, welche als Identifizierungsschlüssel dient und die exakte Identifizierung eines Prozessmodelles bietet. • Dem Verteilungsschlüssel, der zeigt, zu welchem Anteil der jeweilige Prozess dem über die Prozessmodell-Nummer zugewiesenen Folgeprozess zugeordnet ist, bzw. zu welchem Anteil er dem Folgeprozess zu Gute kommt.

76

Die Betrachtungsnummer und der Betrachtungsname müssen bei jedem Prozess identisch sein, dessen Schnittstelle an dieselbe Betrachtung gekoppelt wurde. Da es auch mehrere Folgeprozesse geben kann, soll die Liste dieser beiden Felder sich nach jeder Eingabe automatisch erweitern. Da es mehrere Betrachtungsnummern geben soll (siehe oben) soll sich die Anzahl der Reihen dieser Liste nach jeder Eingabe beliebig erweitern.

Schnittstelle der Prozessmodell-Nummer: 441 Prozesstyp wählen:

Kerngeschäftsprozess Unterstützungsprozess Steuerungsprozess

Betrachtungsnummer:

25

Betrachtungsname:

Betrachtungsnummer:

Simulation 1

Betrachtungsname:

Folgeprozess (Prozessmodell-Nummer):

25

Folgeprozess (Prozessmodell-Nummer):

Verteilungsschlüssel:

0,4

Verteilungsschlüssel:

Folgeprozess (Prozessmodell-Nummer):

57

Verteilungsschlüssel:

0,6

Folgeprozess (Prozessmodell-Nummer): Verteilungsschlüssel:

Abbildung 10: Beispiel zur Schnittstelle der Prozessabhängigkeiten in der Prozessabhängigkeiten-Untersicht zur SID-Sicht

77

Durch diese Schnittstelle ist es dem Controller möglich, Strukturen zu schaffen, die aus mehreren Prozessen bestehen, z. B. um mehrere Prozesse zu einer Prozessgruppe zusammenzusetzen, die dann in ihrer Gesamtheit betrachtet werden kann. Oder um eine Wertschöpfungskette zu schaffen, d. h. alle Prozesse die an der Erzeugung eines bestimmten Produktes beteiligt sind (siehe Abbildung 7). Dabei werden durch den Verteilungsschlüssel auch ihre Anteile an dieser Erzeugung berücksichtigt.

3.5

Integration der PKR in das BI-System

Hier werden Schritt 2: Prozessmessungen und Schritt 3: Ermittlung der Prozesskosten aus dem PKR-Verfahren im BI-System wie beschrieben (siehe 2.4.3) in das BI-System integriert. Der Schritt 1: Grundstruktur der Prozesse ist bereits unter 3.4 Zuweisung von Prozessabhängigkeiten umgesetzt worden. Der Schritt 4: Umlage der Prozesskosten auf die Kostenträger beinhaltet als letzten Schritt des PKR-Verfahrens die Zuweisung des Erzeugnisses zu einer Betrachtungsnummer (siehe Abbildung 10), was durch den Controller erfolgen soll. Integration von Schritt 2 des PKR-Verfahrens in das BI-System: Hinweis: Dieser Bereich arbeitet mit Subjektverhalten. Dieser Schritt soll nicht als Sicht, sondern als Datenbank-Relation im Hintergrund umgesetzt werden. Es werden hierbei alle Subjektverhalten aufgelistet, die der gewählten Betrachtungsnummer oder der gewählten Prozessmodell-Nummer angehören. Da hier bei der Datenhaltung in einer Relation eine Dreidimensionalität entstehen würde, bekommt jedes Attribut einen eigenen Relation. Diese Relationsgruppe wird im Folgenden als „erste PKR- Relation“ bezeichnet. Die Spalte Hauptprozess gilt dabei als die Überschrift der ersten PKR-Relation, die aus der Betrachtungsnummer und dem Betrachtungsnamen besteht. Diese Überschrift existiert als eine Relation der ersten PKR- Relation. In der ersten PKR- Relation sollen nicht nur die Betrachtungen, sondern auch alle Prozesse hinterlegt werden, die nicht über Schnittstellen mit anderen Pro-

78

zessen zu einer Prozessgruppe zusammengesetzt wurden. In diesem Fall besteht die Überschrift der ersten PKR- Relation aus Prozessmodell-Nummer und Prozessmodell-Name. Die genannten Informationen für die Überschrift stellen also Informationen dar, die für die ganze erste PKR- Relation gelten. Für die restlichen EinzelRelationen der ersten PKR- Relation bleiben noch folgende Spalten aus der Tabelle 7: Als Kostentreiber wird wie beschrieben (siehe 2.4.3) die vom BI-System gezählte Durchlaufzahl zu dieser Betrachtungszahl verwendet. Welche Daten hierbei als Kostentreiber hinterlegt werden können, muss der Controller explizit wählen. Die Prozessabhängigkeiten-Untersicht muss um eine entsprechende Funktion ergänzt werden. Eine flexible Möglichkeit ist, dem Controller ein Feld anzubieten, mit dem er direkt ein Feld in der Datenbank als Grundlage für die Durchlaufszählung auswählen kann. Dieses Feld kann in der PKR-Sicht eingefügt werden (siehe Abbildung 11), welche in der Lage ist, jeden beliebigen Prozess und jede beliebige Prozessgruppe darzustellen. Es soll hier eine Spalte „Subjektverhalten“ für die Teilprozesse aus der ursprünglichen Tabelle des Verfahrens (siehe Tabelle 7) geben, welche die Namen der einzelnen Subjekte aus der SID beinhaltet. Die einzelnen Namen sollen dabei direkt mit der detaillierten SVD-Sicht zum jeweiligen Subjektverhalten verlinkt werden. Die Spalte „Kostenstelle“ wird aus der Datenbank über die hinterlegte Kostenstellenzugehörigkeit der einzelnen Subjekte ausgelesen. Den Prozessparameter berechnet das BI-System aus der Relation zwischen den Durchlaufzahlen der Subjektverhalten die bei der Messung in der Datenbank hinterlegt wurden, und dem Kostentreiber. Die Spalte „Maßgröße Teilprozess“ ergibt sich aus der Multiplikation von Kostentreiber und Prozessparameter. Integration von Schritt 3 des PKR-Verfahrens in das BI-System: Auch die Tabelle 8 soll als Relation, bzw. als Relationsgruppe wie beschrieben zur Vermeidung einer Dreidimensionalität in der relationalen Datenbank im

79

Hintergrund gehalten werden. Sie soll als „zweite PKR-Relation“ bezeichnet werden. Die zweite PKR-Relation bezieht die Daten für die Spalte 1 der Tabelle 8 aus der ersten PKR-Relation. Die Spalte „Art“ wird vom bereits hinterlegten Prozesstyp abgeleitet. Die Planprozessmenge wird aus der ersten PKR-Relation bezogen. Die Ermittlung der Planprozesskosten wurde im Rahmen des PKRVerfahrens Schritt 3 bereits behandelt (siehe 2.4.3). Der Bezug der Kosten aus der traditionellen KR wurde dafür gewählt. Die Inhalte des Attributes Prozesskostensatz werden vom BI-System automatisch in die Datenbank eingetragen. Die Umlage als relativer Wert existiert im BI-System bereits bei den Prozessabhängigkeiten als Verteilungsschlüssel (siehe 3.4), welcher hier abgefragt wird. Daraus wird die Umlage in Euro berechnet. Welche Prozesse umgelegt werden müssen, erkennt das BI-System ebenfalls aus den Prozessabhängigkeiten und können dort vom Controller eingestellt werden. So kann er z. B. für eine Betrachtungsnummer, welche eine Reihe von fünf direkt aufeinanderfolgenden Prozessen des Typs Unterstützungsprozess darstellt, bei allen Schnittstellen (siehe Abbildung 7) einen Verteilungsschlüssel von 0 eingeben. Auch hier kommt es wieder zu der entstehenden Diskrepanz (siehe 2.4.3) zwischen Teilprozessen und Subjektverhalten. Dem wird hier so begegnet, dass der über den einzelnen Subjektverhalten liegende Prozess die Verteilungsschlüssel an die Subjektverhalten vererbt. War bei einem Unterstützungsprozess mit drei Subjektverhalten der Verteilungsschlüssel z. B. bei 0,5 und die Planprozesskosten bei 30.000,- Euro, so war die dem Folgeprozess zuzuweisende Umlage bei 15.000,- Euro. Bei der Vererbung des Verteilungsschlüssels an die drei Subjektverhalten mit jeweils 0,5 wird dieser nur auf die Planprozesskosten der einzelnen Subjektverhalten, welche in der Summe 30.000,- Euro ergeben, angewendet. Dadurch entsteht über diesen Weg die wertmäßig gleiche Umlage, wodurch die Diskrepanz behoben wird. Die Tabelle 9 soll mit der Bezeichnung „dritte PKR-Relation“ im Hintergrund in der Datenbank, wie bei der ersten PKR-Relation beschrieben, gehalten werden. Die übrigen Daten für die dritte PKR-Relation bestehen bereits aus den vorhergehenden PKR-Relationen oder können aus ihnen generiert werden. Damit wurde das PKR-Verfahren in das BI-System integriert. Alle Zahlen liegen ihm nun vor und können als neue Sicht dem Controller angezeigt werden. 80

Diese Sicht soll als „PKR-Sicht“ bezeichnet werden und als neue Sichtebene der Sichttiefe 1 existieren. Der Controller soll nach Eingabe einer Prozessnummer oder einer Betrachtungsnummer eine Liste aller zugehörigen Subjektverhalten bekommen, wobei zum selben Prozess gehörige Subjektverhalten von einem Viereck umschlossen sind. Dieses Viereck soll als „Prozessmarkierung“ bezeichnet werden. Zu jedem Subjektverhalten sollen hier der Gesamtprozesskostensatz und die Kostenzuweisung zum Hauptprozess (je nach Auswahl der Prozess oder die Betrachtung) dargestellt werden. Zu jeder Prozessmarkierung soll sowohl die Summe der Gesamtprozesskostensätze als auch der Hauptkostensatz angezeigt werden. Gibt es mehrere Prozessmarkierungen, so soll zusätzlich die Summe der Gesamtprozesskostensätze aller Prozessmarkierungen und die Summe der Hauptkostensätze aller Prozessmarkierungen angezeigt werden.

81

Abbildung 11: Beispiel für eine PKR-Sicht

Die Summe der jeweiligen Prozessmarkierung zur Kostenzuweisung Hauptprozess entspricht dem Hauptkostensatz, in diesem Beispiel 21,00 Euro bei Prozessnummer 377 und 50,00 Euro bei Prozessnummer 612. Die Kostensumme dieser Betrachtung unter Kostenzuweisung Hauptprozess, in diesem Beispiel 71,00 Euro, entspricht z. B. der Summe aller Kosten der Wertschöpfungskette, wenn auch die Betrachtung eine Wertschöpfungskette darstellt. Da hier nicht immer eine Wertschöpfungskette vorliegt, soll dieser Betrag als Oberbegriff ergänzend als die Gesamtkosten der Betrachtungsnummer bezeichnet werden. Ergänzend sei noch vermerkt, dass eine zusätzliche Unter-Sicht zu den Subjekten der PKR-Sicht die einzelnen Kosten für die Subjekte aufschlüsseln können, 82

d. h. die vorhandenen Daten aus der traditionellen KR hinterlegt werden können. Außerdem sollen die Subjektverhalten zur Prozessmessungen-Untersicht verlinkt werden. Mit der PKR-Sicht steht dem Controller nun eine Kostenübersicht zur Betrachtung einzelner Prozesse aber auch jeder gewünschten Struktur von Prozessgruppen zur Verfügung. Sie dient auch als Grundlage für die Controlling-Instrumente des BI-Systems.

3.6

Integration der Controlling-Instrumente in das BI-System

Bei den einzelnen Controlling-Instrumenten wurde bereits in dieser Arbeit geprüft, welche Bereiche von ihnen in einem BI-System umsetzbar sind. Die Grundlagen dafür, wie die Umsetzung jeweils erfolgen kann, wurde in diesem Zusammenhang jeweils erklärt. Die Rahmenbedingungen für das System wurden durch die Festlegung der Sichten (siehe 3.3) und der Schnittstellen für die Zuweisung der Prozessabhängigkeiten (siehe 3.4) vorbereitet. Die Kosten stehen als Grundlage aus der PKR zur Verfügung. Die Controlling-Instrumente sind über eine eigene Sicht aufrufbar. Diese wird mit der Bezeichnung „strategisches-Controlling-Sicht“ belegt. Diese Sicht ist eine neue Sichtebene der Sichttiefe 1. Integration von Prozess-Outsourcing: Die Integration erfolgt für den bereits erarbeiteten Bereich des ProzessOutsourcings (siehe 2.3.1). Demnach wird zur Unterstützung des Controllers eine Gegenüberstellung der Prozesskosten oder der Kosten für die Wertschöpfungskette und der Angebote externer Firmen für die Durchführung derselben Prozesse, Prozessgruppen oder Wertschöpfungsketten benötigt. Für die Kostenseite wurde die PKR bereits vorbereitet, die benötigten Zahlen liegen hier bereits vor. Für das Prozess-Outsourcing soll nun eine Unter-Sicht zur strategisches-Controlling-Sicht in der Sichttiefe 2 mit der Bezeichnung Pro-

83

zess-Outsourcing-Sicht entstehen. Dort soll eine Tabelle vorliegen mit folgenden Attributen: • Betrachtungsnummer • Betrachtungsname • Gesamtkosten der Betrachtungsnummer • Bestes Angebot externer Firmen. Verlinkung auf alle Angebote zu dieser Betrachtungsnummer in einer weiteren Untersicht auf Sichttiefe 3 mit der Bezeichnung „Angebot-Sicht“. In dieser Sicht soll der Controller die Angebote auch direkt eingeben können. Sie beinhaltet nicht nur die Angebotspreise sondern auch die Namen der zugehörigen Firmen. • Ein Button „Drucken“ löst den Ausdruck aller SID-Sichten aus, die zu dieser Betrachtungsnummer hinterlegt sind. Beim Aufruf der Prozess-Outsourcing-Sicht sollen zunächst alle vorher vom Controller definierten Prozessgruppen (siehe 3.4 Zuweisen von Prozessabhängigkeiten) gelistet werden. Darunter wird die Liste aller übrigen Prozesse die in der S-BPM-Suite vorliegen, dargestellt. Damit ein Controller die Angebote auch anfragen kann, muss er den Prozessverlauf auch ausdrucken können. Dazu wurde ein entsprechender Button hinterlegt. Der Controller kann nun in dieser Prozess-Outsourcing-Sicht erkennen, welche Prozesse von externen Firmen günstiger angeboten werden, und somit für ein Outsourcing in Frage kommen. Integration von Prozess-Benchmarking: Wie bereits beschrieben (siehe 2.3.2) wird hierzu in der Datenbank eine zusätzliche Relation als Attribut zur Prozess-Relation hinzugefügt, welches den jeweiligen ID-Schlüssel beliebig vieler Vergleichsprozesse beinhalten kann. Dieser Schlüssel soll als Benchmark-Schlüssel bezeichnet werden. Er soll sowohl bei Prozessen wie auch bei Prozessgruppen hinterlegt werden können. Auch soll jeder Benchmark-Schlüssel einen Benchmark-Namen bekommen, damit der Controller die Aufgabe dieser Gegenüberstellung wiedererkennen kann. Die Zu-

84

weisung dieser beiden Felder soll bei der PKR-Sicht möglich sein, welche so konzipiert wurde, dass sie bereits alle Prozesse und Prozessgruppen darstellen kann. Als Sicht soll eine Prozess-Benchmarking-Sicht als Unter-Sicht der strategisches-Controlling-Sicht dienen. Für jede Gegenüberstellung soll eine beliebige Zahl an Prozessen oder Prozessgruppen gegenübergestellt werden können. Die gegenüberzustellenden Attribute sollen beliebig erweiterbar sein. Sinnvolle Attribute sind: • Betrachtungsnummer oder Prozessmodell-Nummer • Betrachtungsname oder Prozessmodell-Name • Gesamtkosten der Betrachtungsnummer • durchschnittliche Durchlaufzeit • durchschnittliche Bearbeitungszeit • Gesamtzahl der Störungen In der Prozess-Benchmarking-Sicht soll immer die Tabelle mit diesen Attributen mit allen Prozessen oder Prozessgruppen zu einem Benchmark-Schlüssel wählbar sein, und somit angezeigt werden. Für das externe Prozess-Benchmarking, d. h. der Prozessvergleich mit externen Firmen, verwendet der Controller die Szenarioplanung (siehe 2.3.4 und 3.5), um Testprozesse anzulegen, verwendet hierbei aber nicht Subjekte seines Unternehmens, sondern gibt zu diesen Zwecken die Subjekte der Vergleichsunternehmen ein. Die Messungen und Zahlen zu diesen Testprozessen sollen vom Controller manuell hinterlegt werden können, da es sich um nicht-aktive Prozesse handelt, die keine Messungen liefern können. Die Prozess-BenchmarkingSicht kann auf so erstellte Testprozesse den Vergleich mit den Prozessdaten externer Firmen durchführen. Bei der Prozess-Benchmarking-Sicht besteht außerdem die Möglichkeit, Werte zu hinterlegen, die eine maximale oder minimale Abweichung von einer Basiszahl definieren. Wird diese Zahl erreicht, so wird der Controller vom BI-System informiert. Dadurch ist eine automatische Prüfung nach den Vorgaben des Controllers durch das BI-System möglich.

85

Integration der prozessorientierten SWOT-Analyse: Bei der SWOT-Analyse als Argumentation können monetäre Argumente auf Grundlage der PKR des BI-Systems aufgebaut werden. Bei der SWOT-Analyse mit Vergleichszahlen entstehen insgesamt drei UnterSichten zur strategisches-Controlling-Sicht. Zwei davon liegen in der zweiten Sichttiefe, nämlich die SWOT-Werte-Sicht und die SWOT-Noten-Sicht. Als Unter-Sicht zu diesen beiden Sichten liegt in der dritten Sichttiefe die SWOTBewertung-Sicht. Die SWOT-Werte-Sicht listet im Rahmen einer Tabelle Prozesse auf und bildet zu diesen verschiedene Attribute ab. Um Prozesse hinzuzufügen gibt es ein Feld, in das die gewünschte Prozessmodell-Nummer eingetragen werden kann. Auch Prozessgruppen können hier hinzugefügt werden. Ein flexibler Austausch der Attribute ist dadurch umsetzbar, dass der Controller die einzelnen Felder direkt mit Datenbankfeldern belegen kann, und die Attribut-Überschrift selbst eintragen kann. Zu jedem Attribut gibt es drei Felder in horizontaler Anordnung: Eines für generelle Anforderung, eines für eigenes Unternehmen und eines für Wettbewerb. Beispiele für diese Attribute und deren Beschaffung wurden bereits aufgelistet (siehe 2.3.3). Die SWOT-Bewertung-Sicht zeigt dieselbe Tabelle an, die in der SWOT-WertSicht vom Controller festgelegt wurde. Allerdings stehen jetzt an Stelle der drei horizontalen Felder je Attribut zu Prozesszuordnung sechs Felder in vertikaler Anordnung. Der Controller kann hier die Wertebereiche für die Benotung von eins bis fünf hinterlegen. Die SWOT-Noten-Sicht zeigt nun die Noten zur SWOT-Wert-Sicht auf Basis der SWOT-Bewertung-Sicht. Hinter jeder Note kommt hier ein weiteres Feld hinzu. Hier kann der Controller eine Note eintragen, bei deren Erreichen das BISystem ihn automatisch informiert. Integration von Szenarioplanung und Prozessvarianten: Um den beschriebenen neuen Modus in der SID-Sicht und der SVD-Sicht (siehe 2.3.4) umzusetzen, wird jeder im neuen Modus erstellte Test-Prozess mit einem Vermerk in der Datenbank gekennzeichnet. Prozesse, die so gekennzeichnet

86

sind, werden vom gesamten BI-System zwar erfasst, um Auswertungen zu ermöglichen, werden aber als solche markiert. Bei der Verwendung von Wertschöpfungsketten für die Preisbildung und anderen Folgen für andere Betriebsbereiche muss darauf geachtet werden, dass die Test-Prozesse nicht in diese speziellen Ergebnisse einfließen. Die SID-Sicht, die im neuen Modus läuft, soll als SID-Szenario-Sicht und die SVD-Sicht im neuen Modus als SVD-SzenarioSicht bezeichnet werden. Beide Szenario-Sichten können alle Prozesse anzeigen, auch die Test-Prozesse mit dem Vermerk. Die Subjekte, die bei Test-Prozessen hinterlegt sind, nehmen real davon keine Notiz. Der Controller kann sich mit einem Test-Account einloggen und dort die Rollen der verschiedenen Subjekte einnehmen um das Verhalten des Prozesses zu testen. Integration der prozessorientierten Gap-Analyse: Sie liegt in der zweiten Sichttiefe als Unter-Sicht der strategisches-ControllingSicht und trägt die Bezeichnung Gap-Analyse-Sicht. Sie besteht aus einer beliebig erweiterbaren Reihe von Attributen. Um diese flexibel verwalten zu können, soll der Controller die Feldinhalte direkt mit Feldern der Datenbank belegen können und manuell eine Bezeichnung der Attribute in der Gap-Analyse-Sicht eintragen können. Hinter diesen beiden Feldern zum jeweiligen Attribut folgt ein drittes Feld, in das der Controller einen Ziel-Wert eintragen kann, und ein viertes Feld mit einem Ziel-Datum. Wird der Ziel-Wert oder das Ziel-Datum erreicht, so wird der Controller informiert. Das fünfte Feld beinhaltet die Differenz zwischen dem angezeigten aktuellen Wert und dem Ziel-Wert, welche den „Gap“ der Gap-Analyse darstellt. Integration der prozessorientierten Potenzialanalyse: Wie bereits festgestellt wurde (siehe 2.3.6) stehen die beiden Instrumente, nämlich die SWOT-Analyse und die prozessorientierte Potenzialanalyse zueinander in Konkurrenz. Für dieses BI-System wurde die SWOT-Analyse gewählt. Die prozessorientierte Potenzialanalyse wäre damit redundant und wird daher nicht in das BI-System aufgenommen.

87

Integration der Wertschöpfungskettenanalyse: Das bisherige BI-System ist bereits so konzipiert, dass die dafür bereits beschriebene Unterstützungsleistung des BI-Systems (siehe 2.3.7) für den Controller bereits vorliegt, und somit hierfür keine weiteren Konzeptionen benötigt werden. Das manuelle Vorgehen zur BI-gestützten Wertschöpfungskettenanalyse läuft dann so ab, dass der Controller die zu betrachtende Wertschöpfungskette als neue Betrachtungsnummer definiert. Dazu füllt er die Schnittstellen bei allen dieser Wertschöpfungskette zugehörigen Prozessen aus (siehe 3.4). Im Anschluss öffnet er die PKR-Sicht zu dieser Betrachtungsnummer (siehe Abbildung 11). Damit stehen ihm Wertschöpfungen für alle Subjektverhalten, Prozesse und der ganzen Wertschöpfungskette in Form der jeweiligen Kosten zur Verfügung. Auch die Betrachtung der Prozessmessungen ist über die Prozessmessungen-Untersicht möglich, wenn erforderlich. Dadurch stellt das BISystem dem Controller alle erforderlichen Informationen zur Verfügung, um den beim Controller verbleibenden kreativen Anteil der Aufgaben der Wertschöpfungskettenanalyse durchzuführen. Integration der Prozessbündelungsanalyse: Hierzu wird eine Sicht benötigt, die alle Subjektverhalten zu einem Mitarbeiter auflistet. Dies wurde in dieser Form noch in keiner Sicht umgesetzt. Die neue Sicht soll als Bündelungsanalyse-Sicht bezeichnet werden. Sie stellt SIDSichten zu allen Subjektverhalten dar, die zu einem Mitarbeiter hinterlegt sind. Die Subjektverhalten sind dabei horizontal aneinandergereiht. Daraus kann der Controller im Rahmen der Prozessbündelungsanalyse ähnliche Arbeitsschritte erkennen und dann Prozessbündelungen veranlassen.

88

Damit besteht nun folgende Sicht im BI-System:

Abbildung 12: Festgelegte Sichten im BI-System nach Integration der Prozessabhängigkeiten, der PKR und der strategischen Controlling-Instrumente

Die Konzeption des BI-Systems dieser Arbeit ist damit abgeschlossen.

89

4. Ausblick Dem Unternehmenscontrolling steht mit dem Konzept dieser Arbeit ein umfassendes System zur Verfügung, das sowohl eigenständig Aufgaben aus dem Controlling übernimmt, wie auch den Controller unterstützt. Die Schnittstelle zwischen Controller und dem BI-System ist der Bildschirm und die Tastatur bzw. die Maus. Alle Informationen, die der Controller aus dem BI-System erhält, wurden zweidimensional abgebildet. Es wäre aber auch denkbar, dass der Controller sich mittels einer dreidimensionalen Abbildung eines Unternehmens durch ein BI-System bewegt. Also nicht nur eine dreidimensionale Gegenüberstellung von Attributen, sondern eine komplett dreidimensional aufgebaute Unternehmenslandschaft. Schon bei der zentralen Datenhaltung wäre eine neue mehrdimensionale Denkweise der Entwickler, ersatzweise bzw. aufbauend auf die Denkweise von relationalen Datenbanken, hierfür förderlich. Dies würde beim Anwender eine stärkere Auslastung der menschlichen Denkleistung bedeuten. Noch mehr Informationen könnten in verständlicher Weise dargestellt werden. Eine noch stärkere Vernetzung zwischen den einzelnen Daten wäre möglich.

91

Literaturverzeichnis [AhKn06] Ahlrichs Frank, K. T.: Controlling von Geschäftsprozessen. Prozessorientierte Unternehmenssteuerung umsetzen. Stuttgart, Schäffer-Poeschel Verlag (2006). [Beck07]

Becker, M.: Geschäftsprozess-Controlling auf der Basis von Business-Intelligence-Konzepten und Data-Warehouse-Systemen. – Architektur, Datenmodell, Vorgehensmodell und Anwendungsszenarien – Aachen, Shaker Verlag (2007).

[BVWB07] Becker Jörg, V. O.: Softwareauswahl und -einführung in Industrie und Handel: Vorgehen bei und Erfahrungen mit ERP- und Warenwirtschaftssystemen Berlin, Springer (2007). [Bilg08]

Bilgic, A.: Zusammenspiel von Corporate Performance Management, Business Intelligence und Business Activity Monitoring Hamburg, Diplomica Verlag (2008).

[ChGl04]

Chamoni P., G. P.: Integrationstrends bei Business-IntelligenceSystemen. Empirische Untersuchung auf Basis des Business Intelligence Maturity Model. Wirtschaftsinformatik, Jg. 46, 2/2004 , 119-128 (2004).

[EsSi09]

Eschenbach Rolf, S. H.: Controlling professionell Stuttgart, Schäffer-Poeschel (2009).

[FiFO06]

Fischer Herbert, F. A.: Geschäftsprozesse realisieren Wiesbaden, Vieweg (2006).

[Flei94]

Fleischmann, A.: Distributed Systems - Software Design & Implementierung Springer-Verlag (1994).

93

[Gada08]

Gadatsch, A.: Grundkurs Geschäftsporzess-Management Wiesbaden, Vieweg (2008).

[Gary08]

Gary, A.: Business Intelligence. Grundlagen und Anwendungsmöglichkeiten im Controlling. Saarbrücken, VDM Verlag Dr. Müller (2008).

[Gent03]

Gentsch, P.: DataMining im Controlling. Methoden, Anwendungsfelder und Entwicklungsperspektiven. Zeitschrift für Controlling und Management, Sonderheft 2 , 14-23 (2003).

[HaCh94]

Hammer M., C. J.: Business Re-Engineering Frankfurt, Campus Verlag (1994).

[Hoar85]

Hoare, C.: Communicating Sequential Processes New Jersey, Prentice Hall (1985).

[Horv03]

Horvath, P.: Controlling. 10. Auflage München, Verlag Vahlen (2006).

[Inmo96]

Inmon, W.: Building the Data Warehouse. 2. Auflage New York, (1996).

[Joos06]

Joos-Sachse, T.: Controlling, Kostenrechnung und Kostenmanagement Wiesbaden, Deutschland: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, GWV Fachverlag GmbH (2006).

[Kell07]

Keller, W.: IT-Unternehmensarchitektur Heidelberg, dpunkt.verlag (2007).

[Kem06]

Kemper H.G., M. W.: Business Intelligence - Grundlagen und praktische Anwendung. Eine Einführung in die IT-basierte Managementunterstützung, 2. Auflage Wiesbaden, Vieweg+Teubner (2006).

94

[Link04]

Link, J.: Präzisierung und Ergänzung der Koordinationsorientierung: Der kontributionsorientierte Ansatz. In G. P. E. Scherm, Controlling. Theorien und Konzeptionen. ( S. 409431). München, (2004).

[Metr02]

Mertens, P.: Business Intelligence - ein Überblick. Arbeitspapier an der Universität Erlangen-Nürnberg 2/2002 , (2002).

[Miln80]

Milner, R.: Calculus of Communicating Systems Berlin, SpringerVerlag (1980).

[Oehl06]

Oehler, K.: Corporate Performance Management mit Business Intelligence Werkzeugen. München, Carl Hanser Verlag (2006).

[Olfe10]

Olfert, K.: Kostenrechnung. Kompendium der praktischen Betriebswirtschaftslehre. Herne, Neue Wirtschafts-Briefe GmbH und Co. KG (2010).

[Reme05]

Remer, D.: Einführen der Prozesskostenrechnung. Grundlagen, Methodik, Einführung und Anwendung der verursachungsgerechten Gemeinkostenzurechnung. 2. Auflage Stuttgart, Schäffer-Poeschel Verlag (2005).

[Sche05]

Scheer, I.: Aris Controlling Plattform - Whitepaper. Saarbrücken, (2005).

[ScSe02]

Schmelzer J., S. W.: Geschäftsprozessmanagement in der Praxis. München, Carl Hanser Verlag (2002).

[ScFG09]

Schmidt Werner, F. A.: Praxis der Wirtschaftsinformatik. Subjektorientiertes Geschäftsprozessmanagement - Heft 266 Sonderdruck , dpunkt.verlag (2009).

95

[Schu00]

Schulze J., B. V.: Methodische Einführung des Customer Relationship Managements. (S. H., Hrsg.) Modellierung betrieblicher Informationssysteme, Proceedings der MobISFAchtagung 2000 Universität Siegen , (2000).

[SLFB06]

Seufert, : Der Markt für Business Intelligence. Stand und Entwicklungstendenzen. In L. P. Seufert A., Status Quo – Chancen und Herausforderungen ( S. 11-24). Stuttgart, Tagungsband Symposium Business Intelligence (2006).

[Wahl98]

Wahl, G.: UML kompakt. OBJEKTspektrum 2/1998 , (1998).

[Webe04]

Weber, J.: Einführung in das Controlling Stuttgart, SchäfferPoeschel Verlag (2004).

[Wink10]

Winkler, S.: Monitoring kritischer Prozess- und Projektaktivitäten mithilfe persönlicher Assistenten Köln, Josef Eul Verlag (2010).

[WöDö10] Wöhe Günter, D. U.: Einführung in die Allgemeine Betriebswirtschaftslehre München, Verlag Franz Vahlen GmbH (2010).

96

Stichwortverzeichnis

Activity Diagramms · 22

EPK · 22, 23 ERP-System · 31, 37, 56, 65 EUS · 29

B

F

Benchmarking · 42, 43, 44, 45, 84, 85 BI · 15, 16, 29, 30, 32, 33, 34, 35, 36, 37, 38, 39, 40, 72, 75, 88 BI-Instrumente · 35 BI-System · 16, 40, 41, 42, 43, 44, 45, 47, 48, 49, 50, 51, 52, 54, 55, 56, 58, 60, 62, 63, 65, 67, 69, 72, 76, 78, 79, 80, 83, 85, 86, 87, 88 BI-Systems · 15, 16, 54, 56, 86 BPMN · 22, 23 BPR · 41 Bündelungsanalyse · 88 Business Performance Measurement · 33 Business-Intelligence-Systems · 15 Business-Performance-Management · 33 Business-Process-Management · 15

Führungsprozesse · 19

A

C Calculus of Communicating Systems · 23 Controlling · 15, 29, 30, 31, 34, 35, 36, 37, 38, 39, 40, 49, 72, 76, 83, 85, 86, 87, 89 Controlling-Instrumente · 17 strategische · 16 Controllingsysteme · 34 CPM · 33, 34 CRM · 38, 57

D Data Mining · 34 Data-Mart · 37 DDS · 29 Diagrammsprachen · 21 DWH · 32, 33, 37, 38

E eEPK · 22, 23 Einzelkosten · 32 Enterprise-Performance-Management · 33

G Gap-Analyse · 49, 87 prozessorientierte · 49, 87 Gemeinkosten · 32, 33, 58, 59, 62, 69 Gesamtprozesskostensatz · 65, 67, 81 Geschäftsprozess-Management · 15 subjektorientiertes · 15 GP · 19, 20, 21, 22, 24, 25, 26, 27, 28, 38, 49, 74, 75 GPM · 19, 20, 27, 32, 38 GPM-Software · 22

H Hauptkostensatz · 81, 82 Hauptprozess · 60, 61 Hauptprozesskosten · 68 Hauptprozesskostensatz · 67, 68, 69

I IKT · 34 Intelligence · 29

K Kerngeschäftsprozesse · 19, 53, 54, 60, 76 Kommunikationsbeziehungen · 22 Kontrollflussdiagramm · 23 Kostenartenrechnung · 57 Kostenrechnung · 32, 39 Kostenstellen · 28, 59, 61, 62, 64, 65, 66, 79 Kostenstellenrechnung · 57, 63, 66, 67 Kostenträger · 32, 58, 59, 62, 66, 68, 69, 78 Kostenträgerrechnung · 57, 68 Kostentreiber · 59, 61, 62, 79 KPI · 43, 44 KR · 83

97

lmi · 64 lmn · 64, 65 LVS · 65

Prozessparameter · 61, 63, 66, 67, 79 Prozessplankosten · 67 Prozessstörungen · 40 Prozessvariante · 48, 86 PWH · 32

M

Q

Management · 35, 40 MIS · 29, 33 Modellierungssprachen · 23 Monitoring · 30, 31, 38 MSS · 29

Querschnittsprozesse · 19

L

N Notation · 21, 22

O OLAP · 34 Organisationsstruktur · 28 Outsourcing · 41, 83, 84

P PKR · 32, 33, 41, 47, 51, 52, 53, 54, 57, 58, 59, 60, 62, 63, 64, 65, 66, 76, 78, 79, 80, 82, 83, 86, 88, 89 Plankostenrechnung · 32 Planprozesskosten · 65, 67, 80 Planprozessmenge · 61, 67 PLM · 57 POKR · 33, 57 Potenzialanalyse · 46, 50, 51, 52, 87 prozessorientierte · 50, 51, 87 Primärprozesse · 19 Prozess-Benchmarking · 42, 84, 85 Prozessbündelung · 55, 56, 88 Prozessbündelungsanalyse · 55, 56, 88 Prozess-Controlling · 31, 38, 39, 49, 75 Prozessdokumentation · 33 Prozessdurchläufe · 49, 50 Prozessgruppe · 41 Prozessinstanz · 20, 72, 73, 74 Prozesskostenrechnung · 17 Prozesskostensatz · 65, 67, 80 Prozessleistung · 32 Prozessmanager · 28 Prozessmessung · 51 Prozessmodell · 72, 73, 74, 76, 78, 79, 85, 86 Prozess-Monitoring · 32, 38 Prozessorganisation gemischte · 28 Prozess-Outsourcing · 41, 83, 84

98

R Rechnungswesen · 35, 36, 39 Reporting · 34 Ressourcen · 28, 45, 50, 66 Ressourcenanalyse · 50 Ressourcenpools · 28 RFID · 65

S S-BPM · 15 S-BPM-Suite · 15, 16, 22, 24, 27, 55, 56, 62, 71, 74, 75, 84 SCM · 56 S-GP · 71 S-GPM · 15, 16, 19, 22 SID · 15, 23, 24, 73, 74, 76, 79, 84, 86, 87, 88 Steuerungsprozesse · 19, 53, 54, 60, 76 Subjekt · 22 Subjektaufgaben · 49 Subjektorientierung · 20, 21, 22 Subjektverhalten · 15, 25, 26, 27, 56, 62, 63, 73, 75, 78, 79, 80, 81, 83, 88 SVD · 15, 23, 74, 75, 79, 86 SWOT-Analyse · 45, 46, 47, 48, 50, 51, 86, 87 prozessorientierte · 45, 86 Szenarioplanung · 48, 85, 86

U UML · 22, 23 Unternehmen funktionsorientierte · 27 prozessorientierte · 28 Unternehmensanalyse · 49 Unternehmensarchitektur · 73 Unternehmensklassifizierungen · 27 Unterstützungsprozesse · 19, 53, 54, 60, 66, 76, 80

V VD · 87 Vollkostenrechnung · 57, 65

W Wertschöpfung · 53, 54, 76 Wertschöpfungsaktivitäten · 52 Wertschöpfungsanalyse · 54 Wertschöpfungsanteil · 19 Wertschöpfungskette · 52, 53, 54, 60, 62, 69, 82, 83, 87, 88 Wertschöpfungskettenanalyse · 52, 60, 76, 88

99