Vai plānojat ieviest Kanban savos biznesa procesos? Lūk, ar ko sākt. Kanban sistēma: kas tas ir, ar ko sākt, kā to ieviest, galvenie principi

Pēc iespējas īsi par Kanban metodi, tās pamatterminiem un pielietojuma jomām.

Mēs pēc iespējas īsi aprakstījām Kanban metodi, tās pamatnosacījumus un pielietojamības jomas.

1. Kas ir Kanban metode?

Kanban metode ir metode jūsu darba uzlabošanai. Lai ko jūs darītu, pastāv hipotēze, ka Kanban metodes praktizēšana ļaus jums paveikt savu darbu vēl labāk. No Kanban viedokļa tas nozīmē, ka jūs labāk apmierināsit klientu vēlmes.

Kanban kā IT pārvaldības rīku ieviesa Deivids J. Andersons Microsoft (2005) un Corbis. Un metode kļuva plaši izplatīta un nosaukta 2007. gadā.

2. Vai Kanban Method un Toyota Kanban ir viens un tas pats?

(Lielākā karte). Noteikti ne tādā veidā. Kanban Toyota rūpnīcās ir taupīga ražošana, kuras noteicošais princips ir jēdziens “tieši laikā”. Kanban kā vadības termins patiešām nāca no Toyota. Tulkojumā no japāņu valodas šis vārds nozīmē “signāls” vai “karte”. Automobiļu rūpnīcās šādas kartes izmantoja, lai no viena posma uz nākamo pārraidītu informāciju par to, cik un kādas detaļas būs vajadzīgas.

Apskatīsim īsu piemēru. Mums ir jāizgatavo trīs automašīnas “tieši laikā”. Tas nozīmē, ka mēs varam iepriekš precīzi noteikt, cik detaļu mums būs nepieciešams noteiktos posmos, un mēs sākam no gala izvilkt nepieciešamo detaļu skaitu, lai izveidotu šo automašīnu, atbildot uz jautājumiem: “Cik litrus krāsas mēs iekrāsosim. vajag?”, “Cik riteņu?”, “Cik dzinēju?” un tā tālāk. Tādējādi mēs neveidojam rezerves daļu pārpalikumu pārpalikumu veidā un ietaupām uz noliktavu, loģistikas un citām izmaksām.

Arī Kanban metode atbilst jēdzienam “tieši laikā”, taču atšķirībā no Toyota rūpnīcām šeit mēs runājam par intelektuālo darbu. Citiem vārdiem sakot, programmētāja kodu vai mārketinga speciālistu ideju vidusmēra cilvēks nevar pieskarties un redzēt, kamēr tas nepārvēršas par galaproduktu vai pakalpojumu. Tādējādi Kanban metode tiek izmantota, lai vizualizētu intelektuālā darba plūsmu un samazinātu šī nepabeigtā darba apjomu. Pateicoties tam, tiek panākts vienots un prognozējams pakalpojuma sniegšanas ātrums gala patērētājam.

3. Vai Kanban metodi var izmantot ārpus IT?

Jā. Kanban metode ir piemērota jebkura radoša un intelektuāla darba plūsmas vizualizēšanai. Bet daudz efektīvāk ir to izmantot, izmantojot pakalpojumu paradigmas prizmu. Skatieties uz to, ko jūs darāt kā pakalpojumu. Kādi posmi tiek veikti, lai pakalpojums tiktu sniegts? Pēc kādiem kritērijiem jūs sapratīsiet, ka pakalpojums tiek sniegts atbilstoši Klienta vēlmēm? Tas ir sākumpunkts Kanban metodes izmantošanai. Kanban praktizētāji šo punktu sauc par "sāciet ar to, kas jums ir tagad".

4. Vai Kanban ir kā Scrum?

Nē. Scrum ir sistēma ar stingriem noteikumiem un robežām. Scrum ietvaros varat izmantot dažādus rīkus un metodoloģijas, taču, ja atsakāties no kaut kā Scrum prasītā, to vairs nevar uzskatīt par Scrum. Kanban ir metode, rīks ar prakšu un principu kopumu. Jūs varat izmantot visas prakses, dažas prakses vai neizmantot tās vispār. Kanbanā nav stingras koncepcijas par to, kas ir Kanban un kas nav Kanban. Tomēr saprātīga prakses izmantošana var ievērojami palīdzēt nodrošināt visaugstākās kvalitātes pakalpojumus un apmierināt klientu vēlmes.

5. Vai Kanbanam ir vērtības?

Jā. Ir deviņi no tiem: caurspīdīgums, līdzsvars, sadarbība, koncentrēšanās uz klientu, plūsma, vadība, sapratne, vienošanās, cieņa.

6. Jūs rakstījāt par Kanban principiem. Kas viņi ir?

Kanban ir pamatprincipi, kurus sauc arī par pārmaiņu vadības principiem:

1. Sāciet ar to, kas jums ir tagad.
2. Vienojieties par evolūcijas attīstību.
3. Veicināt vadības attīstību visos līmeņos.

Tā kā Kanban metode dzīvo pakalpojumu paradigmā, tā ievēro savus principus:

1. Uzziniet klienta vajadzības un cerības.
2. Pārvaldiet darbu, ļaujiet cilvēkiem organizēties ap to.
3. Izstrādājiet noteikumus, lai uzlabotu veiktspēju.

7. Kāda ir Kanban prakse?

Ir arī seši no tiem:

1. Vizualizēt.
2. Ierobežojiet nepabeigtos darbus.
3. Pārvaldiet darba plūsmu.
4. Izmantojiet skaidrus noteikumus.
5. Ieviest atgriezeniskās saites cilpas (kadences).
6. Uzlaboties un attīstīties.

Tie ir tieši praktiski paņēmieni, kurus izmantojam, lai uzlabotu savu darbu un uzlabotu pakalpojumu kvalitāti.

8. Ak, kadences! Kas ir Kanbanas kadences?

Kadence ir termins no mūzikas. Kanban metodes kontekstā tas apzīmē ritmu. Kadences ir regulāras sanāksmes, kas ir arī atgriezeniskās saites cilpas. Regularitāte nosaka ritmu, ar kādu plūst darba plūsma. Septiņas kadences:

1. Kanban sanāksme (katru dienu). Šeit mēs apspriežam bloķēto uzdevumu statusu.
2. Rindas aizpildīšanas sanāksme (parasti reizi divās nedēļās). Mēs uzņemamies atbildību par to, ko darīsim kā pakalpojumu.
3. Piegādes plānošanas sanāksme (parasti reizi divās nedēļās). Izpildītās saistības atgriežam atpakaļ.
4. Pakalpojuma pārskata sanāksme (parasti reizi divās nedēļās). Izmantojot metriku, pārrunājam servisa kvalitāti un kā to vajadzības gadījumā uzlabot.
5. Darbības sanāksme (parasti reizi mēnesī). Mēs apspriežam saistīto pakalpojumu mijiedarbības kvalitāti ar metriku.
6. Riska pārskata sanāksme (parasti reizi mēnesī). Ar metriku apspriežam bloķēto uzdevumu ietekmi uz pakalpojuma darbību.
7. Stratēģijas pārskata sanāksme (parasti reizi ceturksnī). Mēs apspriežam izmaiņas stratēģijā ar metriku.

9. Es kaut ko dzirdēju par dienesta klasēm. Kas tas ir?

Kanban izmanto pakalpojumu klases, lai noteiktu prioritāti noteiktiem darba veidiem, klientiem vai mazinātu uzņēmējdarbības ietekmi, piemēram, kavēšanās izmaksas. Kavējuma izmaksas ir negūtā peļņa vai izmaksas, kas radušās pakalpojumu novēlotas piegādes dēļ. Apskatīsim kavēšanās izmaksu ietekmi un atbilstošo pakalpojumu klasi, izmantojot piemērus:

1. Paātrinātā klase – neatliekamā pirmā palīdzība-reanimācija. Braukšana pa speciālu joslu. Nav laika atlikt problēmas risināšanu. Vajag pēc iespējas ātrāk.
2. Fiksēta datuma klase – aizkavēšanās izmaksas pēc noteikta laika ievērojami palielinās. Piemērs: projekts federālā likuma formā ar noteiktu sākuma datumu. Ja nepanāksim to laikā, pastāv risks zaudēt licenci.
3. Standarta klase - kavēšanās izmaksas palielinās proporcionāli laikam. Ja mēs to darām uzreiz, mēs nekavējoties gūstam peļņu. Ja mēs to darām ilgu laiku, mēs gūstam peļņu uz ilgu laiku.
4. Nemateriālā klase - mēs to darām, bet šis darbs nenes nekādu acīmredzamu peļņu, kavēšanās izmaksas aug lēnām. Piemēram, mājas uzkopšana. Jums nav regulāri jātīra, bet pēc pusgada jums būs jāveic rūpīga tīrīšana.

10. Kā ir ar metriku? Kā novērtēt pakalpojuma efektivitāti?

Kanban metodei ir metrika, kas ļauj atbildēt uz jautājumiem: kādas ir problēmas darba plūsmā, kāda ir pakalpojuma caurlaidspēja, kāds ir izpildes laiks, kāds ir bloķēšanas izšķiršanas laiks, kāds ir cikla laiks un kas tiek sadalīti darba veidi? Tas viss ļauj servisa vadītājam, pamatojoties uz uzkrātajiem datiem, pieņemt lēmumus par pakalpojumu kvalitātes attīstību un uzlabošanu.

11. Ar kādām problēmām Kanban saskaras ieviešanas laikā?

Galvenais izaicinājums ir izskaidrot cilvēkiem visos līmeņos Kanban prakses vērtību: vizualizāciju un notiekošā darba ierobežošanu. Sakarā ar to, ka cilvēki neredz intelektuālā darba apjomu, viņiem ir grūti saprast, kādai slodzei viņi ir pakļauti. Bet, piemēram, smadzenes ir tāds pats muskulis kā bicepss. Iedomājieties sporta zāli: jūs ienācāt un redzat svaru uz stieņa: “Labi, tas ir par maz. Un tagad tas ir par daudz. Bet tas ir pareizi!” Tādā pašā veidā jāstrādā ar smadzenēm: “Šis ir liels uzdevums, un šis ir mazs, un vispār kaut kā esmu uzņēmies daudz. Es ierobežošu slodzi." Vizualizējot darba plūsmu no gala līdz galam visos līmeņos un ierobežojot nepabeigtā darba apjomu, mēs izveidojam zināšanu darba vilkšanas principu un nodrošinām vienmērīgu tā rezultātu plūsmu saviem klientiem.

12. Kādas programmas ir paredzētas Kanban metodei?

Arī tādu ir daudz. Mēs uzskaitām tikai profesionālus, kas izstrādāti īpaši šai metodei. Mūsu sirds ir dota Krievijas attīstībai Kaiten. Papildus tam ir arī TargetProcess, SwiftKanban, LeanKit un citi.

13. Un kuri uzņēmumi jau izmanto Kanban metodi?

Krievu vidū ir Alfa-Bank, Home Credit Bank, Pochta-Bank, Dodo Pizza, HeadHunter, Clever un citi. No ārzemēm: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, bārs. Šo sarakstu var turpināt vēl ilgi.

14. Vai ir vēl kaut kas svarīgs?

Jā. Visbeidzot, es vēlos atzīmēt divu lomu nozīmi Kanban metodē. Tie ir pakalpojumu sniegšanas pārvaldnieks un pakalpojumu pieprasījumu pārvaldnieks. Pirmais ir atbildīgs par šķēršļu novēršanu piegādes plūsmā. Otrais ir paredzēts, lai pārvaldītu pieprasījumu plūsmu no daudziem klientiem. Ir ļoti svarīgi, lai šīs divas lomas būtu partneri un strādātu kopā.

15. Labi, es saprotu. Kur uzsākt Kanban ieviešanu organizācijā?

Lai uzsāktu Kanban ieviešanu organizācijās, izmantojam S.T.A.T.I.K rīku. – sistemātiska pieeja Kanban izmantošanai. Vairāk par to var lasīt internetā. Bet mēs iesakām apmeklēt apmācību, kurā šis rīks tiek apmācīts biznesa spēles formātā. Izmantojot savu pakalpojumu (organizāciju) kā piemēru, varat izveidot Kanban sistēmu turpmākai lietošanai kaujas apstākļos.

Treneris un konsultants par veiklām metodoloģijām, Scrumtrack.

Labdien

Viena no manām profesionālajām interesēm, kā testēšanas komandas koordinatoram, ir programmatūras izstrādes metodoloģijas. Šobrīd arvien populārākas kļūst tā sauktās Agile metodoloģijas, īpaši Scrum un Kanban. Negodīgi “treneri” spēlē ar “apgalvotiem” terminiem, semināri un sertifikāti (“sertificēts Scrum meistars”, “sertificēts produkta īpašnieks” utt.) pieaug ar lēcieniem un robežām.

Lielākajā daļā negodīgo rakstu un apmācību jebkura metodika tiek pasniegta kā maģiska sudraba lode, kas acumirklī atrisinās komunikācijas problēmas un uzreiz paglābs atsevišķus komandas locekļus no nekompetences. Kopumā tas palīdzēs atrisināt tieši jūsu problēmas. Šogad iestājos maģistrantūrā Baltkrievijas Valsts universitātē cilvēkresursu vadības tehnoloģiju specialitātē un plānoju detalizēti apsvērt izplatītāko programmatūras izstrādes metodoloģiju plusus un mīnusus, kā arī pielietojamības ierobežojumus.

Darba procesā nereti saskāros ar pārpratumiem un nepareizu metodisko līdzekļu interpretāciju, modīgas metodikas lietošanu, neņemot vērā kontekstu. Izlasot rakstu, sapratu, ka problēma ir vairāk globāla nekā lokāla. Šodien es ierosinu nedaudz apskatīt Kanban, tā vēsturi, pamatprincipus un iespējamās piemērošanas robežas.

Termina vēsture

Kanban ir japāņu termins, ko Toyota sāka lietot saistībā ar ražošanu 20. gadsimta 60. gados. Šī principa pamatā ir konveijera ražošanas metode, kā arī dažādi ātrumi atsevišķu tehnoloģisko operāciju veikšanai ražošanā. Es mēģināšu to izskaidrot ar pirkstiem. Jebkurā ražošanā ir galvenā ražošana (“galvenais konveijers”) un papildu ražošana (“papildu konveijeri”). Galaproduktu ražošanas ātrumu nosaka galvenais konveijers, savukārt papildu konveijeri nevar paātrināt produkta izlaišanas ātrumu, bet var to palēnināt, ja vajadzīgās detaļas netiek atbrīvotas laikā.

Turklāt ražošanas laikā var mainīties prioritātes. Piemēram, izrādījās, ka stacija, kas ražoja kreisos spoguļus, saražoja 20 gabalus, bet stacija, kas ražoja labos spoguļus - 10 gabalus, savukārt uz konveijera atrodas 15 automašīnas un ir nepieciešami 15 abu veidu spoguļi. Rodas metriku konflikts - ražošana kvantitatīvi nav kritusies (papildus konveijeri laikā saražoja 30 produktus), taču ražošana joprojām riskē apstāties. Kanban ir paredzēts, lai palīdzētu atrisināt šo problēmu.

