Birçok yönetici sadece ürün geliştirme süreçlerini iyileştirerek veya yeni araçlar/yöntemler kullanarak daha iyi ürünler yaratabileceklerini düşünmektedir. Ancak başarılı ürünleri yaratan süreçler değil insanlardır.

Ürün geliştirme yeteneklerini iyileştirmek istediklerini söyleyen şirketleri sık sık ziyaret ediyoruz. Yalın ilkelerin ve uygulamaların bir taraftan inovasyon yeteneklerini geliştirirken, diğer taraftan maliyeti azaltıp kaliteyi nasıl artıracağını öğrenmek istiyorlar. İnsan kaynaklarının geliştirme yaklaşımları hakkında bilgi aldığımızda çoğu zaman bir ürün geliştirme başkan yardımcısının ağzından dökülen “Elbette, insanlar en değerli varlıklarımızdır. Bu nedenle en iyi üniversitelerdeki en iyi insanları işe alıyor ve yollarından çekiliyoruz” sözlerine benzer cevaplar alıyoruz.

Ancak insan geliştirme başlığı altında çoğu şirketin aslında yaptığı şey yıllık eğitim saati hedeflerine ulaşmak ve çalışanları konferanslara göndermek için bütçe ayırmaktan ibaret. Eğer yöneticiler gerçekten insanların en iyi varlıkları ve inovasyonu mümkün kılan şeyin çalışanlarının enerji ve yaratıcılığı olduğunu düşünüyorlarsa neden yukarıda bahsedilenlerin ötesine gitmiyorlar? Neden insanları büyütmek ve geliştirmek, yeni üretim ekipmanlarını veya bulut tabanlı iş birliği teknolojisini devreye sokmak kadar heyecanlandırmıyor?

Geçtiğimiz yirmi yılda üretim üzerine çalışarak operasyonel mükemmelliğe süreçler üzerinde sadece “yalın” uygulayarak ulaşılmadığını öğrendik. Operasyonel mükemmelliğe ulaşmak için her şeyden önce tüm çalışanlarda sürekli iyileştirme için beklenti oluşturmak ve doğal yeteneklerini geliştirmek gerekiyor. Benzer şekilde yalın ürün geliştirmeyi çalışarak, süreçlerin değil insanların başarılı ürünler geliştirdiğini öğrendik. Geliştirme sürecinde yapılan iyileştirmelerin daha iyi ürünlerle sonuçlanacağını düşünen yöneticilerle sık sık karşılaşıyoruz. Ancak daha iyi ürünler yoktan var olmuyorlar. Başarılı ürünler iyi tasarım süreçleriyle bezenmiş iyi bilgiye sahip geliştiriciler tarafından yaratılmaktadır.

Nihai tasarım; ürün, üretim ve tedarik zinciri özellikleri dahil olmak üzere birbirine bağlı karmaşık teknik kararlar ağının bir ürünüdür. Problemlerin nasıl formüle edildiğinden fikirlerin seçimine ve sınırların müzakeresinden prototiplerin test edilmesine kadar, geliştiricilerin karar verme sürecinde birbiriyle olan iletişimleri ürünü asıl şekillendiren şeydir. Üretim ve muhasebe gibi alışverişin daha ağır bastığı sistemlerde iyi süreçler genelde iyi sonuçlar vermektedir. Yalın ürün geliştirmede önemli olan doğru adımların takip edilmesi değil işin nasıl yapıldığıdır. Hatta şirketlerin “iyi” süreçleri takip ettiği ancak berbat sonuçlar aldığı birçok örnek bulunmaktadır. Yöneticilerin doğal tepkisi süreci suçlamak, daha fazla örnek uygulama yapmak ve kontrol noktalarının sayısı ile sıklığını artırmak oluyor. Organizasyonlar ve liderler insanları merkezde görmedikçe ürün geliştirme sürecindeki iyileştirme çabalarının hiçbir şeyi iyileştirmeme ihtimali oldukça yüksektir.

“Yalın ürün geliştirme” terimi görece yeni ancak altındaki ilkeler otuz seneyi aşkın süredir bilinmektedir. 1980’lerde MIT’de gerçekleştirilen bir çalışmada Japon otomotiv şirketlerinin; fabrikadan yeni ürün geliştirmeye, ürün geliştirmeden tedarik zincirine takip ettikleri uygulamaların diğer otomotiv üreticilerinin uygulamalarından son derece farklı olduğu gözlendi. Araştırmacılar Japon yaklaşımının verimliliğini “Yalın” olarak anmaya başladılar. Devam niteliğinde gerçekleştirilen araştırmada ise özellikle Toyota’nın ürün geliştirme uygulamaları üzerine yoğunlaşıldı ve Kuzey Amerikalı rakipleri ile karşılaştırıldı. Şirketler araştırmayı diğer alanlara uyguladıkça yalın geliştirme hakkındaki bilgi derinleşti. Ancak insanların kritik rolü göz ardı edilmiş gibi duruyor.

