Kanban süsteem: tark projektijuhtimine. Kanbani metoodika projektijuhtimises

Kavatsen kirjutada mitmeid artikleid uuest agiilse arendusmetoodikast Kanban (Kanban Development), et valmistuda Scandinavian Agile Conference 2009-ks, kus annan ühe ettekande (muide, kutsun kõiki ka konverents).
Täna avaldan esimesed artiklid.
Esimese artikli põhieesmärk on kirjeldada võimalikult lihtsalt Kanbani põhitõdesid: mis see on, kuidas see erineb teistest paindlikest metoodikatest ja miks seda vaja on.
Samuti sooviksin kommentaaridesse koguda võimalikult palju küsimusi ja kahtlusi, et neile tulevastes artiklites vastata, nii et kirjutage kõik, millest te aru ei saa, või midagi muud, mida soovite Kanbani kohta teada.
Ma ei ole selle uue metoodika alal just suur ekspert, kuid meeskonna sees jõudsime Kanbanini iseseisvalt ja läbisime järjekindlalt kõik mutatsioonietapid SCRUM-ist Kanbanini, seega on meil praktiline kogemus.

Kõigepealt kirjutan termini päritolust Kanban.

See termin jõudis meile Jaapanist tänu kitsastes ringkondades laialt tuntud Toyota tootmissüsteemile. Soovin, et võimalikult paljud inimesed loeksid sellest süsteemist ja sellesse põimitud aluspõhimõtetest - lean tootmine, pidev areng, kliendikesksus jne. Kõik need põhimõtted on kirjeldatud Taiichi Ohno raamatus Toyota tootmissüsteem, mis on tõlgitud vene keelde.

Mõistel Kanban on sõnasõnaline tõlge: "Kan" tähendab nähtavat, visuaalset ja "bann" tähendab kaarti või tahvlit.
Toyota tehastes kasutatakse Kanbani kaarte kõikjal, et vältida laod ja tööalade risutamist eelnevalt loodud varuosadega. Kujutage ette näiteks uste paigaldamist Toyota Corollale. Teil on teie töökoha lähedal 10 uksest koosnev pakk. Paned need üksteise järel uutele autodele ja kui pakki on jäänud 5 ust, siis tead, et on aeg uued uksed tellida. Võtad Kanban kaardi, kirjutad sellele tellimuse 10 uksele ja viid uste tegijale. Teate, et ta teeb need õigel ajal, et saaksite ülejäänud 5 ust tühjaks saada. Ja täpselt nii juhtubki – viimase ukse paigaldamisel saabub pakk 10 uut ust. Ja seda juhtub kogu aeg – tellite uued uksed ainult siis, kui neid vajate.
Kujutage nüüd ette, et selline süsteem töötab kogu tehases. Kusagil pole ladusid, kus varuosad nädalaid ja kuid istuvad. Kõik töötavad ainult nõudmisel ja toodavad täpselt nii palju varuosi kui soovitakse. Kui järsku on tellimusi rohkem või vähem, kohaneb süsteem ise muudatustega kergesti.

Kanbani kaartide põhieesmärk selles süsteemis on vähendada “käimasolevate tööde” hulka.
Näiteks võib kogu tootmisliinil olla täpselt 10 uksekaarti. See tähendab, et ühel hetkel ei ole liinil rohkem kui 10 valmis ust. Millal uusi uksi tellida ja kui palju on nende paigaldaja ülesanne. Ainult tema teab oma vajadusi ja ainult tema saab teha tellimusi uksetootjale, kuid ta piirdub alati 10-ga.
See Lean tootmismeetod leiutati Toyotas ja nüüd on paljud tootmisettevõtted üle maailma seda rakendamas või juba rakendanud.

Kuid see kõik on seotud tootmise, mitte tarkvaraarendusega.
Mis on Kanbani arendus seoses tarkvaraga ja mille poolest see erineb teistest paindlikest metoodikatest, olgu selleks siis SCRUM või XP?

Esiteks peate kohe aru saama, et Kanban pole konkreetne protsess, vaid väärtuste süsteem. Täpselt nagu SCRUM XP-ga. See tähendab, et keegi ei ütle sulle, mida ja kuidas samm-sammult teha.
Teiseks saab kogu Kanbani kirjeldada ühe lihtsa fraasiga - "Praegu pooleliolevate tööde vähendamine (käimasolevad tööd)".
Kolmandaks on Kanban veelgi “paindlikum” metoodika kui SCRUM ja XP. See tähendab, et see ei sobi kõigile meeskondadele ega kõikidele projektidele. Ja see tähendab ka seda, et meeskond peab olema veelgi rohkem valmis töötama agaralt kui isegi SCRUM-i ja XP-d kasutavad meeskonnad.

Erinevus Kanbani ja SCRUMi vahel:
- Kanbanis pole millegi jaoks ajakaste (ei ülesannete ega sprintide jaoks)
- Kanbanis on ülesandeid rohkem ja neid vähem
- Kanbanis on ülesande tähtajad valikulised või üldse mitte
- Kanbanis pole "meeskonna kiirust" ja arvestatakse ainult ülesande täitmise keskmist aega

Vaadake nüüd seda nimekirja ja mõelge – mis jääb agiilsest metoodikast järele, kui eemaldame spurdid, suurendame ülesannete suurust ja lõpetame meeskonna kiiruse mõõtmise? Mitte midagi?
Kuidas saame üldse rääkida arenduskontrollist, kui võtame ära peamised kontrollivahendid – tähtajad, töökiirus ja spurdid? Minu jaoks on see küsimus peaaegu kõige olulisem.
juhid mõtlevad alati kontrollile ja püüavad seda saavutada, kuigi tegelikult pole neil seda kunagi. Arengu kontroll juhi poolt on väljamõeldis. Kui meeskond ei taha töötada, siis ükskõik kuidas te seda kontrollite, ebaõnnestub see projekt.
Kui meeskond naudib tööd ja töötab täie pühendumusega, siis pole kontrolli vaja, vaid ainult segab ja suurendab kulusid.
Näiteks SCRUM-i üldtuntud probleem on suured kulud aruteludele, koosolekutele ja suured ajakadud sprindi ristmikel (kui vähemalt päev kulub ühe sprindi lõpetamisele ja siis päev uue avamisele. Ja kui sprint on 2 nädalat, siis 2 päeva 2 nädalast on 20%, neetult palju). Seetõttu kulub SCRUM-i kasutamisel peaaegu 30-40% ajast protsessi enda ülalpidamisele - igapäevastele koosolekutele, 5% töötubadele, sprindi retrospektiividele jne. kolmkümmend%!

