Статьи → СиСофт Девелопмент → 123 или Шпаргалка для построения системы комплексной автоматизации в проектной организации, работающей в области ПГС (Часть II)

Часть II

Эта статья является логическим продолжением предыдущей, которая открывала серию статей сотрудников ЗАО «СиСофт». Адресована она руководителям служб САПР или ИТ, которые не хотят бить баклуши и рисовать красивые отчеты, а желают внедрить у себя САПР и ориентируются на сотрудничество с компанией «СиСофт».

Сегодня мы рассматриваем обоснование инвестиций.

Как обосновать инвестиции?

Этот вопрос задает себе каждый, кто хочет подстраховаться перед походом к биг-боссу за деньгами на САПР. Самый простой способ обоснования — расчет возврата инвестиций (ROI).

В сущности, ROI вычисляется по очень простой формуле: Доходы/расходы = ROI. Но, как и во всем, что кажется простым и абсолютно понятным, есть кое-какие нюансы. В деле вычисления ROI самый главный и критичный нюанс — это способ определения дохода. Трудность заключается в том, что доход вычисляется на основе предположения: необходимо определить преимущества, получаемые благодаря внедрению САПР, и найти методы их числовой оценки — притом такой, которая численно отразит относительную выгоду от развертывания и внедрения этого САПР. Задача невероятно тяжела для тех, кто пытается всё рассчитать с точностью до копейки по стоимости и до минуты по времени. Людям более здравомыслящим вполне достаточна величина возврата инвестиций за год.

Но оставим теорию в стороне. Чтобы было понятнее, подсчитаем на живом примере доход и расход от приобретения ПО и запуска его в эксплуатацию. А затем проанализируем результаты.

Возьмем хороший программный продукт Model Studio CS ЛЭП. Как исходное положение примем, что компьютер и AutoCAD в организации уже имеются и установлены на рабочем месте. Соответственно, нашими исходными данными для подсчета ROI будут:

Стоимость программного обеспечения + годовая подписка, А = 75 000 руб. Заработная плата проектировщика, Б = 30 000 руб./месяц. Длительность самообучения/внедрения/настройки, В = 1 месяц. Снижение производительности во время обучения/внедрения/настройки, Г = 60% (то есть 40% от обычной производительности). Рост производительности после обучения/внедрения/настройки, Д = 200% (то есть производительность увеличилась вдвое. Для Model Studio CS ЛЭП обычный показатель 300 400%, но будем вести расчет по пессимистическому сценарию и примем 100%).

Итак, рассчитываем условный «доход», то есть примем нулевые значения прибыли и убытка. Без Model Studio CS ЛЭП человек, получающий зарплату, известную из условий задачи, вырабатывал 100%. Таким образом, «доходная» часть составляла 12 месяцев х 30 тыс. х 100%. Следовательно, условный «доход» без Model Studio CS составлял 360 тыс.

При покупке и внедрении Model Studio CS ЛЭП предполагается, что условный «доход» составит (12 месяцев — 1 месяц обучения/внедрения) х 30 тыс. х 200% + 1 месяц х 30 тыс. х 40%. Получается, что условный «доход» равен 672 тыс., то есть на 312 тыс. больше, чем в отсутствие Model Studio CS.

Перейдем к расходной части. Сюда войдут стоимость ПО и потеря производительности при внедрении. Для расчета «расхода» от внедрения принимаем, что при той же зарплате объем выпускаемой продукции (чертежей) составлял на этапе обучения/внедрения/настройки 60% от стандартного. Таким образом, получаем 75 тыс. (затраты на ПО) + 30 тыс. х 1 месяц х 60%. Следовательно, условный «расход» равен 93 тыс. рублей.

Теперь поделим доход на расход и получаем ROI = 335%. Покупка очень и очень выгодна: за год ПО не только окупится, но еще и умножит прибыль!

Первый расчет умышленно не учитывал расходы, связанные с привлечением преподавателей — рассматривается вариант «самообучения» пользователей. Теперь давайте сделаем такой же расчет, но с обучением. У нас изменятся исходные данные: нужно будет заплатить за обучение, зато время внедрения уменьшится с месяца до двух недель. Одну неделю полностью посвятим обучению (сотрудник будет приносить 0% прибыли), еще неделя на все про все («внедрение»). В наших исходных данных меняются сроки внедрения и добавляется ряд позиций:

