Basic HTML-Version
CM Controller magazin 2/03 - Thomas Schaumburg / Andreas Dassen
entwicklung möglich, die Werte für akti–
vierte Overheadkosten entweder auf den
verrechnenden Kostenstellen oder den
imWege der innerbetrieblichen Leistungs–
verrechnung belasteten Fertigungsauf–
trägen abzugreifen und auf speziellen
Konten zwecks Ausweis im FI-SL zu ver–
buchen (eine ähnliche Vorgehensweise
wird in anderem Zusammenhang bereits
praktiziert). Als effizienter erwies sich aber
eine Lösung unter Nutzung des
Abstimm–
ledgers.
Aus dem Abstimmledger her–
aus werden CO-interne Wertflüsse auf
speziellen Konten nachgebucht (soweit
sie im FI-SL zu Veränderungen der
Ergebniszeile führen - oder technisch
ausgedrückt: bei Wechsel des Funktions–
be r e i chs ) . Indem für den Vorgang
„Bezuschl agung
von
Fert igungs–
aufträgen" ein eigenes Abstimmkonto
eingerichtet und im FI-SL-Bericht separat
ausgewertet wurde, lassen sich die akti–
vierten Overheadkosten komfortabel
identifizieren und aus der Ergebnis–
darstellung eliminieren.
Aus der Vielzahl zur Verfügung stehen–
der I ns t rumen t e werden bei SIG
Combibloc vor allem die folgenden ge–
nutzt:
• Direkte Zuordnung von Konten oder
Kontensets zu Ergebniszeilen;
• Eine Subst i tut ion mit knapp 3 0
Schritten;
• Eine Regel;
• Rechenoperationen im Report Painter
Bericht, um informatorische Werte,
die vor dem Betriebsergebnis wieder
freifallen, auszuweisen.
Selbstverständlich ergeben sich aus den
technischen Rahmenbedingungen diver–
se organisatorische Rückwirkungen.
So ist z. B. sicherzustellen, dass eine
direkte Kontenzuordnung nicht durch die
Zuordnung eines CO-Objektes „über–
schrieben" wird. Analog dem seit länge–
rer Zeit angewandten einhei t l ichen
Kontenplan für die gesamte Gruppe galt
es gruppenweit die Zuordnung von Sach–
konten zu primären Kostenarten zu über–
prüfen und ggf. zu bereinigen. Darüber
hinaus war diese Analyse Anlass, zahlrei–
che historisch gewachsene Kostenarten
zu eliminieren.
Ähnlich bedeutend sind CO-Objekte wie
Kostenstellen, Aufträge oder PSP-Elemen-
te für das Umsatzkostenverfahren. Für
die Funktionsbereichszuordnung, welche
den Wertfluss in eine bestimmte Ergebnis–
zeile steuert, wurden keine Stammdaten–
einträge vorgenommen. Stattdessen er–
folgt die Ableitung über die Substitution,
welche im Kern als Abfolge von Wenn-
Dann-Beziehungen beschrieben werden
kann (sprich: wenn Kostenstellenart x,
dann
Funkt i onsbere i ch
y). Zu–
ordnungsmerkmale sind dabei z. B. die
Kostenstellenart, die Auftragsart oder
bestimmte Stellen der PSP-Bezeichnung.
Der Wunsch nach einer möglichst ein–
fachen Gestaltung der Substitution war
deshalb z. B. Anlass, die Anzahl der
Gemeinkostenauftragsarten zu minimie–
ren und deren gruppenweit einheitliche
Verwendung sicherzustellen.
Die Verwendung einer einzigen Substitu–
tion für alle beteiligten Unternehmen
beinhaltet selbstverständlich auch, dass
jegliche Änderung auf ihre Rückwirkun–
gen in anderen Gesellschaften zu über–
prüfen ist. Konsequenterweise wurde die–
se neu hinzugekommene Aktivität von
vorne herein als zentral wahrzunehmen–
de Aufgabe eingeführt. In gleicher Weise
wird mit der Pflege des gruppenweit ver–
wendeten Berichts zum Umsatzkosten–
verfahren umgegangen. Ein Änderungs–
bedarf entsteht hier primär bei sich ver–
ändernden Reportinganforderungen. Da
diese in gleicher Weise für alle Unterneh–
men Gültigkeit haben, werden auch An–
passungen des Berichtswesens zum
Umsatzkostenverfahren zentral vorge–
nommen. Als positiver „Nebeneffekt" er–
gibt sich daraus, dass
SAP seiner Funk–
tion als „Organisationswerkzeug"
wie–
der einmal gerecht wird - durch die zen–
trale Pflege in einem allgemein genutz–
ten Instrument lassen sich Veränderun–
gen der Rechnungswesenr icht l inien
selbstverständlich deutlich effizienter
umsetzen, als bei mehreren stand-alone
Systemen oder gar manueller Datenauf–
bereitung.
Es versteht sich von selbst, dass auch für
ein weitgehend im Hintergrund laufen–
des Modul wie FI-SL nicht jeder Schritt
automatisiert oder zentralisiert werden
kann. Um dennoch an kritischen Stellen
eine hinreichende Robustheit sicherzu–
stellen, wurden darüber hinaus diverse
ABAP-Lösungen zur Überprüfung der
Datenpflege im System entwickelt. So
wird z. B. das Vorhandensein eines zur
Steuerung der Wertflüsse unedässlichen
Stammdateneintrags in Modul PS täg–
lich automatisch überprüft und ggf. für
neu hinzugekommene PSP-Elemente
eine Fehlermeldung erzeugt , wenn
solche Einträge fehlen.
7 PRODUKTIVERFAHRUNGEN
Allgemeiner
going-live Termin
für das
HB II Projekt war der 1 . 1 . 2002 . Die diver–
sen neu eingeführten Lösungen lassen
sich im Hinblick auf den Produktivstart
in zwei Gruppen einteilen:
^ Funktionalitäten des Tagesgeschäfts,
die ab dem 1 . 1 . 2002 veriässlich an–
wendbar sein mussten,
^ Abschlussinstrumente, für die der
Monatsabschluss Januar 2002 das
due date darstellte.
Bei SIG Combibloc wird FI-SL als
on-line
Instrument
eingesetzt. Entsprechend
musste das Modul ab dem 1.1.2002
funktionsfähig sein. Sowohl zur Sicher–
stellung dieser Anforderung als auch zur
Vermeidung unerwarteter Probleme im
Rahmen der parallel erfolgenden Jahres–
abschlusserstellung (Erweiterung der In–
tegration im System um ein komplett
neues Modul!) erfolgte die technische
Produktivsetzung von FI-SL bereits Ende
November 2 0 0 1 . Dieser frühe Aktivie–
rungszei tpunkt erlaubte es darüber
hinaus, die Einstellungen im FI-SL unter
den realistischen Bedingungen des Tages–
geschäf t s zu überprüfen - der alte
„Grundsatz", dass das Produktivsystem
immer noch die beste Testumgebung
darstellt, konnte auf diese Weise komfor–
tabel und gefahrios angewandt werden.
Ernst wurde es dann ab dem 1. Januar
2002 : Während der ersten Wochen des
Produktivbetriebs erfolgte eine tägliche
Überwachung der Wertflüsse durch das
Projektteam. Dabei diente insbesondere
das nunmehr ebenfalls im Produktiv–
be t r i eb bef indl i che Gesamtkos t en–
verfahren nach lAS als Vergleichs–
maßstab. Auftretende Fehler im Wertfluss
wurden täglich an die jeweilige Fach–
abteilung kommuniziert und zeitnah be–
hoben. Dabei wurde die Lösung nicht in
später schwer nachvollziehbaren „An–
passungsbuchungen" gesucht. Vielmehr
galt es, die originäre Korrektheit der Da–
ten sicherzustellen. Praktisch bedeutete
dies , den fehl erhaf t zugeordne t en
Geschäftsvorfall zu stornieren, die Ein–
stellungen im FI-SL oder Vormodulen zu
korrigieren und den Vorgang erneut ein-
zubuchen. Möglich war diese extensive
146