Çeviri Makale / Altı Sigma Forum dergisi / Sayı: 16

 

"PROBLEMLERİ BAŞLAMADAN ÖNLEMEK"

MOTOROLA, İŞ AÇISINDAN KRİTİK UYGULAMALARI DEVREYE SOKMADAN ÖNCE; RİSKLERİ NASIL MİNİMİZE ETTİ.

 

Vic NANDA - Motorola / ASQ - Six Sigma Forum Magazine

Günümüzün dinamik iş ortamında, şirketlerin büyük çoğunluğu, planlanmış değişikliklerden doğabilecek riskleri ölçmek ve azaltmak gibi zorlu bir mücadeleyle karşı karşıya kalıyor. Burada sözü geçen değişiklikler arasında, şirketin iş süreçlerinde kullandığı bilgi teknolojileri (IT) uygulamalarında ya da genel olarak iş çevresinde yaptığı yeniden düzenleme çalışmaları da yer alabiliyor.

Bu değişikliklere giderken uygun yöntemler kullanılmazsa, potansiyel bir başarısızlığın kurumda yapacağı etki ölçülüp sayılara dökülemiyor ve basit, sübjektif bir tahmin olmaktan öteye gidemiyor (yüksek, orta, düşük gibi). Usule uygun bir risk değerlendirme çalışması yapıldığında ise, bir başarısızlığın sadece belli bir alanda (veya kısa vadede) ortaya çıkaracağı sonuçlar araştırılabiliyor ve bunun bütün şirket üzerinde yapacağı etkiyi değerlendirmek mümkün olmuyor.

Buna rağmen, resmin bütününü görmenin ve buna göre harekete geçmenin de bir yolu var. Bir kuruluş, yakın gelecekte uygulamaya sokacağı değişikliklerin ortaya çıkarabileceği riskleri rakamlara dökmek ve azaltmak için, tasarım başarısızlığı durumunun etkileri analizini (DFMEA) güçlendirecek bir yaklaşım uygulayabilir. Motorola değişim sürecindeyken, DMAIC (tasarla, ölç, analiz et, geliştir, kontrol et) yönteminin yardımıyla bunu başardı ve IT uygulanmalarını geliştirirken karşılaşabileceği önemli aksiliklerin, daha gerçekleşmeden önüne geçti. Böylece, her yıl sistem aksaklıkları nedeniyle yarım milyon dolardan büyük bir rakam harcamaktan kurtuldu.

 

Projeyle ilgili genel bilgiler

Motorola, 2006 yılında, milyonlarca dolanlık bir IT girişiminin parçası olan iddialı bir proje başlattı: Küresel boyutlarda kullanılan, iş açısından son derece kritik bir uygulamanın mimarisini yeniden tasarlayıp, sadeleştirecekti. Birincil amaç, Motorola'nın iş amaçlı kullanılan benzer fonksiyonlara sahip ürünlerinin birbirinden tamamen farklı yapıda IT uygulamalarını ortadan kaldırarak, operasyon verimliliğini artırmak ve maliyetleri düşürmekti. Farklı uygulamalar yerine, birleştirilmiş tek bir IT uygulaması kullanılarak, tüm iş amaçlı Motorola ürünlerinin bununla çalışması sağlanabilirdi.

Böylesine temel bir konuda yapılacak mimari değişiklik, beraberinde potansiyel riskler de taşıyordu. Uygulamaya geçiş sonrası ortaya çıkabilecek aksaklıklar, mevcut iş operasyonlarını tehlikeye atabilir ve ürünleri bir süreliğini çalışmaz hale getirebilirdi. Projenin 2007'nin sonlarında gerçekleştirilen tasarım aşamasında, üst yönetim, önerilen mimari yapının potansiyel başarısızlıklara karşı detaylı incelemelerden geçirilmesine karar verdi. Bu karar, yeni mimari yapının, ürünlerin kullanılırlığı ve güvenilirliği gibi gerekliliklerini tehlikeye atabilecek olası tasarım hataları konusunda değerlendirilmesini gerektiriyordu.

