Yra žinoma, kad pardavėjų rinkodaros pareiškimai kartais labai skiriasi nuo realybės. Tačiau visuotinai pripažįstama, kad gerbiami rinkos dalyviai tokios praktikos nesiima. Tačiau SAP Business One įgyvendinimo projektų vadovas nedidelis Rusijos įmonė Iš asmeninės patirties įsitikinau, kad „nieko žmogaus nėra svetima“ garbingoms įmonėms.

Išlikimo kraštas

Prieš keletą metų beveik visi pasaulio ERP sistemų kūrėjai pradėjo judėti link SMB segmento, kuris buvo paskelbtas kone perspektyviausiu ir prioritetiniu. Rinkai buvo pristatyti nauji produktai, skirti mažoms įmonėms, turinčioms mažus IT biudžetus. Rusijos verslo programų rinka nebuvo išimtis. Vidaus spaudoje pasirodė įtikinami straipsniai, informuojantys Rusijos verslininkus, kad sustiprėjusios konkurencijos sąlygomis (taip pat ir įstojimu į PPO) jie negalės išgyventi, jei neturės modernios automatizuotos sistemos. valdymo apskaita, planavimas ir kontrolė. Pateikti argumentai buvo gana įtikinami. Dėl to daugelio vidutinių ir mažų įmonių vadovybė Rusijoje rimtai galvoja apie perėjimą „prie kažko geresnio nei Excel ir 1C“. Mūsų įmonė taip pat priklauso SMB segmentui ir dėl minėtų veiksnių priėmė vieno iš SAP Corporation partnerių pasiūlymą pristatyti rinkai tuomet naują produktą – SAP Business One (B1).

Kaip matyti iš reklaminių bukletų, šiuolaikiniai programinės įrangos produktai, atitinkantys visuotinai pripažintus pasaulinius standartus, pagaliau tapo prieinami mažoms Rusijos įmonėms. Tai buvo platus funkcionalumas, prieinama kaina ir kelių mėnesių diegimas. Buvo nutylima tik viena – kad smulkusis verslas rizikuoja kur kas labiau žengdamas į „korporacinės programinės įrangos įvedimo“ žaidimą, nes, nepaisant kuklaus biudžeto, palyginti su sensacingais projektais, investicijos į IT nėra didelė kompanija- reikšmingas išlaidų elementas. Kalbant apie verslo mastą, „gražios užjūrio dėžės“ įvedimas tikrai gali pastatyti įmonę ant išlikimo slenksčio.

Čia yra naujas posūkis

SAP nebuvo išimtis pasaulinėse lenktynėse dėl MVĮ ir prieš kelerius metus paskelbė apie „esminius bendrovės produktų portfelio pokyčius“ ir sprendimą padaryti „visišką posūkį į SVV rinką“ ir įtraukti į savo veiklą. produktų linija sprendimas orientuotas į mažas augančias įmones. Be to, buvo paskelbta, kad SVV sprendimų rinka yra vienas iš SAP prioritetų. SAP CIS generalinis direktorius Aleksejus Šlykovas tada pakomentavo šį žingsnį taip: „SAP atpažino momentą, kai rinka didelis verslas, į kurią, visų pirma, buvo orientuotos įmonės verslo aplikacijos, pasirodė arti prisotinimo ir atėjo laikas ieškoti kitų pardavimo rinkų.

Dėl to 2003 metais Rusijos rinkai buvo pristatyta lokalizuota SAP Business One versija – sprendimas, kuris iš esmės skiriasi nuo to, ką SAP darė anksčiau. Tačiau „SAP Business One“ nėra Vokietijos įmonės kūrimas: produktas pirktas iš Izraelio kūrėjų. Įdomu tai, kad SAP Business One išleidimas nebuvo lydimas didelio masto reklaminės kampanijos- visų reklaminių pastangų rezultatas buvo keli informaciniai straipsniai spaudoje ir regioninių seminarų ciklas potencialių klientų organizuoja SAP partneriai. Taip pat oficialiai paskelbta, kad vienos „iki raktų“ darbo vietos kaina (licencijos plius diegimo konsultacijos) sieks 2500–3000 eurų, o diegimo trukmė neviršys 8 savaičių. Be to, buvo žinoma, kad produktas turi vieną reikšmingą pranašumą lyginant su alternatyviais pasiūlymais – jis pritaikomas, jo nereikia programuoti, skirtingai nei 1C sprendimuose, ir jame jau yra paruošti verslo procesai.

Tiesą sakant, per tiesioginį mūsų įmonės pardavimą buvo pasakyta: „Po 2 mėnesių pristatysime produktą, ir jūs turėsite visavertę valdymo apskaitos sistemą“. Tuo rinkodaros informaciją apie gaminį neatitinka tikrosios savo esmės, vėliau įsitikinome savo patirtimi. Iki šiol viskas skambėjo labai įtikinamai. Mus sužavėjo ir SAP partnerio (gerbiamos, ilgametės įmonės mūsų regione) pristatyti sprendimo demonstraciniai vaizdo įrašai. Be to, buvo pateiktas įtikinamiausias argumentas – „jūs esate po patikimo SAP prekės ženklo sparnu“. Ir tai išsklaidė visas mūsų abejones.

žiauri tikrovė

Po trijų mėnesių diegimo tapo aišku, kad SAP Business One funkcionalumas, atvirai kalbant, yra nepakankamas net mažam (70 darbuotojų) verslui. Rusijos sąlygomis. Kodėl mes to nesupratome anksčiau? Sudėtingas klausimas.

Produktas, kaip mums buvo pasakyta, skirtas SVV rinkai, kad įmonės neįtrauktų į ilgą tyrimo etapą, po kurio seka kelių tomų. įgaliojimai. Dėl to po pritaikyto gaminio testavimo etapo susidūrėme su daugiau nei trijų lapų „klaidų“ sąrašu, o nepataisius – tiesiog beprasmiška sistemą sutvarkyti. Vieni iš jų buvo susiję būtent su gaminio veikimo klaidomis, kiti – su sprendimo nepakankamo funkcionalumo problemomis. Pagal mūsų sudarytą sąrašą diegianti įmonė buvo pasirengusi „užbaigti“ apie 30% reikalavimų, o likusių be SAP dalyvavimo pakeisti nepavyko, nes prekės kodas buvo uždarytas. Tų „patobulinimų“, kuriuos partneris gali atlikti pats, įgyvendinimas iš karto padidino projekto kainą. Tai paskatino tai, kad „produktą reikia užbaigti pagal verslo procesų specifiką“. Tuo pačiu metu patobulinimų tikrai reikėjo, bet ne dėl mūsų „specifiškumo“, o tiesiog tam, kad produkte būtų įdiegtas, apskritai, standartinis verslo modelis. Iš mūsų pusės nebuvo jokių neįprastų reikalavimų.