Araştırma Hakkında

Bu makale geçtiğimiz yirmi yılda yalın üretim ve yalın ürün geliştirme hakkındaki kolektif araştırma ve tecrübelerimizin sonucudur. İkimiz (Morgan ve Sobek) doktora tezimizi Toyota’nın ürün geliştirme sistemi üzerine gerçekleştirmiştik. Bu çalışma mevcut yalın ürün geliştirme modellerindeki temel fikirlere yön vermiştir. Ardından Morgan, Ford’da küresel mühendis direktörü olarak görev yaptığı sırada Mazda ile olan işbirliği sayesinde yalın ürün geliştirme algısını ve bilgisini derinleştirerek Ford’un ürün geliştirme yeteneklerini dönüştürmüştür. Sobek ise akademik ve endüstriyel alanlardaki deney ve gözlemleriyle kavram geliştirmeye devam etmiştir. Üçüncü yazarımız (Balle) doktora araştırmasının bir bölümünü Toyota’nın kilit bir tedarikçisiyle olan işbirliği, üretim süreci ve ürün tasarımı üzerine yapmıştır. Birçok “yalın dönüşüm” girişimi aracılığıyla organizasyonların dönüşüm problemlerini yıllarca çalışmıştır. Bu makalede sunulan fikirler araştırma ve tecrübelerimizin kolektif birikimini kullanışlı bir çerçeve içerisinde aktarmayı amaçlamaktadır.

Lean Enterprise Institute CEO’su John Shook’un açıkladığı gibi “Toyota’nın en önemli başarımı öğrenmeyi öğrenmiş olmasıdır.” Yalın bir durum olmaktan ziyade; şirketlerin aynı anda ürün tasarımı, üretim yetenekleri ve tedarik zinciri verimliliğini artırabileceği bir süreçtir. Yeni ürün geliştirmede yalın bakış açısının özü geliştirici yeteneklerini güçlendirmektir. Bu amacını teknik eğitim ve işbirliği yöntemleri kullanılarak her geliştiriciyi daha iyi ürün ve hizmet tasarlar hale getirerek gerçekleştirmektedir. Yalın ürün geliştirme daha iyi ürünlerin temel taşını geliştiricilerin bireysel uzmanlıklarına erişmelerine bağlamaktadır. Böylece tüm sorumluluğu insan kaynaklarına yüklememektedir. Şirketler bireysel uzmanlığı şu üç temel soruyu sorarak sürekli teşvik edebilirler;

1. Daha iyi ürünler tasarlamak adına müşterilerimiz, ürünlerimiz ve üretim süreçlerimiz hakkında neyi öğrenmemiz gerekiyor?
2. Bunu nasıl öğreniniz?
3. Bu öğrenimi nasıl bir organizasyon yapısı ve rutinleri destekler?

Soru 1: Daha iyi ürünler tasarlamak adına müşterilerimiz, ürünlerimiz ve üretim süreçlerimiz hakkında neyi öğrenmemiz gerekiyor?

Yalın ürün geliştirmede, ayrık projeler yürütmenin tersine, geliştirme süreci sabit bir ritimde sürekli bir ürün akışını oluşturmaya programlanmıştır (yalın terimlerle “takt”). Bu bakış açısıyla Apple’nin iPhone değer akışı iPhone 1, iPhone 2 … şeklinde sabit bir hızla çıkan ürünlerden oluşmaktadır. Ana fikir endüstrinin doğal ritminden biraz daha hızlı olmaktadır.

Bir dizi ürün şeklinde düşünmenin tasarım süreci üzerinde önemli bir etkisi vardır. Birçok yeni ürün sıfırdan tasarlanmaz fakat değer zinciriyle evrim geçirir. Bazı durumlarda ilk ürün bir fikri test etme yolu sağlamaktadır. Bu durumda fikir müşteriden alınan cevaba göre düzeltilebilir. Örneğin Toyota’nın ilk Prius’u otomobil pazarında büyük bir pay almak için tasarlanmamıştı. Mühendisler, araç Hollywood’da popüler olduktan sonra, arabanın ticari başarısı karşısında oldukça şaşırmışlardı. İlk Prius’un hedefi hibrit motorların mantıklı olduğunu kanıtlamaktı. İkinci Prius ile Toyota bu teknolojinin genel kullanıcılara daha çok hitap etmesini istiyordu. Şimdi ise SUV ve minivanlar dahil olmak üzere başka araç segmentlerinde kullanılan hibrit teknolojisi ile önemli bir pazar payına sahip bir dizi Prius modeli bulunmaktadır.

