Riigikaitsekorralduste suurendamine ja selle täitmiseks eraldatud vahendite kulutamise kontrolli karmistamine nõudis ettevõtteid masinaehituskompleks süsteemide täiustamine juhtimisarvestus. Vene armee ümberrelvastamise ja moderniseerimise programmi elluviimise osana on tellimuste maht kasvanud, mille tulemusena on ettevõtetel muutunud keerulisemaks kaitsetoodete õigeaegne ja piisava hinnaga tootmine. Lisaks on selgelt näha suundumust tööstuses konsolideerumisele. 60% kaitsetooteid toodavad praegu suured inseneriettevõtted. Tootmise olukorra reaalajas jälgimiseks ja juhtimisarvestuse tõhusaks pidamiseks vastavalt kaasaegsete õigusaktide nõuetele peavad sellised ettevõtted aktiivselt kasutama uusi tehnoloogiaid.

Kaitsetööstuse ettevõtetes kasutatavad automaatikasüsteemid

Seoses suuremahulise tehnilise ümbervarustusega ostavad sõjatööstuskompleksi ettevõtted CNC-masinaid ja loovad automatiseeritud süsteemid juhtimine. Reeglina on sellised automatiseeritud juhtimissüsteemid ehitatud terve spetsialiseerunud kompleksi põhjal tarkvaratooted: ERP, HRM, CAD, EDMS, CPM, EAM, PLM, CAD, CAM, PDM jne Erinevate klasside infosüsteemid on omavahel sujuvalt integreeritud, mille tulemusena ehitatakse üles kaasaegne nutikas tootmine. Automaatsed juhtimissüsteemid toodete kogu elutsükli jaoks võimaldavad ettevõtetel toota konkurentsivõimelisemaid ja kõrgtehnoloogilisi tooteid.

Viimase 5 aasta jooksul on ERP-klassi süsteemid jäänud kaitsetööstuse objektide populaarseimaks IT-lahenduseks. Nende osakaal IT infrastruktuuri kõigi komponentide seas ulatub 35% .

ERP kasutamise eelised masinaehitusettevõttes

“1C:ERP Enterprise Management 2” kasutamisega tehastes ja kaitsetööstuse rajatistes, mis teostavad uurimistööd, tagatakse:

• Riigikaitsekäsu nõuete täitmine. Vastavalt föderaalseadusele “Muudatuste kohta föderaalseadus“Riigi kaitsekorralduse kohta” ja teatud seadusandlikud aktid Venemaa Föderatsioon» 29. juuni 2015 N 159-FZ, on vaja pidada eraldi kulude arvestust erinevaid suundi(raamatupidamine, juhtimine jne).
• Suletud ja järjepidev aruandlus. Masinaehitusettevõtteid kontrollivad korrapäraselt fondivalitsejad, sõjaväe esindused, maksuametid, Rosfinmonitoring, FAS, pangad jne. Tänu ERP juhtimisinfosüsteemi kasutamisele on kõik aruandlusnäitajad hõlpsasti seletatavad ja „võideldavad omavahel”. ise."
• Sõjalise vastuvõtu protseduuride lihtsustamine.
• Täielik kontroll projektijuhtimise, tootmise, rahanduse, logistika vallas.
• Tõhus juhtimine ostud ja tellimused.
• Planeerimise ja kulude reguleerimise lihtsustamine. Tööjõukulud, seadmete ja materjalide vajadused arvutatakse automaatselt.
• Tootmise planeerimise mugavus. Saate määrata iga üksiku toote valmistamise toimingute loendi, määrata neile valmimiskuupäevad ja tarnekuupäevad.
• Tootmise lähetamine.
• Seadmete õigeaegne hooldus ja remont.
• Jooksvate laovarude arvestuse automatiseerimine.
• Tootmisvõimsuse kasutamise arvestuse automatiseerimine.
• Automaatne moodustamine tootmisülesanded töötubade jaoks.
• Planeeritud töögraafikust hilinemisel koheselt teavitada.
• Automaatne ümberplaneerimine koos ülesannete täitmise tähtaegade uuendamisega.
• Automaatne tellimuste genereerimine tarnijatele.
• Võimalus teostada plaani-fakti analüüsi kulude ja tellimuste täitmise tähtaegade kohta pärast nende täitmist.
• Tellimuse täitmise fakti õigeaegne kajastamine.
• Kiire investeeringutasuvus, minimeerides mittelikviidseid varusid, vähendades seisakuid ning kõrvaldades vargused ja kuritarvitused.
• Ettevõtte juhitavuse parandamine. Tootmise olukorda saavad reaalajas jälgida kõik vastutavad isikud.

Kaitsetööstuse automatiseerimine Keskföderaalringkonnas

Tööstusettevõtted seisavad silmitsi ülesandega suurendada tööjõu ja tootmise intensiivistamist. Nende probleemide lahendamine on ilma kasutamiseta võimatu kaasaegsed süsteemid ettevõtte juhtimine. Vaatame võrdluseks tarkvaratooteid, mis pakuvad huvi lennundus- ja masinaehituskompleksi ettevõtetele: “1C: Enterprise 8”, “Parus-Enterprise 8”, “SAP R/3”, “Microsoft Dynamics Navision” või selle teine ​​nimi "Microsoft Business Solutions" Axapta" (autorite märkus: edaspidi "Axapta").

