Seite 90 - 2000-04

Basic HTML-Version

C o n t r o l l e r
magazin 4/2000 - Al f red Biel / Birgit Hei lmann / Thomas Schaumburg
und darüber hinaus im Geschehen des
jeweiligen Softwareprojektes. Vordiesem
Hintergrund lassen Sie uns bitte die ein–
gangs gestellte Frage etwas vertiefen. Es
geht offenbar einerseits um das Ergeb–
nis, z. B. die Erfüllung der Anforderungen
der
GoBS
(Grundsätze ordnungsgemä–
ßer DV-gestützter Buchführu ngssysteme)
und andererseits um die Prozesse, die zu
diesem Ergebnis führen.
K P M G :
Genau dieser Aspekt ist von
besonderer Bedeutung; denn es zeigt sich
immer wieder, dass es nicht der Inhalt
der Prüfungsfeststellungen zu den DV-
Systemen ist, der vom Mandanten
als
ärgerlich emphjnden wi rd. Ganz im Ge–
genteil; nicht selten werden sie auch als
Potentiale zur qual itativen Verbesserung
wahrgenommen. Dass diese Feststellun–
gen dennoch Gegenstand kontroverser
Diskussionen sind, hängt vielmehr da–
mit zusammen,
dass sie auf produk t i ve
DV-Systeme abz ielen, die nach mehr
oder mi nde r mühsel i ger Projektarbei t
i n Betr ieb genommen wu r d e n u n d die
n i emand meh r ände r n möchte.
Inso
fern ist ein Eingriff ab diesem Zei tpunkt
häufig höchst unwi l lkommen. Daher ver–
folgt die PPB durchaus den richtigen An –
satz,
f rühzei t ig, d. h. ab der Pf l ichten-
hef terstel lung
und darüber hinaus in
al len Phasen , in denen r echnungs –
legungsrelevante Inhalte und Abläufe
festgelegt werden bzw. über ihre Richtig–
keit befunden wi rd, die Normen der
GoB
u n d GoBS
in das Projekt einzubr ingen.
Damit ist zwar sichergestellt, dass ent–
sprechende Anforderungen Eingang in
die Konzeption finden, nicht jedoch die
optimale Umsetzung. Hierzu darf sich
die PPB nicht nur als mahnende Instanz
verstehen, sondern sie ist auch aufgeru–
fen, konkrete Realisierungsvorschläge für
die von ihr vertretenen Anforderungen
zu
unterbreiten und beispielsweise zu
beschreiben, wie die Ordnungsmäßigkeit
einer Schnittstel lenverarbeitung praxis–
gerecht überwacht werden kann oder
wie ein Test konkret gestaltet werden
muss. Neben diesen eher technischen
Fähigkeiten muss die PPB ein wachsa–
mes Auge für das interessengesteuerte
Spannungsfeld haben, das zwischen den
Projektakteuren entsteht und das Projekt–
ergebnis nicht unwesentl ich beeinflusst.
Nicht selten kommt es bei Softwareein–
f ü h r u n g s p r o j e k t e n
z u
B l ockade –
si tuat ionen, die daraus resultieren, dass
die Fachabtei lungen primär eine Fortfüh–
rung des Status-Quo in den Prozessen
und Systemen anstreben, während die
Einführungsberater bevorzugt die Lösun–
gen reproduzieren möchten, die sie in
vorangegangenen Projekten bereits er–
folgreich realisiert haben. Hier muss der
PPB moderierend dazu beitragen, dass
anstelle subopt imaler Lösungen das Be–
ste aus den verschiedenen Ansätzen ge–
wähl t wi rd. Ggf. muss er auch Alternati –
ven aufzeigen. Dieses darf allerdings nur
in Ausnahmefäl len passieren, um die
Unabhängigkeit des Wirtschaftsprüfers
und die für eine objektive Beratung ge–
bührende Distanz zum Projekt zu wah–
ren, und nicht zuletzt, um Kompetenz–
streitigkeiten zu vermeiden.
C M :
Untersuchungen sprechen davon,
dass die häufig beklagten Probleme mit
der Softwaresicherheit zu einem erhebli–
chen Teil schl ichtweg Kommunikations–
probleme darstellen.
K P MG :
Damit sprechen Sie einen emi –
nent wicht igen Punkt nicht nur für die
Einführung von Software, sondern auch
für ihren Betrieb im Produkt ivumfeld an.
Während wi r der Auffassung sind, dass
in vielen Standard-Softwarepaketen heut–
zutage eine an sich hohe funktionale
Verarbeitungsstabilität realisiert werden
kann, von der Betreuung im Fehlerfall her
ein hohes Maß an Sicherheit gewährlei –
stet ist und auch die Anforderungen des
Berechtigungsschutzes zufriedenstellend
lösbar sind, resultieren zahlreiche Fehler,
Sicherheitslücken und letztlich Risiken
aus
Kommun i ka t i on s de f i z i t en z w i –
schen den Pro i ekt - „Stakeho l dem" i n
der Imp i ement i erungsphase , die s ich
i n der Bet r iebsphase for tsetzen.
Diese
treten im übr igen um so stärker auf, je
geringer die Integration zwischen einzel–
nen Bestandteilen einer DV-Landschaft
ist und desto mehr Schnittstellen erfor–
derl ich sind. Hier gilt es erfahrungsge–
mäß. Brücken zwischen den typischer–
weise betroffenen Bereichen Logistik und
Rechnungswesen und zwi schen den
Fach- und DV-Abtei lungen zu bauen.
Ein
festes Fundamen t für diese Kommun i –
kat ion b i l den Prozessana l ysen u n d
- beschre i bungen ,
da nur sie es ermög–
l ichen, Abläufe zu validieren und Lücken
zu identifizieren. Vor allem wi rd anhand
einer Prozessbeschreibung schnel ler
deutl ich, welche Auswi rkungen die Ver–
änderungen auf angrenzende Bereiche
haben. Die in der Praxis übl icherweise
s t a t t f i ndenden
Ge sp r äche
übe r
Datensatzformate, Feldinhalte usw. sind
zwar zu einem best immten Zeitpunkt
erforderlich, reichen dagegen nicht aus,
um dem Control ler die Abläufe in der
Produkt ion nahezubr ingen und umge–
kehrt. Ein stabiles, in sich schlüssiges
System kann daraus nicht entstehen.
Insofern sollten bei einem Prüfer bei feh–
lenden Prozessdokumentat ionen früh–
zeitig die „Warnl ichter" aufleuchten.
C M :
Sie haben die Chance, in einem
Softwareprojekt stabilisierend zu wi rken.
Aber besteht nicht auch die Gefahr
zu –
sätz l icher Reibungsver luste?
Geraten
Sie nicht zwangsläufig in ein konfliktäres
Spannungsverhäl tni s gegenüber dem
jeweiligen Systemhaus, dem Projektlei–
ter und anderen Beteiligten? Auch der
Koo r d i na t i ons - u n d A b s t i mmu n g s –
aufwand steigt zwangsläufig. Wie sieht
es aus, wenn z. B. in einer Tochtergesell–
schaft eines Konzerns auch noch andere
Prühjngsorgane auftreten? Wie hält man
die Balance, dami t der Nutzen deuüich
überwiegt?
K P MG :
Eine nutzenstiftende Durchfüh–
rung der PPB ist in der Tat - um Ihre
Metapher aufzugreifen - teilweise ver–
gleichbar einem Drahtsei lakt . Dieses
hängt allerdings weniger mit einer zu
starken Einmischung in die „operative"
Projektabwicklung denn dami t zusam–
men, dass die Anforderungen, die
aus
der PPB an die Projektteilnehmer (Pro–
jektleiter, interne Fachabtei lungen, ex–
terne Berater) herangetragen werden, als
Fremdkörper emphjnden werden, die die
Projekte vor allem in „heißen" Projekt–
phasen unnöt ig belasten. Umso wicht i –
ger ist es daher, mit der PPB frühzeitig zu
beginnen und deren normat ive Ansprü–
che bereits in der Konzeptionsphase ein
z u b r i n g e n . A l l geme i n i st es auch
uner fässl ich, f rühzei t ig klarzustel len,
dass die PPB weder bestrebt ist, die fach–
liche Konzeption inhaltlich zu beeinflus–
sen, noch deren DVtechnische Umset–
zung. Sie ist eine
E r gänzung be i der um
die GoB- /GoBS-Aspekte
und trägt nicht
selten dazu bei , die späteren unverzicht –
baren Verarbei tungsprüfungen (z. B. Ab–
stimmung von Schnittstellenprotokollen)
ergonomischer und damit zeitsparender
zu gestalten. Auch führt die
Betonung
der Anwende r schu l ung u n d Dokumen –
tat ionsbedür fni sse
dazu bei , die mit ei–
ner Softwareeinführung angestrebten
Rat ional isierungs und Opt imierungs –
effekte tatsächlich zu realisieren. Gepaart
mit der zuvor genannten Mögl ichkeit,
372