În condiții ideale, un proiect poate fi finalizat la timp, în limita bugetului și cu cea mai mare eficiență. Este important să existe o abordare standard a sistemelor și a procedurilor pentru a ajuta companiile noi să implementeze SAP cu succes. Această abordare (numită „metodologie”) poate să nu fie cea mai eficientă, dar va garanta succesul în condiții optime. Companiile supraviețuiesc și cresc nu pentru că plănuiesc pentru condiții ideale sau cel mai rău caz, ci pentru că planifică conditii optime. În cazul implementării SAP, metodologia de implementare trebuie să asigure succesul proiectului în condiții dificile de afaceri, structuri organizatorice și de resurse, termene limită etc. Metodologia de implementare are următoarele aspecte:

Modelarea proceselor de afaceri: Compania determină procesele de afaceri dorite sau necesare.

Maparea proceselor întreprinderii cu procesele suportate de SAP: Compania specifică procese și funcționalități SAP standard care îndeplinesc cerințele proceselor modelate.

Analiza decalajelor: Compania evaluează discrepanțele sau decalajele dintre funcționalitatea standard SAP și cerințele proceselor modelate.

Definiția finală a domeniului de aplicare al proiectului de implementare SAP: compania determină domeniul de aplicare al implementării SAP, adică indică ce procese vor fi implementate împreună cu SAP.

Configurarea sistemului SAP: Compania configurează setările de bază SAP utilizând Ghidul de implementare pentru a îndeplini cerințele stabilite anterior (consultați Configurarea prin Ghidul de implementare în Capitolul 12). Toate setările sunt făcute în clientul 001.

Testarea unui sistem SAP personalizat: funcționalitatea sistemului configurat este testată folosind date reale.

Lacunele de funcționalitate detectate pot fi abordate folosind următoarele măsuri:

Dezvoltarea de soluții pentru a obține funcționalitatea dorită, implementând configurația corespunzătoare.

Programarea funcționalității dorite în ERP prin setările utilizatorului.

Instalarea de produse software suplimentare de la alte companii certificate pentru compatibilitate cu sistemul SAP prin programul SAP Additional Software Program (CSP).

Întârzierea implementării acestei funcționalități până la următoarea versiune de SAP sau la următoarea actualizare în care este furnizată această funcționalitate.

Schimbarea radicală a unui proces de afaceri astfel încât să fie compatibil cu funcționalitatea SAP și obținerea aceluiași rezultat.

Modificarea directă a SAP, deși nu este recomandată, deoarece modificările codurilor sursă ale programului vor anula garanția SAP. Mai mult, modificat software este posibil să nu fie compatibil cu versiunile viitoare de SAP.

Sistemul SAP oferă un mediu complet R/3 Business Engineer pentru a ajuta la implementarea SAP. Când modelați procesele de afaceri SAP, este posibil să utilizați oricare dintre următoarele instrumente: IDS Sheer ARIS, Microsoft VISIO, IntelliCorp LiveModel și Enterprise Charter. Acestea se bazează pe modelul de referință R/3 și oferă o interfață directă pentru interacțiunea cu funcționalitatea sistemului R/3. Acest lucru facilitează foarte mult înțelegerea sistemului, deoarece vă permite să începeți anumite tranzacții SAP direct din mediul de modelare: pe de altă parte, modelele de proces furnizate de aceste sisteme oferă un context complet pentru o anumită tranzacție SAP.

Modelul de referință R/3 și instrumentele menționate mai sus utilizează tehnologia de modelare recomandată de SAP numită Event-Driven Process Chain (EPC). În esență, această tehnologie modelează procesele ca un set ordonat de proceduri care sunt declanșate de evenimente din cadrul sistemului. Aceste evenimente pot apărea în baze de date (de exemplu, o actualizare) sau pe ecran - de exemplu, atunci când un utilizator selectează un element de meniu sau face clic pe un link dintr-o pagină Web.

Model procedural SAP

Acesta este un model tradițional de implementare SAP și este complet integrat cu sistemul SAP. Acest model a fost introdus în 1995, concomitent cu sistemul SAP R/3 3.0. Uneori se pune sub semnul întrebării utilizarea modelului procedural SAP: există sentimentul că acest model este depășit și ar trebui abandonat în favoarea AcceleratedSAP. Cu toate acestea, trebuie avut în vedere că metodologia AcceleratedSAP este concepută în principal pentru întreprinderile mijlocii și mici, în timp ce pentru companii mari Modelul procedural SAP rămâne cea mai bună metodologie de implementare SAP. Deoarece în această carte acoperim în principal implementarea SAP pentru întreprinderile mijlocii și mici, aici voi prezenta scurtă descriere Model procedural SAP, care este ideal pentru companiile cu venituri de 1,2 miliarde USD sau mai mult.

În fig. Figura 5.8 reprezintă schematic Modelul procedural SAP.

Orez. 5.8. Model procedural SAP.

Modelul procedural SAP constă din patru faze:

1. Design organizațional și conceptual

Pregatirea proiectului

Organizarea mediului de dezvoltare

Instruirea echipei de proiect

Definirea functiilor si proceselor

Definirea interfețelor și îmbunătățirilor

Design conceptual și organizarea controlului calității.

2. Proiectare și instalare detaliată a sistemului

Configurarea parametrilor de bază

Stabilirea unei structuri organizatorice

Pregătirea datelor de bază

Configurarea proceselor și funcțiilor

Implementarea de interfețe și îmbunătățiri