Kanbani arendus erineb SCRUM-ist eelkõige ülesannetele keskendumise poolest. Kui SCRUMis on meeskonna põhirõhk spurtide edukal läbimisel (peame tunnistama, et see on tõsi), siis Kanbanis on esikohal ülesanded.
Sprinte ei toimu, meeskond töötab ülesande kallal algusest kuni selle lõpuni. Ülesande juurutamine tehakse siis, kui see on valmis. Valminud tööde esitlus - ka. Meeskond ei tohiks hinnata ülesande täitmiseks kuluvat aega, sest sellel on vähe mõtet ja see on peaaegu alati alguses vale.
Kui juht usaldab meeskonda, siis milleks teha ajaprognoosi? Juhataja ülesanne on luua prioriteetsete ülesannete kogum ja meeskonna ülesanne on täita sellest kogumist võimalikult palju ülesandeid. Kõik. Kontrolli pole vaja. Haldurilt pole vaja muud, kui lisada sellesse kogumi ülesanded või muuta nende prioriteeti. Nii juhib ta projekti.

Meeskond kasutab töötamiseks Kanbani tahvlit. Näiteks võib see välja näha selline (võetud):

Veerud vasakult paremale:

Projekti eesmärgid:
Valikuline, kuid kasulik veerg. Siia saab panna kõrgetasemelised projekti eesmärgid, et meeskond neid näeks ja kõik teaksid. Näiteks „Suurendage kiirust 20%” või „Lisa tugi Windows 7 jaoks”.

Ülesande järjekord:
See on koht, kus ülesanded salvestatakse ja need on alustamiseks valmis. Ülemine, kõrgeima prioriteediga ülesanne võetakse alati täitmiseks ja selle kaart liigutatakse järgmisse veergu.

Disaini arendamine:
See ja ülejäänud veerud kuni „Lõpetatud” võivad muutuda, kuna see on meeskond, kes otsustab, milliseid samme ülesanne läbib, et jõuda olekusse "Lõpetatud".
Näiteks võib see veerg sisaldada ülesandeid, mille kood või liidese kujundus pole veel selge ja mida arutatakse. Kui arutelud on lõpetatud, liigub ülesanne järgmisse veergu.

Areng:
Siin jääb ülesanne rippuma, kuni funktsiooni arendus on lõppenud. Pärast lõpetamist liigub see järgmisse veergu.
Või kui arhitektuur pole õige või täpne, saab ülesande tagasi eelmisesse veergu.

Testimine:
Ülesanne on testimise ajal selles veerus. Kui leitakse vigu, tagastatakse see arendusse. Kui ei, siis läheb edasi.

Kasutuselevõtt:
Kõigil projektidel on oma kasutuselevõtt. Mõne jaoks tähendab see toote uue versiooni postitamist serverisse ja teiste jaoks lihtsalt koodi hoidlasse sisestamist.

Valmis:
Kleebis läheb siia alles siis, kui kõik tööd ülesandega on lõpetatud.

Igas töös on kiireloomulisi ülesandeid. Plaanitud või mitte, aga need, mis tuleb kohe ära teha. Selliste jaoks saate eraldada spetsiaalse koha (pildil märgitud kui "Kiirendamine"). Saate Expedite'i panna ühe kiireloomulise ülesande ja lasta meeskonnal kohe sellega tegelema hakata ja see võimalikult kiiresti lõpule viia. Kuid sellist ülesannet saab olla ainult üks! Kui ilmub mõni teine, tuleb see lisada „Task Queue“-sse.

Ja nüüd kõige tähtsam. Kas näete iga veeru all numbreid? See on ülesannete arv, mis võib nendes veergudes korraga olla. Numbrid valitakse eksperimentaalselt, kuid arvatakse, et need peaksid sõltuma arendajate arvust meeskonnas.
Näiteks kui teil on meeskonnas 8 programmeerijat, siis saate reale "Areng" panna numbri 4. See tähendab, et programmeerijad ei tee korraga rohkem kui 4 ülesannet, mis tähendab, et neil on palju põhjuseid teha. suhelda ja kogemusi jagada. Kui panna sinna number 2, võib 8 kahte ülesannet täitval programmeerijal tüdineda või raisata liiga palju aega aruteludele. Kui seate selle 8-ks, siis teeb igaüks oma ülesande ja mõned ülesanded jäävad tahvlile pikaks ajaks, kuid Kanbani põhieesmärk on vähendada aega, mis kulub ülesande üleminekuks algusest peale. valmis etapp.
Keegi ei anna täpset vastust, millised need piirid peaksid olema, kuid proovige esmalt jagada arendajate arv 2-ga ja vaadata, kuidas see teie meeskonnas töötab. Neid numbreid saab seejärel kohandada vastavalt teie meeskonnale.
“Arendajate” all ei pea ma silmas mitte ainult programmeerijaid, vaid ka teisi spetsialiste. Näiteks veeru „Testimine” puhul on arendajad testijad, kuna testimine on nende ülesanne.

Sellisel tahvlil olevad ülesanded ei ole lihtsalt ülesanded, vaid see, mida nimetatakse minimaalseks turundusfunktsiooniks, st funktsiooniks, mida saab klientidele "müüa".
Rahaturufondide jaoks hea test on küsida endalt: "Kas ma kirjutaksin sellest funktsioonist ettevõtte ajaveebis?" Kui ei, siis see pole rahaturufond.

Mida uut ja kasulikku selline limiitidega tahvel annab?

Esiteks, Paralleelsete ülesannete arvu vähendamine vähendab oluliselt iga üksiku ülesande täitmise aega. Pole vaja ülesannete vahel konteksti vahetada, erinevaid üksusi jälgida, neid ajastada jne. - tehakse ainult seda, mida vaja. Sprindiplaneerimist ja 5% töötubasid pole vaja korraldada, sest veerus “ülesannete järjekord” on planeerimine juba tehtud ja detailne töö ülesandega algab AINULT siis, kui ülesannet hakatakse täitma.