Be to, kaip paaiškėjo, SAP Business One nėra trijų pakopų sistema, o sukurta kliento-serverio architektūros pagrindu. Tuo pačiu metu informacija apdorojama ne serveryje, o kliente, o tai tiesiogiai veikia našumą. Beje, mums paleidus sistemą bandomuoju režimu, atsižvelgiant į oficialiose SAP Business One sprendimą aprašančiose bukletuose nurodytus techninės įrangos reikalavimus, deklaruotos sistemos informacijos apdorojimo galimybės nepasitvirtino.

Taip pat būtina atkreipti dėmesį į keletą rimtų SAP Business One trūkumų, kurie nėra akivaizdūs per pirmuosius pristatymus, o „išryškėja“ tik proceso metu:

• duomenų bazių sistemos semantika praktiškai neaprašyta;
• praktiškai nėra saugomų procedūrų;
• sistema yra lėta ir reikalauja daug išteklių;
• dingęs spausdinimo formos atitinkamas Rusijos standartai buhalterinė apskaita;
• atsarginė funkcija neįdiegta (pavyzdžiui, produktai);
• neįvesta ilgalaikio turto apskaita;
• nevykdoma atsiskaitymų su atskaitingais asmenimis apskaita;
• neteisingai vykdoma mokėjimų apskaita;
• nėra galimybės tiesiogines ir netiesiogines išlaidas priskirti gamybos savikainai;
• nėra įdiegta korinio sandėlio palaikymas, neįmanoma vesti apskaitos prekių siuntų kontekste;
• neįgyvendinama galimybė organizuoti vakarėlio atvykimą skirtingomis kainomis;
• MRP neveikia sandėlio kontekste.

Tuo pačiu metu SAP Business One sumų skirtumus kaupia tik nacionaline valiuta, sumų skirtumų ataskaita sudaroma pagal esamą valiutos kursą, todėl neteisingai apskaičiuojami mokėjimų sumų skirtumai.

Išvardinti „trūkumai“ apskritai neleidžia pateikti teisingos informacijos apie įmonės veiklą. Tuo pačiu nėra iki galo aišku, kaip šiuo atveju SAP Business One galima pozicionuoti kaip valdymo apskaitos sistemą. Mažmeninė, didmeninė prekyba ir kitos sparčiai augančios įmonės negalės dirbti su šia sistema dėl jos veikimo apribojimų. Išsaugojus 40–50 pozicijų dokumentą, sistema sustingsta. Jei tokių dokumentų per dieną būna bent 200-300, tai viskas tiesiog nustoja veikti.

Mums buvo pasiūlyta „optimizuoti“ mūsų įmonės verslo procesus, o tai iš tikrųjų mums yra esminių taškų pertvarkymas ir labiau panašu į jau įsitvirtinusio verslo „įspaudimą“ į griežtus sprendimo rėmus. Jei nenorime savo įmonėje perstatyti esamos sistemos, mums buvo pasiūlyta galutinai užbaigti sprendimą. Be to, čia kalbame apie sprendimo funkcionalumo išplėtimą ir reikalaujama programavimo naudojant vadinamąjį SDK paketą (Software Development Kit).

Iš pokalbio su įgyvendinančia įmone sužinojome, kad SAP, paprastai tariant, verčia partnerius savarankiškai tobulinti funkcionalumą ir rašyti vadinamuosius priedus (papildomus komponentus). Šiuos komponentus taip pat galima įsigyti iš kitų partnerių, kurie jau įdiegė šią funkciją. Pavyzdžiui, norint apskaityti operacijas su ilgalaikiu turtu, reikia įsigyti atitinkamą priedą, tas pats, jei norime sekti faktines ir planuojamas išlaidas, dar vienas atskiras modulis skirtas sprendimui sąsajai su banko-kliento sistema . Be to, kad pabrangsta projektas, yra ir kita pusė: jei perkame priedą iš kitos įmonės, tai arba ją reikia įtraukti į įgyvendinimą vėlgi už papildomus pinigus, arba mūsų įgyvendinimo partnerį. susitvarkys patys, bet ir ne nemokamai. Tiesą sakant, tai tampa savotiška „piramidė“, kuri stiprėja, tuo platesnis įmonei reikalingas funkcionalumas.

Parduoti ir pamiršti?

Logiška manyti, kad SAP turėtų tiesiogiai spręsti techninių ir technologinių trūkumų taisymą. Čia bendraujant su SAP Maskvos biuru buvo atskleista keletas įdomių dalykų. Paminėsiu, kad mokėjome už kasmetinį techninį aptarnavimą ir turėjome teisę tikėtis bent dėmesingo kliento požiūrio bei operatyvaus atsakymo.

Turiu iš karto pasakyti, kad nė vienas iš mūsų nurodytų punktų nebuvo ištaisytas. Vietoj to, vyko ilgas susirašinėjimas tarp partnerio ir atsakingi asmenys SAP, kurį galiausiai mūsų partneris mums net parodė. Dauguma atsakymų (mandagūs, bet trumpi atsakymai su savaitės pertrauka) susidarė į tai, kad jie puikiai žino tą ar kitą „klaidą“ ir aktyviai su ja dirba, nes skundžiamės ne mes vieni. tai. Beveik visi punktai, kurių prašėme, buvo tariamai ištaisyti nauja versija SAP Business One. Kurio laukėme apie pusantrų metų.

