Разработка проект.док в системе AutoCAD, СМК. Стандарт предприятия Опции

[Luka]

СИСТЕМА МЕНЕДЖМЕНТА КАЧЕСТВА ISO 9001
ООО "Форум LavTeaM"
Стандарт предприятия

СТП № ХХ/ХХ

Разработка проектной документации в системе AutoCAD
-------------------------------------------------------------------------------

Неоднократно слышал вопросы по этому вопросу, поэтому решил поднять тему.

Основные вопросы:
1. Что это такое, для чего нужна, и нужна ли вообще.
2. Разработка - проблемы и тонкости.
3. Способы реализации на предприятии.

[Luka]

Такое оформление шапки выло выполнено не ради простого оформления. Поясню.

1.

СИСТЕМА МЕНЕДЖМЕНТА КАЧЕСТВА

Даже если у вас нет Системы Качества (далее СК), эта тем в любом случае относится принадлежит к этому вопросу.
Ибо, конечная цель - удовлетовенность Заказчика.
1.1 Хорошим оформлением чертежей за счет того, что мы добились единообразия исполнеия.
1.2 Сокращением сроков выполнения работ за счет оптимизации.
1.3 Уменьшения стоимости.
Мотивация перед руководством и персоналом, что данный документ нужен для решения внутренних проблем - ошибочна.
2.

ISO 9001

Этот стандарт можно рассматривать как руководящий документ. Там даны четкие определения по многим вопросам. Например:
ГОСТ Р ИСО 9001-2001. Общие положения. Самая первая строка ГОСТа гласит: "Для создания системы менеджмента качества требуется стратегическое решение предприятия".
Для нашего Стандарта мы можем расшифровать так: прежде, чем начать разработку документа необходимо осознать его необходимость, степень заинтересованности руководства и персонала.
Опять же, если не идет о сертификации по ISO, то читая ГОСТ в призме своих проблем можно найти много чего и, главное, понять с чего же все же начать.
ГОСТ тяжеловат для освоения, но если вы не определите Цели, Задачи и Ресурсы на начальном этапе и не обоснуете их - будет очень тяжело при подготовке и реализации.
3.

ООО "Форум LavTeaM"

У каждого предприятия свои особенности. Нельзя взять чужой и его внедрять. Т.о. документ разрабатывается для конкретного предприятия.
4.

Стандарт предприятия

Статус документа, в нашем случае Стандарт, т.е. незыблемость его исполнения на предприятии без исключений, кроме одного, если Заказчик поставил определенные условия и это зафиксировано в договоре (кстати, за это можно попросить отдельную денюжку).
5.

Разработка проектной документации в системе AutoCAD

Собственно область, в которой мы хотим добиться результата.

---------------------
Продолжение следует.....

Сообщение отредактировал Luka - 24.05.2006 - 07:23

[Luka]

После того, как опрелились основные организационные моменты, с чего начать?
Я долго искал информацию, перелопатил и проанализировал массу документов, в том числе Стандарты российских и зарубежных компаний и пришел к выводу, что за основу лучше взять американский национальный стандарт:
 volume1_Page_001.jpg ( 43.55 килобайт ) Кол-во скачиваний: 94


Как наиболее полный. Ксати, большая часть предприятий взяла именно его за основу. Именно за основую, и заточило под свои нужды. Ряд вопросов там освещен крайне куцо или вообще нет: совместная работа, 3Д и т.п.
Полный текст стандарта можно взять здесь (5Мб):
https://tsc.wes.army.mil/products/standards/aec/2_0_Std/volume1.pdf
Есть еще и второй том (12Мб):
https://tsc.wes.army.mil/products/standards/aec/2_0_Std/volume2.pdf
Но там только символы, к нам они как-то отношения не имееют.

---------------------------
Пока все. Вопросы, предолжения, замечания по этому этапу?

[kpblc]

> Luka : Классные ссылки, спасибо.
У меня только один встречный вопрос (только Бога ради не обижайся, это не наезд!) - в результате надо написать общую канву СТП? Или что-то иное? Потому как в зависимости от целей и предложения будут немного разные.
Одно дело, если хочется собрать предложения по переработке американского стандарта, другое - если разработать основные принципы наладки ПО для стандартизации работы, будет третий вариант - будет и третий путь. Ну и так далее.
На dwg.ru я на эти грабли уже наступил в полный рост (где-то с полтора года назад). Если будет интересно, скину ссылку на обсуждение тамошнее.

[Luka]