Bunu üzerine bir Altı Sigma proje ekibi (SSPT) kuruldu, katılımcıları şu kişilerden oluşuyordu: Bir Yeşil Kuşak, bir Kara Kuşak, bir İleri Seviye Kara Kuşak, yeni projeyi ortaya çıkaran ana IT projesinden bir müşteri temsilcisi ve proje kapsamı içinde yer alan çeşitli fonksiyonel alanlardan kendi konularında uzman 15 kişi.

Proje için bir de idari ekip kuruldu. Bunu oluşturanlar ise, iki proje sponsoru, bir proje Şampiyonu, finansman grubundan bir temsilci, Motorola IT'nin Altı Sigma programı lideri ve SSPT'de yer alan Kara Kuşak sahibinin o dönemde yöneticisi olan kişiydi.

Proje ekibi için şu hedefler belirlendi:

  1. Önerilen yeni IT mimarisinin potansiyel başarısızlıkları sonucunda bütün şirket için ortaya çıkabilecek riskleri değerlendir ve rakamlara dök.
  2. Şirket için en büyük riskleri oluşturacak temel tehlikelerin doğru sıralamayla ele alınabilmesi için risk hafifletilmesi araştırmaları yap ve geliştirici önerilerde bulun.
  3. Yapılan önerilerin uygulamaya sokulması durumunda, riskte ne kadar düşüş olacağı konusunda öngörüde bulun.

 

Tanımlama aşaması

Ekip, aşağıdaki raporları oluşturdu:

Olurluk İncelemesi - Dağınık bir IT mimarisinden birleşik bir yapıya geçiş, son derece derin bir konu ve her yönüyle anlaşılması ve hafifletilmesi gereken önemli riskler taşıyor.

Fırsat raporu - Önleyici tedbirler almak amacıyla tasarım hatalarının önceden fark edilmeye çalışılması, projede yaşanabilecek sorunları daha erken aşamalarda ortaya çıkarmaya yardımcı olabilir ve şunların minimize edilmesine de katkıda bulunabilir:

Amaç raporu - Projenin amacı, 14 Mart 2008 tarihine kadar önerilen mimarideki kusurları ortaya çıkararak, yeni IT mimarisinin sağlamlığını artırmak ve en az 250.000 dolarlık bir ölçülebilen maliyetten kurtulmaktır.

Proje Kapsamı - Mimarinin analiz edilecek yönleri konusunda referans çizgisi belirlendi ve yeni mimari yapı içinde kusursuz çalışmalarını sağlamak amacıyla değerlendirmeye alınacak yedi teknik süreç akışı listelendi. Bu aşamada, uygulamanın etkileşimde olduğu, yine analizlerin kapsamı içindeki diğer IT uygulamaları da belirlendi.

Proje Planı - Projenin DMAIC akışı içinde her sürecin bitirileceği dönüm noktası tarihleri belirlendi. Yüksek düzeyde hazırlanan proje planı, her proje aşamasını detaylı şekilde alt aşamalara ayıran bir planla daha desteklendi ve burada aşamaların her birinin başlangıç, bitiş tarihlerine ve proje görevleriyle ilgili sorumlulara yer verildi.

Proje bitiş tarihi, SSPT ve proje sponsorları tarafından belirlendi.

 

Ölçme aşaması

Bu aşamada, mevcut süreç performansının referans çizgisini oluşturmak için kullanılacak, performans ölçütlerini listeleyen bir ölçüm planı hazırlanacak ve proje yatırım getirisi (ROI) belirlenecekti.

