Kanban'ı iş süreçlerinize uygulamayı planlıyor musunuz? İşte nereden başlayacağınız. Kanban sistemi: nedir, nereden başlamalı, nasıl uygulanmalı, temel ilkeler

Kanban yöntemi, temel terimleri ve uygulama alanları hakkında olabildiğince kısaca bilgi verelim.

Kanban yöntemini, temel terimlerini ve uygulanabilirlik alanlarını olabildiğince kısaca anlattık.

1. Kanban yöntemi nedir?

Kanban yöntemi çalışmanızı geliştirmeye yönelik bir yöntemdir. Ne yaparsanız yapın hipotez, Kanban yöntemini uygulamanın işinizi daha iyi yapmanızı sağlayacağı yönündedir. Kanban açısından bakıldığında bu, müşteri beklentilerini daha iyi karşılayacağınız anlamına gelir.

Kanban, BT yönetiminde bir araç olarak Microsoft (2005) ve Corbis'te David J. Anderson tarafından tanıtıldı. Ve yöntem 2007 yılında yaygınlaşarak adını aldı.

2. Kanban Yöntemi ile Toyota Kanban aynı şey midir?

(En büyük kart). Kesinlikle bu şekilde değil. Toyota fabrikalarındaki Kanban, tanımlayıcı ilkesi “tam zamanında” kavramı olan yalın üretimdir. Kanban, bir yönetim terimi olarak aslında Toyota'dan geldi. Japoncadan çevrilen bu kelime "sinyal" veya "kart" anlamına gelir. Otomobil fabrikalarında bu tür kartlar, kaç adet ve hangi parçaya ihtiyaç duyulacağı konusunda bir aşamadan diğerine bilgi aktarmak için kullanılıyordu.

Kısa bir örneğe bakalım. Üç arabayı “tam zamanında” yapmamız gerekiyor. Bu, belirli aşamalarda kaç parçaya ihtiyacımız olacağını önceden doğru bir şekilde belirleyebileceğimiz anlamına geliyor ve bu arabayı yaratmak için gerekli sayıda parçayı çıkarmaya sondan başlıyoruz ve şu sorulara cevap veriyoruz: “Kaç litre boya kullanacağız” ihtiyacın var?”, “Kaç tekerleğe?”, “Kaç motor?” ve benzeri. Böylece artık yedek parça fazlası yaratmıyor, depo, lojistik ve diğer maliyetlerden tasarruf sağlıyoruz.

Kanban yöntemi de “tam zamanında” kavramına bağlı kalıyor ancak Toyota fabrikalarından farklı olarak burada entelektüel çalışmadan bahsediyoruz. Başka bir deyişle, bir programcının kodu veya bir pazarlamacının fikri, nihai bir ürün veya hizmete dönüşene kadar ortalama bir insan tarafından dokunulamaz ve görülemez. Böylece entelektüel çalışmanın akışını görselleştirmek ve bu yarım kalan iş miktarını azaltmak için Kanban yöntemi kullanılır. Bu sayede son tüketiciye tekdüze ve öngörülebilir bir hizmet sunumu hızı elde edilir.

3. Kanban yöntemi BT dışında kullanılabilir mi?

Evet. Kanban yöntemi, herhangi bir yaratıcı ve entelektüel çalışmanın akışını görselleştirmek için uygundur. Ancak bunu hizmet paradigması prizmasından kullanmak çok daha etkilidir. Hizmet olarak ne yaptığınıza bakın. Hizmetin verilebilmesi için çalışma hangi aşamalardan geçmektedir? Hizmetin Müşterinin beklentilerine uygun olarak sunulduğunu hangi kriterlere göre anlayacaksınız? Kanban yöntemini kullanmanın başlangıç ​​noktası budur. Kanban uygulayıcıları bu noktaya "şu anda sahip olduklarınızla başlayın" diyorlar.

4. Kanban Scrum'a benzer mi?

HAYIR. Scrum katı kuralları ve sınırları olan bir çerçevedir. Scrum içerisinde farklı araçlar ve metodolojiler kullanabilirsiniz ancak Scrum'da gerekli olan bir şeyden vazgeçerseniz, o artık Scrum olarak değerlendirilemez. Kanban bir dizi uygulama ve ilkeye sahip bir yöntem, bir araçtır. Uygulamaların tamamını veya bazılarını kullanabilir veya hiç kullanmayabilirsiniz. Kanban'da neyin Kanban olduğu ve neyin Kanban olmadığına dair kesin bir kavram yoktur. Ancak uygulamaların akıllıca kullanılması, en yüksek kalitede hizmet sunmanıza ve müşteri beklentilerini karşılamanıza önemli ölçüde yardımcı olabilir.

5. Kanban'ın değerleri var mı?

Evet. Bunlardan dokuzu var: şeffaflık, denge, işbirliği, müşteri odaklılık, akış, liderlik, anlayış, anlaşma, saygı.

6. Kanban'ın ilkelerini yazdınız. Onlar neler?

Kanban'ın aynı zamanda değişim yönetimi ilkeleri olarak da adlandırılan temel ilkeleri vardır:

1. Şu anda sahip olduklarınızla başlayın.
2. Evrimsel gelişim konusunda hemfikir olun.
3. Her düzeyde liderlik gelişimini teşvik edin.

Kanban yöntemi bir hizmet paradigması içinde yaşadığı için ilkelerine bağlı kalır:

1. Müşterinin ihtiyaç ve beklentilerini öğrenin.
2. İşi yönetin, insanların onun etrafında örgütlenmesine izin verin.
3. Performansı artırmak için kurallar geliştirin.

7. Kanban'daki uygulamalar nelerdir?

Ayrıca altı tane var:

1. Görselleştirin.
2. Bitmemiş işleri sınırlayın.
3. İş akışını yönetin.
4. Açık kurallar kullanın.
5. Geri bildirim döngülerini (kadansları) tanıtın.
6. İyileşin ve gelişin.

Bunlar işimizi geliştirmek ve hizmet kalitesini artırmak için kullandığımız doğrudan pratik tekniklerdir.

8. Ah, kadanslar! Kanban'daki kadanslar nelerdir?

Kadans müzikten gelen bir terimdir. Kanban yöntemi bağlamında ritmi ifade eder. Kadanslar aynı zamanda geri bildirim döngüleri olan düzenli toplantılardır. Düzenlilik, iş akışının ritmini belirler. Yedi kadans:

1. Kanban toplantısı (günlük). Burada engellenen görevlerin durumunu tartışıyoruz.
2. Kuyruk doldurma toplantısı (genellikle iki haftada bir). Hizmet olarak yapacaklarımızın sorumluluğunu üstleniyoruz.
3. Teslimat planlama toplantısı (genellikle iki haftada bir). Yerine getirilen yükümlülükleri geri iade ederiz.
4. Hizmet inceleme toplantısı (genellikle iki haftada bir). Metrikleri kullanarak hizmetin kalitesini ve gerekirse nasıl iyileştirilebileceğini tartışıyoruz.
5. Operasyon toplantısı (genellikle ayda bir). İlgili hizmetlerin metriklerle etkileşiminin kalitesini tartışıyoruz.
6. Risk inceleme toplantısı (genellikle ayda bir). Engellenen görevlerin hizmetin işleyişi üzerindeki etkisini metriklerle tartışıyoruz.
7. Strateji inceleme toplantısı (genellikle üç ayda bir). Stratejideki değişiklikleri metriklerle tartışıyoruz.

9. Hizmet dersleri hakkında bir şeyler duydum. Bu nedir?