Dėl to laikomės nuomonės, kad įrodyta " Techninė pagalba» atspindi bendrą pardavėjo požiūrį į verslą su MVĮ. SAP Rusijoje orientuotas būtent į stambius klientus, nes jie turi galimybę į projektą investuoti neribotą laiką ir pinigus. Tačiau SMB negali laukti be galo ir visą šį laiką „maitinti“ SAP konsultantus. Be to, sprendžiant iš atsakymų į mūsų užklausas „efektyvumo“ ir „prasmingumo“, atrodo, kad SAP domina tik licencijų pardavimas, o konkrečiai dėl produkto nieko nedaroma. Taip pat pažymėtina, kad SAP Business One už klientus atsakingi žmonės dažnai keičiasi SAP. Dalis jų, prasidėjus SAP projektui SVV įmonėms, labai greitai perėjo nuo SAP Business One skatinimo klausimų sprendimo prie savo karjeros kūrimo SAP viduje, kita dalis persikėlė į kitas įmones.

Rinkodaros aritmetika

Teiginys „SAP Business One – valdymo apskaitos sistema“ suteikia SAP rinkodaros specialistams ypatingo žavesio. Pasikartosiu, kas gali būti apskaita, jei sistema nesugeba pateikti tikros informacijos apie įmonės veiklą? Jei sistemą „niūriai tempia į verslą“ nelaimingi partneriai, kurie tiesiog priversti įstumti įmonę į šio „sprendimo“ rėmus?

Nuo pat SAP Business One produkto pasirodymo Rusijos rinkoje pradžioje buvo teigiama, kad tai sprendimas vidutiniam ir smulkiam verslui. Ar tikrai? Pati SAP įmonė žiniasklaidoje skelbė 1 iki galo darbo vietos kainą (tai yra licencija+diegimas) - apie 2,5-3 tūkst.€ Be to, buvo paskelbta (kaip prekės privalumas), kad kaina galutinė. .

Norint tikrai automatizuoti pagrindinius verslo procesus nedidelėje įmonėje, tarkime, turinčioje 100-200 žmonių (finansų, pardavimų, sandėlio, pirkimų), reikia įsigyti apie 10-15 darbo vietų. Tai yra, reikia skaičiuoti apie €30-€45 tūkst.. Kaip rodo praktika, savininkai rus. mažos įmonės, kurie kiekvieną centą uždirba „prakaitu ir krauju“, už „programinę įrangą“ mokėti 30 tūkstančių eurų/dolerius nėra taip paprasta. Be to, sistemoje neįmanoma tvarkyti mokesčių apskaitos ir buhalterinės apskaitos, o „1C: Apskaita“ vis tiek reikės. Be to, atidžiau pažvelgus į jau paskelbtus diegimus, galima pastebėti, kad visaverčiai projektai yra reta išimtis ir, kaip taisyklė, kalbame apie 3-5 licencijas. Išvados rodo pačios savaime.

Taigi, mūsų patirtimi, SAP Business One gali dirbti su ne daugiau kaip 10 vartotojų, įmonėje, kurioje nėra pilnaverčio produktų sandėlio, o realiai gali būti apdorojama ne daugiau kaip 2-3 prekių užsakymai per dieną. Kyla klausimas: „Ar mažai besivystančiai įmonei reikia tokios sistemos už daugiau nei du tūkstančius eurų už darbo vieta? Kodėl, jei šiame lygyje pakanka naudoti tik „Excel“?

Pirma, SAP partnerių atstovų teigimu, „Business One“ kūrėjai yra Izraelyje ir nėra aiškios produktų kūrimo programos Rusijos rinka. Tiksliau, tokia plėtra pasauliniu mastu SAP verslo turi mažiausią prioritetą. Ir kad ir kokie aktyvūs būtų partneriai, jie tiesiog fiziškai negali susidoroti su visa šia mašina ir tiesiogiai „išmušti“ būtinus produkto patobulinimus (o SAP atstovybė Maskvoje, pasak liudininkų, neaktyvi). Tokia situacija gana dažna versle, kai išgarsėjusi korporacija pradeda leisti gaminius kur kas žemesne kainų kategorija. Valdymas jau yra nepasiekiamas kosminiame aukštyje, kai „kosminės mintys“ yra atskirtos nuo realybės.

Jei kalbėtume konkrečiai apie Rusijos realybę, tai galbūt priežastis ta, kad pastaruosius 10 metų SAP čia taip pat egzistavo. patogiomis sąlygomis? Užtenka prisiminti net oficialias mūsų pramonės monstrų investicijų į IT sumas. O kalbant apie realius veiksmus, įprastą konkretaus produkto kūrimą ir reklamavimą, galbūt čia reikėjo įgūdžių ir kompetencijų, kurių anksčiau nereikėjo? O projektai tapo skaidresni ir nutildyti problemas nebėra taip paprasta, kaip stambaus masto įgyvendinimuose, kur yra per daug interesų, kad būtų galima atskleisti negražius rezultatus.

Akivaizdu, kad ERP sistemos diegimo tikslai yra dideli pramonės įmonė dažnai toli nuo pačios automatizavimo (ir vis dar didelis klausimas, kaip tokie diegimai turėjo teigiamos įtakos Rusijos pramonei), tačiau SVV segmente šis metodas neveiks. Atkreipiu dėmesį, kad išankstinis pardavimas atliekamas aukštu profesionalumu, kas nenuostabu, turint omenyje SAP darbuotojų ir partnerių kompetenciją. Tačiau ar etiška pasinaudoti Rusijos vadovų nekompetencija ir sumaniai ja manipuliuoti? O mes kalbame apie produktą, kuris skirtas „uždaryti“ visus esminius įmonės valdymo klausimus. Tiekėjo padėtis čia turi būti nepriekaištinga.

Beje, be šios SAP pozicijos: 2006 m. lapkričio 15 d. apskritojo stalo metu buvo oficialiai paskelbti nauji požiūriai į darbą su partneriais, dirbančiais su MVĮ. SAP teigia, kad produkto diegimą atliks tik partneriai. O pardavėjas „atliks bendrąjį užsakymų valdymą ir pateikimą“. Na, o pozicija visai logiška, visiško atsakomybės už projekto rezultatą nuėmimo požiūriu. Tai yra, viena vertus, už Rusijos lyderiai priimant sprendimą įsigyti programinę įrangą, kils ginčas dėl kūrėjo prekės ženklo tvirtumo, kita vertus, vienas prieš vieną klientai liks su partneriu. O pastarasis savo ruožtu yra „vienas prieš vieną“ su produktu. Jei vis dar abejojate, ar įdiegti SAP Business One, pabandykite tiesiogiai pasikalbėti su įmonės, kurioje tariamai veikia šis sprendimas, savininku. Taip pat pabandykite užduoti bent kai kuriuos šiame straipsnyje iškeltus klausimus SAP Business One sprendimų pardavimo vadovui.