Configurarea raportării

Organizarea managementului arhivelor de date

Ultima testare

Proiectare detaliată și instalare a sistemului de control al calității.

3. Pregătirea pentru lansare

Crearea documentației utilizatorului

Această notă se adresează companiilor, clienților care încep să se gândească la implementarea unui nou sistem, fie el SAP sau non-SAP. Am reușit să lucrez pe partea de clienți, pe partea de consultanță (nu doar SAP), ceea ce îmi oferă o înțelegere puțin mai largă a problemelor de ambele părți. De asemenea, aș dori să observ că problemele, sau să le numim provocări, sunt aceleași pentru orice țară. Pot judeca după munca mea la proiecte din SUA, Norvegia, Ungaria și Rusia. Exclusiv experiența mea.

Aproape toți clienții declară ca sarcina principală a implementării sistemului este unificarea proceselor, fluxul de documente și metodologia. Implementarea sistemului ar trebui să rezolve problema unificării, deoarece în cadrul proiectului apar stimulente externe sub formă de consultanți și un buget limitat de proiect, atunci când este necesar să se schimbe rapid și să devină monotone. Clientul, implicit, așteaptă cele mai bune practici de la consultant, care nu există. Să fim sinceri - cele mai bune practici reprezintă modul în care o afacere a ajuns deja la ea starea actuală. Este imposibil să transferați practicile unei companii către alta; acestea nu vor fi cele mai bune practici, ci practicile acelei alte companii. Dar acest lucru este convenabil, deoarece vă permite să priviți, sau mai degrabă să spionați, cum au făcut-o alții. Curiozitatea umană, când nu poți veni singur cu idei, așa că mergi la aproapele tău pentru idei și le îmbunătățești pentru tine.

În cadrul proiectului, consultanții se bazează pe obiectivele proiectului și cer unificarea afacerilor. Rezultatul este o situație în care unei afaceri i se cere să se stabilească pe cont propriu și să dea bani străinilor pentru aceasta. La un moment dat, m-am motivat să merg la sală - odată ce am plătit, apoi „voi merge”. Unificarea în sine nu este, de asemenea, un proces foarte clar. Imaginați-vă o afacere mare cu multe companii, funcții diferite, ierarhii de management diferite. Un exemplu simplu: o fabrică mare cu zeci de mii de angajați și o companie minusculă cu vânzători de produse pentru export. Și toate acestea sunt într-un singur domeniu al proiectului, unde trebuie să existe procese, documente și metode unificate. Pentru unii, cea mai mică schimbare va reveni pentru a bântui numărul, fondurile și eficiența închiderii perioadei, în timp ce alții nu o vor observa deloc. Iar eliminarea unuia dintre bonusuri pentru primul va fi pur și simplu un alt tip de acumulare, în timp ce pentru cel din urmă poate îngropa motivația vânzătorilor. Pentru că unificarea.

Raportarea, în special raportarea internă, este o altă critică pentru ambele părți. Compania spune că sunt necesare rapoarte, de obicei în forme stabilite, iar consultanții oferă „unele descărcări ciudate din sistem într-un format strâmb”. Între fundații și progres apare un conflict, în care practica consacrată într-o întreprindere de management de documente câștigă de obicei. Dacă un certificat de volume fizice ar trebui să fie pe biroul managerului de atelier în fiecare dimineață, atunci niciun sistem nu va ajuta până când șeful începe să deschidă sistemul dimineața. În Occident, această practică este mai puțin frecventă atunci când clientul solicită generarea de rapoarte pe hârtie. Oamenii lucrează cu tehnologii moderne mai mult și mai mult, astfel încât fluxul de documente fără hârtie este dezvoltat și proiectele sunt lansate mai ușor. Desigur, acest lucru nu se aplică raportării legislative.

Metodologia este cea mai mare cantitate de muncă din proiect. Vă voi spune un secret că ei vorbesc adesea despre necesitatea unificării proceselor, dar în practică procesele ocupă 10% din munca efectivă privind unificarea. Principalul lucru este documentele și calculele, iar acest lucru este adesea legat de cerințele legale, în timp ce procesele nu sunt practic reglementate de legi. Prin metodologie mă refer la algoritmi pentru calcularea anumitor cantități, reguli de completare a rapoartelor și formulare de ieșire. La intrarea în proiect, clientului îi place să opereze cu numerele 80/20, 70/30 sau alte valori specifice care măsoară rezultatul unificării. Pe de o parte, ce diferență are câte tipuri de plată vor exista, deoarece aceasta este doar o carte de referință? Pe de altă parte, este necesar la toate nivelurile să înțelegem ce este fondul de salarii, ce sunt costurile cu personalul (acest concept este de obicei mai larg decât fondul de salarii). Din punctul meu de vedere, unificarea ideală tinde spre zero, spre simplificare la un nivel maxim care nu contravine legii și obiectivelor de afaceri.

În cadrul proiectului, când vine vorba de unificarea metodologiei, din domeniu apar multe probleme legate de HR. contabilitate fiscală, economie intreprinderii, contabilitate, juridic. Adesea aceste zone nu au un singur titular care să poată, de la înălțimea sa, să decidă asupra uniformității. Fiecare departament se toarnă în sucul său, ceea ce este dezvăluit în timpul discuțiilor despre același catalog de tipuri de plăți (îmi cer scuze pentru exemplul banal, dar acesta este punctul cel mai dureros din toate proiectele SAP HCM).

