Який професійний спосіб відстеження історії дизайну в машинобудуванні?


9

Якщо ви подивитеся на проектну документацію в наших проектах (біогазові та енергетичні установки), ви дізнаєтесь, що ми плануємо будувати, але не, які інші варіанти розглядалися і чому вони були відкинуті. Ця інформація лежить лише в голові інженерів. Іноді завод протягом багатьох років буде в концептуальній стадії, іноді перемикаючись між інженерами. Тому я вважаю, що я переглядаю варіант, який колег вважав та остаточно відкинув минулого року.

Який хороший спосіб відстежувати дизайнерські рішення, "чому" та "чому - ні"? Я б наголосив на такому підході, який перевіряли, перевіряли та застосовували в інших галузях промисловості.

Додаткова інформація: Моя компанія буде проводити сертифікацію ISO 9001, переважніший підхід, який відповідає цьому режиму якості.

Відповіді:


3

Я думаю, це залежить від того, скільки інформації ви хочете, і наскільки формально ви хочете її відстежувати. Зараз це здається, ні одна інформація не записується ніде, що, очевидно, є першою проблемою. Але відкладати інформацію для рішення, яке ви не збираєтеся шукати, це в кращому випадку не оптимальне використання часу. Вам доведеться визначити, які ідеї розроблені достатньо, щоб бути записаними. Якщо у вас є зустріч, і десяток ідей ставлять на стіл, але половина майже одразу відкидається, чи хочете ви робити записи про те, якими були ці ідеї, і чому вони були відкинуті? Це багато зусиль для того, що було, мабуть, дуже низьким рівнем аналізу, але вони все ще дизайнерські рішення.

Мені здається більш інтуїтивним робити це лише для ідей, які досягають стадії виконання певної роботи над ними. Таким чином, у вас вже є щось відчутне, і це просто потрібно подати у файл проекту, який, сподіваюся, є у вас вже є. Оскільки ця система справді буде генерувати довідкові матеріали для майбутніх проектів, я не думаю, що було б гарною ідеєю створити цілком нову систему архівації цих матеріалів або капітальний ремонт існуючої системи. Знайдіть спосіб інтегрувати його у вашу поточну систему управління дизайном.

Я хотів би переконатись, що у вас є спосіб класифікації різних конструкцій за їх ключовими параметрами. Я мало знаю про ваше поле, але я припускаю, що є певні параметри проектування, яким повинен відповідати кожен проект (фізичний розмір, потужність, тип заводу тощо). Переконайтеся, що вони легко помітні десь, щоб, починаючи новий проект, можна було визначити старі проекти, подібні за різними ознаками. Якщо у вас є ці відкинуті ідеї, що зберігаються в цих папках, ви зможете проаналізувати їх корисність для вашого поточного проекту.

Однак я також хочу взагалі попередити про заглиблення в це питання. Знову я працюю в іншій галузі, де проекти набагато коротші, і як таких, їх набагато більше, але деякі продукти існують у певній формі вже десятиліттями, і є 15-20 ревізій. Ведення історії перегляду фактичних змін дизайну, які були впроваджені, є дуже важливим. Знання того, що було дано замовнику в минулому, коли були внесені зміни, і чому вони були внесені, є ключовим для того, щоб не повторювати минулі помилки та правильно обслуговувати старі конструкції. Але коли ви каталогізуєте проекти, які ніколи не були повністю реалізовані, ви додаєте несуттєві дані поверх істотних даних, і ви можете розібратися лише стільки, до чого речі почнуть губитися. Це звучить як ти шукаєте заміни для міцного спілкування та гарного досвіду. Коли ці проекти змінюються, інженери, що займаються, повинні передавати всю відповідну інформацію. Я розумію, що хочу переконатися, що ви знаєте, що було розглянуто, але я радив би приборкати це бажання, щоб не залити ваші записи непотрібними даними.


Мені дуже подобається ця відповідь і попередження в останньому абзаці та другому абзаці. Я побачу, що пропонують інші.
март

1

Ця відповідь Тревору дає добру оцінку всій філософії, але я хочу детальніше ознайомитися.

