5  Çözümün Yapı Taşları

5.1 80/20 kuralının kritik önemini anlamak

Kitapta daha önce de belirttiğim gibi: sorunu bilmek ve sorunun nasıl çözüleceğini bilmek iki farklı konudur. Şirketim, uzun yıllara dayanan zorlu deneyimlere dayanarak Seksen/20 süreci adını verdiğimiz bir süreç yaratmayı başardı.

Üreticilere sadece bir APS sistemi kurmanın fayda sağlayacağına şüphe olmasa da, bu süreç gözden kaçan asıl noktadır. Bu, yiyecek almak için köşedeki mağazaya gitmek üzere yeni bir Maserati Quattroporte satın alırken, eski, yıpranmış bir Ford’u hızlı bir yere gitmek ve randevunuzu etkilemeye çalışmak için kullanmak gibi bir şeydir. Bir APS sistemini günlük operasyonlara entegre etmenin faydaları o kadar büyüktür ki, bunu başka şekilde yapmanın hiçbir anlamı yoktur. Becerinin devreye girdiği yer burasıdır.

Seksen/20 Süreci, 80/20 kuralına derin inancımızdan gelişti. Bu kural bazen Pareto Kuralı olarak da adlandırılır. Bu kuralı duymamış olanlar için pek çok şeye uygulanabilir. Ancak bizim dünyamızda bu, bir şirketin yalnızca %20 çabayla %80 sonuç elde edebileceğini gösteriyor. Bu kuralı sürecimizin her aşamasında benimsemek, müşterilerimizin genel başarısı üzerinde büyük bir etki yarattı.

Ancak 80/20 kuralını anlayan çoğu kişi, bunun planlama için geçerli olan sonucunu tam olarak kavrayamaz. Çünkü çoğu durumda %100 veya mükemmel çözüme ulaşmak mümkün değildir.

Ancak 80/20 kuralını uygulamaya kalkışmadan önce tamamlamanız gereken bir adım var. Bu tam olarak neyi başarmak istediğinizi belirleyen bir süreçtir. Bu süreç bizi, düzeltmeye çalıştığımız iş sorunlarını derinlemesine düşünmeye, önceliklendirmeye ve başarılı olursa elde edilecek tüm faydaları listelemeye zorlar. Buna Değerlendirme aşaması diyoruz.

Kulağa çok basit geliyor ama bu aşamayı doğru bir şekilde gerçekleştirmek için fazladan zaman harcamak herkesin aynı fikirde olmasını sağlar, kafa karışıklığını önler ve nispeten kısa bir zaman dilimi içinde herkesin bir şirketin stratejik başarısı için önemli olan şeylere odaklanmasına yardımcı olur.

Sorun üzerinde anlaşmaya varıldığında, ideal, uzun vadeli çözümün yüksek düzeyden nasıl göründüğüne dair net bir vizyon oluşturmak değerlendirme aşamasının görevidir. Çoğu durumda bu, çözümü yapı taşları adı verilen belirli sayıda aşamaya ayırmamıza olanak tanır. İlk yapı taşı yalnızca faydaların %80’ini sağlamakla kalmamalı, aynı zamanda bir şirketin iyileştirmeler yapmaya devam edebileceği altyapıyı da oluşturmalıdır.

İlk yapı bloğu ideal çözümün %80’ini sunmalıdır. Tabi ki gerçekte bu %70, veya %85 olabilir. Bu nedenle, ilk yapı bloğunun teslimine giden yola başlamadan önce tüm yapı taşlarının tanımlanması gerekir. Yeni sorunlarla veya “fırsatlarla” karşılaşıldığında genel görünüm, bu fırsatların her şeyin yolunda gitmesini sağlayacak uygun yapı taşına yerleştirilmesini kolaylaştıracaktır.