Teiseks pistikud on kohe näha. Näiteks kui testijad ei tule testimisega toime, siis täidavad nad varsti kogu oma veeru ja uue ülesande sooritanud programmeerijad ei saa seda enam testimise veergu teisaldada, sest see on täis. Mida teha? Nüüd on aeg meeles pidada, et "me oleme meeskond" ja see probleem lahendada. Näiteks saavad programmeerijad aidata testijatel üht testimisülesannet sooritada ja alles siis uue ülesande vabasse ruumi teisaldada. See täidab mõlemad ülesanded kiiremini.

Kolmandaks saate arvutada keskmise ülesande täitmiseks kuluva aja. Kaardile saame märkida ülesande järjekorda lisamise kuupäeva, seejärel selle alustamise ja lõpetamise kuupäeva. Neid kolme punkti kasutades saab juba vähemalt 10 ülesande puhul arvutada keskmise ooteaja ülesandejärjekorras ja keskmise ülesande täitmise aja. Ja nendest numbritest saab juht või tooteomanik juba välja arvutada, mida tahab.

Kogu Kanbani saab kirjeldada vaid kolme põhireegliga:
1. Visualiseerige tootmist
- Jaga töö ülesanneteks, kirjuta iga ülesanne kaardile ja aseta seinale või tahvlile.
- Tootmisülesande oleku kuvamiseks kasutage nimega veerge.
2. Piirake WIP-i( pooleliolev või samal ajal tehtav töö) igal tootmise etapp.
3. Mõõda tsükli aeg(keskmine aeg ühe ülesande täitmiseks) ja protsessi pidevalt optimeerida selle aja vähendamiseks.

Ainult 3 reeglit!
Näiteks SCRUMis on 9 põhireeglit. XP-s - 13 ja klassikalises RUP-is - koguni 120. Tunnetage erinevust.

Siin ma lõpetan esimese artikli Kanbanist.
Ootan teie tagasisidet ja kommentaare, samuti ettepanekuid tulevaste artiklite jaoks.

Kanban - mis see on? Kui palju huvitavat teavet Kanbani kaart sisaldab ja millist funktsiooni see meetod tootmises täidab? Artiklis selgitame üksikasjalikult kanbani tõhusa kasutamise reegleid ja kirjeldame konkreetse näite abil ka vastavate kaartide kasutamise skeemi. Lisaks saate pärast materjaliga tutvumist teada, miks Kanbani tahvlit vaja on, millistes valdkondades on lisaks tootmisele soovitatav seda meetodit kasutada ja mis võib olla sellele hea alternatiiv.

Kontseptsiooni olemus ja meetodi põhijooned

Tänapäeval on märgata selget trendi laovarude hoiustamise kulude suurenemise suunas, mis on kanbani süsteemi sisaldavate “kohesete” laohalduskomplekside tekke peamiseks põhjuseks. Jaapani keelest tõlgituna tähendab "kanban" "silt", "märk". See termin toimib teabemeetodina, mille kaudu antakse luba või märge toote tootmiseks või väljajätmiseks (üleandmiseks) tõmbesüsteemis.

Esitatud teabe edastamise võimalus võimaldab teil täielikult hallata säästlikke tootmisliine teabekaartide abil, et viia konkreetne tootmistellimus üle järgmisest etapist eelmisele.

Sellise tootliku süsteemi arendajaks on Toyota Motors, kes selgitab esitletud ideed kui üht esimest katset just-in-time meetodit praktiliselt rakendada. Kanban-süsteemi kohaselt toimub tootmine järgmise reegli kohaselt: ettevõtte allüksused varustatakse ressurssidega kindlas koguses ja selgelt määratletud tähtajaks, mis on vajalik tellimuse täitmiseks.

Protsessi üksikasjad

Esitatud meetodi skeem on äärmiselt lihtne, kuid sellel on väga tõhus mõju tootmisprotsessi korraldusele. Pärast ettevõtte osakondade varustamist ressursside osas tehakse poolelioleva töö vajaliku mahu üksikasjalik arvutus, mis peaks tulema otse eelviimasest etapist (valmistoote tellimus on seega viimane etapp). protsess). Samamoodi esitatakse eelviimasest etapist eelmisele etapile taotlus kindla koguse pooltoodete kohta.

Seega kujuneb tootmismaht teatud kohas vastavalt järgmise tootmisetapi vajadustele. On loogiline, et iga kahe läheduses asuva tootmisprotsessi etapi vahel luuakse kahekordne ühendus:

Alates n-ndast etapist kuni n-1-ni küsitakse (“tõmmatakse”) vajalik kogus pooleliolevaid töid.
Alates n-1 etapist kuni n-nda etapini saadetakse materiaalseid vahendeid vajalikus mahus.

Teabe edastamise tööriistad

Kanbani paremaks mõistmiseks - mis see on, peaksite mõistma, et selles süsteemis teabe edastamise tööriist on spetsiaalsed kaardid, mis jagunevad kahte rühma:

Tööriistad, mis on otseselt seotud tootmistellimusega. Seda tüüpi kaartidel märgitakse esmalt osade arv, mis tuleb tootmisprotsessi eelmises etapis toota. Need saadetakse n-ndast tootmisetapist n-1 etappi ja on nende kohtade tootmisprogrammi väljatöötamise peamiseks põhjuseks.
Valikutööriistad sisaldavad teavet vajalike materiaalsete ressursside mahu kohta (see võib hõlmata pooltooteid, materjale, osi jne), mis tuleb võtta eelmises montaažietapis. Seda tüüpi kaartidel kuvatakse tootmisprotsessi n-nda etapi jaoks tegelikult saadud ressursi maht alates n-1.

Oluline on märkida, et kaardid võivad liikuda mitte ainult seoses ettevõtte sisemise infrastruktuuriga, vaid ka selle filiaalide või koostööd toetavate ettevõtete vahel.

Tõhusad meetodid Kanbani kasutamiseks - mis see on?

Toyota Motor Corporationi president Taiichi Ohno on välja töötanud mitmeid põhimõtteid kanban-kaartide maksimaalse efektiivsusega kasutamiseks:

Tootmistegevuse järgnev toiming eemaldab eelmisest toimingust kaardile märgitud osade mahu.
Ees asuv tootmisoperatsioon viiakse läbi vastavalt osade loomisele konkreetsel kaardil näidatud koguses ja järjestuses.
Pole ühtegi osa, mida saaks ilma kaardita luua. See säte võimaldab vähendada ületootmist ja ka toodete liigset liikumist. Seega on ringluses olevate kaartide maht võrdne maksimaalse laoseisuga.
Kaart on tellimus toote valmistamiseks (toode on igal juhul lisatud vastavale kaardile).
Mis tahes defektiga osi ei saa edasi anda järgnevasse protsessi. See säte võimaldab muuta toodete valmistamise võimalikult defektivabaks.
Kaartide arvu vähendamine tõstab nende tundlikkuse taset. Seega tulevad päevavalgele olemasolevad probleemid ja teostatakse tõhusat kontrolli varude üle.

