Безбумажная технология - миф или реальность

[DGroot 8]

PMBOK(Project Management Body of Knowledge) - Свод правил по управлению проектами PMBOK Guide 3-rd Edition (Project Management Body of Knowledge), определяет круг знаний, необходимых для эффективного управления проектами.

Перевод на русский есть тут

<noindex>http://www.amazedev.com/pmbok-project-mana...y-of-knowledge/</noindex>

[sceptic 0]

PMBOK(Project Management Body of Knowledge) - Свод правил по управлению проектами PMBOK Guide 3-rd Edition (Project Management Body of Knowledge), определяет круг знаний, необходимых для эффективного управления проектами.

Перевод на русский есть тут

<noindex>http://www.amazedev.com/pmbok-project-mana...y-of-knowledge/</noindex>

Спасибо DSV и DGroot за весьма полезную информацию. Скачал, буду изучать. Правда я это уже видел у Верникова - 7 тонн менеджмента <noindex>http://vernikov.ru/management/project-management.html</noindex>, но PDF как-то привычней.

[Dmitry V. Liseev 0]

Есть такой Американский стандарт PMBOK по управлению проектами! Он соединяет опыт ведения проектов по разным направлениям деятельности. Давайте начнем создавать свой документ по интересуещей нас теме! Обсудим структуру документа и коллективно будем писать! Народ собрался талантливый, тема не затухает! Слабо!!!!!

Только это не стандарт. Это свод практик. Если кто-то тут руководит лидирующей в мире компанией в какой-то области, которая еще не описана в PMBOK, то может поделиться опытом. Если у кого-то нет опыта руководства проектами, то смысла что-то писать тут не вижу. Здесь в основном собрались инженеры, а не менеджеры среднего звена и не топы.

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

[ak762 318]

Если не устраивает софт, я пишу другой. Если меня не устраивает управление, я сам становлюсь менеджером и управляю. Если не устраивает руководство и его методы ведения бизнеса, я создаю с нуля новый бизнес

а поделитесь хоть что за новые флагманы капитализма вами созданы? а то например у GM кризис, а они и не знают что можно с нуля всё создать.

за весьма полезную информацию.

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

Особенно понравилось определение проекта - имеет начало и конец, почему-то сразу возникла ассоциация с Российскими нац. проектами

когда происходит подмена понятий гарантии государства на нац. проекты

так что книга по моему для тех кто думает что он в бизнесе, а не тех кто реально его делает

[DSV 2]

а поделитесь хоть что за новые флагманы капитализма вами созданы? а то например у GM кризис а они и не знают что можно с нуля всё создать.

Вот по моему правильное направление, примеры есть все читать умеют, но это там где то на западе или на востоке! Нужно расти самим и собирать собственную практику! Например в той сфере где мы ее имеем, в частности "Безбумажная технология". Может лес сбережем для наших детей и внуков! Чем черт не шутит! Мне заказали статью по делопроизводству! Хочу эту тему тоже там поднять!

[bomber 45]

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

А где это реализовано? На каком предприятии?

[DSV 2]

А где это реализовано? На каком предприятии?

Реализовано на частном предприятии ФЛИМ город Тольятти, сейчас пригласили продолжить работу дальше, обычный документооборот и оптимизация бизнес процессов!

[Странник 6]

...обычный документооборот и оптимизация бизнес процессов!

Нда... круто, однако.

Впрочем, некогда кое-кем уже <noindex>заявлялись</noindex> вещи не менее крутые.

Меж тем самая простая проблема - как послать КД на согласование комплектом, так что бы каждый докУмент сам нашёл свой маршрут, а спецификация стала способна к утверждению не прежде чем будут согласованы все в неё входящие детали, подсборки, ТУ, принципиальные схемы и т.п... и то

[DSV 2]

Меж тем самая простая проблема - как послать КД на согласование комплектом, так что бы каждый докУмент сам нашёл свой маршрут, а спецификация стала способна к утверждению не прежде чем будут согласованы все в неё входящие детали, подсборки, ТУ, принципиальные схемы и т.п... и то

Как выяснилось на практике, это не проблема. Проблема даже не в проведении извещения на изменения (что само по себе трудная задача), а в их количестве, причине изменения и ее содержании. Получив инструмент для работы, начали создавать такое количество документации, что без механизма управления изменениями и последствиями этих изменений стало не возможно работать! (За что боролись на то и напоролись) Остальные проблемы ушли в тень! Вот так получается господа теоретики и практики! Как я понял, нужна слаженная работа всего коллектива в достижении конечной цели, ложные цели надо отбрасывать иначе . С выходом статьи <noindex>http://www.docflow.ru/analitics/detail.php?ID=18792</noindex> топик можно закрывать!

[Странник 6]

Как выяснилось на практике, это не проблема.

Хм, пока мне видится что для автопоиска маршрута согласования КД не придумаешь ничего лучшего чем нагружение моделей и баз данных предприятия дополнительными атрибутами да логическими условиями. Например, посредством ряда логических операций маршрут определяют:

-принадлежность используемого в детали материала к классу металлов либо неметаллов;

-наличие и конкретное значение атрибута шероховатости по умолчанию;

-атрибут термообработки;

-атрибут покрытия;

-...

Для сборочных единиц появляются пополнительные признаки, вроде электрики, динамики, прочности, собираемости, метрологии и т. п.

Общее же количество маршрутоопределяющих атрибутов зашкаливает за 20, соответственно число возможных вариантов маршрутов составляет порядка 20!=2432902008176640000

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

Кроме того, инструментом формирования комплекта КД под согласование должна выступать электронная структура изделия (ЭСИ) либо её формализованное отражение - спецификация, а это уже требования не только к <noindex>глубине интеграции</noindex> PDM-системы со всеми используемыми на предприятии приложениями, но и к поисковику да функционалу API.

Проблема даже не в проведении извещения на изменения (что само по себе трудная задача), а в их количестве, причине изменения и ее содержании. Получив инструмент для работы, начали создавать такое количество документации, что без механизма управления изменениями и последствиями этих изменений стало не возможно работать! (За что боролись на то и напоролись)

Как я понял, нужна слаженная работа всего коллектива в достижении конечной цели, ложные цели надо отбрасывать иначе .

Собственно о том и речь, что повышение скорости изготовления документации только ужесточает требования к качеству управления, а особенно к классности управленца.

Организация же работ по принципу

вскрытие покажет

ещё никого до добра не доводила.

Например, светлой памяти SWR-PDM обладала замечательным качеством - у объекта могло быть сколько угодно версий, а в каждой версии сколько нужно пользователю итераций, при этом простые и извлечённые конфигурации модели могли быть свои в каждой из итераций. На фоне упоминавшихся ранее связок SolidWorks Explorer & SolidWorks Task Scheduler и автокомпоненты & Toolbox это открывало путь к запуску на утверждение уже продуманного и даже оптимизированного с точки зрения идеологии варианта изделия, но не излечивало менегеров от некомпетентности в проектировании и патологической ненависти к людям с творческими способностями.

P.S. Читать с бумаги действительно приятнее, но кто сказал что сотрудники уровня выше ведущего конструктора действительно ЧИТАЮТ документы? Они в лучшем случае смотрят на орфографию и пунктуацию, не сильно вникая либо не вникая вовсе в суть написанного. Например, в привычном мне классе технических систем одна жалкая справочка из сотни весит порядка 100 листов А4, комплект КД на всего один из десятков агрегатиков около 300 и более, ТУ - в районе 200, технический проект - около 700, причём всё это хозяйство переодически изменяется, а расписывается везде один и тот же, скажем так, мистер Браун.

[DSV 2]

Собственно о том и речь, что повышение скорости изготовления документации только ужесточает требования к качеству управления.

Спасибо за такой развернутый анализ проблемы, но я обратил особое внимание на одну Вашу фразу. Она мне кажется ключевой. Посмотрите ссылку

<noindex>Эффективное производства в России существует!</noindex> , это про результат внедрения мной первого этапа, скорей отношение руководства к результату. Сейчас я продолжаю работу и буду решать проблемы на стыке подразделений. Самое трудное, показать не эффективность работы по привычным схемам и привлечь на свою сторону персонал для продолжения внедрения новых возможностей управления. Вы знаете, наши чисто технические проблемы с атрибутами, схемами, набором функционала в программном обеспечении ни кого не интересуют. Все хотят, чтобы решили их проблемы! Я думаю на сегодня, главная задача пробиться сквозь мозги, тогда и схема согласования упроститься и документы после каждого изменения полностью распечатывать не будут и без бумажная технология станет реальностью, а не возможностью! Если Вас заинтересовал мой опыт, готов поделиться!

[Странник 6]

К сожалению, подобраться непосредственно к тексту статьи не помог даже Googl.

Вы знаете, наши чисто технические проблемы с атрибутами, схемами, набором функционала в программном обеспечении ни кого не интересуют. Все хотят, чтобы решили их проблемы!

И это совершенно справедливое желание.

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

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

[DSV 2]

К сожалению, подобраться непосредственно к тексту статьи не помог даже Googl.

Статью могу выслать у меня она есть!

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

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

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

[Странник 6]

Когда начинаешь внедрение, то неожиданно выясняешь, что люди уже привыкли многое по нормативной документации не делать! Приходится заниматься прописными истинами и это вызывает глухое раздражение.

Если бы глухое...

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

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

Некоторые атрибуты просто отсутствуют в существующей нормативной документации и ее надо писать заново, а это еще трудней доказать!

Доказывать? Интересно, как можно доказать что либо человеку ну ничегошеньки не понимающему в рассматриваемой области техники, но тем не менее имеющему твёрдое предубеждение, подкреплённое материальным интересом и многолетним навыком?

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