Kodumaiste süsteemide hulgas väärib märkimist tööstusettevõtte jaoks vajalikud lahendused “1C: Enterprise 8”: “1C: Management tootmisettevõte 8"; "1C: konsolideerimine 8"; "1C: ettevõtte finantsjuhtimine 8"; "1C: raamatupidamine 8"; "1C: integreeritud automatiseerimine 8"; “1C: Palgad ja personalijuhtimine 8”; "1C: kaubanduse juhtimine 8"; "1C: veebilaiend 8".

"1C: Manufacturing Enterprise Management 8" hõlmab ettevõtte peamisi äriprotsesse, tagades ühtse teaberuumi loomise kogu ettevõtte finants- ja majandustegevuse kuvamiseks, mis võimaldab teil kiiresti hinnata töö efektiivsust ja hankida teavet. lapsendamiseks juhtimisotsused. Konfiguratsioonis 8.2 võimaldab süsteem laadida töökohti, kasutades tööobjektide järjestikust liikumist ajas ja ruumis (osade paralleelset liikumist ei pakuta) ja kajastada seda graafikul. Kvantitatiivse muutusega tootmisprogramm või lisatakse plaanile uus punkt, muudetakse lisandunud tingimusi arvestades töökeskuse koormusgraafikut ja visualiseeritakse.

"PARUS-Enterprise 8" funktsionaalne koosseis: finantsjuhtimine; Logistika juhtimine; Kontroll tootmisprotsessid; Personali juhtimine; Kliendisuhete juhtimine; Äriprotsesside juhtimine; PARUS-ON-Line.

Microsoft Business Solutions Axapta lahenduse terviklik funktsionaalsus, mis hõlmab absoluutselt kõiki äritegevuse aspekte, võimaldab juurutada kaasaegseid lääne juhtimistehnoloogiaid, optimeerida peamisi äriprotsesse ja üldiselt tõsta ettevõtte juhtimise efektiivsust. Osana süsteemi lokaliseerimisest Venemaa turg raamatupidamise pidamise ülesanded ja maksuarvestus vastavalt nõuetele Venemaa seadusandlus, on välja töötatud põhivara, maksuarvestuse ja arvutuste moodulid palgad ja personaliarvestust.

"MBS Axapta" hõlmab ettevõtte äritegevust tervikuna nii sisemiste äriprotsesside kui ka partnerite ja klientidega suhtlemise seisukohast ning eelkõige selliseid aspekte nagu: analüüs ja strateegiline juhtimine; Tootmise juhtimine; kaubandus ja logistika; finantsjuhtimine; projekti juht; suhted klientidega.

SAP R/3 toetab enamikku operatsioonisüsteeme. Serveri- ja kliendisaidid võivad töötada erinevate operatsioonisüsteemide all. Siiski töötab umbes 50% SAP-i tarkvara installimistest Windowsi platvormil.

SAP R/3 süsteem koosneb rakendusmoodulite komplektist, mis toetavad ettevõtte erinevaid äriprotsesse ja on omavahel reaalajas integreeritud. Moodulite koosseis on mitmekesine: “Finants”, “Kontrollimine”, “Põhivarahaldus”, “Projektijuhtimine”, “Tootmise planeerimine”, “Materjalivoo juhtimine”, “Müük”, “Kvaliteedijuhtimine”, “Seadmete hooldus ja remont“, „Personalressursside juhtimine“, „Infovoogude juhtimine“, „Tööstuslahendused“.

Vaadeldavate süsteemide riistvaranõuded on toodud tabelis 1.

Tabel 1 – Nõuded süsteemi riistvarale.

Esitatud tarkvaratoodete maksumus ja juurutamise aeg on toodud tabelis 2.

Tabel 2 – ERP-süsteemide juurutamise maksumus ja ajastus

Ei saa öelda, et “1C: Enterprise 8” on täisväärtuslik tööstusliku raamatupidamise programm. Selle tarkvaratoote miinuseks on see, et tootmisarvestus on keskendunud omahinna arvutamisele valmistooted ja selle müügist saadavat kasumit, s.o. V see toode Tootmise planeerimiseks, ostude planeerimiseks ega tehnoloogiliste tsüklite jälgimiseks pole blokki. Süsteemis töötamine muutub keeruliseks, kui tootmine koosneb mitmest tootest (enam kui tuhande tooteartikliga), tootestruktuur on keeruline ja suur hulk tööstuslikke - tootmispersonal(rohkem kui 5 tuhat inimest).

Parus Corporationi puudused hõlmavad halvasti arenenud partnerite võrgustikku ja lennukiehitusettevõtete tootmise planeerimise lahenduste puudumist.

Ülevaade SAP R3 süsteemi funktsioonidest näitab selle võimet lahendada suurte organisatsioonide ees seisvaid peamisi probleeme. SAP R/3 on seni kõige ulatuslikum süsteem. Paljud maailmamajanduse juhid on valinud selle oma peamiseks ettevõttesüsteemiks.

SAP R/3 on konfigureeritav süsteem, nii et selle ostmisel töötab ettevõte individuaalse versiooniga, mis on kohandatud spetsiaalselt selle parameetritele. Mida laiemad on süsteemi seadistamise ja kohandamise võimalused, ilma et oleks vaja seda ümber kirjutada, seda kõrgem on selle süsteemi tehniline tase. Selle näitaja järgi on SAP/R3 maailmas juhtival kohal. Süsteemil on avatud ja standardne kasutajaliides, pakub graafiline modelleerimineäriprotsesse ja saab töötada interaktiivselt. Lisaks sisaldab SAP R/3 lahenduste komplekt tööstusharuspetsiifilisi lahendusi kosmosetööstusele.

