Комментарии 35
"Руководящий документ" — мощная вещь, аналога которой в IT-компаниях часто нет. Насколько часто приходится его обновлять в вашей организации?
Взгляд на практику оформления проектов почти не меняется.
Ведь в нем можно хранить больший объем знаний(особенности использования изделий, не очевидные вещи, типовые ошибки), комментирование и прочие плюшки условной «базы знаний».
И уже во второй компании реализую стандарты и базы знаний на wiki-движке.
Нужен базовый функционал вики — авторизация и механизм защиты статей от изменений (или даже механизм согласования изменений), вставка картинок из буфера обмена, возможность ссылки на локальные файлы, встраивания видео с ютуба и т.п. Mediawiki c дополнениями вполне подходит.
Статьи делятся на четыре основные категории:
Инструкции (краткое пошаговое руководство по конкретному действию);
Правила (основные технические и/или организационные ограничения);
Информация (сведения, описания, технические и/или организационные);
Сценарии (use case в стиле Алистера Коберна. Например, «Пользователь выполняет действие в программе»).
И соответственно максимально «схлопнуть» текстовую составляющую засчёт перекрёстных вики-ссылок.
Выглядеть всё будет очень скучно. Везде полстранички текста или пяток пунктов с несколькими картинками. Мне как-то стало интересно и я посчитал в своём случае сколько займёт стандарт при распечатке в А4 — получилось порядка 400+ листов, без повторяющихся статей. Хотя внешне всё легко и просто.
Но главное — оно будет работать и будет актуальным. У такого подхода есть один плюс — удобство для потребителя информации.
Отдельный вопрос — приучить людей пользоваться ресурсом, и ни в коем случае не печатать в бумаге.
Перед началом есть смысл продумать структуру и правила в т.ч. и именования самих статей на вики, оформление статей внутри, договориться о применяемой нотации описания процессов, категориях и т.п. Сделать небольшой стандарт по разработке стандарта.
-А как у вас разграничение прав происходит? А чем вы обеспечиваете неизменяемость и целостность данных? А нету ли там данных по 152-ФЗ(а там, как минимум будет ФИО пользователя)? А информации класс присвоен? А на основании каких документов?
Т.е. по сути все сведут к ISO 27001. А это во-первых стоит конских денег, а во-вторых работать под этим самым ISO сильно не комфортно.
Я к тому что не стоит придумывать проблемы самому себе. Если есть практика выкладывания документов в сетевые каталоги, то и вики проблем не доставит.
-Вы понимаете чем файл, отличается от документа? (подразумевался электронный)
Мы задумались, почитали, осознали и пришли к выводу, что нет у нас никаких елЕктронных документов, а файлики… ну они и в Африке файлики, никакой юр.силы не имеют и ссылаться на них нигде нельзя.
Поэтому, вдвойне интересен опыт не очень крупных организаций.
Привет, в двух организациях занимался созданием базы знаний на Dokuwiki именно для конструкторов. Хотя сейчас бы взял Mediawiki — выглядит интереснее, возможностей побольше, есть интеграция с Libre office. Не все сотрудники могут освоить markdown.
В основном в wiki размещаются инструкции, текстом со скриншотами или видео. Принять wiki в качестве какого-то официального документа… Не знаю… в маленькой организации это не нужно, а в большой (с наследием из прошлого) невозможно в силу приверженности людей к другому формату официальных документов.
Основные проблемы при создании такого портала — это определить структуру (я организовывал разделы по продуктам pdm решение, cad решение, ecad и ТД.) и стиль статей, научить пользоваться коллег, разобрать свалку существующих данных в word, pdf, txt и постепенно переписывать их в markdown (можно использовать pandoc для этого). На наиболее частые вопросы пользователей лучше написать по статье, и отправлять их туда, через некоторое время освоят поиск и будут сначало пользоваться им, вместо обращений в поддержку. Наверное лучшей практикой будет если получится организовать чтобы пользователи сами писали статьи (не только по использованию ПО, но и по решению задач из своей профессиональной области, это ведь и есть концепция wiki), тогда это будет не просто портал с инструкциями, а некоторый процесс управления знаниями.
А что у других?Божечки-кошечки, как же вы правы. Смотрю на наш офис и плачу. Да, графические станции, относительно неплохие зарплаты, но офис, социалка, отсутствие кондея, заказ мебели по пол-года (постоянная борьба с «давайте чините») и немой вопрос в глазах руководства «а чего это от нас сотрудники увольняются?»
Причем, вот пришел ты такой к руководителю подразделения и говоришь: «чтобы потом не было больно давайте мы организуем собеседования тет-а-тет, будем агрегировать проблемы и решать их. Да просто проведем соц. опрос на тему кому чего надо?» Не провели, ничего не сделано, зато KPI и «мотивационный план». И все собеседования one-to-one начинаются после того как человек уже положил заявление.
В общем, мое мнение — культура тянется с СССР, а не с запада, в отличии от IT. А в СССР во главе стояла не эффективность и удобство сотрудников, а план.
В чëм разрабатываете текстовые документы?
А что у других?И сразу захотелось у Вас работать.
А вообще вы молодец что сумели настроить рабочую систему для удаленки!
Удаленка для комплексных проектировщиков, по моему мнению, подходит не очень, всё же пока еще очень много моментов на разных стадиях проектирования, которые обсуждаются с чертежами в руках. Если посмотреть на ваш пример, то в рамках небольшого чисто конструкторского бюро это работает неплохо.
В руководящем документе описано всё самое спорное среди конструкторов, что плохо описано в ГОСТе:
- Можно-ли размещать тех. требования не над штампом, а слева от него?
- Стоит-ли использовать запись про неуказанные предельные отклонения или лучше поставить все отклонения прямо на размерах?
- Можно-ли проставлять позиции на разных видах или лучше поставить все выноски на главном виде?
- Что делать, если сварной шов нестандартный?
- Указывать-ли прокат в штампе или указывать только материал?
- По какому принципу раскрашивать сборки и как помечать поверхности разного назначения?
- Сколько и каких шайб класть под головку болта и под гайку?
Ответы на эти вопросы позволяют сделать все чертежи безобразно единообразными и исключить споры в коллективе на эти темы.
С точки зрения резервного копирования PDM-системы зря вы надеетесь только на Яндекс. Даже более крупные и именитые облачные провайдеры теряли данные клиентов. И снапшот ни когда не будет являться полноценной резервной копией. Так как в общем-то не является полной и отдельно лежащей копией данных.
Представьте что выполняя какой-то очередной проект вы внезапно и по независящей от вас причине потеряли все наработки за последний месяц. Как это скажется на вашем бизнесе?
Если уже сложно или лень разобраться с какой-нибудь бесплатной версией Veeam Agent for Microsoft Windows или чем-то подобным. То хотя бы руками минимум раз в неделю копируйте критически важные для работы данные на локальную машину и храните хотя бы пару-тройку таких копий. Тем более объемы у вас пока не запредельные как я понял. Современные каналы интернет позволяют прокачивать такое за вполне разумное время.
А что насчёт безопасности интеллектуальных данных? Получается, что в любой момент времени каждый сотрудник имеет доступ ко всем проектам, которые он может легко сохранить и при желании (или ошибке) распространить?
Что насчёт лицензирования того же Solidworks — выдали всем персональные лицензии или настроили где-то сервер лицензий?
Вопрос воровства данных сотрудниками открыт. Я не видел рабочих решений в этой области. Всегда можно на флешке или по почте забрать себе чертежи с которыми работаешь.
Что касается чертежей на флешке — как правило, инженер если их и забирает, то исключительно для себя.
Твои выполненные проекты — это и есть твой опыт работы.
У каждого есть личная пополняемая база моделек (причем, не только собственноручно нарисованных, но и скачанных с сайта производителя — просто экономится время на поиск), таблиц, чертежей, схем, готовых спецификаций более-менее часто встречающихся изделий или узлов, программ для контроллеров и т.д., которые в случае чего можно взять как шаблон, чуть чуть подправить — и готово.
Если мне где-то скажут, что категорически нельзя подключать свою флешку — я такой организации сразу скажу пока-пока и пойду искать другую. Потому что все свои наработки держать исключительно в памяти — это так себе.
Ну и правило работает в обе стороны — получается, что я не только унести, но и принести с собой ничего не могу, и буду сидеть изобретать собственные велосипеды с нуля в 4 раза дольше.
Если это не какой-то очень специфический проектный институт, наработки из которого в другом месте абсолютно бесполезны.
Глубже она потому, что для того чтобы защитить такого рода данные необходимо воткнуть IDS\IPS систему, отключить флешки и запретить пронос телефона в охраняемый периметр. В общем, все то что так любят на больших гос. оборон. заводах. Вот только, все эти решения снижают КПД на порядок, увеличивают расходы и срок разработки.
Преувеличение же заключается в том что, допустим инженер упер проект(ы). А дальше то что с ними делать?
1. Проекты делаются под конкретного заказчика. Т.е. «продать» решение невозможно т.к. изготовлено под конкретные требования, конкретной организации.
2. Чаще всего в отрасли все плюс-минус знают решения друг-друга и себестоимость гуляет в пределах 10-15%. Причем, очень многое зависит от поставщиков — фирме А дают скидку в 10%, фирме Б нет. Зато у фирмы Б есть свое производство деталек.
В итоге, максимум что можно подчерпнуть из утекших данных, это какие-то «удобства» и best practies. В целом, можно заплатить денег тому же инженеру и он просто все то же самое расскажет рисуя на бумаге эскизы.
Большую угрозу представляет утечка не на этапе проектирования, а на этапе тендера — «За сколько там выставляются конкуренты, какие скидки им дают партнеры и на какой элементной базе будут делать.» Потому, что тогда можно идти к своим поставщикам и давить на них, снижать ЧП и т.д., и т.п.
Отличная статья! Несколько профессиональных вопросов:
- Используется ли у Вас скелетная/опорная/компоновочная геометрия?
- Изделия у Вас не маленькие. Как ведёте работу. Каждый сотрудник ведёт отдельный проект? Или же, проектирование коллективное?
- Все это тоже описано в Руководящем документе?
2. По всякому, зависит от сроков.
3. Концептуальными проработками занимаюсь лично я и ведущие конструктора. Тут подходы и сроки никак не регламентированы. Это — изобретательство. Его в документе не пропишешь. А вот когда уже основные узлы продуманы и просчитаны можно подключать остальной коллектив на «допиливание» и выпуск КД.
Опыт организации труда в конструкторском бюро