- masto ekonomija, yra išlaidų sumažėjimas, atsirandantis dėl padidėjusios gamybos apimties. Didesnės įmonės gauna nuolaidas už didesnes apimtis, daugiau sutaupo rinkodaros ir logistikos veikloje, o pastoviąsias sąnaudas paskirsto didesniam produkcijos vienetų skaičiui, o tai lemia mažesnius gamybos kaštus, bendrai didėjant gamybai.
- diversifikacijos efektas, bendrovė gauna šį pranašumą dėl didelio operacijų sąrašo. Pavyzdžiui, didelė įmonė gali naudoti tos pačios rūšies rinkodaros veiklą arba pardavimo kanalus reklamai skirtingų tipų produktų.
Klausimai, į kuriuos reikia atsakyti:
Kokios yra svarbiausios verslo modelio išlaidos?
Kuris iš pagrindiniai ištekliai brangiausias?
Kurios pagrindinės veiklos reikalauja daugiausia išlaidų?
Inovatyvių projektų verslo modelių pavyzdžiai pateikti E priede.
2 Verslo modelio įforminimo algoritmas
Inovatoriai labai dažnai neturi aiškaus savo verslo vaizdo. Pradiniame etape jie mato tuos pačius darbo ir sąveikos procesus, tačiau ateityje darbo struktūros ir metodai gali kardinaliai pasikeisti. Siekdami efektyvinti pradinį chaosą savo pradedamo verslo pristatyme ir palengvinti tolesnį inovatoriaus darbą keičiant ir plėtojant savo verslą, autoriai sukūrė verslo modelio įforminimo algoritmą, pav. 1
Ryžiai. 1. Verslo modelio formalizavimo algoritmas
Šis algoritmas apima tris lygius. Pirmajame lygmenyje novatorius turi suformuluoti svarbiausią verslumo procesą, t.y. formavimo procesas pinigų srautas ir nustatyti pajamų gavimo tašką. Norėdami tai padaryti, pirmiausia turite „suprasti“ rinką. Tam ištiriami poreikiai, analizuojami vartotojų pageidavimai, segmentuojami ir atrenkami tikslinis segmentas, išbandomas naujas produktas.
Monetizacijos taškas suprantamas kaip ta įmonės veikimo proceso stadija, kai prekės ir/ar paslaugos paverčiamos pinigais.
Taip pat pirmame lygmenyje būtina nustatyti jėgų pusiausvyrą rinkoje: pirkėjo galią, konkurentų buvimą, tiekėjų galią. Ypatingas dėmesys turėtų būti skiriamas įmonėms, kurios yra arba artimiausiu metu gali tapti jūsų konkurentėmis. Reikėtų apsvarstyti galimybę sukurti kliūtis naujoviško produkto ar paslaugos kopijavimui, tiek registruojant intelektinės nuosavybės teises, tiek išlaikant technologinės, techninės ar kitokios praktinės patirties paslaptį.
Antrame lygyje turėtumėte suprasti vidinius verslo procesus, technologijas ir naudojamus išteklius. Čia reikia suprasti, kokių resursų reikia pagaminti tokią produkcijos apimtį, kuri būtų pasirengusi patenkinti pradinį rinkos poreikį, kokios turėtų būti šie ištekliai, kur galime rasti tiekėjų, pasiruošusių tiekti mums reikiamos kokybės išteklius ir kiekis. Ypatingas dėmesys turėtų būti skiriamas žmogiškiesiems ištekliams, t.y. Jūsų įmonės personalui. Kadangi ne visada pavyksta rasti reikiamą skaičių reikiamos kvalifikacijos specialistų, galutinis įmonės veiklos rezultatas priklauso nuo personalo darbo.
Trečiasis lygis leidžia matyti svarbiausių įmonės verslo sistemos elementų tarpusavio ryšį ir šiuos elementus integruoti į vieną schemą. Čia reikia nustatyti 9 elementus (pagal A. Osterwalderio modelį): vartotojų segmentai, santykiai su klientais, pardavimo kanalai, vertės pasiūlymas, pagrindinė veikla, pagrindiniai ištekliai, pagrindiniai partneriai, kaštų struktūra ir pajamų srautai.
Klausimai, į kuriuos reikia atsakyti verslo modelio kūrimo proceso metu.
1 lygis. Produkto ir monetizacijos taško apibrėžimas
Apibrėžkite prekę/paslaugą (kas bus parduodama rinkoje).
Nustatykite, kam reikalingas šis produktas / paslauga (vartotojui).
Nustatykite, kiek vartotojas gali ir yra pasirengęs mokėti už tam tikrą produktą / paslaugą
Atlikite segmentavimą (nustatyti vartotojų grupes)
Ar yra analogų rinkoje, kokie konkurentai?
2 lygis: išlaidų nustatymas
2.1 Produkto gamybos (paslaugos teikimo) technologijos apibrėžimas
2.2 Nustatykite reikalingus išteklius
2.3 Nustatyti reikalingų išteklių kainą gaminio vienetui pagaminti
2.4 Rasti tiekėjus
3 lygis. Sistemos kūrimas
3.1 9 verslo modelio elementų apibrėžimas
3.2 Santykių ir procesų tarp verslo modelio elementų apibrėžimas.
Verslo plėtros perspektyvos
Būtina nustatyti perspektyvias verslo plėtros sritis:
Nustatyti perspektyvius rinkos segmentus;
Parodykite įmonės produktų ir technologijų plėtros kryptis;
Pateikite veiksmus, skirtus produkto, technologijos ir viso verslo plėtrai.
Šioje pamokoje aptarėme 3 temas:
1. Verslo procesų formalizavimas. Kodėl tai svarbu kuriant verslo procesus ir nėra taip sunku, kaip gali pasirodyti neapmokytam specialistui.2. Darbas su verslo procesais Bitrix24
3. Verslo procesų redaktorius, dirbantis su „Veiksmais“
Verslo proceso „Sutarties registracija“ aprašymas:
Įmonės vadovas parengia sutartį su klientu. Kiekviena sutartis turi būti suderinta su skyriaus vedėju (gali būti vykdoma kelis kartus!).
Jei sutarties suma yra didesnė nei 15 000 rublių, buhalteris turi pridėti papildomą informaciją prie sutarties. sąlygas. Jei mažiau, tai papildomai. jokių sąlygų nereikia.
Kiekviena sutartis turi būti suderinta su advokatu (gali būti vykdoma kelis kartus!).
Po visų patvirtinimų vadovas pasirašo sutartį su direktoriumi ir išsiunčia paštu klientui.
Vadovas, gavęs kliento pasirašytą sutarties kopiją, ją užregistruoja.
Verslo proceso „Sutarties registracija“ grafinis įforminimas: 
Webinaro vaizdo įrašas
Webinaro pristatymas, parsisiųsti >>
Medžiagos tvirtinimo užduotis
Būtent užduočių sprendimas leis įgyti naujų įgūdžių! Net kol nepabandysi to įgyvendinti pats teisingus klausimus nekils kaip išspręsti tą ar kitą problemą, jau nekalbant apie atsakymo į jas radimą. Būtinai atlikite užduotis!1. Formalizuokite AKS – grafiškai, rašikliu ant popieriaus lapo arba programine įranga.
Klientas susisiekia su įmone dėl prekių užsakymo. Vadovas sukuria aplikaciją, kurioje nurodo gaminius. Prašymas pateikiamas skyriaus vedėjui tvirtinti.
Jeigu prašymą patvirtina vadovas, paraiška perduodama buhalteriui išrašyti sąskaitą. Sąskaita faktūra pridedama kaip failas prie paraiškos.
Jei sąskaitos faktūros suma yra didesnė nei 50 tūkstančių rublių, ją turi patvirtinti įmonės direktorius. Jei mažiau nei 50 tūkstančių rublių, tada sąskaitą patvirtina vyriausiasis buhalteris.
Patvirtinus sąskaita faktūra perduodama vadybininkui. Vadovas išsiunčia klientui sąskaitą faktūrą.
2. Įforminkite „ant popieriaus“ vieną iš darbo procesų savo įmonėje.
Ar tikrai yra to paties tipo procesų, kurie aiškiai kartoja tuos pačius veiksmus? Pirmą kartą rinkitės paprastus, 5-10 žingsnių, 2-3 dalyviai.
3. Pakeisti BP „Prašymas dėl komandiruotės“ ir perduoti jį visiems BP dalyviams
- Pridėkite pranešimą bet kuriam vartotojui (jūsų pasirinktam) B24, kad maitinimas pradėtas
- Pridėkite užduotį „Perkelti reikalus prieš atostogas“ darbuotojui, kuris pradėjo BP.
Verslo proceso aprašymas- tai dokumentas, kuriame išdėstyta proceso logika ir turinys bei atskirų jo etapų įgyvendinimo reikalavimai. Tai svarbus elementas reguliarios valdymo sistemos. Tai dokumentas, kurį galite duoti naujam darbuotojui ir pasakyti: „Štai kaip mes tai darome“.
Verslo procesų formalizavimas- Tai unikalių žinių ir patirties išgavimas iš atskirų darbuotojų ir vadovų, jos nuoseklaus (visų pripažinto) aprašymo sukūrimas ir paverčiant jį intelektualiniu įmonės turtu.
Palaipsniui aprašydama pirmiausia problemiškiausius, o paskui visus verslo procesus, įmonė formuoja ir plėtoja šį turtą:
- procesų ir viso verslo valdomumo didinimas;
- kad rezultatai būtų nuspėjami;
- pačių verslo procesų tobulinimas;
- lengvesnis naujų darbuotojų įvedimas;
- tampa daug mažiau priklausomas nuo „žvaigždžių“ ir „nepakeičiamų“ darbuotojų.
Kodėl šis turtas vertingas:
- Tai suteikia bendras supratimas visi terminai, darbo turinys, reikalavimai ir lūkesčiai, vertinimo kriterijų vienovė. Tai tampa sąžiningumo pagrindu valdymo sprendimai. Šiuo om vieningas darbo turinio supratimas leidžia darbuotojams suteikti daugiau iniciatyvos, deleguoti kai kurias valdymo užduotis ir atleisti direktorių:
- Pas direktorių nereikia visko laikyti savo galvoje, spardyti ir priminti darbuotojai, kad viskas būtų padaryta.
- Skyrių vadovai turi aiškų supratimą suprasti, ko, kiek ir kaip jie turėtų reikalauti iš darbuotojų.
- Paprastų darbuotojų patirtis tikrumas, kaip atlikti darbą. O jei dar yra darbo planas (tiksliniai rodikliai), jis automatiškai dingsta„būtinybė“ ir noras laukti nuolatinių nurodymų kada ir ką daryti. Pasyvumas tampa nuostolingas, o darbuotojų keitimas tampa lengvesnis.
- Proceso aprašymas gali būti (ir turėtų būti) naudojamas procesų valdymas: planavimas, motyvavimas, rezultatų vertinimas. Jis gali būti naudojamas kaip darbuotojų ir padalinių darbo kokybės vertinimo įrankis.
- Jis gali būti naudojamas naujų darbuotojų įvedimas. Atsiranda technologija greitas mokymasis personalas ir jų darbo kontrolė. Svarbu, kad šie mokymai būtų vykdomi taip, kaip reikia įmonei, o ne taip, kaip atsitiktinai atsitiks darbe atsiradus naujokui. Priešingu atveju darbuotojas užtruks ilgai (ir ne visiškai jūsų kontroliuojamas), kol atsitiktinai susiformuos jo darbo vizija ir darbo įgūdžiai.
- Šis turtas sumažina reikalavimus samdomam personalui, nes darbo rinkoje nereikia ieškoti telepatijos genijų, gali atspėti, ko norite ir kaip jie čia veikia. Taip pat nereikia ieškoti supervadybininkai, kuriam atėjus, viskas pagaliau susitvarkys.
- Procesų aprašymus galima keisti: tobulinti, taisyti, papildyti, panaikinti pasenusius ir pakeisti nauju. Jie gali būti naudojami trikčių šalinimo procesai. Kai matome problemą, proceso gedimą, konfliktą, iš aprašymo nesunku rasti vietą, kur ši problema atsiranda. Po to galite papildyti aprašą arba pakeisti nurodytus veiksmus kitais, atsižvelgdami į įgytą patirtį.
- Leidžia užfiksuoti „subtilias akimirkas“ verslo procesai: kai yra dokumento aprašymas, nesunku rasti vietą, kur įdėti vertingą pastabą, pvz.: „stebėti sąskaitos faktūros gavimą komercinis pasiūlymas Autorius paštu“, „jei kas nors atsitiks, atkreipkite dėmesį į (1) ir (2)“, „jei klientas..., tai pasiūlyk jam...“. Po tam tikro gyvenimo ir naudojimo laikotarpio aprašymai užpildyti stebėtinai vertinga ir specifine informacija. Jei aprašymo nėra, visos šios vertingos idėjos tiesiog prarandamos, nes trūksta vietos jas „patalpinti“.
- Gali mastelis. Jei atidarote naują biurą ar filialą, verslo procesai tiesiog perkeliami ir ten pradeda džiuginti.
Tarp „minusų“ pastebime:
- Reikšmingas vienkartinės pastangos apie verslo procesų aprašymų kūrimą ir pasipriešinimo įveikimą (tai neįprasta vadovams, tingi darbuotojams, kurie „jau viską žino“ ir, be to, nenori tapti lengvai pakeičiamais).
- Būtinybė(taip!) įpareigoti, priversti ir priversti darbuotojus elgtis pagal aprašus ir kontroliuoti Tai. Akivaizdu, kad visi norime atrodyti gerai. Valdant tai pavojinga, nes tokia vadovas neišvengiamai taps darbuotojų manipuliavimo objektu.Be to, tie, kurie labiausiai domisi purvinas vanduo ir rūpinasi „apsaugoti“ savo atsipalaidavusią būtį nuo darbo ir reikalavimų.
SIPOC modelis naudojamas Six Sigma ir kokybės valdyme, siekiant apibrėžti projekto ribas ir peržiūrėti procesus iš viršaus. Dėl mūsų užduočių detalumo šis modelis puikiai veikė mažesniame aukštyje. Toliau grįšiu prie kai kurių išvadų apie proceso apžvalgos „aukštį“.
Šis modelis gali pasitarnauti kaip medžiagos tiekėjas verslo procesų formalizavimui visuotinai priimtomis žymomis. Daugeliu atvejų šis modelis gali visiškai apibūdinti įmonės procesus, jei laikysitės metodikos, šiuo atveju modelis gali būti standartinių 1C konfigūracijų modifikacijų ar diegimo techninių specifikacijų pagrindas.
Šis modelis turi savo pliusų ir minusų, todėl aš nepritariu visuotiniam pritaikymui, bet manau, kad alternatyvi perspektyva visada yra naudinga. Įskaitant ir mane. Komentaruose parašykite ką manote.
Prieš pradėdami
Proceso formalizavimo SIPOC metodu idėjos esmė yra ta, kad mes:
- Ypatingą dėmesį skiriame proceso „masteliui“ arba, kaip aš dar vadinu, „žiūros taško aukščiui“.
- Mes „išvyniojame“ procesą kaip kamuolį, pradedant nuo vartotojų galutinis rezultatas procesas, baigiant jo iniciatoriumi. Ne atvirkščiai!
- Ypatingą dėmesį skiriame proceso etapų „sankryžoms“.
- Ypatingą dėmesį skiriame proceso žemėlapio skaitomumui.
Kaip bebūtų keista, bet nepaisant šių punktų akivaizdumo, beveik visi proceso žemėlapiai, su kuriais susidūriau savo gyvenime, pažeidė bent du iš šių keturių punktų. Jei šis straipsnis padės suprasti šiuos pagrindinius dalykus, aš manysiu, kad pasiekiau savo tikslą, nesvarbu, kokį žymėjimą naudojate.
Kas yra SIPOC
Taigi SIPOC yra akronimas Anglų kalbos žodžiai Tiekėjas (tiekėjas), įvestis (įvestis), procesas (procesas), produkcija (išvestis), klientas (klientas) . Šis modelis leidžia apibūdinti procesus pagal veiksmų seką, informacijos/prekių/paslaugų judėjimą tarp proceso etapų, taip pat ryšius, atsirandančius dėl proceso tarp įvairių dalyvių. Modelis leidžia atsekti proceso verslo logiką su aukštu, bet valdomu abstrakcijos lygiu.
Iškart aiškus proceso aprašymo pavyzdys. Čia galite pamatyti pagrindus.
(S) Horns and Hooves LLC -> (I) Informacinės sistemos reikalavimai -> (P) Reikalavimų įforminimas -> (O) Techninės specifikacijos -> (C) 1C: Franšizės gavėjas
Skaitome iš kairės į dešinę: Klientas išsako informacinei sistemai keliamus reikalavimus, kurie yra formalizuoti, todėl 1C: franšizės gavėjas sudaro techninę specifikaciją.
Vizualiai rodyti:
Dabar pažiūrėkime, kas tai yra ir kam jis skirtas.
S – tiekėjas (tiekėjas). Mūsų pavyzdyje tai yra tam tikra organizacija. Šis vaidmuo gali būti bet koks proceso elementas, suteikiantis proceso įvestį tam tikrą informaciją, dokumentus, medžiagas, produktus, prekes, paslaugas ir tt. Apskritai tai yra bet ko, bet ko, kas būtinai dalyvauja procese, tiekėjas. .
Aš – įvestis. Mūsų pavyzdyje tokie reikalavimai informacinei sistemai. Šie reikalavimai gali būti pateikti el. laišku, aprašyti žodžiu derybose arba įrašyti ankstesniuose pokalbiuose. Viskas, ko reikia procesui, aprašyta čia. Šiam aprašymui taikomi reikalavimai, todėl kai kuriuose šaltiniuose akronimas SIPOC gali būti matomas kaip SIRPORC. Šie reikalavimai, kaip rodo akronimas, taikomi tiek įvestims, tiek išvestims.
Paprastai įvesties ar išvesties reikalavimų nerodome vizualiai, nebent to reikalauja sąlygos (savo praktikoje niekada su tuo nesusidūrėme, bet viskas įmanoma). Tačiau šiuos reikalavimus aprašome priede prie vizualaus verslo proceso vaizdo. Tai lemia atsirandantys nepatogumai naudojant SIPOC korteles vėlesniam naudojimui projektinėje dokumentacijoje dėl didėjančios jų apimties. Tačiau norėdami vizualiai įtvirtinti techniką savo galvoje, nupiešime ją taip:
Reikalavimai objektams, įtrauktiems į procesą, gali būti bet kokios sąlygos, kurios būtinos sėkmingam proceso vykdymui. Rodyklė nuo proceso nukreipta į tiekėją, nes būtent tiekėjas turi laikytis reikalavimų. Tai gali būti išmatuojama medžiagų kokybė arba kiekis, jei tai yra gamyba, arba gali būti reikalaujama atlikti SMART analizę, kad būtų galima įgyvendinti informacinė sistema“, jei tai preliminarus projektas ir pan.
P – Procesas. Čia aprašome procesą, kuris vyks. Mūsų pavyzdyje tai yra reikalavimų formalizavimas. Paprastai šiame bloke aprašoma, kas atsakingas už procesą, galbūt jų vaidmuo. Aprašytas to, kas bus išvestis, gamybos procesas. Piešiu vaizdą tik tam, kad galėčiau vizualiai pavaizduoti procesą.
Paprastai šį aprašymą pateikiame vaizdinio verslo proceso vaizdo priede. [Ignoruokite įstrižainės rodykles, aš piešiu rašydamas straipsnį]
O - Išvestis. Čia aprašome, kas turėjo atsirasti po ankstesnio etapo. Mūsų pavyzdyje tai yra techninė užduotis. Techninės specifikacijos kaip „išėjimas“ iš proceso turi savo reikalavimus, kuriuos suformuluoja užsakovas. Pavyzdžiui, 1C:Franchisee turi techninių specifikacijų projektavimo standartą. Reikalavimas „techninės specifikacijos turi atitikti standartą “ aprašome priede, tačiau norėdami vizualiai tai pataisyti, baigkime piešti:
C – klientas. Mūsų pavyzdyje tai yra 1C:Franchisee, kuri gauna techninę užduotį dėl reikalavimų įforminimo.
Tai labai supaprastintas pavyzdys. Reikia tik pereiti per viršų ir pamatyti vaizdą kaip visumą.
Subtilybės
Tai proceso aprašymas iš paukščio skrydžio. Natūralu, kad pats procesas yra daug sudėtingesnis. Taigi pirmiausia pradėkime nuo proceso detalumo galimybių.
Jei turime kelis „gaunamų“ objektų tiekėjus arba kelis „įeinančius“ objektus, tada jie gali būti rodomi taip:
Tas pats pasakytina apie „išeinančius“ objektus ir klientus:
Dabar, jei įsivaizduosime, kad mums reikia išsamesnių procesų ir reikalavimų detalių, brėžinys taps vis mažiau įskaitomas. Kurių, beje, norime išvengti.
Mūsų detalumo lygis nustatomas empiriškai individualiai kiekvienam klientui.
Siekdami išlaikyti proceso skaitomumą, mes pradedame skaidyti procesą į etapus. Kiekvienas etapas yra SIPOC modelio kopija su savo įėjimais ir išėjimais. Pavyzdžiui, išankstinis projektas gali būti suskirstytas į du ar daugiau etapų, priklausomai nuo reikalingos detalės. Nupiešiu pirmus du.
Jei atidžiai pažvelgsite į šiuos du etapus, pastebėsite, kad pirmieji trys antrojo etapo „Consultant-Protocols-CIO“ elementai dubliuoja paskutinius tris pirmojo etapo elementus. Tai yra proceso etapų sandūros. Prie jų grįšime vėliau.
Bet kaip su cikliniais procesais? Ką apie lygiagrečius procesus? O šakos?
Į visus klausimus atsakysiu eilės tvarka.
Cikliniai procesai visada svarstomi iš „aukščio“, leidžiančio apibrėžti ciklinį procesą kaip atskirą vienetinį etapą. Pavyzdžiui, paskutiniame paveikslėlyje matome, kad protokolai pateikiami tvirtinti CIO. Žinome, kad patvirtinimas gali užtrukti ilgai, nes... kažkas kažką pamiršo arba, priešingai, kažką prisiminė ir protokolai eis pirmyn ir atgal, kol bus gauta proceso „išvestis“ - pasirašyti protokolai. Jei cikliniame procese yra iš esmės svarbių automatizavimui blokų, tai viena tokio ciklo iteracija aprašoma atskira SIPOC kortele.
Lygiagretūs procesai, jei leidžia situacija, aprašomi atskiromis SIPOC kortelėmis. Jei lygiagrečių procesų ryšiai laike yra sudėtingi, tai SIPOC naudojamas tik procesams apibūdinti pačius procesus laike aprašomas kitais įrankiais. Tai neapsiriboja SIPOC kortelių taikymu.
Dabar apie šakas. Jei procese yra šakų, tada SIPOC žemėlapiai aprašo proceso etapus prieš ir po šakų. Šiuo atžvilgiu SIPOC visai nėra patogus įrankis. Jei šakų yra daug, tai reiškia, kad pasirinkta neteisinga „mastas“, arba reikia naudoti kitus įrankius.
Viena vertus, aš suprantu, kad SIPOC turi savo pliusų ir minusų. Kita vertus, įvairių procesų automatizavimo patirtis rodo, kad teisingiausi, stabiliausi ir veikiantys tame pačiame lygyje procesai (jei procesai yra skirtinguose lygmenyse, tada jie brėžiami skirtinguose žemėlapiuose) beveik visada yra linijiniai ir idealiai linkę kontrolinis sąrašas. Sudėtingus procesus arba nubrėžė konsultacinė įmonė, arba jie yra vaizduotės vaisius tema „kaip tai galėtų būti“. Tai retai, bet taip atsitinka, kad procesas yra tikrai sudėtingas ir tikrai nėra kito kelio. Kai tik susiduriame su sudėtingais procesais, iš anksto keliame klausimą, kad greičiausiai procesas nėra optimaliai struktūrizuotas arba aprašytas neteisingai. Dažniausiai taip nutinka, kai kas nors nori viską iš karto aprašyti viename popieriaus lape, nors ir labai dideliame.
Tai labai panašu į programavimo procesą. Mes naudojame tam tikrą procedūrų ir funkcijų detalumą, leidžiančią lengvai naršyti. Įsivaizduokite, kas nutiktų, jei 1C turėtų tik vieną modulį, kuris būtų atsakingas už viską, ir nebūtų procedūrų ir funkcijų, kurios padidintų algoritmo abstrakcijos lygį.
Yra skirtingi valdymo lygiai ir atitinkami skirtingi masto lygiai.
Šiame žemėlapyje nematome karių, technikos ar dalinių. Apžvalgos „aukštis“ neleidžia. Jei analogais imsime operatyvinį valdymą: šakas, dviračius ir pan., tai iš tokio atstumo šių krumpliaračių nepamatysime. Tiesą sakant, jie čia nepriklauso; šis žemėlapis yra strateginio ir taktinio planavimo įrankis. Operatyviniam valdymui reikia naudoti kitus vizualizavimo įrankius.
Negalite visko detaliai pamatyti vienu metu. Įvairių apžvalgos taškų žemėlapiai turėtų būti skirtingi. Jei šis reikalavimas yra įvykdytas, tai beveik visi procesai, kurie detaliai atitinka peržiūros „aukštį“, gali būti aprašyti SIPOC modeliu. Iš to kažkada padariau tokią išvadą: jei procesas aprašytas metoduSIPOC, tada proceso apžvalgos „aukštis“ atitinka detalumo lygį. Tai gali atrodyti kaip prieštaringas pareiškimas. Tikiuosi, jei klystu, kompetentingesni bendražygiai mane pataisys komentaruose. Aš visada pasiruošęs tobulėti. Tačiau iki šiol eksperimentiškai nepavyko patirti priešingo.
Kaip nubraižyti proceso žemėlapį?
Dabar, išnagrinėję pačią procesų apibūdinimo metodiką, turime išmokti ją nubrėžti.
Visų pirma, turime nustatyti detalumo lygį. Kaip rašiau aukščiau, mes nustatome teisingą detalumo lygį, kai paryškinamas tiesinis procesas. Peržiūros „aukštis“ neturėtų būti mažesnis už apskaitai reikalingų operacijų lygį. Tie. Nėra prasmės apibūdinti procesą iki lygio „atlikėjas paėmė rašiklį ir pradėjo rašyti“, nes Ši informacija niekaip neatsispindi apskaitoje.
Kai konsultantas ateina į proceso apklausos pokalbį, jis laikosi šių rekomendacijų.
Jei skaitome procesą iš kairės į dešinę iš viršaus į apačią, tada pradedame piešti procesą iš dešinės į kairę iš apačios į viršų! Tai yra:
Klientas: Pirmiausia nustatome, kas bus proceso rezultatų vartotojas. Tai gali būti kiti padaliniai, konkrečios pareigybės, galbūt išorės rangovai.
Procesas: Tada aprašome patį procesą, kaip veiksmų seką ir asmenį, atsakingą už šio etapo vykdymą.
Įvestis: aprašome, ko reikia šiam etapui užbaigti, ir jam keliamus reikalavimus.
Tiekėjas: aprašome, kas procesui aprūpins reikalingais komponentais.
Aprašėme žemiausią, gaunamą proceso etapą. Ir tada mes pradedame išvynioti kamuolį, judėdami vienu etapu aukštyn. Taip nuosekliai aprašomi visi etapai.
Dabar, jei pamenate, šiek tiek aukščiau rašiau apie proceso etapų sandūras. Atėjo jų eilė. Paprastai apžiūros metu (tai būdinga apžiūros stadijai apskritai) išryškėja įvairūs niuansai. Staiga paaiškėja, kad proceso žingsniui užbaigti reikėjo kažkokio dokumento, tačiau paaiškėja, kad jo niekada nebuvo ir anksčiau procesas buvo atliktas neatsižvelgiant į šį dokumentą. Be to, nes dokumentas niekada neegzistavo, neaišku, kas turėtų jį pateikti proceso etapui. Arba išeina, kad kažkuriame etape išduodamas „išėjimas“, kuris pasirodo niekam nenaudingas, t.y. kai vėliau peržiūrime procesą ir matome „klientus“, kurie vartoja „produkciją“, o paskui niekur nedalyvauja, tai visai gali būti, kad kažkas daroma veltui. Taip būna ne visada, pavyzdžiui, išvestis gali būti spausdinta forma, kuri vėliau patenka į buhalteriją, tačiau automatizavimo rėmuose apskaitos nėra. Procesui apibūdinti toks „išėjimas“ bus nereikalingas, tačiau proceso apribojimų ribose priimtinas. Bet kokiu atveju patikrinti niekada neskauda.
Dėl šių sankryžų kartais išplečiami reikalavimai. Pavyzdžiui, kartą, tirdami kliento procesus, uždavėme klausimą apie kai kurias sąsajas. Paaiškėjo, kad pagal sutartį reikia išrašyti suvestinius aktus ir sąskaitas, o buhalterė viską surašė rankiniu būdu. Pradinių reikalavimų šiai grandinei nebuvo, tačiau apžiūros metu šį tašką identifikavę būtent sandūrų ir jų reikalingumo analizės etape, sukūrėme sprendimo koncepciją, pasiūlėme ją užsakovo vadovybei ir gavome papildomą biudžetą šiai grandinei. .
Tokio pokalbio metu konsultantas sudaro procesus, surašo procesų tyrimo protokolus, juos derina ir kartu su pokalbio garso įrašais perduoda savo vadovui tolesnei analizei.
Neaiškios premijos
SIPOC metodika, būdama paprasta priemonė, leidžia gauti premijas, kurios nėra visiškai akivaizdžios. Turėdami įgūdžių, galite naudoti šį įrankį įvairiose situacijose.
Pačios SIPOC kortelės yra lengvai skaitomos ir lengvai suprantamos sprendimų priėmėjams. Tai leidžia kurti „pardavimo“ apklausas. Vidutiniuose ir dideliuose projektuose dažnai susidurdavo su tuo, kad sprendimų priėmėjas nežinojo, kaip perskaityti IDEFx serijos žymes. Šiuo atveju, jei įmanoma, išvertėme juos į labiau suprantamą lygį, nes kartais būdavo visiška nesąmonė. Jei dirbame su IT skyriumi, tai su jais sutariame dėl tolesnių aprašymų projekto dokumentuose, jei jie nepasisako „prieš“, tuomet ir toliau laikomės SIPOC žymėjimo. Bet būna, kad reikia ir kitų žymėjimų, dažniausiai IDEF0 ir/arba IDEF1, taip nutinka labai retai. Iki šiol negirdėjau svarbaus argumento už šiuos užrašus, išskyrus tai, kad tai yra žinomas standartas, ir jie niekada nematė SIPOC. Išskyrus projektą, kur reikėjo automatizuoti kliento nukreipimo į skyrius procesą, priklausomai nuo to, ką jis perka, kokia apimtimi ir pan., filialų buvo daug. Tiesą sakant, tai yra komplekso automatizavimas operatyvinis valdymas, SIPOC kortelėms ten ne vieta.
Kitas privalumas yra įgūdis nustatyti proceso peržiūros „aukštį“. Dažnai bendraujant su įvairių struktūrų vadovais, jau pokalbio metu, remiantis netiesioginiais ženklais, paaiškėja, kad proceso apžvalgos „aukštis“ pasirinktas neteisingai. Ir tik dėl to valdymas įmonėje yra beveik nuliniame lygyje. Šiuo atveju kreipiuosi į konsultacijas. Padedu suprasti peržiūros aukštumą ir procesų etapus. Paprastai tai leidžia užmegzti glaudesnį ryšį tolimesniam bendravimui ir padidinti pasitikėjimo, kaip eksperto, lygį. Nepaisant ilgo aprašymo, visa tai gali įvykti per vienus verslo pietus.
Na, tikriausiai paskutinis dalykas, kurį norėčiau jums pasakyti. Kartais klientai arba neturi lėšų tyrimui, arba tiesiog nesupranta, už ką iš tikrųjų moka, ir dėl to tampa godūs. Šiuo atveju aš jiems siūlau variantą, kai jie patys užpildo ir detalizuoja procesus. Pasirodo, toks paviršutiniškas konsultavimas, kuris kartais priveda prie projektų. Taip atsitinka susirašinėjime, kur aš jiems siunčiu jau paruoštas trumpikes, o jie jas užpildo. Skambiname vieni kitiems, kai kyla klausimų. Toks požiūris leidžia nenutraukti santykių, palaikyti dialogą ir tuo pačiu negaišti laiko, jei klientas yra godus pinigų, atsidūręs priverstinio taupymo situacijoje ar tiesiog nesupranta, už ką mokėti konsultantams. Paragavęs konsultacinio darbo kartėlio, jis arba duoda rezultatą, su kuriuo gali pradėti dirbti, arba nušoka, kvalifikuodamas save kaip netikslinį klientą, arba perka. normalus tyrimas. Bet kokiu atveju, taikydami šį metodą, išliekame tvirtoje pozicijoje. Pirmuoju atveju padėjome negaišdami laiko, kuris vėliau bus įskaitytas. Antruoju atveju sutaupėme daug laiko ir nervų netiksliniams veiksmams. O trečioje iš apklausos užsidirbome pinigų.
Visų veiksnių suma: metodo paprastumas, mokymosi paprastumas ir plačios konsultavimo galimybės – tai visi privalumai, dėl kurių metodą naudojame vėl ir vėl. Iki šiol dar nemačiau jokiu būdu tokio naudingumo derinio tiriant ir gerinant bendravimo su klientais kokybę. Dar kartą kartoju, kolegos, pasidalinkite patirtimi, man malonu mokytis.
Ruošdamas šią medžiagą nusprendžiau paieškoti, kas yra RuNet šia tema. Bet tai leis jums išplėsti savo supratimą apie šią temą:
Yandex.pictures yra daugybė SIPOC kortelių pavyzdžių
6 Sigma, taupi gamyba...
... ir galbūt tai viskas.
Pridedamas tikros techninės specifikacijos pavyzdys, kuriame buvo nedidelis proceso žemėlapis ir priedas. Tai aiškumo dėlei, kaip mes tai naudojame realiuose projektuose.
P.S. Kaip jau rašiau, nusprendžiau pradėti naujienlaiškį. IN šiuo metu Pašto adresų sąrašas veikia miego režimu. Prenumeratorių dar nėra daug, bet prenumeratorių jau yra nemažai. Dabar jau yra 143 žmonės ir dar 9 nepatvirtino savo prenumeratos (pasitikrinkite Spam aplanką, kartais patvirtinimo laiškas atsiduria ten). Tai tik 15 dienų nuo naujienlaiškio egzistavimo, kuris mane tikrai įkvepia. Artimiausiu metu ves nedidelį nemokamą internetinį mokymą. Nesu profesionalus treneris ir tai daugiau hobis, bet manau, kad tai bus įdomu laisviesiems šauliams ir organizacijų vadovams, užsiimantiems automatizavimu pagal 1c. Šiuo metu ruošiami visi techniniai mokymų elementai. Jei jums patiko ši medžiaga, galite užsiprenumeruoti naujienlaiškį. Planuoju ir toliau skelbti IS; į adresų sąrašą bus įtraukta medžiaga, kuri netinka IS formatui (pavyzdžiui, nesugalvojau, kaip čia vesti mokymus).
Daugelis verslininkų laikosi nuomonės, kad jei verslas daugiau ar mažiau sėkmingas, užtenka viską laikyti savyje esama forma. Tačiau perfrazavus šią tezę, paaiškėja, kad ką nors pakeisime tik iškilus problemoms. Norint išvengti situacijos, lemiančios jų atsiradimą, naudinga reguliariai optimizuoti įmonės darbą. Be to, ekspertai pataria mokėti ypatingas dėmesys apie verslo procesus.
Verslo procesas yra visa veiksmų seka, vedanti prie konkretaus rezultato. Pavyzdžiui, gatavo produkcijos vieneto gamybai arba prekių pardavimui.
Patirtis rodo, kad nors įmonėje dirba nedaug darbuotojų, savininkas gali viską kontroliuoti asmeniškai, nors tai ne visada įmanoma. Tačiau už didelės įmonės Kiekvieno verslo proceso derinimas yra privalomas, kitaip sumažės ir efektyvumas, ir veiklos pelningumas.
Verslo procesų formalizavimo esmė
Verslo procesų formalizavimu siekiama panaikinti chaosą tiek visos įmonės, tiek kiekvieno darbuotojo veikloje atskirai.
Jei to nepadarysite, šios problemos neišvengiamos:
- Ne visada aišku, kuris darbuotojas už ką atsakingas.
- Dažnai neaišku, kas atsakingas už konkrečią užduotį.
- Kiekvienos problemos sprendimas vėluoja, nes nėra aiškaus algoritmo.
- Užduotys (dokumentai, klientai, programos) nueina ilgą „kelią“ per įmonę, kol jos išsprendžiamos ir panaudojami pertekliniai ištekliai. ši byla darbuotojų.
Visa tai sukelia painiavą, kuri laikui bėgant gali išaugti iki nerimą keliančių mastų. Be to, tokiu darbo organizavimu vis didesnį svorį įgauna žmogiškasis faktorius: sunku ką nors sukontroliuoti, kiekvieną kartą tenka patikslinti informaciją su konkrečiais darbuotojais ir nėra garantijos, kad gauta informacija bus patikima. .
Be to, kai kuriais atvejais vadovas net nežino, į kurį darbuotoją turėtų kreiptis kitu klausimu, ir tai dar labiau apsunkina situaciją.
Verslo procesų formalizavimo užduotys
Verslo procesų formalizavimas gali būti atliekamas naudojant įvairius metodus, pavyzdžiui, naudojant BPM sistemos, arba „rankiniu būdu“. Tačiau visada reikia sukurti aiškų algoritmą:
- Žaliavų pirkimas.
- Žaliavų pristatymas į sandėlį.
- Sandėliavimas sandėlyje.
- Siuntimas į dirbtuves.
- Produktų gamyba.
- Prekių siuntimas į sandėlį.
- Prekių pristatymas klientui po pirkimo.
Kiekvienas iš šių etapų apima individualus, atsakingas už vykdymą. Pavyzdžiui, jei žaliavos buvo paimtos iš tiekėjo, bet dar neatvyko į sandėlį, tuomet visi klausimai adresuojami pristatymo tarnybos vadovui, o jei atkeliavo – sandėlio vedėjui.
Be to, kiekvieną etapą sudaro etapai ir daugelis savo mažų procesų. Pavyzdžiui, žaliavų pirkimas apima ilgą kelionę: prieš perkant reikia nuspręsti dėl poreikio, paskambinti tiekėjui, susitarti dėl kainų ir sąlygų ir pan. Yra trys pagrindinės verslo procesų formalizavimo užduotys:
- Turi būti sukurta aiški verslo proceso schema.
- Kiekvienas darbuotojas turi suprasti, kurioje schemos dalyje reikalingos jo pastangos, kur prasideda ir kur baigiasi jo atsakomybė; iš ko jis gauna užduotis ir kur jas turėtų perkelti po apdorojimo.
- Vadovas turi turėti galimybę kontroliuoti, kur tam tikru momentu yra užduotis (kokiame etape ir kuriam darbuotojui).
Verslo procesų formalizavimas automatizuojant
Pirmiausia, verslo procesų formalizavimas nebūtinai reikalauja automatizavimo naudojant BPMS, tai galima atlikti ir rankiniu būdu. Lengviausias būdas – kiekvienam darbuotojui parašyti nuostatas. Dėl to galima sėkmingai išspręsti kai kurias problemas, būtent pirmiau pateikto sąrašo 1 ir 2 užduotis (sudaryti diagramą ir suprasti kiekvieno darbuotojo vaidmenį).
Tačiau verslo procesų įforminimas „ant popieriaus“ beveik neleidžia kontroliuoti, kaip laikomasi taisyklių: ar darbuotojai jų laikosi, ar randa „apeitus“ susitarimo tarpusavyje lygiu. Žmogiškojo faktoriaus vaidmuo ir piktnaudžiavimo darbuotojais galimybės išlieka labai didelės.
Jei verslo procesų formalizavimas atliekamas naudojant BPM sistemas, atsiranda papildomų labai svarbių galimybių:
- Kiekvienos užduoties valdymas nuo pradžios iki pabaigos, galimybė matyti visas sąrašas užduotis.
- Jokių nuostolių: jei užduotis patenka į įvestį, ji vienaip ar kitaip turi pasiekti išvestį.
- Visų kiekvienos užduoties veiksmų sekimas su galimybe aiškiai nustatyti, kas atliko kiekvieną veiksmą.
- Išsamus statistikos rinkimas.
Ši paskutinė funkcija yra ypač svarbi, nes ji padeda, įskaitant:
- Sužinokite, kurie darbuotojai dirba efektyviai, o kurie ne.
- Pamatykite realią kiekvieno darbuotojo visų atliktų darbų apimtį. Gal kas tik apsimeta kažkuo užsiėmęs?
- Atsikratykite įvairių darbuotojų piktnaudžiavimo rizikos.
Verslo procesų formalizavimas yra labai naudingas bet kuriai įmonei. Net jei šiuo metu neturite rimtų problemų, naudinga pradėti kovoti su chaosu įmonės darbe jau dabar, siekiant sumažinti įvairius nuostolius ir kaštus, padidinti visų darbuotojų ir viso verslo efektyvumą bei efektyvumą.