Стоимость обучения, А = 48 000 руб. Длительность внедрения/настройки, В = 0,25 месяца (1 неделя). Длительность обучения, В = 0,25 месяца (1 неделя). Снижение производительности во время обучения, Г = 0% от обычной производительности. Снижение производительности во время внедрения/настройки, Г = 60% (то есть 40% от обычной производительности).

Рассчитываем по аналогии с предыдущим:

Доход = (12 месяцев — 0,5 месяца обучения/внедрения) х 30 тыс. х 200% + 0,25 месяца х 30 тыс. х 40% = 693 — 360 = 333 тыс. руб. Расход = 75 тыс. (затраты на ПО) + 48 тыс. (обучение) + 30 тыс. х 0,25 месяца х 60% + 30 тыс. х 0,25 мес. х 100% = 135 тыс. руб.

ROI = 247%, что тоже не только окупит ПО, но и принесет значительную прибыль в сравнении с инвестициями.

Таким образом, расчет ROI для Model Studio CS ЛЭП показывает превосходные показатели, обусловленные тем, что это очень специализированное программное обеспечение, не требующее долгого освоения и внедрения.

ROI, конечно, не панацея, но это показатель, который вполне обосновывает приобретение ПО. Его применение весьма разнообразно, а значит очень разной (иногда крайне высокой) может быть и сложность вычислений.

Пример на основе Model Studio CS иллюстрирует случай, когда ПО приносит прибыль в год приобретения. Многие программные продукты не способны окупиться за год в явном виде, но могут окупиться косвенно — за счет комбинации с другим ПО или, например, с условиями размещенного заказа на проектирование. Поэтому к ROI, значение которого меньше 100%, могут отнестись с сомнением — а вдруг не окупится? Например, в документах компании Autodesk, которые можно найти в Интернете, произведен расчет для программы Revit. ROI — от 41 до 60%; утверждается, что это хорошие показатели. Не станем спорить: расчет выполнен для неких американских компаний, исходя из их условий инвестирования в САПР. Но оперировать этими же цифрами применительно к вашей компании опрометчиво и неверно: условия приобретения, зарплаты сотрудников и прочие параметры могут значительно отличаться. Чтобы понять, удовлетворителен или нет полученный результат вычисления ROI, нужно сделать еще один несложный расчет и определить минимально допустимый ROImin, то есть тот минимум, который не приведет к убыткам и в конечном счете обеспечит возврат вложенных инвестиций.

Минимальный возврат инвестиций можно рассчитать по формуле ROI_min = Удешевление/Расход, где Удешевление — это условная потеря стоимости софта, оборудования, знаний и т.п.

Итак, проверим минимальный ROI для Model Studio CS ЛЭП. Примем, что полная модернизация программы целесообразна раз в три года (то есть через три года стоимость ПО = 0. Это не так, но предположим), а значит ежегодное удешевление софта составит 1/3 = 33%. Исходя из этого, вычислим удешевление в рублях: 75 000 руб. х 33% = 24 750 руб. в год. Плюс к этому (пойдем по плохому сценарию) нужно добавить ежегодную переподготовку специалиста (24 000 руб.). В сумме выходит 48 750 руб. ROImin = 48 750/135 000 = 36%. Итак, у нас получается, что любой показатель ROI, превышающий 36%, обеспечивает окупаемость Model Studio CS ЛЭП.

Так можно подсчитать ROI практически для любых САПРовских проектов. Несмотря на то что метод не абсолютно точен, его вполне достаточно, чтобы обосновать инвестиции в САПР. Наряду со статистическим методом составления планов по закупкам ПО и по внедрению, ROI позволяет руководителю, ответственному за САПР, показать привлекательность систем автоматизированного проектирования как одного из инструментов повышения конкурентных возможностей проектной организации. Нужно иметь в виду, что при изменении сроков внедрения и оценках повышения производительности полученные цифры могут иметь большой разброс. Поэтому вычисления следует делать с большой осторожностью или все-таки обратиться к экспертам «СиСофт».