Vienkāršākajā formā Kanban ietver divus vienkāršus noteikumus:

• Ražošanas stacijai ir detaļu ražošanas plāns (“atpakaļ atlikums”). Plāns ir sakārtots pēc prioritātes un var mainīties jebkurā laikā (piemēram, stacijai, kas ražo pārāk daudz kreiso spoguļu, vajadzētu pēc iespējas ātrāk pārslēgties uz labās puses spoguļiem);
• stacijā vienlaikus veicamo uzdevumu skaits ir ierobežots (t.i., vienlaikus ražot ne vairāk par noteiktu skaitu spoguļu). Šis ierobežojums ir nepieciešams, lai kontrolētu ražošanas ātrumu stacijā, kā arī reaģēšanas ātrumu uz plāna izmaiņām.

Tagadne

Pēdējā laikā Kanban ir guvis lielu popularitāti programmatūras ražošanā. Dažām komandām šī metodika šķiet ārkārtīgi noderīga, dažas to izmanto kā “kravas kultu”. Pamatojoties uz manu empīrisko pieredzi, tīrais Kanban nedarbojas produktu komandām (lasiet "pamatkonveijera"), taču lieliski darbojas atbalsta komandām, piemēram:

• programmatūras atbalsta grupas, kur “plāns” nav svarīgs, bet svarīgs ir reakcijas ātrums uz izmaiņām;
• testēšanas komandas, kas strādā atsevišķi no izstrādes komandām;
• atbalsta dienests;
• citi "nebūtisku nozaru" piemēri.

Atsevišķi jāatzīmē, ka Kanban labi darbojas startup uzņēmumos, kuriem nav skaidra plāna, bet kuri aktīvi strādā pie attīstības. Es ierosinu apsvērt piemēru Kanban izmantošanai programmatūras izstrādē. Jau iepriekš atvainojos par neglītajām ilustrācijām. Iedomāsimies viena izstrādātāja komandu, kas strādā pie neliela projekta. Attīstības plāns (atliktais atlikums) ir sakārtots darbu prioritārā secībā, komandas limits uzdevumiem procesā ir 1 gab.

Lai vadītu procesu, projekta vadītājs var:

1. mainīt uzdevumu skaita ierobežojumu darbā;
2. pievienojiet uzdevumu ar augstāku prioritāti (piemēram, p0), lai tas tiktu veikts pēc iespējas ātrāk;

Darba procesā var gadīties, ka darbs tiek bloķēts (sabojājies hostings, nav lejupielādēts nepieciešamais ietvars utt.). Parasti bloķētais darbs tiek atgriezts neizpaliktajā sarakstā un tiek atlasīts jauns uzdevums ar visaugstāko prioritāti. Atkarībā no uzdevumu rakstura un komandas veida limitu var palielināt vai samazināt. Piemēram, mūsu izstrādātājs var vienlaikus uzzīmēt reģistrācijas veidlapu un vērot jauna servera izvietošanas procesu. Tomēr, ja uzdevuma izpildes laiks ir mazāks nekā nepieciešams, projekta vadītājs var samazināt limitu vai palielināt komandu. Tādējādi ar pareizu pārvaldību Kanban nodrošina augstāko iespējamo darba ātrumu konkrētai komandai, maksimālo reaģēšanas ātrumu uz izmaiņām un vienlaikus samazina metodikas atbalsta “izmaksas”. Nu, tas arī viss! Kanban nav viegli, vienkārši. Tas ir ļoti vienkārši!

Kanban ierobežojumi, lietojot produktu grupās, ir šādi:

• šī metodika nedarbojas labi ar lielām komandām (vairāk nekā 5 cilvēki);
• Tīrā veidā Kanban nedarbojas labi ar daudzfunkcionālām komandām. Tie. Atšķirībā no Scrum ir grūti apvienot testēšanu un attīstību vienā komandā. Labāka ideja ir sadalīt procesu izstrādes “stacijā” un testēšanas “stacijā” ar atsevišķiem vadītājiem un nepabeigtajiem krājumiem;
• Savas vēstures un specifikas dēļ Kanban nav paredzēts ilgtermiņa plānošanai.

Secinājums

Nobeigumā vēlos piebilst, ka jebkādu metodiku salīdzināšana pēc principa “kurš ir foršāks” nav produktīva un neproduktīva (Captain Obvious). Katrai vairāk vai mazāk izplatītai metodikai ir savi plusi, mīnusi un pielietojuma robežas. Turklāt Agile metodoloģijas pēc būtības izvirza lielākas prasības komandas locekļu komandas darbam un pieredzei.

Ja ir interese par tēmu, turpināšu izskatīt Kanban sīkāk, pēc tam ierosinu sašķirot Scrum un RUP gabalos un bildēs.

Sīkāk un skaidrāk var apskatīties.

Kanban - kas tas ir? Cik daudz interesantas informācijas satur Kanban karte, un kādai funkcijai metode kalpo ražošanā? Rakstā mēs sīki izskaidrosim noteikumus efektīvai kanban izmantošanai, kā arī sniegsim skaidru atbilstošo karšu lietošanas shēmas aprakstu, izmantojot konkrētu piemēru. Turklāt, iepazīstoties ar materiālu, jūs uzzināsiet, kāpēc ir nepieciešams Kanban dēlis, kurās jomās papildus ražošanai ir ieteicams izmantot šo metodi un kas var kalpot kā laba alternatīva tai.

Koncepcijas būtība un metodes galvenās iezīmes

Šobrīd ir vērojama skaidra tendence pieaugt krājumu uzglabāšanas izmaksām, kas ir galvenais iemesls “instant” krājumu vadības kompleksu veidošanai, kas ietver kanban sistēmu. Tulkojumā no japāņu valodas "kanban" nozīmē "birka", "žetons". Šis termins kalpo kā informācijas metode, ar kuras palīdzību tiek dota atļauja vai norāde produkta ražošanai vai izslēgšanai (pārvietošanai) vilkšanas sistēmā.

Piedāvātā informācijas nosūtīšanas iespēja ļauj pilnībā pārvaldīt vienkāršas ražošanas līnijas, izmantojot informācijas kartes, lai pārsūtītu konkrētu ražošanas pasūtījumu no nākamā posma uz iepriekšējo.

Šādas produktīvas sistēmas izstrādātājs ir Toyota Motors, kas prezentēto ideju skaidro kā vienu no pirmajiem mēģinājumiem praktiski ieviest just-in-time metodi. Saskaņā ar kanban sistēmu ražošana tiek veikta saskaņā ar šādu noteikumu: uzņēmuma struktūrvienībām tiek piegādāti resursi noteiktā daudzumā un skaidri noteiktā termiņā, kas nepieciešams pasūtījuma izpildei.

Procesa detaļas

Piedāvātās metodes shēma ir ārkārtīgi vienkārša, tomēr tai ir ļoti efektīva ietekme uz ražošanas procesa organizāciju. Pēc uzņēmuma struktūrvienību piegādes resursu ziņā tiek veikts detalizēts nepieciešamā nepabeigtā darba apjoma aprēķins, kam vajadzētu nākt tieši no priekšpēdējā posma (attiecīgi gatavā produkta pasūtījums ir pēdējais process). Tāpat no priekšpēdējā posma uz iepriekšējo posmu tiek iesniegts pieprasījums par konkrētu pusfabrikātu apjomu.

Tādējādi ražošanas apjoms noteiktā vietā veidojas atbilstoši nākamā ražošanas posma vajadzībām. Loģiski, ka starp katriem diviem ražošanas procesa posmiem, kas atrodas tuvumā, tiek izveidots divkāršs savienojuma veids:

1. No n-tā posma līdz n-1 tiek pieprasīts nepieciešamais nepabeigtā darba apjoms (“vilkts”).
2. No n-1.posma uz n-to posmu tiek nosūtīti materiālie resursi nepieciešamajā apjomā.

Informācijas pārsūtīšanas rīki

Lai labāk izprastu kanban - kas tas ir, jums vajadzētu saprast, ka informācijas pārsūtīšanas rīks šajā sistēmā ir īpašas kartes, kuras iedala divās grupās:

1. Rīki, kas tieši saistīti ar ražošanas pasūtījumu. Šāda veida kartēs vispirms ir norādīts detaļu skaits, kas jāizgatavo iepriekšējā ražošanas procesa posmā. Tie tiek nosūtīti no n-tā ražošanas posma uz n-1 posmu un kalpo par galveno iemeslu ražošanas programmas izstrādei šīm vietām.
2. Atlases instrumenti satur informāciju par nepieciešamo materiālo resursu apjomu (tas var ietvert pusfabrikātus, materiālus, detaļas utt.), kas jāņem iepriekšējā montāžas posmā. Šāda veida kartītēs tiek parādīts resursa apjoms, kas faktiski saņemts ražošanas procesa n-tajā posmā no n-1.

Svarīgi atzīmēt, ka kartes var cirkulēt ne tikai saistībā ar uzņēmuma iekšējo infrastruktūru, bet arī starp tā filiālēm vai korporācijām, kas atbalsta sadarbību.

Efektīvas Kanban lietošanas metodes - kas tas ir?

Taiichi Ohno, Toyota Motor Corporation prezidents, ir izstrādājis vairākus principus kanban karšu lietošanai ar maksimālu efektivitāti:

• Turpmākā ražošanas darbības darbība noņem kartes norādīto detaļu apjomu no iepriekšējās darbības.
• Ražošanas operācija, kas atrodas priekšā, tiek veikta saskaņā ar detaļu izveidi tādā daudzumā un secībā, kas norādīts uz konkrētas kartes.
• Nav tādu daļu, kuras var izveidot bez kartes. Šis noteikums ļauj samazināt pārprodukciju, kā arī pārmērīgu produktu kustību. Tādējādi apgrozībā esošo karšu apjoms ir vienāds ar maksimālo krājumu apjomu.
• Karte ir pasūtījums preces izgatavošanai (prece jebkurā gadījumā ir pievienota atbilstošajai kartei).
• Detaļas, kurām ir kādi defekti, nevar nodot pakārtotajam procesam. Šis noteikums ļauj nodrošināt produktu ražošanu pēc iespējas bez defektiem.
• Karšu skaita samazināšana palielina to jutīguma līmeni. Tādējādi atklājas esošās problēmas un tiek veikta efektīva krājumu kontrole.

Karšu lietošanas iezīmes

Kā izrādījās, kanban pārvaldība tiek veikta pēc noteiktas shēmas, kas ietver īpašu karšu izmantošanu. Tādējādi to lietošanas laikā ir pilnībā jāīsteno prasības attiecīgās sistēmas absolūtas redzamības un maksimālas drošības nodrošināšanai: karšu nozaudēšana, kā arī to sajaukšanās tiek pilnībā novērsta.

Eksperti ir izstrādājuši efektīvu rīku, kas ļauj nodrošināt Kanban sistēmas maksimālu produktivitāti. Šīs metodes tāfele kalpo kā aktīvo karšu savākšanas punkts, jo darbinieki darba vietā bieži izmanto vairākus dažādus rīkus. Tādējādi kartes, kas nonāk ražotājam, tiek novietotas uz vadības paneļa. Un, kad tikko saņemtie karšu instrumenti nonāk “sākuma” laukā, viss atbilstošā daļas numura karšu komplekts tiek nodots tālākā ražošanas procesa veikšanai.

Kanban metodes izmantošanas priekšrocības - kas tas ir?

Uzņēmumi, kas to izmanto, katru dienu saņem materiālo resursu piegādi (un bieži vien vairākas reizes dienas laikā). Tas ļauj pilnībā atjaunināt ražošanas krājumus aptuveni 100-300 reizes gada laikā. Ja salīdzinām Kanban ar tādām sistēmām kā MRP vai MAP, tad šajā gadījumā atjauninājumi notiek aptuveni 10 reizes biežāk.

Kanban metodi ieteicams novērtēt ar piemēriem, kas atklāj tās absolūtās priekšrocības salīdzinājumā ar citām, mazāk produktīvām. Tādējādi Toyota Motors Corporation 1976. gadā piegādāja resursus vienai no daudzajām ražotnēm trīs reizes dienā, bet 1983. gadā - ik pēc desmit minūtēm.

Kanbans bieži tiek izmantots darbā ar lielveikaliem (šim nolūkam īpaši izveidots krājums). Tādējādi patērētājs nosūta lielveikalam atlases kanbanu, kurā norādīts, kā minēts iepriekš, preces apjoms, un lielveikals viņam nodod norādīto preču skaitu. Tajā pašā laikā lielveikals nosūta piegādātājam papildināšanas kanbanu, pēc kura piegādātājs nodod produktus lielveikalam.

Metodes pamatelementi

Kanban sistēmas svarīgākās sastāvdaļas ir šādas:

1. Informācijas komplekss, kas savā struktūrā satur ne tikai kartes, bet arī ražošanas, transportēšanas vai piegādes grafikus, kā arī tehnoloģiskās kartes.
2. Komplekss, kas ir tieši saistīts ar kontroli pār vajadzībām un profesionāli.
3. Komplekss, kas ļauj veikt pilnīgu (TQM) un selektīvu (Jidoka) produktu kvalitātes kontroli.
4. Komplekss, kas nodrošina absolūtu ražošanas izlīdzināšanu.

Prezentētie elementi, izmantojot kopā, ļauj sasniegt īsāko ražošanas ciklu, augstu aktīvu (ieskaitot krājumus) apgrozījumu, kā arī novērst vai minimizēt uzglabāšanas izmaksas gan ražošanai, gan, protams, sasniegt augstāko produkcijas kvalitāti. produktu katrā ražošanas procesa posmā.

Sistēmas trūkumi un tās izmantošanas rezultāti

Tāpat kā jebkurai attīstībai, tieši laikā sistēmai ir daži trūkumi. Pirmkārt, tās ir grūtības organizēt augsta līmeņa konsekvenci starp konkrēta produkta ražošanas posmiem.

Otrkārt, pastāv ievērojams ražošanas procesa un attiecīgi arī produkcijas pārdošanas traucējumu risks. Tomēr detalizēta pasaules prakses analīze saistībā ar attiecīgās metodes piemērošanu parādīja, ka piedāvātā sistēma ļauj samazināt ražošanas krājumus uz pusi un krājumus par 8%, ievērojami paātrinot apgrozāmā kapitāla apgrozījumu un , protams, gatavā produkta kvalitātes paaugstināšanās.

Ir svarīgi atzīmēt, ka kanbanu izmantošana nebeidzas ar ražošanas procesiem. Tādējādi sistēma tiek aktīvi izmantota biroja un projektu aktivitātēs, programmēšanā (ir vesels kanban izstrādes komplekss), kā arī personīgo rezultātu sasniegšanā (personīgais kanban tips).

Kanban sistēma sāka savu ceļu 1950. gados uz Toyota Corporation ražošanas līnijām, pēc tam tā migrēja uz birojiem un kļuva par svarīgu instrumentu projektu vadītājiem.