MBS-Axapta süsteemi eripäraks on skaleeritavus ja lai valik võimalusi selle individuaalseks konfigureerimiseks. Need muudavad selle tarkvaratoote optimaalseks lahenduseks spetsiifiliste ja keerukate äriprotsessidega keskmistele ja suurtele ettevõtetele, mille töötajaskond ei ületa 10 000 inimest.

Toome välja Axapta peamised eelised: erakordne mastaapsus; optimaalne hinna ja kvaliteedi suhe (selle funktsionaalsuse taseme jaoks); rakenduste värskendamise lihtsus; terviklik analüüs ja ärikontrolli lihtsus; planeerimismoodulite olemasolu; võime rahalisi vahendeid juhtida rahvusvahelise äri; Venemaa õigusaktide nõuete täitmine; üleliigse teabe tasakaal.

Esitletavatest tarkvaratoodetest on seega masinaehitus- ja lennutööstuse tööstusettevõtetele sobivaimad Axapta ja SAP R3 süsteemid.

ERP-süsteemi investeeringu suuruse hindamiseks on vaja esitada investeerimisskeem. See koosneb eraldi plokkidest, mis esindavad finants- ja majanduskulude lõpetatud etappi:

1 ERP süsteemi juurutamise kulu;

2 kompleksi riist- ja tarkvara maksumus;

3 ERP kompleksi omamise kogukulu (aastased kulud).

Määratud kulude jagamise skeemi kasutatakse tuntud TCO (total cost of ownership) metoodikas – see on arvutustehnika, mis on loodud selleks, et aidata tarbijatel ja ärijuhtidel määrata mis tahes komponendiga seotud otseseid ja kaudseid kulusid. arvutisüsteemid. Selle rakendamise eesmärk on saada lõplik pilt, mis kajastaks teatud tööriistade ja tehnoloogiate soetamisega kaasnevaid tegelikke kulusid ning võtaks arvesse nende hilisema kasutamise kõiki aspekte.

Kuluartikkel “ERP-süsteemi juurutamise töö maksumus” on reeglina üksikasjalikult määratletud süsteemi juurutamise tööde kalkulatsioonis lepingus, mis on sõlmitud ettevõttega, kes teostab ettevõttes ERP-ruumi integreerimise protsessi. . Arvestuslikud kulud vaadeldavate süsteemide juurutamiseks on järgmised:

- "SAP R3" - umbes 0,8 miljonit rubla. aastal. Rakendusperiood on umbes kaks aastat.

- “Axapta” – umbes 1,0 miljonit aastas. Rakendusperiood on umbes aasta.

Kompleksi riist- ja tarkvara maksumus sisaldab kulusid, mis on seotud kogu tarkvaratoodete kompleksi, näiteks operatsioonisüsteemi (OS), teenuse litsentside ostmisega. tarkvara(tarkvara) ja ERP-toode ise. See artikkel sisaldab ka kogu masinapargi, nii isiklike kui ka serverijaamade ja nendega seotud sideseadmete maksumust. Kogukulu personaalarvutid(PC) ERP-kompleksis arvutatakse nende koguse ja ühe ERP-kompleksi kaasatud arvuti keskmise maksumuse andmete põhjal (tabel 3).

Võrdlevas analüüsis eeldatakse, et arvutus tehakse 50 arvuti või kliendikoha kohta, mis on kaetud ühe litsentsiga.

ERP-kompleksi omamiskulude hindamine hõlmab kahte tüüpi kulusid: kaudsed kulud ja otsesed kulud.

Kaudsed kulud hõlmavad infotehnoloogiaga seotud kulusid, mida enamik infotehnoloogiaosakondi ei eelarvesta ega mõõda. Kõige olulisem osa on tavaliselt kasutajapoolne tugi oma arvutile ja tarkvarale, samuti kolleegide abistamine. See hõlmab süsteemide sõltumatut silumist tõrgete ilmnemisel, väärtusliku teabe varundamist ja taastamist, toiminguid failide ja kataloogidega, plaanivälist koolitust tööaeg ja väikeste (või suurte) rakenduste programmeerimine.

Otsesed kulud hõlmavad kulusid, mis on seotud seadmete, tarkvara, ERP-süsteemi teenindava personali, side jms kuludega.

Otseste kulude vähendamise püüdes kärbivad paljud organisatsioonid lihtsalt IT-eelarveid, mõistmata, et tulemuseks on kaudsete kulude suurenemine – kasutajad kulutavad rohkem aega enda, sõprade ja kolleegide ülalpidamisele. Ilma üksikasjaliku aja jälgimise või statistiliselt paikapidavate vaatlusteta pole täpset viisi mõõta, kui palju aega kasutaja infotehnoloogia (IT) ülesannetele kulutas. Neile, kellel pole võimalust ega ressursse paljude tundide mõõtmiseks, on iga kategooria jaoks olemas valdkonna keskmised.