Vladlenas Tatarskis

SAP diegimas nuo nulio

Naujų ar esamų valdymo informacinių sistemų tobulinimas, remiantis programinės įrangos produktai SAP SE įmones SKYRISE vykdo projektų forma pagal patikrintas ASAP, ASAP Focus, PMBOK metodikas.

ERP klasės IMS diegimo (plėtros) projektai priklauso sudėtingų kompleksinių projektų klasei ir apima ne tik techninis įgyvendinimas verslo sprendimai, bet ir sistemos nustatymo bei naudojimo įgūdžių perdavimas Kliento darbuotojams.

Būtina glaudi sąveika „klientas-konsultantas“ visuose darbo etapuose įgyvendinama sukuriant jungtį darbo grupė projektą. Sprendimų kūrimas ir jų diegimas sistemoje vyksta tiesiogiai dalyvaujant Užsakovo įmonės ekspertams ir techniniams specialistams, o patys sprendimai ir rezultatai tampa jau projekto metu. intelektinė nuosavybė klientų įmonė.

Sistemingai organizuojamas projektas pereina šiuos etapus:

• Projekto inicijavimas
• Koncepcinis dizainas (dizaininių sprendimų kūrimas)
• Projektinių sprendimų techninis įgyvendinimas
• Testavimas
• Vartotojų mokymas
• Pasirengimas OPE paleidimui
• Sistemos paleidimas į produktyvų veikimą ir jos priežiūra

SKYRISE perima darbų apimties, grafikų ir terminų, išteklių ir projekto rezultatų kokybės valdymą. Tuo pačiu metu Valdančioji taryba ir projekto komandos nariai iš Užsakovo pusės visada turi galimybę kontroliuoti ir dalyvauti priimant projekto sprendimus.

SKYRISE didelę reikšmę teikia turimai pramonės patirtimi kuriant informacines sistemas ir geriausios pramonės praktikos modelius (SAP Best Practices) (taip pat žiūrėkite – pramonės sprendimai).

Kada būtina įdiegti SAP nuo nulio

• Įmonė vykdo verslą naudodama ne SAP sprendimą ir susidūrė su technologiniais apribojimais.
• Įmonė yra startuolis ir svarsto pagrindinės informacijos platformos pasirinkimą
• Įmonė gamina didelius organizacinių pokyčių, įskaitant susijungimus ir įsigijimus, arba suderintą veiklos pakeitimą

Kiekvienas iš šių skambučių turi savo darbo scenarijus. Ir už tai
norint pasiūlyti tinkamą sprendimą, būtina detaliai atspindėti tokiai sistemai keliamus reikalavimus ir vėliau pasirinkti technologinis sprendimas atitinkanti įmonės plėtros strategiją.

Išleiskite SAP įmonės šabloną

Remiantis sukurtais automatizavimo poreikiais, jo paspartinimui gali būti naudojamas jau sukurtas sprendimas – Šablonas (Šablonas).

Įmonės šablonas paprastai kuriamas dideliam tarptautiniam holdingui, kai to reikia:
• Suvienyti verslą
• Atsižvelkite į vietinius reikalavimus
• Sujunkite duomenis vienoje informacijos erdvėje

Taip pat galima naudoti pramonės šabloną iš pramonės sprendimų rinkinio (SAP geriausios praktikos).

SAP produktyvumo sistemos funkcionalumo išplėtimas

Gamybinės sistemos funkcionalumo išplėtimas

Gamybinės sistemos funkcionalumo išplėtimas turi savo specifiką. Neteisingi pakeitimai gali sutrikdyti produktyvią sistemą, dėl ko gali būti sustabdyta gamyba arba gabenimas, o tai verslui atneš daug darbo.

1. Visi pakeitimai turi būti atliekami remiantis patikrinta metodika
2. Visi pakeitimai turi būti suplanuoti
3. Visada turėkite planą, kaip anuliuoti pakeitimus
4. Funkcionalumas turėtų būti patikrintas atsižvelgiant į išplėstą pagrindinių verslo procesų funkcinę sritį,
   taip pat praplėstos organizacinės apimties požiūriu

Funkcionalumo išplėtimas paprastai atliekamas naudojant ASAP diegimo metodiką.

Pasirinktinių funkcijų kūrimas

Pasirinktinio funkcionalumo kūrimas dažniausiai suprantamas kaip nestandartinių funkcijų kūrimas.
Tuo pačiu, diegiant vartotojo funkcionalumą, svarbu suprasti duomenų tvarkymo (žinynų), operacijų, ataskaitų kūrimo principus.
Tokių pokyčių pavyzdžiai:

1. Brūkšninio kodo nuskaitymo įrankiai su mobiliuosius įrenginius- nuoroda
2. Komercinės įrangos valdymo sistema –
   nuoroda
3. Lėšų valdymo sistema asmeninė apsauga- nuoroda

Perkėlimas į SAP HANA

Perėjimas prie SAP HANA (High-Performance Analytic Appliance) vykdomas pagal SAP Activate metodiką.
1. Pirmiausia aprašomas visas naudojamų verslo procesų sąrašas
2. Aprašytas visas naudotų žinynų sąrašas
3. Aprašytas visas naudojamų sąsajų sąrašas
4. Įsigytoje įrangoje (On Premise versijos atveju) įdiegta SAP HANA programinė įranga.
5. Vartotojai tobulina funkcionalumą
6. Katalogai ir istoriniai duomenys perkeliami iš senosios sistemos į naują naudojant specialius įrankius
7. Funkcionalumas išbandomas naujoje sistemoje.
8. Sąsajos aktyvuojamos
9. Vyksta perėjimas prie naujos platformos

Atstovauja automatizuota sistema pagrindinių įmonės vidinių procesų valdymas, apimantis apskaitą, finansus, gamybą, prekybą, personalo valdymą, sandėlio atsargas ir daugelį kitų veiklos sričių. Geriausia verslo procesų praktika, lankstumas, mastelio keitimas, prisitaikymas prie bet kurios šalies teisinio konteksto ir konkrečios įmonės individualių poreikių yra pagrindiniai Vokietijos programinės įrangos kūrėjų sukurtos sistemos, kuri tapo viena dažniausiai naudojamų visame pasaulyje, sėkmės veiksniai.