Am văzut această abordare în practica occidentală. Există o parte principală salariile- salariu sau tarif. Formarea acestuia se stabilește după un singur algoritm pentru toate categoriile de salariați, indiferent de metoda de contabilitate și de natura muncii. Acest piesa de baza toate departamentele înțeleg la fel. Partea motivațională (bonusuri, indemnizații, plăți suplimentare) este formată din mai multe tipuri principale de angajamente, care se numesc în cuvinte generale (de exemplu, „Bonus pentru rezultate”, „Bonus pentru calitate”, „Bonus pentru condiții de muncă”, etc. .), iar ceea ce este în interiorul acestor angajamente este atribuit fiecărui departament. Astfel, „Bonus de rezultat” are o semnificație pentru vânzători, alta pentru lucrători și a treia pentru managerii de top. Și nu contează cum se calculează această valoare. Din perspectiva managementului personalului, aceasta este o sumă care trebuie calculată și furnizată de departamentul responsabil. Nimănui nu-i pasă de modul în care acest departament calculează și gestionează această acumulare, deoarece aceasta este responsabilitatea directă a șefului aceluiași departament. Această soluție se încadrează perfect în conceptul de unificare: numărul de algoritmi din zona de atenție HR este minim, motivația fiecărui grup de personal este determinată în zona întreprinderii sau diviziei corespunzătoare, toată lumea are aceeași înțelegerea fondului, durerile de cap de HR tind la zero, deoarece funcția este descentralizată. Lipsa automatizării? Deloc. Deoarece fiecare departament sau întreprindere trăiește în propriul ritm (propriul său sistem de motivare, propriii indicatori, propria viteză de lucru și evaluarea rezultatelor), fiecare departament este preocupat în mod independent de instrumentele pentru îndeplinirea eficientă a acestei funcții. Pentru unii, Excel o dată pe an este suficient, în timp ce alții au nevoie de integrare online cu sistemele de producție. Dar aceste sarcini intră în responsabilitatea acestui departament și știe mai bine decât HR cum să efectueze această sarcină în mod eficient.

Plan de acțiune pentru pregătirea proiectului de implementare SAP HCM

Pauza pentru a construi. Această abordare este adesea folosită în problemele integrării clădirilor între sisteme. Dezactivează un sistem și vezi ce se întâmplă. Dacă nu se întâmplă nimic, atunci acest sistem sau conexiune nu este necesar. În practică, aceasta înseamnă dezactivarea (eliminarea) sistematică a pașilor pentru transferul rapoartelor de la un departament la altul, reducerea utilizării anumitor cărți de referință (tipuri de plată, orare, date de timp, date de bază). De foarte multe ori, atunci când este implementat un nou sistem, o afacere vrea să transfere tot ce are. Dar nimeni nu poate spune de ce. Multe analize au fost implementate dintr-un motiv sau altul în urmă cu ani pentru un caz specific care nu mai este relevant, dar aceste analize continuă să fie completate prin inerție. Ce decizii de management se iau astăzi pe baza acestei analize?

Generarea de rapoarte și documente se datorează adesea faptului că persoanele care primesc aceste documente nu sunt echipate stații de lucru automatizate. Cele mai multe exemplu tipic poate servi ca birou de trecere și serviciu de securitate. Cereri eterne pe hârtie semnate de persoana responsabilă oficial. Poate ar trebui să le oferim posibilitatea de a juca uneori solitaire pe un computer? Costul unei stații de lucru automatizate poate fi mai ieftin decât gestionarea documentelor pe hârtie.

Procese. Acesta este probabil cel mai popular cuvânt în timpul implementării. Toată lumea vrea să simplifice și să unifice procesele. Dacă te uiți la procesele de după implementarea SAP și înainte, nu vor fi atât de multe diferențe cât a existat zgomot în jurul lui. Este foarte ușor să unificați procesele fără a fi legat de sistem. Luăm cea mai simplă versiune a procesului și cea mai complexă (ca mai sus în exemplul cu instalația și vânzătorii). Să ne uităm la modul în care diferă (cu un grad ridicat de probabilitate, diferențele vor fi în numărul de comunicații și forme de ieșire) și aducem procesele la cel mai complex nivel pentru toate întreprinderile. Și apoi mușcăm treptele conform primului principiu „rupe pentru a construi”. Nu este nevoie să construiți diagrame și poezii frumoase - în viața de zi cu zi, nimeni nu se uită la aceste cărți în mai multe volume. Un tabel simplu în Excel vă va ajuta.

Hârtii. Al doilea subiect dureros după metodologie. Hârtiile sunt tot ceea ce legea nu are nevoie. O companie a efectuat un experiment cu eliminarea imprimantelor. Oamenii nu au putut să imprime documente din punct de vedere fizic. După șase luni, numărul documentelor trimise prin e-mail a scăzut semnificativ. În loc de „Unde este raportul?” A început să apară întrebarea: „Unde pot să mă uit?” Cred că există documente care nu pot fi unificate. De exemplu, acorduri suplimentare La contracte de munca. Este suficient să procesezi documentele pentru cele mai frecvente cazuri și să le unificăm și să le automatizezi. Luați orice altceva în afara domeniului de aplicare al proiectului și al unificării, ca într-o situație cu bonus pentru rezultate. Odată cu selecția în masă și angajarea în afaceri cu amănuntul, documentele sunt ușor unificate și automatizate, dar de ce faceți acest lucru pentru giganții industriali?