ERP kompleksi kogu omamiskulu otseste kulude hinnang on toodud tabelis 4. See hinnang on aastane kuluartikkel kogu ERP kompleksi hoolduseks ja teenindamiseks, mis aitab põhjendada ka ettevõtte arenduseelarvet. infotehnoloogiad ettevõttele.

Konservatiivsete hinnangute kohaselt erineb ühe arvuti kogu omamise maksumus oluliselt ERP-süsteemide tootjate deklareeritud väärtustest. Nii on näiteks Microsoft Business Solutions Navisioni puhul see väärtus 1500–2500 eurot ehk praeguse kursi (41 rubla/euro) järgi 61 500–102 500 rubla, arvestuslik väärtus aga 221 765,78 rubla.

See hinnang annab juurutusprojekti kuluosa üsna täpse väärtuse ning võimaldab prognoosida ka ERP-tehnoloogiasse tehtavate investeeringute efektiivsust.

Peamine raskus ERP-süsteemi juurutamisest saadava tulu määramisel ja efektiivsuse arvutamisel seisneb ettevõtte majandusliku kasu väljaselgitamises. Arvatakse, et kui ettevõte uuendust ei juuruta, tähendab see seda, et ta jääb ilma võimalusest teenida kasumit ja jääb ilma saamata jäänud kasumist. Probleemide ja tööpuuduste analüüsist saab välja selgitada, mida saaks parandada ettevõtte juhtimissüsteemide kasutuselevõtuga.

Ettevõtte majandusaruande andmete analüüsi põhjal saadi puuduste kõrvaldamise võimaluse kasutamata jätmisest “kaotamata kasum” järgmiste näitajate järgi:

10-aastase materiaalse kaupade (materjalid ja materjalid) ja põhivara (Põhivara) puuduse keskmine aastanäitaja, mis saadi halva raamatupidamise tõttu, hõõruda.

Halva raamatupidamise tõttu kogunenud üleliigsete laoartiklite 10-aastase perioodi keskmine aastanäitaja, hõõruda.

Põhivara rent 5% ulatuses nende maksumusest, ebaratsionaalse planeerimise tõttu tootmisvõimsust, (iga-aastaselt), hõõruda.

Ettevõtte statistiliste andmete põhjal moodustas ülaltoodud näitajate keskmine aastane "kaotamata kasum" 155 944 738,878 rubla, mis ületab SAP/R3 ja Axapta süsteemide ühekordsete ja aastakulude summat vastavalt 5,89 ja 7,85 korda. ja tõestab nende kasutamise tõhusust. See lähenemine ei pruugi olla täpne, kuid näitab tõsidust ettevõtte ressursside kasutamise tõhususe küsimuses.

KASUTATUD ALLIKATE LOETELU

1 Ettevõtte "1C" ametlik veebisait http://www.1c.ru

2 Axapta. Töötage tulemuste nimel http://axapta.mazzy.ru

3 Tööstuslikud lahendused CMD SOFT. Mis on Microsoft Dynamics NAV (Microsoft Navision)? http://www.cmdsoft.ru/products/microsoft_dynamics/nav

4 Sõltumatu ERP portaal http://www.erp-online.ru

5 Abramova, I.G. Masinaehitusettevõtte tootmise ettevalmistamise korraldamise ja juhtimise alused [ Elektrooniline ressurss]: elektron. õpik toetus /I.G. Abramova; Samar. olek kosmoselennundus Nime saanud ülikool S.P. Koroleva (riiklik teadusülikool); - Elektron. tekstiandmed – Samara, 2011. – 1 email. hulgimüük ketas (CD-ROM).

Esiteks projekti enda kohta: 1C:ERP rakendamine tööstusettevõttes. Kliendi juurde tulles (2015. aastal) oli tehases 5 tuhat inimest. Projekti käigus on tehas oluliselt kasvanud ja tootmismahtusid suurendanud, praegu töötab seal umbes 6,5 tuhat töötajat. 1C on installitud 1,2 tuhandele tööjaamale. Aktiivseid kasutajaid on praegu (juuni 2017) umbes 350, plaanis on neid suurendada 450-ni.

Ettevõte on osa Venemaa sõjalis-tööstuslikust kompleksist ja seetõttu on sellel oma eripära.

Enne seda projekti käivitasin keskmise suurusega ettevõtted (1000-1500 töötajat, 50-150 töökohta). Oleme juba õppinud, kuidas neid teha, olles välja töötanud selge metoodika (nüüd on mul ja minu meeskonnal keskmiselt 7-10 kuud, olenevalt selle keerukusest, et projekti viia äritegevusse.)

Kuid nagu selgus, on enam kui 2,5 tuhande töötajaga ettevõttes projekti keerukuses kvalitatiivne hüpe, mis nõuab tehnoloogia ülevaatamist.

Niisiis, järjekorras. Tehasesse jõudsime 2015. aasta lõpus. Esialgu oli ülesandeks reguleeritud raamatupidamise käivitamine. Funktsionaalse modelleerimise käigus otsustas Kliendi juhtkond (pearaamatupidaja ettepanekul) anda esmaste dokumentide sisestamise funktsiooni üle “kohapeal”. Projekti piire muudeti, et hõlmata keskladusid, laoruume, kaupluste raamatupidamist, lepingute haldamist ja BDDS-i. Reguleeritud raamatupidamise rakendamise tähtaeg nihutati 2017. aastasse ning 2016. aasta jooksul automatiseeriti “esmane” raamatupidamissüsteem.