Kaartide kasutamise omadused

Nagu selgus, toimub kanbani haldamine kindla skeemi järgi, mis hõlmab spetsiaalsete kaartide kasutamist. Seega tuleb nende kasutamise ajal täielikult rakendada nõudeid kõnealuse süsteemi absoluutse nähtavuse ja ülima ohutuse tagamiseks: kaartide kadumine, samuti nende segunemine on täielikult välistatud.

Eksperdid on välja töötanud tõhusa tööriista, mis võimaldab teil pakkuda Kanbani süsteemile maksimaalset tootlikkust. Selle meetodi tahvel toimib aktiivsete kaartide kogumispunktina, kuna töötajad kasutavad töökohal sageli mitut erinevat tööriista. Seega pannakse juhtplaadile kaardid, mis lähevad tootjale. Ja kui äsja saadud kaarditööriistad jõuavad “stardi” väljale, kantakse kogu vastava osanumbriga kaartide komplekt edasise tootmisprotsessi läbiviimiseks.

Kanbani meetodi kasutamise eelised – mis see on?

Seda kasutavad ettevõtted saavad materiaalseid ressursse iga päev (ja sageli mitu korda päeva jooksul). See võimaldab tootmisvarusid täielikult uuendada ligikaudu 100-300 korda aasta jooksul. Kui võrrelda Kanbani selliste süsteemidega nagu MRP või MAP, siis sel juhul toimub uuendusi umbes 10 korda sagedamini.

Kanban-meetodit on soovitatav hinnata näidetega, mis paljastavad selle absoluutse eelise teiste, vähem tootlike meetodite ees. Nii varustas Toyota Motors Corporation 1976. aastal ressursse ühte paljudest tootmiskohtadest kolm korda päevas ja 1983. aastal - iga kümne minuti järel.

Kanbane kasutatakse sageli töös supermarketitega (selleks spetsiaalselt moodustatud varu). Seega saadab tarbija supermarketile valikukanbani, mis näitab, nagu eespool märgitud, toote mahtu ja supermarket kannab talle üle kindlaksmääratud arvu tooteid. Samal ajal saadab supermarket tarnijale täiendamise kanbani, mille järel tarnija kannab tooted supermarketisse.

Meetodi põhielemendid

Kanban-süsteemi kõige olulisemad komponendid on järgmised:

Infokompleks, mis sisaldab oma struktuuris mitte ainult kaarte, vaid ka tootmis-, transpordi- või tarnegraafikuid, samuti tehnoloogilisi kaarte.
Kompleks, mis on otseselt seotud kontrolliga vajaduste üle ja professionaalselt.
Kompleks, mis võimaldab täielikku (TQM) ja valikulist (Jidoka) tootekvaliteedi kontrolli.
Kompleks, mis tagab tootmise absoluutse nivelleerimise.

Esitletud elemendid kooskasutatud võimaldavad saavutada lühima tootmistsükli, varade (sh varude) kõrge käibetaseme, samuti kõrvaldada või minimeerida nii tootmise ladustamiskulusid kui ka loomulikult saavutada toote kõrgeima kvaliteedi. toodet tootmisprotsessi igas etapis.

Süsteemi puudused ja selle kasutamise tulemused

Nagu igal arendusel, on ka just-in-time süsteemil mõned puudused. Esiteks on see raskus konkreetse toote tootmisetappide vahel kõrge järjepidevuse korraldamisel.

Teiseks on märkimisväärne oht tootmisprotsessi ja sellest tulenevalt ka toodete müügi katkemiseks. Sellegipoolest näitas maailma praktika üksikasjalik analüüs kõnealuse meetodi rakendamisel, et esitatud süsteem võimaldab vähendada tootmisvarusid poole võrra ja laoseisu 8% võrra, kiirendades oluliselt käibekapitali käibe ja , loomulikult on valmistoote kvaliteedi tõus.

Oluline on märkida, et kanbanide kasutamine ei lõpe tootmisprotsessidega. Seega kasutatakse süsteemi aktiivselt kontori- ja projektitegevustes, programmeerimisel (kanbani arendust on terve kompleks), aga ka personaalsete tulemuste saavutamisel (personaalne kanbani tüüp).

Tere päevast

Üks minu kui testimismeeskonna koordinaatori erialaseid huvisid on tarkvaraarenduse metoodikad. Praegu on nn Agiilsed metoodikad, eriti Scrum ja Kanban, muutumas üha populaarsemaks. Ebaausad “treenerid” mängivad “kärutatud” terminitel, seminarid ja sertifikaadid (“sertifitseeritud Scrumi meister”, “sertifitseeritud tooteomanik” jne) kasvavad hüppeliselt.

Enamikus hoolimatute artiklite ja koolituste puhul esitatakse mis tahes metoodikat kui maagilist hõbekuuli, mis lahendab koheselt suhtlusprobleemid ja päästab koheselt üksikud meeskonnaliikmed ebakompetentsusest. Üldiselt aitab see teil täpselt teie probleeme lahendada. Sel aastal astun Valgevene Riikliku Ülikooli magistriõppesse personalijuhtimise tehnoloogiate erialal ja kavatsen üksikasjalikult läbi mõelda levinumate tarkvaraarenduse metoodikate poolt- ja vastuargumente, aga ka piiranguid.

Töö käigus kohtasin sageli arusaamatusi ja metoodiliste vahendite ebaõiget tõlgendamist, moeka metoodika kasutamist konteksti arvestamata. Pärast artikli lugemist sain aru, et probleem on pigem globaalne kui lokaalne. Täna teen ettepaneku heita väike pilk Kanbanile, selle ajaloole, aluspõhimõtetele ja võimalikele rakenduspiiridele.

Termini ajalugu