SAP įdiegimas yra rimtas, kelių etapų verslo perėjimo prie iš esmės skirtingų valdymo formų procesas. Tai apima išankstinį projekto parengimą ir optimalių sprendimų parinkimą tiek iš techninės, tiek iš finansinės pusės.

Vienas iš aktualiausių klausimų, dominančių klientus, nusprendusius diegti SAP, yra projekto kaina. Jį sudaro daugybė veiksnių, tačiau mūsų įmonei jos pagrįstumas yra svarbiausias sėkmingo projekto įgyvendinimo kriterijus. Mūsų ekspertai siūlo racionalius sprendimus, kurios finansinė pusė apskaičiuojama atsižvelgiant į maksimalią praktinę grąžą konkrečiam klientui.

SAP sistemos įdiegimas vykstančių pertvarkų gylio požiūriu gali būti laikomas vienu svarbiausių etapų įmonės raidos istorijoje, kurio sėkmė priklauso nuo gerai koordinuoto kūrėjų ir pačios įmonės darbuotojų darbo. . Tuo pačiu sistemos diegime dalyvauja ne tik IT tarnybos, bet ir visi kiti struktūriniai padaliniai.

SAP diegimo rezultatai

SAP diegimas įmonėje leidžia spręsti įvairias gamybos, rinkodaros ir valdymo užduotis, kurios turi įtakos tiek veiklos rodikliams apskritai, tiek konkrečiose veiklos srityse.

Pagrindiniai privalumai, gauti įdiegus SAP, yra šie:

• pagamintos produkcijos (darbų, paslaugų) savikainos sumažinimas;
• darbo našumo didinimas kokybiškai keičiant esamus požiūrius, valdymo metodus ir verslo procesus;
• sutartinės drausmės ir pristatymo datų laikymosi stiprinimas;
• prieigą prie aukštos kokybės analizės;
• verslo procesų valdymo tobulinimas;
• gerinant gavimo kokybę ir greitį valdymo sprendimai;
• ir dėl visų šių transformacijų – įmonės konkurencingumo rinkoje padidėjimas, kapitalizacijos ir gaunamo pelno dydžio padidėjimas.

Pagrindiniai SAP diegimo etapai

Sėkmingas SAP kūrimas ir diegimas reikalauja visiško siūlomų SAP technologijų integravimo su esama įmonės informacine architektūra. Iš rangovo pirmiausia reikia rimtų techninių žinių, didelės SAP sistemų ir modulių diegimo patirties, taip pat gilaus verslo specifikos supratimo ir gamybinę veiklą klientas.

Pagrindiniai SAP diegimo etapai yra:

• Projekto rengimas (Ruošiamas projekto chartija, projekto planas, nuostatai. Atliekama apklausa ir kuriama sprendimo architektūra)
• Koncepcinio verslo projekto kūrimas ("būti" aprašymas SAP terminologijoje. Organizacinės struktūros; pagrindiniai duomenys; verslo procesai; išvedimo formos; ataskaitos; patobulinimai. Scenarijų paruošimas funkciniam testavimui)
• Prototipo ir FT nustatymas (Prototipo sistemos sukūrimas ir testavimas pagal parengtus scenarijus. Pagrindinių duomenų paruošimas užsakovo (žinynai). Integracijos testavimo scenarijaus parengimas)
• Sistemos ir IT pritaikymas (Integracijos testavimas) (Sistemos derinimas pagal funkcinio testavimo rezultatus. Integracijos testavimo atlikimas. Bazinių duomenų užbaigimas. Projekto metu būtini patobulinimai, kurie paprastai užima ne daugiau 10-15% visos sumos darbo)
• Sistemos paruošimas produktyviai pradžiai (darbo stočių diegimas. galutinių vartotojų mokymas. Pagrindinių ir kintamų duomenų įkėlimas.)
• Produktyvi pradžia ir produktyvios pradžios palaikymas (papildomas pagrindinių ir kintamųjų duomenų įkėlimas. Operatyvinis palaikymas galutiniams vartotojams. Pirmųjų laikotarpių uždarymas)

Mūsų įmonės specialistų paruošimo lygis, gilios jų žinios gamybos procesai ir verslo valdymo mechanizmai bei mūsų pačių įdiegtos metodikos prieinamumas leidžia garantuoti greitą ir kokybišką įvairaus sudėtingumo SAP sistemų diegimą.

Kodėl projektas skirstomas į etapus ir kokiu principu dažniausiai vadovaujamasi skaidant projektą į etapus?

Tiesą sakant, viskas yra be galo paprasta, pirmasis - pagal etapo rezultatus stebimas projekto įgyvendinimas, vykdomas jo valdymas, o antrasis - patogu sutarties sąlygas susieti su etapais. : aktyvinimas, mokėjimo grafikas ir kt. Akivaizdu, kad kiekviena fazė turi baigtis tam tikru produktu, kuris šalių požiūriu gali būti laikomas sutarties dalyku ar jos dalimi.

Projektų biuro įkūrimas

Pirmasis ir dažniausiai trumpiausias projekto etapas. Labai dažnai jo pavadinimas įveda klientą į „stuporą“. Kartą, kai turėjau garbės dirbti drąsios metalurgijos įmonės vidinėje komandoje, iš aukščiausios vadovybės pasigirdo gana sarkastiški klausimai: „Ką, ar sutvarkys kėdes šiame etape?“.

Tiesą sakant, aišku, šiuo atveju ne kėdės ar net stalai statomi. Šio projekto etapo produktas iš tikrųjų yra pagrindiniai projekto valdymo dokumentai: įsakymas pradėti projektą, projekto chartija, detalus grafikas, rizikos valdymo planas, komunikacijos planas ir kt.

Dažnai fazės pavadinimą pasirenka kitas, man asmeniškai šis patinka, nes. tikrai atitinka turinį.

Apklausa

Šiame projekto etape rangovo konsultantai susipažįsta su įmonėje vykstančiais procesais, kuriuos turi automatizuoti, išnagrinėja reikalavimus. Bendravimas tarp konsultantų ir įmonės darbuotojų dažniausiai vyksta pokalbio forma, po kurio konsultantas parengia susitikimo ataskaitą. Ataskaitą turi pasirašyti visi susirinkimo dalyviai. Ateityje visi pranešimai apie atliktus interviu bus įtraukiami į ataskaitą.