Otsus, et funktsionaalüksused käivitatakse etappide kaupa katsetööstusse (edaspidi "OPE"), ehkki see tõi meile palju peavalu, osutus globaalselt õigeks: kui oleksime kõik korraga käivitanud, oleks lihtsalt probleemide lainesse uppunud, oh millest ma hiljem räägin.

Ausalt öeldes arvasin, et peamine raskus on kasutajate sabotaaž. Enne 1C kasutuselevõttu ei sisestanud nad midagi tsentraalselt: ühed töötasid Excelis, teised isekirjutatud süsteemides. Dokumendivoo aluseks olid “paberitükid”, mis seejärel esitati automaatjuhtimissüsteemi, et operaatorid saaksid sisestada raamatupidamisprogrammi. Siin lähenes kliendipoolne projektimeeskond asjale asjatundlikult - väljastati hulk tellimusi, allkirjastati peadirektor, mis probleemi lahendas. Tellimused ei olnud koostatud tavapärases stiilis “meie ettevõttes käivitatakse süsteem...”, vaid olid üsna konkreetsed: “sellest ja sellisest kuupäevast võtab raamatupidamine ladudest vastu ainult 1C-st väljastatud dokumente. ” Võimalike arusaamatuste välistamiseks lülitasime kohe sisse dokumentide vöötkoodi ja jagasime raamatupidamisele skannerid (tegelikult üritati Wordis inimeste poolt “joonistatud” dokumente esitada).

Käivitamise järjekord määrati järgmiselt: kesklaod, lepingud, BDDS, töökodade laoruumid, töökoja raamatupidamine ja sellest tulenevalt juba reguleeritud raamatupidamine, mis jagati ka eraldi funktsionaalseteks piirkondadeks.

Esimene (kuigi mitte peamine) probleem oli üsna etteaimatav – andmete maht. Algselt aga alahindasin selle ulatust. Näiteks lihtsalt "madala hinnaga" saldode laadimine (ilma töötlemiseta) võtab umbes 4 päeva. Ja kui tulemustes järsku ilmnevad lahknevused, siis veel neli päeva ja siis veel... See tähendab, et see tööetapp tuleb koos tellijaga planeerides väga hoolikalt läbi töötada, sõna otseses mõttes päevast päeva. Näiteks siin läksime tavapärast teed: laadisime alla ainult kataloogid ja määrasime kasutajad “esmasele” lehele, et pärast ülejäänud allalaadimise lõpetamist oleks kõik läbi viidud, kontrollitud ja sisestatud tegevusarvestusse. Seetõttu ei jõudnud me füüsiliselt kuu lõpuks raamatupidamist konsolideerida ja tagasimakseid koguda ning tegevusaruannete esitamiseks pidime kulusummad vanast süsteemist käsitsi üle kandma ja seejärel erinevate erinevuste tõttu korrigeerima. arvestusmeetodid.

Samuti ei ole kliendil palju vajalikke andmeid tavakujul ning seetõttu tuleb paluda need eelnevalt palju ette valmistada: näiteks nimekiri avatud tellimused Koguma hakkasime kolme (!!!) kuu pärast. Näib, mis võiks olla lihtsam? Ettevõttel peab olema teave selle kohta, mida ta peaks tootma ja kellele saatma ja millal. Aga nagu selgus, olid neil vormistatud kujul vaid tellimisnumbrid (Riigikaitsekorralduse eraldi arvestuse korraldamise nõue) ja toote nimetus, kogus, tähtajad jne. olid salvestatud kas kuskil Excelis või paberlepingutes.

Järgmistes projektides hakkame koos klientidega andmeedastuseks valmistuma kohe pärast projekti esimest etappi – funktsionaalset modelleerimist.

Ja mastaap ise tehtud projekteerimisel tuleb alati silmas pidada: nt algselt soovis klient omavaheliste arvelduste kujundamisel võlgnevuse lepingu etappideks jaotada, kuid pärast meiega ettevalmistustööde tööjõukulu analüüsimist loobuti sellest mõttest.

Samuti suurendab suur hulk “esmaseid” vigade maksumust: kui unustasite ootamatult mõne detaili täitmise või õpetasite neid valesti täitma (mida kahjuks juhtub), siis ei saa te "kiiresti" seda teha. käige kõik oma kätega läbi." Heal juhul saate õigesti täidetud andmed alates järgmisest kuust. See tähendab, et sellistel projektidel saate kasutada ainult väga kogenud projektimeeskonda - algajate "jambreid" ei pruugi lihtsalt olla võimalik parandada.

Lisaks seab selline skaala piloottööstuslikule käitamisele spetsiifilised nõuded: tavaliselt on lihtsate piirkondade jaoks (näiteks kesklaod) eelarves poolteist kuni kaks kuud toetust, see on ploki väljatöötamiseks täiesti piisav. Ja siin hakkasid mõned laopidajad programmi andmeid tõsiselt analüüsima alles 3 kuu pärast. See tähendab, et enne seda õppisid nad lihtsalt dokumente süsteemi sisestama. Selgus, et teiste sektsioonide käivitamise töö käigus tuli suunata ressursse suletud funktsionaalplokkide toetamiseks. Seda tuleb inimeste ja eelarvete planeerimisel arvestada.

