Не очень то доверяю мнению разработчиков и продавцов. Первые хвалят свое детище, т.к. свой ребенок всегда лучше всех. Вторые тоже хвалят, т.к. продать надо. Хочется объективного мнения от непосредственного пользователя. Я думал вы один из них. Спасибо за картинку, но, полагаю, она собрана в Navisworks, а не средствами AutoCAD/nanoCAD.
Про AutoCAD MEP вы не уловили мою позицию, но это не критично. Я согласен с вами, что этот продукт именно для ОВ/ВК по российским стандартам не очень то подходит. Существуют более удачные продукты для этого сегмента. Однако идеологически он построен очень хорошо. Настраивается всё и вся. Главное знать, где искать. Мы его применили для промышленного проектирования в 2012 год. Уперлись только в неподъемность сложных моделей в AutoCAD. По позициям моделировать в AutoCAD MEP было нормально, но получить общую модель из десятков позиций в AutoCAD — никак.
Именно поэтому и киваю на то, что надо бы свой, российский продукт, написанный исключительно под промышленное проектирование, примерно как Aveva, на российском графическом движке. Интерфейс заимствовать из AutoCAD MEP, идеологию построения схем и трубопроводов из Aveva, принцип моделирования строительных конструкций из Tekla/Revit, электрику и автоматику из ElectriCS и AutomatiCS, генплан из GeoniCS/Civil 3D.
В продукт заложить возможность распределенного наполнения централизованной базы данных оборудования и конструкций. Чтобы и завод-изготовитель, и проектный институт, и служба заказчика, могли наполнять её или извлекать из неё информацию. Единица базы оборудования позволяла хотя бы на 50% формировать опросный лист по сохраненным для оборудования параметрам. Программный продукт цеплялся к базе и позволял вставить оборудование в локальную модель.
Модель была бы как геометрической, информационной, так и сразу расчетной. Осуществлялся бы анализ прочности, расчет нагрузок на опоры и т.п. Позволяла бы исключить передачу как минимум половины заданий между смежными отделами. При построении модели происходил анализ конструкции в реальном времени с отображением ненавязчивых подсказок о возможных проблемах, о минимальном расстоянии между опорами, о разрывах между трубами разных диаметров, о необходимости изоляции нужной толщины и т.п.
Что-то я разошелся… :)
На сколько крупные модели ГП/ТХ/АС/ЭМ/АСУ поднимет Model Studio в нынешней реализации? Сдается мне, что модель уровня УПН или УКПГ ему не по зубам. Развейте мои сомнения, если возможно.
Насчет слабости AutoCAD MEP вы заблуждаетесь. Очень мощный и гибкий продукт. В некоторых вопросах лучше Revit. Его позиционирование, как продукт для внутренних коммуникаций в гражданском строительстве, по моему мнению, типичный маркетинговый ход. Попытка продать AutoCAD Plant 3D подороже, при том, что в AutoCAD Plant 3D половина «слизана» с AutoCAD MEP. Слабые только две стороны: платформа AutoCAD и разрезы.
Россия встала на рельсы сырьевой экономики несколько десятилетий назад, но на российском рынке ПО до сих пор нет достойного продукта для проектирования промышленных объектов нефтяной и газовой промышленности. Есть конечно попытки реализации на платформе AutoCAD и даже неплохие, но они морально устаревают вместе с платформой.
Почему до сих пор никто не взял движок C3D и не сделал на его основе продукт а-ля Aveva, Plant 4D, AutoCAD Plant 3D или AutoCAD MEP? Тот же Нанософт, уверен, мог бы такое реализовать! Спрос был бы вполне себе достойный.
В фильме «Матрица» (первая серия) Нео выходил на фасад небоскреба через открытое окно. Это киношный обман или на самом деле бывают высотные здания с открывающимися окнами наверху?
P.S. Также простите за дилетантский вопрос :)
Ну, во первых менять систему мотивации. Она должна быть не от выработки участка, а от выработки завода. Чувствуете разницу? Одно дело, когда ваши люди замотивированы на рост незавершенки, и совсем другое дело, когда они замотивированы на выпуск продукции.
Вся мотивация четко по Голдратту, его теории ограничений (ТОС) и его книге «Цель».
На самом деле — это была «вселенская хитрость»! От своих «айтишников» добиться плана действий директор не мог и сам свой план составить тоже не мог, поэтому решил нанять стороннего специалиста, получить от него план мероприятий и заставить своих «айтишников» по нему пройти. Руководящие и контролирующие функции оставлял за собой.
Он ошибочно полагал, что плана и его собственной инициативы достаточно. :)
P.S. По началу подобные подходы (это был не единственный случай) меня расстраивали, пока не взглянул на ситуацию иначе. Такие организации достойны результата своей работы. :)
… в котором изложить, что необходимо, чтобы внедрить систему.
и сразу вспомнил случай из своей практики. История с внедрением ERP закончилась именно на этом. Я написал подробный план, передал заказчику, получил положенные деньги. Рассчитывал, что дальше будем работать с заказчиком по этому плану, а он решил передать план своим «айтишникам», дескать дальше пусть они все делают, строго по плану.
На сколько знаю, «воз и ныне там». Уж лет 10 прошло.
Так тоже бывает…
Только надо не забыть, что лед, растаявший на полюсах повысит уровень мирового океана настолько, что ездить на велосипеде станет негде. Нет велосипеда — нет проблем!
Ну, easla.com — это не система учета, а скорее платформа, на которой можно реализовать любые бизнес-процессы организации. И главное реализовать так, как они есть, а не полагаться на «заранее продуманные» и зачастую неподходящие по разным причинам. Конечно, лучшие практики — это хорошо, но вымеренными дозами.
Обратная связь на Битрикс24 в рунете очень познавательная. Порой похожа на «ежики плакали но продолжали жрать кактусы».
Я не против Битрикс24, кому-то ее достаточно, но в нашем случае ее возможностей недостаточно.
Обещали диаграмму Гантта строить по назначенным задачам. Дождались!
Пока в тестовом режиме. Осталось «допилить» верстку и локализацию.
Как-то так:
Кстати, можно отдельную статью написать про «прикручивание» DHTMLX компоненты к Yii.
Мне кажется, что разобраться с API любой системы «программисту средней руки» проще, чем с исходным кодом всей системы. Не так уж много найдется желающих копаться во внутренностях системы, скажем, ради интеграции ее с другой системой, когда надо только организовать передачу значений парочки атрибутов отдельных сущностей.
Разве нет?
«На данный момент самым популярным языком программирования является Java» таким заявлением можно начать очень крутой холивар.
Насчет «открытости», всегда считал, что «открытость» системы определяется наличием API и поддержкой различных протоколов обмена данными, например, SOAP, а не передачей исходного кода клиенту.
На сколько я знаю, «Лоцман» — коробочный продукт с преднастроенными бизнес-процессами. Изменить готовые процессы в нем не так то просто. Надо или иметь хорошие знания самого продукта, или платить денежки интеграторам. Причем денежки немалые (в одной из знакомых мне организаций на Лоцман потратили несколько миллионов, а «воз и ныне там»).
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Немного ниже упоминали 1С, но когда я лично изучал возможности продуктов 1С, то заметил, что они не умеют хранить файлы. Это был большой минус. Не знаю как сейчас, возможно ситуация изменилась. Вы в курсе?
Насчет «best practice» (лучших практик). Как показывает мой жизненный опыт, с ними нужно быть поосторожнее. Изучать лучшие практики нужно и полезно (ITIL, PM BOK, CobiT), но тупой перенос их в работу, не оглядываясь на окружающую действительность, может только ухудшить ситуацию.
Конкретный пример из жизни. Недавно на хабре была статья о ревизиях. Ревизии — яркий пример «best practice». Они активно используются на «западе». Ревизии в целом — отличный способ контролировать процесс разработки проектной документации. В нашем ГОСТ нет такого понятия. Есть только изменения, которые позволяют контролировать только процесс изменения документации после сдачи в архив, но вот до этого момента, процедуры не регламентированы. В общем, ревизии — классная штука, если пользоваться ими правильно!
Но их начинают использовать сейчас все кому не лень и совершенно бездумно. Ревизии заменяют изменения в наше ГОСТ. Но наш ГОСТ никто не отменял. В итоге, и ревизии по стандартам «западных» и «прозападных» компаний, и изменения по ГОСТ приходится применять одновременно! Это вносит не просто путаницу, а порой полное непонимание, что и как идентифицировать и в какой момент. И не только на стороне исполнителя, но и на стороне заказчика. Таким образом, великолепный и признанный во всем мире «best practice» не только не помогает в работе, а напротив, тормозит ее, снижает эффективность и прозрачность.
По хорошему, надо было на уровне министерства или как они там сейчас называются, внести изменения в ГОСТ. Отменить изменения, вместо них описать работу с ревизиями и все! Было бы здорово!
Кроме этого существует понятие «зрелость процесса» и «зрелость компании». Многие «best practice» предполагают довольно высокую зрелость и того и другого, поэтому их запуск в «недозрелой» компании создаст больше вопросов, чем решений. Реализация же бизнес-процесса в точности по требованиям самой компании и быстрее и понятнее конечным пользователям от главного инженера, до техника.
Про SAP на хабре тоже недавно была «хвалебная» статья только подтверждающая опасения многих.
Кстати, не стоит забывать и про финансовую составляющую. Продукты 1С и уж тем более SAP имеют такой ценник, что в условиях современного кризиса их просто не потянуть, а easla.com почти бесплатная!
Адаптивная верстка все решает. Если руководство умеет пользоваться сотовым или планшетом, подключиться к интернет и зайти на сайт, то никаких проблем!
P.S. Таким же образом однажды воспользовался доступом к официальной переписке и отправил несколько официальных писем прямо со своей соты.
Про AutoCAD MEP вы не уловили мою позицию, но это не критично. Я согласен с вами, что этот продукт именно для ОВ/ВК по российским стандартам не очень то подходит. Существуют более удачные продукты для этого сегмента. Однако идеологически он построен очень хорошо. Настраивается всё и вся. Главное знать, где искать. Мы его применили для промышленного проектирования в 2012 год. Уперлись только в неподъемность сложных моделей в AutoCAD. По позициям моделировать в AutoCAD MEP было нормально, но получить общую модель из десятков позиций в AutoCAD — никак.
Именно поэтому и киваю на то, что надо бы свой, российский продукт, написанный исключительно под промышленное проектирование, примерно как Aveva, на российском графическом движке. Интерфейс заимствовать из AutoCAD MEP, идеологию построения схем и трубопроводов из Aveva, принцип моделирования строительных конструкций из Tekla/Revit, электрику и автоматику из ElectriCS и AutomatiCS, генплан из GeoniCS/Civil 3D.
В продукт заложить возможность распределенного наполнения централизованной базы данных оборудования и конструкций. Чтобы и завод-изготовитель, и проектный институт, и служба заказчика, могли наполнять её или извлекать из неё информацию. Единица базы оборудования позволяла хотя бы на 50% формировать опросный лист по сохраненным для оборудования параметрам. Программный продукт цеплялся к базе и позволял вставить оборудование в локальную модель.
Модель была бы как геометрической, информационной, так и сразу расчетной. Осуществлялся бы анализ прочности, расчет нагрузок на опоры и т.п. Позволяла бы исключить передачу как минимум половины заданий между смежными отделами. При построении модели происходил анализ конструкции в реальном времени с отображением ненавязчивых подсказок о возможных проблемах, о минимальном расстоянии между опорами, о разрывах между трубами разных диаметров, о необходимости изоляции нужной толщины и т.п.
Что-то я разошелся… :)
Насчет слабости AutoCAD MEP вы заблуждаетесь. Очень мощный и гибкий продукт. В некоторых вопросах лучше Revit. Его позиционирование, как продукт для внутренних коммуникаций в гражданском строительстве, по моему мнению, типичный маркетинговый ход. Попытка продать AutoCAD Plant 3D подороже, при том, что в AutoCAD Plant 3D половина «слизана» с AutoCAD MEP. Слабые только две стороны: платформа AutoCAD и разрезы.
Почему до сих пор никто не взял движок C3D и не сделал на его основе продукт а-ля Aveva, Plant 4D, AutoCAD Plant 3D или AutoCAD MEP? Тот же Нанософт, уверен, мог бы такое реализовать! Спрос был бы вполне себе достойный.
P.S. Также простите за дилетантский вопрос :)
Вся мотивация четко по Голдратту, его теории ограничений (ТОС) и его книге «Цель».
Он ошибочно полагал, что плана и его собственной инициативы достаточно. :)
P.S. По началу подобные подходы (это был не единственный случай) меня расстраивали, пока не взглянул на ситуацию иначе. Такие организации достойны результата своей работы. :)
На сколько знаю, «воз и ныне там». Уж лет 10 прошло.
Так тоже бывает…
А управляют нами «смекалистые парни», только их смекалка не в нашу пользу работает… :)
Обратная связь на Битрикс24 в рунете очень познавательная. Порой похожа на «ежики плакали но продолжали жрать кактусы».
Я не против Битрикс24, кому-то ее достаточно, но в нашем случае ее возможностей недостаточно.
Собственно, код системы открытым не является, только компоненты.
P.S. Переход на Yii 2 только в планах.
Пока в тестовом режиме. Осталось «допилить» верстку и локализацию.
Как-то так:
Кстати, можно отдельную статью написать про «прикручивание» DHTMLX компоненты к Yii.
Разве нет?
Насчет «открытости», всегда считал, что «открытость» системы определяется наличием API и поддержкой различных протоколов обмена данными, например, SOAP, а не передачей исходного кода клиенту.
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Насчет «best practice» (лучших практик). Как показывает мой жизненный опыт, с ними нужно быть поосторожнее. Изучать лучшие практики нужно и полезно (ITIL, PM BOK, CobiT), но тупой перенос их в работу, не оглядываясь на окружающую действительность, может только ухудшить ситуацию.
Конкретный пример из жизни. Недавно на хабре была статья о ревизиях. Ревизии — яркий пример «best practice». Они активно используются на «западе». Ревизии в целом — отличный способ контролировать процесс разработки проектной документации. В нашем ГОСТ нет такого понятия. Есть только изменения, которые позволяют контролировать только процесс изменения документации после сдачи в архив, но вот до этого момента, процедуры не регламентированы. В общем, ревизии — классная штука, если пользоваться ими правильно!
Но их начинают использовать сейчас все кому не лень и совершенно бездумно. Ревизии заменяют изменения в наше ГОСТ. Но наш ГОСТ никто не отменял. В итоге, и ревизии по стандартам «западных» и «прозападных» компаний, и изменения по ГОСТ приходится применять одновременно! Это вносит не просто путаницу, а порой полное непонимание, что и как идентифицировать и в какой момент. И не только на стороне исполнителя, но и на стороне заказчика. Таким образом, великолепный и признанный во всем мире «best practice» не только не помогает в работе, а напротив, тормозит ее, снижает эффективность и прозрачность.
По хорошему, надо было на уровне министерства или как они там сейчас называются, внести изменения в ГОСТ. Отменить изменения, вместо них описать работу с ревизиями и все! Было бы здорово!
Кроме этого существует понятие «зрелость процесса» и «зрелость компании». Многие «best practice» предполагают довольно высокую зрелость и того и другого, поэтому их запуск в «недозрелой» компании создаст больше вопросов, чем решений. Реализация же бизнес-процесса в точности по требованиям самой компании и быстрее и понятнее конечным пользователям от главного инженера, до техника.
Про SAP на хабре тоже недавно была «хвалебная» статья только подтверждающая опасения многих.
Кстати, не стоит забывать и про финансовую составляющую. Продукты 1С и уж тем более SAP имеют такой ценник, что в условиях современного кризиса их просто не потянуть, а easla.com почти бесплатная!
P.S. Таким же образом однажды воспользовался доступом к официальной переписке и отправил несколько официальных писем прямо со своей соты.