Kanban, belirli iş türlerine ve müşterilere öncelik vermek veya gecikme maliyeti gibi iş etkilerini azaltmak için hizmet sınıflarını kullanır. Gecikme maliyeti, hizmetlerin geç teslimi nedeniyle oluşan kar kaybı veya maliyetlerdir. Örnekleri kullanarak gecikme maliyetlerinin ve karşılık gelen hizmet sınıfının etkisine bakalım:

1. Hızlandırılmış sınıf – acil ilk yardım-canlandırma. Özel bir şeritte sürüş. Sorunun çözümünü ertelemeye zaman yok. En kısa sürede lazım.
2. Sabit Tarih Sınıfı – Gecikme maliyetleri belirli bir süre sonra önemli ölçüde artar. Örnek: sabit bir başlangıç ​​tarihi olan federal yasa biçiminde bir proje. Zamanında gitmezsek ehliyetimizi kaybetme riskiyle karşı karşıyayız.
3. Standart sınıf - gecikmenin maliyeti zamanla orantılı olarak artar. Bunu hemen yaparsak anında kar elde ederiz. Uzun süre yaparsak uzun süre kar elde ederiz.
4. Maddi olmayan sınıf - bunu yapıyoruz, ancak bu iş bariz bir kar getirmiyor, gecikmenin maliyeti yavaş yavaş artıyor. Örneğin evi temizlemek. Düzenli olarak temizlik yapmanıza gerek yok, ancak altı ay sonra kapsamlı bir temizlik yapmanız gerekecek.

10. Peki ya ölçümler? Bir hizmetin etkinliği nasıl ölçülür?

Kanban yöntemi şu soruları yanıtlamanıza olanak tanıyan metriklere sahiptir: iş akışındaki sorunlar nelerdir, hizmetin verimi nedir, yürütme süresi nedir, kilit çözüm süresi nedir, döngü süresi nedir ve ne kadardır? iş türleri dağıtılıyor mu? Bütün bunlar, servis yöneticisinin, biriken verilere dayanarak hizmet kalitesinin geliştirilmesi ve iyileştirilmesi konusunda kararlar almasına olanak tanır.

11. Kanban'ın uygulama sırasında karşılaştığı zorluklar nelerdir?

Asıl zorluk, her düzeydeki insanlara Kanban uygulamalarının değerini açıklamaktır: görselleştirme ve devam eden işin sınırlandırılması. İnsanların entelektüel çalışmanın hacmini görememeleri nedeniyle maruz kaldıkları yükü anlamaları zordur. Ancak örneğin beyin, biceps ile aynı kastır. Bir spor salonu hayal edin: içeri giriyorsunuz ve barın üzerindeki ağırlığı görüyorsunuz: “Tamam, bu çok az. Ve artık çok fazla. Ama bu doğru!” Beyinle de aynı şekilde çalışmanız gerekiyor: “Bu büyük bir görev, bu da küçük ve genel olarak bir şekilde çok şey üstlendim. Yükü sınırlayacağım.” İş akışını tüm seviyelerde uçtan uca görselleştirdiğimizde ve devam eden iş miktarını sınırlandırdığımızda, bilgi çalışması için bir çekme ilkesi yaratırız ve sonuçlarının müşterilerimize eşit bir şekilde akışını sağlarız.

12. Kanban yöntemi için hangi programlar var?

Onlardan da birçoğu var. Yalnızca yöntem için özel olarak geliştirilmiş profesyonel olanları listeliyoruz. Kalbimizi Rusya'nın Kaiten gelişimine adadık. Buna ek olarak TargetProcess, SwiftKanban, LeanKit ve diğerleri de var.

13. Peki hangi şirketler halihazırda Kanban yöntemini kullanıyor?

Ruslar arasında Alfa-Bank, Home Credit Bank, Pochta-Bank, Dodo Pizza, HeadHunter, Clever ve diğerleri yer alıyor. Yabancıdan: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, Tupalo. Bu listeye uzun süre devam edilebilir.

14. Önemli olan başka bir şey var mı?

Evet. Son olarak Kanban yönteminde iki rolün önemine dikkat çekmek isterim. Bunlar hizmet dağıtım yöneticisi ve hizmet talep yöneticisidir. Birincisi tedarik akışındaki engellerin kaldırılmasından sorumludur. İkincisi, birçok müşteriden gelen hizmete yönelik talep akışını yönetmek içindir. Bu iki rolün ortak olması ve birlikte çalışması çok önemli.

15. Tamam, anlıyorum. Bir organizasyonda Kanban'ı uygulamaya nereden başlamalı?

Kanban'ı organizasyonlarda uygulamaya başlamak için S.T.A.T.I.K aracını kullanıyoruz. – Kanban kullanımına sistematik bir yaklaşım. Bununla ilgili daha fazlasını internette okuyabilirsiniz. Ancak bu aracın iş oyunu formatında öğretildiği bir eğitime katılmanızı öneririz. Hizmetinizi (organizasyonunuzu) örnek alarak, daha sonra savaş koşullarında kullanılmak üzere bir Kanban sistemi tasarlayabilirsiniz.

Çevik metodolojiler konusunda eğitmen ve danışman, Scrumtrack.

Tünaydın

Test ekibi koordinatörü olarak mesleki ilgi alanlarımdan biri yazılım geliştirme metodolojileridir. Şu anda Çevik metodolojiler, özellikle Scrum ve Kanban giderek daha popüler hale geliyor. Vicdansız "eğitimciler" "abartılı" terimlerle oynuyorlar; seminerler ve sertifikalar ("sertifikalı Scrum ustası", "sertifikalı Ürün sahibi" vb.) büyük bir hızla büyüyor.

Çoğu vicdansız makale ve eğitimde, herhangi bir metodoloji, iletişim sorunlarını anında çözecek ve bireysel ekip üyelerini beceriksizlikten anında kurtaracak sihirli bir sihirli değnek olarak sunulur. Genel olarak sorunlarınızı tam olarak çözmenize yardımcı olacaktır. Bu yıl Belarus Devlet Üniversitesi'nde insan kaynakları yönetimi teknolojileri alanında yüksek lisans programına giriyorum ve en yaygın yazılım geliştirme metodolojilerinin uygulanabilirliğinin sınırlamalarının yanı sıra artılarını ve eksilerini ayrıntılı olarak değerlendirmeyi planlıyorum.

Çalışma sürecinde, metodolojik araçların yanlış yorumlanması ve yanlış yorumlanması, moda metodolojinin bağlam dikkate alınmadan kullanılmasıyla sık sık karşılaştım. Makaleyi okuduktan sonra sorunun yerelden çok küresel olduğunu fark ettim. Bugün Kanban'a, tarihine, temel ilkelerine ve olası uygulama sınırlarına biraz göz atmayı öneriyorum.

Terimin tarihi

Kanban, Toyota'da 20. yüzyılın 60'lı yıllarında üretimle ilgili olarak kullanılmaya başlanan Japonca bir terimdir. Bu prensip, konveyör üretim yönteminin yanı sıra üretimde bireysel teknolojik işlemlerin gerçekleştirilmesi için farklı hızlara dayanmaktadır. Parmaklarımla anlatmaya çalışacağım. Her üretimde bir ana üretim (“ana konveyör”) ve ek üretim (“ek konveyörler”) bulunur. Nihai ürünlerin üretim hızı ana konveyör tarafından belirlenirken, ek konveyörler ürün çıkış hızını artıramaz ancak gerekli parçalar zamanında piyasaya sürülmezse yavaşlatabilir.

Ayrıca üretim sırasında önceliklerde değişiklik olabilir. Örneğin sol ayna üreten istasyonun 20 adet, sağ ayna üreten istasyonun ise 10 adet ürettiği, montaj hattında ise 15 adet araba olduğu ve her iki türden 15 adet aynaya ihtiyaç duyulduğu ortaya çıktı. Ölçülerde bir çelişki var; üretim niceliksel olarak düşmedi (ilave konveyörler zamanında 30 ürün üretti), ancak üretimin hâlâ durma riski var. Kanban bu soruna yardımcı olmak için tasarlandı.