kpblc
Скорее третье - систематизация выполнения работ, куда входит и конфигурирование ПО и разработка шаблонов, но заточка ПО и шаблоны это техническая сторона, как и разработка самого СТП.
Цель одна - уддовлетворенность Заказчика ибо только это приносит реальные деньги. Если расмматривать вопрос как экономия за счет оптимизации, то, проследив дальнейшую цепочку упремся опять же в цель, указанную выше. Т.к., экономия - это сверхприбыль. Сверхприбыль, это дополнительные возможности манипуляций на рунке: манипулирование ценой товара (проекта в нашем), развитие (обучение персонала, автоматизация, увеличение штата и т.п.) предприятия, увеличение пакета услуг ну и т.д.. Для чего? Удовлетворить клиента...
Добавлено Luka в [mergetime]1148453642[/mergetime]
Добавлю.
Ты отвлекись вообще от слова АвтоКАД, программное обеспечение. У нас в пакете СМК более 20-ти документов, цель везде одна. И описана она в самом первом "Политика в области качества".

[Luka]

Во, глянь-ка сколько их, аж 40-к ..... Посчитай сколько относится к сфере ИТ.. -))))

Сообщение отредактировал Luka - 24.05.2006 - 10:10

[Luka]

Ну раз начало тяжелое, мы её проскочим. Я отпишу в общем, без официоза, сами думайте. -))
Первые части - стандартные для документов:
===============НАЧАЛО============================
1. Цели и задачи.
Ну, здесь мы упоминаем о том, что данный документ разработан с целью оптимизации и унификации выполнения проектных работ с графическими документами в редакторе AutoCAD, а так же систематизации и организации совместной работы проектировщиков.
А так же, что стандарт устанавливает правила и порядок работы с документами….
2. Ответственность и область распространения.
2.1 Ответственность несут те-то
2.2 Участвуют генеральный директор и еще там замы если есть.
2.3 Распространятся на все производственные подразделения, которые хоть как-то имеют отношение к документации
3. Внесение изменений.
Пересмотр, отмену и внесение изменений в настоящую документированную процедуру осуществляется ……СМК……… на основании …ответсвенного…
4. Терминология
Здесь мы пишет то, что не понятно будет юзерам из нашего документа.

=================КОНЕЦ===========================

Теперь поехали обсуждать?

Основные моменты, которые нужно осветить
А) Общие настройки (единицы, масштабы …)
Б) Организация работы внутри файла (координаты, внешние ссылки, слои…)
Если нет электронного архива (хотя можно и отдельным документом):
В) Организация совместной работы (структура папок, способы архивации и т.п.)
Г) Идентификация (имена) файлов.

Такой вариант устроит? Или лучше по другому организовать? У меня по другому -)

[kpblc]

Поступлю-ка я по сволочному Лично меня интересует, если честно, именно твой вариант. Потому как более или менее хотя бы часть пунктов А...Г трудностей не представляет (особенно учитывая, что тот же самый ADT предоставляет - там особо не повольготничаешь). Судя по всему, у тебя есть если не готовый, то по крайней мере работающий, вариант.

[McArrow]

Все это очень интересно . Однако такой вопрос - кто этим, по идее, должен заниматься на конкретном предприятии? Если у руководства нет желания что либо менять, то рядовой инженер вряд ли что-то сможет сделать.
Или же большинство читающих уже занимают довольно высокие должности?

[nucleus]

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

Сообщение отредактировал nucleus - 24.05.2006 - 20:23

[kpblc]

Не знаю, оффтоп это или нет, но промолчать не могу (привяжусь все же к каду, стандарт еще не успел прочитать полностью).
> nucleus : Как тебе будет такой вариант (сам я его покушал полной ложкой): сидишь, делаешь файл. Надо отдать соседу - рядом сидит. Спокойно делаешь полный комплект и отдаешь ему по сети. Он чего-то там шипит, матерится вполголоса, через 2 дня выдает обратно доделанный кусок. Теперь твоя очередь плеваться - он поменял все настройки слоев, текстовый и размерный стиль, да еще и стиль печати поменял. Возвращай обратно!
И это было в конторе с 4 (!) конструкторами. Что говорить о тех, кто вынужден работать хотя бы среди 2-3 десятков людей.
Что сейчас расхлебываю:
- Текстовые стили - кто как хочет, так и делает (принцип "чо хочу, то ворочу" в полный рост).
- Размерные стили там же.
- Настройки слоев - каша неимоверная
- Объемы файлов - как в кошмаре программиста: из 200 гигов места под КТО свободно 20 метров. И это нормально считается.
- Разбитая штриховка, исправленные (или разбитые) размеры.
Это в первом приближении - как тебе наборчик? Я тихо прифигел, когда его увидел
Вдобавок надо учитывать разнородность ПО - кто-то на ADT, кто-то - на LT, кто-то на ABS. А решение должно быть одно и сразу для всех