Performans Ölçütleri şunlardı:

  1. Düşük Kalite Maliyeti (COPQ) Kurum içinde gerçekleşen hatalar; başka deyişle ürün piyasaya sürülmeden önce bulunacak hataları düzeltmek için yapılacak IT çalışmasının maliyeti.
  2. Düşük Kalite Maliyeti (COPQ) Kurum dışında gerçekleşen hatalar; başka deyişle ürün piyasaya sürüldükten sonra bulunacak hataları düzeltmek için yapılacak IT çalışmasının maliyeti.
  3. İşle ilgili darbeler, yani satıştan sonra ortaya çıkan sorunların firmaya dolar cinsinden vuracağı darbe.

Süreç performansı için referans çizgisi oluşturacak ölçüm verileri daha önce gerçekleştirilmiş 57 büyük IT projesinden toplandı. Veriler, proje başına ortalama 43 piyasaya sürüş öncesi hatanın ortaya çıktığını ve bunların hata başına giderme maliyetinin ortalama 132,05$ olduğunu gösteriyordu.

IT uygulaması kullanıcılara sunulduktan sonra ise, proje başına ortalama 9 hata görülüyordu. Bunların giderilme maliyeti ise ortalama 1.065,85$ idi, yani piyasaya sürüş öncesi sorunu çözmenin, sekiz katı daha maliyetliydi. Bu veriler IBM tarafından ilan edilen benzer verilerle de örtüşüyordu. Arıza maliyeti ise, kritik bir iş uygulamasında 2003 yılında yaşanan bir olay temel alınarak hesaplanmıştı.

Projenin bu aşaması, daha önce proje dönüm noktalarından biri olarak belirlendiği şekilde, ilgili sonuçların, proje ekibine sunulmasıyla sona erdi.

 

Analiz aşaması

Bu aşamada, daha önce projede tanımlanmış yedi teknik süreç akışı incelendi ve modellendi. Kritik iş uygulaması basamaklarının ve bunların diğer uygulamalarla ilişkisinin tanımlanması için (gerçek süreçlerin genel karakterlerinden oluşturulan) süreç haritaları hazırlandı. Teknik süreç akışlarının bir örneği Şekil 1'de görülmektedir. Yatay biçimdeki dört dikdörtgen, bu senaryoyla ilgili dört farklı kritik iş uygulamasını temsil ediyor. Bir dikdörtgenden diğerine uzanan çizgiler ise, uygulamalar arasındaki kesişim noktaları mesajlarını sembolize ediyor.

Teknik akışlar geliştirildikten sonra, DFMEA şablonu (Tablo 1) her ayrı süreç akışı için başlık bilgisi ve bunlara ait etkinliklerin isimleri (Şekil 1'deki küçük kutular) ve kesişim mesajları (Şekil 1'deki çizgiler) ile dolduruldu. Bu durum, DFMEA atölyesinde zaman kazanılmasına neden oldu, çünkü SSPT, şablonları kullanıma hazır hale getirmişti.

Süreç haritalarının ön hali tamamlanınca, bir DFMEA atölyesi düzenlendi. Atölye, SSPT'ye verilen DFMEA Altı Sigma aracının kullanımına dair bir saatlik eğitimle başladı.

Ekip, ortaya çıkma olasılığı ve tespit alanlarındaki değerlendirmelerini, geleneksel 10 puanlık ölçü sistemini kullanarak gerçekleştirdi. Sorunun ciddiyetiyle ilgili ise 5 puanlık ölçek tercih edildi, çünkü bu, Motorola'nın IT yazılım uygulamalarında bildirilen hataların ciddiyet derecesiyle ilgili zaten mevcut puanlama sistemiyle örtüşüyordu.

 

Risk öncelik sayısı (RPN) = olasılık
(maksimum = 10) x tespit (maksimum = 10)
x ciddiyet (maksimum = 5).

RPNMaksimum = 10 x 10 x 5 = 500.

RPNr = Düzeltici etkinliklerden sonra azaltılmış RPN değeri.

 

Altı Sigma Proje Ekibi (SSPT), RPN > 80 olanları, yüksek riskli başarısızlıklar olarak kabul etti. Bu değer aynı zamanda kabul sınır değeri olarak belirlendi.