Seksen/20 metodolojisinin bir dizi farklı aşaması vardır:

  1. Değerlendirme Aşaması
  2. Tasarım Aşaması
  3. Prototip Geliştirme Aşaması
  4. Entegrasyon Aşaması
  5. Test Aşaması
  6. Uygulama Aşaması
  7. Uygulama Sonrası İnceleme

Elbette bu süreci takip etmenize gerek yok. Ancak sonraki birkaç bölümü okumaya zaman ayırırsanız, umarım sizi her aşamanın ayrı bir amacı olduğuna ve bunun çok başarılı çözümler sunmanın kanıtlanmış bir yolu olduğuna ikna edebilirim.

5.2 Değerlendirme Aşaması

Değerlendirme aşamasında harcanan her kuruş, binlerce kez geri ödenebilir. Her yeni görüşmede, herhangi bir şey yapmadan önce, her müşterinin en az iki gününü bizimle birlikte geçirerek nerede olduklarını, sorunlarının neler olduğunu ve nereye gitmek istediklerini değerlendirmelerini şiddetle tavsiye ederim. Bu aşamada yapılan varsayımlar felaketle sonuçlanabilir. Bu nedenle hangi soruların sorulması gerektiğini ve hangi bilgilerin önemli olduğunu bilen biriyle konuşmak önemlidir. Önyargılı bir fikir ve yarım yamalak düşünülmüş çözümlerle acele etmek büyük bir cazibeye sahiptir. Ancak deneyimler bize planlamada herkese uyan hazır giyim yaklaşım diye bir şeyin olmadığını öğretti. En azından varsa ben hiç görmedim. Bir işletmenin nasıl çalıştığını, bir şirketin işleri neden belirli bir şekilde yaptığını ve belirli iş sorunlarının neler olduğunu bilmeden bir çözüm önermek saçma olur.

Geçenlerde bir meslektaşım bana, iş hedefleri üzerinde anlaşma sağlanmadan bir planlama sisteminin uygulanmasının başarılı olma ihtimalinin düşük olduğunu hatırlattı. Bunun benim dışımda birinden geldiğini duymak beni teşvik etti çünkü bunun bir projenin genel başarısının temel yapı taşı olduğuna ve bu iş hedefleri belgelenip üzerinde anlaşmaya varılana kadar ilerlemenin bir anlamı olmadığına inanıyorum. İdeal durumda bu belirleme, sorunları ölçen ve takip eden performans göstergelerinin belirlenmesine de yardımcı olur.

Genel hedefler üzerinde mutabakata varıldıktan sonra, boşluğun tam olarak anlaşılması, şirketin nerede olduğunu ve nerede olmak istediğini göstererek belgelenmelidir. Bu belgenin, mevcut sistemlerin nasıl çalıştığını, sınırlamalarının açık bir tanımıyla birlikte detaylandırması gerekmektedir.

Bu belge, bir dizi potansiyel çözüm hakkında açık bir tartışmanın kapısını açar. Bununla demek istediğim, endişelerinizi dinleyeceğiz ve başkalarının da benzer sorunları daha önce nasıl çözebildiğini paylaşacağız.

Neyin gerçekçi, yapılabilir ve işe yaraması muhtemel olduğuna dair sağlam bir kavrayışa sahip olmak, her iki tarafın da bu süreçte gerçekçi bir plana ulaşmak için çalışmasına yardımcı olur. Yolun her adımında birlikte çalışacak bir ortağa sahip olmanın, muazzam miktarda zaman, çaba ve hayal kırıklığından tasarruf sağlayabileceğinin önemini vurgulamak istiyorum.

Olasılıkları keşfettikçe fikirler, iş çözümünün üst düzeyden nasıl görüneceğine dair net bir vizyona dönüşmeye başlayacak.

Çözümler HER ZAMAN içten dışa doğru tasarlanmalıdır. İş sorunu, yeni iş süreçlerinin nasıl olması gerektiğine dair bir vizyona yol açar.