Kanban on Jaapani termin, mida hakati tootmisega seoses kasutama 20. sajandi 60ndatel aastatel Toyotas. See põhimõte põhineb konveiertootmismeetodil, aga ka erinevatel kiirustel üksikute tehnoloogiliste toimingute tegemiseks tootmises. Püüan seda näpuga seletada. Igas tootmises on põhitoodang (“põhikonveier”) ja lisatootmine (“lisakonveierid”). Lõpptoodete tootmise kiiruse määrab põhikonveier, samas kui lisakonveierid ei saa toote vabanemise kiirust kiirendada, kuid võivad seda aeglustada, kui vajalikke osi õigel ajal ei vabastata.

Lisaks võivad tootmise käigus prioriteedid muutuda. Näiteks selgus, et vasakpoolseid peegleid valmistav jaam tootis 20 ja parempoolseid peegleid 10 tükki, samas kui koosteliinil on 15 autot ja mõlemat tüüpi peegleid on vaja 15 tükki. Tekib mõõdikute konflikt – toodang pole kvantitatiivselt langenud (täiendavad konveierid valmistasid õigeaegselt 30 toodet), kuid tootmist ähvardab endiselt seiskumine. Kanban on loodud selle probleemi lahendamiseks.

Kõige lihtsamal kujul sisaldab Kanban kahte lihtsat reeglit:

Tootmisjaamal on osade tootmisplaan (“mahajäämus”). Plaan on järjestatud prioriteedi järgi ja see võib igal ajal muutuda (näiteks liiga palju vasakpoolseid peegleid toodav jaam peaks saama esimesel võimalusel parempoolsetele peeglitele lülituda);
jaamas samaaegselt tehtavate ülesannete arv on piiratud (st toota korraga mitte rohkem kui etteantud arv peegleid). See piirang on vajalik nii jaama tootmiskiiruse kui ka plaanimuudatustele reageerimise kiiruse kontrollimiseks.

Olevik

Viimasel ajal on Kanban tarkvaratootmises palju populaarsust kogunud. Mõned meeskonnad peavad seda metoodikat äärmiselt kasulikuks, mõned kasutavad seda "Cargo kultusena". Minu empiirilise kogemuse põhjal töötab puhas Kanban tootemeeskondade jaoks halvasti (loe "põhikonveier"), kuid töötab suurepäraselt tugimeeskondade jaoks, näiteks:

tarkvara tugigrupid, kus “plaan” pole oluline, vaid oluline on muutustele reageerimise kiirus;
arendusmeeskondadest eraldi töötavad testimismeeskonnad;
tugiteenused;
muud näited "mitteoluliste tööstusharude kohta".

Eraldi tuleb märkida, et Kanban töötab hästi startupides, millel pole selget plaani, kuid kes tegelevad aktiivselt arendusega. Teen ettepaneku kaaluda näidet Kanbani kasutamisest tarkvaraarenduses. Vabandan juba ette koledate illustratsioonide pärast. Kujutagem ette, et ühest arendajast koosnev meeskond töötab väikese projekti kallal. Arengukava (mahajäämus) on järjestatud tööde tähtsuse järjekorras, meeskonna limiit tööülesannetele protsessis on 1 tükk.

Protsessi juhtimiseks saab projektijuht:

muuta tööülesannete arvu limiiti;
lisage kõrgema prioriteediga ülesanne (näiteks p0), et see saaks võimalikult kiiresti tehtud;

Tööprotsessi käigus võib juhtuda, et töö on blokeeritud (hostimine on katki, vajalik raamistik pole alla laaditud jne). Üldiselt tagastatakse blokeeritud töö mahajäämusse ja valitakse uus kõrgeima prioriteediga ülesanne. Sõltuvalt ülesannete iseloomust ja meeskonna tüübist võib limiiti suurendada või vähendada. Näiteks saab meie arendaja üheaegselt joonistada registreerimisvormi ja jälgida uue serveri juurutamise protsessi. Kui aga ülesande täitmise aeg on nõutust lühem, saab projektijuht limiiti vähendada või meeskonda suurendada. Seega korraliku juhtimise korral tagab Kanban antud meeskonnale võimalikult suure töökiiruse, maksimaalse reageerimiskiiruse muutustele ning samal ajal vähendab metoodika toetamise “kulusid”. Noh, see on kõik! Kanban pole lihtne, lihtne. See on väga lihtne!

Kanbani piirangud tootemeeskondades kasutamisel on järgmised:

see metoodika ei tööta hästi suurte meeskondadega (üle 5 inimese);
Puhtal kujul ei tööta Kanban hästi funktsionaalsete meeskondadega. Need. Erinevalt Scrumist on testimist ja arendust keeruline ühes meeskonnas ühendada. Parem idee on jagada protsess arendusjaamaks ja testimisjaamaks, millel on eraldi juhid ja mahajäämused;
Oma ajaloost ja spetsiifikast tulenevalt ei ole Kanban mõeldud pikaajaliseks planeerimiseks.

Järeldus

Kokkuvõtteks tahaksin lisada, et mis tahes metoodikate võrdlemine põhimõttel “kes on lahedam” ei ole produktiivne ja kontrakonstruktiivne (Captain Obvious). Igal enam-vähem levinud metoodikal on oma plussid, miinused ja kasutuspiirangud. Lisaks seavad Agile metoodikad oma olemuselt suuremaid nõudmisi meeskonnaliikmete meeskonnatööle ja kogemustele.

Kui teema vastu on huvi, siis jätkan Kanbani põhjalikumat käsitlemist, edaspidi teen ettepaneku Scrum ja RUP sorteerida tükkideks ja piltidena.

Täpsemalt ja selgemalt saab vaadata.

Kanban süsteemi abil reguleeritakse tehases toodetavate toodete kogust. Kanbanit nimetatakse lahja tootmise signalisatsioonisüsteemiks, kuna Kanban juhib tootmist sama osavalt kui aju ja närvisüsteem (esimene signaalisüsteem) inimkeha. Kanbani süsteemi peamine eelis on ületootmise vältimine. Kanban süsteemi eesmärk on toota ainult vajalikke tooteid vajalikus koguses ja õigel ajal.

Jaapani keeles tähendab sõna "kanban" "märki" või "märki". Kanban on tõmbetootmisel kasutatav kontrollkaart.. See on iga tootega kaasas olev töökäsk. Iga selline kaart on kinnitatud detaili või koostu külge, andes teada, kust see või teine osa pärit on ja kuhu see järgmiseks liigutada. Seega Kanban on infosüsteem, mis integreerib tehase ühtseks tervikuks, loob seoseid erinevate protsesside vahel ning koordineerib väärtusvoogu vastavalt kliendi nõudlusele.