En basit haliyle Kanban iki basit kural içerir:

• Üretim istasyonunun bir parça üretim planı (“bekleme listesi”) vardır. Plan öncelik sırasına göre sıralanmıştır ve herhangi bir zamanda değişebilir (örneğin, çok fazla sol ayna üreten bir istasyon mümkün olan en kısa sürede sağ aynaya geçebilmelidir);
• istasyonda aynı anda gerçekleştirilen görevlerin sayısı sınırlıdır (yani aynı anda belirli sayıda aynadan fazlasını üretmeyin). Bu sınırlama, istasyondaki üretim hızının yanı sıra plan değişikliklerine yanıt verme hızının da kontrol edilmesi için gereklidir.

Şimdiki zaman

Son zamanlarda Kanban, yazılım üretiminde oldukça popülerlik kazanıyor. Bazı ekipler bu metodolojiyi son derece faydalı buluyor, bazıları ise bunu bir “Kargo kültü” olarak kullanıyor. Deneysel deneyimlerime dayanarak, saf Kanban ürün ekipleri için pek işe yaramıyor ("temel boru hattını" okuyun), ancak aşağıdaki gibi destek ekipleri için harika çalışıyor:

• “planın” önemli olmadığı ancak değişikliklere yanıt verme hızının önemli olduğu yazılım destek grupları;
• geliştirme ekiplerinden ayrı çalışan test ekipleri;
• destek Hizmetleri;
• “temel olmayan sektörlerin” diğer örnekleri.

Ayrı olarak, Kanban'ın net bir planı olmayan ancak aktif olarak geliştirme üzerinde çalışan girişimlerde iyi çalıştığını da belirtmek gerekir. Kanban'ı yazılım geliştirmede kullanmanın bir örneğini düşünmeyi öneriyorum. Çirkin çizimler için şimdiden özür dilerim. Küçük bir proje üzerinde çalışan bir geliştiriciden oluşan bir ekip hayal edelim. Geliştirme planı (bekleme listesi) iş parçalarının öncelik sırasına göre sıralanır, süreçteki görevler için ekip limiti 1 adettir.

Süreci yönetmek için proje yöneticisi şunları yapabilir:

1. işteki görev sayısı sınırını değiştirmek;
2. mümkün olan en kısa sürede alınması için daha yüksek önceliğe sahip bir görev ekleyin (örneğin p0);

Çalışma süreci sırasında işin engellenmesi söz konusu olabilir (barındırma bozuldu, gerekli çerçeve indirilmedi vb.). Genel olarak, engellenen iş biriktirme listesine geri döndürülür ve en yüksek önceliğe sahip yeni bir görev seçilir. Görevlerin niteliğine ve ekip türüne bağlı olarak limit artırılabilir veya azaltılabilir. Örneğin, geliştiricimiz aynı anda bir kayıt formu çizebilir ve yeni bir sunucunun konuşlandırılması sürecini izleyebilir. Ancak görevin tamamlanma süresi gerekenden azsa proje yöneticisi sınırı azaltabilir veya ekibi artırabilir. Böylece, uygun yönetimle Kanban, belirli bir ekip için mümkün olan en yüksek çalışma hızını, değişikliklere maksimum yanıt verme hızını sağlar ve aynı zamanda metodolojiyi desteklemenin "maliyetlerini" azaltır. İşte bu kadar! Kanban kolay değil, basit. Çok basit!

Ürün ekiplerinde kullanıldığında Kanban'ın sınırlamaları şunları içerir:

• bu metodoloji büyük ekiplerde (5'ten fazla kişi) iyi çalışmaz;
• Saf haliyle Kanban, işlevler arası ekiplerle iyi çalışmaz. Onlar. Scrum'ın aksine test ve geliştirmeyi tek bir takımda birleştirmek zordur. Daha iyi bir fikir, süreci ayrı yöneticiler ve biriktirilmiş işlerle birlikte bir geliştirme "istasyonuna" ve bir test "istasyonuna" bölmektir;
• Geçmişi ve özellikleri nedeniyle Kanban uzun vadeli planlamaya yönelik değildir.

Çözüm

Sonuç olarak, herhangi bir metodolojiyi "kim daha havalı" ilkesine göre karşılaştırmanın üretken ve yapıcı olmadığını eklemek isterim (Kaptan Açıkça görülüyor). Az ya da çok yaygın olan her metodolojinin artıları, eksileri ve uygulama sınırları vardır. Ek olarak, Çevik metodolojiler doğası gereği ekip üyelerinin ekip çalışmasına ve deneyimine daha fazla talep getirir.

Konuya ilgi olursa Kanban'ı daha detaylı ele almaya devam edeceğim, ardından Scrum ve RUP'u parçalara ve resimlere ayırmayı öneriyorum.

Daha detaylı ve net bir şekilde inceleyebilirsiniz.

Kanban - nedir bu? Bir Kanban kartı ne kadar ilginç bilgi içerir ve yöntem üretimde hangi işleve hizmet eder? Makalede kanbanın etkili kullanımına ilişkin kuralları ayrıntılı olarak açıklayacağız ve ayrıca belirli bir örnek kullanarak ilgili kartların kullanım şemasının net bir tanımını vereceğiz. Ayrıca materyale aşina olduktan sonra, neden bir Kanban panosuna ihtiyaç duyulduğunu, üretimin yanı sıra hangi alanlarda bu yöntemin kullanılmasının tavsiye edildiğini ve buna neyin iyi bir alternatif olabileceğini öğreneceksiniz.

Kavramın özü ve yöntemin temel özellikleri

Bugün, kanban sistemini de içeren "anlık" envanter yönetimi komplekslerinin oluşumunun ana nedeni olan stokların depolanmasına ilişkin maliyetlerin artmasına yönelik açık bir eğilim gözlemlenebilir. Japoncadan tercüme edilen "kanban", "etiket", "rozet" anlamına gelir. Bu terim, bir ürünün çekme sisteminde üretilmesi veya hariç tutulması (transferi) için izin veya göstergenin verildiği bir bilgilendirme yöntemi olarak hizmet eder.

Sunulan bilgi aktarma seçeneği, belirli bir üretim siparişini bir sonraki aşamadan bir önceki aşamaya aktarmak için bilgi kartlarının kullanımı yoluyla yalın üretim hatlarını tam olarak yönetmenize olanak tanır.

Böyle üretken bir sistemin geliştiricisi, sunulan fikri tam zamanında yöntemini pratik olarak uygulamaya yönelik ilk girişimlerden biri olarak açıklayan Toyota Motors'tur. Kanban sistemine göre üretim aşağıdaki kurala uygun olarak gerçekleştirilir: İşletmenin bölümlerine, siparişi tamamlamak için gereken, açıkça tanımlanmış bir son tarihe kadar ve belirli miktarda kaynaklar sağlanır.

Süreç ayrıntıları

Sunulan yöntemin şeması son derece basittir, ancak üretim sürecinin organizasyonu üzerinde çok etkili bir etkiye sahiptir. İşletmenin bölümlerini kaynaklar açısından sağladıktan sonra, doğrudan sondan bir önceki aşamadan gelmesi gereken gerekli iş hacminin ayrıntılı bir hesaplaması gerçekleştirilir (buna göre bitmiş ürün siparişi, işin son aşamasıdır). süreç). Benzer şekilde, sondan bir önceki aşamadan itibaren, belirli bir hacimde yarı mamul ürün için bir önceki aşamaya talepte bulunulur.