Eraldi tasub mainida programmi kasutajate teavitamise korraldust. Kohustuslike teadete kuvamiseks on vaja eelnevalt konfiguratsiooni sisse ehitada moodulid: helistada 350 inimesele ja öelda, et juhised on uuendatud või kuluarvestus läheb täna käima, on ebareaalne. Siin aitas meid palju BSP (standardsete alamsüsteemide raamatukogu) plaaster.

Lisaks ülalkirjeldatud mastaabiprobleemile oli projekti teiseks ja peamiseks probleemiks see, et ettevõttes ei olnud ühtegi inimest, kes omaks täielikult ühegi raamatupidamisvaldkonna tööd. Alguses arvasin, et need on ainult selle taime omadused, kuid nüüd saan aru, et suurte organisatsioonide jaoks on selline olukord pigem norm. On mitu võtmekasutajat, kes haldavad mõnda oma "tükki" ise, ja on osakonnajuhataja, kellel on nende tööst oma ettekujutus. Ja nende vahel on kuristik.

Kuidas ma varem töötasin: iga protsessi jaoks selgitati välja selle Omanik, kes kujundas sellele nõuded, koostasime tööplaani, käisime selle võtmekasutajatega läbi ja seejärel kinnitasime koos omanikuga. Tavaliselt katab see tehnika 80% toimingutest hästi ja ülejäänud 20 "parandatakse" pilootoperatsiooni etapis. Seda teed käisime ka siin. Peaaegu kohe ilmnes erinevus tegelikkuse ja osakonnajuhatajate arusaamade vahel. Aga ülemused ütlesid "see ei saa olla!" ja alluvad jõuga ärikultuuri neile vastu ei olnud. Selle tulemusena sisaldas kinnitatud tööskeem liiga töömahukaid toiminguid, palju üleliigseid kontrolle ega sisaldanud teatud summa midagi, "mida neil kindlasti pole". Kõik see tuli piloottöö käigus ümber teha. Juba rakendatud ja tarnitud muudatused kirjutati lõpuks radikaalselt ümber ning EPE ise nõudis programmeerijate pidevat kohalolekut.

Kümnete inimeste vahel iga protsessi kohta teadmiste “levitamise” probleemile lisandus suur hulk pealtnäha sarnaseid osakondi (ainuüksi neil on umbes 30 keskladu), millel, vaatamata funktsioonide sarnasusele, olid omad. spetsiifikat ja oma raamatupidamislikke iseärasusi – mis tähendab, et isegi samu toiminguid saab teha mitmel viisil. Projekti alguses välja kuulutatud loosung "protsesside ühendamine" suri esimese lahingustardi ajal.

Projekti tulemusi analüüsides ei näe ma veel võimalust eriti vähendada riski, et kirjeldatud protsesside ja tegelikkuse vahel tekib oluline lahknevus: selleks, et iga osakonnaga ja seejärel nende juhtidega skeem üksikasjalikult välja töötada, Funktsionaalse modelleerimise eelarvet tuleb suurendada 5-7 korda ja klientidel on tavaliselt raske mõista selle etapi väärtust ja maksta 25% projekti maksumusest pelgalt "paberitüki" eest. Tekkis idee süsteemi testimisest mitmes osakonnas, mida proovisin mõne teise projektiga, kuid see ei õigustanud ennast täielikult.

Hetkel olen enda jaoks otsustanud, et sarnase mastaabiga projektide puhul pean leppima iteratiivse viimistlemisega - lihtsalt korraldama selle õigesti ja kaasama koheselt hindamisse kogu pilootoperatsiooni programmeerijate töö ning suurendama aega. raam kasutajatoe jaoks vähemalt kaks korda.

Projekti kolmas probleem tuleneb kahest esimesest: suur hulk kasutajaid (mille jaoks on vaja palju konsultante) ja suur hulk projekteerimisotsuseid, mis tehakse kohe isikukaitsevahendite etapis. Ja kuna ERP-s saab ühte ja sama probleemi lahendada erineval viisil, kasutavad erinevad konsultandid erinevaid meetodeid ja selle tulemusena hakkab süsteem "levima". Siin ei aita mingid “päevalõpukoosolekud”, sest tänu mahule erinevaid küsimusi konsultandid lihtsalt unustavad õhtuks palju.

Edaspidi tutvustan sellistesse projektidesse eraldi arhitekti, kes on projekti ajaks kasutajatest isoleeritud ja kelle kaudu tehakse kõik projekteerimisotsused. Samuti värskendab ta iga päev kasutusjuhiseid (al suured hulgad kasutajad vajavad neid tõesti).

Mis on tulemus? Vaatamata punnidele, pisaratele ja hallidele juustele käivitati kliendi haldusüksus. Nüüd oleme liikunud reguleerimise juurde. Loodan, et esimestel etappidel saadud kogemused aitavad selle käivitamisel kaasa.

30.01.2008, kolmapäev, 15:01 Moskva aja järgi , Tekst: Andrei Arsentjev