Geriausia praktika – verslo procesų aprašą parengti diagramų pavidalu CASE gaminyje. Tokia diagrama vadinama „As-Is Business Process Diagram“ (toks kaip yra). Tačiau, deja, dėl didelių programinės įrangos produktų kainos ir mažos kliento paklausos ši technologija projektuose naudojama labai retai. Gaila, nes jo naudojimas leidžia daryti įvairias analitines išvadas apie verslo procesų būklę, optimizuoti ir, svarbiausia, ateityje, konceptualiai projektuojant ir kuriant modelį „Kaip bebūtų“ (TO-BE), leidžia atlikti lyginamąją analizę, t.y. leidžia numatyti ERP sistemos diegimo naudą. Šio etapo rezultatas taip pat dažnai yra atnaujintos techninės sąlygos.

Koncepcinis dizainas (modelis TO-BE)

Koncepcinio projektavimo fazė iš tikrųjų turėtų apimti apklausos etapo darbus, tačiau, kalbant apie projekto valdymą, o ypač biudžetą ir laiką, manau, geriau juos atskirti. Faktas yra tas, kad tyrimo etape rangovui jau gali paaiškėti, kad reikia koreguoti kalendorinis planas ir darbo apimtis, klausimas turėtų būti iškeltas aptarimui ir imtasi atitinkamų priemonių. Jei to nepadarysite šiame etape, vėliau to padaryti praktiškai neįmanoma (nors šiuo atveju reikia parodyti diplomatijos stebuklus).

Koncepcinio projektavimo etapas, mano nuomone, yra vienas iš sunkiausių projekto etapų. Čia dažnai susiduriama su įvairių įmonės struktūrų susidūrimais, todėl rangovui tenka nuolat ieškoti išeities iš šios situacijos. Iš tiesų, galiausiai šio konkretaus etapo įgyvendinimo sėkmė paskatins sėkmingą verslo procesų automatizavimą, atsižvelgiant į sistemos keliamus reikalavimus. Šiame projekto etape kuriamas dokumentas – koncepcinis projektas – tai taisyklė, pagal kurią ateityje bus kuriama ne tik sistemos konfigūracija, bet ir verslo procesai. Ne paslaptis, kad Informacinė sistema- tai verslo įrankis, leidžiantis priimti operatyvinius, taktinius ir strateginius sprendimus, taip pat turintis įtakos padalinių, dalyvaujančių rengiant informaciją, darbui.

Taip pat tam tikras sunkumas šiame etape yra narių kūrybiškumo ir kūrybiškumo korekcija. projekto komanda. Dirbant prie konceptualaus projekto, reikėtų papildomai konsultuotis su verslo ekspertais, organizuoti protų mūšius. Reikia padaryti viską, kad sistema būtų maksimaliai pritaikyta užsakovo poreikiams, ir tai yra pagrindinis sunkumas.

Įgyvendinimas

Suprantamiausias ir, daugelio nuomone (manau klaidinga nuomone), svarbiausias projekto etapas. Tiesą sakant, teisingai sukūrus verslo procesų ir sistemos koncepcinį modelį, nustatymų ir tobulinimo etapas sumažinamas iki grynai techninis darbas. Šios fazės sudėtingumą ir svarbą galima paaiškinti įvykiais, kurie, kaip taisyklė, vainikuoja fazę – tai integracijos testas ir produktyvi sistemos pradžia.

Integravimo testas gali vykti pagal skirtingus scenarijus, tačiau šio įvykio prasmė ta, kad atlikėjas turi įrodyti klientui, kad sistema veikia, taip pat jos tinkamumą reikalavimams. Tema tokia sudėtinga, kad šiame straipsnyje į ją nesileisiu, apie tai pakalbėsime vėliau.

Produktyvi sistemos pradžia iš principo yra būtent tas įvykis, kuriam padeda konsultacijos. Mano patirtis rodo, kad buvo įvairių produktyvių startų, ir tai taip pat labai sudėtinga ir plati tema. Leiskite pasakyti, kad jei įvyko produktyvi pradžia, tada projektas buvo sėkmingas 90 proc.

Pradinė parama

Garantinis sistemos aptarnavimas, nieko čia ypatingo nerasi. Labai sunkus etapas rangovui ir užsakovui. Darbo pradžia bet kurioje sistemoje yra lydima didelių vartotojų sunkumų ir klaidų, o pačioje sistemoje, kaip taisyklė, yra nemažai klaidų. Sunkumas daugiausia slypi tame, kad visa tai, kas išdėstyta pirmiau, vyksta vienu metu skirtingi žmonės. Šio etapo ir viso projekto sėkmei labai svarbus yra lygiagrečios apskaitos atmetimas istorinėje (senojoje) sistemoje. Atsisakius lygiagrečios apskaitos ir uždarius ataskaitinį laikotarpį, apimantį visą automatizuotų operacijų spektrą, projektas gali būti laikomas sėkmingu ir baigtu.

Laba diena, kolegos, skaitytojai, draugai!

Šiame straipsnyje pabandysiu pakalbėti apie kai kurias klaidingas nuomones, su kuriomis susiduria konsultantai ir projektų vadovai. Šios klaidingos nuomonės gali kilti įmonės, kurioje įdiegiama sistema, vadovams, paprastiems darbuotojams, kurie turės dirbti naujoje apskaitos sistema ir net iš daugumos konsultantų.

Įvadas

Vienareikšmiškai nepasakysiu, bet manau, kad beveik kiekvienas konsultantas / projektų vadovas / pokyčių vadovas, turintis pakankamai patirties ERP diegimai sistemas (čia mes nebūtinai kalbame apie SAP sistemą), šiame straipsnyje suraskite, su kuo jis iš tikrųjų susidūrė, ir sutinkate (galbūt iš dalies) su mano samprotavimais. Viskas, ką aprašysiu, yra mano asmeninė dizaino patirtis. Ir mano žemiau pateikta klasifikacija yra ne kas kita, kaip susitarimas. Kažkas gali jį pamatyti ir klasifikuoti visiškai kitaip. Paruošta diskusijai straipsnio komentaruose.

