Basic HTML-Version
CM
Controller magazin
2/07
CONTROLLING
IN DER SOFTWARE–
ENTWICKLUNG
Dipl.-Betriebswirt
Dipl.-Informatiker
Alfred BezIer
Sebastian Popescu
beide bei GIB Dr.-Ing. Greiner Ingenieurberatung, München
von Alfred BezIer, Augsburg, und Sebastian Popescu, Münclien
Die Boom-Zei ten der „New Economy"
sind längst vorbei . Möch t e ma n dennoch
kommerz iel le Sof tware erfolgreich pro–
duzieren und im Wet tbewerb langfristig
bestehen, muss man - wie in al len ande–
ren Wi rtschaf tsbereichen - in der l^age
sein, ein Produkt durch eine gesicherte
Arbei tsweise mi t mi n ima l em Aufwand,
kurzen Produkt ionszei ten sowie einer
hohen Qual i tät herstellen zu können.
Dieser Er fahrungsber i cht zeigt keine
verbindl iche Lösung. Auf der Basis von
Best-Practice Erfahrungen werden orga–
nisatorische St rukturen, Me t hoden und
Prozesse vorgestellt, die sich beim Aufbau
eines „Controlling in der Software-Ent–
wicklung" bewähr t haben .
1. CONTROLLING IN EINER SOFTWA–
RE-ENTWICKLUNG
Control l ing verstehen wi r übergreifend
als ein permanentes Messen - Prüfen
- S t eue r n a l l er ( k o s t e nw i r k s ame n )
Prozesse. Daher leistet ein Control l ing
in unserem Sinne neben der kaufmän–
n i schen En t sche i dungsvo r be r e i t ung
auch organisator ische Unt ers tüt zung
und Coaching während des gesamten
Herstel lungsprozesses. Der Übergang
zu einem „steuernden Projektmanage–
ment " ist bei einigen organisatorischen
Tei laufgaben f l i eßend . Zent ra l es Ziel
bleibt es aber, die ertragswirtschaft l ichen
Chancen des Software-Herstellers positiv
zu beeinf lussen' .
Es bedarf detai l l ierter Prozesskenntnisse
in der Sof tware-Entwicklung, um nicht
nur st rategische Entsche idungen als
das „ökonomische Gewissen" beglei ten
zu können. So unterstützt der Controller
im Team mi t dem Entwicklungslei ter und
Produktmanager(n) den wirtschaft l ichen
Herstel lungsablauf und dient in der täg–
lichen operat iven Arbei t als „Lotse", der
im gesamten Herstel lungsprozess den
Überbl ick wahr t .
2. ORGANISATORISCHE RAHMEN–
BEDINGUNGEN
Bevor ma n über geeignete Controlling-
und Organ i sa t i onsmaßnahmen nach–
denkt , gilt es den Ist-Zustand der zu
untersuchenden Sof tware-Unternehmen
zu analysieren. Mi t Fragen nach der lang–
fristigen Entwicklungsplanung, dem Ab–
arbei tungsstau von Anforderungen, der
Wartungsintensi tät eines Produktes, dem
prozentualen Antei l der Neuentwicklung
oder d em Kundensegment verschafft
ma n sich einen gezielten Überbl ick. Erst
dann lassen sich geeignete aufbau- und
ab l au f organ i sa t or i sche M a ß n a h m e n
erarbei ten:
2.1. Aufbauorganisatorische Rahmen–
bedingungen
Das Produzieren von Software ist durch
seine „Einzigartigkeit" geprägt. Es gibt
keine absolute Wiederholung. Keine Pro–
grammzei le wi rd zweimal geschrieben.
Allein aus dieser Tatsache ergibt sich,
dass die Art der Herstellung prinzipiell in
Form einer reinen Einzelfertigung erfolgt.
Für den Herstel lungsprozess bedeutet
dies, dass sich eine Vielzahl unterschied–
licher Stellen oder Beteiligte parallel in
einer logischen Produktlinie entwickeln.
Aufbauorganisatorisch empfiehlt es sich,
diesen Herstellungsprozess in einer flachen
Kompetenzstrukturmi t wenigen hierarchi–
schen Ebenen abzubi lden. Überlagert wird
diese Basis-Struktur durch eine parallele
Projektorganisation. Dies bedeutet, jeder
Mi tarbei ter hat genau einen disziplinari–
schen Vorgesetzten und ist organisatorisch
in mindestens ein Projektteam integriert.
Die Projektorganisation ist zugleich Voraus–
setzung für eine geordnete Mehr-Produkt-
Entwicklung.
2.2. Ablauforganisatorische Rahmen–
bedingungen
Verschiedene nat ionale und internat io–
nale Gremien^ haben für das normier te
und phasenor i en t i e r t e Vorgehen bei
der Sof tware-Entwicklung anerkannt e
Regelwerke für den sog. Sof tware Life
Cycle (Lebenszyklus) entwor fen. In diesen
Model len werden u.a. die wechselseitigen
Beziehungen zwischen den einzelnen
Teilphasen sowie die verbindl ichen Ab–
arbei tungsreihenfolgen festgeschrieben.
Nach der Disziplin der Phasenfolge lassen
sich zwei prinzipiel le Gruppen an Vorge–
hensmodel len unterscheiden:
147