Канбан жүйесі 1950-жылдары Toyota корпорациясының өндірістік желілерінде пайда болды.
Кейінірек, ол офиске көшіп, жобаларды басқарушылардың маңызды құралына айналды.
Практикада Канбанның шексіз икемділігі мен командаларды өзін-өзі басқару мүмкіндіктері
басқа тәсілдер сәтсіз болған жерде тиімділікті қамтамасыз етті. Міне, осы жағдайда, жүйенің идентификациясы
карты негізінен Канбанды қабылдаған мекемелерде ішкі валютаға айналған карта ретінде орнықты.
Түпнұсқа
Lean өндіріс концепциясымен ұқсас, Канбан жүйесі Toyota
басшылары тарапынан жасалды. Тайитчи Охно, жапон өнеркәсіп инженері және жүйенің авторы, американдық супермаркеттердің жұмыс принципінен шабыт алды, мұнда сатып алушы өзі қажетті тауарларды таңдайтын. Toyota корпорациясында қойма осындай “супермаркет” рөлін атқарды.
Сол жерде жұмысшылар сигналдық карталарды (канбанның жапон тіліндегі сөздік-құрастырып аудармасы) айырбастап, өндіріс процесін өздігінен бақылап отырды.
Карталар бөлшектермен контейнерлерге ілінді. Мұндай белгілер келесі мәліметтерді көрсетті: бөлшектердің
санын және мөлшерін, оларды жіберетін бөлім мен олардың тағайындалуын. Автомобильдерді жөндеу және жинау процесімен тікелей айналысқан жұмысшы
(ағымдағы) контейнерлерден “Канбан” ілінген бөлшектерді алды, бұл қоймадан өтінімнің бар екенін көрсетті. Карта жойылып, бос қораппен бірге, транспорт жұмысшысы арқылы қоймаға жеткізілді, мұнда басқа жұмысшы “өндіріс канбаны” белгісі бар бөлшектермен контейнер дайындаған болатын.
Мұндай өндіріс канбаны, қоймаға жоғарыға жіберу үшін өтінім канбанына алмастырылды. Осылайша, карточкада көрсетілген бөлшектердің саны ғана өндірілді.
Жаңа бөлшектер контейнерлері транспорт жұмысшыларына жөнелтілді.
Процесс
Канбан негіздері
Toyota басшылары 6 негізделген ережені баян етті:
- Ағымдағы жұмысшылар қоймадан канбан картасында көрсетілген дәл бөлшектер санын алады
- Жоғарғы мамандар да карталармен қатаң тәртіппен бөлшектерді жібереді
- Канбансыз ештеңе өндірілмейді не қозғалысқа келтірілмейді
- Канбан әрдайым бөлшектермен байланыстырылуы керек
- Кемшіліктері бар бөлшектер жүйеде қолданылмайды
- Канбан карталарының санының төмендеуі өзгерістерге басқарудың сезімталдығын арттырады. Бірақ орнатылған карталардың санында өзгеріс енгізу тек қажет жағдайда ғана жүзеге асырылуы керек.
Канбан — “ширейтін” жүйе. Ол минималды жұмыс аяқталуына (WIP) және күтуші шығындарды жою үшін үздіксіз ағын арасында тепе-теңдік құрады, нәтижесінде артық өндіріс тәуекелін төмендетеді. WIP карталар арқылы реттеледі: олардың саны фиксирленген, ал нұсқаулары ағындық жұмысшыларға бағыт береді.
Қатаң белгілерді тіркеу ережесі энергияны сақтау заңы ретінде жұмыс істейді. WIP шегі
сатылым деңгейі мен ағымдағы процесстердегі статистикалық ауытқу негізінде есептелген канбан карталарының санына пропорционалды түрде белгіленеді. Ағымдағы уақыт кестесінде WIP шегін көрсететін максималды белгі мөлшері осы “жүйе энергиясын” орнататын максимум болып табылады. WIP сондай-ақ, ұзарту принципімен шектеледі: жоғары ағын жылдамдығы ағын жылдамдығына тәуелді.
График, көрініп тұрғандай, Каизен мәдениеті жүйенің негіздері болып табылады.
Процестердің өзін-өзі сақтауы мен стандартты ауытқулар үздіксіз бақылаудан басқарушыны босатып, жұмысшылардың өнімділігін жақсартуға мүмкіндік береді.
IT-дегі Канбанды пайдалану
Канбан жүйесі бағдарламалық қамтамасыз ету саласына енді, өндіріс конвейерлерінде құндылық құрауды жалғастырады.
Дегенмен, мерзімдер, процесс сипаттамасы немесе орындаушының аты сияқты мәліметтерді көрсететін карталар енді бөлшектер бар контейнерлерге емес, келесі бағандарды көрсететін тақтаға қосылады:
Тізім — іске асырылатын тапсырмалар
- Қазіргі уақытта әзірленіп жатқан тапсырмалар;
- Жасалынған, бірақ әлі тестерлерге берілмеген тапсырмалар;
- Тестілеу бөліміне беруге дайын тапсырмалар;
- Жоба менеджері (PM) тарапынан тексерілуде тұрған тапсырмалар;
- Аяқталған тапсырмалар.
Әдетте, баған үстінде шектеу саны көрсетіледі процестердің максималды санын белгілеу үшін. Тізім шегі жетек уақытына негізделіп есептеледі. Егер 5 жұмыс жүріп жатса, оларды орташа есеппен 1 күнде аяқтауға болады, демек, тізім 5‑ке шектелуі мүмкін.
Жоғарыдағы құрылым қатал емес — сіз өзіндік қиялмен сипаттап, жобаның нақты ерекшеліктеріне байланысты бағандарды қосуға болады. Канбан жүйелері тапсырма орындау алдында тапсырманың дайындық критерийлерін анықтауды қажет етуі мүмкін. Мұндай жағдайда, батыс тіліндегі айқындалу (яғни, параметрлерді нақтылау) және орындау (яғни, жұмыс басталу) деп аталатын екі баған пайда болады.
- Приоритеттік кезек бағанын қосу да мүмкін. Орындаушы босатылған кезде, ол осы тапсырма бағанын тазалауы керек, содан кейін ғана басқа тапсырмаларды қолға ала алады.
- Орындалмаған тапсырмалар тізімге қайтарылады немесе графиктен жойылады.
- Канбан мультизадачаны ынталандырмайды, осылайша бір орындаушы үшін процесс шектейді.
- Бір аяқталған жұмыс бірнеше жұмыстардың басталуының алдында артықшылықты болып табылады.
- Екінші жұмыс алғашқысы блокталғанда ғана шешілуі мүмкін.
- Тапсырма орындалуына арналған уақыт аралығы теңгерілген болуы керек. Өте қысқа мерзімдер сапаға әсер етеді. Өте ұзақ шектеулер топтың ресурстарын артық шығарады және процесті қымбат етеді.
Канбанның артықшылықтары мен кемшіліктері
Канбанның келесі артықшылықтары бар:
- Икемді жоспарлау. Топ тек қазіргі жұмысқа ғана назар аударады, ал менеджер тапсырмаларды басым етеді.
- Топ даму процесіне белсенді қатысады. Регулярлы жиналыстар, процесс ашықтығы және өзін-өзі басқару мүмкіндіктері топтарды біріктіреді және шын мәнінде катысушы етеді.
- Цикл ұзақтығын қысқарту. Егер бірнеше адамның дағдылары ұқсас болса, ұзақтық кемиді, бірақ тек бір адам болса, тар орын пайда болады. Сондықтан, мамандар білімдерімен бөлісуі керек, осылайша цикл ұзақтығын оңтайландырады. Бұл бүкіл топқа төмендетілген жұмысты жою және ағынның тұрақтылығын қалпына келтіруді қамтамасыз етеді.
- Тар орындардың санын азайту. WIP шектері назар аудармау, адам ресурстары немесе дағдылардың жетіспеушілігінен туындайтын тар және проблемалық орындарды табуға мүмкіндік береді.
- Көріну. Барлық орындаушылар деректерге қол жеткізген кезде, тар орындарды байқап алу оңай болады. Карточкалардан бөлек, Канбан топтары әдетте екі жалпы түрдегі есептерді пайдаланады: басқару графиктері және жинақталған жұмыс ағын графиктері.
Практикада, жүйе келесі негізгі операцияларды орындауда тамаша өнімділік көрсетеді:
- Бағдарламалық қамтамасыз ету жәрдемдесу топтары немесе жәрдем қызметтері;
- Канбан айқын жоспарсыз, бірақ дамытуға белсендірілген стартаптарды басқаруда жақсы жұмыс істейді.
Канбанның кемшіліктері де бар:
- Жүйе 5‑тен көп жұмысшылар тобы үшін нашар жұмыс істейді.
- Ұзақ мерзімді жоспарлауға арналмаған.
Scrum-нан айырмашылығы
Agile Канбаны дәл солай, Scrum да икемді әдістеме, сонымен қатар IT саласында жиі қолданылады. Алғашқы көзге, олар арасындағы айырмашылық байқалмайды. Екі тәсіл де тізімді қамтамасыз етеді.
IT-де қолдану мысалдары
Microsoft-пен бірден: Канбан бағдарламалық қамтамасыз ету дамыту саласындағы дебюті
Канбан негіздері ақпараттық технологиялар саласында 10 жылдан аз уақыт бұрын қолданысқа енді. Дэвид Андерсон, бағдарламалық жасақтаманың әзірлеушілері үшін канбанның негізгі қорғаушысы, 2005 жылы Microsoft компаниясына кеңес берді. Компанияның XIT тұрақты инженерия бөлімшесі ішкі бағдарламалардағы ақауларды жоюмен айналысқан және наразылық тудырды. Есепті жылдың басына қарай, аталған бөлімшесі өз бөлімшесінде ең нашар болып қалды. Тізім рұқсат етілген көлемнен 5 есе асып түсті, ал сұранысты өңдеудің ұзақтығы – жетек уақыты – әдетте 5 айды құрады.
Андерсонның кеңесі жаңа PM-ге проблемалы бөлімшенің өнімділігін 9 айдың ішінде 155%-ға арттыруға көмектесті. жетек уақыты 5 аптаға дейін қысқарды, тізім қалыпты көлеміне қайтты, және тапсырмалардың уақытында орындалу деңгейі 90%-ға көтерілді. Бұл нәтижелер минималды жаңа мамандардың қатысуымен қол жеткізілді, ал персонал бағдарламалық ақауларды түзету жұмыстарын сол әдістермен жалғастыра берді – тек жұмысты ұйымдастыру тәсілдері өзгерді.
Қызықты жағдай: Драгос Думитриу, XIT-дегі жағдайды өзгертуге бел буды, Андерсонның кітабына сол уақытта тап болды. Оның таң қалдырғаны, Microsoft компаниясында бағдарламалық Канбанның идеологымен кездесуі болды, ол қысқаша алдында сол жерде жұмыс істеген. Думитриу Андерсоннан көмектесуін сұрады, және Андерсон өзінің кітабында сипатталған принциптерді практикада қолдануды келісім берді.
Думитриу үш әзірлеуші мен үш тестілеуші кіретін бөлімді тапты, олардың тізімі 80 сұранысты жинақтады. PM-нің тағайындалуы уақытша болды, себебі жұмыс талаптары ASP технологиясымен жұмыс істей білу, SQL Server-ді басқару және MS Project Server-дің білімін қамтуды талап етті. Жоғары басқару бұл қызметке “техникалық жұмысшыны” дайындауды көздеген, бағдарламалау қабілеті бар, есептер жасау мен тізім жүктемесін болжауға жауапкер. Бөлімшедегі проблема елеулі деректер массиві жинақталса, анықталады деп есептелді. Думитриу шын мәнінде “техникалық жұмысшы” емес еді.
Алайда, Анднерсонмен XIT операциясын талдауды бастағаннан кейін, ол бөлімшедегі қарқынға теріс әсер ететін негізгі факторларды тез арада анықтады:
- Сұранысты орындаудан туындайтын салдарды болжамдап алу (ROM) тым көп уақытты алады. Әзірлеушілер мен тестерлер қажетті есептеулерді, кодты тексеруді және құжаттарды аяқтауы үшін барлық жұмыс күнін өткізуі керек болды. Орташа есеппен бір күнде бір сұраныс алынды. PM-нің есептеулері бойынша, ROM бөлімшенің өнімділігінің 40%-ын талап етті;
- Жоғары құнды сұраныстарға басымдық берілді. XIT тапсырыс бюджеттары есебінен қаржы алды.
- Тапсырыс басымдылығы ай сайын бөлім менеджерлерінің клиенттермен, яғни басқа бөлімдермен кездесулерде талқыланды. Ағымдағы қарқынмен 6 – 7 сұраныс ай ішінде өңделгенде, басқа сұраныстардың басымдықтары үнемі өзгерісте болды. Көптегендері алдағы “кейінгіге” жылжыды, бұл келесі айды білдірмеген.
- Сұраныстардың жартысы ROM кезеңінде жойылды. Олардың кейбірі тым үлкен болды, сол себепті жобаларға қайта жіктелді, ал басқалары тым қымбат болып, жай ғана жойылды. Кейбір сұраныстарды дайындауға алмаған, өйткені олардың енгізілуі тым көп уақытты талап етті. Сондықтан, 40%-ы өнімділіктің талдауларына 50%-ы 거부 edilmiş сұраныстарды қажет етті. Шамамен 15 – 20% еңбек ресурстары босқа кетті.
- Сұраныстарды даярлау айларға созылуы мүмкін. ROM кезеңіндегі есептеулер бұл уақыттан кейін жоғалуы немесе ұмытылуы мүмкін. Бұл әсіресе, енгізу процесін басқа әзірлеуші — талдауды бастаған адамның емес, жүргізуі жағдайында болады.
Канбанның Microsoft-тың проблемалық бөлімшесі үшін шешімдері
- Жоғары менеджерлермен, сондай-ақ клиент менеджерлерімен диалог барысында, Думитриу мен Андерсон ROM кезеңінен бас тартуды талап етті. Есептеулер енгізу кезеңіне қабылданбай, сол орындаушы арқылы жүргізілді, яғни олар әрдайым “жаңа” күйінде қалды.
- Сұраныстар басымдылық беріліп ай сайын кездесулерде немесе жағдай талап еткенде телефон немесе электрондық пошта арқылы басқарылды. 80 тізім тапсырмалары клиенттерге байланысты сұрыпталды. Клиенттер қандай сұраныстар бірінші орындауы керектігін көрсетуге шақырылды.
- XIT қаржыландыруы фиксирленді.
- Сұраныс құны енді есепке алынбады.
- PM Канбан тақтасында резервтер енгізді. Әзірлеушілер жұмыстарды екі саладан — бекітілген тапсырмалар және орындалған тапсырмалар алды. Резерв 6 сұранысты қамтыды, 5‑і жұмыс ағынына қабылданды. Тест жүргізушілер “тестілеу уақытта” резервінен элементтерді таңдады. Код тегерісін талап етпейтін кейбір тапсырмалар әзірлеушілерді айналып өтіп, сонда орналастырылды. Сұраныстар бір тапсырмалық процестерге бөлінген кезде, PM жағдайды жақсырақ бақылап, клиенттер үшін ашықтығын қамтамасыз етті. Резерв енгізу жетек уақытының қысқаруына себеп болды. Мұндай болжаулы жүйе клиенттерге резервте сұраныстың келесі кезекте кім екенін жақсы айқындауға мүмкіндік берді.
- Шамадан тыс үлкен және қымбат сұраныстар бойынша шешімдер жедел қабылданды. Егер әзірлеуші тапсырманы орындауға 15 күн ішінде дайын екендігін растаған болса, немесе модификация жасау worth болса, сұраныс көлемі мен құнына қарамастан операцияға қабылданды.
- Бөлімшеде жұмыс ағынын бақылап отырып, PM команданың құрылымын анағұрлым көп жұмыс жасайтын әзірлеушілер пайдасына өзгерту қажеттілігі бар екенін шешті. Анықтама 2:1 арақатынасымен жүзеге асырылды: XIT 4 әзірлеуші мен 2 тестерден тұрды.
2005 жылдың қорытындысы бойынша, бөлімшенің өнімділігі 155%-ға өсті. XIT-тің өнімділігін жетілдіру үшін екі маман қатыстырылды: бір әзірлеуші және бір тестер. Тізім сұраныстары 10-ға дейін қысқарды, ал бір әзірлеуші тоқсан сайын 11 сұранысты тұрақты түрде өңдеді. Тоқсан сайын 56 сұраныс аяқталды, бұрынғы 11-мен салыстырғанда. Сұраныс құны $7500-дан $2900-ға дейін арзандады.
Corbis-тен қолданылған кездегі
Microsoft-те сәтті жұмыс істей отырып, Андерсон 2006 жылы жаңа күрделі мәселені шешуге көшті.
Сол уақытта ол Corbis — Билл Гейтстің MS-тен ондаған шығармаған екінші компаниясында жұмыс істеп жүрді. Corbis-тің біріктіруіне фотография лицензиялау арналды. Сол уақытта ол әлемде екінші үлкен фото қорды құрайтын, көлемі шамамен 3.5 мың суретті қамтыды.
Андерсонның мақсаты компанияның негізгі шығаруларын жылдамдату болды. Шығарулар арасындағы аралық үш ай, тіпті одан да ұзақ болуы мүмкін. Шығаруды талқылау тек 2 апта менеджер жұмысына шамамен уақыт жұмсалды. Екі апта сайын ықшам шығару немесе жаңартуларды тапсырмалау қажеттілігі болды. Сонымен, маңызды ресурстар негізгі жобаны іске асыруға бағытталу керек еді.
Corbis офисіне Канбан тақтасы берілді, ол Андерсонның персоналмен күнделікті сөйлесу алаңы болды. PM-ның мақсаты процесс визуалды мониторингін жақсарту, өзін-өзі басқаруды нығайту және орындаушылардың жеке жауапкершілігін арттыру болды.
Канбан жүйесі даму бақылауын жеңілдетіп, өнімділікті арттыруға бағытталған.
Көп түсті карталар мен графиктерден басқа, “қалдық орын” кеңістік пайда болды, ол артық тапсырмаларды жинау үшін арналды.
Ресми презентациядан фото
Дэвид Дж. Андерсонның бағдарламалық жүйелер бойынша тұрақты инженерия үшін Канбан жүйесі
Канбан жүйесі жұмыс ағындарының үйлесімді емес жерлерін ашып, тораптар пайда болған жерде анықтады. Шұғыл командалық талқылыстар қазіргі мәселелерді анықтауға ықпал етті. Мысалы, тексеру процедурасы 3 күнге созылды, бұл шығару мерзімдері үшін теріс әсер етті. Үш маман бұл уақытты 24 сағатқа дейін жоюды табуға біріккен.
Канбан карталарының шектері екі рет эмпирикалық түрде белгіленген. “Дайын дамыту” бағанында шектер артпайды. “Дайын тестілеу” деп аталатын жаңа баған да пайда болды. Көптеген ағынды сұраныстар дұрыс құрастырылмаған, бұл уақытты жұмсауға әкелді. Сондықтан PM жоғарғы ағын жұмыс ағымын зерттеп, онда қателер тауып алды. Сұраныстарды өңдеу 100 күнді алса да, шығаратын уақыттар жоспар бойынша, екі апта сайын болатын болды. Шығарылатын контент бойынша шешімдер жарияланудан 5 күн бұрын қабылданды. Microsoft-тың XIT бөлімшесінде, есептеулердің практикалары өнімділік пайдасына өзгертілді.
Тапсырмалар “кешіктіру құны” немесе ресурстардың дайындығына қарай басымдылықтарына сай анықталды. Канбан жүйесі Андерсонға мақсатқа жету үшін емес, сонымен бірге персонал климатын жақсартуға майыстырды. Бірлестік талқылаулары мен процестердің айқындығын себебінен топ мүшелері бір-біріне өзара сенімді болуға мүмкіндік алды. Персонал сонымен қатар Каизен принциптерін ұстана отырып, үздіксіз жақсартуға ынталанды.
Канбанның қолдану және бағдарламалар
Trello
Бұл тапсырмаларды басқарудың танымал Канбан жүйесі. Ол визуалдық тартымдылықпен және қолайлылық интерфейсімен ерекшеленеді. Пайдаланушылар оның супер икемділігін атап өтеді.
Kanbantool
Бұл екі пайдаланушы үшін ақысыз тақтаны ұсынады. Ол также API және сенсорлық интерфейстерді қолдау көрсетеді.
Lean Kit Kanban
Бұл бес пайдаланушыға ақысыз тақта, бірлескен жұмыстың жақсы іске асырылуын қамтамасыз етеді. Ол API қолдау көрсетеді, импорт/экспорт мүмкіндіктерін ұсынады және жақсы статистиканы қамтамасыз етеді.
Kanbanize
Бұл жеткілікті функционалдығы бар толық тегін сервис. Оның иелері қолдануды пайдалана отырып, өнімділікті 300% арттыруға кепілдік береді.
Worksection
Бұл жедел жобаларды бақылау және басқару үшін украиндық SaaS қосымшасы. Қаржылық есептерге, мерзімдерге және Гант диаграммаларына қоса, оның функциялары қазіргі уақытта реттелетін Канбан тақтасын қамтиды.
Қорытынды
Канбан — тек икемді әдістерді қолдану қажеттілігі жоқ жетістіктерге жетуге көмектесетін тәжірибе.
Ерекше өзгерістер еңбектің жоғалуы, тар орындарды басқару арқылы жүзеге асырылады, осылайша вариативтілікті төмендетеді.
Алайда тиімді өзгерістер уақытты талап етеді. Олар біртіндеп жүзеге асырылады, және топтың жаңалықтарға қарсы қарсылығы минималды. Канбан жүйесі топтарды инженерлік әдістерін өзгеріссіз жаңартуға ынталандырады.