Oameni și proiect. Acesta este subiectul cel mai sensibil. Orice manager știe că oamenii sunt sensibili la schimbare. Chiar și rearanjarea mesei în birou poate fi considerată o declarație de război, lipsă de respect față de cei dați întreprinderii cei mai buni ani viaţă. Când începe un proiect de implementare a unui astfel de sistem, și acesta este un proiect mare, fiecare participant în afaceri simte moral că acest lucru este temporar și împotriva lui. Chiar și managerul de proiect are îngrijorări că după proiect rolul lui se va încheia și nu va mai fi nevoie de el de către întreprindere. Înainte de a începe un proiect, oamenii trebuie să aibă o înțelegere clară a ceea ce li se va întâmpla după finalizarea proiectului. Orice proiect este stresant muncă suplimentară, care este diferit de cel obișnuit. Mulți participanți la proiect văd acest lucru ca pe o sarcină suplimentară care nu poate fi compensată în niciun fel. Merită să vă gândiți în avans la motivarea oamenilor să lucreze eficient în proiect, și nu sub lovitura „altfel, vă vom concedia”.

Comunicare sau „vorbire”. Mulți manageri au devenit manageri pentru că au început sau au putut să vorbească. Formulează corect și transmite-ți gândurile interlocutorului tău. Când începe proiectul, ei uită de el. Proiectul presupune implicarea mai multor oameni decât suntem obișnuiți să vedem zilnic. Apare o nouă barieră care trebuie depășită pentru a obține rezultate. Dar aici este problema - nu există motivație. De ce să merg să vorbesc cu cineva dacă nu-mi oferă nimic personal. Cu managerul sau subalternii dvs. - sunteți întotdeauna bineveniți, deoarece stimulentele sunt clare. Și aici sunt complet diferiți oameni (atât în ​​business, cât și consultanți externi), rezultatele comunicării cu care nu oferă nicio motivație. Ca urmare, vedem o lipsă constantă de informații în rândul tuturor participanților la proiect la toate nivelurile. Pentru a reduce riscurile potențiale datorate comunicării, trebuie să stabiliți reguli de comunicare înainte de proiect. Nu reglementări formale despre cine, unde, de ce și când, ci altceva. În practică, aceasta poate fi organizarea inițiativelor de proiect care, într-un plan strategic, vor conduce participanții înșiși să înțeleagă necesitatea implementării unui nou sistem. Anterior, întreprinderile aveau lucruri precum „ratsuhi” - propuneri de raționalizare, a căror implementare ar îmbunătăți într-un fel întreprinderea sau procesul. Aceasta este o inițiativă de proiect care poate implica număr mare oameni fără a anunța proiectul, pregătind astfel atât echipa, cât și afacerea pentru schimbări.

Cel mai important, din punctul meu de vedere, așa cum s-a remarcat în mod repetat în alte articole, acesta este de a transmite obiectivul implementării cât mai exact posibil către cel mai mare număr de oameni din companie.

De ce proiectul este împărțit în faze și ce principiu este de obicei urmat atunci când se împarte un proiect în faze?

De fapt, totul este extrem de simplu, în primul rând, pe baza rezultatelor fazei, implementarea proiectului este monitorizată și gestionată, iar în al doilea rând, este convenabil să legați termenii contractului de fazele: activare, program de plată, etc. Este clar că fiecare fază trebuie să se încheie cu un anumit produs, care poate fi considerat, din punctul de vedere al părților, obiectul contractului sau partea acestuia.

Crearea unui birou de proiect

Prima și de obicei cea mai scurtă fază a proiectului. De foarte multe ori numele său derutează clientul. Odată, când am avut onoarea de a lucra în echipa internă a unui curajos întreprindere metalurgică, din partea conducerii au apărut întrebări destul de sarcastice: „Ce, în această etapă vor aranja scaune?”

De fapt, desigur, în în acest caz, Nu scaunele sau măcar mesele sunt așezate. Produsul acestei faze a proiectului îl constituie de fapt principalele documente de management al proiectului: ordinul de începere a proiectului, carta de proiect, un program detaliat, un plan de management al riscului, un plan de comunicare etc.

De multe ori numele fazei este ales diferit, personal îmi place acesta pentru că... corespunde de fapt conținutului cât mai mult posibil.

Studiu

În această fază a proiectului, consultanții contractorului se familiarizează cu procesele de la întreprindere pe care le vor automatiza și studiază cerințele. Comunicarea dintre consultanți și angajații întreprinderii are loc cel mai adesea sub forma unui interviu, după care consultantul întocmește un raport asupra întâlnirii. Raportul trebuie semnat de toți participanții la întâlnire. În viitor, toate rapoartele privind interviurile efectuate vor fi incluse în raport.

Cea mai bună practică este de a pregăti descrieri ale proceselor de afaceri sub formă de diagrame în unele produse CASE. Această diagramă se numește „As-Is (AS-IS) Business Process Diagram”. Dar, din păcate, din cauza costului ridicat al produselor software, precum și a cererii scăzute din partea clientului, această tehnologie este foarte rar folosită pe proiecte. Păcat, deoarece utilizarea lui vă permite să faceți diverse concluzii analitice despre starea proceselor de afaceri, să efectuați optimizarea și, cel mai important, în viitor, atunci când proiectați și construiți conceptual un model „Cum ar trebui să fie” (TO-BE). , vă permite analiză comparativă, adică vă permite să preziceți beneficiile implementării unui sistem ERP. Rezultatul acestei faze este, de asemenea, adesea o specificație tehnică rafinată.