flowchart LR

    BP("İşletme 
    Süreçleri")

Değerlendirme aşamasının çıktısı, iş hedeflerini yüksek düzeyde özetleyen bir belge ve önerilen çözümü sunmak için ne gerektiğine dair bir tahmin olacaktır.

5.3 Tasarım Aşaması

Değerlendirme aşaması tamamlandıktan ve projeye devam etmek için bir anlaşmaya varıldıktan sonraki adım, yapılması gereken işi ve çözümün sağlanmasıyla ilgili çeşitli maliyetleri ayrıntılı olarak özetleyen bir belge oluşturmaktır. Müşterilerimizin çoğunun sabit maliyetli bir çözüm aradığını keşfettim. Bu belirli koşullar altında mümkün olabilir.

İş Süreçleri belirlendikten sonra danışmanın iş sürecini desteklemek için gereken verileri ve APS çözümünün gerektirdiği işlevselliği tanımlaması gerekir. Bir kez daha vurgulanması gerekir ki danışmanların, gerekli sonuçları sağlamak için gereken özelleştirmeleri1 açıkça tanımlayabilmeleri için, APS sisteminin güçlü yönleri ve sınırlamaları hakkında ayrıntılı bilgiye sahip olmaları gerekir.

flowchart LR
    subgraph APS Çözümü
     BP("İşletme 
    Süreçleri")
    end

Bu aşamada danışman Ayrıntılı Tasarım dokumanını sunacaktır. Bu, yeni sürecin akış şemasını ve gerekli olacak verilerin ayrıntılı listesini içeren bir belgedir. İdeal olarak her bir veri parçası tek bir yerde2 saklanacaktır. Ayrıntılı Tasarım dokumanı: veri kaynağını, veri sorumlu kişisini ve gerekirse verinin nasıl hesaplanacağına dair bir açıklamayı tanımlamalıdır.

flowchart LR
    subgraph Özelleştirme
        subgraph APS Çözümü
            BP("İşletme 
            Süreçleri")
        end
    end

Akış şeması, verilerin çeşitli sistemler arasında nasıl aktığını ve bunu başarmak için gereken çalışmayı açıkça gösterecektir. Bu şema, APS sisteminiz tarafından ERP sisteminiz veya üretim alanı veri toplama sisteminiz gibi diğer sistemlere gönderilmesi gereken verileri gösterecektir. Yeni APS sisteminiz için gereken entegrasyon çalışmalarının çoğu, aşağıdaki şemada tanımlanan dört temas noktası etrafında oluşturulacaktır.

Ayrıntılı spesifikasyonlara ek olarak, bir Planlama Yol Haritası (bazen Planlama Teknik Raporu3 olarak da anılır) oluşturmak için zaman ayırmanızı şiddetle tavsiye ederim.

Planlama Yol Haritası belgesi, yeni planlama sisteminin, planlama sistemiyle etkileşime giren işlevsel alanların her birini nasıl etkileyeceğini daha yüksek düzeyde açıklamak için tasarlanmıştır. Bu gerçekten önemlidir ve göz ardı edilmemelidir. Çünkü sisteminizin gerçek başarısı, şirketlerin birlikte çalışma biçimini değiştirmeye bağlıdır.

Değişemeyenler yeni APS sisteminizin gerçekten büyük faydalarını kaçıracaklardır.

Planlama Yol Haritası, yeni sistemin her bir işlevsel alanı nasıl etkileyeceğini, hangi yeni bilgilere sahip olacağını ve onlardan ne beklendiğini açıklamalıdır. Gerçek şu ki, çoğu insan değişime karşı mücadele etme eğilimindedir ve her grup kimliğini kaybetmeye direnecektir. Dolayısıyla yeni sisteminin kendilerine ve şirkete olan faydalarının, değişimin risklerine göre ne kadar daha fazla olduğunu tam olarak anlayana kadar sürekli eğitim ve rehberliğe ihtiyaç vardır.

Planlama Yol Haritası oluşturma süreci herkese öneride bulunma ve çözümün parçası olma fırsatı verir. Bu, yönetimin yalnızca değişimi zorunlu kıldığı durumlarda yaygın olan tepkilerin bir kısmını ortadan kaldıracaktır. Gerçek şu ki, planlama sistemlerinin başarısız olmasının en büyük nedenlerinden biri, en çok fayda sağlayabilecek olanların neden değişmeleri gerektiğini anlamamasıdır. Bunun kendileri için ne anlama geldiğini anlamıyorlar ve bunun şirkete nasıl bir faydası olacağını anlamıyorlar. Bu yüzden de işleri aynı eski yöntemle yapmaya devam etme eğilimleri var.

Hem Ayrıntılı tasarım dokumanını hem de Planlama Yol Haritasını müşteriyle birlikte incelemek danışmanın sorumluluğundadır. Tüm kilit kişilerin anlaşması olmadan Geliştirme Aşamasına geçmenin bir anlamı olmasa da, tüm gereksinimleri tamamlamadan önce bir prototip oluşturmanın gerekli olabileceği zamanlar olabilir. Bu, insanlar seçeneklerinden emin olmadıklarında devreye girebilecek analiz yoluyla felç olmaktan daha iyi bir seçenektir.

Prototip, herkesin yeni sistemin nasıl çalışacağını daha iyi anlamasını sağlar.

Sistem tasarımı, değerlendirmede belirtilen üst düzey kararları yansıtmalıdır. Ve bu tasarım aşaması, değerlendirmenin yanında projenizin en önemli ikinci aşamasıdır.

Tasarım aşamasında, müşteriden genellikle daha fazla işlevsellik ekleme yönünde baskı gelir. İstisnalar olmasına rağmen, daha fazla işlevsellik ekleme ihtiyacına karşı çıkılmalıdır çünkü bu eklemeler, projenin geri kalanını hızla riske atabilir.

5.4 Geliştirme/Prototip Aşaması

Geliştirme/prototip aşaması, bir dizi test verisi kullanılarak yeni sistemin bir başlangıç ama çalışan bir modelini üretmek üzere tasarlanmıştır. Bu çalışmaların çoğu tesis dışında tamamlanır ve tasarım aşamasında geliştirilen spesifikasyonlara dayanır.

Sistemin çalışma modelini olabildiğince erken oluşturmaya çalışmamızın nedeni, çoğu durumda kullanıcıların yeni sistemin kapsamını, onunla çalışmaya başlayana kadar anlamalarının çok zor olmasıdır. Bu, gerçekten görene ve dokunana kadar bazı seçeneklerini anlayamadıkları veya bazı potansiyel sorunları tahmin edemedikleri anlamına gelir.

Belli nedenlerden dolayı bu mutlaka ideal değildir ancak çoğu insan için tamamen yeni olan kavramların tanıtılmasıyla ilgili gerçekliğin bir parçasıdır. Genellikle prototip oluşturma aşamasında ortaya çıkan şey, yönlendirme tablonuzdaki verilerin hatalı, yarım yamalak veya eksik olduğunun farkına varılmasıdır.

Orta ve üst yöneticilerin anlaması gerekir ki, çoğu ERP sistemi Yönlendirme verilerini öncelikle maliyet gereksinimlerini karşılamak için kullanır ve bu nedenle çalışma sürelerinin mevcut gerçeği yansıtmayabilir. Hiçbir kontrol ve denge olmadığından bu durum genellikle zamanla daha da kötüleşir.

Açıkça sorulan soru şu: “maliyet bilgisi gerçeği yansıtmalı mıdır?” Ve cevap EVET elbette öyle olmalıdır. Lütfen bunun muhtemelen kaybedeceğiniz bir argüman olduğunu unutmayın.

Ancak hatalı çalışma süreleri tek sorun değildir. Yönlendirme tabloları genellikle aşağıdaki sınırlamalara sahiptir:

  • APS sistemlerinin işi belirli bir makineye ataması gerekirken, Yönlendirme verileri operasyon adımlarını iş merkezine göre tanımlarlar.

  • Aynı iş merkezindeki makineler eşit olmayabilir

  • Yönlendirme çalıştırma süreleri yalnızca hatalı olmakla kalmaz, genellikle kurulum sürelerini de içerir

  • Makineye özel çalışma süreleri genellikle mevcut değildir

  • Kurulum süreleri, Yönlendirme tablosunda mevcutsa, yalnızca ortalama kurulum süreleridir ve sıralamaya bağlı değildir

  • Sıralamaya bağlı kurulum sürelerini hesaplamak için gereken veriler genellikle mevcut değildir

  • Ayrıntılı ürün özellik verileri çoğu zaman mevcut değildir

  • Yönlendirme tabloları, takımlar veya operatörler gibi ikincil kısıtlamalara yönelik gereksinimleri nadiren tanımlar.

Bazen bu sorunlar tasarım aşamasında belirlenebilir ancak çoğu zaman daha doğru verilere duyulan ihtiyaç, kullanıcının programı etkileyen tüm kısıtlamaları anlamaya başlamasıyla ortaya çıkar.

Burada bunun genellikle tekrarlanan bir süreç olduğunu belirtmek gerekir. Deneyimli planlayıcıların bile manuel bir program oluşturduklarında attıkları tüm adımları her zaman anlatamadıkları ortaya çıkmıştır.

Mükemmel programı oluşturma konusunda fazla endişelenmekten kaçınmak için iyi muhakeme ve Seksen/20 süreci kullanılmalıdır. Örneğin, iki arka arkaya işlemi optimize etmeye çalışmak, aralarında bir tampon oluşturamadığınız sürece verimsiz olabilir.

5.5 Entegrasyon Aşaması

Çizelgeleme sisteminizi yönlendirmek için gereken verilerin çoğu ERP sisteminizden gelir. Bu genellikle Yönlendirmeleri, Malzeme Listelerini ve İş Emirlerini içerir. Bu bilgiyi APS sisteminizde saklamanıza gerek yoktur ve dolayısıyla bu verileri ERP sisteminizden APS sisteminize indirmek için hızlı ve akıllı bir süreçe ihtiyacınız olacaktır.

Bu yaklaşımı zorlaştıran iki faktör var;

  1. ERP sisteminizdeki veriler, APS sisteminizde ihtiyaç duyduğunuz sonuçları size verecek kadar doğru veya yeterince ayrıntılı olmayabilir. Örneğin çoğu ERP sistemindeki yönlendirmeler, iş merkezi düzeyinde gerekli olan kaynakları tanımlar. APS sistemleri makine seviyesinde planlama yapar ve gerçek dünyada bir iş merkezindeki tüm makineler tüm görevleri yerine getiremeyebilir ve/veya çalışma süresi, hangi makinenin kullanıldığına bağlı olarak değişebilir. Tipik olarak ERP verilerini değiştirmeniz veya manipüle etmeniz gerekecektir ve APS uygulama ortağınızın deneyimine büyük ölçüde güvenmeniz gerekebilir.

  2. Alaylı bilgisi, genellikle insanların kafasında olan, kağıt parçaları üzerinde bulunan veya elektronik tablolarda saklanan veri veya bilgileri tanımlamak için kullandığımız bir terimdir. Bu bilgi genellikle çizelgeleme kararlarının alınma şekli açısından kritik olabilecek ürün özellik verileri (renk veya genişlik gibi) biçimindedir. Ve şunu belirtmek gerekir ki alaylı bilgisini anlama ve entegre etme başarısızlığı, APS sistemlerinin başarısız olmasında muhtemelen en etkili nedendir. Alaylı bilgisi yalnızca verileri içermez, aynı zamanda kuralları da içerir. Dolayısıyla APS çözümünüz buluşsal yöntemler4 üzerine kurulmamışsa alaylı bilgisini simüle edemez.

Tipik olarak verilerin çoğu (%95 +) ERP sisteminizden veya diğer sistemlerinizden APS sisteminize akar. Ancak çoğu zaman iş emirlerinizin her birinin planlanan tarihlerini herkesin görebilmesi için ERP sisteminize geri göndermeye ihtiyaç duyulur. Bu her 5 dakikada bir planlayıcıyı aramak zorunda kalmadan en son bilgilere kolay erişim sağlar.

Bazı ERP sistemleri bunu istemeyebileceğinden, APS sisteminizden ERP sisteminize veri geri beslenirken dikkatli olunmalıdır. Örneğin, verilerin SAP’ye geri gönderilmesi, doğru şekilde yapılmazsa istisna mesajıyla ilgili sorunlara neden olabilir.

APS sistemlerini uygulamak için neredeyse 25 yıl harcadıktan sonra, kategorik olarak şunu söyleyebiliriz ki, APS sisteminizi uygulamak için harcadığınız zamanın büyük bir kısmı, verileri doğru şekilde elde etmek için harcanacaktır. Verileri doğrulamak için harcanan zaman zahmetlidir ancak gereklidir ve veri doğrulama araçları hem uygulama sırasında hem de sonrasında büyük miktarda zaman tasarrufu sağlayabilir.

5.6 Test Aşaması

Bu konu üzerine tek başına koca bir kitap yazılabilir ancak anlaşılması gereken önemli nokta, iki seviyeli testin olması gerektiğidir.

Birim testi, yazılımın temel işlevselliğini test etmek için tasarlanmıştır. İdeal olarak birim testleri tasarım özelliklerinde tanımlanmalıdır.

Entegrasyon testi, entegre sistemin işlevselliğini test etmek için tasarlanmıştır. Ve test uzmanının yeni bir siparişe, sipariş değişikliğine ve silinmiş siparişe ne olacağı gibi olası her iş senaryosu için belgelenmiş bir test plan 5 dosyası oluşturmasını gerektirir. Kullanıcılara kendi test plan dosyalarını oluşturma sorumluluğunun verilmesi şiddetle tavsiye edilir. Çünkü bu oluşturma, yeni sistemi nasıl kullanacaklarını öğrenmeleri için harika bir yoldur. Ayrıca yeni iş sürecindeki herhangi bir aksaklığı tespit etmek için bildiğimiz en iyi yoldur. Kullanıcının test/proje odası pilotunda 6geçirdiği her zaman konfor düzeyini artıracak ve yeni sisteme geçişlerini daha az stresli hale getirecektir.

Her test plan dosyası kaynak verilerini, gerçekleştirilecek adımların bir listesini ve beklenen sonuçları tanımlamalıdır. Entegrasyon testleri genellikle bir CRP’de gerçekleştirilir. Buradaki fikir, yeni sistemden etkilenecek herkesi, yoğun bir süre boyunca birbirleriyle etkileşime girebilecekleri bir odaya toplamaktır. Test/Proje Odası Pilotu genellikle üç ila beş gün sürer.

Test plan dosyalarının boş sayfalı bir kitapta tutulmasını ve kullanıcıların bir test geçtiğinde imza atmasını ve bir test başarısız olduğunda sorunu belgelemesini öneriyorum.

Test/Proje Odası Pilotu çıktısı neyin işe yarayıp neyin yaramadığının ayrıntılı bir şekilde anlaşılmasıdır. Pilot sırasında çözülemeyen sorunlar varsa birden fazla pilot çalışması yapmaya ihtiyaç duyulabilir.

5.7 Uygulama Aşaması

Uygulama aşaması, eski sistemi kapatmak ve yeni sistemi açmak için tamamlanması gereken tüm etkinliklerin yer aldığı bir “Canlıya Geçiş” planıyla başlar.

Mümkün olduğunda her iki sistemi paralel olarak çalıştırmak7 çok mantıklıdır. Bu, eski sistemi kapatmadan önce yeni sistemden aldığınız sonuçları eski sisteme göre doğrulamanıza olanak tanır.

Kural olarak, uygulama aşamasında CRP sırasında tanımlanmayan bir dizi sorun ortaya çıkacaktır. Bu nedenle ilk birkaç gün sistemde ince ayar yapmaya devam edebilecek birinin sahada bulunması önemlidir.

CRP gibi, “Canlı Yayına Geçme” planı da yeni sistemin ne kadar iyi çalıştığını doğrulayacak bir dizi testi veya raporu belgelemelidir. Tüm testler doğrulandıktan sonra sistem “Canlı” olarak kabul edilir. Ancak danışmanın önümüzdeki birkaç ay içinde ortaya çıkabilecek sorunları düzeltmek için kısa sürede hazır bulunmasına yinede ihtiyaç vardır.

Genellikle müşteri her sorunu izlemek için bir sorun listesi oluşturur. Bu liste, bir sorunun ne zaman rapor edildiğini, her sorunun önceliğini, konudan kimin sorumlu olduğunu ve her konunun durumunu göstermelidir. Bu liste, herhangi bir amaca hizmet etmekten vazgeçinceye kadar en az haftada bir kez gözden geçirilmelidir.

Kullanıcılar yeni sistemle neler yapabileceklerini gördükten sonra genellikle onu nasıl kullanacaklarına dair bir sürü yaratıcı fikir edinirler. Bu gerçekleştiğinde sisteme anında işlevsellik ekleme isteği ortaya çıkar. Seksen/20 sürecinde bir kez daha sağduyu devreye giriyor. Öncelik istikrara ulaşmaya odaklanmak olmalıdır. Çünkü hiçbir şey yeni bir sisteme olan güveni hiç bitmeyen bir hata ve sorun akışından daha hızlı yok edemez.

Mümkünse tüm yeni işlevsellik talepleri “2. Aşama” için yeni bir belgeye aktarılmalıdır. Bu iki önemli amaca hizmet eder. (1) her katılımcının fikirlerinin önemli olduğunu ve ele alınacağını bilmesini sağlar. (2) devam eden uygulamaya gereken şekilde odaklanılmasını sağlar.

Bir noktada danışman, “2. Aşamaya” ihtiyaç olup olmadığına karar vermek için müşteri üretici ile görüşecektir. İhtiyaç olması durumunda ek işlevsellik taleplerinin önceliklendirilmesine yönelik bir süreç izlenmelidir.

Danışman, her talep için net gereksinimlerin oluşturulmasına yardımcı olmalı ve bu gereksinimler standart ve tutarlı bir formatı takip etmelidir.

Gereksinimlerin formatı her zaman iş sorunu ve potansiyel iş faydalarıyla başlamalıdır. Daha sonra önerilen çözümü, yapılacak tahmini işi, zaman penceresini ve tahmini maliyetleri açıkça tanımlamalıdır.

Aslında Seksen/20 süreci yeniden başlıyor. Bu süreci sistematik olarak izlememek, halihazırda elde ettiğiniz tüm faydaları hızla geri alabilir.

  1. Customizations↩︎

  2. Master Data (Ana Veri)↩︎

  3. Scheduling White Paper↩︎

  4. heuristic methods↩︎

  5. yazar burada: script (betik) kelimesini kullanmış. Ama daha sonraki kullanımlarından bun scriptlerin yazılımdaki gibi otomatik olmadığını anlıyorum. Bu yüzden yazılım projelerinde daha çok kullanılan test plan dosyası veya dokumanı olarak değiştirmeyi tercih ettim. Bu test planları otomatik veya manuel olabilir.↩︎

  6. yazar conference room pilot, konferans odası pilotu kullanmış. Ben bunu test odası, proje odası pilotu olarak çevirmeyi tercih ettim.↩︎

  7. gölge modu (shadow mode)↩︎