Böylece belli bir sahadaki üretimin ölçeği bir sonraki üretim aşamasının ihtiyaçlarına göre oluşturulmaktadır. Yakınlarda bulunan üretim sürecinin her iki aşaması arasında çift tip bir bağlantı kurulması mantıklıdır:

1. n'inci aşamadan n-1'e kadar gerekli miktarda devam eden çalışma talep edilir ("çekilir").
2. n-1. aşamadan n. aşamaya kadar gerekli miktarda malzeme kaynağı gönderilir.

Bilgi aktarım araçları

Kanban'ın ne olduğunu daha iyi anlamak için, bu sistemde bilgi aktarma aracının iki gruba ayrılan özel kartlar olduğunu anlamalısınız:

1. Üretim emriyle doğrudan ilgili araçlar. Bu tür kartlarda öncelikle üretim sürecinin bir önceki aşamasında üretilmesi gereken parça sayısı belirtilir. Üretimin n'inci aşamasından n-1 aşamasına gönderilirler ve bu sahalar için üretim programının geliştirilmesinin ana nedeni olarak hizmet ederler.
2. Seçim araçları, önceki montaj aşamasında alınması gereken gerekli malzeme kaynaklarının (buna yarı mamul ürünler, malzemeler, parçalar vb. dahil olabilir) hacmine ilişkin bilgiler içerir. Bu tür kartlar, üretim sürecinin n'inci aşamasından n-1'inci aşamasına kadar fiilen alınan kaynak hacmini gösterir.

Kartların yalnızca işletmenin iç altyapısı ile ilgili olarak değil, aynı zamanda şubeleri veya işbirliğini destekleyen kurumlar arasında da dolaşabileceğini unutmamak önemlidir.

Kanban'ı kullanmanın etkili yöntemleri - nedir bu?

Toyota Motor Corporation'ın başkanı Taiichi Ohno, kanban kartlarını maksimum verimlilikle kullanmak için bir dizi prensip geliştirdi:

• Üretim faaliyetinin sonraki işlemi, kartta belirtilen parça hacmini önceki işlemden çıkarır.
• Ön tarafta yer alan üretim işlemi, belirli bir kartta belirtilen miktar ve sırayla parçaların oluşturulmasına uygun olarak gerçekleştirilir.
• Kartsız oluşturulabilecek parça yoktur. Bu hüküm, aşırı üretimin azaltılmasına ve ayrıca ürünlerin aşırı hareketine izin vermektedir. Böylece dolaşımdaki kartların hacmi maksimum stok miktarına eşit olur.
• Kart, bir ürünün üretimine yönelik bir sipariştir (ürün her durumda ilgili karta iliştirilir).
• Herhangi bir kusuru olan parçalar sonraki proseslere aktarılamaz. Bu hüküm, ürünlerin üretiminin mümkün olduğu kadar hatasız yapılmasını mümkün kılmaktadır.
• Kart sayısının azaltılması hassasiyet düzeyini artırır. Böylece mevcut sorunlar ortaya çıkarılarak stokların etkin kontrolü gerçekleştirilir.

Kart kullanmanın özellikleri

Anlaşıldığı üzere kanban yönetimi, özel kartların kullanımını içeren belirli bir şemaya göre gerçekleştirilmektedir. Bu nedenle, kullanımları sırasında, söz konusu sistemin mutlak görünürlüğünü ve maksimum güvenliğini sağlamaya yönelik gereklilikler tam olarak yerine getirilmelidir: kartların kaybolması ve karıştırılması tamamen ortadan kaldırılır.

Uzmanlar, Kanban sistemine maksimum verimlilik sağlamanıza olanak tanıyan etkili bir araç geliştirdi. Bu yöntemin panosu, çalışanlar işyerinde sıklıkla birkaç farklı araç kullandığından, aktif kartlar için bir toplama noktası görevi görür. Böylece üreticiye giden kartlar kontrol panosunun üzerine yerleştirilir. Ve yeni alınan tarak takımları "başlangıç" alanına ulaştığında, ilgili parça numarasına sahip tüm kart seti daha sonraki üretim sürecini gerçekleştirmek üzere aktarılır.

Kanban yöntemini kullanmanın faydaları - nedir?

Bunu kullanan işletmeler günlük olarak (ve genellikle gün boyunca birkaç kez) maddi kaynak tedariki alırlar. Bu, üretim stoklarının yıl içinde yaklaşık 100-300 kez tamamen güncellenmesine olanak sağlar. Kanban'ı MRP veya MAP gibi sistemlerle karşılaştırırsak bu durumda güncellemeler yaklaşık 10 kat daha sık gerçekleşir.

Kanban yönteminin, daha az verimli olan diğer yöntemlere göre mutlak avantajını ortaya koyan örneklerle değerlendirilmesi tavsiye edilir. Böylece Toyota Motors Corporation, birçok üretim tesisinden birine 1976'da günde üç kez, 1983'te ise her on dakikada bir kaynak sağladı.

Kanbanlar genellikle süpermarketlerle çalışırken kullanılır (bu amaç için özel olarak oluşturulmuş stoklar). Böylece tüketici, yukarıda belirtildiği gibi ürünün hacmini belirten bir seçim kanbanını süpermarkete gönderir ve süpermarket kendisine belirtilen sayıda ürünü aktarır. Aynı zamanda süpermarket tedarikçiye bir yenileme kanbanı gönderir ve ardından tedarikçi ürünleri süpermarkete aktarır.

Yöntemin temel unsurları

Kanban sisteminin en önemli bileşenleri şunlardır:

1. Yapısında sadece kartları değil aynı zamanda üretim, nakliye veya tedarik programlarının yanı sıra teknolojik haritaları da içeren bir bilgi kompleksi.
2. İhtiyaçların kontrolü ve profesyonellikle doğrudan ilgili bir kompleks.
3. Toplam (TQM) ve seçici (Jidoka) ürün kalite kontrolüne olanak tanıyan bir kompleks.
4. Üretimin mutlak düzeyde dengelenmesini sağlayan bir kompleks.

Sunulan öğeler birlikte kullanıldığında, en kısa üretim döngüsüne, yüksek düzeyde varlık devir hızına (stoklar dahil) ulaşmayı, aynı zamanda hem üretim için depolama maliyetlerini ortadan kaldırmayı ya da en aza indirmeyi hem de elbette en yüksek kaliteye ulaşmayı mümkün kılar. Üretim sürecinin her aşamasında ürün.

Sistemin dezavantajları ve kullanımının sonuçları

Her gelişme gibi, tam zamanında sistemin de bazı dezavantajları vardır. Birincisi, belirli bir ürünün üretim aşamaları arasında yüksek düzeyde tutarlılık düzenlemenin zorluğudur.

İkincisi, üretim sürecinde ve buna bağlı olarak ürünlerin satışında ciddi bir aksama riski var. Bununla birlikte, söz konusu yöntemin uygulanmasına ilişkin dünya uygulamalarının ayrıntılı bir analizi, sunulan sistemin, işletme sermayesi cirosunu önemli ölçüde hızlandırarak üretim stoklarını yarı yarıya ve stokları %8 oranında azaltmayı mümkün kıldığını gösterdi. doğal olarak bitmiş ürünün kalitesinde bir artış.

Kanban kullanımının üretim süreçleriyle bitmediğine dikkat etmek önemlidir. Böylece sistem, ofis ve proje faaliyetlerinde, programlamada (tam bir kanban geliştirme kompleksi vardır) ve ayrıca kişisel sonuçların elde edilmesinde (kişisel kanban türü) aktif olarak kullanılmaktadır.

