Prosjektstyring, metodikk og løsningsutforming for

Prosjektstyring, metodikk og
løsningsutforming for SAP
prosjekter
Sveinung Gehrken
Fram
Til diskusjon
• Hva kjennetegner vellykkede SAP prosjekter?
• Hvilken metodikk skal man velge?
• Noen tanker om løsningsvalg
Vellykkede SAP prosjekter
Er det så vanskelig da?
(Kompetanse – Ledelse – Fokus – Samarbeid)
• Team
• Prosjektledelse
• Endringsledelse
• Forankring
• Forventninger / innsalg / kontraktsform
• 3. parts støtte
• Ikke overvurder Best Practice mm. Ikke
undervurder personlighet, erfaring og
kompetanse.
Check?
• Fokus på forretningsprosesser og krav først
• Sørg for å oppnå en høy
ROI
• God prosjektleder og et
sterkt team (internt/ext.)
• Ledelsen er engasjert og
org. involvert
• Som kunde ta kontroll og
planlegg godt
• Fokus på gjennomføring
• Opplæring og
endringsledelse
• Hvorfor implementerer vi
SAP?
• Konservativ og
konsekvent
• Demo og konkrete forslag
• Kommunikasjon
• Bruk 3. parts kompetanse
Metodikk
• Beste metodikk?
– Flinke folk!
• SAP metode – Forvirret?
– ASAP, ASAP Focus, Value, Agile, AIO
Trad- ASAP vs. agile
• Hva kan man gjøre uten blueprint?
• Core ERP vs. Frontend, BI, Development
• Salgsmetodikk vs. Reell metodikk?
– Redusere tid/kost også etter kontraktsignering
• Erfaring vs. prøvekanin
Myter
• Svaret på raske implementeringer er
agile/smidig.
• SAP implementeringerer er rigide og er basert
på en ren fossefallsmetode.
Agile
Sammenligning fossefall vs. Agile
Fossefall
• Meget strukturert impl.
prosess. Krav, analyse,
design, kode/konfig, testing.
• Oppfølging på tid, Kost og
omfang.
• Hver fase har egne signoffs.
• Framdrift måles mot klart
definerte leveranser for
hver fase.
Agile
• Nedbrytning til mindre
oppgaver (time-boxed)
• Potensiellt flere iterasjoner
• Teamene er samlokalisert og
Self-Organized
• Ok med endrede krav
• Begrense dokumentasjon
• Framdrift måles opp mot
fungerende komponenter /
produkter/delprosesser med
systemstøtte.
Agile pro/cons
Utfordringer
Gevinster
• Komplekse prosjekter med
dataflyt på tvers av SAP.
• Bransjer med egne krav til
dokumentasjon (f.eks. FDA)
• Når SAP er en del av
omfattende planlegging
/strategiske endringer.
• Fysisk adskilte teams
• Krever høy erfaring og
komptanse.
• Krever omfattende
beslutningsevne/vilje
• Vanskelig på større
nyimplementeringer.
• Fokus er på å
bygge/konfigurere løsninger /
systemstøtte
• Forenkling og kutt i det
unødvendige
• Synlig framdrift
– Mindre pakker / time boxed
– Sjekker ofte
– Framdrift måles etter
fungerende komponenter /
programmer / løsninger som
• Fleksibilitet
– Pga. mindre leveranser
Hybrid
Akselleratorer
Noen tanker om metodikk og
prosjektledelse
• Hva er problemet med en Blueprint??
• Viktigheten av detaljert planer og oppfølginger
• Kontroll ifm. Endringer krever gode planer og
tegninger.
• Ikke vær prøvekanin, vær konservativ
• Drill down – walk the floor.
• Systemstøtte i alle deler av prosjektet
– Planlegging, oppfølging, timer, testing
Løsningsvalg
arkitektur
Løsningsvalg
• Fra RDB og Client/Server til dagens landskap
• Fokuser på SAP’s styrker og unngå svakheter
• Viktigste integrasjonen er den mellom system og
menneske
• Mennesker er dyrt, software/lisens er billig
• Vær konservativ og konsekvent
• Fokuser på der dere er/skal være unike resten er melk
& brød
• Ikke skreddersøm innen melk & brød
• Sørg for at hovedmotoren får den nødvendige pleie.
Kjedelig men viktig.
Diskusjon og spørsmål
Huskeliste omskriv til suksesskriterier
•
•
•
•
•
•
•
•
•
•
ERP is about your business, not the technology.
ERP initiatives are very challenging.
Selecting the right software is the first step in a
successful ERP implementation.
No ERP software is perfect. All have their strengths,
weaknesses and tradeoffs.
A business blueprint is the second step to an
effective ERP implementation.
Business process re-engineering should happen
before - not after - you implement your
ERP software.
ERP software best practices and pre-configured
solutions do not solve all of the
challenges of ERP.
SaaS ERP won’t eliminate all of your risks either.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Your project will fail without adequate
organizational change management.
Executive buy-in and support is critical to ERP
success.
The “A-Team” is critical to ERP success.
There is no “one size fits all” ERP strategy.
If your operations and your ERP system are
misaligned, it’s probably not the software’s
fault.
Expectations are high, but most ERP
implementations don’t properly define the “finish
line.”
Organizations that strive for “no customization”
often end up doing it anyway.
You don’t have to implement ERP all at once.
In addition to planning, implementation is also
about execution.
If you don’t measure it, you won’t achieve it.
It is important to recognize the “canary in the coal
mine” or signs that your implementation
may be in trouble.
ERP success and benefits realization is largely
determined before the implementation
starts.