Часть III

Вэтой части мы хотим поговорить о разработке стандарта предприятия по работе в среде AutoCAD.

Большинству предприятий, использующих AutoCAD как базовый продукт для проектирования, знакомы проблемы стандартизации работ с графическими приложениями. Нет единых правил, каждое подразделение и каждый проектировщик создает чертежи, исходя из собственных представлений о том «как будет лучше»; совместная работа отделов до крайности затруднена. Возникает острая необходимость навести порядок при работе с графическими приложениями. Единственное решение — создать стандарт, регламентирующий правила разработки и оформления графических материалов в среде AutoCAD.

Конечно, существуют ЕСКД, СПДС, СТП, определяющие правила оформления графической продукции (всё, что связано с окончательным видом чертежа на бумаге), но количество вариантов оформления на основе этих стандартов не ограничено, а кроме того стандарты ничего не говорят о «культуре» черчения в AutoCAD. Они разработаны для ручного создания чертежей, и в них просто отсутствуют такие понятия, как «блок», «слой», «правила использования стилей». Следовательно, необходим стандарт, отвечающий современным требованиям электронного оформления графической документации.

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

Первый шаг, он трудный самый

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

Начинать надо прямо сейчас. Чем раньше в информационной среде предприятия появится система, тем проще и быстрее удастся выполнить дальнейшие шаги. Стандарт работы с AutoCAD представляет собой фундамент для последующего внедрения средств САПР в полном объеме и создания единой информационной модели предприятия. Стандартизация является первым шагом на длинном пути к счастливому информационному будущему.

Так что такое этот стандарт? Самое главное его предназначение — определить правила работы в AutoCAD, единые для всех сотрудников и всех проектных подразделений. Не общие рекомендации, а конкретные требования к организации чертежей. Какими должны быть эти правила? Перефразируя знаменитое изречение, можно сказать, что правила могут быть любыми при условии, что они единые. В основе всего лежат требования отдельных специальностей и дисциплин — именно от них и следует отталкиваться при создании стандарта. Для каждой дисциплины разрабатываются свои требования, но обязательно в рамках общих правил (например, формат имени слоя). Кроме того, стандарт должен четко определять требования к таким вещам, как:

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

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

Стандарт нашего будущего

Стандартизация электронных чертежей предприятия — дело очень ответственное. И не всегда такое быстрое, как хотелось бы. Чтобы получить максимальный эффект, весь процесс следует разбить на этапы. Вот четыре основных:

• подготовительный этап;
• обследование предприятия;
• разработка стандарта;
• внедрение стандарта.

Подготовительный этап

Как организовать разработку и внедрение СТП?

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

Что эта группа должна сделать? Проанализировать документацию, выполненную при помощи AutoCAD, собрать наработки, которые, возможно, существуют по каждой специальности, требования к оформлению и многое другое. Вполне вероятно, что представителями группы уже применяется некоторая стандартизация, но не совместная, а индивидуальная.

Трудности, которые придется преодолевать на всем пути, — это постоянная занятость специалистов, текучка, сопротивление руководителей всех звеньев (если вас поддерживает высшее руководство — это уже удача), да и сопротивление исполнителей: трудно доказать, что все наработанное тобой для облегчения твоей работы принадлежит не только тебе, а должно использоваться и твоими коллегами. Внутренний конфликт может возникнуть и в экспертной группе, ведь каждому ее представителю придется пойти на компромисс, и вряд ли совместно сгенерированный документ будет на 100% соответствовать технологиям черчения хотя бы одного из них.

Обследование предприятия

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

Написание стандарта

На этом этапе необходимо:

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

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

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

Итак, стандарт написан. Что он реально даст проектировщику? Практически ничего, кроме головной боли, связанной с дополнительной работой и с необходимостью постоянно рыться в новоявленном документе. Естественно, находятся тысячи причин (в основном срыв сроков подготовки документации и недопонимание механизмов соблюдения стандарта) для отказа от его использования.

Вот тут и возникает необходимость в организации работ по автоматизации использования стандарта — а по сути в его внедрении.

Внедрение

Рассмотрим возможные пути внедрения:

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

Путь, который мы выбираем