Mevcut bir ürün değer akışında, bazı ürün özellikleri değişirken çoğu değişmez. Öyleyse bir değer akışı içerisindeki geliştirme zorluğu pazarı altüst edip ele geçirecek ürünü tasarlamak değil ancak mevcut çözümlerin değer önerisini iyileştirmektir. Ki mevcut müşteriler bir üst modele geçmek, potansiyel müşteriler de ilk defa almak için motive olsunlar. Değeri artırmak ürün tasarımının üç ana yönü hakkında bilgiyi artırmayı gerektirir;

1. Pazara uygunluk: sinir bozucu özellikleri azaltmak ve bugünün müşterisinin tercihlerine uyan yeni özellikler sunmak
2. Üretime uygunluk: daha ucuza üretilen daha kaliteli ürün tasarlamak
3. Endüstriye uygunluk: tedarikçi ağından ve sundukları teknik gelişmelerden daha çok faydalanmak için tedarik zincirindeki fırsatlardan yararlanmak

Mevcut üründeki problemleri çözmek başlangıç açısından güzel bir yer oluşturmaktadır. Yalın üretim yapan bir şirketin mevcut üründeki kalite sorunlarını çözmeye çalıştığı gibi, yalın uygulayan ürün geliştirme takımları da hangi kalite sorunları varsa onları düzeltmeye ve gelecek ürünler için iyileştirmeler yapmaya çalışır. Örneğin sadece birkaç yılda birim satışlarını ikiye katlamayı başaran akaryakıt pompası üreten bir şirketi ele alalım. Eskiden mühendisler müşterilerden sürekli gelen metal panellerin üzerindeki pas şikâyetini hayatın bir gerçeği olarak kabullenmişlerdi. Ancak her sorunu bir bir ele almaya karar verip ürün kalitesini artırdılar. Ardından makinenin müşterilere (petrol istasyonu sahipleri ve şoförler) sunduğu performans ve değeri iyileştirmek için ürünün asıl fonksiyonlarına odaklandılar. Süreç satışlarda ve pazar payındaki büyümeyi sürdüren popüler yeni bir ürünle sonuçlandı.

Mühendislikte kalite, ürünlerin nasıl iyileştirilebileceğine dair değer analizi gerçekleştirmek ve müşterilerin yeni üründe bu doğrultuda hangi özellikleri seveceğini çözmek anlamına gelmektedir. Yalın ürün geliştirmedeki fikir her ürün lansmanını pazarın nereye yöneldiğini öğrenme fırsatı, ürünleri ise evrimleşen değer akışları olarak görmektir.

Soru 2: Bunu nasıl öğreniniz?

Geliştiricilerin ne öğrendiği kadar nasıl öğrendikleri de önem arz eder. Değer akışındaki her bir yeni ürünün iyileştirilmesi bireylerin veya takımların o anki teknik problemleri çözmesi ve başkalarının yaptıklarıyla etkileşim kabiliyetlerine bağlıdır. Geliştiriciler kararlarıyla üretimi ve şirketin tedarik zincirini nasıl etkilediklerinin farkında olmalıdırlar. Bu elbette hem bilgi hem de hızlı öğrenim gerektiren zor bir iştir. Geliştirme takımını ne kadar hızlı öğrenir ve ne kadar çok bilgiye erişirse sonuç da o kadar yalın olur.

İnsanların gerçek sorunlarla uğraşırken birlikte çalışıp öğrendiği öğrenim süreci eylem öğrenme olarak bilinmektedir. Geleneksel yöntemlerle bilgi edinmek yerine, koçluk yapılan bir süreçle iş sırasında öğrenmektedirler. Yalın ürün geliştirme çerçevesinde eylem öğrenme standartlar kullanılarak, problemlere yaratıcı çözümler üreterek ve prototip testleri yapılarak gerçekleşmektedir.

Standartlar

Yalın, klasik geliştirme süreci akışından teknik çözümleri baştan belirlememeye veya “dondurmamaya” çalışması dolayısıyla ayrılmaktadır. Hatta hedef, sonrasında öngörülemeyen engellere takılmayı önlemek adına kilit kararları olabildiğince ertelemektir. Yalın sabit ve esnek olması gereken şeyleri belirlemeye çalışmaktadır. Bu kararların erkenden verilmesi mühendislere nerede esnek davranabileceklerini ve nerede kısıtlara uymaları gerektiği bilgisini vermektedir. Neyin sabit ve neyin esnek olduğuna karar vermek geliştirme sürecinin basit bir özelliği değildir. Aynı zamanda yetenekli mühendislerin eğitim sürecinin de bir parçasını oluşturmaktadır.

