Basic HTML-Version
CM Controller magazin 2/07 - Alfred Bezler / Sebastian Popescu
und i<ostenrelevanten Entscheidungen
hinterfragen. Abgesehen von Manage–
ment fehl ern, wenn beispielsweise die
eingesetzten Ressourcen weder qual i–
tat iv noch quant i tat iv in der Lage sind,
die Anforderungen zu erfül len, liegt der
häuf igste Grund fiJr die fast schicksalhaft;
h i ngenommenen Zielabweichungen bei
den restlichen 71 % der Soft;ware-Projek-
te an der „Unsicherheit". Es wi rd zwar
entwickel t , aber
-
ma n kennt noch nicht alle Anforde–
rungen des Kunden,
-
ma n setzt zu früh neue Technologien
ein,
-
ma n ist von den Wechse lwi rkun–
gen einzelner Programmtei le über–
rascht.
In einer dr i t ten Analyse der Personal–
kosten wi rd ein Blick auf die sog. „schlei–
chenden Anforderungen" geworfen. Dies
sind Anforderungen und Wünsche zu Soft;-
ware-Eigenschaften, die erst nach Projekt–
beginn bekannt wurden und „noch eben
ma l schnell" mi tentwickel t werden sollen.
Die Gründe fiJr diese Anforderung liegen z.
T in einer mangelnden Systemanalyse, in
geänder ten Aufgabenstel lungen, neuen
EDV-Umgebungen usw. |e nach Dynami k
des Umfelds können diese „schleichenden
Anforderungen" monat l ich zwischen 2
bis 5 % desGesamtumfangs ausmachen.
Bei Projekten mi t einer geplanten Dauer
von einem |ahr und mehr kann sich somi t
der Entwicklungsaufwand um die Häl fte
steigern. Zwar gehören Änderungen zum
Projektal ltag, dennoch ist - insbeson–
dere mi t den Kunden - ein geregeltes
Anforderungs- und Freigabever fahren
zu organisieren. Andernfal ls läuft man
Gefahr, dass durch ständig neue Anfor–
derungen ein Projekt nie abgeschlossen
werden kann.
3.2. Zweite Phase: Implementierung
Die zei t intensivste Phase ist die Imple–
ment i erung ( - P r og r ammi e r ung ) . Hier
setzen die Implement ierer (~ Software-
Entwickler) die Ergebnisse und Vorga–
ben der Systemanalyse in ablauf fähige
Programme um. ]e nach Branche, Pro–
dukt-Portfol io oder Innovat ionsgrad des
Unt ernehmens setzt sich diese Arbei t
meist aus e i nem gesunden M i x aus
Neuentwicklung sowie systemat ischer
Wa r t ung und Pflege der bestehenden
Anwendungen zusammen .
Technisch ist das Arbei ten in der Im–
plement ierung i.a. durch
firmeninterne
Richt l inien und / oder Programmier –
konvent ionen geregelt. Aber aus wirt–
schaftlicher Sicht gibt es häuf ig Mög–
l ichkeiten zur Opt imierung, z. B. in der
Wahl der Teamgröße. So verhäl t sich die
Produkt ivi tät des einzelnen Impl emen–
tierers reziprok zur Größe des Entwick–
lungsteams . Es empf i ehl t sich daher,
kleine, selbststeuernde Arbei tsgruppen
zu bi lden, die in einem formal isierten
Reporting (z. B. Ticketsystem) mi t anderen
Entwicklungsgruppen und der -leitung
kommuni z ieren. Ergänzend zudieserauf -
bauorganisatorischen Maßnahme lassen
sich gezielt wei tere Kosteneinsparungen
finden. So sind u. a. folgende Arbeitsstra–
tegien durchaus im Gespräch:
3.2.1. Zukauf von Software-Komponenten
(von Drittherstellern)
Bereits bei der Model l ierung von Soft–
ware versucht ma n , Funkt ionen, Pro–
zeduren und Programmtei le mögl ichst
p r oduk t neu t r a l zu ha l t en , um diese
Komponenten in wei tere Produkte in–
tegrieren zu können. Sof tware-Häuser
unterhal ten häuf ig große Libraries (Pro–
gramm-Bibl iotheken) für die Samml ung
selbstentwickel ter Komponen t en . Bei
einer Neuentwicklung lassen sich diese
Programmte i l e wi e Bausteine zusam–
mensetzen und in neue Appl ikat ionen
integrieren.
Neben diesen selbsterstel l ten Kompo–
nent en geht der Trend unter d em Stich–
wo r t CBSE ( componen t based Sof tware
engineer ing) zur dynami schen Einbin–
d u n g ( e nb e dd e d Sys t ems ) f r emd e r
Modu l - , Klassen- oder Funkt ionsbibl io–
theken . Bei geschäf tskr i t ischen ITPro–
j ek t en oder we n n ma n Proj ekt z i e l e ,
Termine und Budgets exakt e inha l ten
muss , wi rd bei einer „Make-or -Buy"-
Entscheidung häuf ig der Einsatz dieser
D r i t t k ompon e n t e n favor isier t . Me i s t
un t e r schä t z t ma n j edoch die d am i t
ve rbundenen Risiken der Produkthaf –
t ung , War tbarke i t , I nkompa t i b i l i t ä t und
negat i ven Wechse lwi rkungen zwischen
den unterschi edl i chen Komponen t en
verschiedener Herstel ler
3.2.2. Zukauf von Entwicklungsleistungen
(Outsourcing)
Parallel zurn Zukauf von Software-Kom–
ponenten empf iehl t sich das Outsourcing
vol lständiger Programmpakete . Dienten
bei der vorangestel l ten Make-or -Buy-
Entscheidung nur die Produktkosten als
Vergleichsmaßstab, sind beim Outsour–
cing sowohl Produkt- als auch Struktur–
kosten zu berücksicht igen.
Neben Indien sind es vor al lem ITFi rmen
aus den Ländern des ehemal igen Ost–
blocks wi e Rumän i en , Bulgarien oder
der Ukraine, die mi t maßgeschneider ten
Offshore-Dienstleistungen für wesdiche
Software-Häuser aufiwarten. Das Gehalts–
niveau in diesen Ländern liegt deut l ich
unter unserem Standard. So lassen sich
beispielsweise bei gleicher Anzahl der
Beschäf t igten nachha l t i ge Kostenein–
sparungen erzielen oder bei gleichem
finanziellen Aufwand die t ime- to-market -
Zei ten deut l ich reduzieren.
Der Controller sollte als das „ökonomische
Gewissen" des Unternehmens auch die
Risiken des Outsourcing kritisch hinter–
fragen, zuma l der Kommunikat ions- und
Koordinat ionsaufwand überproport ional
ansteigt und die Einarbeitungszeit sowie
die Fehlerquote von „alleine gelassenen"
Entwicklern zu einem spürbaren Kosten–
block werden können. So zählt es u. a.
zu seinen Aufgaben, darauf hinzuwi rken,
dass durch den alleinigen „Zukauf" von
Entwicklungsleistungen die strukturel len
Probleme im Mut t erhaus nicht gelöst
werden können. Vielmehr sollte man die
Global isierung als langfrist ige Chance
erkennen, die erst nach erheblicher An-
schubfinanzierung zu einem Leistungsfak–
tor im Unternehmen werden kann.
Betreibt ma n das Outsourcing als firmen–
politische Zielsetzung, ist die operat ive
Zusammenarbe i t mi t den „Externen" zu
organisieren. Wurden früher Outsourcing-
Projekte als reine ' remote' Entwicklungen
geführt , empf iehl t es sich, die externen
Kräfte - trotz all der kleinen Schwierigkei–
ten wie Zei tverschiebung und Sprachdif–
ferenzen - vol lständig in das Projekt team
zu integrieren.
In d i e s em Z u s a mm e n h a n g we r d e n
klein- und mi t telständische Unterneh–
me n (KMU) e r s tma l s mi t der Frage
konf ront ier t , ob man Englisch als (a)
Unternehmenssprache , (b) generel l in
der Entwicklungsabtei lung oder (c) nur
für ausgewähl te Spezifikationen einführt .
Die Antwor t ist als eindeut iges Signal fiir
die Bedeutung und Ernsthaftigkeit sowie
auf die strategische Ausr ichtung des Un–
ternehmens in Sachen Outsourcing und
Internat ional isierung zu wer ten.
150