Design conceptual (model TO-BE)

Faza de Proiectare Conceptuala ar trebui sa includa de fapt munca depusa in faza de Sondaj, dar din punct de vedere al managementului de proiect, si mai ales al bugetului si termenelor, cred ca este mai bine sa le separam. Faptul este că în timpul fazei de inspecție poate deveni deja clar pentru contractant necesitatea unor ajustări plan calendaristicși domeniul de activitate, problema ar trebui adusă în discuție și luate măsurile adecvate. Dacă acest lucru nu se face în această etapă, atunci este aproape imposibil să o faci mai târziu (deși în acest caz este necesar să arăți miracole ale diplomației).

Faza de proiectare conceptuală, după părerea mea, este una dintre cele mai dificile etape ale unui proiect. Aici, adesea, apar ciocniri între diferite structuri ale întreprinderii și, drept consecință, antreprenorul trebuie să caute în mod constant o cale de ieșire din situația actuală. La urma urmei, în cele din urmă, succesul implementării acestei faze particulare va da un impuls automatizării cu succes a proceselor de afaceri, ținând cont de cerințele propuse de sistem. Documentul în curs de elaborare în această etapă a proiectului, designul conceptual, este regula după care se vor construi în viitor nu doar configurația sistemului, ci și procesele de business. Nu este un secret că sistem informatic- acesta este un instrument de afaceri care vă permite să luați decizii operaționale, tactice și strategice și, de asemenea, influențează activitatea departamentelor implicate în pregătirea informațiilor.

De asemenea, o anumită dificultate în această fază constă în ajustări pentru creativitatea și creativitatea membrilor echipei de proiect. Atunci când lucrați la un proiect conceptual, ar trebui organizate consultări suplimentare cu experți în afaceri și sesiuni de brainstorming. Trebuie făcut totul pentru a se asigura că sistemul este adaptat cât mai mult posibil la cerințele clientului, iar aceasta este principala dificultate.

Implementarea

Cea mai de înțeles și, după mulți (mi se pare eronat), cea mai importantă fază a proiectului. De fapt, odată cu construirea corectă a unui model conceptual de procese și sisteme de afaceri, faza de implementare a setărilor și dezvoltării se reduce la o muncă pur tehnică. Complexitatea și importanța acestei faze pot fi explicate prin activitățile care, de regulă, încununează faza - acesta este un test de integrare și un început productiv al sistemului.

Un test de integrare poate avea loc în funcție de diferite scenarii, dar scopul acestui eveniment este că antreprenorul trebuie să dovedească clientului operabilitatea sistemului, precum și adecvarea acestuia în raport cu cerințele. Acest subiect este atât de complex încât în ​​acest articol nu voi aprofunda despre el mai târziu;

Demararea productivă a sistemului este, în principiu, tocmai jalonul pentru care lucrează consultanța. Din experiența mea, au existat diverse începuturi productive și acesta este, de asemenea, un subiect foarte complex și amplu. Pot spune doar că, dacă a avut loc un început productiv, atunci proiectul a fost un succes în proporție de 90%.

Sprijin inițial

Serviciu de garanție pentru sistem, nu sunt multe de scris aici. O fază foarte dificilă pentru antreprenor și client. Pornirea în orice sistem este însoțită de dificultăți mari și de o abundență de erori din partea utilizatorilor, iar în sistemul în sine, de regulă, există destul de multe erori. Iar dificultatea constă în mare parte în faptul că toate cele de mai sus se întâmplă simultan cu diferiți oameni. Esențială pentru succesul acestei faze și al proiectului în ansamblu este respingerea contabilității paralele în sistemul istoric (vechi). După abandonarea contabilității paralele și închiderea perioadei contabile care acoperă întreaga gamă de operațiuni automate, proiectul poate fi considerat reușit și finalizat.

Se știe că declarațiile de marketing ale vânzătorilor se depărtează uneori serios de realitate. Cu toate acestea, este general acceptat că jucătorii de piață de renume nu recurg la astfel de practici. Cu toate acestea, managerul de proiect pentru implementarea SAP Business One într-un mic firma ruseasca pe experiență personală M-am convins că „nimic uman nu este străin” companiilor respectabile.

Limita supraviețuirii

În urmă cu câțiva ani, aproape toți dezvoltatorii de sisteme ERP din lume au început să se îndrepte către segmentul IMM-urilor, care a fost declarat aproape cel mai promițător și prioritar. Au fost introduse pe piata noi produse destinate companiilor mici cu bugete IT mici. Piața rusă a aplicațiilor de afaceri nu a făcut excepție. În presa internă au apărut articole convingătoare în care îi informează pe oamenii de afaceri ruși că, în condiții de creștere a concurenței (inclusiv aderarea la OMC), aceștia nu vor putea supraviețui decât dacă au un sistem modern, automatizat. contabilitate de gestiune, planificare și control. Argumentele prezentate au fost destul de convingătoare. Drept urmare, conducerea multor întreprinderi mijlocii și mici din Rusia se gândește serios să treacă la „ceva mai bun decât Excel și 1C”. Compania noastra apartine si segmentului IMM si, datorita factorilor de mai sus, a acceptat oferta unuia dintre partenerii SAP Corporation de a introduce un produs care era atunci nou pe piata - SAP Business One (B1).