Medžiagos tema spontaniškai gimė mano galvoje, aptariant kai kuriuos projekto darbo momentus. Mūsų aptartas klausimas buvo susijęs su kai kurių rodiklių planavimo metodikos kūrimu ir automatizavimu. Kartu svarstant klausimą paaiškėjo, kad pačios metodikos dar nėra. Klausimas buvo maždaug toks: įdiegėme įmonės išteklių planavimo (ERP) sistemą. Tai kainuoja daug milijonų pinigų. Ten yra daugybė įvairios informacijos, kurią įveda tūkstantis galutinių vartotojų. Tai kodėl įmonės vadovybė negali gauti reikiamo plano/prognozės būtent iš šios sistemos?

Pažįstama? O žvelgiant iš neišmanančiojo taško, tai visai logiškas klausimas. Galbūt kolegos išgirdo tuos pačius klausimus, tik šiek tiek kitokiame kontekste, bet aš tikiu, kad taip ir buvo. Ir mes priėjome prie pirmo klaidingo supratimo.

1 klaidinga nuomonė: sistema veikia jums arba „raudonojo mygtuko sindromas“

Taigi, pas Klientą diegiame didelę ir brangią ERP sistemą (paprastumo dėlei tarkime, kad kalbame apie SAP sistemos diegimą, nors, kaip rašiau aukščiau, mano argumentai tinka ir kitoms didelėms ERP sistemoms) . Dauguma įmonės darbuotojų, net ir tiesiogiai nedalyvaudami įgyvendinime, kažkur kažką yra girdėję. Išgirdome apie licencijos kainą (kad jos per didelės), realizavimo kainą, konsultantų atlyginimus ir t.t. Užsakovo įmonės darbuotojai, tiesiogiai dirbantys su konsultantais prie diegimo, taip pat dažnai iki pat pabaigos nesupranta, kaip visa tai seksis po produktyvios pradžios. Tačiau jie taip pat turi tam tikrą supratimą apie įgyvendinimo išlaidas. Visi šie žmonės turi pilną teisę manyti, kad sistemos įdiegimas leis daugelį rankinių/rutininių operacijų atlikti automatiškai, t.y. sistema veiks jums.

Taip gimsta stereotipas. Jei Rangovo komanda apie šio stereotipo gimimą neįsivaizduoja, tai produktyvios pradžios metu susidaro situacija, kai vartotojai visiškai nuoširdžiai nustemba, kad kasdien į sistemą tenka įvesti tokį didelį kiekį informacijos. Vartotojai, dalyvavę integracijos testavime. Apmokyti vartotojai. Tie. tie žmonės, kurie teoriškai turėtų būti pasirengę dirbti sistemoje, ją suprasti ir priimti. Jų nuostaba ir nesusipratimas gali išsivystyti į pokyčių atmetimą ir atmetimą, į atvirą maištą.

Mano patirtimi buvo toks atvejis. Kai, įgijus praktinės patirties sistemoje, po produktyvaus starto įmonėje susikūrė „opozicinė koalicija“. Ši grupė žmonių sąmoningai kaupė visą negatyvą, visus konsultantų pradūrimus, visus sistemos funkcionalumo apribojimus (o kaip suprantate, SAP sistemos „funkciniai apribojimai“, lyginant, pavyzdžiui, su 1C, gali būti neįmanoma ištrinti daugelio duomenų, neįmanoma „išvalyti uodegų“). Na, atėjo „X“ valanda, kai visas šis purvo kubilas išsiliejo ant diegimo komandos, o taip pat buvo pateiktas įmonės savininkui kaip pagrindinis argumentas už grįžimą prie senosios apskaitos sistemos. Galiausiai viskas baigėsi gerai. Ir po kurio laiko žmonės, kurie buvo aršiausi naujosios sistemos priešininkai, supratę, kokie jos pranašumai, persigalvojo. BET, jei projekto vadovas (vienoje ar kitoje pusėje) būtų laiku atpažinęs problemą ir atlikęs reikiamus patikslinimus, tokių protestų ir skandalų būtų buvę galima išvengti.

Paminėjau raudonojo mygtuko sindromą. Tai savotiškas dviratis tarp kolegų konsultantų. Esmė ta pati. Kiekvienas vartotojas vienokiu ar kitokiu laipsniu nori, kad jo kasdien atliekamų įprastų operacijų skaičius būtų automatiškai atliktas sistemoje kažkokiu fantastišku būdu. Tie. vartotojas prisijungia, o sistemos sąsają sudaro vienas didelis raudonas mygtukas. Vartotojas paspaudžia mygtuką ir pati sistema atlieka visas reikalingas operacijas. O vartotojas šiuo metu geria arbatą. Konsultuojantis folkloru raudoną mygtuką pavertė raudonu pedalu. Kodėl pedalas? Tada, kad tada galite paspausti koja, ir abi rankos yra laisvos. Vienas – geri arbatą, kitas – žaidi pasjansą. J Visa tai, žinoma, pokštas, tačiau daugelis vartotojų nepavargsta stebėtis, kaip už tokius pinigus įdiegta sistema negali „šiek tiek pagalvoti už žmogų“.

Klaidinga nuomonė Nr. 2: Sistemos įdiegimas „iškraus“ galutinius vartotojus

Tiesą sakant, 2 klaida yra ypatingas (lengvas) pirmosios klaidos atvejis. Bet aš jį išskyriau į atskirą skyrių, nes su tokia klaidinga nuomone susiduriama daug dažniau. Iš ten auga „kojos“. Palyginus senų ir naujų apskaitos sistemų statumo laipsnį ir sąnaudas, vartotojai gali daryti neteisingus ir nepriekaištingus apmąstymus bei išvadas praktikoje. Nauja sistema leis man iš dalies automatizuoti arba kažkaip stebuklingai perkelti kai kurias savo funkcijas kam nors kitam.

Šiuo atveju turime dvi medalio puses. Kažkokia dalis darbuotojų miega ir mato, kaip jiems veikia sistema (visai ar iš dalies – žr. kliedesį Nr. 1). Kita dalis įmonės darbuotojų žiūri toliau ir mato tai kaip problemą. Juk jei dabar sistema kai kurias funkcijas atlieka pati, tuomet reikėtų sumažinti darbuotojų, reikalingų atlikti įprastines operacijas, skaičių. Ši problema taip pat gali sukelti nemalonių pasekmių, netgi atskirų įmonės darbuotojų / padalinių sabotažą.