Prakses bezgalīgā elastība un tās iespējas personāla pašorganizācijai ļāva sasniegt efektivitāti tur, kur citas pieejas nedarbojās. Tas ir gadījums, kad pati karte kļuva par sistēmas vizītkarti - tā nostiprinājās kā iekšējā valūta organizācijās, kas ieviesa Kanban.

Izcelsme

Tāpat kā liesās ražošanas koncepciju, arī kanban sistēmu izstrādāja Toyota vadītāji. Sistēmas autors, japāņu inženieris Taiiči Ono, iedvesmojies no Amerikas lielveikalu darbības principa, kur pircējs pats izvēlējās sev vajadzīgās preces. “Lielveikala” lomu Toyota korporācijā pildīja noliktava.

Tur signāla kartes - un šādi “kanban” tiek burtiski tulkots no japāņu valodas - strādnieki apmainījās ar signālu kartēm, ar savām rokām regulējot ražošanas procesu.

Kartes tika piestiprinātas pie konteineriem ar detaļām. Šīs etiķetes saturēja informāciju par detaļu skaitu un daudzumu, kura nodaļa tās nosūtīja un kur tām jānonāk.

Strādnieks, kurš bija tieši iesaistīts mašīnu uzstādīšanā un montāžā – pa straumi – paņēma detaļas no konteinera, uz kuras bija piestiprināts “kanbans” ar pieprasījumu pēc noliktavas. Karti izņēma un kopā ar tukšo kasti transportieris pārcēla uz noliktavu. Tur cits darbinieks jau bija sagatavojis jaunu rezerves daļu konteineru, uz kura bija piestiprināts ražošanas “kanban” - birka ar informāciju par saražotajām rezerves daļām.

Ražošanas kanban tika aizstāts ar pieprasījuma kanbanu noliktavai un nosūtīts uz detaļu ražošanas līniju - augšpus. Tāpēc tika ražots tieši tik detaļu skaits, kāds bija norādīts kartē. Konteineri ar jaunām rezerves daļām tika nogādāti transportieriem uz montāžas līnijas.

Kanban principi

Toyota vadītāji formulēja 6 sistēmas veidošanas noteikumus:

1. Pakārtotie darbinieki no noliktavas izņem tieši tik daudz detaļu, kā norādīts kanbanā
2. Arī augšteces pārstāvji piegādā rezerves daļas stingri saskaņā ar kartēm
3. Bez Kanban nekas netiek ražots vai pārvietots.
4. Kanban vienmēr jāpievieno daļām
5. Sistēmā netiek izmantotas bojātas detaļas
6. Kanban karšu skaita samazināšana padara vadību labāk reaģējošu uz izmaiņām. Bet, ja vien tas nav absolūti nepieciešams, jums nevajadzētu mainīt noteikto karšu skaitu.

Kanban ir “vilkšanas” sistēma. Tas rada līdzsvaru starp pastāvīgu plūsmu, kas novērš gaidīšanas izmaksas, un minimālo darbu procesā (WIP), kas samazina pārprodukcijas risku. RVP tiek regulēts, izmantojot kartes: to skaits ir fiksēts, un instrukcijas tajās vada pakārtotos izpildītājus.

Obligātās atzīmes noteikums darbojas kā enerģijas nezūdamības likums.

RVP limits tiek sastādīts proporcionāli kanban karšu skaitam, kas tiek aprēķināts atkarībā no pārdošanas līmeņa un aktuālo procesu statistiskās variācijas. Maksimālais tagu skaits — tā pati “enerģija” sistēmā — nosaka RVP augšējo līmeni jebkurā laikā. RVP ierobežo arī vilkšanas princips: augšējās plūsmas ražošanas ātrums ir atkarīgs no apakšējās plūsmas ātruma.

Grafikā redzams, ka viens no sistēmas pamatelementiem ir Kaizen kultūra. Autonoms process un standarta variācijas atbrīvo vadību no pastāvīgas vadības, lai viņi varētu koncentrēties uz darbinieku snieguma uzlabošanu.

Kanban pielietojums IT

Lai gan Kanban turpina nodrošināt vērtību ražošanas līnijās, tas ir iekļuvis programmatūras pasaulē.

Tikai kartītes, kurās ir informācija par termiņiem, apraksts vai procesa numurs un izpildītāja vārds, tagad tiek pievienotas nevis konteineram ar rezerves daļām, bet gan dēlī ar oderētām kolonnām:

• Neizpildītie darbi - uzdevumi, kas jāpabeidz
• Uzdevumi, kas šobrīd tiek izstrādāti
• Uzdevumi, kas ir pabeigti, bet vēl nav nodoti testētājiem
• Uzdevumi ir gatavi pārsūtīšanai uz testēšanas nodaļu
• Uzdevumi, kurus izskata projekta vadītājs (PM)
• Izpildītie uzdevumi

Virs kolonnām parasti tiek rakstīts skaitlis - limits, norādot maksimālo procesu skaitu tajā. Neizpildītās summas limits tiek aprēķināts atkarībā no izpildes laika. Ja sistēmā ir 5 nepabeigti darbi un katra no tām pabeigšana aizņem vidēji 1 dienu, tad nepabeigto darbu skaitu var ierobežot līdz 5.

Iepriekš minētā struktūra nav stingra - Atkarībā no projekta specifikas var pievienot improvizētus skaļruņus. Bieži vien pastāv kanban sistēma, kurā ir jānosaka uzdevuma gatavības kritēriji pirms tā izpildes. Tad parādās divas kolonnas, kuras angliski sauc norādīt(norādīt parametrus) un izpildīt(sāk strādāt).

• Vairāk var pievienot kolonnu ar prioritāro rindu.Kad izpildītājs ir brīvs, viņam ir jāiztukšo šī konkrētā uzdevumu kolonna un pēc tam jāuzņemas citi.
• Uzdevumi, kas netika izpildīti, tiek vai nu atgriezti uz atlikumu, vai izsvītroti no shēmas.

• Kanban neveicina vairākuzdevumu veikšanu, tāpēc vienam izpildītājam ir noteikts procesa limits.

• Vēlams pabeigts darbs, nevis vairāki iesākti.

• Varat uzņemties otru darbu, ja pirmais tika bloķēts.
• Uzdevuma izpildes laikam jābūt līdzsvarotam.Pārāk īss periods ietekmēs kvalitāti. Pārmērīgs limits tērē komandas resursus un palielina procesa izmaksas.

Kāpēc visur tiek izmantota Kanban tāfele, nevis, piemēram, planšetdatori vai milzīgs monitors? Tā kā sistēmas fani atbild uz šo jautājumu, parastajam dēlim ir divas priekšrocības: tā ir vienkārša un nodrošina vizuālu kontroli. Tas ir viegli veikt izmaiņas un nodrošina taustes un sociālo mijiedarbību starp komandas locekļiem.

Kanban priekšrocības un trūkumi

Kanban ir šādas priekšrocības:

1. Plānošanas elastība. Komanda koncentrējas tikai uz kārtējo darbu, uzdevuma prioritāti nosaka vadītājs.
2. Augsta komandas iesaiste izstrādes procesā. Ar regulārām sanāksmēm, caurskatāmiem procesiem un pašorganizēšanās iespējām darbinieki saliedējas un izrāda patiesu interesi.
3. Īsāks cikla ilgums. Ja vairākiem cilvēkiem ir līdzīgas prasmes, ilgums tiek samazināts, bet, ja ir tikai viens, parādās pudeles kakls. Tāpēc darbiniekiem ir jādalās zināšanās un tādējādi jāoptimizē cikla laiki. Tad visa komanda var uzņemties iestrēgušos darbus un atjaunot vienmērīgu plūsmu.
4. Mazāk vājo vietu. RVP limiti ļauj ātri atrast vājās vietas un problēmzonas, kas radušās uzmanības, cilvēku vai prasmju trūkuma dēļ.
5. Redzamība. Kad visiem darbiniekiem ir piekļuve datiem, vājās vietas ir vieglāk pamanīt. Kanban komandas papildus pašām kartēm parasti izmanto divus vispārīgus pārskatus: kontroles un kumulatīvās plūsmas diagrammas.

