| Об выбор САПРов |
[Дек. 9, 2009|01:35 am] |
Два полных дня с утра до вечера дня провел за изучением вопроса о САПР (включая слушание докладов, беседы с поставщиками, чтение документации в количестве и просмотр мнений в форумах). Результаты:
1. Все ведущие "поставщики решений" нажрались "лучших продуктов" в виде закупки компаний, и теперь наперегонки пытаются переварить их в "продуктную линию, закрывающую весь спектр". Переваривание получается у кого-то плохо, у кого-то очень плохо.
2. Ситуация похожа на дорогой ресторан: сначала ты обнаруживаешь меню с 500 позиций, и (глядючи на цены) понимаешь, что за такие деньги ты как минимум должен не ошибиться в выборе -- но только салатиков находишь пятьдесят, из них "простых овощных" десяток. При обсуждении меньше всего играет роль питательность и вкус, но зато идут красивые названия типа "с синхронной муравой" (оказывается травой, по форме листа, вкусу и запаху неотличимой от обычной петрушки из соседней столовой). Затем тебя на полтора часа оставляют наслаждаться собственным аппетитом ("настройка кухни на ваш особенный салат"), затем приносят явно не то, что ты ожидал укусить -- но делают это все так торжественно, что придраться не к чему.
3. Проблемы те же, что и с внедрением больших ERP-систем: либо предприятие начинает работать так, что решение "из коробки" подкручивать не нужно, либо подкручивать будет стоить столько же, сколько заставить предприятие работать так, как требует этого программа. Беда в том, что из коробки отнюдь не все решения работают.
"Процесс решает всё" -- САПРы не слишком помогут при закупке одного модуля на одном рабочем месте. Нужно много разных модулей на разные рабочие места, и чтобы они все работали вместе. Это самое трудное.
И вот тут наступают настоящие проблемы -- приходится интегрировать полупереваренные уже в одной компании но до сих пор существенно различающиеся моделью данных программы бывших разных производителей. А это засада, которой вы не найдете ни в одном рекламном буклете.
Про ситуационную инженерию методов все они ничего не слышали, но в плане activity modeling -- все имеют какие-то варианты схемы для нескольких видов workflow, проектов и т.д. Почему несколько? Ну, там ведь в ядре сидят несколько продуктов разных разработчиков, у каждого из которых когда-то был свой вариант воркфлоу...
4. В ERP есть хотя бы шанс, что руководство разберется, что ему пытаются продать (другое дело, что таки не разбираются -- но это другой вопрос). В САПР этого шанса практически нет. Архитектурные и технологические решения, которые на много лет вперед определяют лидерство или отставание, не видны -- они под капотом.
5. В сотрудников российских офисов не стрелять: они продают, как умеют! Опыт показывает, что самые интересные сведения находятся в R&D отделениях фирм-поставщиков, и требуются немалые усилия, чтобы местным сейлзам добыть актуальную информацию, а не маркетинговое бла-бла-бла. Кстати, про маркетинговое бла-бла-бла: в САПРах, оказывается, этого не меньше, чем в ERP-мире. Или даже больше: материалы все под большим секретом, описания продуктов максимально неподробны, на вебсайтах ничего кроме бла-бла-бла-лучше-всех-бла-бла нет.
6. На сегодняшний день в части работ в части замысла-ТЭО-проектирования моим лидером является Dassault Systemes V6:
-- продукты, конечно существенно недопереварены (так, данные 3D-проекта и жизненного цикла инжиниринга "синхронизированы" уже, но имеют до сих пор разные называния и структуру), но уже четко видно, в какую сторону это переваривание идет -- от документоцентрики стремительно отказываются, архитектура становится SOA. Есть вижн (чего не нашел у других). А вижн вполне может быть конкурентным преимуществом.
-- системная инженерия со всеми ее свойствами (рекурсивность, инкрементальность, итеративность и т.д.) лежит в основе всей продуктной линейки, масштабируемость налицо. От фотоаппарата до небоскреба будет проектироваться одним и тем же софтом, и лежать все это будет в одной и той же базе (которая, кстати, у в ноябре 2009г. вышедшего продукта V6E2010X может находиться в облаке, чтобы ресурсов всегда было "достаточно"). V-диаграмма поддерживается программно (ага, прямая аллюзия с "аппаратно"). У многих других продуктов это требуется специально настраивать, если догадываешься о ее существовании. Тут ей обучают в порядке пользования программой. У меня есть впечатление, что курсу системной инженерии вполне можно учить с использованием этого программного обеспечения: там "жизненный цикл" у любого объекта базы данных.
-- интерфейсы не хочется лизнуть, как у Apple, но они явно поприятнее, нежели у конкурентов. Более того, коллаборативность там понимают абсолютно правильно: работа в итоге должна быть в среде, похожей на виртуальный многопользовательский мир типа Second Life.
Самое забавное, что продавцы Dassault Systemes про эти конкурентные преимущества практически не рассказывают. Такое впечатление, что они привыкли играть в помодульное сравнение с конкурентами (пуговицы на их пиджачках сравниваются с пуговицами на пиджачках конкурентов, ткань подкладки с тканью подкладки и т.д. -- общий же фасончик и удобство в носке всей конструкции мало кого интересует). Более того, значительная часть того, что делает Dassault Systemes на российских предприятиях будет вредна: более отсталые продукты будут явно лучше, ибо позволят поднять производительность на старых бумажных процессах, переведя бумагу в электронную форму. Уйти от процессов проектирования, похожих на бумажные, российским производствам будет боязно -- дураков переучиваться на старости лет нетути.
Обращу особое внимание, что все мои симпатии относятся к "совокупности модулей", ибо по каждому отдельному модулю возможна религиозная война с модулями других поставщиков -- и вовсе не факт, что отдельные модули эту войну выиграют (особенно, если рассматривать какие-нибудь узкие сегменты specialty engineering).
Недостатков у Dassault Systemes V6 тоже тьма тьмущая, начиная с самой высокой по сравнению с конкурентами цены и заканчивая "эта фича у нас есть, но вам она будет доступна только в версии 2012года".
7. В любом случае, с САПР нужно разбираться подробно, ибо системной инженерии без программной поддержки не бывает. И хотелось бы понять, от кого эту поддержку можно получить получше и подешевле (и не говорите мне, что "лучше" и "дешевле" не бывает -- вся история технологии именно про это. САПРов это тоже касается).
В следующих сериях этой саги о САПРах бы рассказал:
-- о жути таблично-формовых мастдайных интерфейсов (или у вас абсолютно единообразный ужасный таблично-формовый интерфейс, или единообразные команды с не пойми какими ключами, или вам нужно учить десятки удобных текстовых и графических DSL -- которые вы просто не сможете все запомнить. Что делать?)
-- о ситуационной инженерии методов и "настройке" монстрообразных корпоративных приложений типа САПР, EPR и т.д.
-- о софтовых приложениях для предприятия vs приложения предприятия к софтам. |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
manoul
loved
cheerful
amused
