Përgatitja për projektin e zbatimit të SAP HCM. Fazat tipike të një projekti të zbatimit të SAP ERP Zbatimi i një sistemi SAP në një ndërmarrje
Mirëdita, kolegë, lexues, miq!
Në këtë artikull do të përpiqem të flas për disa nga keqkuptimet me të cilat përballen konsulentët dhe menaxherët e projekteve. Këto keqkuptime mund të lindin nga drejtimi i kompanisë ku po zbatohet sistemi, nga punonjësit e thjeshtë që do të duhet të punojnë në sistemin e ri të kontabilitetit, madje edhe nga vetë konsulentët.
Hyrje
Nuk do të them pa mëdyshje, por mendoj se pothuajse çdo konsulent/menaxher projekti/menaxher ndryshimi që ka përvojë të mjaftueshme në zbatimin e një sistemi ERP (këtu mund të mos flasim domosdoshmërisht për sistemin SAP) do të gjejë në këtë artikull se çfarë ka në të vërtetë. kam hasur dhe do të pajtohem (ndoshta pjesërisht) me arsyetimin tim. Gjithçka që do të përshkruaj është përvoja ime personale e projektit. Dhe klasifikimi që paraqita më poshtë nuk është gjë tjetër veçse një konventë. Disa mund ta shohin dhe ta klasifikojnë atë krejtësisht ndryshe. Gati për diskutim në komentet e artikullit.
Tema e materialit u shfaq në kokën time spontanisht, gjatë një diskutimi të disa çështjeve të punës në projekt. Çështja që diskutuam kishte të bënte me zhvillimin dhe automatizimin e një metodologjie për planifikimin e disa treguesve. Në të njëjtën kohë, gjatë diskutimit të çështjes, u bë e qartë se vetë metodologjia nuk ekziston ende. Pyetja ishte diçka e tillë: ne implementuam një sistem të Planifikimit të Burimeve të Ndërmarrjes (ERP). Kushton shumë miliona para. Ka shumë informacione të ndryshme që futen atje nga mijëra përdorues përfundimtarë. Pra, pse menaxhmenti i kompanisë nuk mund të marrë planin/parashikimin e nevojshëm nga ky sistem?
Tingëllon e njohur? Dhe nga këndvështrimi i të pa iniciuarve, është një pyetje krejtësisht logjike. Ndoshta kolegët e mi dëgjuan të njëjtat pyetje, por në një kontekst paksa të ndryshëm, por jam i sigurt se ata ishin aty. Dhe kalojmë te keqkuptimi i parë.
Keqkuptim nr. 1: Sistemi funksionon për ju ose "sindroma e butonit të kuq"
Pra, ne po zbatojmë një sistem të madh dhe të shtrenjtë ERP tek Klienti (për thjeshtësi, le të supozojmë se po flasim për zbatimin e një sistemi SAP, megjithëse, siç shkrova më lart, argumentet e mia vlejnë edhe për sistemet e tjera të mëdha ERP). Shumica e punonjësve të kompanisë, edhe nëse nuk janë të përfshirë drejtpërdrejt në zbatim, kanë dëgjuar diçka diku. Kemi dëgjuar për koston e një licence (që janë ndaluese), për koston e zbatimit, për pagat e konsulentëve, etj. Punonjësit e kompanisë së Klientit që punojnë drejtpërdrejt me konsulentët për zbatimin gjithashtu shpesh nuk e kuptojnë deri në fund se si do të funksionojë e gjithë kjo pas një fillimi produktiv. Por ata gjithashtu kanë një ide për koston e zbatimit. Të gjithë këta njerëz kanë të drejtë të supozojnë se zbatimi i sistemit do të lejojë që shumë operacione manuale/rutinë të kryhen automatikisht, d.m.th. sistemi do të funksionojë për ju.
Kështu lind një stereotip. Nëse ekipi i Ekzekutuesit nuk ka asnjë ide për lindjen e këtij stereotipi, atëherë në momentin e një fillimi produktiv lind një situatë kur përdoruesit janë mjaft të befasuar sinqerisht që duhet të fusin një sasi kaq të madhe informacioni në sistem çdo ditë. Përdoruesit që morën pjesë në testimin e integrimit. Përdoruesit që kanë kaluar trajnime. ato. ata njerëz që, teorikisht, duhet të jenë të gatshëm të punojnë në sistem, ta kuptojnë dhe ta pranojnë atë. Befasia dhe keqkuptimi i tyre mund të zhvillohen në refuzim dhe mospranim të ndryshimeve, në rebelim të drejtpërdrejtë.
Ka pasur një rast të tillë në përvojën time. Kur pas fitimit të përvojës praktike në punën në sistem, pas një fillimi produktiv, në kompani u krijua një “koalicion opozitar”. Ky grup njerëzish grumbulloi në mënyrë specifike të gjithë negativitetin, të gjitha gabimet e konsulentëve, të gjitha kufizimet e funksionalitetit të sistemit (dhe siç e kuptoni, "kufizimet funksionale" të sistemit SAP, krahasuar, për shembull, me 1C, mund të jenë pamundësia e fshirjes së shumë të dhënave, pamundësia e "pastrimit të bishtave"). Epo, erdhi ora “X”, kur gjithë kjo kovë pisllëku u derdh mbi ekipin zbatues dhe iu dha edhe pronarit të biznesit, si argumenti kryesor në favor të kthimit në sistemin e vjetër të kontabilitetit. Në fund, gjithçka përfundoi mirë. Dhe pas ca kohësh, njerëzit që ishin kundërshtarët më të zjarrtë të sistemit të ri kuptuan se cilat ishin avantazhet e tij dhe ndryshuan mendje. POR, nëse menaxheri i projektit (nga njëra anë apo tjetra) do ta kishte njohur me kohë problemin dhe do të kishte bërë sqarimet e nevojshme, protesta dhe skandale të tilla mund të shmangeshin.
Unë përmenda "sindromën e butonit të kuq". Kjo është një lloj historie mes kolegëve konsulentë. Çështja është e njëjtë. Çdo përdorues, në një shkallë ose në një tjetër, dëshiron që numri i operacioneve rutinë që ai kryen çdo ditë të kryhet në mënyrë fantastike automatikisht në sistem. ato. përdoruesi hyn në sistem dhe ndërfaqja e sistemit përbëhet nga një buton i madh i kuq. Përdoruesi klikon në butonin dhe vetë sistemi kryen të gjitha operacionet e nevojshme. Dhe përdoruesi është duke pirë çaj në këtë kohë. Këshillimi i folklorit e shndërroi butonin e kuq në një pedale të kuqe. Pse një pedale? Pastaj mund të shtypni me këmbën tuaj dhe të dyja duart janë të lira. Me njërin pi çaj, me tjetrin luan diamant. J Kjo është e gjitha një shaka, sigurisht, por shumë përdorues nuk lodhen të pyesin se si një sistem i zbatuar për atë lloj parash nuk mund të "mendojë pak për një person".
Keqkuptimi nr. 2: Zbatimi i sistemit do të "lehtësojë" përdoruesit përfundimtarë
Në fakt, keqkuptimi nr. 2 është një rast i veçantë (i lehtë) i keqkuptimit të parë. Por e theksova në një pjesë të veçantë sepse ky keqkuptim haset shumë më shpesh. "Këmbët" rriten prej andej. Krahasimi i shkallës së pjerrësisë dhe kostove të sistemeve të vjetra dhe të reja të kontabilitetit u jep përdoruesve bazën për mendime dhe përfundime të pasakta që nuk mbështeten nga asgjë në praktikë. Sistemi i ri do të më lejojë të automatizoj pjesërisht, ose disi të transferoj në mënyrë magjike disa nga funksionet e mia te dikush tjetër.
Në të njëjtën kohë, ne kemi dy anët e medaljes. Një pjesë e punonjësve flenë dhe sheh se si funksionon sistemi për ta (në tërësi ose pjesërisht - shih keqkuptimin nr. 1). Një pjesë tjetër e punonjësve të kompanisë shikojnë më tej dhe e shohin këtë si problem. Në fund të fundit, nëse sistemi tani kryen vetë disa nga funksionet, atëherë numri i punonjësve të kërkuar për të kryer operacione rutinë duhet të reduktohet. Ky problem mund të sjellë edhe pasoja të pakëndshme, madje edhe sabotim të zbatimit nga punonjës/departamente individuale të kompanisë.
Do të doja të përshkruaj një shembull më shumë nga përvoja ime. Nuk e di saktësisht se cilin keqkuptim ta klasifikoj si, nr. 1 apo nr. 2. Ai (shembulli), në një shkallë ose në një tjetër, ka të bëjë me të dyja.
Për një kompani të madhe, një nga firmat kryesore të konsulencës në botë shkroi një metodë të kontabilitetit të kostos së veçantë. Kërkesat për metodologjinë ishin shumë strikte. Përpunimi i dispozitave të metodologjisë dhe një shkallë e lartë detajesh në rezultatet përfundimtare të shpërndarjes së kostos ishin shumë të rëndësishme për kompaninë e klientit. Faza e dytë e procesit të zhvillimit të metodologjisë ishte automatizimi i saj, i cili u krye duke përdorur sistemin SAP BW. Metodologjia u automatizua, përdoruesit u trajnuan dhe cilësia e punës u kontrollua nga kompania që zhvilloi metodologjinë. Klienti ishte plotësisht i kënaqur me rezultatet e punës. Sidoqoftë, që metodologjia të funksiononte në SAP BW, nevojitej një sasi mjaft e madhe informacioni fillestar (siç kam shkruar tashmë, Klienti i kushtoi vëmendje të madhe detajimit të shpërndarjes së kostos). Disa nga të dhënat u shkarkuan nga SAP ERP. Një pjesë e të dhënave nga sistemet e aplikimit. Disa u futën manualisht në MS Excel dhe u ngarkuan në BW duke përdorur formate të veçanta. Madje për këtë punë u caktuan njerëz të veçantë. Gjithçka dukej se ishte mirë. Sidoqoftë, pas ca kohësh, punonjësit që ishin ideologët kryesorë të përdorimit të metodologjisë së zhvilluar dhe morën pjesë në zhvillimin dhe pranimin e saj, filluan të largoheshin nga kompania e Klientit. Këta ishin njerëz që, ndër të tjera, kuptuan rëndësinë e përgatitjes së sasisë së nevojshme të informacionit parësor për të marrë rezultate të sakta të shpërndarjes përfundimtare. Më tej, pas disa kohësh, u morën kërkesa nga Klienti për të thjeshtuar nivelin e detajimit të llogaritjeve. Arsyeja kryesore është sasia e madhe e të dhënave fillestare që duhen përgatitur. Thjeshtimi u bë në disa përsëritje (përsëri pasi kërkesat u morën nga Klienti). Dhe në fund, ajo që mbeti nga modeli i detajuar analitik ishte një “cung” që tregonte disa të dhëna të përgjithësuara. Nuk kishte më nevojë të flitej për nivelin e mëparshëm të detajeve.
Çfarë doja të tregoja me këtë shembull. Fakti që keqkuptimi nga ana e kompanisë së Klientit i fushës së punës që duhet të kryejnë punonjësit e saj, çon në humbjen e pothuajse të gjitha rezultateve të kësaj pune në shkallë të gjerë dhe mjaft të kushtueshme.
Nga rruga, në fillim të artikullit përmenda një situatë kur Klienti kërkon që sistemi të sigurojë një lloj modeli (plani, parashikimi) bazuar në të dhënat e disponueshme. Gjithashtu një keqkuptim shumë i zakonshëm. Por nuk do ta veçoj veçmas. Kjo vlen edhe për keqkuptimet # 1 dhe 2 (ose kudo në mes). Në fund të fundit është se menaxhmenti i kompanisë së klientit ose pronari i biznesit nuk i kupton plotësisht ndryshimet midis algoritmit dhe të dhënave burimore. Çdo model, parashikim, teknikë më në fund përbëhet nga:
A. Një lloj algoritmi, i shprehur në formula të qarta dhe të kuptueshme matematikore/statistikore;
B. Një listë e informacionit të nevojshëm për të mbushur modelin me të dhëna dhe mbi të cilat do të bazohet parashikimi i ardhshëm.
Për disa arsye, njerëzit besojnë se një sistem i mbushur me të dhëna do të bëjë vetë llogaritjet e nevojshme dhe do të nxjerrë parashikimet. Kjo është e gabuar.
Si të shmangni problemet me këto dy keqkuptime (#1 dhe #2)? Është e nevojshme t'u shpjegohet sistematikisht njerëzve në të gjitha nivelet e kompanisë (punonjësit e zakonshëm, menaxherët e ulët dhe të mesëm, menaxhmenti TOP) se sistemi nuk është një robot, jo inteligjencë artificiale. Ajo nuk mund të marrë vendime vetë ose të kryejë operacione që kërkojnë një lloj analize. Një sistem është një mjet që ju lejon të pasqyroni proceset e biznesit, operacionet e biznesit dhe hapat e biznesit të një kompanie me nivele të ndryshme thellësie dhe detajesh. Se sa thellë dhe në detaje proceset, operacionet dhe hapat individualë do të pasqyrohen në sistem vendoset gjatë procesit të zbatimit. Por, sido që të jetë, shumica e informacionit analitik futet në sistem nga njerëzit. Në bazë të këtij informacioni ndërtohen raportet. Dhe thellësia e përpunimit të raportimit analitik dhe menaxherial (lexojmë, e njëjta transparencë biznesi për të cilën përpiqen kompanitë që zbatojnë sistemet ERP) varet nga cilësia dhe vëllimi i informacionit hyrës.
Një tjetër pikë e rëndësishme që mendoj se duhet t'u komunikohet përdoruesve fundorë në të gjitha nivelet. Sistemi nuk po zbatohet për lehtësinë e punonjësve të zakonshëm. Qëllimi i zbatimit të sistemit: Marrja nga menaxhmenti i kompanisë informacion të qartë, të detajuar dhe në kohë për gjendjen aktuale të kompanisë për marrjen e vendimeve të menaxhimit. Për të arritur këtë qëllim, sasia e informacionit të futur nga përdoruesit përfundimtarë madje mund të rritet në krahasim me atë që ishte në sistemin e vjetër të kontabilitetit.
Keqkuptimi nr. 3: Sistemi mund të jetë gjithmonë i "përkulur" për t'iu përshtatur biznesit
- Nuk e mbaj mend ku e pashë këtë (diku në internet), por m'u kujtua shumë mirë fraza: "...Kjo është bërë gjithmonë kështu dhe konsulenti duhet ta përsërisë atë në SAP" - është fillimi i një problemi të madh. .
"...Ka funksionuar gjithmonë në këtë mënyrë, dhe detyra e konsulentit është të kopjojë procesin në sistemin SAP" - ky është fillimi i një problemi të madh.
Një pronar biznesi, duke blerë një sistem dhe duke paguar për zbatimin e tij, dëshiron të shtrydhë nga ky sistem gjithçka që i ka dhënë i vjetri dhe shumë më tepër nga lart. Nga pikëpamja e parimit "Unë qaj, e quaj melodinë", kjo është më se e arsyeshme. Përsëri, duke marrë parasysh koston dhe pjerrësinë e sistemit, krijohet përshtypja e gabuar se ai gjithmonë mund të jetë i vendosur për t'iu përshtatur biznesit, "shtrirë" në proceset ekzistuese të biznesit pa rishikim/auditim.
Ndryshe nga projektet tradicionale të zhvillimit të softuerit, zbatimi i SAP ndahet në tri faza: para-zbatimi, zbatimi dhe pas-zbatimi. Faza e para-zbatimit diskutohet në kapitujt 10 dhe 11. Zbatimi duke përdorur metodologjinë e AcceleratedSAP (ASAP) diskutohet në kapitujt 12 deri në 17. Faza e pas-zbatimit diskutohet në kapitujt 18 dhe 19.
Para-zbatimi Faza e para-zbatimit përfshin formimin e një projekti dhe një komiteti organizues, krijimin e një ekipi projekti implementues, si dhe instalimin e pajisjeve kompjuterike dhe softuerit SAP. Instalimi i softuerit përfshin përgatitjen e harduerit dhe infrastrukturës, instalimin e sistemeve operative, bazat e të dhënave, softuerin e klientit dhe sistemin SAP R/3. Funksioni administrativ gjatë zbatimit të SAP përfshin administrimin e sistemit, menaxhimin operacional R/3, administrimin e rrjetit, bazat e të dhënave, printerët, profilet e klientëve dhe përdoruesve, administrimin e sigurisë, etj. Një aspekt tjetër i rëndësishëm i aktivitetit në këtë fazë është trajnimi i ekipit të projektit të zbatimit dhe përdoruesve të tjerë , suksesi i të gjithë projektit varet nga ky aspekt.
Trajnimi Duke pasur parasysh afatet e ngushta kohore të projekteve të zbatimit të SAP, SAP thekson trajnimin si një komponent kritik për suksesin e çdo projekti të tillë. SAP ofron një gamë të gjerë kursesh trajnimi që mbulojnë të gjitha aspektet organizative të çdo projekti SAP. Temat e këtyre kurseve variojnë nga një pasqyrë e përgjithshme e sistemit deri në një studim të plotë të një teme të caktuar. Kurset e trajnimit ndahen në tre nivele të vështirësisë:
Niveli 1 - Kurse një deri në dy ditore që prezantojnë teknologjinë R/3 Niveli 2 - Kurse tre deri në pesë ditë që ofrojnë specializim fillestar në një fushë të caktuar Niveli 3 - Kurse tre deri në pesë ditë që ofrojnë njohuri të thelluara për fushën e studiuar në Nivelin 2.
Kurset e nivelit 10 janë të destinuara për ata që marrin vendime themelore për sistemin, këto kurse rekomandohen të merren përpara fillimit të projektit të zbatimit.
SAP ofron gjithashtu kurse akademike për partnerët e SAP, të cilat zgjasin 5-7 javë dhe përfshijnë studimin intensiv të një moduli të caktuar (FI, CO, HR, SD, ABAP, Baza, etj.). Këto kurse mbulojnë aspektet më të rëndësishme të një moduli të caktuar, duke filluar nga një hyrje në modul dhe duke përfunduar me një studim të plotë të konfigurimit dhe funksionimit duke përdorur shembullin e një kompanie tregtare. Të diplomuarit e këtyre kurseve marrin titullin “Konsulent i Çertifikuar” për një modul të caktuar. Këto kurse më parë ishin të hapura vetëm për partnerët e konsulencës SAP, por tani janë të hapura për të gjithë klientët e SAP.
Instalimi i SAP
Instalimi i SAP përfshin instalimin e një licence bazë SAP dhe personalizimin e ndërfaqes së përdoruesit. Kjo i lejon sistemit SAP të ushtrojë kontroll të rreptë mbi cilësinë dhe efikasitetin.
Për zbatimin nga ndërmarrjet e vogla dhe të mesme, SAP rekomandon një metodologji të përshpejtuar të zbatimit, AcceleratedSAP, e cila përbëhet nga pesë faza:
Përgatitja e projektit
Hartimi i një diagrami të proceseve të ndërmarrjes
Zbatimi
Përgatitja përfundimtare
Nisja dhe mbështetja teknike.
Pas zbatimit Faza e pas-zbatimit përfshin instalimin e shërbimeve të sistemit si SAP Help, sistemet e rikuperimit të të dhënave të humbura dhe sistemet e arkivimit. Pas zbatimit të moduleve bazë, mund të filloni të zbatoni module të tjera - të tilla si SAP Data Warehouse (BW), SAP Workflow, etj., dhe gjithashtu të njiheni me arkitekturën e sistemit SAP, i cili ju lejon të shtoni lehtësisht dhe shpejt funksione të reja në sistemin.
Për funksionimin efektiv të sistemit SAP, trajnimi i ekipit të zbatimit dhe përdoruesve fundorë luan një rol kritik.
Pse projekti ndahet në faza dhe cili parim ndiqet zakonisht kur ndahet një projekt në faza?
Në fakt, gjithçka është jashtëzakonisht e thjeshtë, së pari, bazuar në rezultatet e fazës, zbatimi i projektit monitorohet dhe menaxhohet, dhe së dyti, është i përshtatshëm për të lidhur kushtet e kontratës me fazat: aktivizimi, orari i pagesës, etj. Është e qartë se çdo fazë duhet të përfundojë me një produkt të caktuar, i cili mund të konsiderohet, nga pikëpamja e palëve, objekt i kontratës ose pjesë e saj.
Krijimi i një zyre projekti
Faza e parë dhe zakonisht më e shkurtër e projektit. Shumë shpesh emri i saj e ngatërron klientin. Një herë, kur pata nderin të punoja në ekipin e brendshëm të një ndërmarrjeje të guximshme metalurgjike, menaxhmenti i lartë bëri pyetje mjaft sarkastike: "Çfarë, në këtë fazë do të rregullojnë karriget?"
Në fakt, sigurisht që në këtë rast nuk po vendosen karriget apo edhe tavolinat. Produkti i kësaj faze të projektit janë në fakt dokumentet kryesore të menaxhimit të projektit: urdhri për fillimin e projektit, statuti i projektit, një plan i detajuar, një plan i menaxhimit të rrezikut, një plan komunikimi, etj.
Shpesh emri i fazës zgjidhet ndryshe, mua personalisht më pëlqen kjo sepse... në fakt korrespondon me përmbajtjen sa më shumë që të jetë e mundur.
Anketa
Në këtë fazë të projektit, konsulentët e kontraktorit njihen me proceset në ndërmarrje që do të automatizojnë dhe studiojnë kërkesat. Komunikimi ndërmjet konsulentëve dhe punonjësve të ndërmarrjes më së shpeshti zhvillohet në formën e një interviste, pas së cilës konsulenti përgatit një raport mbi takimin. Raporti duhet të nënshkruhet nga të gjithë pjesëmarrësit në takim. Në të ardhmen, të gjitha raportet për intervistat e kryera do të përfshihen në raport.
Praktika më e mirë është përgatitja e përshkrimeve të proceseve të biznesit në formën e diagrameve në disa produkte CASE. Ky diagram quhet “Si është (AS-IS) Diagrami i Procesit të Biznesit”. Por, për fat të keq, për shkak të kostos së lartë të produkteve softuerike, si dhe kërkesës së ulët nga klienti, kjo teknologji përdoret shumë rrallë në projekte. Është për të ardhur keq, sepse përdorimi i tij bën të mundur nxjerrjen e përfundimeve të ndryshme analitike për gjendjen e proceseve të biznesit, kryerjen e optimizimit dhe, më e rëndësishmja, në të ardhmen, gjatë projektimit konceptual dhe ndërtimit të "Siç duhet të jetë" (TO-BE ) model, lejon analiza krahasuese, d.m.th. ju lejon të parashikoni përfitimet e zbatimit të një sistemi ERP. Rezultati i kësaj faze është gjithashtu shpesh një specifikim teknik i rafinuar.
Dizajni konceptual (modeli TO-BE)
Faza e Dizajnit Konceptual duhet të përfshijë në fakt punën e kryer në fazën e Anketës, por nga pikëpamja e menaxhimit të projektit, dhe veçanërisht buxheti dhe afatet kohore, mendoj se është më mirë t'i veçojmë ato. Fakti është se gjatë fazës së inspektimit, tashmë mund t'i bëhet e qartë kontraktorit nevoja për të rregulluar orarin dhe qëllimin e punës, çështja e kësaj duhet të shtrohet për diskutim dhe të merren masat e duhura. Nëse kjo nuk bëhet në këtë fazë, atëherë është pothuajse e pamundur të bëhet më vonë (edhe pse në këtë rast është e nevojshme të tregohen mrekulli të diplomacisë).
Faza e projektimit konceptual, për mendimin tim, është një nga fazat më të vështira të një projekti. Këtu shpesh ndodhin përplasje midis strukturave të ndryshme të ndërmarrjeve dhe, si rezultat, kontraktori duhet të kërkojë vazhdimisht një rrugëdalje nga situata aktuale. Në fund të fundit, suksesi i zbatimit të kësaj faze të veçantë do t'i japë shtysë automatizimit të suksesshëm të proceseve të biznesit, duke marrë parasysh kërkesat e paraqitura nga sistemi. Dokumenti që po zhvillohet në këtë fazë të projektit, dizajni konceptual, është rregulli me të cilin do të ndërtohet jo vetëm konfigurimi i sistemit, por edhe proceset e biznesit në të ardhmen. Nuk është sekret që një sistem informacioni është një mjet biznesi që ju lejon të merrni vendime operacionale, taktike dhe strategjike, dhe gjithashtu ndikon në punën e departamenteve të përfshira në përgatitjen e informacionit.
Gjithashtu, një vështirësi e caktuar gjatë kësaj faze konsiston në përshtatjet për kreativitetin dhe kreativitetin e anëtarëve të ekipit të projektit. Kur punoni në një projekt konceptual, duhet të organizohen konsultime shtesë me ekspertë të biznesit dhe sesione të ideve. Duhet bërë gjithçka për t'u siguruar që sistemi t'i përshtatet sa më shumë kërkesave të klientit dhe kjo është vështirësia kryesore.
Zbatimi
Faza më e kuptueshme dhe, sipas shumëkujt (më duket gabimisht), faza më e rëndësishme e projektit. Në fakt, me ndërtimin e saktë të një modeli konceptual të proceseve dhe sistemeve të biznesit, faza e zbatimit të cilësimeve dhe zhvillimit reduktohet në punë thjesht teknike. Kompleksiteti dhe rëndësia e kësaj faze mund të shpjegohet me aktivitetet që, si rregull, kurorëzojnë fazën - ky është një test integrimi dhe një fillim produktiv i sistemit.
Një test integrimi mund të bëhet sipas skenarëve të ndryshëm, por çështja e kësaj ngjarje është se kontraktori duhet t'i provojë klientit funksionueshmërinë e sistemit, si dhe përshtatshmërinë e tij në raport me kërkesat. Kjo temë është aq e ndërlikuar sa në këtë artikull nuk do të thellohem në të;
Fillimi produktiv i sistemit është, në parim, pikërisht momenti historik për të cilin funksionon konsultimi. Në përvojën time ka pasur fillime të ndryshme produktive dhe kjo është gjithashtu një temë shumë komplekse dhe e gjerë. Mund të them vetëm se nëse ka ndodhur një fillim produktiv, atëherë projekti ka qenë 90% i suksesshëm.
Mbështetja fillestare
Shërbimi i garancisë për sistemin, nuk ka shumë për të shkruar këtu. Një fazë shumë e vështirë për kontraktorin dhe klientin. Fillimi në çdo sistem shoqërohet me vështirësi të mëdha dhe një bollëk gabimesh nga ana e përdoruesve, dhe në vetë sistemin, si rregull, ka mjaft gabime. Dhe vështirësia qëndron kryesisht në faktin se të gjitha sa më sipër u ndodhin njëkohësisht njerëzve të ndryshëm. Kritike për suksesin e kësaj faze dhe të projektit në tërësi është refuzimi i kontabilitetit paralel në sistemin historik (të vjetër). Pas braktisjes së kontabilitetit paralel dhe mbylljes së periudhës kontabël që mbulon të gjithë gamën e operacioneve të automatizuara, projekti mund të konsiderohet i suksesshëm dhe i përfunduar.
Në kushte ideale, një projekt mund të përfundojë në kohë, brenda buxhetit dhe me efikasitetin më të madh. Është e rëndësishme të kemi një qasje standarde ndaj sistemeve dhe procedurave për të ndihmuar kompanitë e reja në SAP të zbatojnë me sukses. Kjo qasje (e quajtur "metodologji") mund të mos jetë më efektive, por do të garantojë sukses në kushte optimale. Kompanitë mbijetojnë dhe rriten jo sepse planifikojnë kushte ideale ose më të këqija, por sepse planifikojnë kushte optimale. Në rastin e zbatimit të SAP, metodologjia e zbatimit duhet të sigurojë suksesin e projektit në kushte të vështira biznesi, struktura organizative dhe burimore, afate etj. Metodologjia e zbatimit ka këto aspekte:
Modelimi i procesit të biznesit: Kompania përcakton proceset e dëshiruara ose të kërkuara të biznesit.
Hartimi i proceseve të ndërmarrjes kundrejt proceseve të mbështetura nga SAP: Kompania specifikon proceset dhe funksionalitetin standard të SAP që plotësojnë kërkesat e proceseve të modeluara.
Analiza e mangësive: Kompania vlerëson mospërputhjet ose boshllëqet midis funksionalitetit standard të SAP dhe kërkesave të proceseve të modeluara.
Përkufizimi përfundimtar i fushës së zbatimit të projektit SAP: kompania përcakton fushën e zbatimit të SAP, domethënë tregon se cilat procese do të zbatohen së bashku me SAP.
Konfigurimi i Sistemit SAP: Kompania konfiguron cilësimet bazë të SAP duke përdorur Udhëzuesin e Implementimit për të përmbushur kërkesat e vendosura më parë (shih Konfigurimi përmes Udhëzuesit të Zbatimit në Kapitullin 12). Të gjitha cilësimet janë bërë në klientin 001.
Testimi i një sistemi të personalizuar SAP: Funksionaliteti i sistemit të konfiguruar testohet duke përdorur të dhëna reale.
Mangësitë e zbuluara të funksionalitetit mund të adresohen duke përdorur masat e mëposhtme:
Zhvillimi i zgjidhjeve për të arritur funksionalitetin e dëshiruar, duke zbatuar konfigurimin e duhur.
Programimi i funksionalitetit të dëshiruar në ERP përmes cilësimeve të përdoruesit.
Instalimi i produkteve softuerike shtesë nga kompani të tjera të certifikuara për përputhshmëri me sistemin SAP përmes Programit Softuer Plotësues SAP (CSP).
Vonesa e zbatimit të këtij funksioni deri në versionin tjetër të SAP ose përmirësimin tjetër në të cilin ofrohet ky funksionalitet.
Ndryshimi rrënjësor i një procesi biznesi në mënyrë që ai të jetë i pajtueshëm me funksionalitetin e SAP dhe të arrijë të njëjtin rezultat.
Modifikimi i drejtpërdrejtë i SAP, megjithëse nuk rekomandohet, sepse ndryshimet në kodet burimore të programit do të anulojnë garancinë e SAP. Për më tepër, softueri i modifikuar mund të mos jetë i pajtueshëm me versionet e ardhshme të SAP.
Sistemi SAP ofron një mjedis të plotë R/3 Business Engineer për të ndihmuar me zbatimin e SAP. Kur modeloni proceset e biznesit SAP, është e mundur të përdorni cilindo nga mjetet e mëposhtme: IDS Sheer ARIS, Microsoft VISIO, IntelliCorp LiveModel dhe Enterprise Charter. Ato bazohen në Modelin e Referencës R/3 dhe ofrojnë një ndërfaqe të drejtpërdrejtë për të bashkëvepruar me funksionalitetin e sistemit R/3. Kjo lehtëson shumë të kuptuarit e sistemit, sepse ju lejon të filloni transaksione specifike SAP drejtpërdrejt nga mjedisi i modelimit: nga ana tjetër, modelet e procesit të ofruara nga këto sisteme ofrojnë një kontekst të plotë për një transaksion të veçantë SAP.
Modeli i referencës R/3 dhe mjetet e përmendura më sipër përdorin teknologjinë e modelimit të rekomanduar të SAP të quajtur Zinxhiri i Procesit të Drejtuar nga Ngjarjet (EPC). Në thelbin e saj, kjo teknologji modelon proceset si një grup i renditur procedurash që shkaktohen nga ngjarjet brenda sistemit. Këto ngjarje mund të ndodhin në bazat e të dhënave (për shembull, një përditësim) ose në ekran - për shembull, kur një përdorues zgjedh një artikull të menysë ose klikon një lidhje në një faqe interneti.
Modeli procedural SAP
Ky është një model tradicional i zbatimit të SAP dhe është plotësisht i integruar me sistemin SAP. Ky model u prezantua në vitin 1995, njëkohësisht me sistemin SAP R/3 3.0. Ndonjëherë përdorimi i Modelit Procedural SAP vihet në dyshim: ekziston një ndjenjë se ky model është i vjetëruar dhe duhet të braktiset në favor të AcceleratedSAP. Megjithatë, duhet pasur parasysh se metodologjia AcceleratedSAP është projektuar kryesisht për ndërmarrjet e mesme dhe të vogla, ndërsa për kompanitë e mëdha Modeli Procedural SAP mbetet metodologjia më e mirë e zbatimit të SAP. Meqenëse ky libër fokusohet në zbatimin e SAP për bizneset e mesme dhe të vogla, këtu do të jap një përshkrim të shkurtër të Modelit Procedural SAP, i cili është ideal për kompanitë me të ardhura prej 1.2 miliardë dollarësh ose më shumë.
Në Fig. Figura 5.8 paraqet në mënyrë skematike Modelin Procedural SAP.
Oriz. 5.8. Modeli procedural SAP.
Modeli procedural SAP përbëhet nga katër faza:
1. Dizajn organizativ dhe konceptual
Përgatitja e projektit
Organizimi i mjedisit zhvillimor
Trajnimi i ekipit të projektit
Përkufizimi i funksioneve dhe proceseve
Përcaktimi i Ndërfaqeve dhe Përmirësimeve
Organizimi i dizajnit konceptual dhe kontrollit të cilësisë.
2. Projektimi dhe instalimi i detajuar i sistemit
Konfigurimi i parametrave bazë
Krijimi i një strukture organizative
Përgatitja e të dhënave master
Konfigurimi i proceseve dhe funksioneve
Zbatimi i ndërfaqeve dhe përmirësimet
Vendosja e raportimit
Organizimi i menaxhimit të arkivit të të dhënave
Testimi i fundit
Projektimi i detajuar dhe instalimi i sistemit të kontrollit të cilësisë.
3. Përgatitja për nisje
Krijimi i Dokumentacionit të Përdoruesit
Përfundoi fazën tjetër të projektit për të zbatuar sistemin e menaxhimit të informacionit SAP ERP në një fabrikë të madhe makinerie. Zbatimi i sistemit i lejoi kompanisë të vendosë kontroll të automatizuar të të gjitha proceseve, bëri të mundur uljen e kostove, rritjen e fitimeve nga shitjet me 1.7 herë dhe kalimin e certifikimit ISO/TS 16949.
Rreth klientit
Fabrika prodhon mbërthyes dhe susta për industrinë e automobilave. Ndër konsumatorët e produkteve të saj janë prodhuesit më të mëdhenj rusë (GAZ, KAMAZ dhe të tjerë), nënkontraktorët e tyre dhe klientët nga CIS.
Ndërmarrja ishte e ndarë në një person juridik të veçantë dhe kishte nevojë për një sistem efektiv të menaxhimit.
Situata problematike Problemi ishte nomenklatura - nga 60 në 140 pozicione mjetesh kërkohen për të prodhuar një pjesë. Ndërmarrja prodhon deri në 50,000 njësi të pajisjeve teknike, ajo ka dy objekte prodhuese - kryesore dhe instrumentale
- Puna me tre turne, shtatë ditë në javë. Nevojitej një sistem që do të lejonte llogaritjen e shpejtë të nevojave për punë të balancuar dhe identifikimin e kostos reale të produkteve.
Përpara se të zbatonte zgjidhjet e ASAP Consulting, ndërmarrja iu drejtua automatizimit "patchwork" dhe platformave pa një bazë të dhënash të centralizuar, gjë që çoi në probleme:
kontradiktat e bazës së të dhënave dhe vonesat e të dhënave prej disa ditësh;
shfaqja e informacionit "pas faktit", pa mundësinë e korrigjimit të menjëhershëm;
mungesa e të dhënave për kostot dhe shpenzimet faktike, pamundësia për të parandaluar shpenzimet joproduktive.
Thelbi i zgjidhjes së propozuar
Fabrika kishte kufizime të rrepta kohore, gjë që bëri që interpretuesit të refuzonin detyrën. ASAP Consulting propozoi një sistem informacioni të bazuar në kompleksin SAP ERP, i cili përmbushi kërkesat dhe afatet në sajë të metodologjisë së vet të nisjes së shpejtë.
Thelbi i projektit është të mbulojë të gjitha proceset e biznesit, nga planifikimi i riparimeve deri te gjenerimi i faturave për klientët, gjë që supozohej të ndihmonte: zbatojnë planifikimin dhe riplanifikimin prodhimi, llogaritjet dhe automatike
gjenerimi i raportimit të menaxhmentit në kohë reale; kaloni nga metoda e kaldajës së llogaritjes së kostos tek ai tërthor,
parti;
të arrihet gjurmueshmëria e kostove nga lëndët e para te produktet e gatshme përmes fazave të përpunimit, duke minimizuar kohën e ndërprerjes dhe kostot e eliminimit të forcës madhore.
Fazat e zbatimit
Specialistët e ASAP Consulting u njohën me sistemet ekzistuese dhe, duke përdorur metodologjinë e kompanisë dhe modulet standarde SAP, vendosën pesë module kryesore (plus BC - mbështetje teknike dhe sistemore për projektin):
SD - menaxhimi i shitjeve;
MM - blerja dhe menaxhimi i inventarit;
CO - menaxhimi i kostos dhe llogaritja e kostos;
FI - RAS dhe NU;
PP - planifikimi, kontabiliteti dhe kontrolli i prodhimit. Module të ngjashme janë vendosur në instrumentale
vendosja e ndërveprimit nga fundi në fund, planifikimi automatik duke marrë parasysh inventarët në magazina, kërkesën ditore për produkte, prioritetet dhe kapacitetin;
të zgjidhë problemin e prodhimit dhe nomenklaturës në shkallë të vogël (256,000 produkte);
automatizoni rendin e mjeteve për prodhimin kryesor.
Rezultatet dhe dinamika
Brenda gjashtë muajve, specialistët e kompanisë plotësuan kapacitetin ekzistues dhe prezantuan funksionalitetin e përditësuar pa ndërprerë atë ekzistues. Gjatë procesit të zbatimit, ne kemi zhvilluar proceset e biznesit:
PM/TOPO - mirëmbajtja dhe riparimi i pajisjeve;
WMS - menaxhimi i depove;
BW - magazinë informacioni;
FM - menaxhim financiar;
CS - shërbimi ndaj klientit;
NU dhe SNRF.
Gjatë projektit, një person juridik u nda në një grup kompanish pa ndërprerë prodhimin. Përditësimi teknik u krye në një kohë të shkurtër. Rezultati i integrimit të SAP ishte:
reduktimi i normave të konsumit të materialit me 10%;
kursime në kosto - 2.5 milion dollarë ose 510 ton metal;
rritja e të ardhurave marxhinale me 20%, dhe fitimi nga shitjet me 1.7 herë.
Përveç kësaj, në ndërmarrje:
është vendosur kontrolli operativ i të arkëtueshmeve dhe të pagueshmeve për materialet dhe produktet e prodhimit kryesor;
Koha për nxjerrjen e produkteve të reja në treg është reduktuar me 6 herë (për shkak të integrimit të sistemit T-Flex PDM me zgjidhjen SAP);
një bazë të dhënash prej 256,000 pozicionesh u krijua për mjetin (me çmontim);
Planifikimi "pjese-mjet" është krijuar me të balancuar fuqia;
Cilësia e produkteve është rritur, gjë që ka bërë të mundur marrjen e certifikimit sipas standardit ISO/TS 16949 për të zgjeruar portofolin e shitjeve për të përfshirë klientët me kërkesa të rrepta.
Rezultati
Ndërmarrja mori një sistem që i lejon asaj të sigurojë cilësinë e produkteve dhe vendimet e menaxhimit të marra në të gjitha nivelet në kohë reale. Ai përfshin rreth 1500 kompjuterë që punojnë 820 përdorues. 16,000 porosi dhe rreth një milion regjistrime kontabël gjenerohen në muaj.
Menaxhmenti i uzinës vëren përputhshmërinë e plotë dhe tejkalimin e pritshmërive (një rritje e mprehtë e fitimeve në tre muajt e parë pas përfundimit të projektit), gatishmërinë e specialistëve të kompanisë për të punuar së bashku në mënyrë të frytshme dhe një rritje të nivelit të ndërgjegjësimit të punonjësve. Konsumatori planifikon bashkëpunim të mëtejshëm - integrimin e sistemit me një zgjidhje për konsumatorët, diversifikimin dhe futjen e pozicioneve të reja (fiksuesit e aviacionit).