Tõmba tootmine ja jäätmete kõrvaldamine

Kanbani süsteemis toodetakse eelmistes tootmisetappides täpselt nii palju osi, kui need eemaldati järgneva protsessiga. Pärast ühe protsessi lõpetamist eemaldavad töötajad osad eelmisest protsessist. Nad võtavad nii palju kui nad vajavad, kui nad seda vajavad. Taganemise signaaliks on tarbija tellimus. Sellised Tootmissüsteemi nimetatakse tõmbamiseks.

Tõmbesüsteem põhineb supermarketi ideel. Supermarketis ostavad kliendid seda, mis on riiulitel välja pandud. Riiuleid täiendatakse, kui toit ja kaup otsa saavad. Lean tootmises vastandatakse tõmbemeetodile push-meetodit, mille puhul toodetav kogus sõltub prognoositavast müügist.

Tõmbesüsteem võimaldab paindlikumalt läheneda tootmisele, et saaksite toota ainult neid tooteid, mida vajate, õiges koguses ja õigel ajal. Selline lähenemine väldib ületootmist – peamist kahjude allikat. Tõmbesüsteemi lõppeesmärk on saavutada null kanbani, kui pooleliolev töö on kõrvaldatud. Teisisõnu on kliendi tellimus see, mis käivitab pideva tootmisvoo. Ideaalis on tõmbesüsteemis tootmisprotsessi alati täiustatud.

Kuidas muuta oma Kanbani süsteemi tõhusamaks?

Kanban on kõige parem rakendada siis, kui ettevõte juba kasutab tõmbesüsteem ja praktiseerida väiketootmist, nimelt voolu üksikud tooted Ja rakkude tootmine. Kui need meetodid toimivad, muutub Kanban infosüsteemiks, mille kaudu rakud moodustavad ühtse terviku ja protsessid muutuvad järjepidevamaks. Kui Kanbanit kasutatakse ainult teatud osakondades, võib tootmissüsteemi tõmbamise ja lükkamise aspektide segaduse tõttu tekkida segadus. Kanban-süsteemi kasutamine võimaldab tuvastada põhjuseid, mis tekitavad kahjusid, nimelt ületootmist. Juhtudel, kui tõmbesüsteemi rakendamine ei ole tehase konkreetne eesmärk, võib nende probleemide lahendamine olla väga keeruline. Kui nõudlus ettevõtte toodete järele on ebaühtlane (eriti hooajaliste toodete puhul) ja tootmisprotsessile ei tule tõenäoliselt kasu väikesemahulisest tootmisest, võib kanbani süsteemi kasutamine osutuda ebaefektiivseks ja mõnikord ka ebavajalikuks.

Kuna kanbanide arv tõmbamissüsteemis järk-järgult väheneb, kerkivad esimesena esile ümberlülitusaegadega seotud probleemid. Üleminekuaegade vähendamiseks tuleks koheselt rakendada parendusmeetodeid, seejärel taastub taktiaeg ja segatud väikesemahulist tootmisvoogu saab juhtida kanbanide abil. Kui te ei rakenda meetodeid, mis aitavad üleminekuaega lühendada, ei suuda tehas tarbijanõudluse muutustele reageerida ning kanban-süsteemi juurutamise ja tõmbetootmise põhieesmärk on just nimelt adekvaatselt reageerida nõudluse kõikumisele.

Autonoomne teenus- See on tõmbetootmise teine oluline element. Masinate töökorras hoidmine, rutiinse hoolduse teostamine ja muud seadmete üldise hoolduse elemendid on Kanbani süsteemi edukaks toimimiseks hädavajalikud.

Kanban on täiustatud visuaalse juhtimise meetod, mille edu sõltub suuresti töötajate distsipliinist ja 5S-süsteemi poolt seatud algatuste olulisuse mõistmisest. Tõmbetootmissüsteemi tugev alus on visuaalne töökoht. Hästi korraldatud töökoht saab alguse 5S põhitõdede juurutamisest ja töökoha korrashoidmisest, rippuvate siltide paigaldamisest, kõigi töötajate algatatud pidevast täiustamisest.

Kanban süsteemi integreerimine MRP II-ga

Kanbani süsteemi MRP II-ga (materjalivajaduste planeerimise süsteem) integreerimise probleeme käsitletakse paljudes raamatutes, mistõttu me sellel teemal pikemalt ei peatu. MRP II on arvutisüsteem, mida kasutatakse mitte niivõrd tarbijanõudluse muutustele reageerimiseks, vaid tootmiseks vajalike ressursside hindamiseks. Teisisõnu, MRP II rakendusala on push tootmine. Kuigi mõned ettevõtted püüavad liikuda tõmbetootmise poole, integreerides MRP-süsteemi JA kanban-süsteemi, uuritakse selles raamatus kanbanit kui tõelise tõmbetootmise rakendamise mehhanismi.

Kanbani süsteemi "piloot" või laialdane rakendamine

Väga oluline on otsustada, kuidas Kanbani rakendatakse – kõikjal või mitmes osakonnas. Pidage meeles, et Kanban on süsteem, mis korraldab kõik protsessid tehases ühtseks tervikuks, sidudes need kliendi vajadustega. Kui valite kanbani juurutamise vaid mõnes osakonnas, võib see vähendada üldist mõju ja neutraliseerida kanbani süsteemi kui sellise idee.

Siiski on tõepoolest võimalik kanbani rakendada üksikutes kauplustes isegi pideva tootmisvoo puudumisel. Sel juhul aitab Kanban tuvastada probleeme tootmisvoos. Kui kasutuses olevate kanbanide arv väheneb, venivad üleminekuajad pikemaks, ilmnevad toodete tarnimise viivitused, seadmed seisavad jõude, suurenevad töös olevad varud, mis kõik takistavad toote tootmist. Sellistel juhtudel tuleks rakutootmise rakendamiseks ja ühes tükis voo loomiseks kasutada teisi lean tootmismeetodeid: 5S, SMED, autonoomne hooldus ja optimaalne seadmete paigutus. See on vajalik, et Kanbanist saaks see, mis ta tegelikult on: tõmbetootmise säilitamiseks vajalik sidemehhanism.