Kanban sistemi yolculuğuna 1950'li yıllarda Toyota Corporation'ın üretim hatlarında başlamış, daha sonra ofislere taşınmış ve proje yöneticileri için önemli bir araç haline gelmiştir.

Uygulamanın sonsuz esnekliği ve personelin kendi kendini organize etmesine yönelik fırsatlar, diğer yaklaşımların işe yaramadığı durumlarda verimliliğe ulaşmayı mümkün kıldı. Kartın kendisinin sistemin arama kartı haline geldiği durum budur - Kanban'ı uygulayan kuruluşlarda kendisini dahili bir para birimi olarak kurmuştur.

Menşei

Yalın üretim konsepti gibi kanban sistemi de Toyota yöneticileri tarafından geliştirildi. Sistemin yazarı Japon mühendis Taiichi Ono, alıcının ihtiyaç duyduğu ürünleri kendisinin seçtiği Amerikan süpermarketlerinin çalışma prensibinden ilham aldı. Toyota şirketinde "süpermarket" rolü bir depo tarafından yerine getiriliyordu.

Orada, sinyal kartları - ve "kanban" kelimenin tam anlamıyla Japoncadan bu şekilde çevrilmiştir - işçiler, üretim sürecini kendi elleriyle düzenleyen sinyal kartlarını değiş tokuş ettiler.

Kartlar, parçaların bulunduğu kaplara takıldı. Bu etiketler parça sayısı ve miktarı, bunları hangi departmanın gönderdiği ve nereye ulaşması gerektiği hakkında bilgiler içeriyordu.

Makinelerin (aşağı akış) kurulumunda ve montajında ​​doğrudan yer alan işçi, depo talebiyle üzerine bir "kanban" iliştirilen konteynırdan parçalar aldı. Kart çıkarıldı ve boş kutuyla birlikte nakliyeci tarafından depoya nakledildi. Orada başka bir çalışan, üzerine üretilen yedek parçalar hakkında bilgi içeren bir etiket olan üretim "kanbanı" iliştirilmiş yeni bir yedek parça kabı hazırlamıştı.

Üretim kanbanı, depo için bir talep kanbanı ile değiştirildi ve parça üretim hattına (yukarı yönde) gönderildi. Bu nedenle tam olarak kartta belirtilen sayıda parça üretildi. Yeni yedek parçaların bulunduğu konteynerler montaj hattındaki taşıyıcılara götürüldü.

Kanban ilkeleri

Toyota yöneticileri sistemi oluşturan 6 kuralı formüle etti:

1. Alt çalışanlar depodan tam olarak kanban'da belirtildiği kadar parça çıkarır
2. Üretim tarafının temsilcileri ayrıca yedek parçaları kesinlikle kartlara uygun olarak tedarik ediyor
3. Kanban olmadan hiçbir şey üretilemez veya taşınamaz.
4. Kanban her zaman parçalara eklenmelidir
5. Arızalı parçaların sistemde kullanılmaması
6. Kanban kartlarının sayısının azaltılması, yönetimin değişime daha duyarlı olmasını sağlar. Ancak kesinlikle gerekli olmadıkça belirlenen kart sayısını değiştirmemelisiniz.

Kanban bir “çekme” sistemidir. Bekleme maliyetlerini ortadan kaldıran sabit akış ile aşırı üretim riskini azaltan minimum süreç içi çalışma (WIP) arasında bir denge oluşturur. RVP, kartlar kullanılarak düzenlenir: sayıları sabittir ve içlerindeki talimatlar, sonraki performansçılara rehberlik eder.

Zorunlu etiket kuralı, enerjinin korunumu yasası gibi çalışır.

RVP limiti, satış düzeyine ve mevcut süreçlerdeki istatistiksel değişkenliğe bağlı olarak hesaplanan kanban kartı sayısıyla orantılı olarak belirlenir. Maksimum etiket sayısı (sistemdeki aynı "enerji") herhangi bir zamanda RVP'nin üst seviyesini sabitler. RVP ayrıca çekme ilkesiyle de sınırlıdır: üst akışın üretim hızı, alt akışın hızına bağlıdır.

Grafik sistemin temel unsurlarından birinin Kaizen kültürü olduğunu göstermektedir. Özerk süreç ve standart varyasyon, yönetimi sürekli yönetimden kurtarır, böylece çalışanların performansını artırmaya odaklanabilirler.

Kanban'ın BT'de Uygulanması

Kanban üretim hatlarına değer sağlamaya devam ederken yazılım dünyasına da adım attı.

Yalnızca son teslim tarihleri, açıklama veya işlem numarası ve icracının adı hakkında bilgi içeren kartlar artık yedek parçaların bulunduğu konteynere değil, çizgili sütunlu bir panoya iliştirilmiştir:

• Biriktirme listesi - tamamlanması gereken görevler
• Şu anda geliştirilmekte olan görevler
• Tamamlanan ancak henüz test kullanıcılarına aktarılmayan görevler
• Test departmanına aktarılmaya hazır görevler
• Proje yöneticisi (PM) tarafından incelenen görevler
• Tamamlanan görevler

Genellikle sütunların üstüne bir sayı yazılır - limit, içindeki maksimum işlem sayısını gösterir. Biriktirme limiti, ön süreye bağlı olarak hesaplanır. Sistemde devam eden 5 iş varsa ve her birinin tamamlanması ortalama 1 gün sürüyorsa, biriktirme listesi 5 ile sınırlandırılabilir.

Yukarıdaki yapı katı değildir - Projenin özelliklerine göre doğaçlama hoparlörler eklenebilir.Çoğu zaman, bir görevin yerine getirilmesinden önce hazır olma kriterlerini belirlemenin gerekli olduğu bir kanban sistemi vardır. Sonra İngilizce'de adı verilen iki sütun belirir. belirtmek(parametreleri belirtin) ve uygulamak(çalışmaya başlamak).

• Daha öncelik sırasına sahip bir sütun eklenebilir.Sanatçı özgür olduğunda, bu özel görev sütununu boşaltmalı ve sonra başkalarını üstlenmelidir.
• Tamamlanmayan görevler ya birikime geri gönderilir ya da plandan çıkarılır.

• Kanban çoklu görevi teşvik etmez, dolayısıyla bir uygulayıcı için bir işlem sınırı ayarlanır.

• Tamamlanan işler, başlatılan birden fazla çalışmaya tercih edilir.

• İlki engellenmişse ikinci bir işe girebilirsiniz.
• Bir görevi tamamlama süresi dengeli olmalıdır.Çok kısa bir süre kaliteyi etkileyecektir. Aşırı uzatılmış bir limit, ekip kaynaklarını boşa harcar ve sürecin maliyetini artırır.

Neden örneğin tabletler veya devasa bir monitör değil de her yerde Kanban panosu kullanılıyor? Sistemin hayranları bu soruyu yanıtlarken, normal bir kartın iki avantajı var: Basit olması ve görsel kontrol sağlaması. Değişiklik yapmak kolaydır ve ekip üyeleri arasında dokunsal ve sosyal etkileşim sağlar.

Kanban'ın Avantajları ve Dezavantajları

Kanban'ın aşağıdaki avantajları vardır:

1. Planlama esnekliği. Ekip yalnızca mevcut işe odaklanır, görevin önceliği yönetici tarafından belirlenir.
2. Geliştirme sürecine yüksek ekip katılımı. Düzenli toplantılar, şeffaf süreçler ve kendi kendini organize etme fırsatları aracılığıyla çalışanlar birleşir ve gerçek ilgi gösterir.
3. Daha kısa döngü süresi. Birkaç kişinin benzer becerilere sahip olması durumunda süre kısalır, ancak tek kişi olması durumunda darboğaz ortaya çıkar. Bu nedenle çalışanların bilgiyi paylaşmaları ve dolayısıyla döngü sürelerini optimize etmeleri gerekiyor. Daha sonra tüm ekip durmuş olan işi alıp düzgün akışı yeniden sağlayabilir.
4. Daha az darboğaz. RVP limitleri dikkat, insan veya beceri eksikliği nedeniyle ortaya çıkan darboğazları ve sorunlu alanları hızlı bir şekilde bulmanızı sağlar.
5. Görünürlük. Tüm çalışanların verilere erişimi olduğunda darboğazların tespit edilmesi daha kolay olur. Kanban ekipleri, kartların yanı sıra genellikle iki genel rapor kullanır: kontrol ve kümülatif akış grafikleri.

Uygulamada sistem, temel olmayan üretim alanlarında iyi performans göstermektedir:

• yazılım desteği veya yardım masası ekipleri.
• Kanban, açık bir plan olmadan ancak gelişimin aktif olarak ilerlediği startupları yönetirken iyi çalışır.

Kanban'ın dezavantajları da vardır:

1. 5 kişiden fazla ekiplerde sistem iyi çalışmıyor
2. uzun vadeli planlamaya yönelik değildir.

Scrum'dan Farklar

Scrum, çevik kanban gibi esnek bir metodolojidir ve BT alanında da sıklıkla kullanılır. Aralarındaki farklar ilk bakışta belirgin değildir. Pek çok benzerlik var; örneğin her iki yaklaşımda da birikmiş işlerin varlığı.

	Scrum	Kanban
Adımlamak	Sabit süreli tekrarlanabilir sprintler	Sürekli süreç
Sürüm sürümü	Her sprint sonunda proje yöneticisi (ürün sahibi) tarafından onaylandıktan sonra	Akış kesintisiz veya ekibin inisiyatifinde devam eder
Roller	Ürün Sahibi, Scrum Master, Geliştirme Ekibi	Bir PM tarafından yönetilen bir ekip, bazı durumlarda çevik kanban eğitmenleri de dahil olur
Ana göstergeler	Takım hızı	Lider zaman
Değişikliklerin kabul edilebilirliği	Sprint sırasında yapılan değişiklikler yanlış görev tahminlerine yol açabileceğinden istenmeyen bir durumdur.	Değişim her an gerçekleşebilir

BT'de uygulama örnekleri

Doğrudan Microsoft'tan: Kanban yazılım geliştirmede ilk kez sahneye çıkıyor

Kanban ilkelerinin bilgi teknolojisi endüstrisinde kullanımı 10 yılı aşkın bir süre önce başladı. Yazılım geliştiriciler için Kanban'ın ana popülerleştiricilerinden biri olan David Anderson, 2005 yılında Microsoft'a danışmanlık yaptı. Kendi departmanlarının dahili uygulamalardaki hataları ortadan kaldıran XIT Sürdürülebilir Mühendislik çalışmalarından memnun değillerdi. Raporlama yılının başında bu departman kendi departmanının en kötüsüydü. Birikmiş iş, izin verilen boyutu 5 kat aştı ve bir isteği işleme koyma süresi şu kadardı: önde gelen zaman- genellikle 5 ay sürdü.

Yeni Başbakan, Anderson'un istişarelerinin yardımıyla sorun departmanının verimliliğini 9 ayda %155 artırdı. Lider zaman artık 5 haftaydı, birikmiş iş normal boyutuna döndü ve görevlerin zamanında tamamlanma oranı %90 olarak belirlendi. Tüm bu sonuçlar, yeni çalışanların asgari düzeyde katılımıyla elde edildi; personel, aynı yöntemleri kullanarak yazılım hatalarını düzeltmeye devam etti - Yalnızca işi organize etme yaklaşımları değişti.

İlginç gerçek: XIT'te gidişatı değiştirmeyi üstlenen program yöneticisi Dragos Dumitriu, Anderson'un kitabına hayran kalmıştı. Şaşırtıcı bir şekilde, bir gün önce iş bulduğu Microsoft'ta yazılım Kanban'ın ideoloğuyla tanıştı. Dumitriu, Anderson'dan görevinde yardım etmesini istedi ve Anderson, kitabının ilkelerini uygulamaya koymayı kabul etti.

Dumitriu, birikimlerinde 80 istek birikmiş üç geliştirici ve üç testçiden oluşan bir departman buldu. Pozisyonun gereklilikleri ASP teknolojisiyle çalışma yeteneği, SQL Server kullanarak yönetim ve MS Project Server bilgisini içerdiğinden, Başbakan'ın kendisi geçici olarak atandı. Patronlar bu pozisyonu programlamayı bilen, rapor derlemesi ve birikmiş iş yükünü tahmin etmesi gereken bir "teknisyen" olarak görüyorlardı. O zamanlar etkileyici bir veri dizisi toplanırsa departmanın sorununun tanımlanabileceğine inanılıyordu. Dumitriu o kadar da "teknisyen" değildi.

Ancak kendisi ve Anderson, XIT'in performansını analiz etmeye başladıkça, departmanın hızını olumsuz yönde etkileyen temel faktörleri hızla belirledi:

• Bir isteği yürütmenin sonuçlarını (ROM) tahmin etmek çok zaman aldı. Hem geliştiricinin hem de testçinin gerekli hesaplamaları, kod incelemelerini ve dokümantasyonu tamamlamak için tam bir gün harcaması gerekiyordu. Ortalama olarak günde bir talep alındı. PM tahminlerine göre departmanın verimliliğinin %40'ı ROM'a harcandı;
• Daha yüksek değere sahip taleplere öncelik verildi. XIT, siparişin maliyetinden fon aldı. Taleplerin önceliği her ay departman yöneticilerinin müşterilerle - diğer departmanların yöneticileriyle yaptığı toplantıda tartışıldı. Mevcut hızda birikme patlaması yaşanırken, ayda yalnızca 6-7 talep işlenirken, diğer taleplerin öncelikleri zaman geçtikçe sürekli değişiyordu. Birçoğu, bir sonraki aya bile eşit olmayan, etkileyici bir "sonraya" ertelendi.
• ROM aşamasında isteklerin yarısı elendi. Bazıları çok büyüktü ve proje olarak başka bölümlere aktarılacak şekilde yeniden nitelendirildi, bazıları ise çok pahalıydı ve iptal edildi. Bazı taleplerin uygulanması çok uzun süreceği için geliştirme aşamasına alınmadı. Böylece departmanın verimliliğinin %40'ı, %50'si reddedilen taleplerin analizine harcandı. İşgücü kaynaklarının yaklaşık %15-20'si israf edildi.
• Talebin hazırlık çalışmaları uygulama başlamadan önce aylarca sürebilir. ROM aşamasındaki hesaplamalar bu süre içerisinde kaybolabilir veya unutulabilir. Özellikle uygulama, analizi başlatan aynı geliştirici tarafından gerçekleştirilmediyse.

Sorunlu bir Microsoft departmanı için Kanban çözümleri