Viimase 5 aasta jooksul on Venemaa masinaehitustööstuses ERP-süsteemide juurutamiseks ellu viidud 387 projekti (korporatiivne infosüsteemid). Sellised andmed sisalduvad uuringus Tadviseri keskus. Kokku kasutasid kliendid süsteeme 14 müüjalt. Nagu selgus, on populaarseimad 1C lahendused, mille osakaal ühikutes oli 39,5% (TAdviser sisaldab ERP-klassi süsteemidena vaid 1C “1C UPP 8.x” lahendusi). Kokku viidi 1C lahenduste põhjal ellu 153 projekti. Samas rõhutavad mitmed analüütikud ja turuosalised, et 1C lahendused ei sobi päris masinaehituseks, kui näiteks on vaja hoida spetsifikatsioone keerukatele toodetele, korraldada uusi marsruute, planeerida ja võimsusi tasakaalustada.

Teisel kohal masinaehituse projektide arvult on Ameerika ettevõtte Infor lahendused 74 projekti. Selle põhjuseks on muu hulgas asjaolu, et kunagi väga populaarne BaanERP-süsteem kuulub praegu Inforile. 74 ERP projektist 37 on BaanERP-ist. Tadviseri sõnul on tööstuses arvestatav nõudlus ka Infori enda arenduse, Infor ERP SyteLine süsteemi (sellel põhineva 27 projekti) järele.

Järgmiseks tuleb Compassi ettevõte, millel on samanimeline ERP-süsteem. Selle lahendusi on rakendatud 37 korda. Neljandal kohal on maailma üks suuremaid korporatiivtarkvara arendajaid, Saksa firma SAP. See hõlmas 29 mySAP ERP ja SAP Business One arendust. Esiviisikusse kuuluvad ka Microsoft Dynamics 25 projektid.

Mis puudutab kodumaiste masinaehitusettevõtete nõudlust teatud ERP-toodete järele, siis siin on mitmete analüütikute sõnul mõttekas rääkida mitte ainult lahenduste populaarsusest segmendis tervikuna, vaid ka kaaluda, millised Kasutatakse ERP süsteeme enim nõutud need kliendid kõige suuremahulisemate projektide elluviimisel, millele Venemaa masinaehituse "tipud" toetuvad. Eelkõige on CNews Analyticsi andmetel Infor lahendused (14 projekti) Venemaa masinaehituse kolmekümne suurima hulgas juhtpositsioonil. Kolm selles loendis olevat ERP-projekti on mõeldud Oracle'i ja Microsoft Navi lahenduste jaoks, kaks Microsoft AX-i, IFS-i ja 1C jaoks. Ülejäänud müüjatel (Compass, Parus ja SAP) on ainult üks projekt.

“Tööstusettevõtted (ja eelkõige masinaehitus) aastal viimased aastad hakkasid oma IT-vajadusi realistlikult hindama, ütleb CNews Analyticsi ekspert Eleonora Eršova. Täna saavad nad aru, kui palju millise toote litsentse ja milliste ülesannete jaoks nad vajavad. See on müüjatele hea: selliste klientidega on mugavam ja meeldivam töötada. Samas on masinaehitus üks uuenduslikumaid majandussektoreid, mis on eriti tundlik sissetuleva turuinfo töötlemise täpsuse ja kiiruse suhtes. Selleks vajate tõhusad süsteemid infotöötlus, seetõttu on tööstusettevõtete arengu võtmepunktiks sisemiste äriprotsesside ja väliste tootmissuhete info- ja tehnoloogiline tugi. Neid ülesandeid lahendatakse muuhulgas kaasaegsete ERP-süsteemide juurutamise kaudu. Üldiselt ei saa aga väita, et masinaehitusettevõtted oleksid keerukate infosüsteemide väga aktiivsed tarbijad. Enamasti piirdutakse lihtsamate IT-vahenditega. CNews Analyticsi andmetel saab keskmine transporditehnika ettevõte endale lubada IT-projektide tellimist, mille maksumus ei ületa 300–500 tuhat dollarit.

Venemaa masinaehituse ERP-müüjad

Allikas: Tadviseri keskus

"Eelarved ERP juurutamineÜldiselt need kasvavad, tuntakse huvi personalijuhtimise funktsioonide, mitte ainult palgaarvestuse ja personaliarvestuse vastu, märgib ettevõtte Compass turundusosakonna juhataja. Lev Yakobson. Lääne "raskete" ERP-süsteemide vastu tuntakse huvi. Kuid samal ajal rakendavad lääne personalijuhtimise allsüsteeme väga vähesed. Selle tulemusena on juurutamiste protsent väga kõrge, kui Lääne ERP-süsteem kombineerida kodumaise personalijuhtimissüsteemiga. Kodumaised lahendused on funktsionaalsuselt kasvanud ja suudavad juba palju adekvaatsema raha eest pakkuda kasutajale kõiki vajalikke võimalusi. See kehtib eriti teenuste maksumuse kohta, kuna koduseid süsteeme on keskmiselt lihtsam ja kiirem rakendada ning konsultandi töötunni hind on tavaliselt palju madalam.

