Для зарегистрированных пользователей |
|
Как оценить стоимость проекта автоматизации?
Прежде чем ответить на этот вопрос необходимо определить, кем и с какой целью делается оценка.
Оценка проекта выполняется клиентами, поставщиками решений, и инвесторами. Оценка необходима для решения следующих задач: принятия решения о целесообразности проекта;
- сравнения вариантов автоматизации в процессе выбора;
- переговоров о стоимости проекта;
- планирования расходов на проект автоматизации (бюджетирование);
- контроля фактических расходов на проект автоматизации.
Подход к оценке зависит от ее цели, а так же доступной информации в момент оценки. Есть несколько методов оценки проекта по автоматизации:
- метод аналогий. Оценка делается на основе данных о фактической стоимости аналогичных проектов на предприятиях, близких по масштабу бизнеса и виду деятельности;
- метод аппроксимации (близок методу аналогий). Оценка на основе количественных показателей деятельности компании (например, оборота, прибыли). Стоимость проекта определяется в процентах к одному из показателей за выбранный период с использованием отраслевой статистики. Оценка может также делаться с использованием нефинансовых показателей, например, количества сотрудников, филиалов, рабочих станций.
- директивный метод. Оценка не рассчитывается, а определяется директивно в ходе составления бюджета компании. Проект автоматизации будет стоить столько, сколько за него готовы заплатить.
- затратный метод. Оценка делается исходя себестоимости отдельных составляющих проекта (работ по анализу, разработки и внедрению, приобретению программного и технического обеспечения).
Для использования метода аналогий и аппроксимации требуется информация о контрактах, которая обычно отсутствует у компании-заказчика. Такой информацией располагают компании-поставщики и консалтинговые компании. Зачастую декларируемые суммы проектов автоматизации оказываются завышенными, поскольку компании-поставщики стараются не раскрывать информацию о предоставляемых скидках на программное обеспечение и внедрение. Использование этих методов оправдано при составлении short-list - предварительного списка информационных систем, из которого осуществляется выбор. В случае использования метода аппроксимации доля затрат на ИТ проект в обороте (прибыли) будет выше для малых и средних предприятий, кроме того, доля затрат выше у тех компаний, для которых информационная система является основным средством ведения бизнеса: банков, страховых компаний. Если для производственной компании с оборотом сто миллионов долларов расходы на проект автоматизации могут быть 1-2% от оборота, то для страховой компании с объемом премий несколько миллионов долларов в год расходы на проект могут составить 5-10%. Для использования методов аналогий и аппроксимации самое важное - получить достоверную и адекватную информацию о фактических затратах на аналогичные проекты. Оценка на основе количества рабочих станций эффективна при наличии данных для рассматриваемой информационной системы. Чем больше компания, тем устойчивее оценка. Использование директивного метода особенно эффективно при осуществлении ИТ проекта собственными силами, поскольку в этом случае существеннее возможность влиять на цену отдельных составляющих проекта. Основным недостатком использования данного подхода является риск недофинансирования (излишнего финансирования) проекта автоматизации. Затратный метод требует детального представления проекта автоматизации - перечня работ (work breakdown structure, WBS), и перечня ресурсов. Кроме того, окончательная оценка некоторых составляющих (например, лицензий на информационную систему) может быть получена только после проведения переговоров с поставщиками, согласования вопросов о скидках. Использование этого метода для проектов автоматизации сходно с оценкой обычного проекта, отличия лежат в области учета влияния рисков на стоимость проекта. Цель оценки проекта ИТ так же определяет временную перспективу и состав учитываемых затрат. Для сравнения вариантов автоматизации необходимо получить полную оценку проекта, включая этапы внедрения и эксплуатации. Необходимо спрогнозировать срок и условия эксплуатации системы: рассчитать TCO (total cost of ownership) в будущем, оценить риски изменения условий, а так же риск прекращения проекта. Следует отметить, что при сравнении альтернативных вариантов необходимо использовать полную стоимость проекта, которая складывается из затрат на разработку и внедрения и приведенной суммы затрат на поддержку и обслуживание информационной системы (TCO). Особого внимания требует учет временного фактора в проектах автоматизации. Цена времени - это затраты, которые несет предприятие и упущенные выгоды из-за несовершенства существующей информационной системы. Именно с оценки стоимости времени следует начинать проект автоматизации!
Стоимость проекта автоматизации складывается из следующих составляющих:
- анализ требований к информационной системе;
- выбор информационной системы, поставщиков, консультантов (проведение тендера);
- программное обеспечение (лицензии: информационная система, база данных, операционная система, вспомогательное служебное ПО).
- техническое обеспечение (сервера, персональные станции, каналы связи, сетевые устройства и т.д.);
- настройка (доработка) информационной системы;
- внедрение (обучение пользователей, перенос данных, развертывание системы, интеграция с другими приложениями, тестирование бизнес-логики);
Статьи затрат отличаются по степени точности возможной оценки стоимости. Полная стоимость складывается из затрат на оплату услуг сторонних организаций, покупку оборудования и программного обеспечения, а так же затрат собственных ресурсов организации, в первую очередь - рабочего времени персонала организации. Встречается мнение, что выполнение работ проекта автоматизации силами собственных сотрудников ведет к снижению затрат. Для получения адекватной оценки затрат на работу собственных сотрудников следует использовать не заработную плату, а упущенный доход компании из-за невыполнения сотрудниками их прямых обязанностей. В качестве приблизительной оценки можно использовать чистый доход компании, приходящийся на одного сотрудника, скорректированный на его уровень в организационной структуре. Компании-поставщики информационных систем делают бесплатную оценку стоимости проектов автоматизации в ходе тендера. Для оценки используются методики внедрения соответствующих систем, такие методики имеются у SAP/R3, Navision Axapta, Oracle Applications, Scala и других.
У проекта автоматизации две цены:
- цена спроса - сколько готова компания-заказчик заплатить за проект;
- цена предложения - сколько запросит за проект компания-разработчик.
На цену спроса влияет оценка эффекта от реализации проекта автоматизации, финансовые возможности заказчика, субъективная оценка затрат на выполнение работ. Цена предложения зависит от маркетинговой политики компании-поставщика и себестоимости проекта. Что бы получить заказ, копания-разработчик должна обосновать именно ту цену проекта, которую готова заплатить компания-заказчик. То есть, в основе оценки проекта лежит интуитивное нащупывание директивной оценки (цены спроса проекта). А основанием для директивной оценки может быть как скорректированная оценка, полученная методом аппроксимаций или аналогий (хочу, что бы мой проект по автоматизации был дороже, чем у конкурента А на 10%, но не дороже суммы X) так и бюджетный подход (мы можем потратить на проект автоматизации сумму Y в течение заданного периода). Уокер Ройс, генеральный директор Rational Software, подтверждает справедливость этого утверждения: «на самом деле, в большинстве случаев стоимостные модели используются “от противного” (для подтверждения объявленной стоимости), а вовсе не по прямому назначению (для определения той цены, которую следовало бы запросить) . На рынке программного обеспечения информационных систем и систем управления базами данных наблюдается влияние эффекта сноба - многочисленны примеры приобретения дорогостоящих информационных систем за их известность, без учета реальных потребностей бизнеса, а, иногда, без анализа действительных инвестиционных возможностей. Рынок информационных систем так же является рынком «лимонов» , поскольку характеристики информационной системы не известны заказчику до ее внедрения, что усиливает влияние эффекта сноба. Факт приобретения (внедрения) многофункциональной сертифицированной дорогой информационной системы и в самом деле может улучшить имидж компании у контрагентов и конкурентов, привести к росту рыночной стоимости (капитализации) компании. Внедрение такой системы связывают с повышением прозрачности бизнеса и повышением эффективности управления. Ценовая информация используется менеджерами вместо функционального описания. Например, СУБД Oracle воспринимается всеми участниками рынка как самая надежная и производительная, SAP/R3 имеет репутацию самой полнофункциональной, гибкой и настраиваемой. Высокая стоимость подкрепляет эту репутацию. В случае появления нового продукта на рынке, его стоимость будет воспринята участниками рынка как информация о функциональных качествах продукта, характеристиках производительности и надежности. Особенность стратегии ценового лидерства для разработчиков ПО, в отличие от производственных и сервисных организаций, состоит в том, что для его достижения не требуется уменьшение затрат на разработку (сокращение функциональности и других качественных характеристик, ухудшение обслуживания). Причиной служит отсутствие (или незначительная величина) переменных затрат (стоимость производства копий). Исключение составляют затраты, связанные с сервисным обслуживанием и поддержкой пользователей. Можно сделать парадоксальный вывод: стратегия ценового лидерства в меньшей степени предполагает оптимизацию производственных затрат (а следовательно, и оптимизацию процессов разработки), чем дифференциация или сфокусированность, поскольку ценовое лидерство достигается ни за счет снижения общих затрат на разработку, а благодаря снижение стоимости отдельной копии за счет роста числа продаж, то есть за счет рыночного лидерства. Иными словами, если компания хочет потратить миллион долларов на проект автоматизации, то оценка проекта - миллион долларов. Проекты автоматизации некогда не делаются дешевле или быстрее, чем было запланировано. Но заниженная оценка - оценка меньше себестоимости - не приведет к снижению затрат. Нет универсального рецепта оценки стоимости проекта. Но выбор между точностью и правильностью должен делаться в пользу последней.
Правильная оценка предполагает:
- учет затрат на собственные ресурсы не по затратной, а доходной (альтернативной) оценке;
- учет стоимости времени (необходим для сравнения различных вариантов автоматизации);
- полный учет существенных затрат;
- учет рисков;
- учет дисконтированной полной стоимости владения (TCO) за ожидаемый срок эксплуатации системы
Оценка проекта автоматизации должна основываться на основе оптимального плана закупок. В случае неудачного завершения проекта (не внедрения системы) все затраты проекта являются убытками. В отличие от материальных активов, программное обеспечение невозможно перепродать. Что бы уменьшить риск потерь следует относить затраты на поздние этапы, и, в первую очередь, отсрочить покупку лицензии на программное обеспечение до завершения настройки и доработки системы. Уменьшению рисков способствует также использование контрактов с фиксированной ценой. Управление рисками и оценка проекта - это два параллельных взаимосвязанных процесса. Оценка проекта автоматизации требует согласованной оценки различных видов затрат, и в каждом случае требуется использование специальных методов. Должен быть согласован уровень точности оценок затрат разного вида, рисков, а так же параметры, используемые в расчетах, например, сроки внедрения и эксплуатации системы. Качество полученной оценки зависит от полноты учета существенных затрат проекта, учета рисков, а так же качества оценки каждой составляющей.
|