Praksē sistēma labi darbojas nesaistītās ražošanas jomās:

• programmatūras atbalsts vai palīdzības dienesta komandas.
• Kanban darbojas labi, pārvaldot jaunuzņēmumus bez skaidra plāna, bet kur attīstība aktīvi virzās uz priekšu.

Kanbanam ir arī trūkumi:

1. sistēma nedarbojas labi ar komandām, kurās ir vairāk par 5 cilvēkiem
2. tas nav paredzēts ilgtermiņa plānošanai.

Atšķirības no Scrum

Scrum, tāpat kā veikls kanban, ir elastīga metodoloģija, un to bieži izmanto arī IT jomā. Atšķirības starp tām no pirmā acu uzmetiena nav acīmredzamas. Ir daudz līdzību, piemēram, atpalicības esamība abās pieejās.

	Scrum	Kanban
Temps	Atkārtoti fiksēta ilguma sprinti	Nepārtraukts process
Izlaidiet	Katra sprinta beigās pēc projekta vadītāja (produkta īpašnieka) apstiprināšanas	Plūsma turpinās bez pārtraukuma vai pēc komandas ieskatiem
Lomas	Produkta īpašnieks, Scrum meistars, izstrādes komanda	Komanda, kuru vada PM, dažos gadījumos ir iesaistīti veikli kanban treneri
Galvenie rādītāji	Komandas ātrums	Vadošais laiks
Izmaiņu pieņemamība	Izmaiņas sprinta laikā nav vēlamas, jo tās var novest pie nepareizām uzdevumu aplēsēm	Izmaiņas var notikt jebkurā laikā

Lietojumprogrammu piemēri IT jomā

Tieši no Microsoft: Kanban debitē programmatūras izstrādē

Kanban principu izmantošana informācijas tehnoloģiju nozarē sākās nedaudz vairāk kā pirms 10 gadiem. Deivids Andersons, viens no galvenajiem Kanban popularizētājiem programmatūras izstrādātājiem, konsultējās ar Microsoft 2005. gadā. Viņi bija neapmierināti ar savas nodaļas – XIT Sustained Engineering – darbu, kas novērsa kļūdas iekšējās lietojumprogrammās. Pārskata gada sākumā šī nodaļa bija sliktākā savā departamentā. Neizpildīto līdzekļu apjoms pārsniedza pieļaujamo apjomu 5 reizes, un viena pieprasījuma apstrādes laiks bija vadošais laiks- parasti bija 5 mēneši.

Jaunais PM ar Andersona konsultāciju palīdzību 9 mēnešu laikā paaugstināja problēmnodaļas produktivitāti par 155%. Vadošais laiks tagad bija 5 nedēļas, nepabeigtais apjoms atgriezās normālā apjomā, un tika noteikts, ka uzdevumu izpilde laikā bija 90%. Visi šie rezultāti tika sasniegti, minimāli iesaistot jaunus darbiniekus, darbinieki turpināja labot programmatūras kļūdas, izmantojot tās pašas metodes - Mainījušās tikai pieejas darba organizēšanai.

Interesants fakts: programmas vadītājs Dragoss Dumitriu, kurš uzņēmās XIT pavērsienu, bija aizrāvies ar Andersona grāmatu. Viņam par pārsteigumu viņš iepazinās ar programmatūras ideologu Kanbanu pašā Microsoft, kur viņš dienu iepriekš bija ieguvis darbu. Dumitriu lūdza Andersonu palīdzēt viņa uzdevumā, un pēdējais piekrita savas grāmatas principus īstenot praksē.

Dumitriu atrada nodaļu, kurā bija trīs izstrādātāji un trīs testētāji, kuriem bija 80 pieprasījumi. Pats PM tika iecelts uz laiku, jo amata prasībās bija prasme strādāt ar ASP tehnoloģiju, administrēšana, izmantojot SQL Server un zināšanas par MS Project Server. Priekšnieki šo amatu uztvēra kā “tehniķi”, kurš prot programmēt, jāsastāda atskaites un jāparedz atpalicības noslodze. Tad tika uzskatīts, ka departamenta problēma tiks identificēta, ja tiks savākts iespaidīgs datu klāsts. Dumitriu nebija tik "tehniķis".

Tomēr, kad viņš un Andersons sāka analizēt XIT darbību, viņš ātri identificēja galvenos faktorus, kas negatīvi ietekmēja departamenta ātrumu:

• Bija pārāk daudz laika, lai prognozētu pieprasījuma izpildes sekas (ROM). Gan izstrādātājam, gan testētājam bija jāpavada pilna diena, lai veiktu nepieciešamos aprēķinus, kodu pārskatīšanu un pabeigtu dokumentāciju. Vidēji dienā tika saņemts viens pieprasījums. Saskaņā ar PM aplēsēm 40% no departamenta produktivitātes tika iztērēti ROM;
• Prioritāte tika piešķirta pieprasījumiem ar augstāku vērtību. XIT saņēma finansējumu no pasūtījuma izmaksām. Pieprasījumu prioritāte tika pārrunāta katru mēnesi nodaļu vadītāju sanāksmē ar klientiem - citu nodaļu vadītājiem. Tā kā pašreizējā ātrumā, kad mēnesī tika apstrādāti tikai 6-7 pieprasījumi, tika izveidots liels nepabeigts uzkrājums, laika gaitā nemitīgi mainījās citu pieprasījumu prioritātes. Daudzi no tiem tika pārcelti uz iespaidīgu “vēlāk”, pat ne līdzvērtīgu nākamajam mēnesim.
• ROM posmā puse pieprasījumu tika novērsti. Daži no tiem bija pārāk lieli un tika pārkvalificēti par projektiem, lai tos nodotu citām nodaļām, citi bija pārāk dārgi un vienkārši tika atcelti. Daži pieprasījumi netika ņemti vērā izstrādē, jo to īstenošana būtu bijusi pārāk ilga. Tādējādi 40% no departamenta produktivitātes tika tērēti pieprasījumu analīzei, no kuriem 50% tika noraidīti. Apmēram 15-20% darbaspēka resursu tika izšķiesti.
• Pieprasījuma sagatavošanas darbs varētu ilgt vairākus mēnešus pirms īstenošanas sākuma. Aprēķini ROM posmā šajā laikā var pazust vai aizmirst. It īpaši, ja ieviešanu nav veicis tas pats izstrādātājs, kurš sāka analīzi.

Kanban risinājumi nemierīgai Microsoft nodaļai

