Tesis mühendisliğinde tasarım geçmişini izlemenin profesyonel bir yolu nedir?

Projelerimizdeki tasarım belgelerine (Biyogaz ve atık enerji santralleri) bakarsanız, neyi inşa etmeyi planladığımızı, ancak diğer seçeneklerin dikkate alınmadığını ve neden atıldıklarını öğrenirsiniz. Bu bilgi sadece mühendislerin kafasında bulunur. Bazen bir bitki, bazen mühendisler arasında geçiş yaparak yıllarca kavramsal bir aşamada olacaktır. Bu yüzden kendimi bir iş arkadaşının geçen yıl düşündüğü ve nihai olarak attığı bir seçeneği tekrar gözden geçiriyorum.

Tasarım kararlarını, 'neden' ve 'neden-nots'ları izlemenin iyi bir yolu nedir? Sanayide başka bir yerde denenmiş, test edilmiş ve kullanılmış bir yaklaşımı şiddetle tercih ediyorum.

Ek bilgi: Şirketim ISO 9001 sertifikası alacak, bu KG rejimine uyan bir yaklaşım tercih edilecektir.

Bunun ne kadar bilgi istediğinize ve bunu ne kadar resmi olarak izlemek istediğinize bağlı olduğunu düşünüyorum. Şu anda kulağa hoş geliyor, bu bilgilerin hiçbiri hiçbir yere yazılmıyor, ki bu kesinlikle ilk sorun. Ancak, takip etmeyi düşünmediğiniz bir çözüm için bilgi bırakmak, en iyi ihtimalle, zamanın optimalden daha az kullanılmasıdır. Hangi fikirlerin kaydedilebilecek kadar etli olduğunu tanımlamanız gerekir. Bir toplantınız varsa ve masaya bir düzine fikir konur, ancak yarısı neredeyse atılırsa, bu fikirlerin ne olduğunu ve neden atıldıklarını not etmek ister misiniz? Muhtemelen çok düşük seviyeli bir analiz için çok çaba harcanıyor, ama yine de tasarım kararları.

Bunu sadece üzerinde gerçek bir iş yapma aşamasına ulaşan fikirler için yapmak daha sezgisel görünüyor. Bu şekilde, zaten somut bir şeyiniz var ve bunun bir proje dosyasında dosyalanması gerekiyor, ki umarım zaten sahip olduğunuz bir şeydir. Bu sistem gerçekten sadece gelecekteki projeler için referans materyalleri üreteceğinden, bu materyalleri arşivlemek veya mevcut bir sistemi elden geçirmek için tamamen yeni bir sistem oluşturmanın iyi bir fikir olacağını düşünmüyorum. Mevcut tasarım yönetim sisteminize entegre etmenin bir yolunu bulun.

Sahip olduğunuzdan emin olacağım tek anahtar, farklı tasarımlarınızı anahtar parametrelerine göre sınıflandırmanın bir yoludur. Alanınız hakkında fazla bir şey bilmiyorum, ancak her bir projenin karşılaması gereken belirli tasarım parametreleri olduğunu varsayıyorum (fiziksel boyut, kapasite, tesis türü, vb.). Bunların bir yerde kolayca görülebildiğinden emin olun, böylece yeni bir projeye başlarken, çeşitli açılardan benzer eski projeleri tanımlayabilirsiniz. Atılan bu fikirleri bu klasörlerde sakladıysanız, yardımcı programlarını geçerli projenize analiz edebilirsiniz.

Bununla birlikte, genel olarak bunun çok derinlerine inmek konusunda da uyarmak istiyorum. Yine, projelerin çok daha kısa olduğu farklı bir sektörde çalışıyorum ve bu nedenle, çok daha fazlası var, ancak bazı ürünler onlarca yıldır varlığını sürdürüyor ve 15-20 revizyonu var. Gerçekleştirilen tasarım değişiklikleri için revizyon geçmişinin korunması çok önemlidir. Müşterinin geçmişte ne verildiğini, değişikliklerin ne zaman yapıldığını ve neden yapıldığını bilmek, geçmiş hataları tekrarlamamanın ve eski tasarımlara doğru bir şekilde bakım yapmanın anahtarıdır. Ancak hiçbir zaman tam olarak gerçekleştirilmemiş tasarımları katalogladığınızda, temel verilerin üzerine gerekli olmayan verileri eklersiniz ve işler kaybolmaya başlamadan önce sıralayabileceğiniz çok şey vardır. Sanki kulağa hoş geliyor ' sağlam iletişim ve iyi bir deneyim için bir yedek arıyor. Bu projeler el değiştirdiğinde, ilgili mühendisler ilgili tüm bilgileri iletmek zorundadır. Neyin dikkate alındığını bildiğinizden emin olmak istediğinizi anlıyorum, ancak kayıtlarınızı gereksiz verilerle doldurmamak için bu arzuyu öfkelendirmenizi tavsiye ederim.