1. Dumitriu ve Anderson, yönetim ve müşteri yöneticileriyle yapılan görüşmelerde ROM aşamasının terk edilmesi konusunda ısrar etti. Hesaplamalar uygulamadan hemen önce ve aynı sanatçı tarafından yapıldı, yani "taze" kaldılar.
2. Taleplerin önceliklendirilmesi aylık toplantılarla değil, duruma göre telefon veya e-posta yoluyla gerçekleştirildi. İş yığınındaki 80 görev müşterilere göre sıralandı. İkincisinden ilk önce tamamlanması gereken ana sorguları vurgulaması istendi.
3. XIT finansmanı sabit hale geldi.
4. Taleplerin maliyeti artık dikkate alınmamaktadır.
5. Başbakan, Kanban panosundaki tamponlara girdi. Geliştiriciler işi iki bölgeden aldı: onaylanan ve tamamlanan görevler. Tamponda 6 istek vardı, 5'i çalışmaya alındı. "Test için bekleme" arabelleğinden seçilen test kullanıcıları. Kodda değişiklik gerektirmeyen bazı görevler, geliştiricileri atlayarak orada kaldı. Talepleri tek görevli süreçlere bölerek PM, durum üzerinde daha fazla kontrole sahip olabilir ve müşterilere şeffaflık sağlayabilir. Tamponların eklenmesi, hazırlık süresini kısalttı. Tahmin edilebilir bir sistem altında müşteriler, bir sonraki adımda kimin isteğinin arabelleğe alınması gerektiğini daha iyi belirleyebilir.
6. Taleplerin çok büyük veya pahalı olması durumunda hemen karar veriliyordu. Geliştirici, görevi 15 gün içinde tamamlamaya hazır olduğunu veya değişikliklerin buna değdiğini onaylarsa, boyut veya maliyete bakılmaksızın istek kabul edildi.
7. Departmandaki akışı gözlemledikten sonra Başbakan, personel yapısının daha fazla iş yüküne sahip geliştiriciler lehine değiştirilmesi gerektiği sonucuna vardı. Değişiklikler 2:1 oranında gerçekleştirildi: 4 geliştirici ve 2 test uzmanı XIT'te çalışmaya başladı.

2005 yılı sonu itibarıyla departmanın verimliliği %155 oranında arttı. XIT'in çalışmasını daha da geliştirmek için orada iki çalışan işe alındı: bir geliştirici ve bir test uzmanı. Biriktirilen istek sayısı 10'a düştü ve bir geliştirici, her çeyrekte tutarlı bir şekilde 11 isteği işlemeye başladı. Daha önce 11'e kıyasla çeyrek başına ortalama 56 istek tamamlandı. Taleplerin maliyeti 7.500 dolardan 2.900 dolara düştü.

Corbis'e başvuru

Microsoft'ta başarıya ulaşan Anderson, 2006 yılında yeni bir sorunu çözmeye başladı. Şimdi ise henüz MS'ten ayrılmamış olan Bill Gates'in bir başka şirketi olan Corbis'te çalışıyordu. Corbis'in faaliyetlerinden biri fotoğraf lisanslamasıydı. O zamanlar yaklaşık 3,5 bin görselden oluşan veritabanıyla dünyanın en büyük ikinci fotoğraf stoğuydu.

Anderson'ın görevi şirketin büyük sürümlerini hızlandırmaktı. Çıkışları arasındaki süre üç aydı ve daha da uzayabilirdi. Sadece sürüm planını tartışmak bile yönetimin iki haftasını aldı. Her iki haftada bir küçük sürümlerin veya güncellemelerin yayınlanmasını ayarlamak gerekiyordu. Aynı zamanda, kilit kaynakların ana proje üzerinde çalışmaya yönlendirilmesi gerekiyordu.

Anderson'ın ekiple her gün iletişim kurduğu Corbis ofisinde bir Kanban panosu belirdi. PM'nin amacı, süreçler üzerinde görsel kontrolü geliştirmek, kendi kendini organize etmeyi ve sanatçıların daha fazla kişisel sorumluluğunu geliştirmekti. Kanban sistemi aynı zamanda yönetim gözetimini azaltmayı ve verimliliği artırmayı da hedefliyordu.

Tahtada çok renkli kartlar ve grafiklere ek olarak bir “çöp kutusu” belirdi, çok büyük görevler buraya gönderildi.

Yetkiliden fotoğraf

Yazılım Sistemlerinde Mühendisliği Sürdürmek için Bir Kanban Sistemi, David J Anderson

Kanban sistemi, akışın düzgün olmayı bıraktığı ve darboğaz olarak adlandırılan gecikmelerin meydana geldiği yerleri açıkça ortaya koydu. Ekiple yapılan hızlı tartışmalar mevcut sorunların belirlenmesine yardımcı oldu. Örneğin testlerin 3 gün sürmesi çıkış tarihini olumsuz etkiledi. Üç çalışan bir araya gelerek süreyi bir güne indirmenin bir yolunu buldu.

Darboğaz, bir şirketin operasyon şemasının veya algoritmasının, kaynak sınırlamalarının veya insanların üretkenliğinin görev akışını keskin bir şekilde azalttığı bir bölümüdür. Çalışan kıtlığı, zayıf internet veya tatilde olan bir yönetici ya da görevlerin tamamlanmasını yavaşlatıyor.

Kanban kartı limitleri ampirik olarak iki kez belirlendi. "Geliştirilmeye hazır" sütununda limitler artırıldı. Ayrıca yeni bir sütun da var - "teste hazır". Aşağı yöndeki taleplerin çoğu yanlış formüle edilmiş ve gereksiz zaman kaybına neden olmuştur. Bu nedenle Başbakan üst akışın çalışmasını inceledi ve hatalar buldu.

İsteklerin işlenmesi 100 gün sürebilir ancak yayınlar planlandığı gibi yine de iki haftada bir yayınlanmaya başladı. Sayının içeriğine ilişkin karar yayınlanmadan 5 gün önce verildi. Microsoft'un XIT departmanında olduğu gibi sayma uygulamaları üretkenlik uğruna terk edildi. Görevler "gecikme maliyetine" veya kaynak kullanılabilirliğine göre önceliklendirildi.

Kanban sistemi yalnızca Anderson'un hedefine ulaşmasına yardımcı olmakla kalmadı, aynı zamanda takımın moralini de iyileştirdi. Ortak tartışmalar ve süreçlerin görünürlüğü sayesinde çalışanların birbirlerine güveni arttı. Personel de sürekli iyileştirme uygulaması olan Kaizen'e katıldı.

Kanban metodolojisi nedir ve görevleri zamanında tamamlamanıza nasıl yardımcı olur?

Sürekli çoklu görev ve çok sayıda müşteri koşullarında, er ya da geç herhangi bir sistem aşırı yüklenir. Teslim tarihleri ​​kaçırılmaya, beklentiler karşılanmamaya ve sistem kaosa dönüşmeye başlıyor. Bugün kanban gibi bir metodolojiyle tanışmayı öneriyorum. Bu yaklaşım, kaynakların etkili bir şekilde tahsis edilmesini ve tüm sorunlarımızın çözülmesini vaat ediyor. Hadi kontrol edelim.

Kanban tarihinin bir anı

Kaban fikrinin temeli Toyoyta Motors tarafından icat edildi. Bir otomobil üreticisi, üretim hattında stok ve kapasitenin hatalı tahsisi nedeniyle ağır kayıplar yaşıyordu. Bazı üretim aşamaları boştayken bazıları aşırı yüklenmiş olabiliyordu.

1959'da hattın tüm bölümlerini dengelemeyi mümkün kılan bir üretim kontrol sistemi önerildi. Temel prensip, her aşamada işçilerin gerekli sayıda parçayı içeren kartları asması ve bunların tüm hat boyunca iletilmesiydi. Üretim hattını takip eden her işçi, bir öncekinden tam olarak kartta kendisine ayrılan parça sayısı kadar parça alıyordu.

Bu şekilde her parçanın bir kartı vardı ve fazlalık olamazdı. Sonuç olarak, alanlardaki stoklar artmadı ve sonraki her işçi tam olarak ihtiyaç duyduğu sayıda parçayı aldı.

Kanban'ın ne olduğunu formüle edelim ve bunu İnternet ürünlerinin geliştirilmesine uygulayalım.