Если вы руководитель или сотрудник отдела САПР, вам прекрасно известно, как много времени съедает рутина: обслуживание «железа», серверов, постоянные обращения проектировщиков с просьбами отсканировать это, найти то, вылечить вирус… А еще вы хорошо знаете, как мало времени и сил остается на то чтобы упорядочить работу этих самых проектировщиков и доказать им, что так будет лучше в первую очередь им самим. Поэтому реализация любого мало-мальского улучшения подобна революции, после которой хочется на время забыться, а затем вспоминать ее как дурной сон. Наиболее распространенная ситуация в организациях, где удалось хоть как-то решить вопрос стандартизации: настроенные шаблоны чертежей, лежащие где-то на сервере. Проектировщику, чья голова занята проектированием, необходимо помнить, где все это лежит, проверять, не поменялось ли что-нибудь. А если поменялось, то что делать с текущими чертежами, начатыми по старым шаблонам? То есть отделы САПР, отчитавшись о победоносном выполнении поставленной задачи, фактически переложили заботу о соблюдении стандартов на плечи проектировщиков. Неудивительно, что в таких организациях проектировщики всячески уклоняются от соблюдения стандарта, а сотрудники САПР, вроде бы гордые проделанной работой, в кулуарах жалуются: дескать, мы всё для них сделали, а они… Таким образом, сама идея стандартизации дискредитирована, а желания и возможности возвращаться к ней нет.

Так в чем причины провала? Одна из них — в методах реализации. Правильно реализованная система должна содержать массу инструментов:

• инструменты централизованной настройки рабочей среды проектировщиков, не зависящие от версий AutoCAD или связанные с ними лишь в минимальной степени. Механизм шаблонов не идеален и его по возможности надо избегать;
• инструменты внесения изменений и обновления настроек на рабочих местах. Стандарт должен развиваться, а значит должны меняться и рабочие настройки, но чем меньше этот процесс отвлекает пользователей и сотрудников САПР, тем лучше. Удаленные подключения к рабочему столу крайне неудобны и трудозатратны, особенно если в организации несколько десятков пользователей.

Если существует стандарт, он должен соблюдаться и контролироваться. Механизм контроля есть в AutoCAD, но для каждого чертежа он требует ручной настройки силами пользователя. Скорее всего 90% пользователей о таком инструменте не знают, да проектировщику он и не нужен — чертеж им не начертишь. Поэтому включение такого механизма в работу должно происходить вне зависимости от желаний или действий пользователей. Кроме того, этот механизм должен помогать пользователю находить и исправлять в документе отклонения от стандарта.

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

Только правильно построенная система позволит максимально быстро осуществлять переход на новые версии AutoCAD и работать с разными версиями одновременно. В противном случае все наработки уйдут в историю — примеров тому предостаточно. Принимая решение об обновлении базового ПО, руководство не всегда задумывается об этом…

Добавим еще несколько слов о разработке и внедрении стандарта.

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

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

Можно попытаться внедрить стандарт своими силами, но, как показывает опыт, справиться с этой задачей мало кому удается. На пути внедрения встает масса преград. Это и нехватка ресурсов в связи с загруженностью персонала отделов САПР непосредственными функциями, и отсутствие понимания и поддержки со стороны руководства, и элементарное нежелание пользователей менять выработанные годами собственные технологии работы в AutoCAD. На преодоление этих препятствий может уйти много времени и сил.

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

Будущее ближе, чем кажется

Недавно на российском рынке появился StdManagerCS (www.stdmanager.ru) — решение, позволяющее управлять стандартом предприятия по работе в AutoCAD. Представляя собой модульную систему, StdManagerCS является отличным помощником для сотрудников отделов САПР, в чьи обязанности входит поддержка AutoCAD и пользователей. С другой стороны, он предоставляет IT-шнику набор инструментов, позволяющих автоматизировать соблюдение стандарта, а проектировщику организует рабочую среду, позволяющую работать в соответствии со стандартом. При этом программа в режиме реального времени контролирует соблюдение стандарта и предлагает решения в случае отступления от него. Чтобы активировать этот контроль, от пользователя не требуется никаких действий. Основной принцип, заложенный в программу: соблюдение стандарта без знания самого стандарта.

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