După cum reiese din broșurile publicitare, produsele software moderne care îndeplinesc standardele internaționale general acceptate au devenit în sfârșit disponibile pentru întreprinderile mici din Rusia. Vorbeam despre funcționalitate largă, preț accesibil și câteva luni de implementare. Un singur lucru a fost tăcut - că întreprinderile mici riscă mult mai mult atunci când intră în jocul „implementarii software-ului pentru întreprinderi”, deoarece, în ciuda bugetului modest în comparație cu proiectele de profil, investițiile în IT pentru o companie mică reprezintă un element semnificativ în cheltuielile sale. Și din punct de vedere al dimensiunii afacerii, introducerea unei „cutii frumoase de peste mări” poate pune cu adevărat compania în pragul supraviețuirii.

Iată o nouă întorsătură

SAP nu a făcut excepție în cursa globală pentru întreprinderile IMM-uri și în urmă cu câțiva ani a anunțat „schimbări majore în portofoliul de produse al companiei” și decizia de a face o „întorsătură totală către piața IMM-urilor” și de a include o soluție destinată companiilor mici în curs de dezvoltare în cadrul său. linie de produse. Mai mult, s-a anunțat că piața soluțiilor pentru IMM-uri este una dintre prioritățile pentru SAP. Director general, SAP CIS Alexei Shlykov apoi a comentat acest pas în felul următor: „SAP a recunoscut în timp momentul în care piața de afaceri mari, către care s-au vizat în primul rând aplicațiile de afaceri ale companiei, era aproape de saturație și era timpul să căutăm următoarele piețe de vânzare”.

Drept urmare, în 2003, a fost lansată pe piața rusă o versiune localizată a SAP Business One - o soluție care era fundamental diferită de ceea ce făcuse SAP înainte. Cu toate acestea, SAP Business One nu este o dezvoltare a unei companii germane: produsul a fost achiziționat de la dezvoltatori israelieni. Este curios că lansarea SAP Business One nu a fost însoțită de campanii publicitare de amploare - toate eforturile de promovare au rezultat în mai multe articole de informare în presă și o serie de seminarii regionale organizate de partenerii SAP pentru potențiali clienți. De asemenea, a fost anunțat oficial că costul unui loc de muncă la cheie (licențe plus consultanță de implementare) va fi de 2.500 – 3.000 de euro, iar durata implementării nu va depăși 8 săptămâni. În plus, se știa că produsul are un avantaj semnificativ față de ofertele alternative - este personalizabil, nu trebuie programat, spre deosebire de soluțiile 1C și conține deja procese de afaceri gata făcute.

De fapt, în timpul vânzării directe a companiei noastre, s-a afirmat următoarele: „În 2 luni vom implementa produsul și veți avea în funcțiune un sistem de contabilitate de gestiune cu drepturi depline.” Adevărul este că informatii de marketing despre produs nu corespunde esenței sale reale, am învățat din propria noastră experiență mai târziu. Până acum totul a sunat foarte convingător. Am fost, de asemenea, impresionați de videoclipurile demonstrative ale soluției prezentate de partenerul SAP (o companie respectată, cu vechime în regiunea noastră). În plus, a fost prezentat cel mai convingător argument - „sunteți sub aripa unui brand SAP de încredere”. Și asta ne-a spulberat toate îndoielile.

Realitatea dură

După trei luni de implementare, a devenit clar că funcționalitatea SAP Business One este, sincer, insuficientă pentru a conduce chiar și o afacere mică (70 de angajați) în condițiile rusești. De ce nu am înțeles asta mai devreme? Este o întrebare dificilă.

Produsul, după cum ni s-a spus, este destinat pieței IMM-urilor, pentru a nu trage companiile într-o etapă lungă de examinare urmată de o multi-volum. termenii de referință. Drept urmare, după etapa de testare a produsului configurat, ne-am confruntat cu o listă de „defecțiuni” de mai mult de trei foi și, fără a le repara, a fost pur și simplu inutil să punem sistemul în stare de funcționare. Unele dintre ele se refereau în mod specific la erori în funcționarea produsului, în timp ce altele se refereau la probleme de funcționalitate insuficientă a soluției. Conform listei pe care am întocmit-o, compania de implementare a fost gata să „modifice” aproximativ 30% din cerințe, dar a fost imposibil să se schimbe restul fără participarea SAP, deoarece codul de produs este închis. Implementarea acelor „ajustări” pe care partenerul este capabil să le efectueze singur a dublat imediat costul proiectului. Acest lucru a fost motivat de faptul că „produsul trebuie modificat în conformitate cu specificul proceselor de afaceri”. În același timp, îmbunătățirile au fost într-adevăr necesare, dar nu pentru „specificul” nostru, ci pur și simplu pentru a implementa, în general, un model de afaceri standard în produs. Nu au existat cereri neobișnuite din partea noastră.

În plus, după cum sa dovedit, SAP Business One nu este un sistem cu trei niveluri, ci este construit pe o arhitectură client-server. În același timp, informațiile sunt procesate nu pe server, ci pe client, ceea ce afectează direct performanța. Apropo, când am lansat sistemul în modul de testare ținând cont de cerințele hardware menționate în broșurile oficiale care descriu soluția SAP Business One, capacitățile de procesare a informațiilor declarate ale sistemului nu s-au concretizat.

De asemenea, este necesar să remarcăm câteva deficiențe grave ale SAP Business One, care nu sunt evidente la primele prezentări, ci „apar” doar în timpul procesului:

• semantica sistemului de baze de date practic nu este descrisă;
• practic nu există proceduri stocate;
• sistemul este lent și necesită resurse intensive;
• nu există formulare tipărite corespunzătoare standardele rusești contabilitate;
• Funcția de rezervare (de exemplu, produse) nu este implementată;
• contabilitatea mijloacelor fixe nu a fost implementată;
• contabilitatea decontărilor cu persoane responsabile nu a fost implementată;
• contabilitatea plăților nu este implementată corect;
• nu există posibilitatea de a atribui costuri directe și indirecte costului de producție;
• suportul pentru un depozit celular nu a fost implementat este imposibil să se țină evidența pe lot de mărfuri;
• capacitatea de a gestiona sosiri de loturi la prețuri diferite nu a fost implementată;
• MRP nu funcționează în contextul unui depozit.

În același timp, SAP Business One acumulează diferențe de sumă numai în moneda națională, se întocmește un raport privind diferențele de sumă pe baza cursului de schimb de astăzi, ceea ce duce la o acumulare incorectă diferențe de sumă la efectuarea plăților.

„Deficiențele” enumerate fac în general imposibilă furnizarea de informații corecte despre activitățile companiei. În același timp, nu este în totalitate clar cum, în acest caz, SAP Business One poate fi poziționat ca sistem de contabilitate de gestiune. Cu amănuntul, angroși alte companii cu creștere rapidă nu vor putea lucra cu acest sistem din cauza limitărilor în performanța acestuia. Salvarea unui document cu 40-50 de poziții aduce sistemul într-o stupoare. Dacă există cel puțin 200-300 de astfel de documente pe zi, atunci totul se oprește pur și simplu.

Ni s-a oferit să „optimizăm” procesele de afaceri ale companiei noastre, ceea ce, în esență, este o restructurare a punctelor cheie pentru noi și mai degrabă arată ca „strângerea” unei afaceri deja existente care funcționează bine în cadrul rigid al unei soluții. Dacă nu dorim să reconstruim sistemul existent în compania noastră, ni s-a propus să finalizăm soluția. Mai mult, aici vorbim despre extinderea funcționalității soluției și necesită programare folosind așa-numitul SDK (Software Development Kit).

Dintr-o conversație cu compania de implementare, am aflat că SAP, în general, forțează partenerii să perfecționeze în mod independent funcționalitatea și să scrie așa-numitele suplimente (componente suplimentare). Aceste componente pot fi obținute comercial și de la alți parteneri care au implementat deja această funcționalitate. De exemplu, pentru a contabiliza tranzacțiile cu active fixe, trebuie să cumpărați suplimentul corespunzător, același lucru, dacă vrem să ținem evidența costurilor reale și planificate, un alt modul separat este conceput pentru a conecta soluția cu banca- sistem client. Pe lângă faptul că costul proiectului crește, mai există o latură: dacă cumpărăm un add-on de la o altă companie, atunci fie trebuie să-i implicăm în implementare pentru, din nou, bani suplimentari, fie partenerul nostru de implementare. se va ocupa de ea independent, dar nici gratuit. De fapt, se dovedește a fi un fel de „piramidă”, care crește cu atât mai mult, cu atât funcționalitatea cerută de întreprindere este mai largă.

Vinde si uita?

Este logic să presupunem că corectarea deficiențelor tehnice și tehnologice ar trebui să fie tratată direct de SAP. Aici, au apărut câteva puncte interesante în comunicarea cu biroul SAP din Moscova. Permiteți-mi să menționez că am plătit pentru asistența tehnică anuală și am avut dreptul de a conta cel puțin pe un tratament atent ca client și pe un răspuns prompt.

Voi spune imediat că niciunul dintre punctele menționate nu a fost corectat. În schimb, a existat o lungă corespondență între partener și oficialii SAP, pe care, până la urmă, partenerul chiar ne-a arătat-o. Majoritatea răspunsurilor (politicoase, dar răspunsuri scurte cu o pauză de o săptămână) s-au rezumat la faptul că sunt bine conștienți de acest sau acel „bug” și lucrează activ la el, deoarece nu suntem singurii care ne plângem acest. Aproape toate punctele pe care le-am solicitat au fost corectate noua versiune SAP Business One. Pe care îl așteptăm de aproximativ un an și jumătate.

Drept urmare, suntem de părere că „suportul tehnic” demonstrat reflectă abordarea generală a furnizorului de a face afaceri cu IMM-urile. SAP în Rusia se concentrează în mod special pe clienții mari, deoarece aceștia au posibilitatea de a investi o cantitate nedeterminată de timp și bani în proiect. Dar IMM-urile nu pot aștepta la nesfârșit și nici nu pot „hrăni” consultanții SAP în tot acest timp. Mai mult, judecând după „promptitudinea” și „conținutul” răspunsurilor la solicitările noastre, se pare că SAP este interesat doar de vânzarea de licențe, și nu se face nimic în mod specific cu privire la produs. De asemenea, este de remarcat cât de des se schimbă persoanele responsabile pentru clienții SAP Business One la SAP. Unii dintre ei, după demararea proiectului SAP pentru IMM-uri, au trecut foarte repede de la rezolvarea problemelor de promovare a SAP Business One la crearea propriei cariere în cadrul SAP, în timp ce cealaltă parte s-a mutat în alte companii.

Aritmetica de marketing