Lisaks brutonäitajate – projektide arvu ja nende funktsionaalse mahu ning seega ka ostetud litsentside arvu – kasvule on oluliselt muutunud ka kvalitatiivsed omadused, ütleb SAP tööstuse ärilahenduste vanemarhitekt. Aleksei Nasakin. - Esiteks on muutunud kliendinõuete põhifookus: kui varem kõlas põhiküsimus "mis teil on masinaehitusettevõtte juhtimiseks?", siis nüüd küsitakse esimese asjana "mis teil on planeerimiseks ja juhtimiseks?" tootmist, kui näeme, "et selle funktsiooniga on kõik korras, siis vaatame kõike muud." Seega on tööstusharu jõudnud arusaamisele, et tööstuse spetsiifika ja eeldatav juurutamise efektiivsus koondub reeglina funktsionaalsuse logistikaossa. Ja kas teie tarkvaratootel on täisfunktsionaalne tootmisjuhtimine, olete seda praktikas rohkem kui korra rakendanud ja siis olete tõesti "masinaehituse lahenduse" müüja või teil pole seda kõike ja teie toode on “lahendus millelegi muule väga olulisele." "". Teiseks oluliseks tööstustrendiks on spetsialisti sõnul tööstuse struktuurimuutuste järgimine, nimelt suurosaluste organiseerimine. Mida rohkem osalusi, seda nõutumad on lahendused, mis on seotud osaluste toimimine - konsolideerimine, eelarvestamine, portfelli projektijuhtimine jne. .P.

Tadviseri sõnul on masinaehituse projektide arvu poolest suurima ERP-integraatori esiviisikus ainult üks ettevõte, kelle kohta võib öelda, et ta on spetsialiseerunud selle valdkonna juurutustele Frontstep (masinaehitusettevõtete osatähtsus ERP-süsteemide osakaal siinsete ERP-projektide koguarvust ületab 56%. Ülejäänud integraatoritel on tööstusharu laiem mitmekesistamine. Lisaks kolmandale kohale tarnijate edetabelis on Compassi ettevõte uhke ERP-süsteemide juurutuste arvu poolest. See moodustab üle 8,3% koguarvust lõpetatud projektid. "Vajadus arvestada masinaehitusettevõtete äriprotsesside spetsiifikaga viib selleni, et selles valdkonnas juhivad ERP-süsteemide juurutamise turgu kohalikud, kogunenud kogemustega tegijad," märgivad teadlased.

„Tasapisi hakkab kasvama arusaam, et ainuüksi konsultantide abiga elluviimine on võimatu, vaja on luua ühine töörühm, et see on üsna pikk ja töömahukas protsess,“ rõhutab Lev Yakobson lõimumisest rääkides. . Varem uskusid paljud, et isegi eraldi alamsüsteemi juurutamise probleem on võimalik lahendada kohe, "kastist väljas". Nüüd on neid vähem."

„Lisaks valiku põhirõhu nihkele on tõusnud valijate pädevuse tase,“ lisab Aleksei Nasakin. „Kas teie lahenduses on rakendatud APS-i algoritmi?“ – see küsimus kerkib üsna esile. sageli."

Esialgne probleem ja ülesanded

Ettevõte kasutas Clipperis välja töötatud süsteemi (tootmisandmete sisestamiseks), “1C: Accounting 7.7” (reguleeritud raamatupidamise pidamiseks) ja “1C.8 ZUP” (palgaarvestuse jaoks). Juhtkond kaalus üleminekut terviklikule rakenduslahendusele “1C: Manufacturing Enterprise Management 8” (või “1C: ERP 2.0”).

Pakutud lahendus

Vastavalt kliendi nõudmistele pakuti välja 2 teostusvarianti:

1) Tarkvaratoodetel põhinev automatiseerimine “1C: UPP 8” + “PiterSoft: protsessihaldus”

2) Automatiseerimine tarkvaratoodetel “1C: ERP 2.0”.

Võrdlevad omadused lahendused on välja pakutud tabelis 1.

Tabel 1. Kliendi eesmärkide ja 1C tarkvaratoodete funktsionaalsete võimaluste vahelise seose võrdlevad omadused

Klient otsustas automatiseerida, kasutades 1C: ERP 2.0.

Tulemus

1. Klientide individuaalsete tellimuste järgi oma tehniliste vahenditega toodetud toodete tootmise arvestus. dokumentatsioon

2. Ostja spetsifikatsioonide täitmise jälgimine kõikides etappides (tootmine - kogus, müük - kogus, hind), sealhulgas tähtajad

3. Tootmisülesande automaatne genereerimine

Käivitati "Treasury" (tulude ja kulude planeerimine) ja "BDDS" (ettevõtte rahavoogude plaaniline faktiline analüüs) plokid. Osaliselt käivitati “BDR” plokk (ettevõtte tulude ja kulude plaan-faktanalüüs) (projekt peatati Kliendi rahastuse puudumise tõttu)

1. Käivitatud on reguleeritud (süsteemis nii raamatupidamine kui maksuarvestus).

2. Rakendatud materjalide ja valmistoodete seeria(partii)arvestus

3. Korraldas tootmiskulude laekumise tellimuse alusel

4. Vajaliku reguleeritud Raamatupidamise ja Maksuaruandlus(kaasa arvatud konsolideeritud)

1. Kliendi spetsifikatsioonide automatiseeritud arvestus, planeeritud kulukalkulatsioonide arvutamine vastavalt spetsifikatsioonidele

2. Rakendatud kontroll ostja spetsifikatsioonide täitmise üle kõikides etappides (tootmine - kogus, müük - kogus, hind), sealhulgas tähtajad

3. Vastastikused arveldused klientidega spetsifikatsiooni/spetsifikatsioonirea kontekstis.

4. Loodud on mehhanism dokumentide automaatseks genereerimiseks ja hindade arvutamiseks meie enda juriidiliste isikute vahel.

Projekti elluviimise käigus automatiseeriti järgmised tootmistegevuse valdkonnad.