Sabit ve esnek olanı ele almak için farklı yaklaşımlar gerekmektedir. Standartlar sabit öğelere uygulanır. Standartlar en çok önceki ürünlerden gelen tecrübelerin üzerine kurulu olduğu zaman işe yararlar. Çünkü belirli kararların etkisi bilinmektedir ve bu kararları uygulamamak sorunlara yol açabilir. En detaylı hallerinde standartlar geliştiricilere bilinen performans limitleri ve ödünleşim eğrileri hakkında bilgi verir. Yalın geliştiriciler performans değerlerine bağlı parametreler, mevcut üretim kapasitesini tanımlayan üretim standartları ve kalite veya test kriteri belirleyen geliştirme süreci standartları gibi çeşitli standartlar kullanmaktadır.

Tecrübeler ve dersler bir projeden diğerine aktarıldığı için standartlar geliştiricilere hızla doğru kararlar almalarına yardımcı olur. Aynı şeyi tekrar öğrenmek için zaman ve kaynak harcamanın anlamı yoktur. Aynı zamanda yeni takım üyeleri bu standartları ilk projelerine uygulayarak tecrübeyle sabit bilgi edinirken tecrübeli geliştiriciler de standartları bilgilerini pekiştirmek ve başkalarına aktarmak için kullanmaktadır.

Problemlere yaratıcı çözümler üretmek

Esnek olarak belirlenmiş veya mevcut standartların geçerli olmadığı alanlar yaratıcı problem çözmeyi gerektirir. Ancak akla ilk gelen fikri kovalayıp iterasyon ile bu fikri iyileştirmek yerine birçok seçeneği birden ele alıp çözüm için uygun olmadıkları belli olana kadar seçenekleri değerlendirmek gerekir. Bu değerlendirme sürecine agresif testler ve fonksiyonlar-arası değerlendirmeler büyük katkı sağlamaktadır. Buradaki hedef belirli bir çözüme karar vermeden önce problemin altında yatan tasarım alanını tam anlamıyla kavramaktır. İdeal durumda bu “küme tabanlı” süreç yalnızca uygulanabilir bir çözüme ulaştırmayacak aynı zamanda sonraki projede kullanılabilecek ilk standartları oluşturacaktır.

Standartları uygulamak, bir problemi var olan bilgiyi tekrar kullanarak hızlıca çözmeye yönelik yakınsak bir düşünce süreci iken; küme tabanlı eşzamanlı mühendislik (KTEM), geliştiricileri belirli bir durum için birbirinden farklı teoriler üretmeye teşvik eden ve bu teorileri çürütene veya doğrulayana kadar test eden ıraksak bir düşünce sürecidir. Her iki düşünce süreci de yaratıcılık için esastır ancak sabit ve esnek olan karıştırılırsa yanlış yerlerde uygulanabilirler. Geliştiriciler bu iki yaklaşım arasında takılmadan geçiş yapabilmeli, liderler ise geliştiricileri uygun düşünce şekline ne zaman yönlendirmeleri gerektiğini fark etmelidirler.

Sözlerimizi somutlaştırmak adına: Toyota’nın Japonya’daki teknik merkezinde üretim süreci standartlarının geliştirme sürecine en erken aşamalarda iletildiğini ve çoğu durumda ürün tasarımının bu standartlara uyumluluğunun zorlandığını öğrendik. Sözün özü sürecin ön tasarımı yapılmıştı ve ürün tasarımı da süreç tasarımını izlemiştir. Birkaç farklı üründe aynı süreçlerin kullanılmasından daha öte bir durumdan bahsediyoruz. Tecrübeyle sabitlemek kaydıyla Toyota süreç mühendisleri tüm üretim süreçlerinde dünya standardında bir üretim mükemmelliği oluşturmak için gerekli kilit öğeleri belirlemiş ve standartlarını bu bilgilerin üzerine kurup geliştirmişlerdir (ör. belirli malzemelerin ve geometrilerin talaş kaldırma sınırları veya malzemelerin taşınması için tutulacak kısımlar, parça yerleri vb.). Yeni ürünler tasarlandıkça aynı süreçler ve ekipmanlar, ürün standartlara uyduğu müddetçe, kullanılmaya devam edilebildi. Sürecin ilk aşamalarında süreç mühendisleri ürün tasarımının üretilip üretilemeyeceğini biliyordu. Üretim yeteneklerinin geliştirilmesi gerektiği özel durumlarda ise Toyota, eşzamanlı inovasyon ile yeni ürünleri ve yeni süreçleri tek bir entegre sistem olarak tasarlamaları adına yüksek yetkilere sahip bir takım atamıştır.

Prototip Testleri