[Luka]

kpblc
Я уже говорил, это документ ДСП. А-Г, можно добавить еще Д, я до него уже дорастаю, но скорее всего это будет отдельный документ, а именно Системные настройки - файлы, папки, реестр, . программ.
Если есть какие-то вопросы, вот я и предлагаю пройтись просто по списку и обсудить, там не все гладко, есть и подводные..

nucleus
Как правило руководство САПР (ИТ). А могут и энтузиасты, собрались молодняком с разных отделов и наваяли, сколько можно в бардаке жить. Собственно эта тема для вас, энтузазистов.

Mc Arrow
Хочешь работать как хочешь, создай свою фирму. Вот тут уж точно не получится "как хочешь".
СМК - да, этщ нужно руководству, юзерам тоже, но боятся, т.к. этож Работать придется, просто так не отмажешься. Только деваться некуда, завтра все равно будет и это даже от руководства не зависит..
Стандарт по графике - ну это уже чисто юзеровский документ. Начальство к нему как-то равнодушно. У нас его даже в перечне не было. Тут ситуация зарождалась из того же, что и у kpblc, инженеров в одном отделе достало, стали сами унифицировать, здальше цепная реакция, другие отделы - а как вы это сделали? Начали свое ваять, полдела, пошли непонятки между смежниками. Пришлось вмешаться, оторвать задницу и заняться разработкой корпоративного. Мне-то он тоже на х.. не нужен -)

Сообщение отредактировал Luka - 25.05.2006 - 10:44

[kpblc]

На dwg.ru болтается проект СТП - dwg.ru/dwl/177 (немного отличается в результате от проекта, приведенного в "САПР на базе AutoCAD - как это делается") и там же указана и ссылка на ветку по обсуждению этого дела. Некоторые соображения у меня на блоге - http://my.opera.com/kpblc/ и там прикрепленные посты. Если интересно и есть время
Просто дублировать практически все это вместе я не вижу смысла, если честно.

Сообщение отредактировал kpblc - 25.05.2006 - 12:32

[McArrow]

Luka
Я же, наоборот, послностью с этим согласен. Унификация может оказать просто неоцеоценимую услугу. Все эти примеры, которые привел Крыс, я хорошо почувствовал уже в своей студенческой жизни.

В общем, следим, читаем, вникаем

[~Илюха~]

Luka

Цель одна - уддовлетворенность Заказчика ибо только это приносит реальные деньги.

Закачкику побарабану как мы работаем.
nucleus

эта свистопляска прежде всего нужна руководству. в целях упорядочивания внутренних трудовых отношений. и разруливания конфликтных ситуаций.

И руководству зачастую тоже.

По этому подобная стандартизация это ЛИЧНАЯ проблема самой нижней цепи.
А вопрос этот можно решить только с участием и ПОНИМАНИЕМ людей из управления. Поэтому тут или "пан или пропал", т.е. или комплексное изменеине проектирования предприятия или как кривая вывезет.
Это кстати если не вникать в способ производства в наших условиях, когда один проект делают несколько организаций(По разделам), иначе проблема находит себе новое развитие.

[kpblc]