Declarația „SAP Business One este un sistem de contabilitate de gestiune” oferă marketerilor SAP un farmec aparte. Repet, ce fel de contabilitate poate exista dacă sistemul nu este capabil să ofere informații adevărate despre activitățile întreprinderii? Dacă sistemul este „tras scârțâit în afacere” de către parteneri nemulțumiți care sunt pur și simplu forțați să forțeze compania în cadrul acestei „soluții”?

Încă de la începutul lansării produsului SAP Business One pe piața rusă, s-a afirmat că aceasta este o soluție pentru întreprinderile mijlocii și mici. Este asta cu adevărat adevărat? Compania SAP însăși a anunțat în media costul unui loc de muncă la cheie (adică licență + implementare) - aproximativ 2,5-3 mii € În plus, s-a anunțat (ca avantaj al produsului) că prețul este final .

Pentru a automatiza cu adevărat procesele cheie de afaceri într-o companie mică, să zicem cu un personal de 100-200 de persoane (finanțe, vânzări, depozit, achiziții), este necesară achiziționarea a aproximativ 10-15 stații de lucru. Adică, trebuie să te bazezi pe o sumă de aproximativ 30-45 de mii de euro După cum arată practica, proprietarii micilor companii rusești care câștigă fiecare ban „cu sudoare și sânge” nu vor plăti atât de ușor 30 de mii de euro/dolari. „software”. Mai mult, este imposibil să se mențină contabilitatea fiscală și contabilitatea în sistem și, cel puțin, „1C: Contabilitate” va fi în continuare necesar. Mai mult, dacă te uiți cu atenție la implementările deja anunțate, vei vedea că proiectele cu drepturi depline sunt o excepție rară și, de regulă, vorbim de 3-5 licențe. Concluziile sugerează de la sine.

Astfel, din experiența noastră, SAP Business One poate funcționa dacă nu sunt mai mult de 10 utilizatori, într-o companie care nu are un depozit de produse cu drepturi depline și nu pot fi procesate mai mult de 2-3 comenzi de produse pe zi. Se pune întrebarea: „Este necesar un astfel de sistem pentru o companie mică în curs de dezvoltare la peste două mii de euro pe locul de munca? De ce, dacă la acest nivel este suficient să folosești Excel?”

În primul rând, conform reprezentanților partenerilor SAP, dezvoltatorii Business One sunt localizați în Israel și nu există un program clar de dezvoltare a produsului pentru piata ruseasca. Mai exact, o astfel de dezvoltare la scară globală a afacerii SAP are cea mai mică prioritate. Și oricât de activi sunt partenerii, pur și simplu nu pot face față fizic cu întreaga mașină și „elimină” îmbunătățirile necesare produsului direct (iar reprezentanța SAP din Moscova, conform martorilor oculari, este inactivă). Această situație este destul de comună pentru afaceri atunci când o corporație care și-a făcut un nume începe să producă produse într-o categorie de preț mult mai mică. Managementul este deja la o înălțime cosmică de neatins, cu „gândurile cosmice” divorțate de realitate.

Dacă vorbim în mod specific despre realitatea rusă, atunci poate că motivul este că în ultimii 10 ani SAP a existat aici în condiții prea confortabile? Este suficient să ne amintim chiar și sumele oficiale ale investițiilor în IT de către monștrii noștri industriali. Și când a fost vorba de acțiune reală, de dezvoltare normală și de promovare a unui anumit produs, poate că erau necesare abilități și competențe care nu erau necesare înainte? Iar proiectele au devenit mai transparente și nu mai este la fel de ușor să reducă la tăcere problemele ca în implementările la scară largă, unde sunt prea multe interese implicate pentru a expune publicității rezultate inestetice.

Este clar că obiectivele implementării unui sistem ERP la scară largă întreprindere industrială sunt adesea departe de automatizare în sine (și este încă o mare întrebare cum au avut astfel de implementări un impact pozitiv asupra industriei ruse), dar în segmentul IMM-urilor această abordare nu va funcționa. Observ că prevânzarea se face la un nivel înalt nivel profesional, ceea ce nu este surprinzător, având în vedere competența angajaților și partenerilor SAP. Dar este etic să profităm de incompetența managerilor ruși și să o manipulezi cu pricepere? În plus despre care vorbim despre un produs care este conceput pentru a „închide” toate problemele cheie ale managementului companiei. Poziția furnizorului aici trebuie să fie impecabilă.

Apropo, în plus despre această poziție a SAP: la masa rotundă din 15 noiembrie 2006, au fost anunțate oficial noi abordări de lucru cu partenerii care lucrează cu IMM-urile. SAP spune că implementarea produsului va fi condusă în întregime de parteneri. Și vânzătorul însuși „va asigura managementul general și plasarea comenzilor”. Ei bine, poziția este destul de logică, din punctul de vedere al înlăturării completă a răspunderii pentru rezultatul proiectului. Adică, pe de o parte, pentru managerii ruși, atunci când iau o decizie de achiziție de software, va exista o discuție cu privire la soliditatea mărcii dezvoltatorului, pe de altă parte, clienții vor rămâne „unu la unu” cu partenerul lor. . Iar acesta din urmă, la rândul său, este „unu la unu” cu produsul. Dacă mai aveți îndoieli cu privire la implementarea sau nu a SAP Business One, încercați să discutați direct cu proprietarul companiei în care se presupune că funcționează această soluție. De asemenea, încercați să întrebați managerul dvs. de vânzări SAP Business One cel puțin câteva dintre întrebările ridicate în acest articol.

Vladlen Tătarski