Geliştirme işinin doğası gereği geliştiriciler modelleri inşa etmeyi umdukları şeylerin temsili olarak kullanıyorlar. Bu modeller çizimler ve hipotezlerden üç boyutlu modellere ve bilgisayar simülasyonlarına kadar çeşitlenmektedir. Çoğu mühendis, mühendislik problemlerinin ilk prensiplere geri dönerek ve somut çözümleri kurcalayarak çözüldüğünü düşünüyor. Ancak yalın düşünce mevzubahis modellerin kalitesinin hem çözümlerin kalitesine hem de hızına inanılmaz katkıda bulunduğunu gösterdi. Mevcut standartlar altında çözümlerin simülasyon ve testleri, ister dijital ister analitik modelleme isterse de karton ve yapıştırıcı ile olsun, geliştiricilerin öğrenimi için esastır.

Modeller inanılmaz derecede önemli araçlardır. Yeni fikirlerin kendilerini ifade ettiği ortam ve asıl öğeyi yaratmadan fikirlerin sürdürülebilirliğinin değerlendirme aracıdır. Bu nedenle modeller birçok fikre daha bakmaya imkân tanır ve bu fikirler hakkında hızlıca ve etkili bir şekilde ders çıkartılır. Ancak modeller gerçekliği olduğu gibi yansıtamaz. Hatta modellere aşırı güvenilip buna göre karar alındığında problemler ortaya çıkabilir. Sonuçta modellerin fiziksel dünyayı ne kadar öngörebildiği ihtiyacı “yalın” ürün geliştirmeyi betimleyen birkaç uygulamaya yol açmıştır. Örneğin;

• Bir tasarım kâğıt üzerinde güzel görünebilir ancak bir veya birden fazla deneyimli tasarımcının ayrıntılı incelemesi, potansiyel zayıflıkları ortaya çıkarabilir. Tasarım incelemeleri geliştirme sürecinde alınan yolu görünebilir kılma ve geliştiricileri eğitme konusunda mükemmel fırsatlar sunmaktadırlar. Fonksiyonlar arası ortaklarla gerçekleştirildiğinde ise incelemeler disiplin sınırlarının kesişiminde muazzam bir öğrenime imkân sağlayabilir.
• Bilgisayar simülasyonları tasarım konseptinin davranışlarını tahmin edebilir ancak bilgisayar modelinin tüm önemli değişkenleri hesaba kattığını sadece tasarımı amaçlanan bağlamında gözlemleyerek doğrulayabiliriz (yalın terminolojide “gemba” olarak bilinir).
• Öğenin nasıl inşa edilebileceği hakkında erken bir görüş sahibi olmak için prototip inşa etmek en iyi yol olabilir. Tamamen zihinsel veya yapay görsellere bel bağlayan geliştiriciler çoğu zaman üretimde devasa farklılıklar yaratan kritik detayları göremeyebiliyorlar.
• Konseptin gereksinimleri ne kadar karşıladığını ve tasarım ödünleşimlerini belirlemek adına fiziksel testlerin erkenden ve sık sık yapılması gerekir. Tasarımın spesifikasyonları veya gereksinimleri karşılayıp karşılamadığını görmek için test yapmak yerine geliştirme takımları, belirli bir parametre değer aralığında tasarımın nasıl davrandığını olabildiğince öğrenmeye çalışmalıdır.

Soru 3: Bu öğrenimi nasıl bir organizasyon yapısı ve rutinleri destekler?

Başarılı yeni ürün geliştirme yeteneği öğrenmeye bağlı olduğuna göre yöneticilerin öğrenim alanını genişletmeleri için nasıl yapılar kurmaları gerekir? Önemli yapılardan biri gelişimin kendisidir. Yalın ürün geliştirme bakış açısı, titizlikle detaylandırılmış iş akışlarına uymaktansa öğrenmeyi ve takım çalışmasını teşvik eden süreçleri tercih etmektedir. Bu durum göz önünde bulundurulursa etkili bir yalın geliştirme süreci birbiriyle örtüşen beş fazdan meydana gelmektedir;

1. Proje sahibinin ve çekirdek takımın değeri tanımladığı ve ürünün sabit ve esnek yönlerinin belirlendiği erken konsept fazı.
2. Temel esnek yönlerde alternatif çözümlerin keşfedildiği ve alt-sistem seviyesinde istenilen konseptin nasıl gerçekleştirileceğine dair departmanlar arası uzlaşmanın arandığı ön tasarım veya araştırma fazı.
3. Standartları uygulamayı temel alan detaylı tasarım fazı.
4. Yeni ürünü üretmek için imalat sistemlerinin ve tedarik zincirinin nasıl düzenlenmesi gerektiğinin kararlaştırıldığı imalat öncesi fazı.
5. Tedarikçilerle iletişimi içeren işleme (talaş kaldırma, pres vb.) ve prototip fazı.

