CADmaster

Часть 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, хоть и продается в коробке, по сути своей к коробочным программам не имеет никакого отношения. Это сложная система, требующая к себе и своим возможностям уважительного отношения. Так давайте к ней соответствующим образом и относиться. Только тогда она ответит вам взаимностью и станет не тяжкой неизбежностью, а реальной помощницей в работе.

Скачать статью в формате PDF — 338.0 Кбайт