Teisest küljest, kui olete juba 5S-i, kiire ülemineku ja autonoomse hoolduse juurutanud ning soovite üle minna tootmise tõmbamisele, soovitame tungivalt laiendada Kanbani süsteemi kogu tehases. Sel juhul sünkroniseerib kanbani süsteem kõik tootmisprotsessid, ühendades need üheks ahelaks ja määrab kogu tootmise üldise tempo vastavalt taktiajale - tarbijate nõudluse "impulsile". Kanban aitab tuvastada tööpõrandal probleemsed kohad, mis muidu võiksid märkamatuks jääda. Kanbani süsteemiga muutub säästlik tootmine reaalsuseks.

Kuidas saab Kanban teie ettevõtet paremaks muuta?

Meid kõiki õpetati tõhusalt töötama: mida rohkem tooteid toodame, seda paremini me töötame. Nii on meile alati öeldud. Võtsime selle väite tegevusjuhiseks: "rohkem" tähendab "parem". Kanbani kasutava tõmbesüsteemi lahja tootmismeetodi puhul pole see väide aga asjakohane.

Kanbani süsteemis viib põhimõte "rohkem, veelgi rohkem" ja toodete väljalaskmine ainult seetõttu, et on midagi toota, kõige tohutuma kahju, see tähendab ületootmise. Kanban-süsteemis toodavad töötajad tooteid ainult siis, kui nad saavad signaali. Kanban on signalisatsioonisüsteem ja tootmise nõue tuleneb ülesvoolu protsessist, alustades kliendi tellimusest.

Kambani juhtimine tähendab majanduspraktikas sellist äritegevuse korraldamist – olgu selleks siis tootmine, logistika või jaemüük –, mida võib iseloomustada kui just-in-time süsteemi. Mõiste “Kanban” ise, mis on jaapani keelest tõlgitud kui “nähtav kaart”, sisaldab lähenemist äri optimeerimisele, jagades toiminguteks ja visualiseerides tööprotsessi. Ja kuigi Toyota kasutas Kanbani filosoofiat esmakordselt rohkem kui pool sajandit tagasi, töötas selle meetodi selle tänapäevases tähenduses välja ja pakkus välja majandusteadlane David Anderson.

Mis on Kanbani süsteem?

Majandusteadlane David Anderson jõudis 2005. aasta kevadel Tokyos keiserliku palee idapoolsetes aedades jalutuskäiku tehes järeldusele, et turistidele mõeldud korduvkasutatavad mitmevärvilised plastpiletid, nimega Kanban, võivad saada majandustegevuse vahendiks. ebakindluse tingimused. Jalutuskäiku tehes ja Kanbanis turnides lõpetas ta sisuliselt "mõttelise töö". Kontrollerid tegid spetsiaalsele veergudega tahvlile märkmeid külastajatele kaartide väljastamise ja tagasisaamise kohta.

Anderson jõudis järeldusele, et kaartide ja veergude kaudu on võimalik näiteks kontrollida laoseisu või kauba tarnimist. Tänu just-in-time kontseptsioonile on võimalik minimeerida materjalikulusid ja optimeerida müüki. Midagi sarnast kasutati Toyota masinaehituse tootmises juba eelmise sajandi 60ndate lõpus, kuid siis oli samaaegselt sooritatud ülesannete arv minimaalne, töö tehti range algoritmi järgi.

Seega nägi Anderson Kanbani tahvlit väärtusliku tootmisvahendina, mida ta kirjeldas raamatus Kanban: Successful Evolutionary Change for Your Technology Business.

Mida teeb Kanban tootmiseks?

Seega on David Andersoni sõnastatud Kanbani metoodika evolutsiooniline ülesannete haldamise protsess, mis hõlmab töö (tarnete) täpset korraldamist.

"Peamine põhimõte on, et ükski töö ei tohiks olla asjatu," ütleb majandusteadlane Maxim Yurkin. - Kanban võimaldab ärimehel optimeerida projekti etappe juba enne selle algust, lähtudes tema käsutuses olevast visuaalsest teabest sarnase töö lõpetamise kohta. See on see, millele "lahja tootmine" on üles ehitatud.

Kui võrrelda tootmisprotsesse enne ja pärast Andersoni metoodika juurutamist, näeme, kuidas materjalikulud päevast päeva vähenevad. Samas juhinduvad töötajad Kanbani kaardil olevast kirjest “Tehtud” (“tehtud”) “just in time”. Andersoni meetodit rakendanud ettevõtjad teatasid oma äri kasumlikkuse kasvust 25-30% – ilma suuremate investeeringuteta. Aja jooksul on Kanbani meetod muutumas laiemalt levinud ja nõudlikumaks nii keskmistes kui ka väikestes ettevõtetes.

Kuidas Kanbanit ettevõttes tutvustada?

Venemaa meedias avaldatud publikatsioonide analüüs näitab, et paljudel juhtudel tähendab Kanbani juurutamine „just-in-time“ tarnesüsteemi integreerimist, mis kasutab spetsiaalseid tahvleid veergudega „to do“ (algas tööd), „in“. edusammud” (töötamine), “ülevaatus”” (töö läbivaatamine), “test” (tulemus), “tehtud” (lõpetatud). Seega kontrollitakse kõigi töötajate tegevust ja ei tohi tekkida olukorda, kus ühel töötajal on kogunenud tohutult palju täitmata ülesandeid, teine aga istub jõude.

Andersoni raamatu venelasest lugeja võib arvata, et Kanban on intuitiivne. See on nagu vankri hobuse ette panemine, sest traditsiooniline planeerimine käib nullist. See meetod julgustab "lõpetama alustamist ja alustama lõpetamist".

4 Kanbani põhimõtet

JIT-süsteemi mõistmiseks ja edukaks juurutamiseks oma ettevõttes peate tähelepanu pöörama üheksale Kanbani põhiasjale: 4 põhimõttele ja 5 reeglile. Alustame põhimõtetega:

Hinda alati seda, mida teed.
Olge valmis evolutsioonilisteks muutusteks.
Austage rolle, kohustusi ja tiitleid.
Julgustage mitteametlikke juhte.

Fakt on see, et Kanbani kontseptsioon ei paku "raua" seadeid, veel vähem ette "terapeutilisi" protseduure. Seetõttu soovitab Anderson olemasolevale töövoogudele lisada reegleid, mida tuleb tootmises igapäevaselt järgida. Pange tähele, et Kanbani meetod hõlmab vähima takistuse tee järgimist. Teisisõnu julgustab see praeguses süsteemis pidevaid järkjärgulisi ja evolutsioonilisi muudatusi, kuna revolutsiooniline muutus seisab silmitsi märkimisväärse vastupanuga – nii töötajate kui ka klientide poolt.