1. Dumitriu un Andersons sarunās ar vadību un klientu menedžeriem uzstāja, ka jāatsakās no ROM posma. Aprēķini tika veikti tieši pirms ieviešanas un to veica viens un tas pats izpildītājs, tas ir, tie palika “svaigi”.
2. Pieprasījumu prioritāšu noteikšana tika veikta nevis ikmēneša sanāksmēs, bet gan atbilstoši situācijai, izmantojot telefona zvanus vai e-pastus. 80 neatliekamie uzdevumi tika sakārtoti atkarībā no klientiem. Pēdējiem tika lūgts izcelt galvenos vaicājumus, kas vispirms jāaizpilda.
3. XIT finansējums ir kļuvis fiksēts.
4. Pieprasījumu izmaksas vairs netiek ņemtas vērā.
5. PM ievadīja buferus Kanban panelī. Izstrādātāji veica darbu no divām zonām: apstiprinātajiem un izpildītajiem uzdevumiem. Buferī bija 6 pieprasījumi, 5 tika paņemti uz darbu. Testētāji atlasīti no bufera “Gaida testēšanu”. Daži uzdevumi, kuriem nebija nepieciešamas izmaiņas kodā, nonāca tur, apejot izstrādātājus. Sadalot pieprasījumus viena uzdevuma procesos, PM varētu vairāk kontrolēt situāciju, kā arī nodrošināt klientiem caurspīdīgumu. Buferu ieviešana samazināja vadīšanas laiku. Klienti, izmantojot paredzamu sistēmu, var labāk noteikt, kura pieprasījums ir jābuferē nākamajam.
6. Ja pieprasījumi bija pārāk lieli vai dārgi, lēmums tika pieņemts nekavējoties. Ja izstrādātājs apstiprināja, ka ir gatavs paveikt uzdevumu 15 dienu laikā vai izmaiņas bija tā vērtas, pieprasījums tika pieņemts neatkarīgi no izmēra vai izmaksām.
7. Novērojot plūsmu departamentā, PM nonāca pie secinājuma, ka jāmaina štatu struktūra par labu ar darbu vairāk noslogotiem attīstītājiem. Izmaiņas tika veiktas attiecībā 2:1: XIT sāka strādāt 4 izstrādātāji un 2 testētāji.

2005. gada beigās departamenta produktivitāte pieauga par 155%. Lai vēl vairāk uzlabotu XIT darbu, tajā tika pieņemti divi darbinieki: viens izstrādātājs un viens testētājs. Neizpildīto pieprasījumu skaits samazinājās līdz 10, un viens izstrādātājs sāka konsekventi apstrādāt 11 pieprasījumus ceturksnī. Vidēji ceturksnī tika izpildīti 56 pieprasījumi salīdzinājumā ar 11 pieprasījumiem iepriekš. Pieprasījumu izmaksas samazinājās no 7500 USD līdz 2900 USD.

Pieteikšanās Corbis

Sasniedzis panākumus Microsoft, Andersons 2006. gadā sāka risināt jaunu izaicinājumu. Tagad viņš strādāja Corbis, citā Bila Geitsa uzņēmumā, kurš vēl nebija pametis MS. Viena no Korbisa aktivitātēm bija fotogrāfiju licencēšana. Tobrīd tas bija otrs lielākais foto krājums pasaulē ar aptuveni 3,5 tūkstošu attēlu datubāzi.

Andersona uzdevums bija paātrināt uzņēmuma galvenos izlaidumus. Intervāls starp viņu iziešanu bija trīs mēneši, un tas varēja pieaugt vēl ilgāk. Tikai atbrīvošanas plāna apspriešana vadībai aizņēma divas nedēļas. Bija nepieciešams organizēt nelielu izlaidumu vai atjauninājumu izlaišanu ik pēc divām nedēļām. Tajā pašā laikā galvenie resursi bija jānovirza darbam pie galvenā projekta.

Korbis birojā parādījās Kanban dēlis, kur Andersons katru dienu sazinājās ar komandu. PM mērķis bija uzlabot procesu vizuālo kontroli, veicināt pašorganizēšanos un lielāku izpildītāju personīgo atbildību. Kanban sistēmas mērķis bija arī samazināt vadības pārraudzību un palielināt produktivitāti.

Papildus daudzkrāsainām kartēm un grafikiem uz tāfeles parādījās “miskaste”, kurā tika nosūtīti pārāk lieli uzdevumi.

Foto no amatpersonas

Kanban sistēma programmatūras sistēmu inženierijas uzturēšanai, Deivids J. Andersons

Kanban sistēma skaidri parādīja, kur plūsma pārstāj būt vienmērīga un kur notiek kavēšanās, tā sauktais sašaurinājums. Ātras pārrunas ar komandu palīdzēja identificēt pašreizējās problēmas. Piemēram, testēšana ilga 3 dienas, kas negatīvi ietekmēja izlaišanas datumu. Trīs darbinieki apvienojās un atrada veidu, kā samazināt laiku līdz vienai dienai.

Sašaurinājums ir uzņēmuma darbības shēmas vai algoritma sadaļa, kurā resursu ierobežojumi vai cilvēku produktivitāte krasi samazina uzdevumu plūsmu. Strādnieku trūkums, slikts internets vai direktors atvaļinājumā bloķē vai palēnina uzdevumu izpildi.

Kanban karšu limiti tika noteikti empīriski divas reizes. Ailē "gatavs attīstībai" limiti ir palielināti. Ir arī jauna kolonna - “gatavs testēšanai”. Daudzi pieprasījumi pakārtotajam posmam bija nepareizi formulēti, radot nevajadzīgu laika tērēšanu. Tāpēc PM pārbaudīja augšējās plūsmas darbību un konstatēja kļūdas.

Pieprasījumu apstrāde varētu ilgt 100 dienas, taču, kā plānots, laidieni joprojām sāka iznākt ik pēc divām nedēļām. Lēmums par izdevuma saturu pieņemts 5 dienas pirms publicēšanas. Skaitīšanas prakse, tāpat kā Microsoft XIT nodaļas gadījumā, tika atmesta par labu produktivitātei. Uzdevumi tika prioritizēti atbilstoši “kavējuma izmaksām” vai resursu pieejamībai.

Kanban sistēma ne tikai palīdzēja Andersonam sasniegt mērķi, bet arī uzlaboja noskaņojumu komandā. Pateicoties kopīgām diskusijām un procesu atpazīstamībai, darbiniekiem izveidojās uzticība vienam pret otru. Arī darbinieki pievienojās Kaizen, tas ir, nepārtrauktas uzlabošanas praksei.

Kas ir kanban metodoloģija un kā tā palīdz izpildīt uzdevumus laikā?

Pastāvīgas daudzuzdevumu veikšanas un liela klientu skaita apstākļos jebkura sistēma agrāk vai vēlāk kļūst pārslogota. Sāk nokavēties termiņi, cerības netiek piepildītas, un sistēma pārvēršas haosā. Šodien es ierosinu iepazīties ar tādu metodoloģiju kā kanban. Šī pieeja sola efektīvi sadalīt resursus un atrisināt visas mūsu problēmas. Pārbaudīsim.

Kanban vēstures mirklis

Kaban idejas pamatu izgudroja Toyoyta Motors. Kāds automašīnu ražotājs cieta lielus zaudējumus nepareizas krājumu un jaudas sadales dēļ ražošanas līnijā. Daži ražošanas posmi varēja darboties dīkstāvē, un daži bija pārslogoti.

1959. gadā tika piedāvāta ražošanas kontroles sistēma, kas ļāva līdzsvarot visus līnijas posmus. Pamatprincips bija tāds, ka katrā posmā strādnieki izlika kartes ar nepieciešamo daļu skaitu, kuras tika nodotas tālāk. Katrs strādnieks, kas sekoja pa ražošanas līniju, paņēma tieši tik daudz detaļu no iepriekšējā, cik viņam bija atvēlēts kartē.

Tādā veidā katrai daļai bija karte, un pārpalikums vienkārši nevarēja būt. Rezultātā krājumi apgabalos nepalielinājās, un katrs nākamais strādnieks saņēma tieši tik nepieciešamo detaļu skaitu.

Formulēsim, kas ir kanban, un pielietosim to interneta produktu izstrādē.