Trevor'ın bu cevabı tüm felsefeye oldukça iyi geliyor, ama ayrıntılardan daha fazlasını elde etmek istiyorum.

İlk olarak, alternatif kayıtların neden tutulmadığını anlayın. Bu muhtemelen bir öngörü sorunu veya bir depolama (kağıt veya bilgisayar) sorunu olarak başladı.

Geçmişte bir zamanlar birisi alternatiflerin yararlı olmayacağını düşündü, bu yüzden atıldı veya silindi. Bu muhtemelen bir şirket kültürü sorunudur. Bu bir sorun olarak tanımlandığına göre, şirket çapında gündeme getirilebilir. Önceden oluşturulmuş kayıtların tutulması kolaydır.

Orijinal mühendisler alternatiflerin yararlı olabileceğini düşünse bile, depolama maliyeti (fiziksel veya bilgisayar) nedeniyle belgeleri saklamamış olabilirler. Bu durumda, bu sorunun şimdi çözülmesi gerekir. Artık durum böyle değilse, kayıtların tutulması maliyetli bir teklif olmadığı için kelimenin şirkete yayılması gerekiyor.

İkinci olarak, alternatif karşılaştırma yöntemine bakın. İki alternatif değerlendirme kategorisi vardır: düşünce ve hesaplama.

Düşünce karşılaştırmaları, kavram formundan başka hiçbir şey yapmamak için yeterince hızlı atılan fikirlerdir. Bu fikirler ilk kez çok hızlı bir şekilde atılırsa, muhtemelen kaydedilmeleri gerekmez. Onları itibarsızlaştırma çabası o kadar önemsiz ki, tekrar gözden düşecekler.

Gerçekte hesaplama aşamasına geçen alternatifler bir şekilde tutulmalıdır. Hesaplamalar veya planlar ilk kez yapıldıysa, kaydedilecek bir şey zaten var. Fikir bir çıkmaz yol olsa bile, iş zaten yapılmış, bu yüzden dosyaya koyun! Tarihlendiği sürece referans gösterilebilir.

Bir karar verildiğinde bir not yazın (özellikle birisine değilse dosyaya). Bu gelecekte zaman kazandırır, ancak sürece bir adım ekler. Bu, genel olarak geliştirilmiş dokümantasyon ile birlikte üzerinde çalışılması gereken bir şeydir.

Son olarak, her şeyi tarih! Nihai kayıtları tutmak için zaten mevcut olan sistemlerle çalışmayı deneyin, her şeye bir tarih ekleyin. Diğer organizasyon yöntemleri başarısız olsa bile, alternatiflerin sırası öğelerin üzerindeki tarihler kullanılarak yeniden oluşturulabilir.

Aşağıda beyaz eşyaların, tüketim mallarının ve OEM üreticilerinin belge fikirleriyle ilişkilendirdiğim üç genel yöntem yer almaktadır.

Kullanıcı Arabirimi (Kavramsallaştırma) fikir belgeleri
Büyük, etki dolu ve çığır açan ancak şu anda uygulama için dikkate alınmayan fikirler için proje numaraları oluşturun. Bu fikirleri çoğu durumda bir veya iki sayfalık bir belgede ve projeyi rafa almadan önce belgeleyin. Arama motoru teknolojisi ve yazılım büyümesi ile bu fikirler aranabilir bir veritabanında saklanabilir. Mevcut iş gücünün geçiş doğasıyla bunu belgenin fikrini iyi bir şekilde buldum. Teknoloji ve uygulama yöntemindeki büyüme ile teknolojinin ayrıntılı dokümantasyonu daha az önemlidir çünkü teknolojinin daha iyi ve iyileştirilmesi mümkün olacaktır.$t+1$