Farklı fazlar ürün geliştirmenin yaratıcı doğasını yansıtmaktadır. Öğrenmeye bağlı oldukları için aşırı detaylı proje planlaması oldukça zordur. Örneğin, birinci faz hem müşteri ihtiyaçlarını değerlendirmek için müşterilerin içine hem de var olan çözümlerin sınır ve kabiliyetlerini anlamak için teknolojinin içine “dalmayı” içermektedir. Bu öğrenmeye bağlı olarak geliştiriciler uzman gruplarla paylaşmak için ürün konseptleri veya taslak ürün broşürleri yaratabilirler. Ardından yapılan tartışmalar doğrultusunda, takım konseptin hangi yönlerinin standartlara uyması gerektiği (ilk konsepte kıyasla bazı değişiklikler gerektirebilir) ve hangilerinin esnek (ürünlerin mevcut standartların ötesine gitmesi gerektiği, inovasyon gerektirir) olduğu konusunda kararlar alacaktır. Birinci faz kesin hatlarla tanımlanmış tüm fonksiyonlar-arası ortakların desteklemek için anlaştığı ürün konsepti, zaman çizelgesi ve kaynak planı ile tamamlanır. Konsept onayı ise yönetim kurulu seviyesinde bir karardır.

İkinci faz özünde araştırma fazıdır. Ürünün esnek olarak görülen yönlerine odaklanılır. Buradaki fikir her alt-sistem için birkaç alternatifi ele alıp zayıf fikirleri elemeye çalışmaktır. Bir çözüme karar vermeden önce etkileşim içerisindeki alt-sistemlerin birbiriyle ve imalat edilmek istenen ürünün de üretim yetenekleriyle uyumunun sağlanması gerekmektedir. Süreç, tasarım her açıdan çalışacak (müşteri ihtiyacı, üretim, tedarik zinciri) bir çözüme yakınsayana kadar devam etmektedir. Örneğin yeni bir araç konsepti önemli bir miktarda ağırlık azaltma ile yüksek seviyelerde burulma sertliği (daha iyi direksiyon hakimiyeti için) ve yeni yaya güvenliği standartları üzerine kurulu olsun. Üretim mühendisleri ve etkileşim içindeki parçaların (mevcut sistemlerle uyumlu olmalıdırlar) tasarımcıları çeşitli seçenekleri gözden geçirecektir. Standartlar sistemine ve kısıtlara en uyumlu alternatifler ileri düzeltmeler için seçilir.

Araştırma fazını yalınlaştırmak bir fikri çürütmek için gereken minimum bilginin peşinde koşmayı ve son ana kadar detaylı tasımdan ve ürün simülasyonundan kaçınmayı gerektirir. Eğer gerekli bilgi hızlı bir taslak veya maketle kolayca elde edilebilecekse detaylı tasarımları erkenden geliştirmek (fikirden sonradan vazgeçilmektedir) israftır. Yalın geliştirme takımları, eldeki fikir sonuç vermezse, B planı çözümü hazırda bekleterek riski ortadan kaldırırlar. Araştırma fazı ödünleşimlerin doğasını ve tasarım sınırlarını anlamak için konseptin gereksinimleri sağladığını belirlemekten ibaret değildir. Derinlemesine bir anlayışa sahip olmak takıma iyi kararlar verme fırsatı sunar ve sonraki fazlarda yapılması gereken iterasyon sayısını azaltır. İkinci faz her alt-sistem ve ana parça için gerçekçi bir mimari planla beraber benimsenecek orijinal tasarımlar için ön standartlar ile son bulur.

Eğer birinci ve ikinci fazlara uygun kaynak sağlanırsa sonraki fazların düzgünce akması beklenir ve sıradan geliştirme süreçlerinin başına bela olan yeniden çalışma seviyelerini gerektirmez. Takımlar güçlü tasarımlar için standartlara oldukça bel bağladığından çoğu bilinmeyen ortadan kaldırabilir. Böylece detaylı proje planlama araçları etkili bir şekilde uygulanır ve geliştirme alt-takımları arasındaki iş koordinasyonu sağlanır. Birinci ve ikinci fazdaki ön çalışmalar gerçekleştirilmezse üçüncü ve beşinci fazlar arasında çok fazla belirsizlik oluşur. Bu belirsizlikler ise detaylı proje planlamasını oldukça zor hale getirir.

