Hikaye gerçek, her şeyi kendi gözlerimle gördüm.
Birkaç yıl boyunca çoğunuz gibi bir adam programcı olarak çalıştı. Her ihtimale karşı şu şekilde yazacağım: "programcı." Çünkü o 1Snik'ti, sabit bir yapım şirketinde çalışıyordu.
Bundan önce farklı uzmanlıkları denedi - Fransa'da 4 yıl programcı, proje yöneticisi olarak çalıştı, aynı zamanda yönetim ve küçük bir satış yapmak için projenin bir yüzdesini alırken 200 saati tamamlamayı başardı. Kendi başıma ürünler geliştirmeye çalıştım, 6 bin kişilik büyük bir şirkette BT departmanının başındaydım, alıntı mesleğim olan 1C programcısını kullanmak için farklı seçenekler denedim.
Ancak tüm bu pozisyonlar, öncelikle gelir açısından bir şekilde çıkmazdaydı. O zamanlar hepimiz hemen hemen aynı parayı alıyorduk ve aynı şartlarda çalışıyorduk.
Bu adam, satmadan veya kendi işini kurmadan nasıl daha fazla para kazanabileceğini merak ediyordu.
Kendini akıllı bir adam olarak görüyordu ve çalıştığı şirkette kendine uygun bir yer bulmaya karar verdi. Bu nişin kimsenin işgal etmediği özel bir şey olması gerekiyordu. Ve şirketin kendisinin bu nişteki bir kişiye para ödemek istemesini istedim, böylece kimseyi kandırmaya veya hiçbir şeyi aldatmaya gerek kalmayacaktı. Bu hedefi gerçekleştirmek için: Bu pozisyondaki bir kişiye çok miktarda para ödenmesi gerekiyor. Tek kelimeyle eksantrik.
Arama kısa sürdü. Bu adamın çalıştığı şirkette "iş süreçlerinde işleri düzene koymak" denebilecek tamamen özgür bir niş vardı. Her şirketin birçok sorunu vardır. Bir şeyler her zaman yolunda gitmiyor ve gelip iş sürecini düzeltecek kimse yok. Bu nedenle, sahibinin iş süreçlerindeki sorunlarını çözmesine yardımcı olabilecek bir uzman olarak kendisini denemeye karar verdi.
O dönemde altı aydır şirkette çalışıyordu ve piyasadaki ortalama maaşı alıyordu. Kaybedecek hiçbir şeyi yoktu, özellikle de aynı işi bir hafta içinde kolaylıkla bulabileceği için. Genel olarak bu adam, aniden hiçbir şey yolunda gitmezse kötü bir şey olmayacağına karar verdi ve kovuldu.
Cesaretini toplayıp sahibinin yanına geldi. Ben kendisine işin en sorunlu sürecini iyileştirmesini önerdim. O zamanlar depo muhasebesiydi. Artık bu şirkette çalışan herkes bu sorunları hatırlamaktan bile utanıyor, ancak üç ayda bir yapılan stoklar, muhasebe sistemi ile fiili bakiyeler arasında yüzde onlarca tutarsızlıklar gösterdi. Ve maliyet, miktar ve pozisyon sayısı açısından. Bu bir felaketti. Şirket aslında muhasebe sisteminde yılda yalnızca dört kez, envanter sayımından sonraki gün doğru bakiyeye sahipti. Adamımız bu süreci düzene koymaya başladı.
Adam, envanter sonuçlarındaki sapmaları yarı yarıya azaltması gerektiği konusunda mal sahibiyle anlaştı. Üstelik sahibinin kaybedecek özel bir şeyi yoktu, çünkü kahramanımızdan önce çeşitli işçiler her şeyi düzeltmek için girişimlerde bulunmuşlardı ve genel olarak görev pratik olarak çözülemez olarak görülüyordu. Bütün bunlar ilgiyi büyük ölçüde artırdı, çünkü her şey yolunda giderse, o zaman adam otomatik olarak işleri nasıl düzene koyacağını ve çözülemeyen sorunları nasıl çözeceğini bilen bir kişi haline gelecektir.
Böylece, envanter sonuçlarına dayalı sapmaları bir yıl içinde 2 kat azaltmak gibi bir görevle karşı karşıya kaldı. Projenin başlangıcında bunu nasıl başaracağı hakkında hiçbir fikri yoktu ancak depo muhasebesinin basit bir şey olduğunu ve dolayısıyla yine de faydalı bir şeyler yapabileceğini anlamıştı. Üstelik sapmaları yüzde onlardan yüzde onlara düşürmek o kadar da zor görünmüyor. Danışmanlık veya benzeri faaliyetlerde çalışmış olan herkes, süreç sorunlarının çoğunun oldukça basit adımlarla çözülebileceğini bilir.
Ocak ayından mayıs ayına kadar bir şeyler hazırladı, biraz otomatikleştirdi, depo muhasebesi iş sürecini yeniden yazdı, mağaza sahiplerinin, muhasebecilerin iş akışlarını değiştirdi ve genel olarak kimseye hiçbir şey göstermeden veya söylemeden tüm sistemi yeniden yaptı. Mayıs ayında herkese yeni talimatlar dağıttı ve yılın ilk envanterinin ardından kendi kurallarına göre çalışarak yeni bir hayat başladı. Sonuçları gözlemlemek için gelecekte şirket, iki ayda bir olmak üzere daha sık stok yapmaya başladı. Zaten ilk sonuçlar olumluydu ve yıl sonuna gelindiğinde denetim sonuçlarından sapmalar yüzde birin çok altına düştü.
Başarı muazzamdı ama sürdürülebilirliğine inanılamazdı. Adam, kenara çekilip süreci gözlemlemeyi bırakırsa sonucun korunacağından şüpheliydi. Yine de bir sonuç vardı ve adam, sahibiyle üzerinde anlaştığı her şeyi aldı. Ardından, birkaç yıl sonra sonucun istikrarı doğrulandı - birkaç yıl boyunca sapmalar% 1 dahilinde kaldı.
Daha sonra deneyi tekrarlamaya karar verdi ve sahibine başka bir sorunlu süreci (tedarik) iyileştirmesini önerdi. Müşterilerimizin istediği hacimlerde sevkiyat yapmamıza izin vermeyen eksiklikler vardı. Bir yıl içinde açıkların yarıya indirileceği ve adamın ayrıca çeşitli iş süreçlerini ve diğer sapkınlıkları otomatikleştirmek için 10C ile ilgili 15-1 projeyi tamamlayacağı konusunda anlaştık.
İkinci yılda yine her şey başarıyla tamamlandı, açıklar 2 kattan fazla azaldı, tüm BT projeleri başarıyla tamamlandı.
Maaş, bu adamın iki yıl boyunca tüm ihtiyaçlarını zaten tam olarak karşıladığı için, biraz yerleşmeye, sakinleşmeye ve kendisi için yarattığı rahat, sıcak bir yere oturmaya karar verdi.
Nasıldı? Resmi olarak BT direktörüydü. Ama gerçekte kim olduğunu anlamak zor. Sonuçta bir BT yöneticisi ne yapar? Kural olarak BT altyapısını yönetir, sistem yöneticilerini yönetir, ERP sistemini uygular ve yönetim kurulu toplantılarına katılır.
Ve bu arkadaşın değişim süreçlerine katılma konusunda temel sorumluluklarından biri vardı ve esas olarak bu süreçlerin oluşturulması, başlatılması, çözümlerin araştırılması ve önerilmesi, yeni yönetim tekniklerinin uygulanması, önerilen değişikliklerin incelenmesi, diğer fonksiyonların etkinliğinin analizi ve bölümler ve son olarak, tüm şirket için bir stratejik planın bağımsız olarak geliştirilmesine kadar işletmenin stratejik gelişimine doğrudan katılım.
Kendisine sınırsız yetki verildi. Daha önce erişiminin olmadığı herhangi bir toplantıya gelebilirdi. Orada bir not defteriyle oturdum, bir şeyler yazdım ya da sadece dinledim. Nadiren konuşurdu. Daha sonra çağrışımsal hafızanın bu şekilde daha iyi çalıştığını iddia ederek telefonla oynamaya başladı.
Toplantıda nadiren yararlı bir şey verdi. Gitti, düşündü, sonra ya eleştiriyle, ya görüşle, ya önerilerle ya da daha önce uyguladığı çözümlerin açıklamasını içeren bir mektup geldi.
Ancak daha sık olarak toplantıları kendisi düzenlerdi. Bir sorun buldum, çözüm ürettim, ilgili tarafları belirledim ve herkesi toplantıya getirdim. Ve sonra - elinden geldiğince. İkna etti, motive etti, kanıtladı, savundu, başardı.
Gayri resmi olarak, şirket sahibi ve yöneticisinden sonra şirketteki üçüncü kişi olarak kabul ediliyordu. Elbette 4 numaradan başlayarak tüm “şirket insanlarını” fena halde çileden çıkardı. Özellikle yırtık kot pantolonu ve parlak tişörtleriyle ve ayrıca sahip olarak geçirdiği zamanla.
Sahibi ona günde 1 saat verdi. Her gün. Sorunları, çözümleri, yeni işleri, gelişim alanlarını, göstergeleri ve verimliliği, kişisel gelişimi, kitapları, kısacası hayatı konuştular, tartıştılar.
Ama bu adam tuhaftı. Sanki arkanıza yaslanın ve mutlu olun, hayat güzel. Ama hayır. Düşünmeye karar verdi.
Merak etti: Neden bu onun işine yaradı da diğerleri başaramadı? Sahibi de onu itti: Başkalarının da düzeni yeniden sağlayabilmesini istediğini söyledi, çünkü çok sayıda yönetici var, kural olarak operasyonel yönetim ve stratejik planlamayla ilgileniyorlar, ancak pratikte hiç kimse sistemik değişikliklerle meşgul değil onların süreçlerinde. Görev tanımlarında süreçlerini hızlandırmaları, verimliliği artırmaları gerektiği yazıyor olabilir ama aslında bunu yapan kimse yok. Nedenmiş? Adam da bunun nedenini merak etti ve tüm bu yöneticilerle konuşmaya gitti.
Kaliteden sorumlu müdür yardımcısına geldi ve ürünlerin Japonlardan daha iyi olması için Shewhart kontrol çizelgelerinin tanıtılmasını önerdi. Ancak meslektaşının Shewhart kontrol çizelgelerinin ne olduğunu, istatistiksel süreç kontrolünün ne olduğunu bilmediği ve yalnızca kalite yönetiminde Deming döngüsünün kullanımını duyduğu ortaya çıktı. TAMAM…
Başka bir müdür yardımcısına giderek kontrolün getirilmesini önerdi. Ama burada da destek bulamadım. Kısa bir süre sonra sınır yönetimini (sınır yönetimi) öğrendi ve süreçleri iyileştirmek için tüm müdür yardımcılarına bu metodolojinin sistemik kısmını uygulamasını önerdi. Ama adamımız ne kadar konuşursa konuşsun, hiç kimse konunun neyle ilgili olduğunu derinlemesine araştırmak istemedi. Belki ilgilenmiyorlardı ya da çok zordu. Ama aslında kimse bunu anlamadı.
Genel olarak şirkette bildiği ve kullandığı her şeyden bahsetti. Ama kimse onu anlamadı. Örneğin depo muhasebesinde her şeyin neden düzeltildiğini ve kontrol ve sınır yönetiminin bununla ne ilgisi olduğunu hala anlamıyorlar.
Son olarak programcılarına ulaştı; kadroda 3 kişi vardı. Sınır yönetiminden, kontrolden, kalite yönetiminden, çeviklikten ve scrum'dan bahsetti... Ve şaşırtıcı bir şekilde her şeyi anladılar ve hatta teknik ve metodolojik incelikler de dahil olmak üzere onunla bir şekilde tartışabildiler. Depo ve tedarik projelerinin neden işe yaradığını anladılar. Ve sonra adamın aklına geldi: Aslında programcılar dünyayı kurtaracak.
İş süreçlerini normal şekilde ve gerekli ayrıntılarla anlayabilenlerin yalnızca programcılar olduğunu fark etti.
Neden onlar? Aslında hiçbir zaman net bir cevap bulamadı. Sadece tez ipuçlarını formüle ettim.
Öncelikle programcılar işin konu alanlarını biliyorlar ve bunları şirketteki diğer tüm insanlardan daha iyi biliyorlar.
Ayrıca programcılar süreç algoritmasının ne olduğunu gerçekten anlıyorlar. Bu önemlidir çünkü iş süreçleri birer algoritmadır ve bunların içindeki öğeler tutarlı olmayabilir. Örneğin adamın üzerinde çalıştığı satın alma sürecinde ilk adım yıllık satın alma planı oluşturmak, ikincisi ise günlük satın almaydı. Bu adımlar doğrudan bir bağlantıyla birbirine bağlanmıştır, yani insanların bu algoritmaya göre çalışması gerektiği - yıllık bir satın alma planı hazırlaması ve talebi hemen yerine getirmesi gerektiği varsayılmaktadır. Yıllık satın alma planı yılda bir kez hazırlanmakta olup, günde 50 kez başvuru alınmaktadır. Algoritmanın bittiği yer burasıdır ve üzerinde çalışmanız gerekir. Aslında, programcılar için algoritma bilgisinin bir rekabet avantajı olduğunu, çünkü bunlara aşina olmayan herhangi birinin bir iş sürecinin nasıl çalışması gerektiğini ve nasıl temsil edilebileceğini anlamadığını düşündü.
Adama göre programcıların bir diğer avantajı da yeterli boş zamanlarının olması. Hepimiz bir programcının bir göreve gerçekte ihtiyaç duyduğundan üç kat daha fazla zaman harcayabileceğini biliyoruz ve çok az kişi bunu fark edecek. Bu yine bir rekabet avantajıdır, çünkü bazı iş süreçlerini düzene koymak için çok fazla boş zamana sahip olmanız gerekir - düşünün, gözlemleyin, çalışın ve deneyin.
Adama göre çoğu yöneticinin bu kadar boş vakti yok ve bundan gurur duyuyor. Aslında bu, bir kişinin verimliliği artırmak için zamanı olmadığı için etkili olamayacağı anlamına gelse de - bir kısır döngü. Bizim kültürümüzde meşgul olmak moda olduğundan her şey aynı kalır. Ve biz programcılar için bu bir avantajdır. Boş zaman bulabilir ve her şeyi düşünebiliriz.
Programcıların bir bilgi sistemini hızla değiştirebileceğini söyledi. Bu her işletmede geçerli değil ama çalıştığı her yerde istediği değişikliği yapabiliyordu. Özellikle de başkasının işiyle ilgilenmiyorlarsa. Örneğin, kullanıcı eylemlerini gizlice ölçecek bir sistem başlatabilir ve daha sonra bu bilgiyi aynı muhasebe departmanının verimliliğini analiz etmek ve muhasebe maliyetini takip etmek için kullanabilir.
Ve onun sözlerinden hatırladığım son şey, programcıların büyük miktarda bilgiye erişebildiğidir, çünkü... Sisteme yönetici erişimine sahip olmak. Dolayısıyla bu bilgiyi analizlerinde kullanabilirler. Normal bir tesisteki hiç kimsenin böyle bir kaynağı yoktur.
Ve sonra gitti. Zorunlu iki haftalık gözaltı süresi boyunca, yaptığı işe devam etmek istediğimiz için deneyimlerini paylaşmaya zorladık. Neyse, pozisyonu boşaldı.
Birkaç gün boyunca onu bir sandalyeye oturttular, kamerayı açtılar ve monologlarını kaydettiler. Tamamlanan tüm projeleri, yöntemleri, yaklaşımları, başarıları ve başarısızlıkları, nedenleri ve sonuçlarını, yöneticilerin portrelerini vb. anlatmamızı istediler. Özel bir kısıtlama yoktu çünkü Kafasından neler geçtiğini bilmiyorlardı.
Monologların çoğu elbette saçmalık ve kahkahalardan oluşuyordu; harika bir ruh halindeydi çünkü St. Petersburg'a gitmek üzere taşradan ayrılıyordu. St. Petersburg'da çalışmak için nereye gitmelisiniz? Elbette Gazprom'a.
Ancak monologlarından faydalı bir şeyler çıkarmayı başardık. Size hatırladıklarımı anlatacağım.
İşte bu adamın tavsiyeleri. İş süreçlerinde işleri düzene koymaya çalışmak isteyenler için.
Bu tür işleri yapabilmek için öncelikle belli bir düzeyde “donma”ya sahip olmanız gerekir. İşinizi kaybetmekten korkmamalı, risk almaktan korkmamalı, meslektaşlarınızla çatışmalardan korkmamalısınız. Onun için kolaydı çünkü şirkette henüz altı ay çalıştığı, kimseyle iletişime geçecek zamanı olmadığı ve buna niyeti olmadığı bir dönemde yolculuğuna başlamıştı. İnsanların gelip gittiğini anlamıştı ama kendi sonuçları ve işletme sahibi tarafından yapılan değerlendirmeler onun için önemliydi. O zamanlar meslektaşlarının ona iyi mi yoksa kötü mü davrandığı onu pek ilgilendirmiyordu.
İkinci nokta ise bu işi etkili bir şekilde yapabilmek için maalesef ders çalışmanız gerekecek. Ancak MBA için değil, kurslarda, enstitülerde değil, kendi başınıza çalışın. Örneğin bir depoya yönelik ilk projesinde sezgisel davrandı, "kalite yönetimi"nin ne olduğu dışında hiçbir şey bilmiyordu.
Verimliliği artırmaya yönelik yöntemlerin neler olduğuna dair literatürü okumaya başladığında kullandığı teknolojileri keşfetti. Adam bunları sezgisel olarak uyguladı, ancak bunun onun icadı olmadığı ortaya çıktı, her şey zaten uzun zaman önce yazılmıştı. Ancak zaman harcadı ve doğru kitabı hemen okumuş olmasından çok daha fazlasını. Burada yalnızca belirli bir tekniği incelediğinizde, bunlardan hiçbirinin, hatta en gelişmişinin bile bir iş sürecinin tüm sorunlarını tamamen çözemeyeceğini anlamak önemlidir.
İkinci püf nokta ise ne kadar çok teknik bilirseniz o kadar iyidir. Örneğin, eski Japonya'da, en ünlü kılıç ustalarından biri olan ve iki kılıç stilinin yazarı Miyamoto Musashi yaşıyordu. Bir okulda bir ustanın yanında okudu, sonra Japonya'yı dolaştı, farklı adamlarla kavga etti. Adam daha güçlüyse yolculuk bir süreliğine durdu ve Musashi öğrenci oldu. Sonuç olarak, birkaç yıl içinde farklı ustaların çeşitli uygulamalarının becerilerini edindi ve kendine ait bir şeyler ekleyerek kendi okulunu kurdu. Sonuç olarak eşsiz bir beceriye ulaştı. Burada da durum aynı.
Elbette iş danışmanı olarak hareket edebilirsiniz. Genel olarak harika adamlardır. Ancak kural olarak bir çeşit metodoloji getirmek için geliyorlar ve işin ihtiyaç duyduğu yanlış metodolojiyi uyguluyorlar. Öyle üzücü durumlarımız da oldu ki, kimse sorunun nasıl çözüleceğini bilmiyor ve kimse nasıl çözüleceğini düşünmek istemiyor. İnternetten aramaya başlıyoruz ya da bir danışmanı arayıp bize neyin yardımcı olabileceğini soruyoruz. Danışman, kısıtlamalar teorisini tanıtmamız gerektiğini düşünüyor ve söylüyor. Tavsiyesi için ona para ödüyoruz, uygulamaya para harcıyoruz ama sonuç sıfır.
Bu neden oluyor? Çünkü danışman şunu şöyle bir sistem getiriyoruz dedi ve herkes onunla hemfikir oldu. Harika, ancak tek bir metodoloji, tek bir iş sürecinin bile tüm sorunlarını kapsamaz, özellikle de başlangıçtaki önkoşullar - bizim önkoşullarımız ve metodolojiyi uygulamak için gerekenler - örtüşmüyorsa.
Adamın önerdiği uygulamada en iyiyi alıp en iyiyi uygulamanız gerekiyor. Yöntemleri tamamen ele almayın, temel özelliklerini, özelliklerini ve uygulamalarını alın. Ve en önemli şey özü anlamaktır.
Örneğin Scrum veya Agile'ı alın dedi. Adam monologlarında herkesin Scrum'ın özünü tam olarak anlamadığını defalarca tekrarladı. Ayrıca Jeff Sutherland'ın bazılarının "hafif okuma" bulduğu kitabını da okudu. Bu ona derin bir okuma gibi geldi çünkü Scrum'ın temel ilkelerinden biri kalite yönetimidir, bu doğrudan kitapta yazılıdır.
Toyota Üretimi hakkında, Jeff Sutherland'ın Scrum'ı Japonya'da nasıl gösterdiği, orada nasıl kök saldığı ve onların felsefesine ne kadar yakın olduğu hakkında konuşuyor. Ve Sutherland, Scrum Master'ın rolünün öneminden, Deming döngüsünden bahsetti. Scrum Master'ın rolü süreci sürekli hızlandırmaktır. Scrum'daki diğer her şey - aşamalı teslimat, müşteri memnuniyeti, sprint dönemi için net bir iş listesi - de önemlidir, ancak tüm bunların giderek daha hızlı ilerlemesi gerekir. İşin hızı, ölçüldüğü birimlerde sürekli olarak artmalıdır.
Belki de bu bir çeviri meselesidir, çünkü kitabımız “Scrum - devrim niteliğinde bir proje yönetimi yöntemi” olarak çevrilmiştir ve İngilizce başlık tam anlamıyla tercüme edilirse şu ortaya çıkacaktır: “Scrum - yarı zamanda iki kat daha fazla” yani, ismi Scrum'ın temel bir fonksiyonu olarak hızı ifade etmektedir.
Bu adam Scrum'ı uyguladığında, hiçbir önemli değişiklik olmadan ilk ayda hız iki katına çıktı. Değişim için noktalar buldu ve Scrum'ın kendisini çok daha hızlı çalışacak şekilde değiştirdi. İnternette yazdıkları tek şey şu soruyla karşı karşıya kaldıkları: "Hızı iki katına çıkardık, geriye bu kadar hızla ne yaptığımızı anlamak mı kalıyor?" Ancak bu tamamen farklı bir alan...
Ayrıca kişisel olarak birkaç teknik önerdi. Bunları temel ve temel olarak adlandırdı.
Birincisi sınır yönetimidir.
Bunu Skolkovo'da öğretiyorlar, adama göre başka kitap ve materyal yok. Bir şekilde, sınır yönetimi üzerine vaaz veren Harvard'lı bir profesörün konferansına katılacak ve ayrıca Harvard Business Review'da Eric Trist'in çalışmaları hakkında birkaç makale okuyacak kadar şanslıydı.
Sınır yönetimi, sınırları görebilmeniz ve sınırlarla çalışabilmeniz gerektiğini söylüyor. Çok sayıda sınır var ve bunlar her yerde; departmanlar arasında, farklı iş türleri arasında, işlevler arasında, operasyonel ve analitik çalışma arasında. Sınır yönetimi bilgisi daha yüksek gerçekleri açığa çıkarmaz, ancak gerçekliği biraz farklı bir ışıkta, sınırlar prizmasından görmemizi sağlar. Ve buna göre onları yönetin; gerektiğinde onları dikin ve yolunuza çıktıkları yerden kaldırın.
Ancak çoğu zaman adam kontrol etmekten bahsediyordu. Bu konuyla ilgili bir çeşit tuhaflığı vardı.
Kontrol etmek kısaca sayıya dayalı yönetimdir. Burada tanımın her parçasının önemli olduğunu söyledi; hem “yönetim” hem de “bazlı” ve “sayılar”.
Biz, kontrolün üç bileşeninde de kötü olduğumuzu söyledi. Özellikle hem birbirleriyle hem de iş sisteminin diğer bölümleriyle yakından bağlantılı oldukları göz önüne alındığında.
Kötü olan ilk şey sayılardır. Bunlardan çok az var ve kalitesiz.
Daha sonra sayıların önemli bir bölümünü 1C bilgi sisteminden aldık. Yani iddia ettiği gibi 1C'deki sayıların kalitesi iyi değil. En azından verileri geriye dönük olarak değiştirebilme yeteneği nedeniyle.
Bunun 1C geliştiricilerinin hatası olmadığı açıktır - yalnızca pazarın gereksinimlerini ve yerel muhasebe zihniyetini dikkate alırlar. Ancak kontrol amacıyla, 1C'nin belirli bir kuruluştaki verilerle çalışma ilkelerini değiştirmek daha iyidir.
Ayrıca, ona göre 1C'den gelen sayılar, örneğin Excel kullanılarak yarı manuel işleme tabi tutuluyor. Bu tür işlemler aynı zamanda veriye kalite ve verimlilik katmaz.
Sonunda, yanlışlıkla hatalı rakamları yöneticiye göndermemek için başka biri nihai raporu iki kez kontrol eder. Sonuç olarak rakamlar alıcıya güzel, doğrulanmış ama çok geç ulaşıyor. Genellikle - dönemin bitiminden sonra (ay, hafta vb.).
Ve burada her şeyin çok basit olduğunu söyledi. Ocak ayına ilişkin rakamlar size Şubat ayında geldiyse artık Ocak ayı faaliyetlerini yönetemezsiniz. Çünkü Ocak ayı çoktan bitti.
Ve eğer rakamlar muhasebeye dayanıyorsa ve şirket üç ayda bir KDV beyanı sunan en sıradan şirketse, o zaman yöneticisi çeyrekte bir nispeten yeterli rakamları alır.
Gerisi açık. Ayda bir kez numara alırsınız - yılda 12 kez numaralara göre yönetme (yani kontrol) fırsatına sahipsiniz. Üç ayda bir raporlama yaparsanız yılda 4 kez yönetirsiniz. Artı bir bonus - yıllık raporlama. Bir kez daha yönlendirin.
Geri kalan zamanlarda kontrol genellikle körü körüne gerçekleştirilir.
Rakamlar ortaya çıktığında (ve ortaya çıkarsa), o zaman ikinci sorun devreye giriyor: rakamlara göre nasıl yönetilecek? Onun mantığının bu noktasına katılamıyordum.
Adam, yöneticinin daha önce sayılara sahip olmaması durumunda görünümlerinin vay etkisi yaratacağını savundu. Rakamlara şöyle bakıp çarpıtacak, insanları halıya çağıracak, açıklama ve soruşturma talep edecek. Rakamlarla oynadıktan, analizler yaptıktan ve tüm çalışanlara “artık sizden kurtulmayacağım” diye tehditkar bir şekilde söz verdikten sonra yönetici çok çabuk sakinleşecek ve bu konudan vazgeçecektir. Aracı kullanmayı bırakın. Ama sorunlar devam edecek.
Bunun, yetersiz yönetim becerileri nedeniyle gerçekleştiğini söyledi. Her şeyden önce kontrolde. Yönetici bu sayılarla ne yapacağını bilmiyor. Ne сyapılacak - ne yapılacağını biliyor - hayır. Yapmak yukarıda yazılanlardır (kavga etmek, oynamak). Yapmak günlük bir iş sürecidir.
Her şeyin çok basit olduğunu savundu: Dijitalin iş sürecinin bir parçası olması gerekiyor. İş sürecinde açıkça açık olmalıdır: rakamlar normdan saparsa kim neyi ve ne zaman yapmalı (herhangi bir seçenek - sınırın üstünde, sınırın altında, koridorun ötesine geçme, bir eğilimin varlığı, beklentilerin karşılanamaması) niceliksel vb.)
Ve böylece temel ikilemi özetledi: sayı mevcut, yönetim verimliliğini artırmak için iş sisteminin bir parçası haline gelmeli, ancak... bu gerçekleşmiyor. Neden?
Çünkü Rusya lideri gücünün bir parçasını bile rakibine kaptırmayacak.
Rus yöneticinin rakipleri - yüksek kaliteli ve çalışan bir iş süreci, iyi düşünülmüş karşılıklı yarar sağlayan motivasyon ve uygun otomasyon - ne yazık ki yöneticiyi işsiz bırakacak.
Biraz saçma, sence de öyle değil mi? Özellikle liderler konusunda. Tamam, sana söyledim, kendin karar ver.
Bence biraz daha az ama yine de çok fazla Scrum'dan bahsetti.
Mutlaka Scrum'ı okuyun ve pratikte deneyin dedim. Eğer okuduysanız ama denemediyseniz kendinizi cahil sayın diyor. İnternetteki makaleler ve her türlü rehber (ne oluyor?) yerine, örneğin Sutherland'ın bir kitabını okumak daha iyidir.
Scrum'ın yalnızca uygulama yoluyla ve yapılan iş miktarının zorunlu ölçümüyle öğrenilebileceğini söyledi. Kişisel olarak en önemli iki rolü deneyin: Ürün Sahibi ve Scrum Master.
Adama göre, sprint kaynaklarını ve maliyetini artırmadan sprint başına tamamlanan görev hacmini artırabildiğinizde, Scrum Master rolünü pratikte deneyimlemek özellikle önemlidir.
Tepesinde TOS (sistem sınırlamaları teorisi) vardı.
Adama göre bunlar, hemen hemen her alanda, herhangi bir iş sürecinde ve bir bütün olarak iş sisteminde uygulanabilecek verimliliği artırmanın temel, temel ilkeleridir.
TOS'a aşina olmadığımızı öğrendiğinde bize anlatmayı bıraktı. Bizi Eliyahu Goldratt'ın kitaplarını okuma zevkinden mahrum bırakmayacağını da sözlerine ekledi. Scrum'a da benzer bir öneride bulundu: okuyun ve deneyin. Mesela hangi pozisyonda olursanız olun, hangi işi yaparsanız yapın, TOC yöntemlerini kullanarak verimliliği artırabileceğiniz bir yer var.
Sonra görünüşe bakılırsa teknik çantası kurudu ve şöyle dedi: Belirli bir durumda uygulamalı çözümler yaratmak için ilkeleri karıştırın.
Bunun ana öneri, başarının anahtarı olduğunu söylüyor. İlkeleri, özü anlayın ve benzersiz uygulama çözümleri (iş süreçleri ve iş sistemleri) yaratın.
Sonra bir alıntıyı hatırlamaya çalıştı ve sonunda internete girmek zorunda kaldı. Eliyahu Goldratt'ın "Devlerin Omuzlarında Durmak" başlıklı makalesinden bir alıntı olduğu ortaya çıktı:
“Uygulamalı çözümler (uygulamalar) ile bu çözümlerin dayandığı temel kavramlar arasında fark var. Kavramlar geneldir; uygulamalı çözümler ise kavramların belirli bir ortama uyarlanmasıdır. Daha önce de gördüğümüz gibi bu tür bir uyarlama basit değildir ve çözümün belirli unsurlarının geliştirilmesini gerektirir. Bir uygulama çözümünün belirli bir ortam hakkındaki ilk varsayımlara (bazen gizli) dayandığını unutmamalıyız. Bu uygulama çözümünün, varsayımların doğru olmadığı bir ortamda çalışması beklenmemelidir.”
Bir programcının ve bir "iş süreci iyileştiricinin" çalışmalarının çok benzer olduğunu söyledi. Ve sol.
Kaynak: habr.com