Noriu aprašyti dar vieną pavyzdį iš savo patirties. Nežinau, ar jis priklauso #1 ar #2. Jis (pavyzdys) įvairiais laipsniais susijęs su abiem.

Didelei įmonei, vienai pirmaujančių konsultacinių firmų pasaulyje, buvo parašyta atskira kaštų apskaitos metodika. Reikalavimai metodikai buvo labai griežti. Labai svarbus buvo metodikos nuostatų išplėtojimas ir aukštas galutinių išlaidų paskirstymo užsakovo įmonei rezultatų detalizavimas. Antrasis metodikos kūrimo proceso etapas buvo jos automatizavimas, kuris buvo atliktas naudojant SAP BW sistemą. Metodiką automatizavo, vartotojus apmokė, darbų kokybę tikrino metodiką sukūrusi įmonė. Klientas liko visiškai patenkintas darbo rezultatais. Tačiau, kad metodika veiktų SAP BW, prireikė gana daug pradinės informacijos (kaip jau rašiau, Klientas sumokėjo didelis dėmesys išlaidų paskirstymo informacija). Dalis duomenų buvo įkelta iš SAP ERP. Dalis duomenų iš taikomųjų sistemų. Dalis buvo suvyniota rankiniu būdu MS Excel ir naudojant specialius formatusįkeltas į BW. Šiam darbui net buvo skirti specialūs žmonės. Viskas atrodė gerai. Tačiau po kurio laiko Užsakovo įmonę pradėjo palikti darbuotojai, kurie buvo pagrindiniai sukurtos metodikos panaudojimo ideologai, dalyvavo ją kuriant ir priimant. Tai buvo žmonės, kurie, be kita ko, suprato, kaip svarbu paruošti reikiamą tomą pirminė informacija gauti teisingus galutinio paskirstymo rezultatus. Be to, po kiek laiko Klientas sulaukė prašymų supaprastinti skaičiavimų detalumą. Pagrindinė priežastis – per daug pradinių duomenų, kuriuos reikia paruošti. Supaprastinimas buvo atliktas keliomis iteracijomis (vėlgi, nes atsiranda Kliento reikalavimai). Ir galiausiai liko „kelmas“ iš detalaus analitinio modelio, kuris parodė kai kuriuos apibendrintus duomenis. Apie buvusį detalumo laipsnį kalbėti nereikėjo.

Ką norėjau parodyti šiuo pavyzdžiu. Tai, kad Užsakovo įmonės nesupratimas dėl darbų kiekio, kurį privalo atlikti jos darbuotojai, praranda beveik visus šio didelio masto ir gana brangaus darbo rezultatus.

Beje, straipsnio pradžioje minėjau situaciją, kai Klientas reikalauja pateikti kokį nors modelį (planą, prognozę) iš sistemos pagal turimus duomenis. Tai taip pat labai paplitusi klaidinga nuomonė. Bet atskirai neišskirsiu. Tai taip pat taikoma 1 ir 2 klaidoms (arba kažkur tarp jų). Esmė ta, kad Kliento įmonės vadovybė ar verslo savininkas nelabai supranta algoritmo ir pradinių duomenų skirtumus. Galiausiai, bet koks modelis, prognozė, technika susideda iš:

A. Kažkoks algoritmas, išreikštas aiškiomis ir suprantamomis matematinėmis/statistinėmis formulėmis;

B. Informacijos, reikalingos modeliui užpildyti duomenimis ir kuria bus grindžiama ateities prognozė, sąrašas.

Žmonės kažkodėl tiki, kad sistema, užpildyta duomenimis, pati sukurs būtini skaičiavimai ir daryti prognozes. Tai netiesa.

Kaip išvengti problemų dėl šių dviejų (1 ir 2) klaidingų nuomonių? Būtina sistemingai aiškinti visų įmonės lygių žmonėms (paprastiems darbuotojams, žemesniems ir viduriniosios grandies vadovams, aukščiausios grandies vadovams), kad sistema nėra robotas, ne dirbtinis intelektas. Ji negali pati priimti sprendimų ar atlikti operacijų, kurioms reikia kažkokios analizės. Sistema – tai įrankis, leidžiantis įvairiais gilumo ir detalumo lygiais atspindėti įmonės verslo procesus, verslo operacijas ir verslo žingsnius. Kiek giliai ir detaliai procesai, operacijos ir atskiri žingsniai atsispindės sistemoje, sprendžiama diegimo metu. Bet kaip ten bebūtų, didžiąją dalį analitinės informacijos į sistemą įveda žmonės. Ataskaitos yra pagrįstos šia informacija. O analitinės, vadovybės ataskaitų kūrimo gilumas (skaitome, pats verslo skaidrumas, kurio siekia įmonės, diegiančios ERP sistemas) priklauso nuo įvedamos informacijos kokybės ir apimties.

Kitas svarbus punktas apie kuriuos, mano nuomone, reikėtų pranešti galutiniams vartotojams visais lygiais. Sistema diegiama ne dėl paprastų darbuotojų patogumo. Sistemos diegimo tikslas: Aiškios, išsamios ir savalaikės informacijos apie esamą įmonės būklę gavimas įmonės vadovybei priimti valdymo sprendimus. Norint pasiekti šį tikslą, galutinių vartotojų įvedamos informacijos kiekis gali net padidėti, lyginant su tuo, kas buvo senojoje apskaitos sistemoje.

3 klaidinga nuomonė: visada galite „sulenkti“ sistemą verslui

• Nepamenu, kur tai mačiau (kažkur internete), bet puikiai prisimenu frazę: „...Taip buvo daroma visada ir konsultantas turėtų tai pakartoti SAP“, yra didelės problemos pradžia.

„...Taip veikė visada, o konsultanto užduotis yra dubliuoti procesą SAP sistemoje“ – tai didelės problemos pradžia.

Verslo savininkas, pirkdamas sistemą ir mokėdamas už jos įdiegimą, nori iš šios sistemos išspausti viską, ką jam davė senasis, ir daug daugiau iš viršaus. Pagal principą „moku, užsakau muziką“ tai yra daugiau nei pagrįsta. Vėlgi, atsižvelgiant į sistemos kainą ir statumą, susidaro klaidingas įspūdis, kad ji visada gali būti pritaikyta verslui, „įtempta“ į esamus verslo procesus be peržiūros / peržiūros.