Спочатку з’ясуйте, чому альтернативні записи не ведуться. Це, ймовірно, почалося як передбачуваним випуском, або проблемою зберігання (паперового чи комп'ютерного).

Свого часу в минулому хтось думав, що замінники не будуть корисні, тому їх викинули або видалили. Ймовірно, це проблема культури компанії. Тепер, коли це було визначено як питання, його можна підняти в масштабах усієї компанії. Зберігати записи, які вже були створені, легко.

Навіть якщо оригінальні інженери вважали, що альтернативи можуть бути корисними, вони, можливо, не зберігали документи через вартість зберігання (фізичного чи комп’ютерного). Якщо це все-таки має місце, цю проблему потрібно вирішити зараз. Якщо це вже не так, слово потрібно поширити по всій компанії, що ведення обліку не є дорогим пропозицією.

По-друге, подивіться на альтернативний метод порівняння. Існує дві категорії альтернативного розгляду: думка та обчислення.

Порівняння думки - це ідеї, які відкидаються досить швидко, що вони ніколи не змушують їх оприлюднювати будь-що, крім форми концепції. Якщо ці ідеї були відкинуті так швидко вперше, то, ймовірно, їх не потрібно записувати. Зусилля щодо їх дискредитації настільки банальні, що їх просто знову дискредитують.

Альтернативи, які насправді перейшли до етапу розрахунку, слід зберігати у певній формі. Якщо розрахунки чи плани були зроблені вперше, тоді вже є на чому зекономити. Навіть якщо ідея виявиться тупиковою, робота вже зроблена, тому занесіть її до файлу! Поки він датується, на нього можна посилатися.

Напишіть записку (до файлу, якщо не для когось конкретно), коли буде прийнято рішення. Це економить час у майбутньому, але це додає кроку до процесу. Це над чим працювати над покращенням документування в цілому.

Останнє, побачити все! Спробуйте попрацювати з уже створеними системами, щоб зберегти остаточні записи, просто додайте дату до всього. Навіть якщо інші методи організації не вдається, порядок альтернатив можна відновити, використовуючи дати на елементах.


0

Нижче наводяться три загальних методики того, як білі товари, товари народного споживання та виробники ОЕМ я пов’язував із ідеями документа.


t+1

Огляди дизайну (NPD - Розробка нового продукту)
Дизайн розглядає ще один хороший процес, який може допомогти документувати проектні рішення. Це, як правило, більше технічної документації, ідеї, які відкидаються, як правило, не є добре задокументованими. У більшості організацій огляди дизайну є частиною моделі фазових воріт .

Документальна ідея документації (в або закрити виробництво)
Я знайшов організації, що використовують існуючу систему управління змінами для документування нових ідей. У цій системі інженер пропонує ідею в простому документі або на сторінці. Ідея переглядається та приймається або зберігається на майбутнє. Ця конкретна організація використовувала SAP для управління змінами, таким чином, система була менш придатною для пошуку технологічної бази, але все-таки добре підходила до них.

Підсумовуючи, більшість ідей зберігаються з наступної причини

  • Відсутність фінансових ресурсів для реалізації ідеї / пропозиції
  • Брак людських ресурсів для реалізації ідеї / пропозиції
  • Не вписується в поточний план проекту
  • Ринок ще не готовий прийняти нові технології

Тому добре простежувати ідеї, адже коли вище перешкод вирішуються, ідеї стають реалістичними рішеннями.

Список літератури:


0

Інші зробили багато хороших коментарів щодо документації загалом, але я хочу запропонувати певний клас програмного забезпечення, яке допоможе надзвичайно.

Я вважаю, що програмне забезпечення для управління версіями є прекрасним для таких питань. На жаль, це не надто часто зустрічається за межами розробки програмного забезпечення, але це лише питання часу, перш ніж він захопить в інших сферах.

Ось приклад: Моя дослідницька група має сховище Subversion, яке використовує більшість людей (Популярне альтернативне програмне забезпечення - git ). Використання контролю версій допомагає забезпечити безперервність дослідницьких проектів після того, як хтось піде, тому що більшість файлів, що мають відношення до проекту, є разом із докладним журналом того, яку роботу вони виконували в той час, і (якщо вони роблять правильно) обґрунтування. Я докладу.

Скажімо, у вас на комп’ютері папка, яка містить усі файли

Все автоматично датується, коли це зроблено (термін контролю версій для того, що інші можуть називати "завантаження"). Повідомлення про вчинення діє як коротка примітка (як запропонувала Махендра Гунавардена, вам можуть знадобитися довші та більш офіційні записки для більш великих рішень). Ви описуєте зміну файлів проекту, говорите: "Ми вирішили, що підхід X недоцільний. Замість цього ми спробуємо Y. Видалили файли, пов'язані з підходом X, і створили нову модель CAD для підходу Y."

Потім, пізніше, якщо ви вирішите, що підхід X насправді є правильним, і ви хочете викопати видалені файли, це не важко. Ви можете легко повернути будь-яку частину на стару версію та продовжувати звідти.

У цьому підході є деякі додаткові переваги. По-перше, це робить обмін файлами з іншими досить просто. Вони просто перевіряють сховище (термін управління версіями, який може означати або поточну версію, або всі версії), а потім регулярно її оновлювати (для цього є команди). В основному всі синхронізовані. По-друге, ви можете отримати резервну копію (старіші версії) в основному безкоштовно. Зважаючи на це, це не означає, що вам не потрібно підтримувати нормальні резервні копії, лише у вас є інший варіант відновлення випадково загублених файлів. Я настійно рекомендую також створити резервну копію всього сховища.


Я подумав, що VCS не справляються з бінарними краплями добре. Вони можуть обробляти файли, але вони втрачають можливість бачити , що саме змінилося, тобто текст "відрізняється".
туман

Ви можете уникнути цього певною мірою, написавши точно те, що змінилося в повідомленні про вчинення. Крім того, вам потрібне додаткове програмне забезпечення для висвітлення змін, що виходять за межі простого вигляду. Я бачив способи розрізнення зображень та бачив програмне забезпечення для візуалізації CFD, яке дозволяє бачити, чим відрізняються два різних файли даних. Я неясно згадую, що деякі програмні засоби для САПР мають таку можливість. Це не так просто, як відрізняти текстовий файл, але в принципі це не неможливо. Хочу також підкреслити, що це проблема не для керування версіями сама по собі, скоріше проблема з нашою здатністю до перегляду відрізняється.
Бен Треттел

Щодо ефективності зберігання даних, то лише краще розміщення відмінностей у базі даних. Я думаю, що деякі системи контролю версій будуть робити це для бінарних файлів, хоча мені доведеться уважніше вивчити це.
Бен Треттел
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.