Gyors történeti áttekintés
2000
'90
'80
'60
'70
Accounts payable
Accounts receivable
MRP II.
HRMS
ERP
CRM, APS, MES, E-commers,
??? → CMR, CEM, ...
IBM
SAP
J D Edwards
Baan
Oracle
PeopleSoft
Siebel
!!! INTERNET !!!
salesforce.com
SFA, BPM, MIS
General ledger
MRP
Gomba mód
szaporodnak a betűszavak
Aki végigment ezen az úton,
annak valahogy így néznek ki a
cégében az IT támogató rendszerei
Aki tovább szeretne lépni, annak általában "integrálnia" kell, akár egy új rendszer bevezetéséről, akár egy régi továbbfejlesztéséről van is szó...
Na de mi a jó megoldás?
Az IT fejlesztések bevezetőinek élete nem egyszerű, de legalább bonyolult!
Nyilván nem véletlen a rengeteg "bukott" projekt...
A statisztika elég "lehangoló"
"51 % értékelte az ERP implementációt sikertelennek"
2001 - The Robbins-Gioia Survey

"a projektek 40 %-a a bevezetés lezárását követő egy év múlva sem érte el a kitűzött üzleti célját"
"az implementációs költségek átlagosan 25 %-kal lépték túl a költségvetést"
2001 - The Conference Board Survey

"az utólag elemzett projelktek több, mint 61 %-át értékelték sikertelennek"
1997 - The KPMG Canada Survey

"a projektek 31 %-át még befejezésük előtt törölték"
"53%-uk pedig a tervezett költségek közel háromszorosába került"
1995 - The Chaos Report by the Standish Group

"az üzleti IT projektek közül a CRM-ek buknak a legnagyobb arányban"
2007 - CRMBuyer.com
A bukások okai:
Klasszikus projektmenedzsment problémák
IT / CRM fejlesztésre jellemző specialitások
Bukott CRM projektek aránya:
2001 Gartner Group: 50%
2002 Butler Group: 70%
2002 Selling Power, CSO Forum: 69.3%
2005 AMR Research: 18%
2006 AMR Research: 31%
2007 AMR Research: 29%
2007 Economist Intelligence Unit: 56%
2009 Forrester Research: 47%
Michael Krigsman - ZDNet
IT specifikus hibák
Az üzleti igények nem tiszták
Üzleti oldal vezetése nem elkötelezett
Nem vonják be a felhasználókat
Hiányzó, vagy silány követelmények
Elmaradó tesztelés
Csúszó, vagy hiányzó hibajavítás
Gyors technológiai fejlődés (mire elkészülne, már nem érekes)
PM specifikus hibák
Túl távoli, vagy irreális határidő
"Mozgó cél"
Változáskezelés gyengesége, hiánya
Kivételkezelés elégtelensége
Erőforrás hiány
Projekttervezés hiánya
Kommunikációs hiányosságok
Túlzott elvárások
Költségek alábecslése
Kulturális különbségek
Sokféle rendszer,
szigetszerű működés
Tanulságok (?)
Minél újabb és dinamikusabb egy üzleti terület;
annál kevéssé létezik kiforrott, "iparági" megoldás,
annál nagyobb az igény az "egyedi" rendszerekre,
annál fontosabb, hogy a rendszer az ügyfél-kiszolgálás teljes folyamatát támogassa,
annál fontosabb, hogy a felhasználók bevonásával készüljön (a tervezéstől a fejlesztésen át a tesztelésig) a bevezetendő rendszer
annál kevésbé alkalmasak a klasszikus projekt-menedzsment módszertanok a bevezetések során
Nem mindegy, hogy
mennyire bonyolult a rendszer
Minél régebbi és stabil egy üzleti terület;
annál könnyebb olyan "kész" rendszert találni, ami nagyon nagy valószínűséggel éppen jó lesz
annál nagyobb kockázatot jelent minden olyan elem, ami eltér az "iparági standard" világától
annál valószínűbb, hogy a bevezetett rendszertől sem kell nagyfokú rugalmasságot elvárni (jövőre is jó lesz az úgy, ahogy most bevezetjük...)
annál egyszerűbb a rendzser bevezetését egy rutinos projektmenedzsmentre bízni (akiknek már tapasztalatuk is van hasonló bevezetésekben)
?
A helyzet nem könnyű.

Nagy az esély a bukásra!
Nem mindegy, hogy
"MOL", vagy "ZAPPOS"
Nem mindegy, hogy a fejlsztés
"Termék", vagy "Szolgáltatás"
Minél egyszerűbb az üzleti folyamat, amit támogatni kell;
annál egyszerűbb lehet a rendszer, amit be kell hozzá vezetni,
annál gyorsabb fejlesztés,
annál rövidebb integráció,
annál gyorsabb lehet a bevezetés,
annál egyszerűbb a testre szabás
... folytassuk!
annál kevésbé van szükség a klasszikus értelemben vett projekt-menedzsment módszertanok használatára
Minél bonyolultabb a támogatandó üzleti folyamat;
annál összetettebb lehet a rendszer,
annál nehezebb és drágább a testre szabás,
annál valószínűbb, hogy a beveztés során sok lesz a CR
... folytassuk!
annál fontosabb lehet valamilyen projekt-menedzsment módszertan alkalmazása a bevezetés során
Minél inkább tekinthető a fejlsztés egy "termelési" folyamatnak;
annál jobban kell a pontos specifikáció (pontos termék-terv)
a legyártott termék átadása után annál kevésbé van "folytatás"
... folytassuk!
annál valószínűbb, hogy a bevezetés is "projekt szerűen" fog történni
Minél inkább tekinthető a fejlesztés egy szolgáltatásnyújtásnak;
annál kevésbé lehetséges (és szükséges) 100%-os specifikációt adni ELŐRE,
annál nehezebb a teljesítést időpillanathoz kötni,
... folytassuk!
annál kevéssé értelmezhető a "bevezetési projekt" úgy, mint egy egyszeri tevékenység, aminek definit vége van