> nucleus : Спасибо
В продолжение темы, ессно, ИМХО всю дорогу.
Если в самом начале применения СТП, то надо хотя бы примерно определить "ближайшие" задачи - для того, чтобы их решать, и "общие", которые ставит руководство. Это самый важный этап - фактически формирование собственного ТЗ. Чем грамотней оно расписано, тем быстрее будет идти работа. Как я шел (если интересно, читаем дальше), применительно к AutoCAD'y:
1. Унификация текстовых и размерных стилей. Никаких шаблонов, встретил завтра другую любовь и все, привет, шаблоны переделывать. Проще сделать программно - создать текстовый стиль и на его основе размерный, потом его активировав - не такая уж и большая проблема на самом деле.
2. Унификация типов линий. Создаем собственный файл с описаниями, его подгружаем (как - пока оставляем за кадром).
3. Унификация имен слоев. Пользователю надо предоставлять иллюзию свободы - менять вес линии и цвет слоя, но тип линии - это уже фигушки. Текстовые линии привязаны к создаваемому в п.1 стилю, ибо нефиг. Имена слоев формировать по определенному заранее закону, и не отступать от него ни на йоту в дальнейшем - может оказаться необходимым учитывать данные только с определенных слоев, имена которых формируются динамически. Мне пару раз понадобилось. Ох и матерился же я...
4. Унификация имен блоков - оборудования, изделий и проч. Ручное рисование тех же кранов или выключателей крайне желательно отключать.
5. Продумать хранение данных - по максимуму, учитывая особенности конкретной фирмы. Так, например, у меня никто из конструкторов не заполняет свойства файла. Поэтому можно туда записывать определенные данные, читать оттуда (особенно учитывая, что до этих свойств можно добраться и без открытия файла как такового, просто используя методы Windows). Зачем это? Ну хотя бы для того, чтобы файлы проекта А не пробовали записывать в папку проекта Б. У меня это пока не реализовано, додумывать надо.
6. Самое главное. Предоставить удобный инструмент для использования. Слайд меню - к черту. Выбор из текста - туда же. Человек так устроен, что графику он воспринимает лучше и запоминает больше, чем текст, особенно технический. Значит, максимальное использование графического представления.
7. Все, что я рассказал по поводу блоков, это, конечно, здорово, но и про БД забывать не надо. Их тоже "на карандаш".
---
Также надо дополнительно продумать вариант загрузки приложений, ускорения работы и вариант сетевой работы. Например, то, как сделано в ruCAD'e - установка блоков через XML-меню, это, конечно, здорово, но не для интенсивной сетевой работы. Как выяснилось, все меню у них хранятся на локальных машинах, а потом каким-то хитрым образом синхронизируются. Лично я считаю это лишней тратой сил - вполне достаточно сделать БД на основе любого движка, организовав к ней подключения и формирование запросов.
Загрузка через собственный стартер тоже, наверное, неплохо, но мне пока достаточно дополнительного меню
Ускорение работы программ... Тут зачастую оказывается, что критичных мест не так уж и много. Но это уже к вопросу квалификации программиста.

По этому подобная стандартизация это ЛИЧНАЯ проблема самой нижней цепи.

Не согласен. Категорически. Как только ты сможешь убедить руководство в преимуществах, все встанет на место, и тебе будет полный карт-бланш. Суть в следующем. Если те же самые конструкторы теряют примерно 2 дня на то, чтобы собрать все файлы, имеющие отношение к одному проекту, да привести их в порядок (в смысле почистить от мусора, изменить стили, прочие подобные телодвижения), а потом ОВ-шники, например, теряют еще 2 дня на приведение файлов от АС в нормальый вид, то минимальные лиспы здесь уже окажутся очень неплохими - все примитивы в ByLayer, содержимое блоков - по ByBlock, к примеру, изменить текстовые стили и размерные стили, поменять настройки "ихних" слоев... Все это не так уж и сложно на самом деле.
Насчет развития - это да. Но! Отдавай на сторону, пускай файл там корячат как хотят, а потом ты при загрузке файла получаешь нормальный стандартизированный вид (без всяких усилий), каково будет?

[~Илюха~]

kpblc

Как только ты сможешь убедить руководство в преимуществах, все встанет на место, и тебе будет полный карт-бланш.

На это дело может уйти очень много времени нервов и жизни, а результата не достигаеш. Я был свидетелем подобных войн в 5 разных фирмах. так что из личного опыта или делай изначально всё сам или будеш затычкой во все дыры. Чтоб руководство дало добро на всё это оно должно в этом разбираться и курировать или очень доверять и хорошо платить тому кто этим будет заниматься вместо него. А тут всегда стена.
Не спорю может эта ситуация присуща моему региону и т.п. Надеюсь что у остальных всё проще.

[kpblc]

В общем-то тут просто надо политику подключать и сначала немного прогнуться под руководство и конечных пользователей, выяснить, что им надо "из того, что можно пощщупать". И на это и давить, и делать именно для этого, не забывая о высших материях

[~Илюха~]

Ну не знаю конечный пользователь, у нас так точно, ещё не дорос до того чтоб осозновать как им эффективнее работать. Как легче они все знают, а как эффективно оч мало. Поэтому извините тут я бы рекомендовал диктатуру и не "пролетариата" а Руководителя группы. Этот человек на данном этапе формирования культурного слоя проектировщиков любого раздела по строительству есть Бог для исполнителя и должен знать максимально хорошо как профессию так и технику реализации.

Сообщение отредактировал ~Илюха~ - 26.05.2006 - 10:24

[kpblc]

Где ж ты такого найдешь? Любая предоставляемая программа (а СТП надо поддерживать сначала программно) должна работать:
1) быстро (без тормозов)
2) надежно (без падений по непонятным причинам)
3) просто (просто ею пользоваться)
4) удобно (запомнить легко, что где лежит и когда домой )
Все эти пункты равноценны.