Bunun ardından SSPT, aşağıdaki başarısızlık biçimlerinin açığa çıkarılması üzerinde yoğunlaşmaya karar verdi:

Ortaya çıkarılan kesişim noktaları şu şekilde sınıflandırıldı:

IT uygulamaları söz konusu olduğunda, ağ hataları, hafıza kayıpları, veritabanı tasarım hataları ve kapasite problemleri (işlemci, hafıza veya bilgi saklama) gibi altyapıyla ilişkili başarısızlıklar da ortaya çıkabiliyor. Altyapıyla ilgili bu tür hataların uçsuz bucaksız bir genişlikte olması nedeniyle, altyapıyla ilgili başarısızlıkların, DFMEA çalışmaları dışında tutulmasının gerekli olduğuna karar verildi.

Ekip, zaman kazanmak amacıyla, DFMEA analizleri boyunca, teknik akışlarda benzerlik gösteren noktalarda gerekli kaldıraçları uygulayarak, takip eden analizlerde, akışlar arasındaki özgün farklılıklar üzerinde yoğunlaşabilme imkânı sağladı. Başka bir deyişle, A ve B teknik akışları arasında bazı bölümler aynıysa, A akışının DFMA analizleri sırasında ortaya koyulan başarısızlık biçimleri, B'ye de uygulandı. Son olarak, bunlara ek olarak belirlenen çeşitli tiplerdeki başarısızlıklar da DFMEA analizinin risk değerlendirilme bölümüne ve daha sonra ortaya çıkabilecek olası ilgili kişilere (mesela altyapıyla ilgili analiz yapabilecek bir DFMEA analizi grubuna) verilecek belgelere eklendi.

 

Geleneksel DFMEA'nın Genişletilmesi

Daha önce de bahsi geçtiği üzere, SSTP'nin zorlu görevlerinden biri de Motorola'nın nasıl bir riskle karşılaşacağını daha doğru bir şekilde anlayabilmek için, geleneksel DFMEA sonuçlarının daha dışarıdan bakarak değerini hesaplayarak tahmin yürütmekti. Bu, DFMEA çalışmaları sırasında, Risk Öncelik Sayısı (RPN) puanlaması için daha geniş bir bakış açısı gerektiriyordu.

Bu amaç doğrultusunda, ciddiyet ölçüsünün kullanılabileceğini söylenebilir. Örneğin, bütün şirket için çok korkunç sonuçları olabilecek bir etki, 10 puanlık bir ölçekte 10 olarak değerlendirilebilir, fakat bu yaklaşım, bütün şirket bazında sistematik bir hesaplama yöntemine izin vermez. Mesela dışarıya dönük bir varyantla (şirket kaynak planlaması [ERP] 7'den), başarısızlık cinsine bağlı olarak, sürecin en fazla üç farklı versiyonunda karşılaşılabilir (Şekil 2).

Yine aynı şekilde, işlemin diğer ucunda, hata tipine bağlı olarak, bir başarısızlıkla en fazla altı farklı ERP'de daha karşılaşılabilir. Ya da içeriye yönelik en fazla iki farklı akış versiyonunda karşımıza çıkabilir. Bu nedenle bütün şirket çapında karşılaşılabilecek gerçek riski anlamak için (şirket RPN'si veya eRPN olarak bahsedilecek), gereken yerlerde, tek bir akışa ait RPN, akış versiyonlarının veya ERP'lerin sayısıyla çarpılmalı.