David Anderson julgustab väärtustama olemasolevaid äriprotsesse, aga ka töötajate rolle, ametinimetusi ja kohustusi. Teisisõnu, kui mõned protsessid protseduuri sees on õigesti sooritatud, siis tasub need salvestada. Nende moderniseerimise juurde saate naasta hiljem, kui muid protsesse täiustatakse. Oluline on mõista, et järkjärguline muutus ei tohiks tekitada hirmu, mis takistaks edasiminekut. Vajalik on kokku panna meeskond, mis võimaldaks ärimehel uusi tooteid laialdaselt tutvustada ja seeläbi hõlbustaks Kanbani kontseptsiooni elluviimist.

Samuti märgitakse, et igas meeskonnas on inimesi, kes naudivad autoriteeti, isegi kui neil pole kõrgeid positsioone. Neid aga kuulatakse ja austatakse. Nende karjääri kasvu on mõistlik edendada. Selliste mitteametlike juhtide julgustamine avaldab positiivset mõju ettevõtte kui terviku tervisele.

5 Kanbani reeglit

Lisaks neljale põhimõttele kirjeldas David Anderson oma raamatus “Kanban: Successful Evolutionary Changes for Your Technology Business” 5 põhireeglit, millest edukad ärimehed kinni peavad:

Töövoo visualiseerimine.
Pooleli tööde piirang (WIP – Work-In-Progress).
Töövoo juhtimine.
Muudatuste selgus ja läbipaistvus.
Koostöö parandamine (mudeleid ja teaduslikku meetodit kasutades).

Räägime reeglitest üksikasjalikumalt. Kuna Kanbani eesmärk on järjepideva optimeerimise kaudu töövoogu positiivselt muuta, tuleb ennekõike vastata põhiküsimusele: mis on ettevõtte evolutsiooni eesmärk? Seda saab teha alles pärast protsessi toimimise mõistmist. Alles siis on soovitatav proovida integreerida just-in-time kontseptsiooni.

Äriprotsesside visualiseerimine on väga tõhus meetod. Visualiseerida saab nn Kanbani tahvli või LeanKiti platvormi abil. Pange tähele, et LeanKit toetab säästliku tootmise põhimõtete juurutamist, et luua tingimused äriprotsesside pidevaks täiustamiseks ja uuenduste integreerimiseks.

"Visualiseerimismeetodid on sama mitmekesised kui optimeeritavad töövood," selgitab Maxim Yurkin. "Lisaks töövoogudele ja täitmisajale võib tegevuste klassifitseerimisel kasutada muid kriteeriume, nagu tururisk ja viivituskulud."

Kui visualiseerite oma töövoo õigesti, leiate hõlpsalt WIP-i fragmente, mida nimetatakse "ärimõrvariteks".

"See tähendab, et võitlus poolelioleva töö vastu peab jätkuma kogu tööprotsessi vältel," kirjutab David Anderson. - Kuna õigel ajal tegemata töö „viib“ negatiivse järgmisse etappi ja seejärel kahekordistab negatiivse järgmisele sammule. Ja see on nagu lumepall. WIP-i vähendamine nullini on Kanbani nurgakivi.

Tagasiside on väga oluline. Kui olete muudatused teinud, peate veenduma, et olukord on tõepoolest paranenud.

„Kanbani meetod on põnev teekond, kui sa ei tea, kuhu sa välja jõuad,“ tuletab David Anderson meelde. "Ühe probleemi lahendamine võib teise halvendada."

Et muudatuste elluviimise protsess ummikseisu ei satuks, peab see olema arusaadav kõigile projektis osalejatele. Sellega seoses on loogiline tsiteerida teist Andersoni tsitaati: „Ilma selge arusaama, kuidas asjad peaksid toimima, kipub igasugune probleemide arutelu olema emotsionaalne, anekdootlik ja subjektiivne. See on sama tõsi kui põlvnemisreaktsioon."

Kanbani meetodi puhul on võtmemõisteks Kaizen, mis tähendab pidevat, järkjärgulist ja positiivset muutust.

"JIT-i integreeriv ärimees peab mõistma, mis Kaizen on," ütleb Anderson. "Kui te ei ole pühendunud täiustamisele, pole Kanbani rakendamisel mõtet."

Kanban vs. Agiilne

On selge, et Kanbanil on oma halvustajad, väites, et teised mõisted on paremad. Samal ajal soovitavad eksperdid mitte segi ajada Andersoni meetodit teiste tunnustatud juhtimissüsteemidega – nende sõnul on see nagu õunte võrdlemine apelsinidega. Kõige sagedamini on Kanbani kontseptsioon vastu:

Agiilne;
Scrum;
lahja;
Kuus Sigma;
PRINTS2.

Samal ajal on Kanban ja Agile sarnased nagu vennad, ainsa erinevusega, et Anderson pakkus välja laiema meetodi, samas kui Agile keskendub rohkem IT-projektidele. Mõlemad meetodid hõlmavad evolutsioonilisi muutusi, kuigi esimesel juhul on ärimehe roll Agile Manifesti järgi võrreldamatult olulisem kui töötaja staatus.

Kui Kanban hõlmab lepitamatut võitlust poolelioleva töö vastu, siis agiilne filosoofia on selles osas liberaalsem, kuna seab esikohale paindlikkuse – valmisoleku muudatusteks, mis on “tähtsamad kui algne plaan”.

Programmeerijad vaatavad tõenäolisemalt "mahajäetud alamprojekte", kui leitakse optimaalsem tarkvaraarhitektuur. Ettevõtted Dostaevsky, Chernika, uKit Group ja teised võivad teile öelda, et Kanban on Venemaal tõhus meetod.

Järeldus

Kanban on intuitiivne viis töövoo korraldamiseks, mis aitab ärimehel teha rohkem ja töötada kiiremini. Kuid süsteem “just in time” ei ole imerohi kõigi probleemide jaoks, vaid tööriist, mida tuleb osata õigesti kasutada, tehes iga päev tööprotsessis peeneid muudatusi, mis koos annavad tulemusi.

Pange tähele, et Kanban on ebaefektiivne keerukates mitmetasandilistes tehnoloogilistes süsteemides, kuid on peaaegu ideaalne väikestele ja keskmise suurusega ettevõtetele.