Например, производство рвёт и мечет при получении извещения о изменениях в КД даже если всё вполне технически и экономически обоснованно. Если скорость выпуска КД резко возрастает, но не повышается качество проектирования, то изменений становится только больше, что собственно и было отмечено выше по топику. Таким образом, фундамент безбумажного документооборота это в большей степени эффективность связки CAD/CAE/PDM, чем собственно WORKFLOW.

Впрочем, никакой CAD всё одно не перекроет отсутствия правильной идеологии построения изделий.

Еще один существенный фактор, это скорость восприятия новой мысли в технической среде! Если проект внедрения не учитывает этот фактор, риск неудачи резко увеличивается!

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

Из всего сказанного я делаю вывод, что не программный продукт является основным фактором успеха, а формализация процессов и готовность персонала к изменениям.

Мне думается, что рано или поздно всё одно потребуется сработать по принципу

Делай как я!

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

[SVB 188]

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

Странник, а эта статья: <noindex>http://www.cadcamcae.lv/N50/7.htm</noindex>

не из вашей "скромной конторки"?

[DSV 2]

Уважаемые коллеги, я вижу практически полное совпадение взглядов! Мне это нравится! Просто СОФТ для меня телега! Я на многих из тих работал, знаком с вендорами и разработчиками, не дай Вам бог узнать, что они в курилке говорят про свой продукт! Я пересказывать не буду! Дыры в СОФТе будут всегда, большие, маленькие, критичные и не очень! Наше дело инженерное сделать работу быстрее, грамотнее, дешевле и ни кто своим шоу нас не должен сбивать сэтой мысли! Факторов влияющих на успешную работу много, но нельзя эту работу сделать без людей! Я верю, что миф станет реальностью, но не скоро, тем более не сейчас! Если собрать в команду фрилансеров и поселить в одном городе, чтобы иногда встречаться, сделать можно гораздо больше!

Всегда рад помочь, Ваш DSV

[Странник 6]

Странник, а эта статья: <noindex>http://www.cadcamcae.lv/N50/7.htm</noindex>

не из вашей "скромной конторки"?

По вполне понятным причинам подробно говорить не буду, отмечу лишь 2 с моей точки зрения важные вещи:

1. бизнеспроцессы в той "скромной конторке" организованы весьма недурно и без всякого WORKFLOW;

2. их забугорные конкуренты равной "весовой категории" сидят в основном не на ProE даже, но на CATIA, наверно от

делать нечего, друзья.

А вот интересное заявление, <noindex>отсюда</noindex>.

...в NX нет никаких проблем назначать требования не на всю модель,а на конкретные её части, в том числе и задавать зоны и впоследствии технолог (или кто ещё) может спокойно ткнув в эту зону (или геометрический элемент) посмотреть все связанные с ней требования. Механизм есть и достаточен для работы. Естественно кроме кнопок нужен СТП и не один, но принципиальная возможность есть и как показывает практика всё это вполне достижимо. Не так давно удалось сходить на экскурсию в КБ Сухого и ГСС. Там полный букет характерных российских проблем - низкие зарплаты, средний возраст выше среднего, куча тонкостей связанных с твердолобостью заказчика - то бишь Минобороны, итд... Но при этом народ вполне себе спокойно работает на базе 3D моделей, все согласование и утверждение только по 3D, чертеж из себя представляет ОДИН изометрический вид, без размеров и надписей. Как сказали - для "мокрой" подписи по требованию приёмки.

Может имеет смысл организовать коллективную экскурсию в КБ имени Сухого?

[DGroot 8]

Что будет с книгами через 10-15 лет

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

Спешите смотреть, пока ролик не забанили по просьбе правообладателя.

<noindex>http://web.rambler.ru/post/chto-budet-s-kn...erez-10-15-let/</noindex>

[DSV 2]

Что будет с книгами через 10-15 лет

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

Спешите смотреть, пока ролик не забанили по просьбе правообладателя.

<noindex>http://web.rambler.ru/post/chto-budet-s-kn...erez-10-15-let/</noindex>

Посмотрел ролик, прямо скажу впечатляет! Если будет соответвующий сервис под этот дивайс, то просто замечательно! А сейчас мы наблюдаем другую картину, продают мобильные модемы и прошивают в модеме симку зарегистрированную на територии, переезжаешь в другое место и с тебя берут по роуменгу, а другую симку вставить нельзя, нужно новый модем покупать! Вот такой сервис по русски! И нам только ждать и надеется, что родное государство повернется к нам лицом!

[Странник 6]

Что будет с книгами через 10-15 лет

Когда человек разумный видит предлагаемый товар, то скурпулёзно оценивает возможные выигрыши, но первый вопрос к продающему всёже о цене.

В рассматриваемом рекламном ролике главное это абсолютное доминирование в мире единой электронной валюты и электронная идентификация личности.

Значит французами прогнозируется ещё 10-15 лет...