Geliştirme sürecine ek olarak organizasyonel yapılar da geliştiricilerin öğrenimini desteklemelidir. Başmühendis ürünün pazar başarısından sorumludur ve teknik kararların son karar merciidir. Kendisi ürünün mimarıdır ve ürüne nelerin dahil edilip edilmemesi gerektiği hakkında hüküm verir. Başmühendisin tasarım mühendisleri üzerinde resmi bir otoritesi yoktur ancak ürünü, tasarımdan üretime – üretimden tedarik zincirine, tüm şirket boyunca çeken kişidir.

Organizasyonun kalan kısmı, temel sorumluluk alanları arasında teşkilatlandırılmaktadır. Bu fonksiyonel grupların öncelikli rolü geliştiricileri “yönetmek” değildir. Tecrübeli kişiler iş sırasında öğrenme merkezleri gibi davranarak işin hem teorisini hem de geleneklerini standartlar ve uygulamalar formunda daha az tecrübeli arkadaşlarına aktarmaktadır. Ürün tasarımı bu nedenle başmühendisin vizyonu ile her geliştirme alanındaki bilgi sınırlarının erime potasıdır. Geliştirme sürecinin aşamalarını vurgulayan çeşitli tasarım incelemeleri, fonksiyonlar-arası öğrenim etkinlikleri olarak kullanılmaktadır. Buradaki amaç mühendisliğin, pazarlamanın, üretimin ve satın almanın projedeki sabit/esnek sınırlar hakkında mutabık olduklarından emin olmaktır.

Daha büyük organizasyonlar bir grup başmühendisi veya proje yönetim ofisini ve ayrı fonksiyonel grupları departman veya bölüm olarak bünyelerinde bulundurma imkanına sahiptirler. Ancak bu durum, kişilerin aynı anda birden fazla görev üstlenmek zorunda olduğu daha küçük organizasyonlar için uygulanabilir olmayabilir. Önemli olan nokta birisinin başmühendis olarak davranması (başka bir deyişle vizyondan, sistem mimarisinden ve alınan kararların müşteri ihtiyaçlarını karşılamasından sorumlu bir kişi) ve diğerlerinin de temel alanlarda bilgi standartlarını sürdürüp uygulamasıdır.

Yöneticiler için Uygulama

Yeni ürün veya hizmetler geliştirmekle sorumlu bir yöneticiyseniz, çalışanlarınızın gelişimini desteklemek için atabileceğiniz birkaç adım bulunmaktadır.

Öncelikle teknik uzmanlığı organizasyonunuzun bir beklentisi haline getirebilir ve ödül sisteminiz ile günlük çalışmalarınızın içerisine dahil edebilirsiniz. Toyota “yüksek teknik kabiliyeti” geliştirmeyi yeni mühendis yetiştirmede merkeze aldı. Benzer şekilde mühendis liderler için mentorluğu da Toyota’da temel niteliklerden biri haline getirdi. Ford Motor aynısını gövde ve pres mühendisliği içerisindeki her alanda teknik olgunluk modeli ile gerçekleştirdi. Ayrıca şirketin görevlendirme, tasarım incelemeleri ve ödüllendirme mekanizmalarıyla da bu modelini destekledi. Modele göre bireyler teknik kabiliyetleri ile değerlendiriliyor ve planlar kişilerin teknik olgunluklarını artıracak şekilde oluşturuluyor ve bireysel performans değerlendirmelerinde göz önüne alınıyordu. Bu model teknik uzmanlığa güçlü bir teşvik sunuyor ve insanları daha derin uzmanlıklara sahip olmak için departmanlarında kalmaya özendiriyordu. Ki sonunda da emekleri ödüllendiriliyordu.

İkinci olarak ise tasarım standartları geliştirip bu standartları kullanmalısınız. İşe organizasyonun içerisinde barınan bilgiyle başlayabilirsiniz. Tecrübeli geliştiricilerinizle akıllı bir tahtanın önünde birkaç saat harcayın ve belirli bir alt-sistemi nasıl tasarlayacaklarını veya yeni bir tasarımcıya nasıl tavsiyede bulunacaklarını sorun. Elde ettiğiniz bilgiyi kullanıcı dostu bir hale soktuktan sonra bu tasarım yönergelerini sonraki geliştirme projesinin başlangıç noktası olarak kullanın. Tasarım standartlarına sahip olduktan sonra geliştirme projesinde aldığınız dersler doğrultusunda standartlarınızı sistematik bir şekilde güncellemelisiniz. Toyota ve diğer şirketler geliştirme projelerini tamamladıktan sonra o projede öğrendikleri üzerine düşünmek ve tasarım standartlarına eklenebilecek bilgileri ayıklamak için bir iki haftalarını ayırıyorlar. Ardından alınan dersleri kullanılabilir bir formata sokmak için ek çalışmalar gerçekleştiriliyor. Hangi tasarım standardına kimin sahip olduğu açıkça bilinmelidir. İdeal durumda kolay kullanımı sağlamak adına standartları kullanacak grup değişmeyecektir.