Örneğin, RPN değeri 500 olan bir risk, bir ile çarpıldığında, eRPN değeri 500 olacaktır. Fakat RPN riski daha az, mesela 200 görünen bir risk (bütün ERP'lerde karşılaşılacağı varsayılarak) 7 ile çarpıldığında eRPN değeri 1.400'e ulaşacaktır. Bu örnekte, bütün şirket için daha yüksek risk taşıyan durum, RPN değeri 200 olandan kaynaklanmaktadır. Bu şekilde dışarıdan bakılmadan ve eRPN kavramı kullanılmadan öngörüde bulunulursa, ekip yanlış yönlendirilmiş olur ve ilgisini daha çok RPN değeri 500 olan başarısızlığa yöneltir.

eRPN = RPN x [varyasyon veya ERP sayısı]

eRPNMaksimum = 500 x 7 = 3.500

eRPNr = Düzeltici Etkinliklerden sonra azaltılmış eRPN değeri.

ERPN değerinin hesaplanması cevabın sadece bir bölümünü oluşturuyor, çünkü pek çok başarısızlık tipi, aynı kök nedeni paylaşıyor olabilir. Durum böyle olursa, bu tarz pek çok farklı soruna kaynak olan kök nedenler, tek bir soruna neden olanlarla kıyaslandığında daha büyük önem taşımaya başlar. Bu yüzden, tekrar tekrar karşılaşılan kök nedenler büyük bir dikkatle ele alınmalıdır, çünkü şirkete en büyük zararı bunların verme olasılığı yüksektir.

Aynı kök nedenden kaynaklanan tüm eRPN değerlerini toplayarak, o kök nedenin, şirketi içine attığı toplam riski tahmin edebilirsiniz. Bunu, yani aynı veya benzer kök nedene dayanan bütün başarısızlıkların şirket için oluşturduğu toplam riski, kümülatif eRPN diye isimlendiriyoruz.

 

Nedenler Üzerine Beyin Fırtınası

İlk aşama, sürecin her basamağında ortaya çıkabilecek potansiyel başarısızlıklar konusunda beyin fırtınası yapmaktı. SSPT, her bir süreç basamağını ve ilgili kesişim mesajlarını ayrı ayrı inceledi, potansiyel uygulama ve veri tabanıyla ilişkiler üzerinde beyin fırtınası yaptı. Potansiyel başarısızlıkların her birinin neden ve başarısızlık açısından önem dereceleri belirlendi. Ekip, her başarısızlığın ciddiyet derecesi, gerçekleşme olasılığı ve tespit edilebilme değerleri konusunda hemfikir olduktan sonra, her başarısızlığın RPN puanı ayrı ayrı hesaplandı.

Bir hafta süren bir atölye çalışmasında SSPT, 57 başarısızlık tipi belirledi. Bunlardan 27'si kabul edilebilir sınırı aşan ve bütün şirketi ciddi anlamda etkileyebilecek yüksek riskli başarısızlık tipleriydi. Tablo 2, en riskli 5 başarısızlık tipiyle ilgili kısmın küçük bir bölümünü gösteriyor. Sıralama, eRPN puanı daha yüksek olandan, daha düşük olana doğru yapıldı. Okunabilirliği artırmak için, bazı sütunlar gizlendi.

SSPT, kök nedenler arasında en yüksek kümülatif eRPN değerine sahip olanla da özel olarak ilgilendi. En yüksek riskli üç kök nedenle ilgili kısmın küçük bir bölümü, Tablo 3'te görülüyor. Aynı kök nedenle ilişkili başarısızlıkların tümü birinci sütunda listelenirken, ortak kök nedenler ise ikinci sütunda yer alıyor.

Şekil 3, kümülatif eRPN değerlerine göre, yüksekten düşüğe doğru sıralanmış kök nedenleri gösteriyor. Her sütunda yer alan farklı renkler, aynı kök nedenden kaynaklanan farklı başarısızlıklara denk geliyor.

Örneğin ilk sütunda aynı kök nedenden kaynaklanan altı farklı başarısızlık yer alıyor. İlk sütunda bu farklı farklı renklere sahip bölümlerin her birisinin kapladığı alan, bunların şirket çapındaki risk (eRPN) düzeylerini ifade ediyor.

 

İyileştirme Aşaması

Bu aşamada ekip, listelenen kök nedenlerle ilgili gelişmeler ve bunları düzeltici eylemler üzerine beyin fırtınası yaptı. 13 kök nedeni düzeltmek için 15 geliştirme önerisi yapıldı.

Şekil 4, orijinal risk profilini ve geliştirme önerileri uygulandıktan sonra risk profilinde ortaya çıkan tahmini azalmayı gösteriyor. Hesaplanan risklerin bu şekilde, yani "öncesi ve sonrası" şeklinde ifade edilmesi, üst yönetime şirketin maruz kalacağı toplam riskin sunulmasında güçlü bir yöntem.

Yeniden hesaplanan RPN değerleri, belirlenen düzeltici eylemler uygulanırsa, başarısızlık tiplerinin %80'inin kabul edilebilir risk düzeyinin altına düşürülebileceğini gösterdi. 27 başarısızlık tipinden sadece 1 tanesi, bütün düzeltici eylemler devreye sokulsa bile, kabul edilebilir risk düzeyinin üzerinde, 120 RPN değerinde kaldı.

Ardından, her bir düzeltici eylem önerisi, IT projesi üzerindeki uygulama etkileri açısından, aşağıdaki kriterlere göre değerlendirildi:

  1. Olumsuz finansal etkisi yok (bütçe)
  2. İş takvimi üzerinde etkisi yok.
  3. İş süreci üzerinde etkisi yok.

Yukarıdaki kriterlerin hepsini karşılayan öneriler, uygulama riski düşük olarak sınıflandırıldı. Öneri, yukarıdakilerden birini bile karşılamıyorsa, uygulama riski yüksek olarak sınıflandırıldı ve uygulamaya alınmadan önce, daha detaylı bir etki değerlendirilmesi gerektiğine karar verildi.

Son olarak analiz sonuçları, her tavsiyenin beraberinde getireceği uygulama riski değerlendirmeleriyle birlikte, üst yönetime sunuldu.

 

Kontrol Aşaması

Düzeltici eylemler, ana IT projesinin aşamaları arasında yer alan çok sayıda aya ve aşamaya yayıldığından, Altı Sigma projesi, bütün düzeltici eylemlerin belgeler halinde IT projesinin yöneticisine teslim edilmesiyle son buldu. Bu belgelerde, her bir eylemden sorumlu olacak kişilerin isimleri ve düzeltici eylemlerin sonuçlanacağı tarihler de ayrı ayrı belirtiliyordu.

 

Faydanın Gerçekleşmesi

Bu proje Motorola'nın toplam riski %77 azaltmasıyla sonuçlandı.2 Ayrıca, yüksek riskli olarak tanımlanmış 27 başarısızlık tipinden 26'sının potansiyel riski, kabul edilebilir risk sınırının çok altına indirildi.

Motorola'nın daha önce gerçekleştirdiği 57 büyük çaplı IT projesinin hata sayısı, hatalarla mücadele etkinliği ve bunları düzeltmek için yapılan çalışmaların maliyetiyle ilgili tarihi verilerinden yola çıkıldığında, SSTP, 27 yüksek riskli hatanın önceden belirlenmesiyle COPQ maliyetlerinden ürünün piyasaya sunulmasından önceki düzeltme çalışmalarından dolayı yılda 2,905$, satışa sunulmasından sonraki düzeltici çalışmalardan yılda 5.329$ direkt tasarruf edildiğini saptadı.

Satış sonrası sorunların işletmeye indireceği darbe dikkate alındığında ve 2003'te benzer bir durumun işletmenin çok daha küçük bir bölümünü etkileyen bir tecrübeden edinilen tarihi verilerden yola çıkıldığında, SSTP, gelecekte karşılaşılabilecek benzer bir durumun şirkete indireceği yıllık darbenin, hangi tip sistem hatalarıyla karşılaşılacağına da bağlı olarak, en az 560.000$ olacağını saptadı.

Bu bedelin içinde, nakit dönüş devir hızı, acele gönderi maliyeti, çalışanların bozuk ürünleri çalışır hale getirmek için harcayacağı zaman (IT personeli değil), sözleşme kaynaklı cezalar, işgücü kaybı, ihracat avantajlarının yitirilmesi gibi unsurlar da yer alıyor. Bu nedenle, tahmini yıllık maliyetler en az 568.234$ azaltılmış oldu. Karşılaşılabilecek sistem hatası tiplerine göre, bu rakam çok daha büyük de olabilir.

Tahmini proje maliyetinin 77.280$ olduğu dikkate alınınca, projenin yatırım getirisinin (ROI), sadece ilk yıl üzerinden hesaplansa bile, maliyetinin 6,35 katı olduğu görülüyor.

 

Sınırlamalar

Kullandığı süreç veya teknolojiyi değiştirirken iş risklerini sayılara dökmek veya azaltmak isteyen bir şirket, bu projenin sonuçlarını direkt olarak uygulayabilir. Bu projedeki değişim, teknolojiyle ilgili olsa bile çalışmanın özünü oluşturan FMEA (süreç FMEA veya PFMEA olarak da adlandırılıyor) aracı ya da projedeki ismiyle DFMEA, bir sürecin potansiyel başarısızlık tiplerini ortaya çıkarabilir.

Herhangi bir yaklaşımda olduğu gibi, bunda da bazı sınırlamalar vardır. FMEA'nın karmaşık hata tiplerini (mesela birbirini takip eden bir dizi küçük hatanın birleşimiyle ortaya çıkabilecek bir etki) ortaya çıkaramadığı kabul edilmektedir. SSPT, standart COTS uygulamasında yer alan başarısızlıklarla ilgili başarısızlık tiplerini dikkate almadı, çünkü bunlar yeni IT mimarisine geçişin bir sonucu değildi.

Son olarak, FMEA analizlerindeki başarısızlık senaryolarının puanlanması her zaman için sübjektif bir çalışmadır ve son RPN puanları, grubun üzerinde anlaştığı değerleri temel alır. Yine incelediğimiz olayda DFMEA analizleri, potansiyel başarısızlıklarla ilgili tarihi verilere sahip olunmadığından, zorlu bir süreç olmuştur. Bunun nedeni, yeni mimari yapının daha önce Motorola veya başka bir firmada uygulamaya sokulmamış olmasıdır.

Bu sınırlamalara rağmen, DFMEA yöntemi, şirket çapındaki riski sayılara dökmek ve minimize etmek açısından güçlü bir araç olarak görevini yerine getirmiştir. Analiz sonuçları, yönetimin, şirket çapında riskin sayılara dökülmesiyle ilgili beklentilerini de karşılamıştır. Bu projede tanımlanan yaklaşım, işlerinde planlı değişiklikler yapmak isteyen ve şirket çapında karşılaşılabilecek risklerin değerlendirilmesi konusunda benzer zorluklar yaşayan kuruluşlar tarafından doğrudan adapte edilebilir.

Referanslar

  1. Humphrey Watts, A Discipline for Software Engineering, Addison Wesley, 1995.
  2. The balance of 23% should not be misunderstood as residual risk of any one failure to Motorola. Instead, it is the cumulative effect of all 27 highrisk failures together. In other words, it is more appropriate to consider each high-risk failure separately because the high-risk failures were not related, and thus were unlikely to be encountered simultaneously.

Kaynakça

  • Arkusinski, Andy, "Failure Modes and Effects Analysis During Design of Computer Software," presentation, 24th Digital Avionics Systems Conference, Oct. 30, 2005.
  • Haapanen, Pentti and Atte Helmunen, "Failure Mode and Effects Analysis of Software-Based Automation Systems," STUK (Finland's radiation and nuclear safety authority), August 2002, p. 37.
  • Vijayaraghavan, G.V., "A Taxonomy of E-commerce Risks and Failures," master's degree thesis, Florida Institute of Technology, May 2003.