Kanban, üretimin tüm aşamalarında siparişleri iletmek için bilgi kartlarını kullanan bir yalın üretim yönetim sistemidir (Japonca: "sinyal"/"kart"). Basit bir ifadeyle, bir ürünün fikir aşamasından mağaza rafına çıkışına kadar olan tüm yolunu takip ediyoruz.

Yukarıda bir kanban panosu var. Bu, görev durumunu görüntülemek için kullanılan ana araçtır. Ana prensip: Belirli bir görevin üretim sürecinin hangi aşamasında bulunduğunu görüyoruz. Üstelik zaman her alanda takip ediliyor, yani sistemde her zaman “ ” bulabilir ve onlarla çalışabilirsiniz.

Projenizin özelliklerine göre sütun sayısını kendiniz belirlersiniz. Ürününüzün geçtiği ana aşamaların bunlar olması önemlidir. Yukarıdaki örnek, bir çevrimiçi ürünün geçtiği ana aşamaların artı veya eksilerini göstermektedir.

Metodolojinin uygulama alanı oldukça geniştir. Kanban, proje uygulaması, satış yönetimi, üretim hatları, BT geliştirme ve hatta kendi hayatınızı organize etmek için kullanılır.

Okumayı böldüğüm için özür dilerim. Telegram kanalıma katılın. Yeni makale duyuruları, dijital ürünlerin geliştirilmesi ve büyüme hileleri, hepsi orada. Seni bekliyor! Devam edelim...

Kanban ilkeleri

• Görevlerin görsel gösterimi. Tüm görevler kart şeklinde sunulmalı ve tahtaya yansıtılmalıdır. Görevlerin durumunu güncellemek çok önemlidir. Örneğin geliştiriciler kodu hazırlayıp test için gönderdiyse görev kartının uygun sütuna gitmesi gerekir. Böylece herhangi bir ekip üyesi herhangi bir zamanda görevin hangi aşamada olduğunu görebilir.
• Üretimin her aşamasında Devam Eden Çalışma (devam eden iş veya eş zamanlı olarak gerçekleştirilen iş) sütunlarındaki sınırlama. Sistemin er ya da geç görev akışından "boğulmamasını" sağlamak için kısıtlamalar koymak gerekir. Örneğin yukarıdaki Analiz sütununda (analitik) kanban panosunda 2 kişi çalışıyor ve en fazla 2 görevi halledebiliyorlar, daha fazla yüklemenin bir anlamı yok, sistemin sonraki aşamaları boşta kalacağından. Sütun kısıtlamaları ampirik olarak seçilir.
• Tamamlanmamış görevlere odaklanın. Görevlerin olduğu tahtaya bakarken, öncelikle şu veya bu sütunda "asılı" olan görevlere dikkat edin. Aşamalardan biri sizin için en fazla zaman alıyorsa, mümkünse kaynakları yeniden dağıtmayı veya insanları eklemeyi deneyin.
• Devamlı gelişme. Sistemdeki yükü dengelediğinizde tüm süreci takip etmeniz daha kolay olacaktır. Döngü süresini ölçün (görevin ayrı bir sütunda ne kadar süreyle asılı kaldığı ve Yapılacaklar'a girdiği andan Bitti'nin yayınlanmasına kadar geçen süre). Sistemdeki yükleri değiştirin ve tüm aşamaları tamamlamak için gereken süreyi azaltın.
• Detaylara dikkat edin. Örneğin, geliştiricilerin periyodik olarak yazdığı kod testi geçemezse ve revizyon için geri gönderilirse, belki de daha kaliteli bir ürünün test edilmesi için geliştirme kalitesini iyileştirme seçenekleri vardır?

Kanban yaklaşımı idealist görünebilir ancak sizi temin ederim ki ilkeleri sonuç doğurur. Öncelikle metodolojiyi durumunuza uyarlamanız, ardından sistemi cilalamanız gerekiyor.

Kanban araçları

Veya bir kanban panosunun nerede muhafaza edileceği.

• Excel tabloları
• Çıkartmalı tahta
• Bir fantezi daha...

Aslında pek çok seçenek var, Google'da arayabilir ve biraz ilham alabilirsiniz. Önemli olan bu panoya sahip olmanız ve süreçteki tüm katılımcıların şu anda görevlerde neler olduğunu görebilmesidir.

Kanban panolarına örnekler

İşte duvarda asılı olan ve her görevin yapışkan notlara yansıtıldığı bir tahta.

Veya Trello gibi bir bulut hizmeti olabilir.

İşinizde hangi araçların ve seçeneklerin kullanılacağına dair çeşitli görüşler vardır, ancak bu çoğunlukla bir zevk meselesidir. Sadece farklı çözümler deneyin ve en çok beğendiğinize karar verin. Önemli olan kanban kullanmaya başlamak ve mümkün olan en güzel tahtayı kullanma konusunda takılıp kalmamaktır.

Benim fikrim şu: beyin fırtınası yapmak veya vakalar üzerinde çevrimdışı çalışmak için, çıkartmalarla dolu normal bir tahta iyi sonuç verir. Ancak günlük işler için elbette Jira, Kanbantool, Trello vb. gibi bir bulut çözümü kullanmanız gerekir. Bunlarda, tüm ekip görevlere yorum ekleyebilir, bunları sütunlara göre taşıyabilir ve çok daha fazlasını yapabilir.

Nüanslar/düşünceler

İnternet ürünleri hakkında konuşursak, kanban çalışır, yardımcı olur ve gelişir, ancak dikkate alınması gereken bir takım endişeler veya nüanslar vardır.

• Büyük ihtimalle bir sütuna Devam Eden Çalışma limitlerinin getirilmesi proje yönetim ekibini biraz korkutabilir. Sonuçta, bir geliştiricinin veya örneğin bir test uzmanının paralel olarak kaç görevi çözebileceğini nasıl belirleyebilirsiniz? Ya kısıtlamalar getirirsek ve onlar da rahatlarsa?

Görüyorsunuz, eğer bir kişi tam olarak yüklenmemişse, bu kötü bir şey değil. Yapılan işi inceleyip analiz edebilir, eksiklikleri bulup düzeltebilir ve hatta dinlenebilir. Ayrıca, sürecin diğer bölümlerinden (sütunlar) yoldaşlarınıza yardımcı olabilirsiniz; daha fazla ayrıntı aşağıdadır.

• Kanaban gurularına göre sistem, işlevler arası ekiplerde ideal olarak çalışıyor. Şöyle bir şey, yapacak bir şeyin yoksa git bir işçi arkadaşına yardım et. Doğru, geliştiricilerin testçi olabileceği veya tam tersi olabileceği ve sistem mimarının tasarımcıya yardım edeceği bir ekip oluşturmak için çok para harcamanız gerekecek ve buna değer mi?

Elbette ekip üyelerinin birbirlerinden bir şeyler öğrenmesi ve bir şey olması durumunda bir şekilde yardımcı olabilmeleri harika bir şey. Ancak bu koşulun sağlanabilmesi için tercihen yakınlarda oturan ve sürekli iletişim halinde olan küçük ekiplerin olması gerekiyor. Büyük projelerde bu tür bir deneyim alışverişini yeniden oluşturmak zordur.

Bu nedenle, eğer sessiz bir anım varsa, becerilerimi geliştirme eğilimindeyim. Ne yaptığınıza bakın, onu nasıl geliştirebileceğinizi düşünün, faydalı makaleler okuyun. İnsan, taşıma bandının dişlisi değil, yaşayan bir organizmadır.

Toplam

Kanban metodolojisine baktık ve umarım artık bunu projenizde nasıl uygulayacağınızı anlamışsınızdır. Süreçlerinizi ana aşamalara ayırmaya ve edinilen bilgilere göre sistemi optimize etmeye çalışın.