Kanban ir vienkārša ražošanas vadības sistēma (japāņu: "signāls"/"karte"), kas izmanto informācijas kartes, lai paziņotu par pasūtījumiem visos ražošanas posmos. Vienkāršiem vārdiem sakot, mēs izsekojam visu produkta ceļu no idejas līdz izlaišanai veikala plauktā.

Augšpusē ir kanban dēlis. Šis ir galvenais uzdevuma statusa parādīšanas rīks. Galvenais princips: mēs redzam, kurā ražošanas procesa posmā atrodas konkrētais uzdevums. Turklāt laiks tiek izsekots visās jomās, tas ir, jūs vienmēr varat atrast sistēmā “ ” un strādāt ar tiem.

Kolonnu skaitu nosakāt pats, pamatojoties uz sava projekta īpašībām. Ir svarīgi, lai šie ir galvenie posmi, kuriem jūsu produkts iziet cauri. Iepriekš minētais piemērs ir plus vai mīnus galvenās tiešsaistes produkta stadijas.

Metodoloģijas pielietojums ir ļoti plašs. Kanban tiek izmantots projektu īstenošanai, pārdošanas vadībai, ražošanas līnijām, IT attīstībai un pat savas dzīves organizēšanai.

Atvainojiet, ka pārtraucu lasīšanu. Pievienojieties manam telegrammas kanālam. Svaigi paziņojumi par rakstiem, digitālo produktu izstrāde un izaugsmes hack, tas viss ir tur. Gaidot tevi! Turpināsim...

Kanban principi

• Uzdevumu vizuālais attēlojums. Visi uzdevumi ir jāuzrāda kartīšu veidā un jāatspoguļo uz tāfeles. Ir ļoti svarīgi atjaunināt uzdevumu statusu. Piemēram, ja izstrādātāji sagatavoja kodu un iesniedza to pārbaudei, tad uzdevuma kartei jāiet uz attiecīgo kolonnu. Tādējādi jebkurš komandas dalībnieks jebkurā laikā var redzēt, kurā stadijā atrodas uzdevums.
• Ierobežojums WIP (nepietiekams darbs vai darbs, kas tiek veikts vienlaicīgi) kolonnām katrā ražošanas posmā. Lai sistēma agrāk vai vēlāk “neaizrīsies” no uzdevumu plūsmas, ir nepieciešams noteikt ierobežojumus. Piemēram, uz kanban paneļa, kas atrodas augstāk kolonnā Analīze (analītika), strādā 2 cilvēki, un viņi var tikt galā ar ne vairāk kā 2 uzdevumiem, nav jēgas tos ielādēt vairāk, jo turpmākie sistēmas posmi būs dīkstāvē. Kolonnu ierobežojumi tiek atlasīti empīriski.
• Koncentrējieties uz neizpildītiem uzdevumiem. Apskatot tablo ar uzdevumiem, vispirms pievērsiet uzmanību tiem uzdevumiem, kas “karājas” vienā vai otrā kolonnā. Ja kāds no posmiem jums aizņem visvairāk laika, mēģiniet pārdalīt resursus vai pievienot cilvēkus, ja iespējams.
• Pastāvīgu uzlabošanu. Kad esat sabalansējis slodzi sistēmā, jums būs vieglāk pārraudzīt visu procesu. Izmēriet cikla laiku (cik ilgi uzdevums atrodas atsevišķā kolonnā un cik ilgi no brīža, kad tas nonāk sadaļā To do, līdz tiek izlaists Gatavs). Mainiet sistēmas slodzes un samaziniet laiku, kas nepieciešams visu posmu pabeigšanai.
• Pievērsiet uzmanību detaļām. Piemēram, ja izstrādātāju periodiski rakstītais kods neiztur testēšanu un tiek atgriezts pārskatīšanai, tad varbūt ir iespējas uzlabot izstrādes kvalitāti, lai tiktu pārbaudīts kvalitatīvāks produkts?

Kanban pieeja var šķist ideālistiska, taču es jums apliecinu, ka tās principi dod rezultātus. Pirmkārt, jums ir jāpielāgo metodika jūsu situācijai un pēc tam jānoslīpē sistēma.

Kanban instrumenti

Vai arī kur uzturēt kanban dēli.

• Excel tabulas
• Dēlis ar uzlīmēm
• Vēl viena fantāzija...

Patiesībā ir daudz iespēju, varat pameklēt googlē un smelties iedvesmu. Galvenais, lai tev ir šī tāfele un visi procesa dalībnieki var redzēt, kas šobrīd notiek ar uzdevumiem.

Kanban dēļu piemēri

Šeit ir tāfele, kas karājas pie sienas, kur katrs uzdevums ir atspoguļots uz līmlapiņām.

Vai arī tas varētu būt mākoņpakalpojums, piemēram, Trello.

Ir vairāki viedokļi par to, kādus rīkus un iespējas izmantot savā darbā, taču tas lielākoties ir gaumes jautājums. Vienkārši izmēģiniet dažādus risinājumus un izvēlieties sev tīkamāko. Mērķis ir sākt lietot kanban, nevis iestrēgt, izmantojot pēc iespējas skaistāko tāfeli.

Mans viedoklis ir šāds: prāta vētrai vai darbam ar lietām bezsaistē, parastais dēlis ar uzlīmēm darbojas labi. Bet ikdienas darbam, protams, ir jāizmanto mākoņa risinājums, piemēram, Jira, Kanbantool, Trello utt. Tajos visa komanda var pievienot komentārus uzdevumiem, pārvietot tos pa kolonnām un daudz ko citu.

Nianses/domas

Ja runājam par interneta produktiem, tad kanban strādā, palīdz un uzlabo, taču ir vairākas bažas vai nianses, kas jāņem vērā.

• Visticamāk, WIP ierobežojumu ieviešana kolonnā var nedaudz nobiedēt projekta vadības komandu. Galu galā, kā noteikt, cik uzdevumu izstrādātājs vai, piemēram, testētājs var atrisināt paralēli? Ko darīt, ja mēs ieviestu ierobežojumus un viņi vienkārši atslābinās?

Redziet, ja cilvēks nav pilnībā noslogots, tas nav slikti. Viņš var izpētīt un analizēt paveikto, atrast trūkumus un tos labot un pat atpūsties. Turklāt jūs varat palīdzēt saviem biedriem no citām procesa daļām (kolonnām), sīkāka informācija zemāk.

• Pēc kanaban guru domām, sistēma ideāli darbojas daudzfunkcionālās komandās. Nu kaut kas tāds, ja nav ko darīt, ej palīgā kādam darba biedram. Tiesa, lai sapulcinātu komandu, kurā izstrādātāji varētu būt testētāji un otrādi, bet sistēmas arhitekts palīdzēs projektētājam, vajadzēs izlocīt lielu naudu, un vai tas ir tā vērts?

Protams, ir lieliski, ja komandas dalībnieki mācās viens no otra un var kaut kādā veidā palīdzēt, ja kaut kas notiek. Bet, lai šis nosacījums tiktu izpildīts, ir jābūt mazām komandām, kuras vēlams sēdēt kaut kur tuvumā un pastāvīgi sazināties. Lielos projektos šādu pieredzes apmaiņu ir grūti reproducēt.

Tāpēc vairāk sliecos pilnveidot savu prasmi, ja ir kāds kluss brīdis. Paskatieties uz paveikto, padomājiet, kā to varētu uzlabot, lasiet noderīgus rakstus. Cilvēks ir dzīvs organisms, nevis konveijera zobrats.

Kopā

Mēs esam apskatījuši kanban metodoloģiju, un tagad, es ceru, jūs saprotat, kā to izmantot savā projektā. Mēģiniet sadalīt savus procesus galvenajos posmos un optimizēt sistēmu, pamatojoties uz iegūtajām zināšanām.