Üçüncü olarak düzenli (örneğin haftalık) teknik tasarım incelemeleri gerçekleştirmelisiniz. Bu incelemelerin amacı eylem öğrenme ve fonksiyonlar-arası işbirliğiyle insanları geliştirmek olmalıdır. Sorulacak kilit sorular arasında;

1. Söz konusu aracın veya testin tasarım standardı nedir?
2. Mevcut tasarım standartla karşılaştırıldığında ne durumda?
3. Bunu kanıtlayacak veri nerede?

Tasarım incelemelerini, konferans odalarından ziyade, mümkün olduğu kadar sahada (test laboratuvarı, prototip atölyesi veya fabrika) gerçek yapılarla gerçekleştirin. Ki insanlar görebilsin, dokunabilsin ve hemfikir olup olmadıklarını söyleyebilsinler.

Dördüncü adım olarak organizasyonunuzun resmi geliştirme sürecine eleştirel gözle bakıp şu soruları sormalısınız;

• Tüm kararların müşteri istekleriyle uyumlu olduğundan emin olmak için müşteriyi anlamaktan, sistem mimarisini yaratmaktan ve çabaları koordine etmekten kim sorumlu?
• Müşterinin hangi sorunlarını çözmeyi amaçlıyorsunuz ve şirket ek olarak hangi değerleri sunuyor?
• İnsanlar tasarımın sabit (mevcut standartlara uyulacağı) ve esnek yönlerini ne dereceye kadar erkenden belirleyebiliyorlar? Geliştirme takımıyla açıkça belli olan ve çetrefilli hatta imkansızlar hakkında yeterince dürüst konuşmalar gerçekleştiriyor musunuz?
• Esnek alanları araştırmak için araştırma fazına yeterince kaynak sağlıyor musunuz? Bu faz projenin kalan aşamalarındaki zorluklar için yeterli açıklık ve kesinlikle sonlanıyor mu?
• Süreç kontrol noktaları gereksinimleri veya görev listesini sağlamaya kıyasla öğrenmeyi ne kadar teşvik ediyor? Kontrol noktalarınız sayısı doğru mu? Doğru zamanda mı gerçekleşiyorlar? Ve doğru kişiler mi dahil oluyor?

Son olaraksa organizasyon içerisindeki liderlik kültürünü kontrol etmelisiniz. Liderlere öğrenmenin karar vererek değil, iyileştirme üzerine odaklanıldığında (iş atayarak ve yön göstererek) desteklendiğini hatırlatın ve bu bakış açısıyla davranmalarını rica edin. Tasarım ve üretim standartları (ürün ve teknik süreçler hakkında şu anda bildiklerimiz) organizasyonun ürünler ve üretim süreçleri hakkındaki bilgisini derinleştirmek için temel araçlardır. Standartlarla aradaki farkı kapamak için problem çözmeyi teşvik etmek sorumlu geliştiricilerin otonomisini ve sorumluluğunu derinleştirecektir. İnsanların neyi nasıl öğrenmesi gerektiği hakkında açıklayıcı sorular sormak da geliştirici kapasitesini ileriye taşıyacaktır.

Başarılı insanlar başarılı ürünler üretir. Yalın ürün geliştirmenin asıl amacı giderek daha bilgili ve yetenekli hale gelen, problem çözebilen ve yeni çözümler üretebilen iyi geliştiriciler yetiştirmektedir. İnovasyon için gerekli bilgiyi insanlar üretir. Yeni ürünler, üretim sistemleri ve daha güçlü tedarik zincirleri tasarlamak için bu bilgiyi insanları kullanır. Bu nedenle insanlar ve sosyal sistemler ürün geliştirme sistemlerinin en önemli parçasıdır. Ne yazık ki her organizasyon bu şekilde düşünmüyor. Sonuçta süreçler ve araçlar temelinde düşünmek daha basit geliyor. Ancak hem araştırmalarımız hem de yalın geliştirme organizasyonları ile olan çalışmalarımızdan gelen tecrübelerimiz geliştiricilerin ne öğrenmesi gerektiğini, nasıl öğrenmesi gerektiğini ve bu öğrenmeyi hangi organizasyon yapılarının desteklediğini anlamamıza yardımcı oldu. Bu görüşleri uygulayarak ve insanları geliştirme sistemlerinin belkemiği haline getirerek şirketler bir taşla üç kuş vurabilirler: artan inovasyon, daha kısa pazara çıkış süresi ve daha düşük maliyet.

Kaynak
Michael Ballé
James Morgan
Durward K Sobek II

Çeviri
Mehmet Talha Kurt
Araştırma Görevlisi
Yalın Enstitü