Tasarım incelemeleri (NPD - Yeni Ürün Geliştirme)
Tasarım, mühendislik tasarımı kararlarının belgelenmesine yardımcı olabilecek iyi bir süreci gözden geçirir. Bu daha teknik belgeler olma eğilimindedir, reddedilen fikirler iyi belgelenmeme eğilimindedir. Çoğu organizasyonda tasarım incelemeleri faz kapısı modelinin bir parçasıdır .

Arka uç (Üretimde veya üretimde) fikir belgeleri Yeni fikirleri belgelemek
için mevcut bir değişiklik yönetim sistemini kullanan kuruluşlar buldum . Bu sistemde mühendis fikri basit bir sayfa veya sayfa belgesinde önerir. Fikir gelecek için gözden geçirilir ve kabul edilir veya rafa kaldırılır. Bu özel kuruluş SAP'yi değişim yönetimi için kullandı, bu nedenle sistem teknoloji tabanı araştırmasına daha az yatkındı, ancak onlar için iyi bir performans gösterdi.

Özetle, çoğu fikir aşağıdaki nedenle rafa kaldırılmıştır

• Fikri / öneriyi yürütecek mali kaynakların eksikliği
• Fikri / öneriyi yürütecek insan kaynakları eksikliği
• Mevcut proje planına uymuyor
• Pazar henüz yeni teknolojileri benimsemeye hazır değil

Bu nedenle parça fikirleri iyidir, çünkü yukarıdaki engeller çözüldüğünde fikirler gerçekçi çözümler haline gelir.

Referanslar:

• Değişim yönetimi
• Tasarım yorumu
• Faz kapısı modeli

Diğerleri genel olarak belgeler hakkında çok iyi yorumlarda bulundular, ancak muazzam bir şekilde yardımcı olacak belirli bir yazılım sınıfı önermek istiyorum.

Ben bulmak sürüm kontrol yazılımı konularında bu tür için mükemmel olmak. Maalesef yazılım geliştirme dışında çok yaygın değil, ancak diğer alanlarda yetişmesi sadece zaman meselesi.

İşte bir örnek: Araştırma grubumda çoğu insanın kullandığı bir Subversion deposu var (Popüler bir alternatif yazılım git ). Sürüm kontrolünü kullanmak, biri ayrıldıktan sonra araştırma projelerinin sürekliliğini sağlamaya yardımcı olur, çünkü bir projeyle ilgili dosyaların çoğu orada, ne zaman yaptıkları ve (eğer doğru yaparlarsa), mantığı. Ayrıntılara gireceğim.

Diyelim ki bilgisayarınızda tüm dosyaları içeren bir klasör var

Her şey yapıldığında otomatik olarak tarihlenir (diğerlerinin "yükleme" olarak adlandırabileceği sürüm kontrol terimi). Taahhüt mesajı kısa bir not görevi görür (Mahendra Gunawardena'nın önerdiği gibi, daha büyük kararlar için daha uzun ve daha resmi notlar isteyebilirsiniz). "X yaklaşımının uygulanabilir olmadığına karar verdik. Bunun yerine Y'yi deneyeceğiz. X yaklaşımı ile ilişkili dosyaları sildik ve Y yaklaşımı için yeni bir CAD modeli oluşturduk."

Daha sonra, X yaklaşımının aslında doğru olan olduğuna karar verirseniz ve silinen dosyaları kazmak istiyorsanız, zor değildir. Herhangi bir parçayı kolaylıkla eski sürüme geri döndürebilir ve oradan devam edebilirsiniz.

Bu yaklaşımın bazı ek faydaları vardır. İlk olarak, dosyaları başkalarıyla paylaşmayı oldukça kolaylaştırır. Depoyu (geçerli sürüm veya tüm sürümler anlamına gelebilecek bir sürüm kontrol terimi) kontrol ederler ve düzenli olarak güncellerler (bunu yapmak için komutlar vardır). Temel olarak, herkes senkronize edilir. İkincisi, temel olarak ücretsiz bir yedek (eski sürümler) alabilirsiniz. Bununla birlikte, normal yedekleri tutmanız gerekmediği anlamına gelmez, sadece yanlışlıkla kaybolan dosyaları geri yüklemek için başka bir seçeneğiniz vardır. Tüm depoyu da yedeklemenizi tavsiye ederim.